I recently had the pleasure of attending the Society of Clinical Data Management (SCDM) Annual Conference (September 2022) in San Antonio, TX. While I’ve been in healthcare all of my professional life, I’m a relative newcomer to the clinical research and life sciences world. The event was a great crash course in all things data-related for life sciences. Notably, I was impressed with the spirit of camaraderie and helpfulness. In every single one of my sessions, audience members were answering each other’s questions, offering advice, and sharing their data management war stories. It was great to see that level of collaboration!
I was also impressed to witness robust discussions on leveraging emerging and maturing interoperability standards such as Fast Healthcare Interoperability Resources (FHIR). The excitement around the possibility of leveraging a ubiquitous interoperability paradigm is understandable. There have been historical attempts to drive interoperability meaningfully forward that have had limited success. It may be helpful to examine the lessons learned from previous attempts, to ensure better results with implementing new approaches.
A brief history
The challenge of communicating complex clinical information between disparate systems has existed for decades. Emerging in the late 1980s, the HL7 v2 messaging standard attempted to solve point-to-point communications between systems within a hospital, including patient administration, lab, and radiology. The HL7 v2 messaging standard succeeded in becoming a ubiquitous interface format for very specific use cases. It enabled the communication of an event (patient admission, lab order), as well as context (patient, ordering provider, encounter, location). In general, systems had to agree on the specific interpretation and implementation of the standard. Lab systems would put out their HL7 interface specifications for ordering systems to consume. Each system may have had a slightly different implementation of the standard; however, given the strong business need, dedicating IT resources to integration projects was an easily justifiable expense. In this model, both the sending and receiving systems were known to each other; developers on either side would have the luxury of communicating, aligning on their implementation and engaging in point-to-point testing.
As electronic health records started to mature, the industry started to focus on broader use cases. Point-to-point connectivity doesn’t scale when a provider needs to refer a patient to any other provider in their community, regardless of what Electronic Health Record (EHR) system they’re using. Similarly, if a patient arrives incapacitated in the ER, the ER’s Hospital Information System likely hasn’t built a web of point-to-point interfaces with every other healthcare provider in the community to pull prior medical histories. There was a need for broader interoperability between unknown systems.
In the early 2010s, Meaningful Use (MU) emerged as something that many hoped would be a galvanizing force to both ubiquitous adoption of EHRs across all care providers (Stage 1)1 and the [meaningful] use of interoperable standards and technologies (Stage 2).2 Specifically, to receive incentive payments (and to avoid penalties) through the Centers for Medicare & Medicaid Services (CMS), providers had to:
Use Certified EHR Technology (CEHRT), and,
Prove that they were using it meaningfully. For example, providers had to prove that 5% of their patients were viewing, downloading, or transmitting their encounter summaries electronically. Providers were forced not only to make this data available via patient portals but also to encourage their patients to access that information.
To support wide-scale interoperability, the Office of the National Coordinator for Health Information Technology (ONC) created a set of specifications that all EHR vendors needed to adhere to in order to certify. If you were an EHR company in the early 2010s, achieving MU2 Certification became a prerequisite for market success. These standards dictated both the format of the data when transitioning care (built upon HL7’s Clinical Document Architecture [CDA]), as well as the specific terminology systems to be used within these documents. For example, Medications must include an RxNorm code, while Problems were to include a SNOMED CT or ICD-9 code. Additionally, ONC specified the transport mechanisms to be used to share these documents amongst various healthcare providers.
What worked
MU Stages 1 and 2 were absolutely a forcing function to widescale adoption and usage of EHR technology, with 89% of the country’s physicians adopting EHR technology by 2015.3 Most EHRs were able to export and import C-CDA documents in some discrete manner, enabling at least a basic form of data portability between systems.
What didn’t work
Many of us, during that time, thought that C-CDA and MU2 would finally help us achieve interoperability at scale. And while it moved us forward, it was hardly the panacea of clinical data exchange we had hoped for. In reality, C-CDA documents were hugely complex, and specifications were ambiguous enough to leave room for interpretation. As developers, we needed to account for an infinite level of complexity and interpretations of the standard. Additionally, EHR terminologies are hugely complex and detailed. Oftentimes, codes are “overtaken” or extended for use by a clinic, muddling their meaning across systems. Many EHRs relied on external management systems to provide clinical terminologies that needed to be purchased by each practice. This led to varying implementations and usage of those terminology sets, even within a single EHR vendor’s universe. In short, data was flowing, but it was still difficult to understand semantically.
A new hope
In early 2011, Grahame Grieve, one of the original architects of FHIR, posted4 about the need for a simpler, more sensical framework for exchanging data, based on the goals of a new task force (Fresh Look) set up by HL7. By the mid-2010s, many in the industry agreed with Grieve’s view, leading to more widespread popularity of FHIR. EHRs slowly started to adopt early draft versions of the standard in recognition of its simplicity and sensibility. In 2016, lawmakers enacted the 21st Century Cures Act, tasking ONC with creating a set of interoperability rules5 to finally drive ubiquitous exchange of clinical data (again). While the specific details of the law will not be discussed here, below are some [oversimplified] key concepts from the Act. The interoperability rules:
Created a definition (and specific prohibition of) Information Blocking actors
Mandated the need to share clinical data electronically with both patients and covered entities as allowable by the Health Insurance Portability and Accountability Act (HIPAA),6 first limiting to specific data, and then broadening the scope of data to be shared
Mandated the use of FHIR (version R4) for structured clinical data exchange, requiring that EHRs support this version of FHIR and that healthcare providers actually implement those EHR versions.
Compliance guidelines were on a rolling basis, with a major deadline7 (support for FHIR R4) arriving at the end of 2022. Where does that leave us?
All healthcare organizations in the US will support some level of exchange via FHIR.
FHIR R4 contains a set of normative resources, which means they are unlikely to change and are considered to be well-adopted and safe to use at scale.
There is a fairly robust set of data classes and elements in the United States Core Data for Interoperability (USCDI)8 that what we can expect as input.
So, nationwide clinical data exchange is just around the corner, right? Not quite so fast…
Levels of interoperability
I’ll start with some guidance from the Health Information and Management Systems Society (HIMSS), on how it classifies various levels of interoperability9 between systems:
Health Information and Management Systems Society (HIMSS) levels of interoperability.
| Level | Description | Example | |
|---|---|---|---|
| Level 1 | Foundational | Establishes the inter-connectivity requirements needed for one system or application to securely communicate data to and receive data from another. | Establishing an SFTP to exchange clinical files. |
| Level 2 | Structural | Defines the format, syntax and organization of data exchange including at the data field level for interpretation. | Agreeing to use Consolidated Clinical Document Architecture (C-CDA) documents to exchange information and agreeing to the minimal set of data and fields to be included (this document will contain a “Gender” field). |
| Level 3 | Semantic | Provides for common underlying models and the codification of the data, including the use of data elements with standardized definitions from publicly available value sets and coding vocabularies, providing shared understanding and meaning to the user. | Specifying which clinical terminologies are going to be used, sharing code sets and mappings, or creating canonical understanding of various codes (M = male, F = female, etc.) |
| Level 4 | Organizational | Includes governance, policy, social, legal and organizational considerations to facilitate the secure, seamless and timely communication and use of data both within and between organizations, entities and individuals. | Providing blanket trust, based on a third-party intermediary (such as DirectTrust), and automated mechanisms to communicate patient consent and the purpose of use of exchanged clinical data. |
The Challenge Remains
According to the definitions above, FHIR, and its mandate from 21st Century Cures, provides Level 2 (Structural) and, to some degree, Level 3 (Semantic) interoperability, guaranteed to be implemented to some degree by every healthcare organization in this country. However, there are still a few major challenges to be overcome:
Organizational interoperability – in order to exchange via FHIR, you must (i) enter into data sharing and usage agreements between parties, (ii), discover endpoints and be granted access, and (iii), ensure trust and patient consent are accounted for, communicated, and potentially revocable during exchange.
Semantic interoperability – when integrating between two, well-known endpoints and organizations, coming to canonical understanding of the specific terminologies to be used, and the ways in which they’re leveraged is relatively simple. Creating ubiquitous, large-scale canonical understanding and agreement only comes with time and concerted effort across the industry. We are not there yet.
Structural interoperability – in theory, when all systems support the same version of FHIR, they are inherently at least structurally interoperable. In practice, I remain highly skeptical that “we got it right the first time”. In reality, there will be multiple interpretations, and these will require real world testing, adjustments, and redeployments to get to a widely accepted, converged and true standard.
A Path Forward
The excitement about the prospect of finally having easy, scalable access to EHR data for clinical research is understandable. Clinical data collected through the course of a study must conform to study protocols and data standards to be effective at evaluating results across a population. This competes with much of the purpose of an EHR, meant to capture and structure detailed data about an individual patient, to facilitate billing and care delivery. The practice of Population Health Management seems to fall between these two broad approaches: population-level analytics based on detailed clinical data collected from disparate sources.
Having worked through these challenges when implementing large scale Health Information Exchanges and Population Health Management programs, I offer the Clinical Data Management organization implementing a broad scale EHR data acquisition strategy the following pieces of advice:
Always expect to take a multi-pronged approach. The truth is that while organizations will do what they must for compliance, they have already made significant investments in exchanging clinical data for targeted use cases. Ensure there is flexibility within your data ingestion stack to support multi-variant transport mechanisms and content formats (such as HL7v2 and C-CDA documents). Decouple these from your core business processing logic by creating an internal canonical model.
Consider evaluating tools leveraged by healthcare institutions. To create semantic interoperability, you may consider leveraging clinical data mapping technologies, such as Clinical Architecture and Intelligent Medical Objects (IMO), to help manage the complexities of the terminologies themselves, and the organization-specific cross-mappings. These technologies may help to map the highly detailed taxonomies of clinical data to those more relevant for clinical research.
Follow Postel’s Robustness Principle. Within the original Transmission Control Protocol (TCP) specification,10 one of the original authors, Jon Postel, stated, “be conservative in what you do, be liberal in what you accept from others”. In this case, expect to have a wide variety of inputs and interpretations of standards, and ensure your stack is robust enough to account for the implementation of specific variations.
Finally, it’s not all doom and gloom. I firmly believe that FHIR is a richer, simpler and fundamentally better standard that will drive healthcare interoperability meaningfully forward. Having the regulatory tailwinds to support its adoption is key to its success. However, it is too early to declare the problem solved, so let’s ensure we continue to keep sight of the entire field of opportunities available to acquire clinical data.
Competing Interests
The author is a current employee of Medidata Solutions, an organization providing technology solutions for clinical trials and research.
References
1. Centers for Medicare and Medicaid Services. Medicare & Medicaid EHR Incentive Program: Meaningful Use Stage 1 Requirements Overview. 2010. Accessed October 10, 2022. https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/downloads/mu_stage1_reqoverview.pdf
2. Centers for Medicare and Medicaid Services. Eligible Professional’s Guide to Stage 2 of the EHR Incentive Programs. 2013. Accessed October 10, 2022. https://www.cms.gov/regulations-and-guidance/legislation/ehrincentiveprograms/downloads/stage2_guide_eps_9_23_13.pdf
3. Alammari D, Banta JE, Shah H, Reibling E, Ramadan M. Meaningful Use of Electronic Health Records and Ambulatory Healthcare Quality Measures. Cureus. 2021; 13(1): e13036. Published 2021 Jan 31. DOI: http://doi.org/10.7759/cureus.13036
4. Grieve G. HL7 needs a fresh look because V3 has failed. Published August 15, 2011. Accessed October 7, 2022. http://www.healthintersections.com.au/?p=476.
5. Office of the National Coordinator for Health Information Technology. ONC’s Cures Act Final Rule. Published 2020. Accessed January 10, 2023. https://www.healthit.gov/sites/default/files/page2/2020-03/HighlightedRegulatoryDates.pdf.
6. Keeler B. The gang explains information blocking: HIPAA. The Gang Explains Information Blocking: HIPAA. Published November 7, 2021. Accessed October 10, 2022. https://healthapiguy.substack.com/p/the-gang-explains-information-blocking#%C2%A7privacy-rule.
7. Office of the National Coordinator for Health Information Technology. Cures Act Final Rule: Highlighted Regulatory Dates. Published 2020. Accessed October 10, 2022. https://www.healthit.gov/sites/default/files/page2/2020-03/HighlightedRegulatoryDates.pdf.
8. Office of the National Coordinator for Health Information Technology. United States Core Data for Interoperability (USCDI). Interoperability Standards Advisory (ISA). Published 2020. Accessed October 10, 2022. https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi.
9. Health Information and Management Systems Society. Interoperability in Healthcare. Published August 25, 2021. Accessed October 10, 2022. https://www.himss.org/resources/interoperability-healthcare#Part1.
10. Postel J. ed. DOD Standard Transmission Control Protocol. Information Sciences Institute, University of Southern California. 1980. https://www.rfc-editor.org/rfc/pdfrfc/rfc761.txt.pdf. DOI: http://doi.org/10.17487/rfc0761