Fhir JS App Integration Problems

[Radu Craioveanu]

Fhir JS App Integration Problems

 

Summary:

Attempts to use Fhir data directly with JS client based apps has led to integration problems. JS libraries like Angular, JQuery Datatables, ReactJS rely on simple flat arrays of JS objects to render the UI. Fhir data tended to be verbose, required post processing in JS to convert, and referenced JS objects in an array by a reference number system which was incompatible with JS UI libraries.

 

 

Problems Encountered:

 

·      Large Fhir payload was difficult to reduce to a minimal JSON format suitable for Angular

·      SMART library was unable to work with the complete REST methods we used: POST, GET, DELETE, PUT using JS web tokens and additional header data we needed to send.

·      Fhir data referenced by reference number in arrays had to be post processed in JS to a flat JSON format so it could be consumed by Angular.

·      Creating converters from Fhir to flat JSON is time consuming and increased processing time in JS apps leading to poor performance.

 

 

Example JSON minimal flat format needed for Angular/JQuery Datatables/ReactJS:

[

{id:123,dateTime:’10-12-2016’,status:’added’},

{id:125,dateTime:’10-12-2016’,status:’removed’}

]

 

 

Example of converter needed to format Fhir data into simple flat JSON data:

We ended up using Lodash to post process Fhir data but it creates a brittle app and converters had to search through Fhir data to transform it into simple JSON.

 

var x =  _.find(x.resource.contained, function(o) {

                if (o != undefined ) {

                    return o;

                } else {

                    return null;

                }

            });

[mark....@juxly.com]

We have an entire app built using AngularJS that hits every exposed endpoint with the exception of DocumentReference.Create. We do no server side parsing of data returned from Cerner. All things considered, it's a very easy api to work with.

For starters, try using this library to get data from Cerner:

https://github.com/smart-on-fhir/client-js

The code below is our primary function to get data from the api.  The `fhirResource` variable represents the root endpoint, something like Condition or AllergyIntolerance. `jxResource` is the name of our internal model that we'll map it to and `resFunction` does the mapping. It works beautifully.

function getFhirData(fhirResource, jxResource, resFunction) {
    // Use the smart library to make an api search on the patient for a specific fire resource.
    // log Items, and then run the handed in resFunction (response function);
    return service.smart.patient.api.search({type: fhirResource}).then(function(response){
        return resFunction(response);
    },function(error){
        error.name = jxResource;
        return error;
    });
}

While I agree that the data model could be improved, this is a FHIR thing and not based on Cerner's implementation. And really, for healthcare, it's awesome. It's way better than parsing "standard" HL7 messages or (gasp) pulling text files off remote servers with FTP and parsing based on spaces and line endings - all of which is standard practice in healthcare tech. It's a huge step forward for the industry. 

These are not social media apps. The data is complex by it's very nature and is used to make life and death decisions. Clarity and completeness should be the design goal. Simplicity is less valuable in this context.