ML has opened up avenues in life sciences at such a pace that everyday researchers are looking for new ways to apply it to health care. From drug discovery process to computer-aided diagnostics and detection, from early sepsis prediction to automated pre-screening of radiology scans, ML are being deployed everywhere today.
No single observational data source provides a comprehensive view of the clinical data a patient accumulates while receiving healthcare, and therefore none can be sufficient to meet all expected outcome analysis needs. This explains the need for assessing and analyzing multiple data sources concurrently using a common data standard. This standard is provided by the OMOP Common Data Model (CDM).
Common Data Model (CDM)
The CDM is designed to support the conduct of research to identify and evaluate associations between interventions (drug exposure, procedures, healthcare policy changes etc.) and outcomes caused by these interventions (condition occurrences, procedures, drug exposure etc.). Outcomes can be efficacious (benefit) or adverse (safety risk). Often times, specific patient cohorts (e.g., those taking a certain drug or suffering from a certain disease) may be defined for treatments or outcomes, using clinical events (diagnoses, observations, procedures, etc.) that occur in predefined temporal relationships to each other. The CDM, combined with its standardized content (via the Standardized Vocabularies), will ensure that research methods can be systematically applied to produce meaningfully comparable and reproducible results.
Fast Healthcare Interoperability Resources (FHIR)
FHIR is the latest standard to be developed under the HL7 organization. Pronounced ‘Fire’ , FHIR stands for Fast Healthcare Interoperability Resources.
Technically are starts from a sound foundation:
It’s a more granular way to exchange data without the rigid workflow of traditional HL7.
No overhead of SOAP and other nonsense by using a straightforward RESTful style approach.
High emphasis on conformance and reference implementations, connectathons etc. as part of the core process.
It focuses on hitting 80% of the common use cases rather than the 20% of exceptions (80/20 rule).
But more important than the technical factors, FHIR addresses some real needs in the market. It passes the smell test of enabling people to make money and save money. These are the drivers:
• Mobile healthcare applications and the cloud
• Medical device integration
• More flexible custom workflow
That’s what’s exciting about FHIR – this standard really could be useful and actually drive new efficiencies. For vendors it represents an opportunity to offer more value to their clients and build new revenue streams. For end users this offers ways to streamline and improve patient care and drive down bottom line costs.
CDM vs. FHIR
There are pros and cons to each.
The OMOP CDM is great. It was essentially THE standard for creating ambitiously interoperable clinical models that required the unification of multiple data types; before FHIR you didn't really have anything else. The main issue with using it in practice however, was actually getting your data into the CDM representation. This was easier (but still time consuming) for concepts where relatively widely used vocabularies already exist (SNOMED, LOINC, etc) because you could use those as a bridge into the CDM. But if your organization either hadn't implemented these coherently (very common in multiple-hospital systems) or if you wanted to use something else it was a major pain because all of a sudden you had to delay some graduate student's dissertation work for 6 months while they went through and coded all your stuff.
The advantage of FHIR is that the EHR vendors have already signed on to support it, so if you use an EHR that supports FHIR (which is all the major ones) then the data you want to use can be readily accessed already coded as FHIR concepts. The tradeoff is that a much smaller number of concepts are currently available for use. While there is functionality in FHIR to create your own unsupported concepts, this kind of goes against the whole interoperability idea and is pretty heavily discouraged.
Currently the CDM is preferred for the process of creating clinical models, for a few reasons. First, it's more descriptive, allowing you to build more robust models with a wider array of concepts. Second, (this used to be an issue, not sure if it still is, however) some institutions with FHIR enabled EHRs can't actually support large scale data extraction through FHIR required to build datasets on which to build models. These institutions can, however, still use the old method where you run a bunch of time- and computationally-intensive SQL queries on a backup of their EHR's relational database (once a month if you're really lucky), which you can then map into the CDM to create your dataset.
Where FHIR really has its potential is in the development of apps that sit on top of it. Since FHIR apps can query the EHR for information, the models that you've built will run in real time, with basically no extra work. With an old CDM-based model, you needed to encode the real time EHR data into CDM concepts on the fly, which was either (a) impossible, rendering many time-critical models unusable or (b) involved a collaboration with your EHR vendor to build a custom module.
There is a group at Georgia Tech that maintains a mapping between the CDM and FHIR, which allows clinical researchers to build high-performance complex models using the CDM, and then translate it into slightly-lower-performance simpler models using FHIR concepts for implementation. As the concepts supported by FHIR increases, the usefulness of apps built on FHIR should improve as well.