Mirth and FHIR

[rjkroll]

After experimenting with the Mirth FHIR plugin, which is great, and setting up a FHIR Listener, along with the Mirth FHIR "database", I am beginning to get a better understanding of what Mirth and FHIR can do, but had some questions if anyone knows.

It looks like Mirth, as a RestAPI for FHIR, obviously works out of the bag. The endpoints are exposed, we can use them to Post/Get/Put, etc. I have been sending example FHIR resource messages, creating them, updating them, getting the history of the resource, getting the whole Bundle for the patient. From the looks of it, everything looks on the up-and-up.

Although the database you create for the example FHIR Listener channel only has one table, called "resource" and holds all resources in it, it seems to be working as well, including versioning. Anything I post to it is properly stored and acted upon (as defined in the capability statement)

My questions, if anyone knows are thus:

• What are the limitations of using the FHIR plugin with Mirth right now to spin up a simple FHIR server? Other then maybe allowing/disallowing, some resources and maybe operations on resources, it doesn't look like there is much to be done from a Mirth channel/interface standpoint that the plugin doesn't already handle? If I am just doing very basic things, would this plugin be "enough" and there wouldnt really be anything else needed to intense?
• The database: I know there is much debate on how you create your database, if you store resources as is, or if you use a relationional model, or if you create tables for all resources, but does anyone know if using a database with just one table "resource" like the example channel sets up would actually be feasible? I can't imagine this scaling well, but I am not sure how that works in regards to FHIR and Postgres.
• This database also seems to be storing the XML and no the JSON. Does anyone know if an implemation would be hamstrung by only storing XML and not JSON? I know it converts it back to JSON in the channel when responding, but wasn't sure if I should be looking to use something like FHIRBASE as the backend, where everything is stored in JSONB, but I know that would take some development in Mirth to probably rewrite a bunch of code.

Other then that, I know we need to use something like OAUTH or Smart on FHIR for security. Will we experience any issues using this type of security mechanism if we do not have the SSL plugin to use in Mirth? I was seeing conflicting reports on this.

Sorry for the wall of text, but just trying to wrap my head around what I would need to do to incorporate/build upon Mirth and the FHIR plugin to actually get it up and running correctly.

[narupley]

The reason why XML is stored in the database is so that we could leverage XPath queries to do some more advanced things:
destination-search-script.js#L111
Search Utility Methods.js#L56

Yep, there's absolutely nothing stopping you from using JSON instead of XML. Recent versions of PostgreSQL support the JSONB data type with JSONPath functionality too I think. You're right, using the one monolith "resource" table would probably not scale well in the long run. You could perhaps only store the most recent version of a resource in that table, and store historical versions elsewhere. Or maybe you want to use a completely normalized table structure where resources actually get split up and stored in different places, etc.

The HTTP/Web Service/FHIR listeners all support various authentication methods, including Basic, Digest, and "OAuth Token Verification", where the channel will make a GET request to the OAuth server to validate an access token. There is also the JavaScript HTTP Authentication where you can write a custom script to do whatever authentication you need. Finally there's a Custom Java Class HTTP Authentication method where you can do the same thing but in your own custom-made Java implementation instead. Basically it's just an authentication hook where you provide an instance of our Authenticator class and return an AuthenticationResult, and the sky's the limit as far as the actual authentication you want to implement.

SMART on FHIR, as far as I understand, isn't really something you "use" like Basic Auth or OAuth. It's not even an authentication protocol at all in fact, it's just a set of guidelines for how to create applications that plug into EHR systems and so on. Part of that I'm sure is authentication, but I think many of those apps end up using OAuth in some fashion.

[rjkroll]

Thank for you such a detail response! This was very helpful