EHR and Genomic Data
Pulling genomic data into EHR is a complex task because of the volume of genomic data and the difficulty in interpretation.
Bringing Digital health & Gen AI research to life!
Pulling genomic data into EHR is a complex task because of the volume of genomic data and the difficulty in interpretation.
I have tried to summarize basic steps in a physician-patient encounter.
A PICTURE OF A RDF (Photo credit: Wikipedia) |
I have been an RDF fan even before I used it for dermbase. I promptly signed the Yosmite Manifesto and blogged about it last year. After gaining more experience in the regional health information exchange initiative(s), I still feel that RDF is important, but in a different way.
Most federated regional clinical viewers query host databases, convert the results into an intermediary format (mostly xml or HL7), apply filters and then provide a consolidated view in the browser and mobile as html embellished with jQuery. Though this seems not-so-scalable technology, it works remarkably well in a regional context. Federated clinical viewers also attempt to create data warehouses on top of the Clinical Viewer. Such data warehouses have enormous potential in population informatics and RDF could be an ideal framework for this purpose.
RDF is a proven technology that is schema agnostic. However in this context the biggest advantage of RDF is its data-atomic nature that enables each data element to be queried, changed, or deleted independent of any other data element. RDF blank nodes can be used to effectively anonymize the data. From a data analytics perspective representation in the RDF format makes data amenable for “reasoning” to discover new knowledge.
Genomic data analytics has revolutionized pre-clinical research. Growing popularity of Health Information Technology (HIT) and Health Information Exchange (HIE) has not yet resulted in a similar impact on population health. There are some fundamental differences between genomic and clinical data.
The fundamental characteristics of genomic data are:
1. The data format is simple though it can be annotated in different ways.
2. Raw data is collected first without consideration of relevance. Hypothesis formulation and analysis come later.
3. The data is mostly anonymous.
4. The format and analysis protocol remain the same.
The clinical data has different characteristics:
1. The data is often complex and hence it is difficult to have a uniform format.
2. Data is collected to prove or disprove a hypothesis/diagnosis. Hence only relevant data is collected.
3. The data is often tagged to an individual.
4. The analysis protocol and data collection depends on the hypothesis/diagnosis.
RDF framework would allow abstracting population data from normal everyday HIE data for clinical practice, but both operating within the same ecosystem. The framework will also allow clinical data to have the analytics friendly qualities of genomic data. The clinical viewer can push data into the RDF repository without a separate warehousing process thereby reducing overhead and increasing relevance. New generation wearable devices and monitors can push anonymized raw data directly into the RDF repository. The privacy and security concerns of this architecture will be minimal.
There is another hitherto unexplored advantage for such a clinical RDF repository. Temporal data related to climate changes and other events such as natural calamities can also be pushed into the “structureless” RDF repository making it possible to assess the population health impact of such events.
The e-Health lessons from healthcare.gov debacle is being debated widely. The idea of applying large scale IT initiatives in clinical domains has its own risks. As we relentlessly move towards a fully digital healthcare ecosystem, is it possible to hide some of its complexities from the clinicians?
Patient empowerment is the buzzword in eHealth now and clinicians are generally viewed with some skepticism. EHealth has learnt over the years (in the hard way) that the clinicians may be reluctant to relinquish their firm grip on clinical data. After all they generated the data and they are the custodians though they do not own it!
One of the approaches worth trying is to give the clinicians control and freedom over their end of things. In other words, separate enterprise EMR from the physician EMR. However the key to success in this scenario is interoperability.
Interoperability of EMRs are being actively explored by many research teams and organizations. However the emphasis is on better standardization. As interoperability emerges as a global paradigm, the standardization strategy that has failed for the last decade or so, still seems impractical?
I am working on an interoperability solution that segregates physician EMR solutions logically and physically from Enterprise EMR solutions. I would like to call this Bring Your Own EMR (#BYOE) pronounced as ‘bio’. The general framework is shown above. If you would like to join the #BYOE initiative or give feedback, shoot me an email!!
Bring Your Own EMR by Bellraj Eapen is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at http://nuchange.ca/?p=21.
Please cite this page as: Eapen BR. Bring Your Own EMR (#BYOE) . Available from: http://nuchange.ca/?p=21