FHIR Chat · JS FHIR Client

Hi All - I'm starting a new project that has a need to talk to various different FHIR resources, from a couple of different FHIR servers. I have had a look at the FHIR javascript clients that I have found, but so far nothing is jumping out as truely awesome. FHIR.js seems the best that I have come across so far, however it was last updated 7 months ago. It also has some fixed requirements around implementation. i.e. the adapter concept.

Grahame Grieve (Mar 30 2016 at 06:57):

what is it you want from a JS client?

Cole Diffin (Mar 30 2016 at 06:59):

In an Ideal world, something that uses fetch, and Promises out of the box, and then expects polyfills for older browsers.

Cole Diffin (Mar 30 2016 at 06:59):

I could bake an adapter that enables this for FHIR.js - but wondering if there are other things out there

Mario Hyland (Mar 30 2016 at 08:52):

Not sure if this help, but throwing it out there - have you visited AEGIS WildFHIR Clients/Server demo systems? They are intended as an RI (Reference Implementation) for others to bang against.
AEGIS WildFHIR v0.9 – Supporting FHIR DSTU 2.0
Client UI  http://wildfhir.aegis.net/dstu2gui
Server Base URL  http://wildfhir.aegis.net/dstu2

AEGIS WildFHIR v1.0 – Supporting FHIR DSTU 2.1
Client UI  http://wildfhir.aegis.net/fhirgui
Server Base URL  http://wildfhir.aegis.net/fhir

Josh Mandel (Mar 30 2016 at 13:28):

We need to touch up FHIR.js. @nicola are you around here? We have a pull request at https://github.com/FHIR/fhir.js/pull/50 that it would be great if you could take a look at.

Assuming we get tha tworked out, I think we should write the fetch + promises adapter for FHIR.js, at any rate. Should be a small addition.

Josh Mandel (Mar 30 2016 at 13:28):

For what it's worth, we've been using FHIR.js as the core of SMART's JS client for a while now, and it's been working well.

nicola (RIO/SS) (Mar 30 2016 at 17:43):

Hi, I'll take a look

nicola (RIO/SS) (Mar 30 2016 at 18:28):

Merged & migrated to mocha (jasmine is awful :)

Cole Diffin (Mar 30 2016 at 19:26):

@Mario Hyland I havnt seen the AEGIS Clients - i'll take a look thanks.

Cole Diffin (Mar 30 2016 at 19:29):

I have been messing with FHIR.js last night. It seems that I can hook up fetch and native promise via an adapter. I'll continue playing and see where i get.

Cole Diffin (Mar 30 2016 at 19:30):

I've also noticed the docs are incorrect. Adapter need to provide a defer which is not documented. I might submit a PR once i know whats suposed to be there.

nicola (RIO/SS) (Mar 30 2016 at 19:30):

Nice! You are welcome!

Cole Diffin (Mar 31 2016 at 00:27):

In FHIR.js - the 'adapter' needs a defer object. (The one that has no documentation)

Regardless of what I provide it I'm receiving "Error loading data from the source: Error: I need adapter.defer". Any quickl ideas, or should I direct this question to github's issue queue.

Josh Mandel (Mar 31 2016 at 03:09):

For example see https://github.com/FHIR/fhir.js/blob/master/src/adapters/node.js - your adapter needs a "defer" and an "http".

Cole Diffin (Mar 31 2016 at 03:48):

Thanks Josh, Figured it out a bit further by copying the jQuery example and seeing that in action. The adapter is responsible for parsing the object as well..... and the search method actually returns a promise, instead of calling a callback as the docs indicate.

Cole Diffin (Apr 03 2016 at 21:05):

Hi All, Is there any existing plans to work on the current documentation for fhir.js?

David Teirney (Apr 03 2016 at 21:11):

Who within the FHIR community is actively involved in looking after FHIR.js? For example, who would pick up and triage or prioritise work on any of the issues raised within Github? https://github.com/FHIR/fhir.js/issues

Josh Mandel (Apr 03 2016 at 22:50):

@nicola @Nikolai Schwertner and I have worked on this together.

Josh Mandel (Apr 03 2016 at 22:51):

Definitely would like to keep this up to date. @Cole Diffin and @David Teirney

Josh Mandel (Apr 03 2016 at 22:52):

Also worth pointing out that we have SMART-specific documentation that demonstrates how to several FHIR.js features including search, etc at http://docs.smarthealthit.org/clients/javascript/

Cole Diffin (Apr 03 2016 at 23:13):

@Josh Mandel The Docs on the Smart site a re a bit better - but its not really clear enough for new commers that they are interchangeable.

Josh Mandel (Apr 03 2016 at 23:13):

Oh, agreed -- we clearly have a lot to do here. We basically got this in just enough shape to pretty much work, several months ago.

Josh Mandel (Apr 03 2016 at 23:14):

Would love help fleshing these out, and I'd be happy to explain the parts that I understand/recall :-)

Cole Diffin (Apr 03 2016 at 23:15):

Sounds like a way forward. I'm just finishing off an evaluaiton between a roll your own client and FHIR.js. I would like to have had more options - but sseems there isnt. :-)

Josh Mandel (Apr 03 2016 at 23:15):

Yes -- the risk with FHIR.js is that its level of abstraction is *so high*. Wrapping it up in particular combinations (as we do for SMART) makes it more usable.

Josh Mandel (Apr 03 2016 at 23:16):

Do keep in mind if you're going to roll your own that there are a bunch of details to get right (things like reference resolution). Might be worth looking at the FHIR.js tests in any case to have a sense of these.

Cole Diffin (Apr 03 2016 at 23:16):

I'm not keen on rolling my own.

Cole Diffin (Apr 03 2016 at 23:17):

The decision is not only mine to make though.

Cole Diffin (Apr 03 2016 at 23:20):

On a side note, I dont know much/anything about the smart on fhir library yet. (Although breif looks it does look interesting) Do you know if there is anything that abstracts further that FHIR.js to a point wher eyou can call a funciton to retreive data, and have is sensibly returned.

It's hard to explain what im thinking. Something like the following

resource.getConsultant('primary').getFullName()

Cole Diffin (Apr 03 2016 at 23:20):

Although - with the current flexibility in the spec, this would probably be very difficult to get right

Josh Mandel (Apr 03 2016 at 23:20):

We have a few things like this -- e.g. helpers to resolve medications (from medicationCodeableConcept or medicationReference, in a MedicationOrder), but it's pretty ad-hoc.