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 Details

Date: October 2, 2023

Time: 3PM ET

Coordinates:  Join Zoom meeting: | Meeting ID: 510 046 7805 | +1 929-436-2866-US (New York)




  • Quorum (Co-Chair + 4) Met 


  • Administrative 
  • JIRA Tickets
  • AOB
  • Next Meeting


HCP_Backlog - FOR REVIEW (includes Nutrition resources)

HCP_Ballot Related - JIRA that need to be completed by R5 (many of these are related to Normative content)

HCP_Work In Progress - Items that need to be updated in the build and/or QA for completion

Module Pages

The following are draft pages to organize and author content for each of our health care product resources: 


Upcoming Topics/Due Dates

October 2
October 9
October 16
October 23
October 30

Action Items

Instructions: Type your task here, using "@" to assign to a user and "//" to select a due date

Action Item


  • Administrative

  • JIRA tickets
    • BDP 
      • Service Request tickets that relevant to the current BDP backlog

        • Reference:
        • 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.  Paul provided an attachment in the JIRA with the two resource draft, while Jose updated a one resource with profile draft in a build branch.
        • Option 1 can support the use case (would require including in the draft explicit reference from Receipt to Dispatch), but it is not clear what other stages would be of interest.  If there is a need to document handoffs-waypoints more detailed than simple status updated on the Dispatch or Receipt, that seems to be able to be done with multiple Dispatch and Receipt pairs.  Discussions on being able to send notices to the receiver on status/stage could be associated with the Dispatch and does not seem to require a separate stage.  The main challenge is therefore why to have this level of flexibility when GS1 only has two as well and the use cases so far do not clearly indicate a need for more stages.  At the same time, when splitting the flow into more stages could make queries for different state in the flow easier.
        • Option 2 also supports the use case, but does not have the flexibility to expand on the stages as that would require adding new resources.  It would be easier to document the different relevant operational statuses specific to each resource.  Queries for a state based on statuses or other details that would now be within a resource rather than a separate stage would be harder.
        • Either way, an overall tracking identifier can be associated with all relevant resource instances, while in either case we still have to determine when in the flow ownership changes from the sender to the receiver as that is not always completion of receipt, e.g., in multiple hops there may be documentation of receipts but the ownership remains with the sender until the "last" receipt is "complete".
        • There is no interest in a single resource without profiles as that would mix ownership of the resource instance between the sender and receiver.
        • Jose will aim to identify sample stages that could be of interest to more dynamicaly add as needed.
      • 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.

Review follow-up from: 

  • Added to September 2023 WGM – Need to see if these are addressed.
    • Need to work with DEV group on the following: 
      • FHIR-40291 -Update the device specification example valueset to cover additional uses
        • Updated with action item to be completed by October 16, 2023
      • FHIR-41413 - Need to bring to DEV
          • Recommendation is to Remove Patient and RelatedPerson if DEV is ok with that resolution
          • If so - this could be a new JIRA
        • See notes on Families/Households/Workplace/Events


  • 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

From the Chat


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


  • TBD

  • FHIR-32756 - request-insurance extension needs more context given in the description
  • Waiting for Jose Costa-Teixeira  to respond to comments; this should be included in a future call (August 8 or 15)
  • FHIR-19516 - Substantive workflow changes for OO resources
  • Needs to be assigned (Status = Resolved Change Required)
  • TBD

  • TBD


  • FHIR-40384
    • Need to distinguish device-created from transcribed observations
    • General sense that this is a valuable attribute, whether as extension or core element.
    • Rather than taking one element at a time, would like to address together with other device-observation attributes.
    • Also need to consider whether we need to distinguish electronic without user verification/acceptance or with, which is not the same as fully transcribed.
  • FHIR-40335 
    • Clarify use of Observation.subject, .device, and .focus for devices
    • To be discussed with Device Module
  • Device/Device Definition Mapping 
  • Pending additional review
  • FHIR-31750 - Complement Valueset-identifier-type for Device identifiers 

  • Approved; Updating UP-232
  • Examples
  • Search Parameters
  • Mappings (TBD)
  • Need to complete work on Device Definition to make it consistent with or address variations from Device resource
  • TBD


  • FHIR-26429  - Consider adding extension to allow fuzzy timing for DeviceRequest.occurrence

  • Note - Robert Hausam there is an outstanding question in comments for you - also see under Service Request.

  • Need update from OO on FHIR

  • FHIR-26948 - Create examples for prosthetics (e.g. glasses, lenses) in DeviceRequest; Comment added for Jose - Pending
  • See topic below (Device Request and VisionPrescription)
  • Device Request and VisionPrescription (see below)

  • FHIR-11217
    • Amendment: Address where VisionPrescription should be referenced in DeviceRequest in a separate JIRA ticket; which will expand the discussion around custom devices
    • Action: In HCP we will work through the wording.
  • Discussed at May 2023 WGM
  • Need to work on this in committee
  • Will be kept open until UDI IG has addressed these and can confirm it covers it.
  • FHIR-34491 - Add statusReason in ServiceRequest

  • FHIR-40631
    • Some OO requests need basedOn to RequestOrchestration
    • NutritionOrder (was NutritionRequest), ServiceRequest (Diagnostic/Procedure/ReferralRequest), VisionPrescription

  • FHIR-38818 - Clarify SupplyDelivery for shipment vs reception

Product Pattern
  • Need Jose Costa-Teixeira and Carl Leitner on the call.
  • Is there a benefit to have definition for BDP, in blood bank with ordering is one (and maybe only example).