Do all EPIC installations support FHIR?

[Onkara]

As I am developing a greenfield app which will consume HL7 ADT data and post HL7 OBX messages I am tempted to use SMART on FHIR, but my questions are

1. Do all EPIC installations support FHIR? I assume this is a unsafe assumption, what about other EMRs like Cerner ?
2. Are all FHIR resources supported by EPIC or other EMRs?
3. What should be my safest integration strategy? should I still use expensive interface engines ? 

Any guidance is much appreciated.

Thanks,
Onkara

[Wes Rishel]

The open source version of Mirth is used in many environments, including as a an integration module within vendor products, so I wouldn't recommend using software cost as a basis for deciding.

Epic, Cerner and Allscripts support various mixes of FHIR resources in their sandboxes. Where they support a resource they vary on whether they support creating or updating. Dan Gotlieb just put together a summary of the support of these three vendors.

If your prospect list includes hospitals that use Meditech, McKesson or other EHR vendors, or hospitals that mix and match an inpatient EHR with other ambulatory EHRs, then HL v.2 seems like your only choice.

Even if you limit your marketing targets to clients of the three EHR vendors that support it, it would be reasonable to assume that:

• The FHIR features supported in the sandbox aren't available at all client sites, according to which version of the vendors' software a given client is running. The lag time here could be as high as two years.
• If you are thinking of using FHIR to gether ADT data, then what architecture works for your software: querying for data on a specific patient vs consuming a stream of all ADT transactions? The former favors FHIR, but the latter strongly favors v.2 ADT messages.
• Individual client hospital organizations will vary in their willingness and ability to turn on FHIR support. They may have issues based on their assessment of technological resource or the ability of the IT organization to support the users of FHIR and SMART apps.

On the other hand, even though virtually all vendors support ingoing OBRs, the process of getting an interface running in production is cumbersome and requires adaptation of message details to variations among products, product releases, and even how the products are implemented at individual sites. The long term hope is that inbound streams of the equivalent FHIR resources will be less idiosyncratic, but it will be a couple of years before we know whether this hope is being realized.

Some other thoughts on this market are available at my recent blog post, Sidecar EHR Apps: SMART and FHIR Lift Vendors Over the Hump and On to New Humps. 

Regards,

Wes Rishel

Retired Healthcare Computer Nerd

____

"The older one grows, the more one likes indecency."

Virginia Woolf

____

 

--
You received this message because you are subscribed to the Google Groups "SMART on FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhir+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Wes Rishel

Retired Healthcare Computer Nerd

[Onkara]

@Wes, Thanks for a very detailed reply I appreciate your effort.

So HL7v2 being the safer choice for now it seems I can't make a SMART app HL7v2 since SMART is for FHIR standard, right?

To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhi...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Kevin Mayfield]

It seems you've already decided to using messaging and chosen the format of those messages, so I'm not sure what the use case is for FHIR (using Restful API's). Are you planning to replace the OBX messages with FHIR Observations?

I've done some work converting from HL7v2 to FHIR and vice versa. I've always used Apache Camel using HAPI HL7v2 and HAPI FHIR Libs in this area but tend to leave orchestration work (and most of the HL7v2 integrations) in the integration engine. So typical flow is

Mirth -> Integration Engine -> Mirth (for HL7v2)

Camel -> Integration Engine / BPMN Engine  (both optional) -> Camel (Mixed environments or pure FHIR) 

It sounds as though you're building a endpoint, which would be Mirth or Camel in the above. You're more likely receiving messages or sending to an integration engine.

I prefer Camel because it allows me direct access to the HAPI libs (does mirth put a javascript layer on top of these??) plus it has a lot of support for none HL7* endpoints. It also fits well with other enterprise integration components. 

[Onkara]

Hi Kevin,

As far as I know FHIR is not yet widely deployed in production and may not be for few years that is the main driving factor for us to use HL7v2. Unless this assumption is wrong?

As I am a noob to HIT, could you help me understand the role of BPMN with integration engine? my understanding was that interface engines run the interface which transforms the messages and send it to an endpoint. Was BPMN driving the flow of data between interfaces?  

Thanks,

Onkara

[Kevin Mayfield]

Re: BPMN I was illustrating how FHIR has been changing integration.

My main reasons for using FHIR was around data protection. Sending patient, encounter data to every system within the hospital leads to many copies of data which is not good for patients privacy. My app or device should only hold data for patients it is dealing with, not a local copy entire hospitals patient database. 

This starts to rule out messaging (HL7v2 ADT) as an option and being able to look up Patient data via an API is a better way forward (where we can also follow industry standards on authentication and permissions). So to find a patient you query the PAS system via an API - it just makes information governance/data protection so much easier.

You normally get several integration engines on a single HL7v2 feed. Endpoints normally using smaller engines, i.e. mirth/camel to do the transforms which work with a central engine which also does transforms but also routing and distribution.