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 2 of 2 (73 before filters) · summarised discussions only
| Question | Next step | Specifications | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| billing-options extension context and profile mismatches (opens chat.fhir.org) | Which is correct for the billing-options extension location: the extension context (CommunicationRequest.payload.content; VisionPrescription.lensSpecification.product) or the profile paths (CommunicationRequest.payload; VisionPrescription.lensSpecification)? Where should it appear for Device and NutritionOrder? | Proposed: the billing-options extension placement in CRD 2.2.1 may be corrected for CommunicationRequest and VisionPrescription to the payload and product CodeableConcept levels; Device placement is still disputed and NutritionOrder is undetermined. Adding an explicit dataAbsentReason allowance on p | Earlier respondent view: extension sits on value[x] of CommunicationRequest payload; on VisionPrescription lensSpecification product CodeableConcept; Device context should be Device.codeCodeableConcept; NutritionOrder placement unresolved. A follow-up participant argues the Device profile already has the extension at root matching the context of use, and that DeviceRequest has it under codeCodeableConcept, which matches context of use; they say their must-support tests pass. A new reply confirms | The work group reviews FHIR-59699 and the open CommunicationRequest and Device placement questions. | Da Vinci CRD 2.2.1, Da Vinci CRD 2.2.1 DeviceRequest profile |
| Machine summary · unreviewed · claude-haiku-5-5 · analysed Oct 21, 2026 · inferred | Da Vinci CRD | FHIR Chat | 5 messages this month · 17 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 |
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.