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 36 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
Sources: All
Channels: All
Stage: All
Impact: All
More
Columns: All
Showing 8 of 8 (73 before filters) · summarised discussions only
| Question | Next step | Specifications | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| PAS IG ClaimResponse.addItem.itemSequence cardinality (opens chat.fhir.org) | Is the PAS IG's intended cardinality for ClaimResponse.addItem.itemSequence 1..1 or 1..*, and why is it an array rather than a positiveInt? | No change to the specification is indicated; implementers should treat itemSequence as an array constrained to at most one item, consistent with base R4 ClaimResponse. | A respondent said itemSequence is an array in the base FHIR definition, constrained in the profile to a maximum of one member. Asked why it is not a simple positiveInt, the respondent said FHIR resource schemas are fixed across all use cases, so if an element is an array anywhere it is an array everywhere, which lets systems process instances in a use-case-independent way. This is a common pattern across Da Vinci IGs. No formal decision or change to the profile was recorded. | — The summary says nothing here. | Da Vinci PAS, FHIR R4 ClaimResponse | — Cites no HL7 Jira item. | Machine summary · unreviewed · claude-haiku-5-5 · analysed Nov 7, 2026 · inferred | Da Vinci PAS | FHIR Chat | 4 messages this week · 33 hours ago |
| Prior Auth Inquiry – Patient Identifier Type (MB) (opens chat.fhir.org) | Is the MB identifier type expected to be mandatory on the Patient resource for Prior Auth Inquiries, and should the Beneficiary Patient profile explicitly reflect that requirement? | If the correction is made, the PAS IG text would place the MB member identifier on Coverage rather than requiring it on Patient.identifier, changing where implementers look for it. | A respondent says the earlier statement is incorrect: the member identifier is found on Coverage, not on Patient. A Jira item is requested so the IG text can be corrected. No Jira key yet given. | A Jira item is to be submitted so the PAS IG text can be corrected. | Da Vinci PAS | — Cites no HL7 Jira item. | Machine summary · unreviewed · claude-haiku-5-5 · analysed Nov 7, 2026 · inferred | Da Vinci PAS | FHIR Chat | 2 messages this week · 33 hours ago |
| coverage-info on adaptive QR, pre-2.2 (opens chat.fhir.org) | Does DTR 2.2 support an adaptive selector Questionnaire that identifies separate clinical Questionnaires for later completion, including when $questionnaire-package is called without CRD or coverage-information, before filing a Jira request? A participant also asked where the spec-43 text originated. | — The summary says nothing here. | Responding participant explained the intended flow: the selector Questionnaire must be used as clinical evidence, 'S' is supplemented rather than replaced, and forms are retrieved via $questionnaire-package using coverage-assertion-id or the resource plus related resources. Users choose which forms to complete. A participant traced the spec-43 text to the STU 2.0.0 DTR formal specification, introduced in an August 2023 overhaul tracked under FHIR-41854; no ticket with the exact wording found yet | The search for the originating tracker for spec-43 continues, and the work group or other implementers are expected to confirm whether DTR 2.2 supports the handoff without CRD or coverage-information. | Da Vinci DTR 2.2, Da Vinci DTR STU 2.0.0, Da Vinci PAS |
| Machine summary · unreviewed · claude-haiku-5-5 · analysed Nov 6, 2026 · inferred | Da Vinci DTR | FHIR Chat | 4 messages this week · 37 hours ago |
| PAS ClaimResponse – TransmissionIdentifiers (opens chat.fhir.org) | Should the PAS ClaimResponse TransmissionIdentifiers (interchangeSenderID/interchangeReceiverID) follow the X12 ISA06/ISA08 direction convention with payer as sender, or be retained as-is from the original PAS request? | — The summary says nothing here. | No answer yet. The question has been posted; no reply in the thread. | A reply from the work group or IG authors is expected to confirm the expected TransmissionIdentifiers behaviour on the ClaimResponse. | Da Vinci PAS | — Cites no HL7 Jira item. | Machine summary · unreviewed · claude-haiku-5-5 · analysed Nov 4, 2026 · inferred | Da Vinci PAS | FHIR Chat | 1 message 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 |
| PAS Claim.Identifier.System (opens chat.fhir.org) | In the Claim resource, would there always be one identifier with system value urn:trnorg:<TRN03>? Why is the maximum Claim.identifier cardinality 2? | Receivers should accept one or two Claim identifiers and should not reject a Claim whose identifier system is not urn:trnorg, per the SHOULD wording; the TRN-mapping rationale is explained but no change to the standard is proposed. | Per a reply citing the published PAS 2.2.1 package: Claim.identifier is 1..2 (unsliced) in profile-claim and profile-claim-update, and 1..1 in profile-claim-inquiry. Claim.identifier.system is 1..1 with a SHOULD to use urn:trnorg:<TRN03> for the TRN. A later reply from the IG side says Claim.identifier maps to the X12 TRN segment (as does ClaimResponse.identifier). The maximum of 2 comes from X12, which allows an originating claim TRN plus one added by any clearinghouse. A SHALL was considered, | — The summary says nothing here. | Da Vinci PAS, Da Vinci PAS 2.2.1, X12 278 | — Cites no HL7 Jira item. | Machine summary · unreviewed · claude-haiku-5-5 · analysed Nov 2, 2026 · inferred | Da Vinci PAS | FHIR Chat | 3 messages this week · 5 days ago |
| PAS Claim Update - updated claim status (opens chat.fhir.org) · chat quiet | None stated. The thread holds only bare links to a Jira ticket, with no question or explanation. | — The summary says nothing here. | No answer or decision. A participant posted the FHIR-59555 link again without comment. The ticket's content is not in the thread, so its status and any resulting change are unknown. | — The summary says nothing here. | Da Vinci PAS |
| Machine summary · unreviewed · claude-haiku-5-5 · analysed Oct 15, 2026 · inferred | Da Vinci PAS | FHIR Chat | chat quietChat quiet since Oct 6 · FHIR-59555 moved 19 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.