Integrating Remote Vitals into an EHR via HL7

[user-don]

Hi everyone,

I work for a 3rd party vendor that collects remote vitals from patients (not a hospital, and don't have an EHR). We wish to integrate with EHRs (pushing vitals) for large health systems, and have been told that our best path forward is to develop a set of HL7v2 messages and associated API documentation.

I have also been recommended to use Mirth as a testing environment to ensure our code is written correctly, as it is similar in nature to the "integration engines" that most major hospital chains use.

Basically, the diagram is [our_backend_sending_HL7v2_messages] --> [hospital's_integration_engine] --> [hospital's_EHR]

Is that a fair assessment of how most third parties integrate with EHRs? Is there anything I'm missing?

Thanks, and let me know if this is not the appropriate forum for this sort of question.

[pacmano1]

There are many scenarios, e.g. below. Good thing is you really don't need to care about any of it from a topology perspective (yet).

• your engine -> their engine -> their EHR
• your ending -> hospital's engine -> EHR's engine -> EHR
• your engine -> their EHR
• your eingine -> their integraiton hub/router that may connect to downstream integration engines -> their EHRs at their clients
• there are more!

Since I work specifically in this space - what you will need to worry about is the EHR's standards for consuming your vitals data - that is wildly variable. In general you will need to abide but their specifications, not develop your own. You can't just write something and say "here is my spec, abide by it".

In my opinion, you and your team need to assess your target market (i.e. weigted by potential revenue) and create intefaces as per that EHR's requirements.

You can of course consider aggregators like Redox, Sansoro/Datica (whatever they are called) and see if they have a more generic API to code to - trade of is always cost in that model.

[user-don]

Thank you so much @pacmano1. So for a large hospital chain, they wouldn't typically ask us for our HL7 documentation in the case where they have an integration hub? Instead, they would provide specifications, and expect us to develop against them?

Really good to know the other scenarios I hadn't considered; integrating straight into the EHR from our engine would be markedly different in terms of approach.

[pacmano1]

No, Direct to the EMR just means there might not be an interface engine. It does not change the protocols in use such as HL7.

You might encounter HL7, API, FHIR, SOAP, CDA, CSV, and other technologies when it comes to healthcare integration in general, let alone vitals sharing.

[pacmano1]

Don't focus on the presence of an integration engine. It is irrelevant in this context. What is relevant is the specifications to which you need to conform.

There also may be situations where you are asked for your specification(s) also. It just depends on the other side.