Stream: javascript
Topic: fhir.js still maintained?
David Winters (Feb 21 2022 at 14:48):
Is fhir.js still maintained? It is woefully out of date and is a dependency for client.js.
Josh Mandel (Feb 21 2022 at 15:02):
https://github.com/smart-on-fhir/client-js has been more of a focus for the SMART team, but hasn't seen a lot of features (or requests) over the past year, aside from work on supporting SMARTv2. I don't think fhir.js should be a technical dependency if you're using the current client-js version -- see http://docs.smarthealthit.org/client-js/v2.html docs
Josh Mandel (Feb 21 2022 at 15:02):
http://docs.smarthealthit.org/client-js/#fhirjs-integration specifically
David Winters (Feb 21 2022 at 18:00):
It does show up as a dev dependency: https://github.com/smart-on-fhir/client-js/blob/master/package.json#L51
Is it still used at all or could it be removed?
Vladimir Ignatov (Feb 21 2022 at 18:24):
As a dev dependency it is not required and not included in your builds, unless you import it manually somewhere. It is only included there for testing...
Client-js does not need Fhir.js but is able to integrate with it at runtime:
- In browsers, if fhir.js is included via script tag and globally available, then the client objects created by client-js will have some additional functionality
- In node, the same thing will happen if fhir-js is imported and put into the global namespace
Older versions of client-js did depend on fhir.js but that was very difficult to maintain. That is why it is now "optional", for those who want to use it, and may even be completely removed in future versions if people are not interested in using it.
Angelo Miguel Ferreira (Mar 25 2022 at 09:15):
Hello everyone!
I came accross this question and I believe there is no need to create a new thread, since the topic is similar.
@Josh Mandel so I understand that the SMART on FHIR JS Library was initially written by you but then at a certain stage it has been maintained by SMART, which hasn't been changing it much, am I right in stating this?
I was looking though for some guidance, not sure if this is the correct place, but I'll expose my doubt nevertheless.
I maintain a SMART on FHIR app that performs the OAuth2 handshake using the SMART on FHIR JS Library.
A client of mine works with EPIC and they just got a quarterly update that broke the connectivity between my app and their EHR system. When they questioned EPIC about the broken connectivity with one their partners (us) they got this back:
"To match HL7 FHIR specifications, the OAuth2.0 token endpoint (for example, https://<Interconnect Server URL>/oauth2/token) returns a token type value of “Bearer” instead of "bearer." If your app-orchard application is designed to receive case-specific “bearer," authentication will fail. We need to verify that a token type value of “Bearer” does not interrupt the authentication process."
The error following the attempted handshake is: Error: invalid_grant: Invalid launch token
Have you come accross this before with other vendors? Does it ring any bell at all?
I have searched fhir-client.js for matches of 'bearer', 'Bearer', etc. but haven't found anything that seemed to be what we I was looking for.
Any tips, guidance, comments, etc. would be useful!
Thanks in advance!
Josh Mandel (Mar 25 2022 at 13:17):
Can you clarify what library are you are using and your software, at what version? This thread was originally about a library called FHIR.js, which is not actively maintained to my knowledge. But smart still maintains a JavaScript client library at http://docs.smarthealthit.org/client-js/
Josh Mandel (Mar 25 2022 at 13:19):
In any case, none of these tools should care much about the capitalization of the word "Bearer" in the access taken response JSON payload, but It's possible there is a bug. It would be helpful to know what you were using.
Angelo Miguel Ferreira (Mar 25 2022 at 18:37):
Thank you @Josh Mandel for your comment.
The system uses that exact library to perform the connection to the EHR system - http://docs.smarthealthit.org/client-js/
Its usage on the system I am currently maintaining was not coded by myself and I have been trying to figure out how is it being used, but it has been a painful process due to the lack of documentation. Without understanding it it's difficult to debug and spot where issues are actually happening.
The system is launched using the EHR Launch flow, meaning that the ISS parameter - their FHIR server - is passed by our client.
Is there any kind of workflow that describes what happens when FHIR.oauth2.authorize is executed?
There is this, but it isn't helping much - http://docs.smarthealthit.org/client-js/api.html
I have found out this, from cerner, and I could infer from what happens on the code that the FHIR.oauth2.authorize goes through all the authentication process until getting the actual access token that can be further used to query the FHIR server for clinical data, but it's a shame that all of that happens in a blackbox.
Based on this, do you have anything you think could provide some guidance?
Josh Mandel (Mar 25 2022 at 19:06):
Do you have suggestions for a different API design that would be more useful? For near term debugging, are you seeing errors connecting to the Epic sandbox, or only at certain customer endpoints? Being able to reproduce any errors would be very helpful.
Last updated: Apr 12 2022 at 19:14 UTC
