Financial Data

Financial Data

The API calls below show how to use S4S for sharing Financial Data. The Financial Data Use Case is aligned with FHIR STU3.

The examples below refer to the following variables:

• patientId indicates the FHIR id of the Patient in context. For example, 123.

• lastCheck indiclates a FHIR instant, with millisecond-level precision including a timezone. For example, 2016-04-01T02:52:32.000Z

We’ll also refer to two “request times”:

• first-connection for broad queries that the app will make once, after first approval, to back-fill historical data
• periodic-update for narrow queries the app will make frequently (e.g. weekly)

(Note: a production-quality app might repeat the “broad” queries on an occasional basis — e.g. yearly — as a sanity check, and to discovery any data that may have fallen out of the record.)

Want to propose a change? edit this page!

Authorization expectations: SMART on FHIR OAuth2

Sync for Science^TM (like Argonaut) uses the OAuth2-based SMART on FHIR authorization specification. But we don’t need all the moving parts. In particular, in Sync for Science we can get away with a minimum of:

1. “confidential clients”, meaning that apps get assigned a client_id and client_secret to authenticate to EHRs.The general SMART and Argonaut specs also require support for “public clients”, but it’s not strictly a requirement in S4S.

2. “standalone launch” flow, meaning that the patient (research participant) can begin by interacting with the PMI app, and from there, can launch into an “connect to my EHR” workflow. The general SMART and Argonaut specs also require support for the “EHR launch flow” (where apps launch from an EHR or portal), but it’s not strictly a requirement in S4S.

3. patient/*.read launch/patient offline_access scopes, meaning that when the app launches, it will ask the EHR for permission to read all data available to the patient, and it will ask to learn the FHIR id of the patient whose records are shared.

We also do not require support for Single Sign-on via OpenID Connect in S4S (though again, it’s part of SMART and Argonaut, and we encourage implementers to support it).

Server metadata

Return a FHIR capability statement with SMART extensions for OAuth

GET /metadata

Patient demographics

Includes: name, birth sex, birthdate, race, ethnicty, preferred language

On first-connection, periodic-update.

GET /Patient/{{patientId}}

Request

GET /api/open-fhir/Patient/smart-1288992 HTTP/1.1
Host: portal-stu3.demo.syncfor.science
Accept: application/json+fhir

Response

Coverage

Includes: details about a patient’s insurance coverage (TODO: include details from BB on FHIR profiles)

On first-connection

GET /Coverage?beneficiary={{patientId}}

Request

GET /api/open-fhir/Coverage?beneficiary=smart-1288992 HTTP/1.1
Host: portal-stu3.demo.syncfor.science
Accept: application/json+fhir

Response

On periodic-update

GET /Coverage?beneficiary={{patientId}}&_lastUpdated=gt{{lastCheck}}

Request

GET /api/open-fhir/Coverage?beneficiary=smart-1288992&_lastUpdated=gt2016-04-16 HTTP/1.1
Host: portal-stu3.demo.syncfor.science
Accept: application/json+fhir

Response

Explanation Of Benefit

Includes: details about benefits that a patient has received through their insurance coverage (TODO: include details from BB on FHIR profiles).

On first-connection

GET /ExplanationOfBenefit?patient={{patientId}}

Request

GET /api/open-fhir/ExplanationOfBenefit?patient=smart-1288992 HTTP/1.1
Host: portal-stu3.demo.syncfor.science
Accept: application/json+fhir

Response

On periodic-update

GET /ExplanationOfBenefit?patient={{patientId}}&_lastUpdated=gt{{lastCheck}}

Request

GET /api/open-fhir/ExplanationOfBenefit?patient=smart-1288992&_lastUpdated=gt2016-04-16 HTTP/1.1
Host: portal-stu3.demo.syncfor.science
Accept: application/json+fhir

Response