One of the biggest complaints in healthcare is the lack of interoperability. But the nitty-gritty of how to achieve interoperability is messy. Standards are an acronym soup. What is SNOMED, LOINC and DICOM? How is HL7 FHIR related to SMART on FHIR? Who is the ONC? How is any of this relevant for the digital medicine community? This article provides an overview of the current landscape of health IT standards relevant for digital medicine.
As a research lead at The Digital Medicine Society (DiMe), I wanted to tackle a topic that is foundational to the success of our young field. DiMe convenes clinicians, researchers and developers for open discussions around standards and we welcome your feedback on this piece in the comments and/or via Twitter.
Digital health data is growing 40% year on year. In addition to traditional lab and diagnostic tests, clinicians, researchers and patients now have access to social, environmental and sensor data collected continuously outside of the clinic.
How can the healthcare community leverage all this exciting, yet overwhelming, data to inform clinically meaningful decisions? We need an efficient way to integrate the data from digital tools into electronic health records (EHR) and personal health records (PHRs) so information can be shared between clinical or research teams and their patients.
Many in the digital medicine community recognize the importance of adopting standards for the format, exchange and security of digitally captured clinical data. Without consistent use of agreed upon standards, digital medicine risks further burdening the healthcare system with untrustworthy and siloed data — but where do we begin?
Before we promote the broad adoption of any existing standards or begin developing new ones, the digital medicine community first needs a baseline knowledge of key terms and important organizations in health IT.
The goal of this post is to present the current landscape of health IT data standards, highlighting resources that are accessible to multiple stakeholders, with special emphasis on:
Standards are simply an agreed upon method for doing something. Of note, standards are different from specifications and guidances.
This post will be specifically focused on health IT standards. In health IT, standards refer to “agreed-upon methods for connecting systems together.” The Healthcare Information and Management Systems Society (HIMSS) categorizes health IT standards into four types.
Categories of Health IT Standards by HIMSS
These four types of standards are important because patients interact with the healthcare system in a multitude of settings. Let’s consider an example:
A patient is admitted to a hospital because of a cardiac arrhythmia. While in the hospital, the patient gets an electrocardiogram (ECG) and the results are stored in the hospital’s EHR system. When the patient is discharged, they follow up with their cardiologist who is not affiliated with the particular hospital where the patient was admitted. Let’s say the patient is able to bring a paper copy of the ECG to the cardiologist’s office. If the hospital and the cardiologist use the same content and terminology standards for what the data in an ECG is supposed to be, then the report is valuable to the cardiologist in making an informed patient care decision. In today’s world, likely the cardiologist will want to access the ECG electronically. In order to do this, the EHR in the cardiologist’s office needs to “talk” to the EHR in the hospital. To allow for meaningful exchange of the patient’s ECG data between institutions, the EHR systems not only needs to follow the same content and terminology standards but transport and privacy standards as well.
When “talking” between EHR systems is successful, the systems have achieved interoperability. Interoperability is defined as
“the ability of different information systems, devices or applications to connect, in a coordinated manner, within and across organizational boundaries to access, exchange and cooperatively use data amongst stakeholders, with the goal of optimizing the health of individuals and populations.”
Although achieving interoperability is the ultimate goal of adopting and consistently using health IT standards across the health system, this task is a lot easier said than done.
To help keep stakeholders in the industry on the same page, a government organization will typically be charged with the oversight of standards.
The Office of the National Coordinator for Health Information Technology (ONC) is one of the leading government agencies that works with the health IT community to promote the use of standards. In 2015, they published a 10 year roadmap for building a standards based infrastructure to promote interoperability in the healthcare system. They annually publish the Interoperability Standards Advisory (ISA) to summarize adoption of existing health IT standards for clinical and research purposes.
Standard Development Organizations (SDO) are “member supported organizations, who develop and maintain standards to meet industry needs.” SDOs in the healthcare industry are often accredited by the American National Standards Institute. An SDO is composed of paid staff and volunteers from a wide range of backgrounds (ex: providers, insurers, health IT software developers, patients) who contribute knowledge and skills to publish and update standards. According to the ONC, there are at least 40 SDOs involved in health IT standards.
For example, Health Level Seven International (HL7) is an accredited SDO founded in 1987 focused on clinical and administrative data. HL7 has over 500 corporate members across 50 countries.
A deep dive on FHIR and SMART on FHIR
In this section, we will do a deep dive on FHIR and SMART on FHIR as two standards that have been highlighted by the ONC and commonly used by health tech companies.
Fast Health Interoperability Resource (FHIR) is a standard for data exchange developed by HL7. FHIR is constructed using data models, called resources. There are distinct resources for different types of clinical and administrative information that can be documented and exchanged. For example, there is a resource for medication orders, one for care plans and one diagnostic reports.
A key feature of FHIR is that resources can reference each other to form a web of data. This is important for adding context when a system is looking at a single resource. For example, if a system receives a blood pressure measurement as an FHIR Observation Resource, the system can issue a query for a time series of historical measurements, or a query for information about the hospital where the measurement was taken, or the name of the clinician who took the measurement. For developers, this is a key distinction from the previous HL7v2 standard that relies on structured messaging instead of resources.
Another key feature of FHIR is that resources are built on structures and protocols very familiar to developers from other industries. FHIR resources can be represented as either JSON or XML and can be accessed over a http-based RESTful API.
Software Engineering 101
JSON and XML: data serialization and transport languages. JSON is more broadly used among developers today than XML.
Application Program Interface (API): code that allows web based applications to communicate and exchange information in a standard way.
SMART stands for Substitutable Medical Applications and Reusable Technologies. As an organization, SMART aims to create an ecosystem built on standards to allow developers to make apps that can function in any healthcare system, regardless of EHR vendor. Some of SMART’s key work has been the App Launch protocol focused on data security. The protocol defines a set of OAuth 2.0 and Open ID Connect profiles for how third party applications access a patient’s health data in a FHIR supported EHR. Thus, the protocol is commonly referred to as SMART on FHIR. FHIR defines where the data is located and how it looks while SMART’s App Launch protocol defines who can access it. TL;DR for developers: you can think of SMART on FHIR as OAuth for a healthcare application.
Security surrounding access to health data is different than other types of consumer data due to HIPAA legislation that provides privacy and security provisions for safeguarding medical information. Using SMART’s protocol, developers can ensure a secure login to sensitive health information stored in a digital tool or app. The protocol also enables designations of different levels of access. For example, a patient is only able to view a medication order but a provider is able to view, change or create an order. HIPAA violations are punishable by law so it is very important to pay attention to privacy standards. Of note, similar privacy protections exist internationally as well. For example, the European Union enforces the General Data Protection Regulation (GDPR), which came into effect in May 2018.
Yes! Though like any adoption, it’s a slow process with a lot of room for growth and many challenges still to overcome.
The ONC is cautiously optimistic about FHIR implementation as a key step to improving interoperability. The ONC determined that as of 2015 approximately 32% of developers certified through the agency are using FHIR Release 2 as the data exchange standard in health IT products. Nearly 51% are combining FHIR and OAuth 2.0 (aka SMART on FHIR), perhaps indicating that developers are cognisant of the importance of HIPAA compliance.
Among the top ten health IT developers with the largest market share (i.e. Cerner, Epic, Meditech), 82% of hospitals and 64% of clinicians reported using FHIR Release 2 to meet the ONC’s 2015 Edition of health IT certification criteria, meaning that FHIR has significant popularity in the field.
As top EHR vendors like Cerner and Epic move towards consistent adoption and implementation of SMART authorization and FHIR data models, opportunities are available for tech companies to build more advanced products in the healthcare industry. For instance, Apple’s Health app uses a SMART on FHIR interface to retrieve medical record data from an EHR and display the records on a patient’s iPhone. In June 2019, the app became available for any healthcare organization whose EHR is configured using FHIR APIs allowing for patient access. Cerner, Epic, CPSI Evident Thrive and just recently Allscripts (as of August 2019), support implementation of the Apple product. Consistent use of standards among EHR vendors can shift the healthcare ecosystem towards improved patient engagement by expanding patient access and control of their own health data.
SMART has other projects geared towards developers, providers, patients and hospitals looking to integrate data from mobile apps into EHR systems. The App Gallery and sandbox allow public access to open source tools for developers to build and test their applications. Having an open platform is important because sharing consistent and uniform methods (standards!) fosters transparency and trust between stakeholders.
Another example of an open platform for integrating data collected on digital tools or apps is Open mHealth. Open mHealth has been advocating for open interoperability standards for mobile health data since 2011. Their work to develop Shimmer, an application for reading health data from third party APIs and Granola, a serialization library for Apple HealthKit data, are both open to developers on GitHub. In 2017, in collaboration with IEEE, Open mHealth started the P1752 Open Mobile Health Working Group to begin development of standards for meaningful description, exchange, sharing, and use of data collected from sensors and mobile applications. To address high priority areas, there are subgroups for sleep, physical activity and mobility and metadata.
Similar to FHIR, Open mHealth is constructed of data models. The data models, called schemas, are specifically focused on data collected from digital tools. For example, there are schemas for activity and sleep. While the scope is narrower than FHIR, Open mHealth’s schemas are intended to be lightweight and meet the unique challenges of data collected from digital tools (see more below!). Importantly, Open mHealth and FHIR can work together. This implementation guide describes how Open mHealth can be combined with FHIR to pull health data from popular APIs like Google Fit, Fitbit and Apple Health and make it accessible in EHR systems as FHIR Observations.
If Cerner, Epic and Apple are onboard, the industry must be moving forward swiftly towards full interoperability, right? Yes and no.
The healthcare industry has largely decided de-facto on FHIR and SMART on FHIR as being worthwhile and we’ve made huge progress in their implementation and adoption. While FHIR in particular has gained a lot of hype, there are many challenges in reaching interoperability including business concerns among EHR vendors and culture shifts among clinicians around why, when and how to share data.
When thinking about how to get the data from digital tools, like smartwatches, activity trackers or other sensors, into the EHR and integrated into physicians’ workflows, there are some questions our community needs to ask.
The following articles further explore the challenges of integrating data from digital tools into the EHR.
Data standards may be wonky, but they will transform healthcare. STAT, October 2019
Integrating Physical Activity Data with Electronic Health Records. BIOSTEC Conference, February 2019
From smartphone to EHR: a case report on integrating patient-generated health data. Nature, June 2018
Extending HL7 RIM Model to Capture Physical Activity Data. International Conference on Software Engineering and Knowledge Engineering, July 2017
The Wild Wild West: A Framework to Integrate mHealth Software Applications and Wearables to Support Physical Activity Assessment, Counseling and Interventions for Cardiovascular Disease Risk Reduction. Progress in Cardiovascular Diseases, May/June 2016
Integrating Data from “Wearables” into EHR. MGMA STAT
The Digital Medicine Society (DiMe), the 501(c)3 professional society for those who practice in the digital era of medicine, convenes clinicians, researchers and developers for honest discussions on how to proceed in the development, adoption and adherence to open data standards. DiMe’s goal is not to become a standards setting organization. Nonetheless, we are well placed to bring together experts from different disciplines and fields to identify their needs for new standards and challenges with existing methods. This post is the first step towards starting conversations around data standards for digital medicine.
DiMe is committed to highlighting and promoting collaboration across existing initiatives already underway. For example:
Participation in the workgroups and open platforms listed above is a great way to get involved and work towards interoperability solutions.
Want to stay up to date with data standards and other current topics in digital medicine? We welcome you to join DiMe to build the future of digital medicine with us.
Special thanks to Simona Carini, Andy Coravos, James Gannon, Jennifer Goldsack, Dan Gottlieb, David Haddad, Josh Mandel, Ernesto Ramirez, Mark Shervey and Noah Zimmerman for their expert contributions to this piece.