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 68 · the newest, plus the latest from each source
Standards discussions and posts, newest activity first: topic, channel, source, date of last activity, question, where it stands, next step, impact, specifications, HL7 Jira items and who wrote the summary.
Can a payer convert a numeric CPT code submitted in PAS to a custom CPT code and report that custom code under addItem in the ClaimResponse?
Answered
Responders: if the custom code is a real CPT code that differs from the one requested, it can be reported in addItem. A wholly custom code is not workable: validation fails for a non-real CPT code, and using the CPT system URL for an illegal code makes the instance non-conformant. Earlier item mapping outcome (A1/A6/A3 with addItem) is unchanged.
— The summary says nothing here.
Clarification
Implementers may report a different real CPT code in addItem when it differs from the requested code, but not a non-CPT custom code under the CPT system URL.
Is it compliant for a CRD response to return only a context identifier (coverage-assertion-id) for DTR rather than a questionnaire or policy URL, and how does a non-payer DTR app resolve it?
Answered
A CRD response need only point to the form to be filled out; no policy URL is required (detail.value may optionally point to one). CRD need not name specific Questionnaires; DTR determines forms. With CRD supported, EMRs should always call DTR with a context id; DTR can be launched without CRD in phased deployments. Each payer has one DTR server, which is the payer's responsibility. The DTR app never resolves context to questionnaires itself; the DTR client calls $questionnaire-package on the pa
— The summary says nothing here.
Clarification
— The summary says nothing here.
Da Vinci CRD, Da Vinci DTR, SMART Backend Services
Is the incorrect "unable to determine system" report still a problem with the complete guide, given the August workaround that removed the primitive binding?
Answered
Implementer says the original failure came from binding PhdUnitCodeVS to the primitive origin.code, which receives a bare code and cannot resolve system. Tested on validator 7.0.2 with R5 and R6 ballot5 synthetic code systems: Quantity-level binding gives zero errors for qualified codes, unknown codes and missing systems still fail. The August workaround already removed the primitive binding, so the current downloaded profile is not a current failure. Mixed-system value set would need the Quanti
Not stated in the thread; the IG authors would need to decide whether to retain the mixed-system value set using the Quantity-level binding.
Change proposed
Proposed: Observation.value[x].origin would carry the required binding to PhdUnitCodeVS in place of the origin.code binding, if the mixed-system value set is retained. Current guide already has the primitive binding removed.
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.
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
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.
