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 Notes

JIRA Trackers for Today

• New JIRAs for this week, all of the following are Technical Correction and did not need votes 
  • FHIR-31953 - The guidance btwn R4 and R5 has changed;
    • Added a comment to find out if the updates to the Observation.component in the specification address his concerns.  If not, we asked for suggestions on what needs to be clearer.
  • FHIR-26674 - ServiceRequest.asNeeded[x] and ServiceRequest.reason
    
    • R5 text is still a bit confusing and the group determined that the condition that is reason for ServiceRequest may trigger asNeeded for any of the stated reasons – therefore the codeableConcept option was not needed and may become inconsistent with the reason.
    • Added a disposition as follows: 
      • Remove the choice for asNeeded
      • Keep the boolean datatype
      • Add an invariant so that if Reason is empty, asNeeded must be false
      • Update the definition to indicate that ServiceRequest.asNeeded can be triggered for any of the stated ServiceRequest.reason (s)
      • Provide an example showing how to use asNeeded in conjunction with Reason. 
    • Also need to update: 
      • ServiceRequest.asNeeded[x] terminology binding needs to be removed
    • Added comment to Zulip as follows: 

      • What if we moved asNeededBoolean and asNeededCodeableConcept to be separate elements, change the names to be asNeeded and asNeededFor, respectively, to follow the pattern in Dosage and DeviceRequest?

  • FHIR-32377 - Getting issue details... STATUS
    • Motion to find Not Persuasive because it was determined for R5 to be at FMM4.
    • Marti Velezis / Elliot Silver : 5-0-0
  • FHIR-40499 - Align with workflow patterns and remove instantiates[x]
    • Moved to WGM for discussion on Monday Q3
    • No discussion today about this ticket - as this is something cross resource that needs to be handled across OO Resources.
  • FHIR-40266 -
    • Add to Block Vote - April 2023
    • We will add QuestionnaireResponse as a reference to DiagnosticReport.result along with guidance on the appropriate use.  

-------Adjourned meeting at 3:01PM-----------

Next Meeting: April 11, 2023

Backlog - Did not Discuss -----------------------------

• 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??  
  • No further discussion this week - the submitter did not respond to the comments yet.
• 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