3 areas which can cause your interface project to fall out of range
Except for Registration (ADT in HL7 vernacular) interfaces, Result (ORM) interfaces are the next most commonly implemented interface making them old hat to many. However adding connections to additional labs, system upgrades, and initial rollouts for those not yet connected continue to make result interfaces one of the more common add-on projects associated with electronic health records. Throw in vendor nuances, increasing use of extra connection points through additional interface engines/hubs/HIEs, and individual EHR capabilities/limitations and a new result interface implementation project can get complex quickly despite their prevalence. Here are just a few common areas which can broadly impact a results interface implementation and that interface’s ongoing maintenance.
The flip side to the result coin is ordering and generally speaking where there is a result interface there is very often an order interface. However, this is not always the case. Due to limitations on either the EHR or lab vendor side an order interface may not be possible or it may just be slated for a later phase of either side’s project. In any case, there are special considerations that need to be taken into account when there is not an electronic order interface accompanying a result interface. These primarily come down to what the lab vendor is able/willing to key into their system and send back on the result interface. Without the ability to receive certain identifiers back in result messages (i.e. Patient Number/MRN, Test Codes, Requisition or Accession Numbers) matching the results to the original orders or patients may be difficult or impossible and could impact whether orders are even able to be placed electronically in the first place. Understanding what your lab vendor will be able to send back to you in result messages will greatly impact the nature and scope of the project.
2. Routing & Carbon Copy
How will the lab vendor and/or any systems between they and you determine what results should be sent to your system(s)? Will you have the option of receiving labs? Not just those that your providers ordered but also those they’ve been CC’d on, and how can your system best handle these? They are important things to outline at the beginning of a result interface project due to the sweeping configuration and workflow considerations. Whether routing is performed at a site or provider level can have implications for providers that practice at multiple sites. If receiving carbon copied results, you will need to determine how your system can/should handle how these results get filed into the system. Decision points, such as whether the results should file under the original ordering provider’s name or your provider’s name who has been cc’d, may have an impact on result verification workflows as well as who and how you build users in your system.
3. Multiple Lab Vendors
Until such time comes that LOINC, or some other common standard, is used by lab vendors to identify orders and results, managing multiple sets of test codes will always be a major concern if interfacing with more than one lab. How this is handled will vary widely depending on the EHR system you are on, but can become extremely complex, especially if any protocol of overlaying or ‘syncing’ labs is employed, as is common in some products. Ensuring that the right codes go to the right labs in order to improve accuracy and reduce follow-up calls, billing implications, and the user experience of order labs, all have to be taken into account when determining a strategy for the management of multiple code sets.