Use of SMART on FHIR for a stand alone, non-web application that wishes to PUSH resource bundles

[Brian Reinhold]

So far it seems everything I have read about SMART on FHIR concerns applications that wish to access resources on a FHIR server. The PCHA (Continua) use case is to bring medical measurements taken remotely into the EHR system. We need a standardized authenticated/authorized means of delivering a FHIR bundle to a server. We were looking to the SMART on FHIR as a means to accomplish it.

THanks

[Michele Mottini]

You could use the system described at http://docs.smarthealthit.org/authorization/backend-services/ to authenticate, and then POST the bundle to the FHIR server.

Most FHIR server at this point support only reading and not writing / modifying resources though

  - Michele

  CareEvolution Inc

[Josh Mandel]

Hi Brian,

Thanks for writing! In general, SMART on FHIR provides an app platform that lets third-party apps:

1. Get authorized to access an EHR's FHIR endpoint

2. Work with data using profiles that lock down vocabularies / data requirements

3. (optionally) integrate within the UI of the EHR

When it comes to writing data into the EHR system, it's still relatively early days. Our API supports reading as well as writing -- but most real-world vendor implementations today are focused on read. For example, Argonaut and Sync for Science are focused on reading data from the EHR. Still, we're already seeing support for some data-writing in commercial systems (e.g. Cerner's SMART on FHIR implementation allows for creation of new problems -- FHIR Condition resource -- and free-text notes). I expect we'll see increasing interest in this domain as healthcare provider begin to look for easier opportunities to integrate patient-generated health data into the clinical workflow.

I should note that, even when EHRs do not support writing data (like a FHIR bundle) directly into their operational system, SMART apps can still play an important role by integrating a *view* (UI, visualizations, etc) onto externally-stored patient-generated data. For example, you can build a SMART app that collections patient data and maintains these data in an app-specific datastore... and then integrates a view onto the app-specific store into the EHR. In the near-term, this is a pretty practical approach, and it doesn't preclude deeper integration down the line.

Best,

  Josh

On Tue, May 10, 2016 at 1:52 PM, Brian Reinhold <brianbr...@gmail.com> wrote:

So far it seems everything I have read about SMART on FHIR concerns applications that wish to access resources on a FHIR server. The PCHA (Continua) use case is to bring medical measurements taken remotely into the EHR system. We need a standardized authenticated/authorized means of delivering a FHIR bundle to a server. We were looking to the SMART on FHIR as a means to accomplish it.

THanks

--
You received this message because you are subscribed to the Google Groups "SMART on FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brian Reinhold]

Josh, 

I am not sure if this is the proper way to reply (top-posting vs bottom-posting). The main task of this application is to collect data from medical devices through transports such as Bluetooth and USB. The data is then transformed into V2.6 messages and/or FHIR bundles and sent RESTFul or via Web services to an approrpiate server. So far it has worked well with several FHIR servers at the FHIR connectathon in Montreal BUT all the transactions for FHIR were unsecure (no oAuth, no TLS). Since this data could be coming from halfway around the world we (PCHA) is looking for a standardized way of implementing the transaction authorized, authenticated, and secure and FHIR is not the only transaction option.

I will check the link provided by Michele. (Of course I assume that the FHIR server will give the app permission top write bundles and that would be implicit in the oauth token. Registration with the oAuth server is likely out of band?

[Brian Reinhold]

Michele,

As it turns out I have already read this section but it seems very web-services and read-only oriented. As a stand-alone, non web app NOT using any of the UI features of the server (FHIR docs might be queued until connectivity is established and then sent without user intervention) it is not clear to me at least how I might do that.

Brian

[Michele Mottini]

Sorry, I don't understand

A stand-alone server application without any UI should be able to create a signed JWT assertions, send it to the token end point, get back an authorization token and then use that to call the FHIR server.  There are no redirects or user interactions involved.

You can test the whole thing against our test server ( http://fhir.careevolution.com) - we do support that authentication. See  details at the bottom of http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing

At the moment being we support create/update for Encounter, Location, Patient, Practitioner and Procedure but we have Immunization, Medication, MedicationAdministration, MedicationOrder and Condition in the works and more to be started shortly.

  - Michele

  CareEvolution Inc

[Brian Reinhold]

Michele,

That sounds great. IF that is the case than I think I have everything in place. My application can do the following:

enter the url to the oAuth authorization service provider

enter the username and password for the oAuth authorization service provider ( I assume these need to be obtained out-of-band) {Assuming a bearer token}

do i need a basic authorization code in the token request?

enter the url of the FHIR service

With this information I then do the following:

1. Take a measurement with some Personal health device, say a glucometer

2. When the measurement is received a FHIR transaction bundle is created containing resources describing the Device, Patient, and Observations

3. If using secure-oauth transports, if no oauth token has been obtained, request a token from the oauth authentication service provider

4. Use the oauth token in the POST of the FHIR bundle to the FHIR service

Does this sound okay? If so it is not obvious from the description in the SMART on FHIR authorization tutorial.

Thanks

[Josh Mandel]

Thanks Brian, Michele!

I'm excited that you're delving into these specs and building solutions around them. I do want to be very clear about the state of SMART's own reference servers: we don't currently support the backend authorization protocol. We have been focused on the user-facing app authorization, and working to make sure that vendors can build consistent implementations of this protocol.

That said, we'd be happy to take feedback and suggestions on the backend protocol; I just want to make sure you're not expecting to test it against fhir-api-dstu2.smarthealthit.org :-)

Best,

Josh

[Pascal Pfiffner]

Just to have it mentoined, we're doing something similar in C3-PRO, although not currently with user-level auth but with app-level auth. For our purpose an iOS app performs a dynamic client registration, obtains an access token with its client credentials, then submits PRO and device sensor data to the FHIR endpoint. Since we encrypt the resource, it's wrapped in a simple 4-value JSON container, so strictly speaking it's not FHIR while on the wire. :)

Some more details on our website, maybe it's useful: http://c3-pro.chip.org/architecture.html

Pascal