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

Difference between revisions of "201701 Medication Track"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "{{subst::Template for FHIR Connectathon Track Proposals}}")
 
(Copied from initially created page by Melva Peters)
Line 1: Line 1:
 +
[http://wiki.hl7.org/index.php?title=Category:201701_FHIR_Connectathon_Track_Proposals Return to January 2017 Proposals]
 +
[[Category:201701_FHIR_Connectathon_Track_Proposals|January 2017 Proposals]]
 +
__NOTOC__
 +
=Medication Track=
 +
 +
'''Coordinated with other related Connectathon tracks'''
 +
 +
* US-Core IG
  
−
[[Category:201701_FHIR_Connectathon_Track_Proposals|Jan 2017 Proposals]]
 
−
__NOTOC__
 
−
=Track Name=
 
  
 
==Submitting WG/Project/Implementer Group==
 
==Submitting WG/Project/Implementer Group==
 
<!-- Who is asking for this track? -->
 
<!-- Who is asking for this track? -->
 +
 +
[http://www.hl7.org/Special/committees/medication/projects.cfm?action=edit&ProjectNumber=1297 Pharmacy FHIR Profiles Project]
 +
 +
[http://www.hl7.org/Special/committees/medication/index.cfm Pharmacy Work Group]
  
 
==Justification==
 
==Justification==
 
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
 
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
 +
 +
This project is intended to support the Pharmacy WG in moving the Pharmacy FHIR resources to a higher maturity level based on feedback from the Argonaut Project, HL7 work groups and industry implementers.  The key objective for this project is to use implement and test the following FHIR Medication related resources and the corresponding US-Core medication Profiles:
 +
 +
* [http://hl7-fhir.github.io/medication.html Medication]  and [http://ig.fhir.me/Healthedata1/stu3-daf/daf-core-medication.html US Core Medication]
 +
 +
* [http://hl7-fhir.github.io/medication.html Medication Order]  and [http://ig.fhir.me/Healthedata1/stu3-daf/daf-core-medicationorder.html US Core Medication Order]
 +
 +
* [http://hl7-fhir.github.io/medicationstatement.html Medication - Medication Statement] and [http://ig.fhir.me/Healthedata1/stu3-daf/daf-core-medicationstatement.html US Core Medication Statement]
 +
 +
* [http://hl7-fhir.github.io/medicationadministration.html Medication Administration]
 +
 +
* [http://hl7-fhir.github.io/medicationdispense.html Medication Dispense]
 +
 +
In addition to implementing the existing US-Core medication Profiles this tract will examine and support the development of new proposed US-Realm profiles for ''MedicationAdministration'' and ''MedicationDispense''.
  
 
==Proposed Track Lead==
 
==Proposed Track Lead==
 
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon -->
 
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon -->
 
See [[Connectathon_Track_Lead_Responsibilities]]
 
See [[Connectathon_Track_Lead_Responsibilities]]
 +
 +
[mailto:mpeters@gevityinc.com Melva Peters]
 +
 +
[mailto:brett@riverrockassociates.com Brett Marquard]
 +
 +
[mailto:ehaas@healthdedatainc.com Eric Haas]
 +
 +
 +
pending... dedicated Zulip chat stream.
  
 
==Expected participants==
 
==Expected participants==
 
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
 
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
 +
 +
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.
 +
 +
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).
  
 
==Roles==
 
==Roles==
−
Please include information here regarding how much advance preparation will be required if creating a client and/or server.
+
 
 
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on -->
 
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on -->
−
===Role 1 Name===
+
 
 
<!-- Provide a description of the capabilities this role will have within the connectathon -->
 
<!-- Provide a description of the capabilities this role will have within the connectathon -->
 +
 +
(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 [http://docs.smarthealthit.org/authorization/ '''OAuth2-based SMART on FHIR authorization specification''']. To make this more approachable for new implementers, you can think about handling security in four parts:
 +
# 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
 +
# 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.
 +
# 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.
 +
# 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==
 
==Scenarios==
 
<!-- What will be the actions performed by participants? -->
 
<!-- What will be the actions performed by participants? -->
  
−
===Scenario Step 1 Name===
+
==== 5 Use cases:====
−
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
+
# Patient access to medications
−
:Precondition: <!-- What setup is required prior to executing this step? -->
+
# Dispense medication from pharmacy
−
:Success Criteria: <!-- How will the participants know if the test was successful? -->
+
# Create new outpatient prescription
−
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->
+
# Add new medication to patient medication list
 +
# Access to medication administration
 +
 
 +
 
 +
=== 1. Patient access to medications ===
 +
'''Action:''' (Patient consumer) requests medications.
 +
This scenario is the same as the Argonaut use case Sprint 4.  Refer to the [http://argonautwiki.hl7.org/index.php?title=Medications Argonaut Medications IG] for Success Criteria.
 +
(Note although this references DSTU2, our focus is on STU3.)
 +
 
 +
'''Preconditions:'''
 +
# Patient does exist on the server previously with medications.
 +
# Server Conforms to the [http://ig.fhir.me/Healthedata1/stu3-daf/capabilitystatement-daf-query-responder.html US-Core CapabilityStatement-daf-query-responder] for Medication, MedicationStatement, MedicationOrder, and Patient profiles
 +
 
 +
'''Success Criteria:'''Patient medication list returned.
 +
 
 +
'''Bonus point:'''The medication list includes both MedicationStatement and MedicationRequest
 +
 
 +
'''[https://github.com/Healthedata1/Medications-Track-Issues/issues Questions for Discussion]:(GitHub issues link)
 +
 
 +
=== 2. Dispense medication from pharmacy===
 +
tbd
 +
 
 +
=== 3. Create new outpatient prescription===
 +
tbd
  
−
<!-- Provide a description of each task -->
+
=== 4. Add new medication to patient medication list===
 +
tbd
 +
=== 5. Access to medication administration===
 +
tbd
  
 
==TestScript(s)==
 
==TestScript(s)==
Line 38: Line 119:
 
These should be committed to SVN under trunk/connectathons/[connectathon]
 
These should be committed to SVN under trunk/connectathons/[connectathon]
 
-->
 
-->
 +
tbd

Revision as of 20:55, 26 October 2016

Return to January 2017 Proposals

Medication Track

Coordinated with other related Connectathon tracks

  • US-Core IG


Submitting WG/Project/Implementer Group

Pharmacy FHIR Profiles Project

Pharmacy Work Group

Justification

This project is intended to support the Pharmacy WG in moving the Pharmacy FHIR resources to a higher maturity level based on feedback from the Argonaut Project, HL7 work groups and industry implementers. The key objective for this project is to use implement and test the following FHIR Medication related resources and the corresponding US-Core medication Profiles:

In addition to implementing the existing US-Core medication Profiles this tract will examine and support the development of new proposed US-Realm profiles for MedicationAdministration and MedicationDispense.

Proposed Track Lead

See Connectathon_Track_Lead_Responsibilities

Melva Peters

Brett Marquard

Eric Haas 


pending... dedicated Zulip chat stream.

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

5 Use cases:

  1. Patient access to medications
  2. Dispense medication from pharmacy
  3. Create new outpatient prescription
  4. Add new medication to patient medication list
  5. Access to medication administration


1. Patient access to medications

Action: (Patient consumer) requests medications. This scenario is the same as the Argonaut use case Sprint 4. Refer to the Argonaut Medications IG for Success Criteria. (Note although this references DSTU2, our focus is on STU3.)

Preconditions:

  1. Patient does exist on the server previously with medications.
  2. Server Conforms to the US-Core CapabilityStatement-daf-query-responder for Medication, MedicationStatement, MedicationOrder, and Patient profiles

Success Criteria:Patient medication list returned.

Bonus point:The medication list includes both MedicationStatement and MedicationRequest

Questions for Discussion:(GitHub issues link)

2. Dispense medication from pharmacy

tbd

3. Create new outpatient prescription

tbd

4. Add new medication to patient medication list

tbd

5. Access to medication administration

tbd

TestScript(s)

tbd
Retrieved from "https://wiki.hl7.org/w/index.php?title=201701_Medication_Track&oldid=128073"