FHIR Chat · Prototyping · Imaging for Consumers

So, to get concrete about prototypes... we have the latest SMART on FHIR launcher (including support for the about-to-be-published SMARTv2 spec) at https://smart.argo.run. It acts as a proxy in front of the open server hosted at https://r4.smarthealthit.org, implementing support for SMART on FHIR launch as well as token introspection. What this means is that

a client app can "register" (or not; the launcher isn't picky) and request authorization for a specific patient record
an imaging API server can receive API calls that include an access token, and can introspect this token by calling the the introspection_endpoint endpoint listed in [FHIR base]/.well-known/smart-configuration to receive a payload like:

{
    "patient": "87a339d0-8cae-418e-89c7-8651e6aab3c6",
    "token_type": "bearer",
    "scope": "launch/patient patient/ImagingStudy.rs patient/Patient.rs",
    "client_id": "smart_granular_app",
    "active": true,
    // extra properties snipped
}

This introspection payload should have all the data needed (patient, scope, active) for an imaging API server to perform authz on a request like GET /fhir/ImagingStudy?patient=X or GET /dicomweb/studies/Y.

Josh Mandel (Nov 05 2021 at 16:05):

The source for (this branch of) the SMART Launcher is at https://github.com/microsoft-healthcare-madison/smart-launcher; we've got a PR underway to incorporate the latest functionality back into https://github.com/smart-on-fhir/smart-launcher

Josh Mandel (Nov 05 2021 at 16:09):

So for a demo, I think we'd want:

An imaging server (or pair of 'em) supporting GET /fhir/ImagingStudy?patient=X and GET /dicomweb/studies/Y, enforcing authz based on token introspection
A simple web app that authorizes against the launcher and then fetches some patient demographics from the launcher's clinical data server + fetches some imaging data from the Imaging server

Chris Hafey (Nov 05 2021 at 17:43):

Now that I think of it, the fastest way to get this done is to implement a server that implements the needed FHIR and DICOMweb endpoints for some static data. Another benefit of this is that it would make it much easier for others to understand so they can implement it themselves (my ultimate goal)

Chris Hafey (Nov 05 2021 at 17:44):

that long with a simple image viewer built with cornerstone should be easy to do

Josh Mandel (Nov 05 2021 at 17:59):

Re: server implementing support for static data just to be clear, you mean a "dynamic" web server that can parse query params and authz headers (etc), but for which the "backing store" is basically a directory with a few JSON + DICOM files in it? I agree, that's a great model.

Josh Mandel (Nov 05 2021 at 18:00):

I think this could be a ~200-line Node.js app. (Then we can talk about other "persistence modules" that would allow this server to source data from a PACS or whatever. There's going to be some real value, one the very bare bones work, to showing how to connect this into real underlying imaging data sources.)

Josh Mandel (Nov 05 2021 at 18:03):

(On the real-world integration front, the hard and interesting bits are like: given a FHIR Patient id, how do I know which DICOM files "belong to" this patient? You need some mapping/matching strategy that's often institution-specific.)

Chris Hafey (Nov 05 2021 at 19:38):

yes exactly and nodejs is exactly what I was planning to do it in.

Chris Hafey (Nov 05 2021 at 19:41):

for real world integration, yes I can see this being an integration issue. Most PACS/VNA systems are synchronized with the PHR nowadays so it may not be too bad. I have not heard of many customers integrating PACS/VNA with FHIR yet though - I think it is still in early adoption phase

Chris Hafey (Nov 12 2021 at 17:02):

All - realistically I won't be able to move this forward until December due to RSNA and US Thanksgiving Holidays coming up.

Josh Mandel (Nov 12 2021 at 17:24):

Thanks for the heads up! If anyone feels the urge to start a project before then, I'd say drop a note here :-)

Josh Mandel (Jan 11 2022 at 21:30):

I've been tinkering a bit at the FHIR connecthon this week -- using Epic's support for Introspection to try things out.

Josh Mandel (Jan 12 2022 at 18:32):

https://github.com/jmandel/smart-imaging-c10n-2022-01 is what I put together as a quick demo. It works around some current limitations in the Epic introspection API, resolves the FHIR Patient full resource associated with an access token, and provides access to some canned DICOM images. The major gap right now is that Epic's authorization UX doesn't provide any way for consumers to review/approve a request that includes "Imaging Data". Just USCDI stuff.

Ryan Howells (Mar 17 2022 at 20:14):

We (@Josh Mandel @Gino Canessa and a few others) are still actively looking for folks who may want to test out this spec. If you are interested, please let us know via this thread or offline.

Josh Mandel (Mar 17 2022 at 20:16):

This thread only has a handful of subscribers -- folks who have already indicated interest. It's likely not a good place to cast a net!

Ricky Bloomfield (Mar 17 2022 at 20:16):

I've reached out to some contacts to see if I can drum up some interest!

Ryan Howells (Apr 05 2022 at 19:25):

I'm still actively looking as well. It came up today in a conversation with an app that may have some interest from a health system.

Ricky Bloomfield (Apr 05 2022 at 20:26):

I have two people who are looking into it at their respective organizations. Neither of them have said "no" yet, so that's a start!

Elliot Silver (Apr 05 2022 at 22:33):

Ping. @Jonathan Whitby @Chris Hafey @Christopher Lindop @Kinson @David Kwan @Diana_Ovelgoenne @Brian Bialecki @Chris Carr @Eric Martin @Brad Genereaux

Brad Genereaux (Apr 07 2022 at 03:58):

I'm not sure I can help with testing, but happy to ideate or talk through any issues!

Last updated: Apr 12 2022 at 19:14 UTC

Main menu