There has been a recent uptake in well-established tech companies and startups alike focusing on healthcare technology and data. As these new medical products flood the healthcare space, it is important to revisit the basics of integrating with EHR Systems. I reached out to Syed Abdul Aziz to provide a simple guide for new developers in the healthcare space. Syed is a systems engineer in the medical-device industry with extensive experience in integrating medical-device data with EHR systems. Here are a few points that he laid out. They should provide a good starting point for anyone entering the field.

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 integration across the various vendors with greater ease.

2. Decide between unidirectional vs. bidirectional interfaces

You need to identify whether your integration will be a unidirectional or bidirectional interface. A unidirectional interface is one in which 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 results to the patient’s physician. The tech can send the 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 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 bidirectional interface utilizes two-way communication in which both systems are sending and receiving data. One setup 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. Using our previous example, a bidirectional interface can be observed in lab settings in which a physician will order an X-ray from the lab, and when the X-ray is completed, the X-ray tech will attach the results to that lab order and send it back to the physician. A bidirectional interface can be more complicated, as it requires work from both the EHR vendor and the medical-device company. However, a bidirectional 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 data 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 number, 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 require 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 analyze 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 the 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 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 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 that the patient’s information is available in your system).

4. Determine matching for patient and provider

What data do you have in 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 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 based 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’s 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 which function you want your system to serve once the EHR integration is complete and, as such, determine whether you want your EHR exports to be done manually or automatically.

Manual EHR exports are done upon the 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 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 when the physician may not necessarily be making any changes or adjustments on the system and 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 develop their products. Rather than making this the last step in the development process, developers should consider this earlier in the product development life cycle, as it can help them create a product that is a natural extension of a provider’s workflow.