2023-02-21 InM WG Agenda/Minutes

Date: 2023-02-21

Facilitator: @Nick Radov

Note Taker: @Riki Merrick

Attendees

Present	Name	Affiliation
X	Anthony Julian	Mayo Clinic
X	Nick Radov	United Healthcare
	Isaac Vetter	Epic
X	Ulrike Merrick	Vernetzt, LLC
	Craig Newman	Altarum
X	Vassil Petchev	Epic
X	Michelle Barry	Availity

Create Decision from template

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

Agenda Topics

Agenda Outline	Agenda Item	Meeting Minutes from Discussion	Decision Link(if not child)
Management	Quorum Reached (co-chair + 2) Y/N	Yes
Management	Minute Approval
Methodology	MessageHeader.identifier - do we need it?	https://chat.fhir.org/#narrow/stream/179280-fhir.2Finfrastructure-wg/topic/Proposal.20for.20message.20identifier.20issues Relationship between bundle and messageHeader Minimum message is bundle with messageHeader – for a communications ACK You have to make a bundle for each message Batch bundle with entry for each bundle So we should support the bundle.identifier, but no need for a messageHeader.identifier If the snapshot that is the message cannot be maintained in restFUL representation, if you have a purely FHIR server where all resources are stored, so they can be updated – cannot keep the messageHeader resource AFTER the bundle was set So MUST have RESTful persistence of the bundle = similar to V2 messages For intermediaries, when you are forwarding to multiple recipients you should update the bundle.identifier You don’t want to use the bundle.id for the intermediary to change, because the bundle.id can be reassigned by the receiving server – that’s why you need bundle.identifier We only need bundle.identifier - left note on zulip Proposal to suggest to remove FHIR messaging from the specification and write an IG in V2 on how to send a FHIR retrieval result message (ORU with RP in OBX-5 to the FHIR resource(s)) see if we get feedback	We only need bundle.identifier
Methodology	Requirement for response message in FHIR	https://chat.fhir.org/#narrow/stream/179280-fhir.2Finfrastructure-wg/topic/Does.20every.20message.20have.20a.20response.20message.3F FHIR spec is clear for synchronous response For asynchronous response and support for other transport mechanisms to support messaging, MUST have at least one response back to message Require a response message (SHALL) and adapt to the transport mechanism you are using For process message expect an http response of 200 response is ok Must have endpoint defined for those ACKs, so that needs to be included in the initial bundle that is being sent – that is covered Return bundle is 0..1 – maybe to support sending of operationOutcome? There seems to be disconnect between instructions under messaging: https://build.fhir.org/messaging.html and process-message: https://build.fhir.org/messageheader-operation-process-message.html Propose to update the messaging instructions page: https://build.fhir.org/messaging.html and carve out an exception for operation process-message	Propose to update the messaging instructions page: https://build.fhir.org/messaging.html and carve out an exception for operation process-message
Methodology	Gender Harmony Block Vote	These are jiras that have been approved by Gender Harmony group and need the official vote for V2.9.1 ballot will be sent later this week - for voting on March 7th
Methodology	Open FHIR tickets	FHIR-40264 This affects the notifications IG Changes to messageHeader.author / sender / responsible We need sender – for many reasons – at minimum for v2-FHIR Mapping from MSH-4 How would you reference the task for the purpose of identifying the sender/author/responsible? If messageHeader.responsible and messageHeader.author was intended to be used for workflow, then task should be used, but what if that was used for identifying the responsible levels (device / person / role / organization) jira that discusses how to use author, sender and responsible = FHIR-32403 proposed disposition is to move messageHeader.responsible to extension With the content deadline for R5 being 2/24 we need to resolve quickly, if we want to add in R5 - Tony will set up a zulip chat – Riki will review how notifications uses these elements – they are all MUST SUPPORT in the current version of the notifications IG – to know how much impact that would be = https://chat.fhir.org/#narrow/stream/179263-fhir-messages/topic/FHIR-40264
Methodology	Approve errata and publication request RE: V2.9, V2.9.1 MSH-6 repeatability.	NOT DISCUSSED
Management	Next agenda
Adjournment		Adjourned at

Supporting Documents

Outline Reference

Supporting Document

Minute Approval

Approve errata and publication request RE: V2.9, V2.9.1

MSH-6 repeatability.

HL7 Version 2.9 Technical Correction Publication Request

V2-25489 - Getting issue details... STATUS

Draft errata letter

20230216-V29-chapter2-CSDO_Errata_Letter.docx

V2 unresolved issues filter

T	Key	Summary	Assignee	Reporter	P	Status	Resolution	Created	Updated	Due

Loading...

Refresh

InM unresolved FHIR issues

T	Key	Summary	Assignee	Reporter	P	Status	Resolution	Created	Updated	Due