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 3 of 3 (73 before filters) · summarised discussions only
| Question | Next step | Specifications | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| DTR Metric Calculation (opens chat.fhir.org) | Does elapsedTime for DTR Metric #8 run until the QuestionnaireResponse is completed or only until the questionnaire package is returned, and what is the completion point for Standard Questionnaires where the payer may not see QR completion? | Payers are not expected to report elapsedTime for Standard Questionnaires; that metric is produced by the Full DTR client or SMART App, and package response time is measured separately from qrpackage actions. | elapsedTime is defined in the logical model as cumulative user response time from DTR start to QR store, including across sessions, measuring how long users take to fill out the form. Questionnaire-package response time is separate: responseTime minus requestTime on actions with actionDetail qrpackage. For Standard Questionnaires, a payer cannot calculate elapsedTime; only the Full DTR client or SMART App can. | — The summary says nothing here. | Da Vinci DTR | — Cites no HL7 Jira item. | Machine summary · unreviewed · claude-haiku-5-5 · analysed Nov 6, 2026 · inferred | Da Vinci DTR | FHIR Chat | 4 messages this week · 42 hours 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 |
| DTR adaptive questionnaire (opens chat.fhir.org) · chat quiet | Should DTR add guidance that questions no longer applicable are removed from the QR and contained Questionnaire, while prior answers are held and pre-filled if questions reappear? A change request was requested. | If adopted, DTR would state that questions no longer applicable are removed from the QuestionnaireResponse and contained Questionnaire, with prior answers optionally held in memory and pre-filled on re-applicability; no decision yet. | No decision recorded. One participant asked for a DTR change request, saying the guidance should eventually live in SDC but DTR should carry it meanwhile. Another said this relates to FHIR-57904 and that storing the QR directly as FHIR may not support retaining prior answers, so FHIR-57904 wording on work-in-progress may need revisiting. A third said retained prior answers would be in memory only and lost after save and leave. | The requested DTR change request is to be filed and the FHIR-57904 work-in-progress wording may be revisited; neither has been done yet. | Da Vinci DTR, SDC |
| Machine summary · unreviewed · claude-haiku-5-5 · analysed Oct 15, 2026 · inferred | Da Vinci DTR | FHIR Chat | chat quietChat quiet since Oct 5 · FHIR-57904 moved 45 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.