There has been a recent uptake of well-established tech companies as well as start-ups focusing on Healthcare technology and Healthcare Data. As these new Digital Health products flood the healthcare space, it is important to revisit the basics of integrating with EHR Systems because providers need to be able to review and track their patient data in a centralized location. Here are a few considerations that should serve as good starting points for anyone entering this space:

1.  Follow the HL7 Standards

This may be evident to most folks in the Healthcare IT field, but for those new to the industry it is imperative to ensure that the medical device data can be exported following HL7 standards. To learn more about HL7 standards please refer to the guest article here. By following HL7 standards, the process of integrating with EHR systems becomes much smoother. Although not every EHR system is the same, by following the standards, you will be able to replicate EHR integrations across the various vendors with greater ease.

2.  Decide between Unidirectional vs. Bi-directional Interface

You need to identify whether your integration will be a unidirectional interface or a bi-directional interface. A unidirectional interface is one where the medical device data is being delivered to the EHR system or, depending on the product, data from the EHR system is being delivered to your medical device. An example of this can be if a patient has an X-ray done at a Lab, and the X-ray Tech needs to send the Lab results to the patient’s physician. The X-ray Tech can send your X-ray results to the physician via a unidirectional interface and the physician’s EHR system would simply need to be able to receive that lab result and be able to attach it to the patient’s electronic chart. Unidirectional interfaces are simpler to implement because they require one system to be able to deliver the HL7 file and the other system to be able to receive and interpret the file.

In comparison, a bi-directional interface utilizes two-way communication where both systems are sending and receiving data. One setup of this could be that the medical device data is being sent to the EHR system and the EHR system is providing some data back to the medical device in response. Another way is if the EHR system sends a request to the medical device for data and the medical device provides some data back in response. Using our previous example, a bi-directional interface can be observed in lab settings where a physician will order an X-ray from the lab, and when the X-ray is completed, the X-ray technician will attach the X-ray results to that lab order and send it back to the physician. A bi-directional interface can be more complicated as it requires work from both the EHR vendor and the Medical device company. However, a bi-directional interface is more robust and can provide greater insight into the full workflow.

3.  Identify Data Type to Export

Within an HL7 standard, the medical device can be exported via discrete data points or as a PDF report generated by the medical device system. Exporting discrete data involves including specific data points within the HL7 file. Examples of discrete data points include device model, serial, battery life, heart rate, etc. These data points can be provided via OBX segments in the HL7 file. The other option is to generate a PDF report from your system and send it to the EHR via HL7 message.

A discrete data interface is expensive to implement, as the EHR vendor would need to set up a means for the device data to be populated into a form on the EHR system. It can also take quite a bit of time from your team as you will need to walk the EHR vendor through the data being provided as well as how the data should be displayed once it appears on the EHR system. The benefits of a discrete data interface are that it can allow the customer to do data analytics on the data since it now resides on their system.

In contrast, PDF integrations are much simpler and cheaper to implement. With PDF integrations, there are a few methods to set up the interface. One method is to embed the PDF message within the HL7 message. Since HL7 Standard does not allow embedding binary files, the PDF file would need to be encoded. Base 64 encoding is most common but Hex encoding can also be used. The PDF report can be sent as a single PDF report or as multiple PDF reports within the same HL7 message. The PDF file can also be sent as a separate file via an interface engine and a reference pointer provided via an MDM file. PDF integrations are often easier to implement because of as long as your HL7 file conforms to standards, the EHR vendors can easily take the message coming from your system and attach the PDF to the patient’s chart, provided the patient’s info is available in your system.

4.  Determine Matching for Patient and Provider

What data do you have on your system that the EHR system can use for patient/provider matching? Patient information will be populated in the PID segment of the HL7 message and EHR systems will use any combination of Patient Record Number (PRN), first name, last name, social security number, and date of birth to match patients coming from your system. The PRN is the most accurate way of doing patient matching but the challenge there is that the information must be available in your system to be provided. Thus, if the PRN number is not available, EHR systems will do matching on a combination of other fields that are available to ensure accuracy of matching.

The Provider information is used to fill the PV1 segment, which allows the data coming from your system to appear on the Physician or medical provider’s “desktop” as some EHR systems refer to it. This way, the medical providers will see that there is a pending report for them to review and sign. Thus, you will need to identify a way to get provider information, even if it is as simple as the National Provider Identification (NPI) number.

5.  Decide between Automatic Export vs. Manual Export

Lastly, you need to identify what function you want your system to serve once the EHR integration is complete and as such, determine if you want your EHR exports to be done manually or automatically. Manual EHR Exports are done upon action of a user, such as a lab result being sent when a user sends it. This would make sense if you believe that your system will continue to remain an integral part of the physician’s workflow after EHR integration. This is typically the case if the Physician uses your web portal for programming of the patient’s device or to make adjustments to the patient’s treatment in any way. After all changes have taken effect, the physician would manually export the data as a last step to file the data into the patient’s electronic chart and trigger the billing.

Automatic export is the exporting of medical device data to the EHR system as it becomes available and without physician intervention. This can be done for devices providing periodic data where the physician may not necessarily be making any changes or adjustments on the system and thus does not need to access it. Automatic export can save medical providers quite a bit of time in their workflows, as they no longer need to access another portal to get medical device data for a subset of their patients.

New developers in the healthcare space need to be thinking about these ideas as they are developing their products. Rather than making this the last step of the development process, developers should consider this earlier in the product development life-cycle as it can help them develop a product that is a natural extension of a provider’s workflow.

I am a Systems Engineer at St. Jude Medical, Inc. with extensive experience in integrating Telehealth products with EHR systems. My opinions do not represent the views of my employers.