2016-12-08 Rx Conf Call

Related Links Pharmacy Home Page Conference call minutes

Attendees

• Melva Peters (Chair)
• John Hatem
• Michelle Miller

ListServ Discussions

• List Serve Postings

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

FHIR Tracker Items

TR#12409 - MedicationDispense.substitution cardinality

• Proposed change:
  • clean up definition for backbone element from "Deals with substitution of one medicine for another" to ?
  • discussed changing the substitution element to include:
    • add comment at Substitution - "If nothing is specified, substitution was not done." Cardinality remains 0..1
    • wasSubstituted - boolean 1..1 - will not include as a modifier - this element does not change the meaning of the MedicationDispense
    • type - CodeableConcept 0..1
    • reason - CodeableConcept 0..*
    • responsibleParty 0..* - reference(Practitioner)

Action:  Vote on for next call
Action:  Melva to send out an email to Pharmacy

TR#10456 Renaming MedicationOrder to MedicationRequest Discussion

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

• 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
    • Motion to make an update medicationRequest occurrence per list shown in GoToMeeting: Motion: Jose Second: Marla 5:0:0
  • workflow supports a choice for occurrence but the cardinality of 0..1 - need to change that cardinality

Action:  John to talk to Lloyd, FMG

• Discussion - November 14
  • performerType - agreed to add it with comment - evaluating the use and terminology for this - NEED TO DEFINE VALUE SET - LM THINKS THIS IS AN EXTENSION NOT CORE
    • Cerner may be able to use category
    • okay to treat as an extension
    • Motion: John/Michelle to treat performer type as an extension and not add to MedicationRequest - 4-0-0 Carried

• Discussion - November 21
  • Outstanding items
    • occurence[x] - need to refer to MnM
    • requester - need determine stages appropriate for requesters - Proposed:
      • Proposal – Patient, RelatedPerson, Practitioner, Device, Organization
      • Plan – Practitioner, Patient, RelatedPerson
      • Original order – Practitioner
      • Comments received - LM - add device to plan
      • Approved change as above - moved by Jose -seconded by Marla 5-0-0 Carried

• Discussion - November 28
  • Call at 4pm Eastern tomorrow to discuss changes to Timing Datatype for GF#12201, GF#10478, and GF#12352 plus change to Occurrence - need co-chair to attend.
    • TR#10478
      • Need to update value set to add morning, afternoon, night or change to extensible
    • TR#12201 - option for days on timing
      • Need to update value set to add morning, afternoon, night or change to extensible
        • Dec 5 - John provided update on coverage if this item at MnM. That resolution provided the valueset values needed for this change request. ****** Motion to make the mapping changes per the dropbox spreadsheet (all items with X). Marla/Second John:6:0:0

 Action:  Melva also added that we need to create examples for this item as well.

• Discussion - December 5
  • Results from meeting on Nov 29 for GF#12201, GF#10478, and GF#12352
  • Change to Occurrence
    • Dec 5 update:
      • John and Michelle provided update on coverage if GF#12201 from MnM meeting. That resolution provided the valueset values needed for this change request. Melva also added that we need to create examples for this item as well. See GFforge#12201 for valueset items.
      • John and Michelle provided update on coverage if GF#12352 from MnM meeting. See GForge#12352 for details. No further action by Pharmacy
      • GF#10478 - voted on in MnM, committed to build, next action for Pharmacy unknown.
      • group agreed upon changes to Request resource, see "Mapping Med Order to Workflow Request logical model.xlsx in Dropbox for details.

 Action: Melva to make mapping changes to the build for MedicationRequest mappings

• Discussion - December 8
  • Requester - add as a backbone element with agent and onBehalfOf
    • to support the verbal order (where entering on behalf of someone else) - need to add a new element to reference(Practitioner)
    • agent = prescriber
    • onBehalfOf = scoping organization
    • recorder= person who entered the order (on behalf of prescriber)
    • Motion to update the Requester to a backbone element with same definition as currently in Spec and add agent and onBehalfOf and add a new element Recorder to support verbal/phone orders - John/Michelle 2-0-0

TR 12340 - Guidance for Substance abuse

• Michelle Miller introduced on 11/10/16 call.
• should MedicationStatement be used to document substance abuse
• although, substance abuse tracking forms usually have more than can be documented in MedStatement. e.g., desire to quit
• John:
  • classic clipboard at visit, are you taking these meds - each is a MedicationStatement
  • other "active products" - tobacco, alcohol, abusable substances - are handled as observations
• but, if the clipboard asked "do you use illegal substances" ... need support Y/N/no response. This seems to be a MedicationStatement (need to support negation and no answer)
• broader consideration: how to support MedicationStatement negation - is it MedicationStatment.notTaken ?
  • similar to assertions of Condition Absence (see Condition resource ... 9.2.3.5)
  • Note this is in a Zulip chat as "Substance Abuse"
• November 14: Tracker item has been added - need to spend more time on this
  • observation could be used that would support Question/Answer as well for negative statement of use - Questionnaire
  • create an example

Action:  develop some wording about when medicationStatement vs social history could be used as well as create examples (positive and negated) - Melva

Harmonization of Statement with Event

• 11/10/16 brief discussion on mapping MedicationStatement to Workflow Event
• Nov 14, 2016: No discussion
• November 21, 2016: brief discussion - will continue on next call
• November 28, 2016: see spreadsheet
• December 5, 2016: no updates
• December 8, 2016: see updates to spreadsheet and Gforge
  • Status
    • Logical model includes "preparation" - will not add to MedicationStatement
    • No changes to our statuses

GF#12148

• requests common search parameters across resources. One of the requests is for date across medication resources - but the medication resources do not have any common date related search parameters. I would suggest that there should be a 'date' on each of them.
  • MedicationRequest datewritten rename to date
  • MedicationAdministration effective-time - add date with same definition
  • MedicationDispense - whenhandedover rename to date
  • MedicationStatement - add date = MedicationStatement.dateAsserted
  • Some ideas:
    • 1 - I would have thought that when comparing MedicationStatements with MedicationAdministrations and other medication resources, the date of interest was the the 'date of medication use', not the 'date of assertion'. So MedicationStatement's search date should be based on effective.
    • 2 - This would be an opportunity to align the names of MedicationAdministration.effectiveTime[x] and MedicationStatement.effective[x].
    • 3 - The information that can be held by the combined data elements effectiveDateTime and effectivePeriod can also be held by two different data elements date and duration. That design would give a common date data element for searching without adding an extra data element just for searching.
    • Discussed 11/21 call, a common search parameters across resources.

 Action: John to ask Grahame (or someone on FMG) to join our call to discuss this with us.

TR#12011 - MedicationStatement - entered in error status

• concern about the use of the status - of the record and the use of the medication
  • entered in error - is about the record itself
  • perhaps needs a second status to separate out the use of the medication from the record itself - recordStatus vs medicationUseStatus
  • there could be some additional statuses for the record - under review; suspicious
  • historical context - carried over from V3 models
  • PatientCare has split their statuses - clinical status vs verification status - on allergy and conditions
  • need to raise this up to FHIR Infrastructure - to see if there is a pattern that should be used across resources
  • consider updating our definition of the concept for status.
  • Motion: Persuasive with Mod - Update the definition of the status for all resources for what entered in error means - John/Tom - 5-0-0 Carried

Action:  need to create a new tracker item

TR#12175 - special authorization for ordering a drug

Action: reach out to Vince to get more information - concrete examples

TR#12347 - Adjust Medication.package.container value set to SNOMED CT Physical object hierarchy

TR#12347

Action: Melva to followup with tracker item author to ask which valueset she is proposing to use for container - complete

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

Order Service Catalogue PSS

• Update on project meetings