-
Notifications
You must be signed in to change notification settings - Fork 5
Implementation Sprint 3
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).
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
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.
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:
- Standalone launch sequence only
- Public clients and confidential clients are both supported
- 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)
- Onecontext parameter is returned to the app upon successful authorization:
-
patient
(indicates the patient currently open in the EHR)
- No single-sign-on (OpenID Connect) is required
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
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
.
Re-Sprint Details
Re-Sprint 1
Re-Sprint 2
Re-Sprint 3
Re-Sprint 4 (TBD)
Re-Sprint 5 (TBD)
Re-Sprint 6 (TBD)