Updated: FHIR: Request for Feedback

[narupley]

UPDATE 2021-10-25: We have now moved our FHIR Connector extension from a free download to our commercial offerings. This was a free-to-download pilot project for 3+ years. The latest version of the FHIR extension is available to customers on our Gold/Advanced support tiers, please contact us at [email protected] if you're interested!

https://www.nextgen.com/products-and-services/integration-engine

The current FHIR Connector extension includes the following features:

• Support for R5 (Preview #1), R4, STU 3, DSTU 2.1, DSTU 2
• FHIR Data Type (seamless conversion between XML and JSON resources)
• FHIR Listener source connector
  • Your own custom FHIR server, tweak the capability statement as you need it
  • Automatically serves up capability statement
  • Automatically serves up HTML web UI for browsing capability statement and other resources
• FHIR Sender destination connector
  • Connect to any FHIR-capable server
  • Automatically populates available interactions/operations based on the server's capability statement
• FHIR Model Builder transformer step
  • A drag-and-drop UI for any FHIR resource / data type
  • Convert your data (e.g. from HL7 v2.x) to FHIR
• FHIR Model Builder code template type
  • Same as the transformer step, but in code template form, can share between channels
• FhirUtil utility class available in JavaScript for various useful methods

We also have some example channels / code templates / transformers for the FHIR extension up on our GitHub: https://github.com/nextgenhealthcare...ample-channels

Example of the FHIR resource builder UI:



Original Post:

In case you didn't know, we currently have a FHIR Technology Preview that you can download and try out for free. It includes a source connector (FHIR Listener) that acts as a FHIR server. It handles the Capability Statement automatically, and will parse incoming requests to supply useful information in the source map. It also stands up a configurable website for displaying resources and other information, and includes some other helper/utility classes to help streamline your implementation.



We're working on updates to this, and would like some feedback from the community! Help us out by answering any of the following questions, or feel free to give general feedback or feature requests.

How many of you are using FHIR, either with or without Mirth Connect? If you're not using it, are you planning to?

What are you using it (or are wanting to use it) for? Any specific use-cases you can share?

For those of you using the FHIR Technology Preview, what is your honest feedback? What are we doing right, and what can we improve upon? Any specific gotchas or pain points we can iron out?

Among other things, here are some general updates/improvements under consideration:

• Support for STU3 (R3)
• Add a destination (FHIR Sender) connector
  • Similar to the Web Service Sender, this should have the ability to download capabilities from the server and display supported resources/interactions in drop-down menus
• Add a graphical UI builder for FHIR resources
• Add a dedicated FHIR data type that supports both XML and JSON
• More documentation and examples!

Thank you in advance!

[craig.burdulis]

We definitely want STU3 support at our organization. Also, the documentation for configuring the FHIR Listener could be improved with more examples/details that would help those not too familiar with FHIR but very familiar with MC.

[narupley]

We definitely want STU3 support at our organization. Also, the documentation for configuring the FHIR Listener could be improved with more examples/details that would help those not too familiar with FHIR but very familiar with MC.

Thanks, I've added that to the list! Are you currently using the technology preview?

[[email protected]]

Nick,

We are not currently using the technology preview. We do have FHIR square in our sites for projects that are slowly coming together.

I would be looking to use it in Mirth Connect. I think having the Destination (FHIR Sender) would make a lot of sense as it seems that brokering these types of connections may become more and more normal in the flow.

I typically prefer to code things using Javascript, even when there is a alternate GUI method of doing so. That just seems to be my preference for filters, transformers. I could see have the FHIR Listener and the FHIR Sender connectors in place, but everything in between being Javascript.

With regards to STU3, and other versions, it will be interesting to see what initial version really gains the traction based on the projects I get involved with. That will probably dictate where we start, not necessarily where we end.

Is this connector being designed for the appliance only? Will it ultimately be part of Mirth Connect?

Cheers.
Chuck.

[casest]

FHIR is on our radar and we are researching options, but there are no current projects underway.

Stephen

[narupley]

Is this connector being designed for the appliance only? Will it ultimately be part of Mirth Connect?

It won't be for the appliance only, it'll be a separate extension that will be able to be used with standalone Mirth Connect instances as well!

[polsonmrhc]

We're not using FHIR now. No vendors we communicate with require it and our main EHR vendor doesn't have the capability yet. We will perhaps use FHIR once the federal TEFCA initiative kicks in, but that will depend upon the connection requirements the QHIN decides upon. Right now, our HIE is pushing for HL7 v2 for provider to QHIN communications, and FHIR between QHINs as per the USCDI. By the time all of it is implemented, I expect to have forgotten just about everything I learned in HL7 FHIR class from a year-and-a-half ago.https://www.mirthcorp.com/community/...ilies/wink.gif I wanted to begin working with the FHIR connector at the time I took the class, but we're not up on the latest version of Mirth Connect and would have to upgrade our server first.

[kirbykn2]

We are using FHIR in our DEV environment. Before we commit any additional resources/time the update to STU3 is necessary.

An example of how to implement the FHIR connector with a Microsoft SQL DB would be helpful. Also a way to ease the mapping from FHIR to a database. If you could configure your db schema in Mirth to the FHIR structure and then Mirth could prepare the appropriate calls to retrieve the data, that would be great. Much like the way me map HL7 messages in Mirth, we could import the db schema, and map the FHIR element to where it lives in our db.

Built in functionality to map from FHIR to CDA.

The webpage and conformance report is good feature. Being able to add/edit the content displayed here in the channel may be helpful. Also would this be the appropriate place to display the implementation guide or a link to it?

A dedicated location on the forum for FHIR specific questions may be helpful.

[mikko]

No projects in our organization that requires us to use FHIR. But it's definitely in my radar for future projects. Still exploring how it works though. And btw, great update!

[narupley]

The webpage and conformance report is good feature. Being able to add/edit the content displayed here in the channel may be helpful. Also would this be the appropriate place to display the implementation guide or a link to it?

If you look in "extensions/fhir" in your installation directory (should be accessible via Appliance control panel too), there are a few things you can edit.

First are the files in public_html. These are HTML templates used for the overall look-and-feel of your webpage (template.html), as well as specific pages for loading the landing page and resources.

Then resource-specific template pages are in the narratives directory. There are two that ship with the technology preview by default, for Conformance and OperationOutcome (essentially your "error" page). You can add your own templates and provide links to them in narratives.properties. For example you'll see that for OperationOutcome there are the following lines:

operationoutcome.class=ca.uhn.fhir.model.dstu.resource.OperationOutcome
operationoutcome.narrative=file:extensions/fhir/narratives/OperationOutcome.html

There's a small blurb on this in the documentation, but we'll be sure to add more examples too.

Hope that helps!

[JoshMc]

I would say support for newer versions of the standard would be helpful along with updated versions of HAPI FHIR API. I think those two kinda go together. That said, I've had some reasonable success using a standard HTTP Sender with stand-alone HAPI FHIR Libraries to build and parse FHIR resources.

A FHIR Sender Destination Connector Could be quite helpful when using Mirth Connect as a proxy.

[siddharth]

My use case

My Client is using FHIR as a data model for their API, for the most part.

Mirth is a default consumer of them web-services. Now, (almost all) customers use HL7 as a medium for data exchange and not FHIR at the moment, so Mirth acts as a broker between the application API and customers, takes the incoming HL7 and converts into FHIR format and sends to the API.

Same thing in reverse as well, so Mirth takes information from the APIs in FHIR format and constructs an HL7 Results or MDM message. So its inbound and outbound both.

We have not evaluated this FHIR Listener that Mirth has to offer, because it did not fit our use case.

However, as an addition I would say what Mirth can do is, provide FHIR parsers that can readily convert from HL7 data type (say 'XPN') to FHIR data type( HumanName). What I think HL7 to FHIR, and FHIR to HL7 is what many customers will demand.

[StefanScholte]

Hi naruply,

As of this moment we are not using FHIR in our Organization yet.
However In the Netherlands many FHIR resources are being made and standarized
https://simplifier.net/NictizSTU3/~introduction. so support for STU3 is very welcome.

As a proof of concept we made a FHIR connector for retrieving Patient information.
what we did is retrieving patient information from the database and building a FHIR message from scratch.

[mdehoog]

First FHIR development

We will start our first FHIR development shortly.
Working with a hospital, we will implement a FHIR client to retrieve patient data and appointments. We will for now just use the standard HTTP Sender to do this.

Would love to have the improvements mentioned:

• Support for STU3 (R3)
• FHIR Sender connector
• Graphical UI builder for FHIR resources (WHOOW. Would be great. Any previews available yet???)
• dedicated FHIR data type with Message Template Tree descriptions

[narupley]

We'll likely demo some of our work-in-progress on the Developer Q&A next week...