Now
Everything moving in the standards community
Discussions and publisher posts from every source the feed publishes, newest first. Each entry links to its source; nothing here is a copy of what was said.
Curated by Nicholas J. Dugan.
Sources
- FHIR Chat — 111 messages this week across 31 feeds · last message 4 hours ago
- HL7 Mailing List — 3 messages this week across 2 feeds · last message 37 hours ago
- HL7 Blog — 1 post this week · last post 3 days ago
Feed checked just now. Counts are the feed's own, for the last seven days.
Specification: 1 of 88
Sources: All
Channels: All
Stage: All
Impact: All
More
Columns: All
Showing 4 of 4 (73 before filters) · summarised discussions only
| Question | Next step | Specifications | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Block Vote 27 (opens chat.fhir.org) | — The summary says nothing here. | Twelve CRD tickets are proposed for block vote approval at the 17 November FM call, which could change CRD content if approved. | A 12-ticket CRD block vote is scheduled for review on the FM call on 17 November. Items can be pulled from the vote by request in the thread, email or direct message. A corrected Jira filter link was posted. | Participants may request that items be pulled from the vote before the FM call on 17 November, and the work group reviews the 12 tickets then. | Da Vinci CRD | — Cites no HL7 Jira item. | Machine summary · unreviewed · claude-haiku-5-5 · analysed Nov 4, 2026 · inferred | Da Vinci CRD | FHIR Chat | 2 messages this week · 3 days ago |
| CRD-inpatient behavioral health with no CPT/HCPCS (opens chat.fhir.org) | For inpatient behavioral health with no CPT/HCPCS, what should the EHR place in ServiceRequest.code in CRD; is an NUBC revenue code acceptable there or should revenue use another path; and how is a level-of-care selection translated into the draft order for pre-service PA? Follow-up asks what sites code today, whether NUBC codes sit in ServiceRequest.code, what works end-to-end, and when to use DT | No specification change is proposed; implementers should expect CRD orders to carry whatever codes the health system already maps, and level-of-care or revenue data may need DTR or mapping setup rather than a new CRD field. | Earlier answer: EMRs do not change ordering when adopting CRD; orders keep existing codes (typically SNOMED or LOINC); payers needing extra data should use DTR; terminology mapping is done by each health system with payers. New messages: a participant summarized takeaways: CRD should not change order entry, US Core does not drive ordering, extra data should come via DTR rather than a new CRD field, and non-CPT/HCPCS services need CRD/PAS mapping setup at each health system. No confirmed pattern | Implementers with live inpatient behavioral health CRD and PAS workflows are asked to share what codes they use today, whether NUBC codes appear in ServiceRequest.code, and example ServiceRequests. | Da Vinci CRD, Da Vinci DTR, Da Vinci PAS, US Core | — Cites no HL7 Jira item. | Machine summary · unreviewed · claude-haiku-5-5 · analysed Nov 4, 2026 · inferred | Da Vinci CRD | FHIR Chat | 7 messages this week · 3 days ago |
| PAS system URL HCPCSReleaseCodeSets (opens chat.fhir.org) | Is the fix limited to the CRD billingCodes ValueSet rather than serviceRequestCodes, and should receivers be required to accept the old https URL during the change? Which CRD/US Core version should carry the change? | CRD billingCodes ValueSet is expected to send the http HCPCS system URL; the version vehicle and whether receivers must also accept the https form are not yet settled. | Earlier answer stands: the authoritative Coding.system is http://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets, and CRD must be corrected. New messages: US Core STU7 billing/procedure value set also uses the https form and is corrected in STU9. Participants agree the corrected URL must be sent. Open points: whether receivers must also accept the old URL, and whether the change goes in CRD 2.2.2 (with a SHOULD-accept note) or waits for 2.3. One participant argues the change belongs in the next | The versioning approach (CRD 2.2.2 versus 2.3, and whether receivers must accept the legacy URL) is to be settled before the technical correction is published. | Da Vinci PAS, Da Vinci CRD, HCPCS Release Code Sets, Da Vinci CRD 2.2.1, Da Vinci CRD 2.2.2, Da Vinci CRD 2.3, US Core STU7, US Core STU9 |
| Machine summary · unreviewed · claude-haiku-5-5 · analysed Oct 21, 2026 · inferred | Da Vinci PAS | FHIR Chat | 11 messages this month · 17 days ago |
| Appointment Book Coverage Information Extension (opens chat.fhir.org) · chat quiet | How should coverage-assertion-id be sent as context when no order is selected, given context is 0..1 but SHALL be included if coverage-information was available? Also whether an Appointment may be DTR launch context, and why QuestionnaireResponse.context is 0..*. | — The summary says nothing here. | Partly clarified: an Appointment can be sent when launching DTR, and the app would retrieve the ServiceRequest if the Appointment is tied to one. QuestionnaireResponse.context is 0..* because one response may apply to several orders while only one order is in context at launch. A participant asked for a change request; FHIR-59401 was submitted for discussion. Not settled: the no-order-selected case for the SHALL on coverage-assertion-id context. No decision recorded. | The work group discusses FHIR-59401 to resolve how coverage-assertion-id context is sent when no order is selected. | Da Vinci CRD, Da Vinci DTR 2.2.0, SMART App Launch |
| Machine summary · unreviewed · claude-haiku-5-5 · analysed Oct 15, 2026 · inferred | Da Vinci CRD | FHIR Chat | chat quietChat quiet since Sep 23 · FHIR-59401 moved 8 days ago |
Links open the source, which asks you to sign in if the discussion needs it. This page shows the newest entries the feed returns, not a complete archive. Summaries, including the Impact sentence, are written by a model from the discussion and say so until they are reviewed; they name no one. Stages, Impact categories and Jira statuses come from the thread and from HL7 Jira, not from a work group's formal record. A discussion whose chat has gone quiet stays listed while its Jira items are open or moving.