ANSI 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: May 2, 2023

Time: 2PM

Coordinates:  Join Zoom meeting: https://zoom.us/j/5100467805 | Meeting ID: 510 046 7805 | +1 929-436-2866-US (New York)

Attendees

JD Nolen, Elliot Silver, Kathy Walsh, Rob Hausam, Marti Velezis

Chair: JD Nolen

Scribe: Marti Velezis

  • Quorum (Co-Chair + 4) Met 

Agenda

  • Zulip
  • JIRA Tickets - Backlog
  • Next Meeting

LINKS TO JIRA - OO on FHIR DASHBOARDS

Meeting Notes

Zulip Discussions

Coordination: https://chat.fhir.org/#narrow/stream/179256-Orders-and-Observation-WG/topic/Usage.20of.20panel.20of.20Observations

  • Summary: Need to find a time to discuss the usage of Panel of Observations – that is AU friendly time. 
    • Angus Millar and David McKillop "would like to attend a HL7 O&O international teleconference to discuss, but as 2pm US Eastern time (GMT -4) correlates to 4am our time (GMT +10) it would be good to have it scheduled at your convenience."

    • Options: At WGM either Q0 - 7AM CT or Tues/Wed Q5 - 5PM CT; updated the Zulip discussion with these options for David and Angus.

JIRA Trackers for Today

  • Old JIRA review 
  • Outreach - Follow-up
    • FHIR-34491 - Add statusReason in ServiceRequest
      • We initially discussed that we did not see value in adding statusReason as we didn't know what additional value it would bring (esp. with the example of Procedure.statusReason value set)

      • We left a comment to reporter to provide use cases for us to consider
      • Also – could this be used for the next JIRA re: verbal orders??  
      • 4/18 - No further discussion this week - the submitter did not respond to the comments yet.
      • Rob will send Finnie Flores an email to get a response
      • Please try Anne Forsyth (aforsyth@cihi.ca) – she is now the manager of data standards in CIHI and may be able to provide a contact. You may wish to provide her the organ donation context.
      • 4/25 - Marti sent email Anne 
      • 5/2 - Need to take a vote based on CIHI's response: From Shannon O’Connor Canadian Institute for Health Information (CIHI): I’ve followed up with our Organ Donation and Transplant (ODT) team who have confirmed that they do not have a Service Request data element, or anything equivalent. As such, this request is no longer needed and can likely be deemed as Not Persuasive.
      • Added this for 5/4 OO Main call
    • FHIR-34207 - Add attribute to document confirmation
      • We started to discuss this ticket - re: As various orders may be place verbally, a ServiceRequest needs to be able to document that this ServiceRequest confirms a verbal order that may already have been fulfilled, thus not re-initiated.
      • Proposal to add extension
        • The backbone includes .time and .note (Annotation) – and annotation also includes  time.  Need to evaluate how to represent this information. 
      • We also discussed whether or not there was some connection to the status and statusReason
      • No further discussion this week - need to determine need with Hans Buitendijk 
      • Marti Velezis sent email to Hans with request to review this ticket.
      • 4/25 - Marti sent email to Hans 
      • 5/2 - Follow-up from Hans: email dated 2023-04-25  Confirming that the order represents a verbal order does not seem to be appropriate to be covered under a status.  This is not a state progression, rather a source of the documentation perspective.  So I’d pursue 34207 rather than 34491 for verbalOrderConfirmation.  Perhaps the name could be adjusted to something as a source, e.g., just .source and capture the transcriber as well since the requester is in .requester already.  .basedOn is already used to reference a resource and this would not reference a resource, rather document that it was transcribed.  The status of it may be anything ranging from just started to already completed, another reason not to use status.
        • Added to Wednesday Q2 for discussion with PC.  No need to link this with FHIR-34207.

Next Meeting: May 16, 2023 (after the WGM)

-------------Adjourned at 2:30 PM EDT----------------

Backlog

The following are tickets that have action items (waiting for input, assigned to WGM or email outreach) that need to be completed prior to discussing again.

  • FHIR-26674 - ServiceRequest.asNeeded[x] and ServiceRequest.reason
    • FHIR-40765 - Align Request resources' asNeeded and reason (related ticket)
    • Follow-up from Pharmacy Co-chairs - need to update once we receive a response
    • Waiting on feedback from pharma
    • Will chat about this on Friday's catalog call May 5, 2023
  • FHIR-39448  
    • This ticket was reopened after R5 publication
    • We reviewed the previous proposed changes and confirmed that the changes still need to be made
    • Robert Hausam will add to the list of proposed changes if any additional changes are required; and we will discuss next time.
  • FHIR-38985
    • Added to the FHIR-I session at WGM on Thursday Q2
  • FHIR-38833
    • This ticket was reopened after R5 publication
    • Added to the FHIR-I session at WGM on Thursday Q2
    • See if we can get FHIR-I to add another time slot for Rob to participate