2016-10-03 Rx Conf Call

Related Links Pharmacy Home Page Conference call minutes

Attendees

• Marla Albitz
• John Hatem
• Ken Sinn
• Michelle Miller
• Scott Robertson (scribe)
• Yunwei Wang
• Melva Peters

ListServ / Zulip Discussions

• List Serve Postings
  • no ListServ or Zulip items noted

FHIR Maturity DEFERRED

• Current Maturity status
  • spreadsheet has been submitted - MedicationOrder, MedicationStatement and Medication - MM2
  • review of MedicationStatement Maturity
• no further needed for the resources to get them to MM2
• Discuss in Baltimore about getting to MM3

 COMPLETED Action Item: Melva will look at the FMM spreadsheet to identify which FMM 3 items the Rx resources are needed.  Melva will enter one or more GForge items to address FMM3 in before the ballot close.

FHIR Discussion Items

• Revisit deferred GForge items: Determine if should be changed to triage for consideration now.
  • • deadline is December for any changes to be included in publication
    • doing a quick pass to see if we want to move to triage ... then look at one or two in detail (as time permits)
  • 5827 Should medication have a status code?
    • Melva - we need to deal with this ... but may not be enough time with December deadline
    • John - this is related to a discussion in O&O ... we should bring it out to discuss (can be re-deferred if necessary). Will depend to some degree on what comes out of the O&O discussion.
  • 7562 2015May core #853 - Expand description and usage of Medication.code.display
    • Marla thinks that some narrative was added, or that the narrative is available.
    • agree to bring out of deferred and assess what can or needs to be said
  • 7641 2015May core #932 - Look at moving extensions to core
    • need to review, some of these extensions may already be in core. move out of deferred
  • 7747 2015May core #1038 - How can we address this requirement, which is supported in HL7 v2 and is a common use case in building our Medication Administration Record systems?
    • John - there is a way to deal with this now. Move out of deferred
  • 7830 2015May core #1152 - Add RXD
    • Marla - know the work needed. Move out of deferred
  • 7910 2015May core #1230 - Decouple active medication list from medication statement (compliance / wasNotGiven)
    • from Cerner. Med Statement is a mix of patient reported, compliance info, etc. move out of deferred ... at least to discuss
  • 8489 Medication related indicators - maintenance drug, over the counter
    • may be able to incorporate with formulary discussion. move out of dieferred
  • 10066 Should route and site be inside dosage instruction line?
    • pull out to triage status
  • 10577 Adding image of the drug or medicine to Medication Resource
    • may be related to formulary discussion ... but may get deferred again

• • Motion - move all items to triage (John/Michell) 8-0-0

Vote for reaffirmation of PSS

• HL7 Pharmacy Knowledge Base Query Reaffirmation PSS
  • Motion to Approve (Melva/John) 8-0-0 - Passed

CDS Request DEFERRED

• Background
  • The CDS Work Group as part of reconciling ballot comments for the CQF-on-FHIR Ballot has created a resource in FHIR that can be used to describe "templates" for intent resources like MedicationOrder, ProcedureRequest, etc. The resource is called ActivityDefinition (https://hl7-fhir.github.io/activitydefinition.html).
  • As part of specifying the template for a MedicationOrder, we need to be able to specify the dosageInstruction and dispenseRequest elements. Rather than copying the element from the MedicationOrder resource definition, we are planning on defining a DosageInstruction and a DispenseRequest type that we could reference, rather than duplicating the maintenance of those elements.
  • Do you have any questions or concerns with this approach? The initial step is just to define the data types based on the MedicationOrder structure and will not involve any changes to the MedicationOrder resource.
  • Pharmacy WG has some concerns about the fact that CDS may be creating
• July 18 Update
  • more info see CDS Pharmacy FHIR request
  • suggestion that a datatype may be an option but that it will not be done it time for the freeze for STU3 - would need special permission to put a substantive change in to the release
  • continue to discuss on our teleconferences and possibly include time on the agenda for Baltimore
• Information from Lee for discussion on August 29
  • Regarding my specific interest, I'm sure you are familiar with the NCCN Chemotherapy Order Template use case by now. We have implemented an initial version of an authoring system and I plan to bring it to Baltimore. The current implementation actually exports Order Templates as a FHIR Bundle that contains a PlanDefinition.
  • For the individual "Regimen Entries" of the order template, we are currently using the ActivityDefinition resource because MedicationOrder was deemed to be a 'Request' resource and so we were advised not to use it in this 'Definitional' space.
  • The problem with this is that ActivityDefinition is very generic and so it doesn't have many of the dosageInstruction fields that you have in the MedicationOrder (a number of which I even helped to get added). This means that we must use extensions for all that. This might be OK, but there are also further complications such as the issue I opened at How to support definitional MedicationOrder with multiple dosageInstruction? (10433)
  • Basically, because we'd like to specify at least the core details of a MedicationOrder in the defined fields of the ActivityDefinition resource (fields like 'quantity' and 'product'), it means that we need to add an extra level of nesting into our structure so that each DosageInstruction becomes its own ActivityDefinition. In this case, I have concerns about the fact we are making our already complicated structure one level deeper and also, more importantly, I'm not sure that it is feasible for anyone to implement the logic that would be necessary to 'place' those dosageInstruction ActivityDefinitions into a single MedicationOrder.
  • One proposal for dealing with this is for Pharmacy to define a re-usable type for 'dosageInstruction' that could be re-used (hopefully with 0..* cardinality) in the ActivityDefinition resource in order to better align ActivityDefinition with MedicationOrder and also keep the two in sync going forward. My understanding is that this was discussed with Bryn in the past, but unfortunately I missed that conversation.
  • An alternative idea that I had is to have a separate resource that is specifically focused on MedicationOrder 'templates' in the definitional space (although it seems I'm the only one advocating for that).
  • Anyway, I'm sure Bryn has his own take on all of this, and so I'm mostly just trying to join the conversation to see where things are headed in order to align our implementation to the likely direction of the spec (or chose not to). For example, if we know there is broad support for introducing dosageInstruction to the ActivityDefinition, then we can define extensions that look just like it...or we could even help to get that change into the FHIR build and hopefully we could use some generated stubs in our implementation.
  • Discussion - August 29th -
    • CDS - PlanDefinition Resource - good fit for a regimen or plan definition that can relate multiple medication orders together
    • MedicationOrder is not really intended to be an order template - originally Pharmacy had thought that MedicationOrder could be used for the definitional space
    • Have had a previous discussion about requirement for a DosageInstruction datatype that could be reused
    • CDS want to reuse specifications from domain areas - such as MedicationOrder
      • may need more than DosageInstruction datatype - possibly DispenseRequest
    • proposal from CDS - take DosageInstruction element - and make it re-usable - make it a datatype - would see a single element in the resources
    • Task is to take DosageInstruction - turn it in to a "type" - this didn't cause an issue for Pharmacy, but there is a potential concern about the other content of a MedicationOrder that may or may not be included in a PlanDefinition
    • would be helpful to create a pharmacy specific example that would show where the different data elements exist - there is a low risk suicide example that could be used
    • Concern raised by Lee: when it comes time to place the order - there is a mapping that needs to happen from generic activityDefinition to medicationOrder - from generic concepts to specific concepts.

Completed Action: example from Lee to help to elaborate - with current build and desired outcome - Lee to also include what should be included if there was a DosageInstruction type.  Also include other changes that are needed - some extensions are included that might need to be considered by Pharmacy WG
Completed Action: Do a map from the PlanDefinition and ActivityDefinition to the MedicationOrder - concrete examples
Action:  Based on feedback and further discussion from examples - Pharmacy will create DosageInstruction and DispenseRequest types - needs a motion and vote - could pilot it with other resources

• Completed - Planned Discussion - September 12th
  • review examples from Lee and vote on creating new types
  • 9/12 Lee walked us through the samples he produced
• there is consensus on the call to designate DosageInstruction element as a "type", but will motion and vote on it in Baltimore next week.

Renaming MedicationOrder to MedicationRequest Discussion DEFERRED

• 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

DUR DEFFERED

• Consider the addition of DUR (Device Utilization Review) to Pharmacy resources

 Action:  Ken will create a narrative that defines and provides an overview of DUR to serve as the basis for a larger discussion with external workgroups.

Next meeting

• Monday, September 19th Q3 in Baltimore - Safe travels!