Implementation Sprint 3

Historical purposes only -- see re-sprints for updates!

Share a patient's documents

Argonaut Implementation Sprint 3 focuses on the scenario where a user approves an app with limited permissions, scoped down to a a single patient record. The app will have access to patient demographics and any "documents" available about that patient.

##Sprint 3 Instructions

Please sign up!

If you're working on a server, please complete the "servers" tab of the Sprint 3 Spreadsheet. This time around you'll need to update the status flag to indicate whether you've begun work (or completed work), so clients will know when to start testing. You'll also share details about how a developer can obtain OAuth client credentials (client_id for public apps, or a client_id and client_secret for confidential apps) as well as user login credentials. You might consider simply sharing a set of fixed credentials in this spreadsheet, or else directing users to a web page where they can complete self-service registration. If absolutely necessary, you can ask developers to e-mail you directly.

If you're working on a client, please complete the "clients" tab of the Sprint 3 Spreadsheet. You'll also need to update the status flag to indicate whether you've begun work (or completed work).

Overview: FHIR API Calls

GET /Patient/{id} Retrieve a patient's basic demographics and identifiers, given a unique patient id.

GET /Patient/{id}/DocumentReference?type={}&created={} Search for available documents about a patient, given a unique patient id. Optional search parameters can filter results on:

• type a code describing this document (see below for details)
• created creation date

Notes

Argonaut Document Access provides background on how the DocumentReference endpoint works — but note this guide is a work in progress, and our first sprint starts with just a subset of functionality.

The Argonaut Implementation Program now uses FHIR DSTU2.

Overview: Authorization

This sprint builds on our introduction to the SMART on FHIR OAuth 2.0 authorization process. Recall that in Sprint 2, we authorized access at a very coarse level, delegating all of a user's read privileges to an app. This time, we add support for apps that don't need access to an entire population of patient records, but instead require just one record. We accomplish this through a set of "launch scopes". In terms of SMART's authorization guide, we'll make the following assumptions:

1. Standalone launch sequence only
2. Public clients and confidential clients are both supported
3. Access scopes include:

• launch/patient (indicates to the EHR that a single patient must be selected to complete the launch process)
• patient/*.read (to ensure a patient-specific access token)

4. Onecontext parameter is returned to the app upon successful authorization:

• patient (indicates the patient currently open in the EHR)

5. No single-sign-on (OpenID Connect) is required

Details

DocumentReference.type

For the DocumentReference search API, each document should have a type explaining what kind of document it is — e.g. Clinical Summary, Discharge Summary, or Imaging Report. When exposing C-CDA documents, this type code should be populated from the CDA document.code, meaning:

Document type	Code	System
Care Plan	56447-6	http://loinc.org
Consultation Note	11488-4	http://loinc.org
Continuity of Care Document	34133-9	http://loinc.org
Diagnostic Imaging Report	18748-4	http://loinc.org
Discharge Summary Note	18842-5	http://loinc.org
History and Physical	34117-2	http://loinc.org
Operative Note	11504-8	http://loinc.org
Procedure Note	28570-0	http://loinc.org
Progress Note	11506-3	http://loinc.org
Referral Note	57133-1	http://loinc.org
Transfer Summary	18761-7	http://loinc.org

This means that a client can search for summary notes via:

GET /Patient/{id}/DocumentReference?type=http://loinc.org|34133-9

DocumentReference.format

Each DocumentReference also defines a format value that can provide specific details about the format of the document — over and above the content's MIME type. The community is still figuring out best practices for format values, but a list of recommended codes is provided here. At the very least, C-CDA documents should have a format value of urn:hl7-org:sdwg:ccda-structuredBody:1.1.