Interoperability, key element for CDS
A few weeks ago, we wrote about the Clinical Decision Support Systems (CDS) and the work we are developing at Gradiant in this field.
To summarise, CDS are sophisticated components of the Electronic Health Record (EHR) that generate and present information useful to the clinical practitioner so that, without disrupting their workflow, they can make an informed decision and act accordingly. To do this, CDS require computable biomedical knowledge, patient-specific data, and a reasoning mechanism that combines both.
In this post, we want to go into detail about the knowledge of these components, especially in the question of interoperability, and the importance that this property has for health information systems to expand their capabilities and exploit their full potential.
What does interoperability represent for healthcare?
Healthcare system is an information-based institution that generates a large amount of data from several applications and systems. Professionals face a major challenge in trying to share data across disparate platforms, some of which cannot easily communicate with others. Interoperability allows different systems and applications to communicate with each other, favouring that providers can access and integrate information regardless of the system the data is stored in.
Healthcare Information and Management Systems Society (HIMSS) defines interoperability as the ability of systems and devices to exchange and interpret shared data. Systems must not only be able to share information, but must also know how to use it and present it intelligibly to the user. The HIMSS definition of interoperability is established in a three-tiered model:
- Fundamental interoperability. This layer ensures that the data transmitted by one sanitary software system is received by another. However, the transmission receiving system is not required to interpret said data. Fundamental interoperability, can be considered as the basis of a communications pyramid, offering the most basic exchange services.
- Structural interoperability. It is an intermediate layer that defines the format of the exchanged data. HIMSS points out that this form of interoperability, also known as syntactic or technical interoperability, allows the “uniform movement” of health data from one system to another where “they are preserved and maintained without altering the clinical and operational purposes and the meaning of such data”.
- Semantic interoperability. It provides the highest level of interoperability: the ability of two or more systems or devices to exchange information and use the information that has been exchanged. In the health sector, semantic interoperability is critical to bridging the terminology gap between various health software systems and data sources.
Why is interoperability so important?
Interoperability allows the exchange of patient information stored in different geographies and by different entities: organizations, vendors, Electronic Health Record (EHR) systems and other software systems, such as CDS.
In the area of healthcare, this capacity has great potential in streamlining the clinical care workflow thanks to:
- Improving efficiency. When data are presented on a consistent basis, no matter what the source, it is easier for practitioners to quickly get to the bottom of the issue as they make treatment decisions, and it becomes easier provide technological solutions that help them make those decisions.
- Safer care transitions. Continuity of care is crucial for patients, whether for chronic conditions or to deal with an acute situation with multiple health care providers. Interoperability allows for safer transitions of care, which leads to better outcomes for patients in general.
For example, a patient who is on vacation and needs to go to the emergency room may not be able to provide all the details of their medical history. The doctor in charge could treat you more quickly and comprehensively if your EHR data were accessible from the hospital you are in.
- Can help lower costs. Information can be shared early and timely. Therefore, data from a patient who underwent a blood test last week at their doctor’s office can be used today during an emergency room visit, saving the time and cost of repeating unnecessary tests at Hospital.
Greater efficiency through greater exchange of information would save time and effort, resulting in greater cost savings.
Addressing therefore the challenge of interoperability has become a critical point for health care. Interoperable systems provide better quality and timely healthcare by making it easier for physicians, as well as healthcare software systems, to access patient health information, reducing medical errors and misdiagnoses.
However this streamlining in the information query is not immediate. It will only work to the extent that different medical software providers agree to share what some of them may consider as system information.
How do you achieve interoperability?
Healthcare software systems have traditionally “spoken” different languages, making difficult (and in many cases impossible) to communicate and interact between them. In order to make these systems to exchange information as fluidly as possible, it is necessary to adopt standards.
Health standards regulate how patients’ information is stored and electronically exchanged. Open standards allow developers to create applications that can be connected to health data systems (such as electronic medical records), and databases without the need for specialized knowledge about each system. For clinicians, patients and researchers, the standards offer the possibility of having an ecosystem of third-party applications that can offer EHR modules tailored to their needs, as well as expand systems with new capabilities such as support for clinical decision.
Some sectors such as banking or telecommunications have developed and implemented international standards for exchanging electronic data. However, in healthcare national and international development has had to face major challenges. One reason is believed to be that medical records are typically accumulations of interactions involving multiple actors (health professionals, patients, administration …) because, in general, the data they contain are not categorized uniformly and may contain large amounts of free text and images.
Ideally, a single set of standards would provide efficient access to text data, numerical data and images, allowing information to be shared appropriately by health professionals, administrators and consumers. However, the difficult reality of health information systems has generated the need to develop a large number of specific standards for each field of application. It is therefore not surprising that clinical data standards sometimes look like a complex collection of different vocabularies and obscure technical details.
Standards applied to clinical decision support
Although, as discussed above, the CDS offer very promising capabilities, the scalability of many current approaches has limited their impact on health care.
In order to facilitate the creation and adoption of decision support tools, the healthcare industry has developed several standards that encompass both syntactic and semantic interoperability. Currently, several organizations work together to align and unify interoperability criteria, including Health Level Seven International (HL7) and Healthcare Services Platform Consortium (HSPC).
Some of the standards applied to clinical decision support that have been created from this common effort, many of which we have already incorporated into our solutions in Gradiant, are described below.
HL7 InfoButton
Infobuttons are context-sensitive links embedded in EHR that allow retrieving information relevant to the patient in a simple way. During patient care, physicians often need to seek information related to their clinical care activities. Most of the questions often remain unanswered due to lack of time or resources available, which can result in errors in the diagnosis or treatment of the patient and in adverse outcomes. With this type of functionality embedded in the EHR, doctors can access the search results in seconds, thus keeping the focus on the patient.
The HL7 InfoButton specification provides a standard mechanism for clinical information systems to access clinical knowledge resources online. Supported parameters include: coded concepts (ICD-9, ICD-10, LOINC, SNOMED CT, RXNORM, NDC, GPI); subtopics (diagnosis, treatment, etiology, etc.); receiver of information (provider, patient); observations of seriousness (for laboratory results, high, low); age of the patient; gender of the patient; type of meeting (inpatients, outpatients, etc.); context of the task (revision of the list of problems, entry of the medication order, etc.); type of user (resident, nurse, specialist, etc.); and user details (system identifier, user ID).
In this way, clinicians can perform personalized searches at a single click about clinical content relevant to a patient’s specific disease, medication or laboratory results, in combination with age, gender and other contextual criteria, facilitating and accelerating the making decisions without leaving your workflow.
HL7 DSS
The HL7 Decision Support Service (DSS) specification provides a standard Application Programming Interface (API) for service-oriented clinical decision support. This standard provides a common interface for HCE and other clinical information systems to use external clinical decision support features.
The EHR system that wants to use decision support services must be able to package patient data in a standard format, invoke the remote service using standard Service Oriented Architecture (SOA) methods and process the output produced by the service. The EHR will display the results returned by the remote SSDC using its usual methods for displaying information, alerts, or reminders.
This specification does not indicate how the decision support service has to be implemented, nor does it impose any standard on the format of the useful data provided to the service. However, other HL7 standards are generally used as vMR, CDA or FHIR as a model for structuring the data. In addition, DSS requires the use of standard terminologies to encode the data. For example: RxNorm for medications, SNOMED for problems and diagnostics, or LOINC for laboratory results.
However, this standard is being overcome by much more complete standards like FHIR, which we explain below.
FHIR
FHIR stands for Fast Healthcare Interoperability Resources and is the latest standard for the exchange of electronic medical information developed and promoted by the international organization HL7. FHIR has been designed specifically for the web, basing its structures on XML or JSON documents and using HTTP-based REST web services to simplify data exchange processes to the maximum. This is in complete opposition to what could be found to date, using SOAP services in most of the interoperability profiles that were being used.
By using standard APIs, FHIR enables developers to create applications that can be connected to an HCE and enter information directly into the provider’s workflow, avoiding discomforts of other standards that often require the provider to access the data by separated.
FHIR can be used as a standalone data exchange standard, but it can also be used and used in association with existing consolidated and emerging standards. Use cases of this standard are almost unlimited, including advanced CDS functionality.
Two of the most promising open standards that use FHIR to provide clinical decision support capabilities are SMART on FHIR and CDS Hooks.
SMART on FHIR
SMART, Replaceable Medical Applications, is an open source standards-based healthcare application platform architecture developed by Boston Children’s Hospital and Harvard Bioinformatics.
The original goal was to allow any developer to create a health care application that would work in any health organization, regardless of HCE. Initially, its intention was to define a standard that would make this model possible. However, when the FHIR standard began to receive support from the medical community, SMART moved away from standard development and focused on formalizing the process for interacting with FHIR interfaces, describing how applications should be “thrown” from the HCE and standardizing the security protocols used by third parties to exchange data with the EHR systems of healthcare organizations.
SMART on FHIR applications run on electronic health records, allowing physicians to access directly connected applications in their workflow to more easily visualize, interact and transmit health data. The platform seeks to give users options through substitutability, through which a user or institution can choose an alternative application or function through an application store or an EHR repository.
CDS Hooks
CDS Hooks is a specification for provider-independent remote decision support, proposed by Josh Mandel, a researcher at Harvard Medical School and a leading architect for SMART on FHIR.
One of the challenges SMART apps face for integration into the EHR is that the user has to decide and take action to launch the application. Doctors need to know which application will be useful at what point in your workflow. This specification defines a series of hooks that provide information, suggestions or access to a SMART application, within a user’s standard workflow. Even if the doctor did not know of the existence of that application or was not thinking about it, a card is provided reminding him that it exists, and offering to execute it. Therefore, CDS Hooks is really a complementary technology for SMART apps, as it makes it easier to run the right application at the right time, while helping to avoid explicit actions.
CDS Hooks seeks to open the EHR to third-party clinical decision support services. For developers, CDS Hooks provides a model to deeply embed your services and applications into the HCE workflow in an open and interoperable way, leveraging FHIR data and aspects of SMART on FHIR. For providers, CDS Hooks opens a new set of support for relevant clinical decision based on context in its workflow. However, the CDS Hooks specification is still at an earlier stage and clearly less mature than the SMART protocol on FHIR.
The standards applied to support clinical decision-making and, perhaps more importantly, tools and resources that support these standards are critical elements for CDS capabilities to be increasingly available to healthcare providers.
Aware of the importance of interoperability in the healthcare environment, in Gradiant we have adopted the use of open sanitary standards, so that the clinical decision support tools that we develop are accessible to the largest possible public, thus contributing to the improvement of healthcare assistance.
Author: Lorena González Castro, senior researcher – developer in eHealth department at Gradiant.
