2016-11-03 Rx Conf Call

Related Links Pharmacy Home Page Conference call minutes

Attendees

• John Hatem
• Melva Peters (Chair)

ListServ / Zulip Discussions - DEFERRED

• List Serve Postings
  • email from Grahame - fluid orders - sent to the Pharmacy list
• Zulip
  • MedicationStatement
    • related to "do not do" - as in patient not to be given a certain medication
    • may come out of Negation project from Patient Care
    • a number of items included in this Zulip chat
      • patient not to be given medication
        • not likely a medicationStatement - is this a negative order?
        • has not come up for Cerner - may infer something like this from an allergy
      • doctor recommends that GP prescribes drug ABC

Action:  Melva to reach out to Philip to post tracker item

Order Service Catalogue PSS

• OO PSS - consideration to co-sponsor

File:HL7 Project Scope Statement v2016 OS update Sept2016 v2.docx

• the project will cover the requirements for a catalogue in a generic way - would include a set of resources as appropriate
  • would include other metadata about the catalogue - date approved
  • discussion of the scope of this - needs to include use cases for formularies that go beyond ordering such as adjudication of claims/coverage or where a prescriber needs to order a medication that is not part of a formulary.
  • Motion: Pharmacy agrees to co-sponsor - Jose - seconded by John - 5/0/0

Action:  send comments to Lorraine Constable - complete
Action:  followup about times for calls - complete

Renaming MedicationOrder to MedicationRequest Discussion TR#10456

• Email received July 4, 2016 from Lloyd
  • The FHIR Workflow task force has been working for almost the past year to come up with guidelines to improve the consistency of how workflow (the process of requesting something to happen and then reporting the results of that request) are handled across all FHIR resources. Its scope encompasses clinical, administrative and financial resources. We've had relatively broad participation in the bi-weekly calls and very broad participation in the face-to-face sessions at HL7 WGMs.
  • While the project is still testing the recommendations using a variety of use-cases, we are sufficiently confident in the stability of the recommendations, that we voted last week to request all impacted work groups to apply the relevant changes to their resources for inclusion as part of the upcoming STU 3 ballot.
  • We recognize that the timelines for making this occur are tight. In the event that a work group cannot make the changes requested, we invite them to, at minimum, provide an implementation note highlighting the intention to adjust each affected resource to align with the workflow pattern and to include a hyperlink to the "workflow.html" page. (This page doesn't exist yet, but it will.)
  • We also recognize that not all of these recommendations will fall into the 80% for all resources. Work groups are asked to do the following for each recommendation:
    • Apply the recommendation from the FHIR workflow task force as part of core
    • Create extensions to support those data elements that are relevant but not commonly used by the domain
    • Indicate that they feel the recommendation should not apply to their resource by posting an email to the fhirworkflow list server indicating why they believe a given recommendation is inappropriate for a given resource.
    • ((The list of resources believed to be impacted by the FHIR Workflow recommendations are provided in the attached spreadsheet. Most of the listed resources are categorized as either a "request" - a resource that indicates a specific intention for something to occur; or an "event" - a resource that represents a specific occurrence that could have been done in response to a request. A few event resources are marked with a question-mark as it's not clear whether they are requested or not. It's possible that one or more resources in the spreadsheet that were not categorized should in fact be listed as a "request" or an "event". Feel free to apply the workflow recommendations to uncategorized resources if you feel they should apply.
    • In addition to these categorizations, the workflow project calls for the Order and OrderResponse resources to be removed. They are superseded by Task. As well, the scope of ProcessRequest and ProcessResponse should be revised to leverage Task for the purpose of requesting the current state of a resource and for soliciting a state change.
  • The recommendations are as follows:
    • Request
      • Add a note in the introduction section that the resource is a "request" resource from a FHIR workflow perspective, including a hyperlink to workflow.html#request.
      • Rename the resource to [xxx]Request instead of [xxx]Order (request resources are used for plans, recommendations and proposals, not just orders
      • Ensure all of the data elements present in the "request" pattern document (attached) are present in the resource, keeping consistency with the naming where possible and adapting definitions to reflect domain-specifics
      • Ensure the status element for the resource has a terminology that aligns with the "request" states as well. (Note that all statuses related to fulfillment progress are now handled by Task.)
  • Event
    • Add a note in the introduction section that the resource is an "event" resource from a FHIR workflow perspective, including a hyperlink to workflow.html#event.
      • Ensure all of the data elements present in the "request" pattern document (attached) are present in the resource, keeping consistency with the naming where possible and adapting definitions to reflect domain-specifics
      • Ensure the status element for the resource has a terminology that aligns with the "request" states as well. (Note that all statuses related to fulfillment progress are now handled by Task.)
• From January 25 meeting: Lloyd shared the proposal to rename all request type resources to <resource>_Request. Seeking consistent name for all resources and term that encompasses larger swath of types of requests. An element beneath the tag instance would state the particular request, such as 'order'. This impacts the current Pharmacy Medication Order FHIR resource.

 Completed Action: Rx WG to discuss to determine if we agree or not. - agreed (with no vote) to comply with change but not needed to be made yet, per Lloyd

• Lloyd suggested that we hold off on making the change, if we decide to make the change. Wait for FHIR Infrastructure group to workout additional details before we make the changes. May have impact on how other data elements are name or included.
• Discussion: If we agree to the change, we'll need to review the description and other content for our resource to ensure that it accurately reflects the usage. This type of change will mean changes for implementers and it may not be as intuitive for implementers.
  • No decision to be made today. Will consider on a future call
  • Discussion - July 11 Meeting
    • John described the change proposed - we can alias resource to include MedicationOrder
    • Moved by John - seconded by Marla to add note to introduction section to Medication Order Add a note in the introduction section that the resource is a "request" resource from a FHIR workflow perspective, including a hyperlink to workflow.html#request. and to add an implementation note highlighting the intention to adjust each affected resource to align with the workflow pattern and to include a hyperlink to the "workflow.html" page. - 7/0/0 Carried
    • Moved by John - seconded by Marla to add note to introduction section to Medication Dispense, MedicationAdministration, MedicationStatement - Add a note in the introduction section that the resource is a "request" resource from a FHIR workflow perspective, including a hyperlink to workflow.html#request. and to add an implementation note highlighting the intention to adjust each affected resource to align with the workflow pattern and to include a hyperlink to the "workflow.html" page. 7/0/0 Carried
• Discussion on August 22
  • John has done a mapping for MedicationOrder to RequestLogicalModel - See spreadsheet File:Mapping Med Order to Workflow Request logical model.xlsx
    • change name to MedicationRequest and add alias to MedicationOrder
      • identifier - recommend do not change cardinality
      • definition reference - add
      • basedOn reference to request - assume that we should add, but John to ask Lloyd for clarification
      • replaces - reference to request - we need to discuss this - we have priorPrescription - not sure if this is the same - should we have both - John to ask Lloyd for clarification
      • status - need to have a discussion with workflow team about codes - question about cancelled and stopped
        • change our cardinality to be 1..1
      • stage - add
      • reference to patient - change cardinality to 1..1
      • reference to Encounter/Episode of care - do not change
      • occurence - leave as is for now
      • requester - we only reference practitioner - need to consider if we should expand
      • performerType and performer - need to consider - may be related to who should administer the medication
• Discussion on October 10
  • See updated spreadsheet
  • Will continue discussion 10/17
• Discussion on October 17
  • File:Mapping Med Order to Workflow Request logical model.xlsx
  • Motion to add definition, basedOn, requisition, stage, reason reference (to observation), supportingInformation to MedicationOrder - moved by John - seconded by Yunwei - Carried 6/0/0
    • this deals with TR#12203 and TR#12174
  • Motion to add change name to MedicationRequest and add Medication Order as an alias - moved by John - seconded by Melva
    • discussion of concerns that the name MedicationRequest doesn't make sense from a business perspective, but when plans and recommendations are included, it may make sense
    • will be consistent with other resources that are orders
    • Vote: 4/0/2 - Carried
• Discussion on October 24
  • some changes have been made
  • Status discussion
    • propose we keep our definitions
    • add Cancelled to our statuses
    • leave "stopped" in
    • Motion: to add cancelled to our value set and keep our definitions and that we lobby Workflow to make their definitions more generic and add stopped to their value set - Scott-Michelle - 8/0/0

Action:  John to talk to Workflow about making definitions more generic.  November 3 - Follow up - do we have a tracker item, if not, lets create one. No answer from Workflow on this topic. 
Action:  John to talk to Workflow about adding "stopped" to Request status value set.   November 3 - Follow up from John, this needs to be raised in MnM. 

• Discussion on October 27
  • Subject - keep as is - do not add Group at this point
    • change cardinality to 1..1 and add guidance re: anonymized patient
  • Context - currently support Encounter; will add Episode of Care
    • Change name to context
  • requester - currently only reference Practitioner -
    • need to include comments that define the stages that can be done by what type of practitioner.
    • original order must be practitioner
  • performer type - who needs to administer
    • add it with comment - evaluating the use and terminology for this
  • Performer - do not add - would be considered an extension

Motion: by John - seconded by Marla to accept the Oct 27 changes - 5/0/0 carried

• Discussion - October 21
  • Occurence - discussion of use of this to support 1 tablet three times daily for 10 days started on Nov 3, 2016
  • workflow supports a choice for occurrence but the cardinality of 0..1 - need to change that cardinality

Action:  John to talk to Lloyd - completed.  November 3, Lloyd told me we need to follow-up with MnM. 

• Discussion - November 3
  • all changes made except performerType and requester (reference)
  • Discuss whether we need vote again on adding Performer Type to Medication Order resource.

FHIR Tracker Items

• TR#12011 - MedicationStatement - entered in error status
  • need to understand his use case - sent email - no response as of Nov 3

Action:  Melva to reach out to requester - complete

• TR#12175 - special authorization for ordering a drug

Action: reach out to Vince to get more information - concrete examples - Vince will send when back from vacation

• TR#10478
  • Need to update value set to add morning, afternoon, night or change to extensible

Action:  Talk to Lloyd about what it would take to change to extensible - Completed, will follow up with MnM. 

• TR#12201 - option for days on timing
  • Need to update value set to add morning, afternoon, night or change to extensible

Action:  Talk to Lloyd about what it would take to change to extensible - Completed, will follow up with MnM.

• TR#12237 - make dispenseRequest it's own resource

Action:  Reach out to submitter and Tom to see if they can join the call - complete. waiting for feedback from submitter. 

• TR#10389 - adding guidance if you need to include lot number and batch on a dispense
  • discuss

FHIR Workflow Meetings Status

• no further meetings until December, 2016

FHIR Maturity

• Current Maturity status
  • spreadsheet has been submitted - MedicationOrder, MedicationStatement and Medication - MM2
  • review of MedicationStatement Maturity
  • no further need for the resources to get them to MM2
• Update on MedicationDispense implementations

Next meeting

• Monday, November 7, 2016