Jay,
If you already have an inbound HL7 interface on the MD-reports side and it simply stopped working after your cross reference file got blown away, you will need to re-create the cross reference file. You will need the unique ID values on the MD-reports side for each provider in order to do that. I'd be happy to connect offline and work you through it if that is the case. If there was never an HL7 interface between these two systems, then read on...
What you need is an inbound HL7 interface on the MD-reports side. That interface will need to process what's called ADT messages (stands for Admit-Discharge-Transfer; but it's essentially the patient demographics in Centricity). CPS 12 has an interface engine called MIK on its side that can be configured to generate these ADT messages when new patients are added or modified in Centricity. The inbound interface for MD-reports monitors a folder for these ADT messages and then processes them appropriately. You have a few options, but there are only two that I would recommend. Regardless of which is chosen, you will need to contact the MD-reports vendor to find out what options they have for processing inbound HL7 ADT messages. The ultimate recommendation would be dependent upon their response.
Option 1: Use the MIK to generate the outbound HL7 messages on the CPS side and then let MD-reports use their interface engine to process them into MD-reports.
Option 2: Use the MIK to generate the Outbound HL7 messages and use an interface engine like Mirth or Qvera to talk to the MD-reports database. You would essentially manage your own interface engine.
Option 1 is recommended if the other vendor has a decent interface engine and their cost (if any) is reasonable. ADT interfaces are the least complicated of all HL7 interfaces and I would be shocked if they didn't already have one for Centricity. Just don't be taken advantage of by the vendor. Some vendors have been known to charge several thousand dollars for the interface.
Option 2 is recommended if the vendor's interface is too costly or if you find it to be unreliable. Controlling your own interface engine is desirable when you need greater visibility of the data traffic between the two systems or when you need data transformation features above and beyond what the vendor's interface provides. Running your own interface engine opens up a lot of other opportunities for interoperability as well, but a lot of medical practices don't have anyone on staff that can configure and maintain an interface engine. I personally like option 2 when you have several systems you need to interface with and the practice prefers internal control. You can also troubleshoot and resolve problems a lot faster and avoid the issues you often run into when dealing with interfaces between two different vendors (i.e. the blame game).
Posted : April 2, 2016 5:42 pm
