Anti-Trust Policy:  Professional Associations, such as HL7, which bring together competing entities are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 meetings and conferences, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust Policy as stated in §05.01 of the Governance and Operations Manual (GOM).

MEETING MINUTES

• Administrative
  • Next week labor day - no meeting
  • Week after HL7 WGM - no meeting
    • OO WGM 202309 - Agenda
  • September 18 - re-cap WGM
  • September 25 - resume JIRAs and work items
• JIRA tickets
  • BDP 

    • Service Request tickets that relevant to the current BDP backlog

      • https://jira.hl7.org/browse/FHIR-38818
      • Reference: https://github.com/IHE/pharm-supply/blob/master/input/fsh/delivery.fsh#L11
      • SupplyDelivery should be profiled (one above) for shipped and received; and an additional elements to described
      • Need to show direct linkage between what is requested, shipped and received.
      • We will resume the discussion next time and work on how this should look to reconcile concerns raised in the JIRA ticket for accounting for all products shipped and received.
      • Suggestion to not mix the dispatch and the receipt/reconciliation in one SupplyDelivery resource, rather to have two resources SupplyDispatch and SupplyReceipt.
      • How does that sync with pharmacy?  Also noting that "dispense" is a different concept than "shipping" as "dispense" does not involve the physical movement that a "shipment" would help manage.
      • We clarified that MedicationDispense is also just focused on "assigned to a patient" and any transportation would be a separate from the dispense.
      • Option 1:
        • Keep SupplyDelivery and add .stage(dispatch|receipt), enhance status for appropriate values for each stage and add a reference from receipt to dispatch.
      • Option 2:
        • Split SupplyDelivery into SupplyDispatch and SupplyReceipt and include SupplyDispatch a reference to SupplyReceipt.  Possibly remove an attribute that is not applicable to the resource at hand.
      • Paul and John to prep a list on attributes that are applicable for Receipt vs. Dispatch based on which we can then determine whether that points to using a single resource with two stages, or two resources.
      • Will continue the discussion in two weeks or as soon as ready thereafter.
      • http://build.fhir.org/ig/IHE/pharm-supply/StructureDefinition-ihe-supply-receipt-notice.html
      • http://build.fhir.org/ig/IHE/pharm-supply/StructureDefinition-ihe-supply-shipment-notice.html
    • Reviewed the statement "assigned to a specific patient" as it appears to be missing a level of clearance and/or authorization that this can be dispensed. 
      • One argument is that the original order (ServiceRequest) provides the authorization is there (akin to MedicationRequest).
      • Another argument is that there be an explicit clearance/authorization on the dispense as the order may be for "a red blood cell", but the dispense is about "this red blood cell" that must have been cleared/authorized to be appropriate for the specific patient.  All BDP follow that same pattern.
      • Perhaps to define "the dispensed product" (represented by BDPDispense) is "the product approved and assigned to a specific patient (usually in response to a service request)."  Then the verb "dispense" would be "approve and assign to a specific patient".  Note that the approval could have been in place as part of the originating service request, or as part of the dispense process because the service request was not explicit enough, but in either case the key is that at the time of completing the dispense any necessary approvals must be there.
      • Need to confirm that the statuses reflect that upon a certain status this definition is fully in effect.  Currently, the BDPDispense.status implies the product can be "dispensed" before approval for release.
  •  
    • https://jira.hl7.org/browse/FHIR-41872 - 

• • Other ServiceRequest tickets:
    • FHIR-34194 -Add businessEvent extension
    • FHIR-34205 -Add ServiceRequest.status values
      • Has disposition – more discussion needed?
      • Does it need larger review ?  If yes -- suggest adding it to block vote (if yes - add grouping = "OO-FHIR-Block-Vote" and "August-2023"?
    • FHIR-34207 -Add attribute to document confirmation
      • Has disposition – more discussion needed? 
      • Does it need larger review ?  If yes -- suggest adding it to block vote (if yes - add grouping = "OO-FHIR-Block-Vote" and "August-2023"?
    • FHIR-31589 -Clarify ServiceRequest.supportingInfo can't be 'questions'
  • Device
    • FHIR-41597 -codeableReferences in DeviceDefinition missing valueset bindings
    • FHIR-40289 -Solve device conformance to standard "options"
  • Procedure (from Pt Care)
    • FHIR-33390

Any follow-up from: 

• Need to work with DEV group on the following: 
  • FHIR-40291 -Update the device specification example valueset to cover additional uses
  • FHIR-41413 - Need to bring to DEV
    • DeviceDispense.performer.actor
      • Recommendation is to Remove Patient and RelatedPerson if DEV is ok with that resolution
      • If so - this could be a new JIRA

From the Chat
 
David Barwin to Everyone (Aug 28, 2023, 3:03 PM)
https://jira.hl7.org/browse/FHIR-41872
Can we add this to BDP agenda
 
Jose Costa Teixeira to Everyone (Aug 28, 2023, 3:54 PM)
http://build.fhir.org/ig/IHE/pharm-supply/StructureDefinition-ihe-supply-receipt-notice.html
http://build.fhir.org/ig/IHE/pharm-supply/StructureDefinition-ihe-supply-shipment-notice.html
 
John Hatem to Everyone (Aug 28, 2023, 3:54 PM)
I need to prepare for my next call.  Will follow the work.  John

INVENTORY BACKLOG

Note these are issues that we did not have time to discuss, or already have been discussed, but may not be ready for disposition (i.e., waiting for input or additional work needs to be completed).