Imagine these three scenarios:
1. A patient stops by a busy urgent care center for concerning flu-like symptoms. Rather than waiting a couple hours just to start being seen by the nurse, the patient sits at a kiosk and interacts with an artificial intelligence (AI) assistant that asks the patient some questions tailored to the signs and symptoms. The patient can even follow easy instructions to take her own temperature, capture pictures of her ear drums using a digital otoscope and record her heart and lung sounds. The AI system then records this information, infers a probable diagnosis of influenza and sends the information to the clinician’s electronic medical records (EMR) with the Subjective Objective Assessment Plan (SOAP) note mostly filled out. Now, when the patient sees the clinician, most of the work is done and the time can be spent between the patient and clinician discussing the diagnosis and treatment plan.
2. Another busy patient is on a ranch and has developed a rash. It’s an hour drive to the nearest doctor or urgent care. So instead, the patient uses his phone and sets up a telehealth visit with a doctor right then. The doctor can review the patient’s previous history obtained from the EMR, look at an uploaded picture of the rash sent by the patient and converse with the patient over video. The document note would then be sent back to the EMR along with the rest of the patient’s record. The patient’s regular primary care provider can now access this encounter for follow up.
3. A busy doctor is seeing 30 patients a day in the clinic. Documentation and order entry is time consuming in the EMR, but this doctor uses her phone and a special app to record the patient/physician encounter and use natural language processing and machine learning to turn this recording into a SOAP note. In addition, orders for labs and x-rays are captured during the encounter and sent to the EMR along with the SOAP note.
These scenarios are not science fiction. They represent new modalities of capturing patient information outside of the typical EMR workflow – which I will call external apps for now. These modalities are working to be interoperable with the rest of the patient’s health information, which is typically stored in the EMR and claims databases. As their prevalence grows within the health IT ecosystem, it is important to understand how standards are being leveraged to integrate these applications within traditional EMRs.
Understanding the Role of Standards between EMRs and External Apps
Some data sets are easier to capture and integrate into these external apps. Here are some of the types of patient information being sent from and received by these external applications:
- Problem, procedure, medication and allergy information
- Notes, e.g., SOAP
- Lab and x-ray results and orders
HL7 V2 is often used to extract basic patient demographics and other patient administration, or ADT, type data for use in these external applications. So, for example, when the doctor walks into the patient room to record the encounter, these external apps described above have already pulled visit and demographic information from the EMR. These external apps also want to be able to book appointments and be notified of visits through the clinicians’ schedule typically maintained in the EMR. I often see proprietary EMR application program interfaces (APIs) used to handle the scheduling.
When exchanging more clinically related data, additional challenges arise in the semantic interoperability of these apps with EMRs. Structured and often codified information such as the patient’s problems, procedures, medications and allergies are shared and often have these semantic interoperability challenges. However, there are several standard terminologies that can be used for coding to mitigate these challenges. The below examples highlight the role of standards to ensure semantic interoperability.
- A telemedicine application may want to extract a patient’s drug allergies from the EMR and use it their application to alert of potential drug allergy warnings when a doctor orders a prescription for a patient during a virtual visit. In order to enable this workflow, the drug allergies need to be coded using the same proprietary terminology or appropriately mapped to each other.
- The diagnosis recorded during virtual telemedicine encounters need to be coded to help support the ability to perform orders and send the correct visit diagnosis back into the EMR.
- Lab and radiology orders often require codification to proprietary EMR-specific (and often provider-specific) order entry catalogs. Sometimes industry standard names and codes can be accepted for lab orders, but more likely used for reporting lab results.
For the free text notes generated by each of these systems, the HL7 CCD document format serves as a syntactic bridge allowing notes to be extracted from these external apps and sent to the EMR repository and well as received by these apps.
FHIR®’s Progress in Syncing These Technologies
There are several interface options when trying to sync the external app with the EMR. Where does FHIR come into play? These application vendors are beginning to use FHIR to transmit and receive information from various healthcare IT applications, such as EMRs and payer data repositories. However, FHIR still has not reached ubiquitous use across all the EMRs, so proprietary APIs are still predominantly being used to interface. Many major EMR vendors have app-type stores that these external vendors are working with to achieve interoperability. These stores may use FHIR interfaces, but proprietary EMR APIs still appear to be more prominent.
Another potential channel that external apps are interested in using are the nationwide services. Some initiatives are already aggregating patient information from the EMRs and can be a data source for these applications.
These examples of new technology and healthcare interactions are really at the tip of the iceberg – we will increasingly see all kinds of patient data being captured using novel interfaces external to the traditional EMR. As standards like FHIR mature and are increasingly adopted, hopefully we will be able to use a single interface to be interoperable with any EMR.
The views and opinions expressed in this blog or by commenters are those of the author and do not necessarily reflect the official policy or position of HIMSS or its affiliates.
DISCOVER THE POWER OF INTEROPERABILITY
HIMSS Interoperability Call to Action
Our Call to Action offers guiding principles to inform health policy and spur our nation’s health sector to action. Become a supporter
Interoperability & Health Information Exchange Committee
Help advance interoperability and standards-based health IT systems that lead to meaningful health information exchange. Join the committee
HIMSS19: CHAMPIONS OF HEALTH UNITE
300+ education sessions. 1,300+ vendors. 45,000+ health information and technology superheroes.