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
 
(72 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
[http://wiki.hl7.org/index.php?title=Category:201701_FHIR_Connectathon_Track_Proposals Return to January 2017 Proposals]
 
[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]]
 
[[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]''' ==
 
=Medication Track=
 
=Medication Track=
  
Line 32: Line 33:
  
 
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''.
 
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''.
 +
 +
We will also introduce the scenario for search across all Medication Resources using common search parameter as it  is described in the [http://build.fhir.org/http.html#vsearch Core Specification]
  
 
==Proposed Track Lead==
 
==Proposed Track Lead==
Line 82: Line 85:
 
# Patient and Provider access to a patient’s active and historical medication list
 
# Patient and Provider access to a patient’s active and historical medication list
 
# Patient and Provider updates to a patient’s active and historical medication list
 
# Patient and Provider updates to a patient’s active and historical medication list
−
# Create new outpatient prescription
+
# Create a new outpatient Prescription
 +
 
 +
[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
 +
 
 +
 
 +
==Submitting WG/Project/Implementer Group==
 +
<!-- 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==
 +
<!--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-MedicationRequest.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==
 +
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon -->
 +
See [[Connectathon_Track_Lead_Responsibilities]]
 +
 
 +
[mailto:mpeters@gevityinc.com Melva Peters]
 +
 
 +
[mailto:brett@riverrockassociates.com Brett Marquard]
 +
 
 +
[mailto:ehaas@healthdedatainc.com Eric Haas]
 +
 
 +
==Expected participants==
 +
<!-- 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 Spreadsheet]. You'll also need to update the `status` flag to indicate whether you've begun work (or completed work).
 +
 
 +
==Roles==
 +
 
 +
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on -->
 +
 
 +
<!-- Provide a description of the capabilities this role will have within the connectathon -->
 +
 
 +
(reproduced from Argonaut Project implementation-program ReConnectathon)
 +
 +
====Server/EHR====
 +
 
 +
If you're working on a server, please complete the "servers" tab of the Connectathons 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 Connectathons Spreadsheet (see above) . You'll also need to update the status flag to indicate whether you've begun work (or completed work).
 +
 
 +
==Scenarios==
 +
=== Dedicated [https://chat.fhir.org/#narrow/stream/implementers/topic/Jan17Connectathon.20Medication.20Track Zulip chat stream] for this Track.===
  
−
=== 1. Patient and Provider access to a patient’s active and historical medication list ===
 
−
'''Action:''' (Patient consumer or Provider) requests active medications or historical medication list.
 
  
−
Using
+
====Use cases:====
−
`GET /MedicationStatement?patient={id}&status=active`
+
# Patient and Provider access to a patient’s active medication list
−
for active medications or
+
# Patient and Provider updates to a patient’s active medication list
 +
# Create a new outpatient Prescription
  
−
`GET /MedicationStatement?patient={id}&status=active,completed,stopped,on-hold`
+
=== 1. Patient and Provider access to a patient’s active and historical medication list ===
−
for historical medications
 
  
−
This scenario is similar to 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.)
 
  
−
Examples:
+
[https://github.com/Healthedata1/FHIR-ONC-Meds/issues?q=is%3Aopen+is%3Aissue+label%3A%22access+to+medications%22+label%3AConnectathon Issues and Questions] (GitHub issues link)
  
−
http://fhir3.healthintersections.com.au/open/MedicationStatement/?pat=1&status=active
 
  
−
http://fhir3.healthintersections.com.au/open/MedicationStatement/?pat=1&status=active,completed,stopped,on-hold
+
'''Action:''' (Patient consumer or Provider) requests active medications or historical medication list.
  
 
'''Preconditions:'''
 
'''Preconditions:'''
 
# Patient does exist on the server previously with medications.
 
# 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, MedicationRequest, and Patient profiles
+
# 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, MedicationRequest, and Patient profiles
 +
# Client conforms to the US-Core MedicationStatement, MedicationRequest, and Patient profiles
 +
# Server and Client mandatory support of the [http://build.fhir.org/medicationstatement-definitions.html#MedicationStatement.category category element for MedicationStatement] and [http://build.fhir.org/medicationrequest-definitions.html#MedicationRequest.category MedicationRequest]
  
 
'''Definitions'''
 
'''Definitions'''
 
# Active Medication List – A list of medications that a given patient is currently taking.  
 
# Active Medication List – A list of medications that a given patient is currently taking.  
−
# Medication history - include a record of prior modifications to a patient’s medications
+
<!-- # Medication history - include a record of prior modifications to a patient’s medications
 
#* Ambulatory setting. Over multiple encounters
 
#* Ambulatory setting. Over multiple encounters
 
#* Inpatient setting. For the duration of an entire hospitalization.
 
#* Inpatient setting. For the duration of an entire hospitalization.
 +
-->
 +
# MAR linked to workflow and is medication actually given during hospitalization.
 +
 +
'''Use Cases'''
 +
# Get all medication for patient (prescribed or consumed) = historical
 +
# Get a current snapshot of active medications
 +
#* filter by status
 +
#* [https://github.com/Healthedata1/FHIR-ONC-Meds/issues/12 does category matter?]
 +
# for medications for encounter: ( encounter will be added to MedicationStatement)
 +
#*filter by encounter
 +
# Get only MAR orders
 +
#* Only Uses MedicationRequest Resource  ( no MedicationStatement )
 +
 +
Using a search on MedicationStatement with the following parameters:
 +
 +
* patient
 +
* status
 +
* category
 +
<!--
 +
* encounter for extension Reference Encounter )[see issue 5]
 +
**for historical inpatient medications - (see example below)
 +
**if absent return the most recent hospitalization
 +
-->
 +
 +
====Quick Start:====
 +
 +
Search on the Medication resources with the following parameters:
 +
 +
* patient
 +
* status
 +
* category
 +
* encounter
 +
<!--
 +
**for historical inpatient medications - (see example below)
 +
**if absent return the most recent hospitalization
 +
-->
 +
 +
-----
 +
Issues: [https://github.com/Healthedata1/FHIR-ONC-Meds/issues/11 How many # of Queries  for 1-3 ?]
 +
-----
 +
 +
'''1. Get all medication for patient (prescribed or consumed) = historical '''
 +
 +
* Currently: Searching just the MedicationStatement Resource
 +
GET [base]/MedicationStatement?status=active,completed,stopped,on-hold&subject=[id]
 +
 +
* For Consideration:  Searching both MedicationStatement and MedicationRequest Resources
 +
(See Bonus 2. below for a discussion of cross resource searches using common search parameters.)
 +
GET [base]?_type=MedicationStatement,MedicationRequest?status=active,completed,stopped,on-hold&patient=[id]
 +
 +
'''2. Get a current snapshot of active medications'''
 +
 +
* Currently: Searching just the MedicationStatement Resource
 +
GET [base]/MedicationStatement?status=active&subject=[id]
 +
 +
* For Consideration:  Searching both MedicationStatement and MedicationRequest Resources
 +
(See Bonus 2. below for a discussion of cross resource searches using common search parameters.)
 +
GET [base]?_type=MedicationStatement,MedicationRequest?status=active&subject=[id]
 +
 +
'''3. Get medications for encounter'''
 +
 +
* Currently: Searching just the MedicationStatement Resource
 +
GET [base]/MedicationStatement?status=active&subject=[id]&encounter=[id]
 +
 +
* For Consideration:  Searching both MedicationStatement and MedicationRequest Resources
 +
(See Bonus 2. below for a discussion of cross resource searches using common search parameters.)
 +
GET [base]?_type=MedicationStatement,MedicationRequest?status=active&subject=[id]&encounter=[id]
 +
 +
'''4. Get only MAR orders - Searching only the MedicationRequest Resource'''
 +
GET [base]/MedicationRequest?status=active&subject=[id]
 +
 +
 +
Examples: ( todo - complete )
 +
 +
http://fhir3.healthintersections.com.au/open/MedicationStatement/?pat=1&status=active
 +
 +
http://fhir3.healthintersections.com.au/open/MedicationStatement/?pat=1&status=active,completed,stopped,on-hold
 +
  
−
'''Success Criteria:'''Server returns a Bundle containing entries for:
+
'''Success Criteria:'''Server returns a Bundle containing entries for each of the use cases above
−
* all the patient's active medications
+
 
−
* all the patient's current and past medications
+
====Bonus point:====
−
   
+
 
 +
'''1. Search for a patient medication across  all of the medication resources.'''
 +
 
 +
In this scenario, the medication list includes MedicationRequest, MedicationAdministration and MedicationDispense resources in addition to MedicationStatement and multiples queries or a [http://build.fhir.org/search.html#revinclude _revinclude] on Patient would be used See Bonus 2. below for a discussion of cross resource searches using common search parameters.
  
−
'''Bonus point:'''The medication list includes MedicationRequest, MedicationAdministration and MedcicationDispense resources
+
# The medication list includes MedicationRequest, MedicationAdministration and MedicationDispense resources
 +
# Search on these resources with the following parameters:
 +
#* patient
 +
#* status
 +
#* category note: is not a common search paramenter
 +
<!--
 +
#* encounter for extension Reference Encounter )[see issue 5]
 +
#**for historical inpatient medications - (see example below)
 +
#**if absent return the most recent hospitalization
 +
-->
  
 
With Server Conforming to Pharmacy FHIR Maturity Project [http://healthedatainc.com/go-ftp/FHIR-ONC-Meds/StructureDefinition-medicationadministration.html MedicationAdministration Profile] and [http://healthedatainc.com/go-ftp/FHIR-ONC-Meds/StructureDefinition-medicationdispense.html MedicationDispense Profile]
 
With Server Conforming to Pharmacy FHIR Maturity Project [http://healthedatainc.com/go-ftp/FHIR-ONC-Meds/StructureDefinition-medicationadministration.html MedicationAdministration Profile] and [http://healthedatainc.com/go-ftp/FHIR-ONC-Meds/StructureDefinition-medicationdispense.html MedicationDispense Profile]
  
−
Using
 
−
`GET /MedicationRequest?patient={id}&status=active`
 
−
`GET /MedicationDispense?patient={id}&status=active`
 
−
`GET /MedicationAdministration?patient={id}&status=in-progress`
 
−
for active medications or
 
−
`GET /MedicationRequest?patient={id}&status=active,completed,stopped,on-hold`
 
−
`GET /MedicationDispense?patient={id}&status=active,completed,stopped,on-hold`
 
−
`GET /MedicationAdministration?patient={id}&status=in-progress,completed,stopped,on-hold`
 
−
for historical medications
 
  
−
[https://github.com/Healthedata1/FHIR-ONC-Meds/labels/Access%20to%20medication%20administration Issues and Questions] (GitHub issues link)
+
 
 +
'''2. Search for a patient medication across the MedicationStatement and MedicationRequest Resources'''
 +
 
 +
In this scenario,  MedicationRequest, MedicationStatement are being used and performing a search for a patient patient medication using the [http://build.fhir.org/http.html#vsearch cross resource queries].
 +
 
 +
# The medication list includes MedicationRequest, MedicationStatment resources
 +
# Search on these resources with the following common parameters:
 +
#* patient
 +
#* status
 +
#* category
 +
<!--
 +
#* encounter for extension Reference Encounter )[see issue 5]
 +
#**for historical inpatient medications - (see example below)
 +
#**if absent return the most recent hospitalization
 +
-->
 +
----
 +
[https://github.com/Healthedata1/FHIR-ONC-Meds/issues/13 Questions for discussion:]
 +
1  Should there be a Category element and parameter for MedicationAdministration and MedicationDispense as well?
 +
    This would allow a single query across all medications resources for a medication list.
 +
----
 +
 
 +
GET [base]?_type=MedicationStatement,MedicationRequest?status=active,completed,stopped,on-hold&subject=[id]&_format=[mime-type]
 +
 
 +
 
 +
 
 +
'''3. retrieve a historical medication list for a prior hospitalization (for example 3 hospitalizations ago)'''
  
 
=== 2. Patient or Provider adding new medication to patient’s (“active”) medication ===
 
=== 2. Patient or Provider adding new medication to patient’s (“active”) medication ===
  
−
'''Action:''' (Patient consumer or Provider) requests active medications or historical medication list.
+
 
 +
[https://github.com/Healthedata1/FHIR-ONC-Meds/labels/Update%20medication%20list Issues and Questions] (GitHub issues link)
 +
 
 +
 
 +
'''Action:''' (Patient consumer or Provider) updates active medications list.  Specifically updates (add, revise, deprecate) to MedicationStatement.
  
 
Using
 
Using
−
  `POST/PUT...
+
add
−
for active medications or
+
  PUT /MedicationStatement/[id] or POST /MedicationStatement
 +
revise
 +
PUT /MedicationStatement/[id]
  
−
``POST/PUT...
 
−
for historical medications
 
  
 
Examples:
 
Examples:
 +
 +
1. adding a new active medication to the patient records
 +
 +
POST http://fhir3.healthintersections.com.au/open/MedicationStatement
 +
 +
Request Body
 +
<?xml version="1.0" encoding="UTF-8"?>
 +
<MedicationStatement xmlns="http://hl7.org/fhir">
 +
  <status value="active"/> 
 +
        <MedicationCodeableConcept>
 +
          <coding>
 +
            <system value="http://www.nlm.nih.gov/research/umls/rxnorm"/>
 +
            <code value="315266"/>
 +
            <display value="Acetaminophen 500 MG"/>
 +
          </coding>
 +
        </MedicationCodeableConcept>
 +
  <patient>
 +
    <reference value="Patient/pat1"/>
 +
    <display value="Donald Duck"/>
 +
  </patient>
 +
  <effectiveDateTime value="2015-01-23"/>
 +
  <note>
 +
    <text value="Patient indicates they miss the occasional dose"/>
 +
  </note>
 +
  <category value="patientspecified">
 +
  </category>
 +
  <dosage>
 +
    <sequence value="1"/>
 +
    <text value="1-2 tablets once daily at bedtime as needed for restless legs"/>
 +
  </dosage>
 +
</MedicationStatement>
 +
 +
2. Changing a status from active to stopped
 +
 +
PUT http://fhir3.healthintersections.com.au/open/MedicationStatement/2
 +
 +
Request Body
 +
 +
<?xml version="1.0" encoding="UTF-8"?>
 +
<MedicationStatement xmlns="http://hl7.org/fhir">
 +
  <id value="2"
 +
  <status value="stopped"/> 
 +
        <MedicationCodeableConcept>
 +
          <coding>
 +
            <system value="http://www.nlm.nih.gov/research/umls/rxnorm"/>
 +
            <code value="315266"/>
 +
            <display value="Acetaminophen 500 MG"/>
 +
          </coding>
 +
        </MedicationCodeableConcept>
 +
  <patient>
 +
    <reference value="Patient/pat1"/>
 +
    <display value="Donald Duck"/>
 +
  </patient>
 +
  <effectiveDateTime value="2015-01-23"/>
 +
  <note>
 +
    <text value="Patient indicates they miss the occasional dose"/>
 +
  </note>
 +
  <category value="patientspecified">
 +
  </category>
 +
  <dosage>
 +
    <sequence value="1"/>
 +
    <text value="1-2 tablets once daily at bedtime as needed for restless legs"/>
 +
  </dosage>
 +
</MedicationStatement>
  
  
Line 151: Line 404:
 
# Patient does exist on the server previously with medications.
 
# 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, MedicationRequest, and Patient profiles
 
# 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, MedicationRequest, and Patient profiles
 +
# Client conforms to the US-Core MedicationStatement, MedicationRequest, and Patient profiles
 +
# Server and Client mandatory support of the [http://build.fhir.org/medicationstatement-definitions.html#MedicationStatement.category category element for MedicationStatement] and [http://build.fhir.org/medicationrequest-definitions.html#MedicationRequest.category MedicationRequest]
 +
# Client has write access to Server
  
−
'''Definitions'''
 
−
# Active Medication List – A list of medications that a given patient is currently taking.
 
−
# Medication history - include a record of prior modifications to a patient’s medications
 
−
#* Ambulatory setting. Over multiple encounters
 
−
#* Inpatient setting. For the duration of an entire hospitalization.
 
  
 
'''Success Criteria:
 
'''Success Criteria:
  
−
'''Bonus point:'''The medication list includes MedicationRequest, MedicationAdministration and MedcicationDispense resources
+
* Client successfully adds new MedicationStatement to Patient's medication list
 +
* Client successfule revises existing MedicationStatement on Patient's medication list
 +
 
 +
 
 +
====Bonus point:====
 +
update MedicationRequest, MedicationAdministration and MedcicationDispense resources
  
 
With Server Conforming to Pharmacy FHIR Maturity Project [http://healthedatainc.com/go-ftp/FHIR-ONC-Meds/StructureDefinition-medicationadministration.html MedicationAdministration Profile] and [http://healthedatainc.com/go-ftp/FHIR-ONC-Meds/StructureDefinition-medicationdispense.html MedicationDispense Profile]
 
With Server Conforming to Pharmacy FHIR Maturity Project [http://healthedatainc.com/go-ftp/FHIR-ONC-Meds/StructureDefinition-medicationadministration.html MedicationAdministration Profile] and [http://healthedatainc.com/go-ftp/FHIR-ONC-Meds/StructureDefinition-medicationdispense.html MedicationDispense Profile]
  
−
`POST/PUT...
+
=== 3. Create a new outpatient Prescription ===
−
for active medications or
+
 
 +
 
 +
[https://github.com/Healthedata1/FHIR-ONC-Meds/labels/Create%20new%20outpatient%20prescription Issues and Questions] (GitHub issues link)
 +
 
 +
 
 +
==== 3.1 Action: ====
 +
Provider creates new outpatient Prescription using the MedicationRequest resource ( this just a record of the request and need to be made actionable by some Workflow pattern described below.
  
−
``POST/PUT...
+
Using
−
for historical medications
 
  
−
[https://github.com/Healthedata1/FHIR-ONC-Meds/labels/Access%20to%20medication%20administration Issues and Questions] (GitHub issues link)
+
PUT /MedicationRequest/[id] or POST /MedicationRequest
  
−
=== 3. Dispense medication from Pharmacy ===
 
−
This scenario should be considered for future use since current vendors haven't prioritized the resources to support.
 
  
−
=== 4. Create new outpatient Prescription ===
+
Examples:
−
This scenario should be considered for future use since current vendors haven't prioritized the resources to support.
+
 
 +
adding a new prescription for the patient
 +
 
 +
POST http://fhir3.healthintersections.com.au/open/MedicationRequest
 +
 
 +
Request Body
 +
<?xml version="1.0" encoding="UTF-8"?>
 +
<MedicationRequest xmlns="http://hl7.org/fhir">
 +
  <status value="active"/>
 +
  <stage>
 +
      <coding>
 +
        <code value="original-order"/>
 +
      </coding>
 +
  </stage>
 +
  <medicationCodeableConcept>
 +
      <coding>
 +
        <system value="http://www.nlm.nih.gov/research/umls/rxnorm"/>
 +
        <code value="315266"/>
 +
        <display value="Acetaminophen 500 MG"/>
 +
      </coding>
 +
  </medicationCodeableConcept>
 +
  <patient>
 +
      <!--  Linked to the resource patient who needs the medication  -->
 +
      <reference value="Patient/pat1"/>
 +
      <display value="Donald Duck"/>
 +
  </patient>
 +
  <dateWritten value="2015-01-15"/>
 +
  <prescriber>
 +
      <!--  Linked to the practitioner who treats patient  -->
 +
      <reference value="Practitioner/f007"/>
 +
      <display value="Patrick Pump"/>
 +
  </prescriber>
 +
  <category>
 +
      <coding>
 +
        <system value="http://hl7.org/fhir/medication-request-category"/>
 +
        <code value="inpatient"/>
 +
        <display value="Inpatient"/>
 +
      </coding>
 +
  </category>
 +
  <dosageInstruction>
 +
      <sequence value="1"/>
 +
      <text value="one to two tablets every 4-6 hours as needed for rib pain"/>
 +
  </dosageInstruction>
 +
</MedicationRequest>
 +
 
 +
 
 +
 
 +
 
 +
 
 +
'''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, MedicationRequest, and Patient profiles
 +
# Client conforms to the US-Core MedicationStatement, MedicationRequest, and Patient profiles
 +
# Server and Client mandatory support of the [http://build.fhir.org/medicationstatement-definitions.html#MedicationStatement.category category element for MedicationStatement] and [http://build.fhir.org/medicationrequest-definitions.html#MedicationRequest.category MedicationRequest]
 +
 
 +
 
 +
'''Success Criteria:
 +
 
 +
* Client successfully create new MedicationRequest
 +
 
 +
==== 3.2 Action: ====
 +
Subsequent workflow steps depend on specific pattern agreed upon by busines partners.  See a list of possible scenarios [http://build.fhir.org/workflow.html#commpatterns here].
 +
 +
For example the new outpatient Prescription is made actionable by using the Task resource to initiate a prescription to a community or inhouse pharmacy.
 +
 +
Note:  The request would generate a NCPDP script for community pharmacy or likely a v2 message or inhouse pharmacy.
 +
 
 +
 
 +
 
 +
'''Bonus point:''' update MedicationRequest, MedicationAdministration and/or MedicationDispense resources based on new MedicationRequest.
 +
 
 +
With Server Conforming to Pharmacy FHIR Maturity Project [http://healthedatainc.com/go-ftp/FHIR-ONC-Meds/StructureDefinition-medicationadministration.html MedicationAdministration Profile] and [http://healthedatainc.com/go-ftp/FHIR-ONC-Meds/StructureDefinition-medicationdispense.html MedicationDispense Profile]
  
 
==TestScript(s)==
 
==TestScript(s)==

Latest revision as of 18:25, 15 January 2017

Return to January 2017 Proposals

Report out presentation

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.

We will also introduce the scenario for search across all Medication Resources using common search parameter as it is described in the Core Specification

Proposed Track Lead

See Connectathon_Track_Lead_Responsibilities

Melva Peters

Brett Marquard

Eric Haas

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 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.

Use cases:

  1. Patient and Provider access to a patient’s active and historical medication list
  2. Patient and Provider updates to a patient’s active and historical medication list
  3. Create a new outpatient Prescription

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

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 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 ReConnectathon)

Server/EHR

If you're working on a server, please complete the "servers" tab of the Connectathons 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 Connectathons 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.

Use cases:

  1. Patient and Provider access to a patient’s active medication list
  2. Patient and Provider updates to a patient’s active medication list
  3. Create a new outpatient Prescription

1. Patient and Provider access to a patient’s active and historical medication list

Issues and Questions (GitHub issues link)


Action: (Patient consumer or Provider) requests active medications or historical medication list.

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, MedicationRequest, and Patient profiles
  3. Client conforms to the US-Core MedicationStatement, MedicationRequest, and Patient profiles
  4. Server and Client mandatory support of the category element for MedicationStatement and MedicationRequest

Definitions

  1. Active Medication List – A list of medications that a given patient is currently taking.
  2. MAR linked to workflow and is medication actually given during hospitalization.

Use Cases

  1. Get all medication for patient (prescribed or consumed) = historical
  2. Get a current snapshot of active medications
  3. for medications for encounter: ( encounter will be added to MedicationStatement)
    • filter by encounter
  4. Get only MAR orders
    • Only Uses MedicationRequest Resource ( no MedicationStatement )

Using a search on MedicationStatement with the following parameters:

  • patient
  • status
  • category

Quick Start:

Search on the Medication resources with the following parameters:

  • patient
  • status
  • category
  • encounter
Issues: How many # of Queries  for 1-3 ?

1. Get all medication for patient (prescribed or consumed) = historical

  • Currently: Searching just the MedicationStatement Resource
GET [base]/MedicationStatement?status=active,completed,stopped,on-hold&subject=[id]
  • For Consideration: Searching both MedicationStatement and MedicationRequest Resources

(See Bonus 2. below for a discussion of cross resource searches using common search parameters.) 

GET [base]?_type=MedicationStatement,MedicationRequest?status=active,completed,stopped,on-hold&patient=[id]

2. Get a current snapshot of active medications

  • Currently: Searching just the MedicationStatement Resource
GET [base]/MedicationStatement?status=active&subject=[id]
  • For Consideration: Searching both MedicationStatement and MedicationRequest Resources

(See Bonus 2. below for a discussion of cross resource searches using common search parameters.) 

GET [base]?_type=MedicationStatement,MedicationRequest?status=active&subject=[id]

3. Get medications for encounter

  • Currently: Searching just the MedicationStatement Resource
GET [base]/MedicationStatement?status=active&subject=[id]&encounter=[id]
  • For Consideration: Searching both MedicationStatement and MedicationRequest Resources

(See Bonus 2. below for a discussion of cross resource searches using common search parameters.) 

GET [base]?_type=MedicationStatement,MedicationRequest?status=active&subject=[id]&encounter=[id]

4. Get only MAR orders - Searching only the MedicationRequest Resource 

GET [base]/MedicationRequest?status=active&subject=[id]


Examples: ( todo - complete )

http://fhir3.healthintersections.com.au/open/MedicationStatement/?pat=1&status=active

http://fhir3.healthintersections.com.au/open/MedicationStatement/?pat=1&status=active,completed,stopped,on-hold


Success Criteria:Server returns a Bundle containing entries for each of the use cases above

Bonus point:

1. Search for a patient medication across all of the medication resources.

In this scenario, the medication list includes MedicationRequest, MedicationAdministration and MedicationDispense resources in addition to MedicationStatement and multiples queries or a _revinclude on Patient would be used See Bonus 2. below for a discussion of cross resource searches using common search parameters.

  1. The medication list includes MedicationRequest, MedicationAdministration and MedicationDispense resources
  2. Search on these resources with the following parameters:
    • patient
    • status
    • category note: is not a common search paramenter

With Server Conforming to Pharmacy FHIR Maturity Project MedicationAdministration Profile and MedicationDispense Profile


2. Search for a patient medication across the MedicationStatement and MedicationRequest Resources

In this scenario, MedicationRequest, MedicationStatement are being used and performing a search for a patient patient medication using the cross resource queries.

  1. The medication list includes MedicationRequest, MedicationStatment resources
  2. Search on these resources with the following common parameters:
    • patient
    • status
    • category
Questions for discussion:
1  Should there be a Category element and parameter for MedicationAdministration and MedicationDispense as well?
   This would allow a single query across all medications resources for a medication list.

GET [base]?_type=MedicationStatement,MedicationRequest?status=active,completed,stopped,on-hold&subject=[id]&_format=[mime-type]


3. retrieve a historical medication list for a prior hospitalization (for example 3 hospitalizations ago)

2. Patient or Provider adding new medication to patient’s (“active”) medication

Issues and Questions (GitHub issues link)


Action: (Patient consumer or Provider) updates active medications list. Specifically updates (add, revise, deprecate) to MedicationStatement.

Using add 

PUT /MedicationStatement/[id] or POST /MedicationStatement

revise 

PUT /MedicationStatement/[id]


Examples:

1. adding a new active medication to the patient records

POST http://fhir3.healthintersections.com.au/open/MedicationStatement

Request Body 

<?xml version="1.0" encoding="UTF-8"?>
<MedicationStatement xmlns="http://hl7.org/fhir">
 <status value="active"/>  
       <MedicationCodeableConcept>
         <coding>
           <system value="http://www.nlm.nih.gov/research/umls/rxnorm"/>
           
           <display value="Acetaminophen 500 MG"/>
         </coding>
       </MedicationCodeableConcept>
 <patient>
   <reference value="Patient/pat1"/>
   <display value="Donald Duck"/> 
 </patient>
 <effectiveDateTime value="2015-01-23"/>
 <note>
   <text value="Patient indicates they miss the occasional dose"/>
 </note>
 <category value="patientspecified">
 </category>
 <dosage>
   <sequence value="1"/>
   <text value="1-2 tablets once daily at bedtime as needed for restless legs"/>
 </dosage>
</MedicationStatement>

2. Changing a status from active to stopped

PUT http://fhir3.healthintersections.com.au/open/MedicationStatement/2

Request Body 

<?xml version="1.0" encoding="UTF-8"?>
<MedicationStatement xmlns="http://hl7.org/fhir">
 <id value="2"
 <status value="stopped"/>  
       <MedicationCodeableConcept>
         <coding>
           <system value="http://www.nlm.nih.gov/research/umls/rxnorm"/>
           
           <display value="Acetaminophen 500 MG"/>
         </coding>
       </MedicationCodeableConcept>
 <patient>
   <reference value="Patient/pat1"/>
   <display value="Donald Duck"/> 
 </patient>
 <effectiveDateTime value="2015-01-23"/>
 <note>
   <text value="Patient indicates they miss the occasional dose"/>
 </note>
 <category value="patientspecified">
 </category>
 <dosage>
   <sequence value="1"/>
   <text value="1-2 tablets once daily at bedtime as needed for restless legs"/>
 </dosage>
</MedicationStatement>


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, MedicationRequest, and Patient profiles
  3. Client conforms to the US-Core MedicationStatement, MedicationRequest, and Patient profiles
  4. Server and Client mandatory support of the category element for MedicationStatement and MedicationRequest
  5. Client has write access to Server


Success Criteria:

  • Client successfully adds new MedicationStatement to Patient's medication list
  • Client successfule revises existing MedicationStatement on Patient's medication list


Bonus point:

update MedicationRequest, MedicationAdministration and MedcicationDispense resources

With Server Conforming to Pharmacy FHIR Maturity Project MedicationAdministration Profile and MedicationDispense Profile

3. Create a new outpatient Prescription

Issues and Questions (GitHub issues link)


3.1 Action:

Provider creates new outpatient Prescription using the MedicationRequest resource ( this just a record of the request and need to be made actionable by some Workflow pattern described below.

Using 

PUT /MedicationRequest/[id] or POST /MedicationRequest


Examples:

adding a new prescription for the patient

POST http://fhir3.healthintersections.com.au/open/MedicationRequest

Request Body 

<?xml version="1.0" encoding="UTF-8"?>
<MedicationRequest xmlns="http://hl7.org/fhir">
  <status value="active"/>
  <stage>
     <coding>
        
     </coding>
  </stage>
  <medicationCodeableConcept>
     <coding>
        <system value="http://www.nlm.nih.gov/research/umls/rxnorm"/>
        
        <display value="Acetaminophen 500 MG"/>
     </coding>
  </medicationCodeableConcept>
  <patient>
     <reference value="Patient/pat1"/>
     <display value="Donald Duck"/>
  </patient>
  <dateWritten value="2015-01-15"/>
  <prescriber>
     <reference value="Practitioner/f007"/>
     <display value="Patrick Pump"/>
  </prescriber>
  <category>
     <coding>
        <system value="http://hl7.org/fhir/medication-request-category"/>
        
        <display value="Inpatient"/>
     </coding>
  </category>
  <dosageInstruction>
     <sequence value="1"/>
     <text value="one to two tablets every 4-6 hours as needed for rib pain"/>
  </dosageInstruction>
</MedicationRequest>



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, MedicationRequest, and Patient profiles
  3. Client conforms to the US-Core MedicationStatement, MedicationRequest, and Patient profiles
  4. Server and Client mandatory support of the category element for MedicationStatement and MedicationRequest


Success Criteria:

  • Client successfully create new MedicationRequest

3.2 Action:

Subsequent workflow steps depend on specific pattern agreed upon by busines partners. See a list of possible scenarios here.

For example the new outpatient Prescription is made actionable by using the Task resource to initiate a prescription to a community or inhouse pharmacy.

Note: The request would generate a NCPDP script for community pharmacy or likely a v2 message or inhouse pharmacy.


Bonus point: update MedicationRequest, MedicationAdministration and/or MedicationDispense resources based on new MedicationRequest.

With Server Conforming to Pharmacy FHIR Maturity Project MedicationAdministration Profile and MedicationDispense Profile

TestScript(s)

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