ImOnFHIR is my personal platform for making healthcare interoperability simpler to understand and more useful in practice. I've been a bedside nurse, a nurse informaticist, a software engineer, a solution architect, an AI strategist, and a patient. I build here for the people who do this work: clinicians, implementers, and the community that keeps the standards moving.
What was asked, where it stands, what happens next and what it changes, across HL7 and FHIR community channels. Newest first; sort or filter to hone in.
Showing 10 of 67 · the newest, plus the latest from each source
Standards discussions and posts, newest activity first: when, source, channel, topic, question, where it stands, next step, impact, specifications, HL7 Jira items and who wrote the summary.
Seventeen publication notices posted with no questions or discussion. Newest two add Domain Analysis Model: Nutrition Care ed. 4 (normative) and SMART Scheduling Links STU 1.0.0. Earlier items include retirement of HL7 V3 RCL R2, FHIR R6 6.0.0-snapshot1, US-PCS 1.0.0 STU, EHRS-FM Release 2.1, CQM 2.0.0 STU, DEQM 1.0.0 STU, and others.
— The summary says nothing here.
The V3 RCL R2 standard is retired, so implementers should no longer rely on it for new work; SMART Scheduling Links STU 1.0.0 and Nutrition Care DAM ed. 4 are newly published.
FHIR R6, US Core, US Patient Care Summary 1.0.0, CDC Opioid CPG Data Exchange Profiles 1.0.0, CDC Opioid CDS 2022.1.1, SDOH Clinical Care 3.0.0, Quality Measures (CQM) 2.0.0, Data Exchange for Quality Measures (DEQM) 1.0.0
1) Are servers expected to support both the direct Resource (Bundle) and Parameters formats for PAS $submit and $inquire requests? 2) For v2.2 $inquire with return 0..*, must servers return Parameters for multiple Bundles and may they return an unwrapped Bundle for exactly one, so clients must handle both?
Agreed
A responder explained the v2.2 rules: $submit response MUST be a bare resource and never Parameters; $inquire response MUST be Parameters unless there is exactly one 'return' parameter of resource type with cardinality 1, in which case a bare resource is both allowed and mandated. Under 2.1 (return 1..1) bare resource was returned for both, so the 0..* change is breaking. For requests, clients may use either form and servers must accept both; the responder considers tightening clients to a singl
The work group triages change request FHIR-59693 to tighten request invocation and clarify response-format documentation in the specification.
Change proposed
Expected: PAS spec documentation will state clearly when bare resource versus Parameters responses apply, and clients may be restricted to one request invocation form, simplifying servers.
Block vote on 24 Bulk Data tickets is planned for the October 14 2026 call. No vote has occurred yet. Listed tickets carry proposed dispositions (e.g. Persuasive, Persuasive with Modification) that are not yet adopted. Any ticket can be pulled from the block before the vote.
The work group votes on the block of Bulk Data tickets at the October 14 2026 call, unless a ticket is pulled beforehand.
Will the work group approve the block of Bulk Data ballot-comment tickets (Persuasive / Persuasive with Modification) at the October 14 2026 call, and which tickets are excluded?
Open question
Block vote set for Oct 14 2026. FHIR-59160 pulled from block at a participant's request and moved to Oct 21 agenda; FHIR-59172 was never in the block. On Oct 9 the proposer pulled FHIR-58835, FHIR-59016, FHIR-58878, FHIR-59015 and FHIR-59148 from the block, with revised resolutions noted (FHIR-58835 to also cover the deleted element in the Export manifest; FHIR-59016 tied to FHIR-58834; FHIR-58878 conflicts with group.md; FHIR-59148 to be broader policy; FHIR-59015 to also address parameter defi
The work group holds the block vote on the remaining tickets at the October 14 2026 call, followed by the agenda items starting with FHIR-58962 includeAssociatedData.
Whether any ticket in the second Bulk Data block vote should be pulled from the block for discussion.
A second block vote of 20 Bulk Data tickets is scheduled for the October 28 call. The post lists nine with proposed dispositions (mostly Persuasive, some Persuasive with Modification, one Considered for Future Use). No vote has taken place yet.
Participants may request that a ticket be pulled from the block; the work group votes on the block at the October 28 call.
Ballot
If the block passes, the listed Bulk Data tickets will be resolved with the proposed dispositions, which may change the Bulk Data specification text.
Links open the source, which asks you to sign in if the discussion needs it. Summaries are written by a model and say so until they are reviewed; they name no one. Updated just now.
