This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201701 US Core Track"

From HL7Wiki
Jump to navigation Jump to search
 
(16 intermediate revisions by the same user not shown)
Line 2: Line 2:
 
[[Category:201701_FHIR_Connectathon_Track_Proposals|January 2017 Proposals]]
 
[[Category:201701_FHIR_Connectathon_Track_Proposals|January 2017 Proposals]]
 
__NOTOC__
 
__NOTOC__
 +
== '''[http://wiki.hl7.org/images/2/27/20170115_Connectathon_Presentation_USCore_Meds.pptx Report out presentation]''' ==
 
=US-Core Track=
 
=US-Core Track=
  
Line 18: Line 19:
  
 
==Justification==
 
==Justification==
−
API access to the 2015 CCDS is required for EHR certification.
+
API access to the 2015 CCDS is required for EHR certification. In prior Connectathons, the DAF project team hosted a track to test the content profiles and a few basic queries.
  
−
''' US-Core Connectathon Priority Profiles:''' Allergies, Patient, CareTeam, Device, Observation-Vitalsigns
+
This track will focus on testing Client and Servers coverage on the recommended queries.
 +
 
 +
''' US-Core Connectathon Priority Profiles:'''  
 +
 
 +
AllergyIntolerance, Assessment and Plan of Treatment, CareTeam, Condition, Device-UDI, Goal, Immunization, Lab DiagnosticReport, Lab Observation, Observation-Smokingstatus, Observation-Vitalsigns, Patient, Practitioner, Procedure
 +
 
 +
Current draft of [http://hl7.org/fhir/us/core/index.html US-Core STU3 Profiles]
  
 
US-Core formalized conformance:
 
US-Core formalized conformance:
−
* [http://hl7.org/FHIR/us/daf/2016Sep/conformance-daf-query-requestor.html Conformance requirements for the US Requestor actor (to be updated)]
+
* [http://hl7.org/FHIR/us/daf/2016Sep/conformance-daf-query-requestor.html Conformance requirements for the US Requestor actor (to be updated post STU3)]
−
* [http://hl7.org/FHIR/us/daf/2016Sep/conformance-daf-query-responder.html Conformance requirements for the US Responder actor (to be updated)]
+
* [http://hl7.org/FHIR/us/daf/2016Sep/conformance-daf-query-responder.html Conformance requirements for the US Responder actor (to be updated STU3)]
  
 
Background on original [http://argonautwiki.hl7.org/index.php?title=Implementation_Guide#Introduction Argonaut use cases]:
 
Background on original [http://argonautwiki.hl7.org/index.php?title=Implementation_Guide#Introduction 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==
 
==Proposed Track Lead==
Line 45: Line 46:
 
Please sign up!
 
Please sign up!
  
−
If you're working on a server, please complete the [https://docs.google.com/a/healthedatainc.com/spreadsheets/d/1WVL09ge7SXE-Og6k3oVqWH9dcRexq76uIpGjJOBO4rQ/edit?usp=sharing "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.
+
[https://docs.google.com/spreadsheets/d/1b_zl38TvseYgENOozuVUYPB0fsX-THUm4tRHpJu36kI/edit#gid=0 FHIR Connectathon Participants]  
  
−
If you're working on a client, please complete the [https://docs.google.com/a/healthedatainc.com/spreadsheets/d/1WVL09ge7SXE-Og6k3oVqWH9dcRexq76uIpGjJOBO4rQ/edit?usp=sharing "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).
+
For Attestation and Tracking, please update [https://docs.google.com/spreadsheets/d/173CP0eQmlELxs0PuNP6aPrfDzBfTfVbmlse1lfWCu18/edit#gid=583925162 Attestation Tracker]
  
 
==Roles==
 
==Roles==
Line 74: Line 75:
 
==Scenarios==
 
==Scenarios==
 
=== Dedicated [https://chat.fhir.org/#narrow/stream/implementers/topic/Jan17Connectathon.20US-Core.20Track Zulip chat stream] for this Track.===
 
=== Dedicated [https://chat.fhir.org/#narrow/stream/implementers/topic/Jan17Connectathon.20US-Core.20Track Zulip chat stream] for this Track.===
−
 
−
 
−
==== 5 Use cases:====
 
−
# Patient access
 
−
# Allergies Access
 
−
# CareTeam
 
−
# Device
 
−
# Vital-signs
 
−
 
  
 
=== 1. Patient search ===
 
=== 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]'''
+
:Action: A client searches the patient Service for patients  
 
:Precondition: Patients with the search criteria have  been created
 
:Precondition: Patients with the search criteria have  been created
−
:Success Criteria: patients displayed in interface. (use browser query to confirm)
+
:Success Criteria: a client is able to execute and receive a response for each of the following queries:
 +
  GET [base]/Patient/[id]
 +
  GET [base]/Patient?identifier=[system]|[code]
 +
  GET [base]/Patient?name=[string]&gender=[code]
 +
  GET [base]/Patient?name=[string]&birthdate=[date]
 +
  GET [base]/Patient?family=[string]&gender=[code]
 +
  GET [base]/Patient?given=[string]&gender=[code]
  
−
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.
+
=== 2. Allergies Retrieve===
−
 
+
:Action: A client searches the AllergyIntolerance Service for patient's allergies
−
{| class="wikitable"
+
:Precondition: Patients with Allergies have been created
−
|id
+
:Success Criteria: A client is able to execute and receive a response for each of the following queries:
−
|name.last
+
  GET /AllergyIntolerance?patient=[id]
−
|name.given[1]
+
 
−
|name.given[2]
+
=== 3. Assessment and Plan of Treatment Access===
−
|gender
+
:Action: A client searches the Assessment and Plan of Treatment Service for patient's Assessment and Plan of Treatment
−
|birthdate
+
:Precondition: Patients with Assessment and Plan of Treatment have been created
−
|race
+
:Success Criteria: A client is able to execute and receive a response for each of the following queries:
−
|ethnicity
+
  GET /CarePlan?patient=[id]&category=assess-plan
−
|----
+
  GET /CarePlan?patient=[id]&category=assess-plan&status=active
−
|dafpid-1001
+
  GET /CarePlan?patient=[id]&category=assess-plan&date=[date]{&date=[date]}
−
|Shaw
+
  GET /CarePlan?patient=[id]&category=assess-plan&status=active&date=[date]{&date=[date]}
−
|Amy
 
−
|V.
 
−
|female
 
−
|2007-03-20
 
−
|White
 
−
|Non-Hipanic
 
−
|----
 
−
<!--
 
−
|dafpid-1002
 
−
|Ross
 
−
|Joseph
 
−
|I.
 
−
|male
 
−
|2003-10-02
 
−
|White
 
−
|Non-Hipanic
 
−
|----
 
−
|dafpid-1003
 
−
|Hill
 
−
|Robert
 
−
|P.
 
−
|male
 
−
|1964-06-19
 
−
|White
 
−
|Non-Hipanic
 
−
-->
 
−
|----
 
−
|}
 
  
−
=== 2. Search for all Patient Allergies ===
+
=== 4. Goals Access ===  
−
:Action: Client and Server support querying of:
+
:Action: A client searches the Goals Service for patient's Goals
 +
:Precondition: Patients with Goals have been created
 +
:Success Criteria: A client is able to execute and receive a response for each of the following queries:
 +
  GET /Goal?patient=[id]
 +
  GET /Goal?patient=[id]&date=[date]{&date=[date]} 
  
−
:*DAF Allergy for all of a patient's Allergies using using '''GET /AllergyIntolerance?patient=[id]'''.
+
=== 5. Immunization Access ===
 +
:Action: A client searches the Immunization Service for patient's Immunizations
 +
:Precondition: Patients with Immunizations have been created
 +
:Success Criteria: A client is able to execute and receive a response for each of the following queries:
 +
  GET /Immunization?patient={id}
  
−
:*DAF MedicationStatement for all of a patient's Medications: using '''GET /MedicationStatement?patient=[id].'''.
+
=== 6. Implantable Devices/UDI ===
 +
:Action: A client searches the Device Service for patient's Devices
 +
:Precondition: Patients with Devices have been created
 +
:Success Criteria: A client is able to execute and receive a response for each of the following queries:
 +
  GET /Device?patient=[id]
  
−
:Precondition: There is a US-Core Allergy resourcesthat has been created in the system.
+
=== 7. Laboratory Results ===
−
:Success Criteria: All US-CoreAllergy resource data for a patient are displayed in an interface.
+
:Action: A client searches the Lab Service for patient's Laboratory Results
−
:Bonus point:
+
:Precondition: Patients with Laboratory Results have been created
−
:* 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}]'''
+
:Success Criteria: A client is able to execute and receive a response for each of the following queries:
−
:* Client Server supports querying of DAF Condition, on patient.id and category="problems" using '''GET /Condition?patient=[id]&category=problem'''.
+
  GET [base]/DiagnosticReport?patient=[id]&category=LAB
 +
  GET [base]/DiagnosticReport?patient=[id]&code=[LOINC{,LOINC2,LOINC3,...}]
 +
  GET [base]/DiagnosticReport?patient=[id]&category=LAB&date=[date]{&date=[date]}
 +
  GET [base]/Observation?patient=[id]&category=laboratory
 +
  GET [base]/Observation?patient=[id]&code=[LOINC{,LOINC2,LOINC3,...}]
 +
  GET [base]/Observation?patient=[id]&category=laboratory&date=[date]{&date=[date]}
  
 +
=== 8. Problems and Health Concerns ===
 +
:Action: A client searches the Problems and Health Concerns service for patient's Problems and Health Concerns
 +
:Precondition: Patients with Problems and Health Concerns have been created
 +
:Success Criteria: A client is able to execute and receive a response for each of the following queries:
 +
  GET /Condition?patient=[id]
 +
  GET /Condition?patient=[id]&clinicalstatus=active,relapse,remission
 +
  GET /Condition?patient=[id]&category=problem
 +
  GET /Condition?patient=[id]&category=health-concern
  
−
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.
+
=== 9. Procedures ===
 +
:Action: A client searches the Procedures for patient's Procedures
 +
:Precondition: Patients with Procedures have been created
 +
:Success Criteria: A client is able to execute and receive a response for each of the following queries:
 +
  GET /Procedure?patient=[id]
 +
  GET /Procedure?patient=[id]&date=[date]{&date=[date
  
−
{| class="wikitable"
+
=== 10. Smoking Status===
−
|Conditions
+
:Action: A client searches the Smoking Status service for patient's Smoking Status
−
|Allergies
+
:Precondition: Patients with Smoking Status have been created
−
|SNOMED-allergies
+
:Success Criteria: A client is able to execute and receive a response for each of the following queries:
−
|----
+
  GET [base]/Observation?patient=[id]&code=72166-2
−
|Hypertensive disorder
 
−
|none
 
−
|160244002
 
−
|----
 
−
|}
 
  
−
=== 3. CareTeam Access===
+
=== 11. Vital Signs===
−
tbd
+
:Action: A client searches the Vital Signs service for patient's Vital Signs
 +
:Precondition: Patients with Vital Signs have been created
 +
:Success Criteria: A client is able to execute and receive a response for each of the following queries:
 +
  GET [base]/Observation?patient=[id]&category=vital-signs
 +
  GET [base]/Observation?patient=[id]&code=[vital sign LOINC{,LOINC2,LOINC3,...}]
 +
  GET [base]/Observation?patient=[id]&category=vital-signs&date=[date]{&date=[date]}
 +
  GET [base]/Observation?patient=[id]&code=[LOINC{,LOINC2...}]vital-signs&date=[date]{&date=[date]}
  
−
=== 4. Device-UDI Access ===  
+
=== 12. CareTeam===
−
tbd
+
:Action: A client searches the CareTeam service for patient's CareTeam
−
=== 5. Vital Signs Access ===
+
:Precondition: Patients with CareTeam have been created
−
tbd
+
:Success Criteria: A client is able to execute and receive a response for each of the following queries:
  
 
==TestScript(s)==
 
==TestScript(s)==
Line 171: Line 172:
 
These should be committed to SVN under trunk/connectathons/[connectathon]
 
These should be committed to SVN under trunk/connectathons/[connectathon]
 
-->
 
-->
−
  tbd
+
  Formal test data and tools will be provided to meet the use cases above.

Latest revision as of 18:24, 15 January 2017

Return to January 2017 Proposals

Report out presentation

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

Submitting WG/Project/Implementer Group

DAF Profiles Project

Justification

API access to the 2015 CCDS is required for EHR certification. In prior Connectathons, the DAF project team hosted a track to test the content profiles and a few basic queries.

This track will focus on testing Client and Servers coverage on the recommended queries.

US-Core Connectathon Priority Profiles:

AllergyIntolerance, Assessment and Plan of Treatment, CareTeam, Condition, Device-UDI, Goal, Immunization, Lab DiagnosticReport, Lab Observation, Observation-Smokingstatus, Observation-Vitalsigns, Patient, Practitioner, Procedure

Current draft of US-Core STU3 Profiles

US-Core formalized conformance:

Background on original Argonaut use cases:

Proposed Track Lead

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

Track Lead: Nagesth Bahsyam (Dragon)

Expected participants

Please sign up!

FHIR Connectathon Participants

For Attestation and Tracking, please update Attestation Tracker

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.

1. Patient search

Action: A client searches the patient Service for patients
Precondition: Patients with the search criteria have been created
Success Criteria: a client is able to execute and receive a response for each of the following queries:
 GET [base]/Patient/[id]
 GET [base]/Patient?identifier=[system]|[code]
 GET [base]/Patient?name=[string]&gender=[code]
 GET [base]/Patient?name=[string]&birthdate=[date]
 GET [base]/Patient?family=[string]&gender=[code]
 GET [base]/Patient?given=[string]&gender=[code]

2. Allergies Retrieve

Action: A client searches the AllergyIntolerance Service for patient's allergies
Precondition: Patients with Allergies have been created
Success Criteria: A client is able to execute and receive a response for each of the following queries:
 GET /AllergyIntolerance?patient=[id]

3. Assessment and Plan of Treatment Access

Action: A client searches the Assessment and Plan of Treatment Service for patient's Assessment and Plan of Treatment
Precondition: Patients with Assessment and Plan of Treatment have been created
Success Criteria: A client is able to execute and receive a response for each of the following queries:
 GET /CarePlan?patient=[id]&category=assess-plan
 GET /CarePlan?patient=[id]&category=assess-plan&status=active
 GET /CarePlan?patient=[id]&category=assess-plan&date=[date]{&date=[date]} 
 GET /CarePlan?patient=[id]&category=assess-plan&status=active&date=[date]{&date=[date]}

4. Goals Access

Action: A client searches the Goals Service for patient's Goals
Precondition: Patients with Goals have been created
Success Criteria: A client is able to execute and receive a response for each of the following queries:
 GET /Goal?patient=[id]
 GET /Goal?patient=[id]&date=[date]{&date=[date]}

5. Immunization Access

Action: A client searches the Immunization Service for patient's Immunizations
Precondition: Patients with Immunizations have been created
Success Criteria: A client is able to execute and receive a response for each of the following queries:
 GET /Immunization?patient={id}

6. Implantable Devices/UDI

Action: A client searches the Device Service for patient's Devices
Precondition: Patients with Devices have been created
Success Criteria: A client is able to execute and receive a response for each of the following queries:
 GET /Device?patient=[id]

7. Laboratory Results

Action: A client searches the Lab Service for patient's Laboratory Results
Precondition: Patients with Laboratory Results have been created
Success Criteria: A client is able to execute and receive a response for each of the following queries:
 GET [base]/DiagnosticReport?patient=[id]&category=LAB
 GET [base]/DiagnosticReport?patient=[id]&code=[LOINC{,LOINC2,LOINC3,...}]
 GET [base]/DiagnosticReport?patient=[id]&category=LAB&date=[date]{&date=[date]}
 GET [base]/Observation?patient=[id]&category=laboratory
 GET [base]/Observation?patient=[id]&code=[LOINC{,LOINC2,LOINC3,...}]
 GET [base]/Observation?patient=[id]&category=laboratory&date=[date]{&date=[date]}

8. Problems and Health Concerns

Action: A client searches the Problems and Health Concerns service for patient's Problems and Health Concerns
Precondition: Patients with Problems and Health Concerns have been created
Success Criteria: A client is able to execute and receive a response for each of the following queries:
 GET /Condition?patient=[id]
 GET /Condition?patient=[id]&clinicalstatus=active,relapse,remission
 GET /Condition?patient=[id]&category=problem
 GET /Condition?patient=[id]&category=health-concern

9. Procedures

Action: A client searches the Procedures for patient's Procedures
Precondition: Patients with Procedures have been created
Success Criteria: A client is able to execute and receive a response for each of the following queries:
 GET /Procedure?patient=[id]
 GET /Procedure?patient=[id]&date=[date]{&date=[date

10. Smoking Status

Action: A client searches the Smoking Status service for patient's Smoking Status
Precondition: Patients with Smoking Status have been created
Success Criteria: A client is able to execute and receive a response for each of the following queries:
 GET [base]/Observation?patient=[id]&code=72166-2

11. Vital Signs

Action: A client searches the Vital Signs service for patient's Vital Signs
Precondition: Patients with Vital Signs have been created
Success Criteria: A client is able to execute and receive a response for each of the following queries:
 GET [base]/Observation?patient=[id]&category=vital-signs
 GET [base]/Observation?patient=[id]&code=[vital sign LOINC{,LOINC2,LOINC3,...}]
 GET [base]/Observation?patient=[id]&category=vital-signs&date=[date]{&date=[date]}
 GET [base]/Observation?patient=[id]&code=[LOINC{,LOINC2...}]vital-signs&date=[date]{&date=[date]}

12. CareTeam

Action: A client searches the CareTeam service for patient's CareTeam
Precondition: Patients with CareTeam have been created
Success Criteria: A client is able to execute and receive a response for each of the following queries:

TestScript(s)

Formal test data and tools will be provided to meet the use cases above.
Retrieved from "https://wiki.hl7.org/w/index.php?title=201701_US_Core_Track&oldid=131273"