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).
Date: April 11, 2023
Coordinates: Join Zoom meeting: https://zoom.us/j/5100467805 | Meeting ID: 510 046 7805 | +1 929-436-2866-US (New York)
JD Nolen, Rob Hausam, Kathy Walsh, David Barwin, Yanick Gaudet, Marti Velezis
Co-chair: JD Nolen
Scribe: Marti Velezis
- Quorum (Co-Chair + 4) Met
- JIRA Tickets - Backlog
- Next Meeting
LINKS TO JIRA - OO on FHIR DASHBOARDS
- OO on FHIR Dashboard - Includes all resources related to OO on FHIR
JIRA Trackers for Today
- FHIR-26674 - ServiceRequest.asNeeded[x] and ServiceRequest.reason
Follow-up on Zulip discussion
- Proposed Disposition:
1. Make asNeededBoolean and asNeededCodeableConcept separate elements, change the names to be asNeeded (0..1) and asNeededFor (0..*), respectively, to follow the pattern in Dosage and DeviceRequest
2. Add this invariant: "AsNeededFor can only be set if AsNeeded is empty or true"
3. Update definitions to reflect the changes in the elements
4. Provide examples showing how to use asNeeded/AsNeededFor
1. An example showing asNeeded and asNeededFor being used with Reason
2. An example showing asNeeded and asNeededFor without Reason
3. An example showing asNeeded without Reason
- order - test glucose or exercise
- reason - diabetic
- asNeededFor - glucose level
- 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/11 - 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
- 4/11 - No further discussion this week - need to determine need with Hans Buitendijk
-------Adjourned meeting at -----------
Next Meeting: April 18, 2023