201701 US Core Track

Return to January 2017 Proposals

US-Core Track

US Core profiles support the ONC 2015 Common Clinical Data Set (CCDS) using the Argonaut provided constraints. This track is an extension of the Argonaut efforts to test and record progress against the formal US-Core profiles.

This track is based on FHIR STU3 ballot, US-Core STU2.

Coordinated with other related Connectathon tracks

• Medication Track

Submitting WG/Project/Implementer Group

DAF Profiles Project

Justification

API access to the 2015 CCDS is required for EHR certification.

US-Core Connectathon Priority Profiles: Allergies, Patient, CareTeam, Device, Observation-Vitalsigns

US-Core formalized conformance:

• Conformance requirements for the US Requestor actor (to be updated)
• Conformance requirements for the US Responder actor (to be updated)

Background on original Argonaut use cases:

US-Core Allergies, Patient

This is a continuation of the DAF connectathons in January 2015, May 2016, and September 2016.

US-Core CareTeam, Device, Observation-Vitalsigns

Extend DAF connectathon to include retrieval of CareTeam, Device, Vital Signs for both provider and patient access. This connectathon will review consistently of CareTeam implementation.

Proposed Track Lead

Coordinator: Nagesth Bahsyam (Dragon), Brett Marquard, Eric Haas

Track Lead: Nagesth Bahsyam (Dragon)

Expected participants

Please sign up!

If you're working on a server, please complete the "servers" tab of the Signup 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 4 Spreadsheet. You'll also need to update the `status` flag to indicate whether you've begun work (or completed work).

Roles

(reproduced from Argonaut Project implementation-program Resprint)

Server/EHR

If you're working on a server, please complete the "servers" tab of the Sprints Spreadsheet (see above). 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. The preferred approach is to direct users to a web page where they can complete self-service registration. (If absolutely necessary, you can ask developers to e-mail you directly.) Work on your OAuth implementation

The expectation is that servers will follow Argonaut’s best-practice approach by implementing the OAuth2-based SMART on FHIR authorization specification. To make this more approachable for new implementers, you can think about handling security in four parts:

1. open server. Before you get OAuth working, and even once you have an OAuth-secured server, it can be helpful to host sample data at a totally unprotected https endpoint. This facilitates testing, debugging, and exploration
2. Standalone launch. Following SMART’s “standalone launch” flow means that the user (patient, or clinician) can begin by launching an app, and from there can engage in a “connect to my EHR” workflow. This approach is suitable for MU3 patient API access.
3. EHR launch. Following SMART’s “EHR launch” flow means that the user (patient, or clinician) can begin from the EHR or potal, and launch an app from there, ensuring that the app learns the context about the surrounding EHR or portal environment. This approach is suitable for embedding apps in an EHR or portal.
4. Single Sign-on. Using the OAuth2-based OpenID Connect framework for single sign-on, your authorization server can “vouch for” a user’s identity. This helps ensure that users don’t need to create a new account, with new credentials, for every app they use. This approach to SSO can be used with either of SMART’s launch flows.

Client

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

Scenarios

Dedicated Zulip chat stream for this Track.

5 Use cases:

1. Patient access
2. Allergies Access
3. CareTeam
4. Device
5. Vital-signs

1. Patient search

Action: DAF Requestor (client) searches the patient Service for patients with at least 2 patient elements - for example last name and gender GET [base]/Patient?family=[string]&gender=[code]

Precondition: Patients with the search criteria have been created

Success Criteria: patients displayed in interface. (use browser query to confirm)

To get started sample patient data for a patient is provided here and as example resource files in the TestScripts Section below. This patient is used in other example resource listed below. The use of this data is not required for successfully completing this track. Participants can use their own data.

id	name.last	name.given[1]	name.given[2]	gender	birthdate	race	ethnicity
dafpid-1001	Shaw	Amy	V.	female	2007-03-20	White	Non-Hipanic

2. Search for all Patient Allergies

Action: Client and Server support querying of:

• DAF Allergy for all of a patient's Allergies using using GET /AllergyIntolerance?patient=[id].

• DAF MedicationStatement for all of a patient's Medications: using GET /MedicationStatement?patient=[id]..

Precondition: There is a US-Core Allergy resourcesthat has been created in the system.

Success Criteria: All US-CoreAllergy resource data for a patient are displayed in an interface.

Bonus point:

• Client Server supports querying of DAF MedicationStatement based on patient.id and date period using GET [base]/MedicationStatement?patient=[id]&[eq|lt|gt|geyyyy-mm-dd{&eq|lt|gt|geyyyy-mm-dd}]
• Client Server supports querying of DAF Condition, on patient.id and category="problems" using GET /Condition?patient=[id]&category=problem.

To get started sample data for the patient listed above is provided here and as example resource files in the TestScripts Section below. The use of this data is not required for successfully completing this track. Participants can use their own data.

Conditions	Allergies	SNOMED-allergies
Hypertensive disorder	none	160244002

3. CareTeam Access

tbd

4. Device-UDI Access

tbd

5. Vital Signs Access

tbd

TestScript(s)

tbd