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 5 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 4 minutes ago. Counts are the feed's own, for the last seven days.

Specification: 1 of 88
Specification
Sources: All
Sources
Channels: All
Channels
Stage: All
Stage
Impact: All
Impact
More
More filters
Columns: All
Columns

Showing 1 of 1 (73 before filters) · summarised discussions only

Discussions and posts: topic, channel, source, date of last activity, question, where it stands, next step, impact, specifications, HL7 Jira items and who wrote the summary.
QuestionNext stepSpecifications
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?
Change proposed
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
Open question
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
  • FHIR-59699 (Resolved - change required) · jira verified Nov 8, 2026
    1. Discussed (reached)
    2. Filed (reached)
    3. Triaged (reached)
    4. Resolved (reached)
    5. Applied (not yet)
    6. Published (not yet)
Machine summary · unreviewed · claude-haiku-5-5 · analysed Oct 21, 2026 · inferredDa Vinci CRDFHIR Chat5 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.