Da Vinci Payer Data Exchange
2.2.0 - STU 2.2
US
Da Vinci Payer Data Exchange
2.2.0 - STU 2.2
US
Da Vinci Payer Data Exchange, published by HL7 International / Financial Management. This guide is not an authorized publication; it is the continuous build for version 2.2.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-epdx/ and changes regularly. See the Directory of published versions
| Page standards status: Informative |
Previous Page - Member-Authorized OAuth2 Exchange
| JIRA Ticket | Change |
|---|---|
| FHIR-56546 | Link to output parameters profile from operation definition profile |
| TC: FHIR-56455 | Provider-Member-Match OperationDefinition: removed redundant/incorrect sentence from the bottom of the rendered page stating that the returned Group resources can be used as input to $davinci-data-export for bulk member matching and member health history retrieval. Not all of the returned Group resources (NonMatchedMembers, ConsentConstrainedMembers) are used to retrieve member data, so the statement was misleading. The remaining comment text describing the response Parameters profile structure (MatchedMembers / NonMatchedMembers / ConsentConstrainedMembers slices) is retained |
| TC: FHIR-56454 | Provider-Member-Match OperationDefinition Description: reworded "This operation aligns with the Payer-to-Payer Bulk Member Match but is designed for provider-initiated requests" to "This operation is functionally similar to the Payer-to-Payer Bulk Member Match operation but is designed for provider-initiated requests" for clarity |
| TC: FHIR-56445 | Data Mapping → Ingesting Exchanged Data §7.6 step 5: corrected "Use the Target Organization Resource ID for any references to this Location" to "Use the Target Location Resource ID for any references to this Location" |
| TC: FHIR-56434 | Introduction §3.7.1.3 (US Core Profiles, STU6 - 6.1.0): inserted missing / separator in the link to the USCore Condition Problems and Health Concerns Profile so it resolves to …/STU6.1/StructureDefinition-… rather than …/STU6.1StructureDefinition-…. The identical defect on the parallel STU7 - 7.0.0 list entry was also corrected |
| TC: FHIR-56425 | PDex provider-access Server CapabilityStatement (FHIR Artifacts §14.0.1): copy-paste error in the opening sentence of the Description corrected. "PDex Payer-to-Payer API Server actor … queries submitted by PDex Payer-to-Payer Requestors" replaced with "PDex Provider Access API Server actor … queries submitted by PDex Provider Access Clients" so the description aligns with the rest of the paragraph and with the Provider Access actor it describes |
| FHIR-56380 | Persuasive with Modification. The submitter observed that the PDex Prior Authorization profile narrative tells implementers to filter with ?use=preauthorization, but ExplanationOfBenefit.use is not one of the base R4 ExplanationOfBenefit search parameters and is not listed in the PDex Server CapabilityStatement, asking whether the CapabilityStatement should be extended (or a SearchParameter added) to remove the inconsistency. The submitter's implied remedy (add use to the CapabilityStatement / define a custom SearchParameter) is not adopted in this STU update — that would be a structural change to a published artifact and is out of scope for STU2.2.0. Instead, the Prior Authorization profile narrative (§13.23.1) now carries a clarifying note that re-characterizes ?use=preauthorization as an illustrative, non-normative example, and points implementers at the portable, conformance-listed alternative — _profile=http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/pdex-priorauthorization combined with patient — with client-side filtering by ExplanationOfBenefit.use as a fallback. Formalizing a use SearchParameter and adding it to the CapabilityStatement is left for a future version of the IG |
| FHIR-56184 | Persuasive with Modification. The submitter observed that the Provider Treatment Attestation Profile (used in the $provider-member-match request) needs references to identify the attesting provider, organization, and actors using business identifiers — typically NPI — rather than relative Reference.reference values that are local to the requester's system, and asked that this be expressed via narrative or examples (including the option of references to contained resources carrying the business identifier). FHIR-56259 (already in this STU 2.2.0 update) addressed the Consent.performer half of the request by adding performer.identifier 0..1 MS with NPI guidance and updating examples accordingly. The residual portion is now resolved by extending the same identifier-based-logical-reference guidance to Consent.organization and Consent.provision.actor.reference in the profile element definitions, and by updating the three example Consent instances (Example-Provider-Treatment-Attestation-Consent, TreatmentAttestationExample1, TreatmentAttestationExample2) to populate Reference.identifier.system = http://hl7.org/fhir/sid/us-npi + Reference.identifier.value (with Reference.display retained) on organization and provision.actor.reference rather than relative Reference.reference values. The submitter's broader implication that these elements gain new normative MS or cardinality constraints is not adopted in this STU update — narrative + example clarification is sufficient to address the matching concern, and adding new MS to a published profile beyond what was already done for performer is out of scope; this is recognized as a candidate for a future cycle |
| TC: FHIR-56160 | Payer-to-Payer Exchange [deprecated] §6 Data Retrieval Methods data-mapping table: Resource column for the PDex Prior Authorization profile row corrected from "Prior Authorization" to "ExplanationOfBenefit", since the PDex Prior Authorization profile is constrained on the FHIR R4 ExplanationOfBenefit resource and the column otherwise lists FHIR R4 resource types |
| FHIR-56107 | Already Addressed by FHIR-56545. The submitter observed that the MatchedMembers output parameter on the Provider-Member-Match OperationDefinition incorrectly pointed to the Member-Provider Treatment Relationship Group profile, while the Provider $multi-member-match Response Parameters profile correctly identified ProviderMemberMatchGroup as the matched-members profile. The Provider-Member-Match OperationDefinition has since been re-aligned with the 3-bucket outcome model under FHIR-56545: MatchedMembers.targetProfile = Canonical(ProviderMemberMatchGroup), NonMatchedMembers.targetProfile = Canonical(ProviderMemberNoMatchGroup), ConsentConstrainedMembers.targetProfile = Canonical(MemberOptOut). No further changes required for FHIR-56107 |
| FHIR-56252 | Considered for Future Use. The submitter (filing a Question) observed that the PDex Prior Authorization profile provides no clear way to link a Prior Authorization EOB to its supporting administrative or clinical documentation, even though CMS-0057 obligates impacted payers to exchange that documentation through the Payer-to-Payer API; they recommended slicing ExplanationOfBenefit.supportingInfo following the Da Vinci PAS pattern (category additionalInformation from PASSupportingInfoType, valueReference → DocumentReference). The work group agrees the linkage is valuable. The structural slice (with MS, value-set binding, and reference-target constraint) is not adopted in this STU update because it would add new normative constraints to a published profile beyond the narrow STU scope, and because settling the inline-vs-URL DocumentReference.content policy needs broader review (PDex P2P must support large attachments — for example, documents exceeding ~10 MB — that should be linked by URL rather than inlined as base64, which differs from the PAS DocumentReference profile's inline-only pattern). Resolved in this update by adding informative narrative to the PDex Prior Authorization profile (§13.23.1) describing the recommended implementation pattern: populate the inherited base R4 supportingInfo[x] with category PASSupportingInfoType#additionalInformation (PAS is already a PDex IG dependency) and valueReference to a DocumentReference, with explicit support for both inline (content.attachment.data) and URL-referenced (content.attachment.url) content so implementers can link large documents without inlining. Formal slicing is deferred to a future cycle |
| FHIR-56543 | Duplicate of FHIR-56545 — Already Addressed. The submitter observed the same three-way misalignment between the Provider-Member-Match OperationDefinition (14.6.1), the Provider $multi-member-match Response Parameters profile (14.6.1), the Provider $multi-member-match Response Parameters profile (MatchedMembers (ProviderMemberMatchGroup), NonMatchedMembers (ProviderMemberNoMatchGroup — single Group covering both unmatched and treatment-attestation-failed cases), and ConsentConstrainedMembers (MemberOptOut). No further changes required for FHIR-56543; recommend resolving as Duplicate of FHIR-56545 |
| FHIR-56498 | Member Opt-Out Group profile (§14.19.1): added the missing value-set binding on Group.characteristic.code. Previously the element carried a fixed pattern of PdexMultiMemberMatchResultCS#consentconstraint but inherited the base R4 "example" binding with no value set — an authoring oversight noted by the submitter. Added * characteristic.code.coding from http://hl7.org/fhir/us/davinci-pdex/ValueSet/PDexMultiMemberMatchResultVS (default required strength), matching the binding pattern already used on the sibling Group profiles PDexMemberMatchGroup and ProviderMultiMemberMatchResponseParameters (where the same value set is bound on characteristic.code.coding). The fixed-pattern code (#consentconstraint) is retained and is a member of the bound value set, so the binding is consistent with existing conformant instances |
| FHIR-56497 | Member Opt-Out Group profile (§14.19.1): Group.managingEntity previously inherited the base R4 reference targets (Organization, Practitioner, PractitionerRole, RelatedPerson) even though the profile description names a Payer organization as the managing entity — an under-constrained element that allowed semantically incorrect references. Constrained * managingEntity only Reference(Organization) on the Member Opt-Out Group profile, and applied the same constraint to the other Payer-managed Group profiles in the IG family — MemberProviderTreatmentRelationship, ProviderMemberMatchGroup, ProviderMemberNoMatchGroup, PDexMemberMatchGroup, PDexMemberNoMatchGroup — to keep the Group profile family aligned (consistent with the family-wide pattern set by FHIR-56540 on Group.type). PDexProviderGroup is not touched in this update because it inherits from the Da Vinci ATR ATRGroup profile and has a different lifecycle. The ^definition text on each affected managingEntity element was extended to record the rationale (managing entity is always a Payer / healthcare organization). Existing example instances already use Organization references, so no example changes were required |
| FHIR-56495 | Member Opt-Out Group example (Group/member-opt-out-group-001, §14.123.2): the example previously identified the managing Payer with an NPI on managingEntity.identifier.system = http://hl7.org/fhir/sid/us-npi, but health plans do not typically have an NPI. The example was updated to identify the Payer using the NAIC company code OID system (urn:oid:2.16.840.1.113883.6.300) with identifier.type set to PDexIdentifierType#naiccode, and a literal managingEntity.reference = "Organization/Payer1" was added so consumers can resolve the managing entity either by logical (identifier-based) lookup or by FHIR reference (Reference.display retained). The same NPI-on-Payer defect existed on four sibling Group example instances and was corrected in the same update for consistency: the example in MemberProviderTreatmentRelationship, and the three ProviderMemberMatchGroup / ProviderMemberNoMatchGroup example instances in ExampleProviderMemberMatchGroups.fsh. No profile-level structural changes were required |
| FHIR-56493 | Member Opt-Out Group profile (§14.19.1): Group.code was previously bound to PDexMultiMemberMatchResultVS (which contains match, nomatch, and consentconstraint) but not fixed, even though instances of this profile only ever represent the consent-constrained / opt-out outcome — the other codes are not semantically applicable. Added the fixed pattern * code = PdexMultiMemberMatchResultCS#consentconstraint to the profile, aligning the conformance constraint with the example and with the profile's intended scope. The ^definition text was extended to record the rationale. The value-set binding is retained alongside the fixed pattern. The same "fix-to-single-code" treatment may be applicable to the other Group profiles in the family (PDexMemberMatchGroup, PDexMemberNoMatchGroup, ProviderMemberMatchGroup, ProviderMemberNoMatchGroup, MemberProviderTreatmentRelationship) but is not extended to those in this update — each requires individual review of its Group.code intent (in particular, MemberProviderTreatmentRelationship.code currently binds to a "member match result" value set even though a TRL is not a match-result group, suggesting the binding itself needs reconsideration in a future cycle) |
| FHIR-56507 | Persuasive with Modification. The submitter asked for the FHIR Artifacts page (§14.0.1, artifacts.html) to be reorganized so that within each artifact type, items are sorted by the API they pertain to (Patient Access, Provider Access, Payer-to-Payer, etc.). Reorganizing the auto-generated artifacts.html itself is not adopted in this STU update because that requires per-artifact groups: metadata in sushi-config.yaml across dozens of profiles, extensions, value sets, code systems, and operations, with significant risk of mis-categorization for cross-cutting artifacts; that work is best done as a single holistic editorial pass in a future cycle. As a narrow alternative that addresses the underlying readability concern in this update, a new navigational page Artifacts by API is added (registered in sushi-config.yaml under pages: and surfaced under the FHIR Artifacts top-level menu entry alongside the existing canonical page, now labeled "All Artifacts (by type)"). The new page indexes the principal profiles, OperationDefinitions, CapabilityStatements, Parameters profiles, Group profiles, and reused / cross-cutting artifacts under headings for each API (Patient Access, Provider Access v2, Provider Access v1 [deprecated], Payer-to-Payer Bulk, Payer-to-Payer Member-Authorized, and Cross-cutting). The auto-generated artifacts.html is unchanged and remains the canonical complete listing; the new page is purely a navigation aid |
| FHIR-56505 | Payer-to-Payer Exchange (bulk) 7.5.4–7.5.5 (Da Vinci Data Export Payload / DaVinci-Data-Export Operation): the page previously carried two separate but largely overlapping conformance statements about what data is exchanged via the Payer-to-Payer Bulk API — 7.5.4–7.5.5 (Da Vinci Data Export Payload / DaVinci-Data-Export Operation): the page previously carried two separate but largely overlapping conformance statements about what data is exchanged via the Payer-to-Payer Bulk API — SHOULD include" with US Core 3.1.1 or 6.1.0, and pdex-168 listed essentially the same payload as "SHALL be available" but mentioned only US Core 3.1.1, which had the effect of imposing a hard requirement on US Core 3.1.1. Per CMS-0057 the Payer-to-Payer payload is mandatory, so the SHALL strength is correct and the SHOULD was wrong. Resolved by collapsing the two into a single canonical conformance expectation: §4pdex-158 is now the merged SHALL list with consistent US Core version flexibility ("US Core 3.1.1 or US Core 6.1.0"), claims/encounters via CARIN BB Non-Financial Basis profiles, and Prior Authorization records together with the structured and unstructured administrative and clinical documentation that supports each decision (with a pointer to the linkage pattern described under FHIR-56252 in the PDex Prior Authorization profile narrative). pdex-168 is retained as a conformance-ID anchor but its body is now a back-reference to pdex-168 is retained as a conformance-ID anchor but its body is now a back-reference to |
| FHIR-56499 | Persuasive with Modification. The submitter raised two distinct concerns about the Payer-to-Payer Exchange (bulk) _since narrative (7.5.5.1.1): (a) the five-year clinical-history limit conflicts with the CMS-0057 final rule (the explicit subject of FHIR-56496), and (b) _since is the wrong parameter for date-of-service filtering because Bulk Data _since filters by Resource.meta.lastUpdated (when the FHIR resource was last changed on the source), not by the clinical / service date carried within the resource. Issue (a) is resolved in the same STU 2.2.0 update under FHIR-56496, which reframes the five-year window as a floor on the requestor's obligation rather than a cap on either party. Issue (b) is resolved in this update: the pdex-172–pdex-176 narrative was rewritten to (i) explicitly clarify that _since filters by _lastUpdated and is the correct parameter only for incremental "what is new on the source" retrievals (notably the run-off use case the IG already describes); (ii) add a new "Filtering by date of service — _typeFilter" subsection that recommends _typeFilter with per-resource date search parameters (Encounter.date, Observation.date, Immunization.date, Condition.onset-date, ExplanationOfBenefit.service-date, etc.) as the correct mechanism for date-of-service-bounded retrieval, and notes that resource types without a date-of-service search parameter (e.g., AllergyIntolerance) cannot be filtered this way; (iii) replace pdex-176's previous "if _since is earlier than five years, the date SHALL be overridden" mechanism with the more accurate model that the responder enforces the §pdex-172 boundary server-side regardless of any _since value, SHALL NOT silently rewrite _since to act as a clinical-history floor, and where a requester supplies a date-of-service filter via _typeFilter the responder SHALL apply the boundary as an intersection on top of the requester's filter |
| FHIR-56496 | Persuasive (applied as proposed and extended to parallel statements with the same defect). The submitter cited 42 CFR 422.121(b)(4)(ii) and observed that the regulation's "data with a date of service within 5 years before the request" language constrains the requesting plan's obligation (the requestor must request all in-scope data covering at least the past 5 years to satisfy the rule) — it does not prohibit a requestor from asking for older data and does not require a responder to cap returned data at 5 years. The IG's prior wording on the Payer-to-Payer Exchange (bulk) page misread the rule as a hard cap on both parties. Resolved by reframing the four parallel five-year SHALL statements (pdex-130, pdex-130, requesting health plan to request at least the 5-year window (to satisfy 42 CFR 422.121(b)(4)(ii)); (ii) require a responding health plan to be capable of returning at least the past 5 years of in-scope data so that requestors can meet their obligation; and (iii) explicitly permit either party to request or return data older than 5 years at their discretion. The five-year window is now described in the IG as a floor on the requestor's obligation, not a cap on either party. The "under review pending FHIR-56496" inline note that was added to pdex-172 under FHIR-56499 is removed. The Prior Authorization status-window rule (pdex-172 under FHIR-56499 is removed. The Prior Authorization status-window rule ( |
| FHIR-56492 | Payer-to-Payer Exchange (bulk) 7.5: 7.5: SHALL be accomplished by the use of the Bulk FHIR API specification" without naming the specification or stating what obligation that placed on implementers, and (as the submitter noted) the section actually uses the Da Vinci $davinci-data-export and PDex $multi-member-match operations rather than the Bulk Data Access IG's generic $export, leaving the conformance ambiguous. Reworded §pdex-129 to (i) name the HL7 FHIR Bulk Data Access Implementation Guide STU2 (2.0.0) as the specification whose async-delivery semantics are required (operation kick-off via HTTP POST, status polling per the FHIR R4 Asynchronous Request Pattern, completion manifest referencing NDJSON output files); (ii) call out that the two operations actually used in this section ($multi-member-match and $davinci-data-export) both follow that delivery pattern; and (iii) explicitly state that the conformance does not require implementers to additionally support the generic $export operation, addressing the submitter's specific point of confusion |
| FHIR-56491 | Payer-to-Payer Exchange (single member) 7.4: 7.4: SHALL implement Payer-to-Payer Exchange for a single member by following the content provided in this section of the IG", which the submitter reasonably read as ambiguous between (interpretation 1) "if a payer chooses to implement single-member exchange, then this content must be followed" and (interpretation 2) "every payer must implement single-member exchange in addition to the Bulk Payer-to-Payer Exchange of pdex-192". Interpretation 1 is the intended meaning — single-member Payer-to-Payer exchange is not itself required by CMS-0057 (the Bulk Payer-to-Payer Exchange of pdex-192". Interpretation 1 is the intended meaning — single-member Payer-to-Payer exchange is not itself required by CMS-0057 (the Bulk Payer-to-Payer Exchange of $everything / Bulk FHIR) are alternatives ("SHALL utilize the access token returned from the Member Access step to request/retrieve data using one of the following three methods"), so no change to that text was needed |
| FHIR-56486 | Persuasive with Modification (privacy-favoring default; structural removal not adopted). The submitter raised a privacy concern that disclosing opt-out status to a requesting provider — by distinguishing 'opted out' from 'not matched' in the $provider-member-match response — could itself constitute a disclosure the member did not authorize, and recommended removing the opt-out group from the operation along with the MemberOptOut profile and the ConsentConstrainedMembers slice on the response Parameters profile. Full structural removal is not adopted because (a) the 3-bucket response model was reconciled under FHIR-56545 and is depended on by FHIR-56498, FHIR-56497, FHIR-56495, FHIR-56493, and FHIR-56509 also in this update, and (b) some payers operate in jurisdictions or under member preferences where opt-out disclosure is permitted and the type-level distinction is operationally useful. Resolved with a privacy-favoring SHOULD default added in four places: (i) the OperationDefinition's ConsentConstrainedMembers parameter documentation, (ii) the Provider $multi-member-match Response Parameters profile's parameter[ConsentConstrainedMembers].resource ^comment, (iii) the MemberOptOut profile description, and (iv) the Provider Access (v2) 7.3 narrative (new 7.3 narrative (new SHOULD suppress the ConsentConstrainedMembers output and instead include the affected members in the NonMatchedMembers Group, making the response indistinguishable to the requester between a true no-match and a matched-but-opted-out outcome. The ConsentConstrainedMembers and MemberOptOut cardinalities are already 0..1 so suppression is conformant; payers that determine no such concern applies MAY continue to populate the bucket. No FSH structural changes |
| FHIR-56479 | Use Case Scenarios 8.2 ("Useful Patient History for Providers"): 8.2 ("Useful Patient History for Providers"): SHALL be mapped to FHIR clinical resources as follows" introducing a normative-strength conformance statement on a page that is itself informative, and over a data-types list (e.g., Family History, generic Medical Devices) that includes types outside the regulatory data-exchange scope. Reworded pdex-386 to descriptive MAY language: "Where a payer elects to exchange any of the data types listed above, the table below identifies the FHIR R4 / US Core profile that the payer MAY use for each", with an explicit follow-up sentence stating that the page is informative, that nothing in the table adds normative obligations beyond those imposed by the relevant regulation or by the operation-specific pages of this IG, and that listing data types outside regulatory scope is purely illustrative. The §5pdex-386 anchor is retained for stability of any external references; the table itself is unchanged |
| FHIR-56456 | Page standards-status promoted from informative to trial-use for the following 17 pages, per ticket request: introduction.md, narrative-conformance.md, securityandprivacy.md, FHIRAccessPermissions.md, pdeximplementationactorsinteractionsdatapayloadsandmethods.md, handlingdataprovenance.md, provider-access-api.md, provider-access-api-v2.md, payertopayerexchange.md, payertopayerbulkexchange.md, datamapping.md, PDexPriorAuthorization.md, member-authorizedoauth2exchange.md, consent.md, cds-hooks.md, PDexProvenance.md, PDexMedicationDispense.md. Configured in sushi-config.yaml under pages: by changing each page's structuredefinition-standards-status extension valueCode from informative to trial-use. Pages not listed in the ticket (e.g., index.md, overview.md, ImplementationGuide-hl7.fhir.us.davinci-pdex.md, the per-resource US Core data-mapping sub-pages, usecasescenarios.md, workflowexamples.md, changehistory.md, credits.md, PDexDownloads.md, artifacts.html, artifacts-by-api.md, other-igs.md) retain their previous informative status |
| FHIR-56453 | Removed CoverageToLink from the Provider-Member-Match Operation and the Provider $multi-member-match Request profile, since linking a member's previous coverage to a new coverage is meaningful only in the Payer-to-Payer member-match scenario (where the requesting payer holds the new coverage). In Provider Access the requester is a provider — not a payer issuing new coverage — and CoverageToLink therefore has no use case. Specifically: (i) the MemberBundle.CoverageToLink part on the Provider-Member-Match OperationDefinition (Operation-provider-member-match.fsh) was removed and replaced with a comment explaining the omission and the contrast with the Payer-to-Payer case; (ii) the parameter[MemberBundle].part contains CoverageToLink 0..1 slice on ProviderMultiMemberMatchRequestParameters (ProviderMultiMemberMatchRequestProfile.fsh) was removed and replaced with the same explanatory comment; (iii) the file-header comment was updated from "Not requiring CoverageToLink" to "Not defining CoverageToLink at all"; (iv) the redundant note on the example request Description ("CoverageToLink is not included as providers do not issue new coverage") was removed since the slice is no longer defined to begin with. The PDex $bulk-member-match (Payer-to-Payer) Operation and PDexMultiMemberMatchRequestParameters profile are unchanged — they retain CoverageToLink because it is meaningful in that scenario. Builds on the prior FHIR-55620 example-side fix, which removed CoverageToLink from a Provider example; this update completes the cleanup at the profile and operation level |
| FHIR-56452 | Provider-Member-Match OperationDefinition (§14.6.1): the MatchedMembers output parameter cardinality was 0..1, but the Provider $multi-member-match Response Parameters profile (ProviderMultiMemberMatchResponseParameters) declared the same parameter at 1..1. Per the 3-bucket reconciliation under FHIR-56545, the MatchedMembers Group is always emitted (even when no submitted member was matched, in which case Group.member[] is empty) so the matched-Group identifier is always available for the subsequent $davinci-data-export step. The OperationDefinition's MatchedMembers.min was therefore raised from 0 to 1, aligning the OperationDefinition cardinality with the response Parameters profile. The documentation and a new in-FSH comment now explicitly record the "always emitted, even when empty" semantic. The parallel PDex Payer-to-Payer $bulk-member-match OperationDefinition was already at 1..1 for MatchedMembers, so no change was needed there |
| FHIR-56444 | The submitter observed an apparent inconsistency between pdex-05 (PDex Provenance, "A Provenance resource SHOULD be provided with each member-related resource…") and §6pdex-127 (Overview, "Health Plans SHALL provide Provenance records that, at a minimum, indicate that they are playing the role of Transmitter of the data in any PDex information exchange") and asked whether implementers are required to support Provenance. The two statements are not actually in conflict — they apply at different scopes — but the IG narrative did not call out the distinction, so it read as ambiguous. Resolved by adding an explicit "Two distinct Provenance obligations" introduction at the top of the PDex Provenance page that names the two scopes: (1) per-exchange Transmitter Provenance — §pdex-127 — SHALL (each PDex exchange / bundle carries at least one Transmitter Provenance from the Health Plan), and (2) per-resource Author/Source Provenance — pdex-04, pdex-04, (each member-related resource SHOULD carry a Provenance describing its upstream origin, in addition to the Transmitter Provenance, particularly when the requester uses _revinclude=Provenance:target). pdex-05 was reworded to make the per-resource scope explicit and to state that it is "in addition to" the pdex-05 was reworded to make the per-resource scope explicit and to state that it is "in addition to" the Handling Data Provenance page was reworded the same way and now explicitly cross-references pdex-127. No conformance levels were changed (pdex-127. No conformance levels were changed ( |
| FHIR-56299 | Persuasive with Modification (narrative-only disambiguation; no FSH structural changes). The submitter raised three related concerns: (Q1) why $provider-member-match.ConsentConstrainedMembers uses the MemberOptOut profile while $bulk-member-match uses PDexMemberNoMatchGroup for the same conceptual outcome; (Q2) how a payer that stores both a master MemberOptOut opt-out list (the payer-internal scaffolding pattern) and the response MemberOptOut Groups emitted by $provider-member-match should distinguish them at query time when both conform to the same profile; (Q3) how MemberProviderTreatmentRelationship master-list Groups would be distinguished from "Groups generated by $provider-member-match" — which carries a partly mistaken premise. Resolved with three narrative additions. Q1 (Group-profile divergence): a new "Why the response Group profiles differ from $bulk-member-match" subsection on the Provider Access (v2) page clarifies that both operations use the same 3-bucket outcome model but the Provider Access side binds a distinct MemberOptOut profile to the consent-constrained bucket while Bulk PDex reuses PDexMemberNoMatchGroup for that bucket; the bucket itself is separately enumerated on the response Parameters profile in both cases. The subsection includes a per-bucket profile-binding table and a future-direction note pointing at FHIR-56480 Level B (deeper Group-profile alignment). Q2 (MemberOptOut discriminator): the MemberOptOut profile description now recommends Group.identifier with a payer-defined system URI as the discriminator between master-list instances and operation-emitted response instances (e.g., https://{payer}/fhir/identifier/master-opt-out-list for masters vs https://{payer}/fhir/identifier/match-result or omitted for operation-emitted responses), with Group.meta.tag offered as an alternative. The narrative explicitly notes that Group.code is not a reliable discriminator because it is fixed-pattern to PdexMultiMemberMatchResultCS#consentconstraint on every conformant instance per FHIR-56493. Q3 (MemberProviderTreatmentRelationship clarification): a new "$provider-member-match does not emit MemberProviderTreatmentRelationship Groups" subsection on the Provider Access (v2) page corrects the premise — the operation emits ProviderMemberMatchGroup (Id pdex-provider-member-match), not MemberProviderTreatmentRelationship (Id pdex-treatment-relationship); the two are distinct profiles with different lifecycles, and the discriminator between them is Group.meta.profile, not Group.code. The "PDexprovidergroup" guess is identified as referring to the v1-deprecated PDexProviderGroup attribution profile, which is unrelated. (Note: an earlier draft of this entry incorrectly described $bulk-member-match as using a 2-bucket model; that was a misreading. The Bulk OperationDefinition and the PDexMultiMemberMatchResponseParameters profile both define a separate ConsentConstrainedMembers slice, so the Bulk side is also 3-bucket; the divergence between the two operations is in which Group profile binds to each bucket, not in the number of buckets. The narrative on the Provider Access (v2) page reflects the corrected description.) No FSH structural changes |
| Dependency version bumps (IG Publisher warnings) | Three of four "dependent IG version is getting old" warnings raised by the IG Publisher in the STU 2.2.0 build were addressed in this update; the fourth is intentionally deferred to a future major release. Bumped: hl7.fhir.us.davinci-hrex from 1.1.0 to 1.2.0 (PDex relies heavily on HRex profiles hrex-coverage, hrex-patient-demographics, hrex-consent, and the $member-match operation; bumping keeps the most-referenced dependency current); hl7.fhir.us.carin-bb from 2.1.0 to 2.2.0 (CARIN BB Non-Financial Basis EOB profiles are normatively referenced in the Bulk Payer-to-Payer and Provider Access claims-data flows; a 2.x → 2.x bump warrants a re-validation pass against PDex examples and the data-mapping guidance, which is performed as part of this update); hl7.fhir.us.davinci-crd from 2.1.0 to 2.2.1 (CRD is referenced for cross-IG pattern alignment but PDex does not directly profile CRD artifacts, so the bump is low-risk). The "Base Specs" top-level menu entry intentionally retains the label "HRex 1.1.0" / STU1.1/, since the Da Vinci IG template enforces a warning if that specific label is not present in the menu; the actual dependencies: entry resolves to HRex 1.2.0 — the menu is a navigation aid only. Deferred: hl7.fhir.us.davinci-pas 2.1.0 (PAS provides extension-itemAuthorizedDetail referenced by the PDex Prior Authorization profile and PASSupportingInfoType referenced by the FHIR-56252 supporting-documentation linkage narrative; a bump may shift the structure or canonical of those reused PAS artifacts and warrants a coordinated review with the PDex Prior Authorization profile narrative additions made in this update). The deferred PAS bump will be revisited in a future major release alongside the FHIR-56443 US Core 3.1.1 cleanup work that has the same scope-too-large rationale, and any FHIR-56391 structural addition (the item.extension[productOrServiceCodeEnd] slice that would reuse a PAS extension definition) that is performed at the same time |
| FHIR-56138 | Persuasive (applied as proposed; informal work-group guidance codified in the IG). The submitter requested explicit, codified guidance on when a provider/EHR system should use Provider Access v1 (Attribution) versus Provider Access v2 (Attestation), citing informal guidance from PDex work group calls (2026-02-27 and 2026-03-06): v2 is expected for in-network providers supporting the CMS-mandated Provider Access API; v1 may be used for Value-Based Care (VBC) / risk-based provider program scenarios; and the case where a provider/EHR is both in-network and under a VBC contract needed an explicit answer. Resolved by adding a new "When to use Provider Access v1 (Attribution) versus Provider Access v2 (Attestation)" section near the top of the Provider Access API (v2) page, with a per-scenario decision table and two new conformance IDs: pdex-241a (payers SHALL support v2 for the CMS-0057 Provider Access API obligation; in-network providers/EHRs SHOULD use v2) and §7pdex-241b (a provider/EHR operating under both in-network and VBC arrangements with the same payer SHOULD use v2 for the CMS-mandated exchange and MAY use v1 for VBC-specific data flows alongside it; the choice is per-request, per-purpose, not per-payer or per-contract). A cross-reference subsection has been added to the Provider Access API (v1) page stu-note at the top, pointing readers at the v2-page guidance and explicitly noting that v1 remains supported for VBC-driven data flows. The IG narrative is now consistent with the work-group's informal guidance, which was previously communicated only on Confluence call notes |
| FHIR-56177 | Not Persuasive (with clarifying narrative). The submitter asked why the PDex Provider Access Consent profile uses patient-privacy on Consent.scope rather than the v3 PurposeOfUse ValueSet used by TEFCA. The premise conflates two structurally distinct elements: Consent.scope is bound by FHIR R4 to the ConsentScope code system (treatment / patient-privacy / research / adr) and answers "what kind of consent is this?"; the v3 PurposeOfUse ValueSet (used by TEFCA) is bound to Consent.provision.purpose and answers "for what purpose does this consent apply?". The profile's existing * scope = $consentscope#patient-privacy is correct for an information-disclosure consent and parallels the FHIR-56537 resolution on the ProviderTreatmentAttestation profile. Resolved by adding ^short / ^definition narrative on the scope element in the PDex Provider Access Consent profile FSH that explicitly distinguishes Consent.scope from Consent.provision.purpose, names the ConsentScope code system as the binding for scope, and notes that the profile does not redefine provision.purpose, so implementers retain the base R4 Consent profile's extensible binding to v3 PurposeOfUse on that element and may use TEFCA-style purpose codes there as appropriate. No structural changes (cardinalities, MS, slicing, or fixed values are unchanged); the existing patient-privacy value is correct |
| FHIR-56185 | Payer-to-Payer Exchange (bulk) §6.4.7 (Scopes for Operations): the suggested OAuth scope for executing $bulk-member-match was given as http://hl7.org/fhir/us/davinci-pdex/OperationDefinition/bulk-member-match (lower-case hyphenated), but the actual canonical URL of the Bulk Member Match OperationDefinition is http://hl7.org/fhir/us/davinci-pdex/OperationDefinition/BulkMemberMatch (CamelCase). The mismatch meant that an authorization server checking grants by URL match against the OperationDefinition would not recognize the suggested scope. Resolved by aligning the suggested scope text with the actual canonical URL: the bullet now reads http://hl7.org/fhir/us/davinci-pdex/OperationDefinition/BulkMemberMatch. A clarifying note has been added explaining that the scope matches the OperationDefinition URL verbatim and that the prior …/bulk-member-match form was a documentation error. The OperationDefinition's canonical URL is unchanged; the FSH artifact is unchanged. The scope-list bullet for $davinci-data-export (the second scope) is unaffected |
| FHIR-56258 | Persuasive (applied as proposed; per-member Consent evaluation made explicit). The submitter (filing a Question) asked how $bulk-member-match should handle a request in which multiple submitted members all match demographically but a subset have invalid Consent (e.g., expired) — should the responder split the response across MatchedMembers and ConsentConstrainedMembers per member, or treat the bulk request as all-or-nothing? Confirmed the per-member treatment: a Consent failure on one member SHALL NOT cause the responder to fail the whole request and SHALL NOT re-bucket the other members. Added a new "Per-member Consent evaluation" subsection to the Payer-to-Payer Exchange (bulk) page (pdex-154a / pdex-154a / not placed in NonMatchedMembers because it did demographically match), and notes that consent-error operational diagnostics belong out-of-band (operator logs, support channels) since the Group conveys the consent-constrained outcome categorically. Cross-references the parallel $provider-member-match operation, which applies the same per-member rule subject to the privacy-favoring default at pdex-261a (per FHIR-56486). No FSH structural changes; the pdex-154 / pdex-155 / pdex-155 / |
| FHIR-56391 | Persuasive with Modification (narrative-only; structural addition deferred). The submitter observed that the PDex Prior Authorization profile provides a slice to express the end of an authorized procedure code range (via the nested PAS extension at item.extension[authorizedItemDetail].extension[productOrServiceCodeEnd]) but no equivalent slice on item.extension for the end of a requested procedure code range — item.productOrService holds either a single code or the start of a requested range, with no companion item-level element for the range end. Adding a structural productOrServiceCodeEnd slice on item.extension (reusing the Da Vinci PAS extension definition that this profile already depends on) is the natural fix and is the submitter's proposal. Full structural addition is not adopted in this STU update because it adds new conformance surface to a published profile and warrants broader review (alignment with PAS, downstream-implementer impact, ballot consideration). Resolved by adding a "Representing a requested procedure code range" narrative subsection to the PDex Prior Authorization profile narrative describing an interim pattern that uses only currently-conformant elements: one item entry carries the range start in item.productOrService; a second item entry carries the range end; both entries share an item.extension[itemTraceNumber] value so consumers can group them as a single requested range. The authorized-range end continues to be expressed via the existing nested authorizedItemDetail extension. A future-direction note records the expectation that a future IG version will add the dedicated item-level productOrServiceCodeEnd slice; the interim pattern is forward-compatible with that addition. No FSH structural changes |
| FHIR-56400 | Already Addressed by FHIR-56545. The submitter observed that the Provider-Member-Match OperationDefinition page on the published build pointed NonMatchedMembers at the PDex (Payer-to-Payer) Member No Match Group profile (Id pdex-member-no-match-group) rather than at the Provider Member No Match Group profile (Id pdex-provider-member-no-match), and asked which was correct given the two profiles have different conformance. The Provider variant is correct. This is the same defect that FHIR-56107 also reported (about MatchedMembers); both halves were corrected under FHIR-56545 when the Provider-Member-Match OperationDefinition was re-aligned with the 3-bucket outcome model: MatchedMembers.targetProfile = Canonical(ProviderMemberMatchGroup), NonMatchedMembers.targetProfile = Canonical(ProviderMemberNoMatchGroup), ConsentConstrainedMembers.targetProfile = Canonical(MemberOptOut). The current FSH (Operation-provider-member-match.fsh) reflects the corrected state. No further changes required for FHIR-56400; recommend resolving as Duplicate of (or Already Addressed by) FHIR-56545 |
| FHIR-56433 | Two parallel narrative locations carried directly contradictory conformance levels for the same expectation: Provider Access (v1) 7.2.2 7.2.2 SHALL implement the pdex-provider-consent" while Provider Access (v2) 7.3.3 7.3.3 MAY implement the pdex-provider-consent". Additionally, the submitter asked what "implement the pdex-provider-consent" actually meant operationally. Resolved by: (i) aligning pdex-326 (v1) to MAY to match §8pdex-275 (v2), since the MAY is consistent with the IG's overall scope (per FHIR-56509 and the Scope of this section callout, the IG does not prescribe payer-internal mechanisms for tracking opt-out / sharing preferences — FHIR Consent is one valid pattern); (ii) adding a uniform inline definition of what "implement the pdex-provider-consent" means on both pages — namely, (a) accept Consent.create requests against the Patient Access API for a Consent resource conforming to the PDex Provider Consent profile, and (b) honor the resulting Consent decision when evaluating the member's opt-out / opt-in status during a Provider-Member-Match / $provider-member-match request; (iii) adding an explicit cross-reference between the two pages so readers see the alignment and the v1-side note records that the prior SHALL has been corrected to MAY. Payers that capture sharing preferences via legacy systems, internal APIs, or other channels remain fully conformant. The pdex-275 and pdex-275 and |
| FHIR-56435 | Overview 2.3 (2.3 (SHALL provide Provenance records that, at a minimum, indicate that they are playing the role of Transmitter of the data in any PDex information exchange") required a Transmitter agent on every Provenance in the exchange, or only at least one Provenance per exchange playing the Transmitter role (i.e., the per-exchange / per-bundle Transmitter Provenance). The intended reading is the latter; the IG's example library (single Transmitter Provenance per bundle, distinct from per-resource Author / Source Provenance records) supports it. Resolved by rewriting pdex-127 to make the per-exchange / per-bundle scope explicit: "For each PDex information exchange, the Health Plan SHALL provide at least one Provenance resource naming the Health Plan as the Transmitter of the data — i.e., a Provenance whose agent[].type includes a Transmitter entry and whose agent.who references the Health Plan's Organization, with target[] referencing the resources transmitted in the exchange. This is an exchange-level (per-bundle) obligation: a single Transmitter Provenance per exchange satisfies §9pdex-127. The Health Plan is not required to add a Transmitter agent entry to every per-resource Provenance that the exchange may also carry; per-resource Author / Source Provenance records are retained as-is alongside the exchange-level Transmitter Provenance." A cross-reference to the Two distinct Provenance obligations section added under FHIR-56444 is included so readers see how pdex-127 (per-exchange SHALL) and §10§11 pdex-127 (per-exchange SHALL) and §10§11 |
| FHIR-56436 | Two parallel narrative locations — Provider Access (v1) 7.2.5 (7.2.5 (SHALL support "the standard search parameters for group that are specified in the base Group resource in FHIR R4", and linked to the PDex Member Match Group profile page (which only marks code as mandatory in its narrative). The submitter reasonably asked which interpretation governed: the 10 base R4 Group search parameters, or only code? Neither matches the actual PDex Server CapabilityStatement, which enumerates identifier and characteristic as the SHALL-support parameters for the Group resource. Resolved by aligning both narrative sections with the CapabilityStatement: pdex-157 and pdex-157 and SHALL support the Group search parameters enumerated in the PDex Server CapabilityStatement (and its US Core 6.1.0 variant) — at minimum identifier and characteristic — and that the CapabilityStatement is the authoritative source. The wrong link to the profile page is replaced with a link to the CapabilityStatement; an additional pointer to the base R4 Group search-parameter index is added so implementers can see the full set of base parameters they MAY support beyond the IG's required minimum. The pdex-157 and pdex-157 and |
| FHIR-56437 | Payer-to-Payer Exchange (single member) 7.4.5 ($everything operation): the prior pdex-214 read "The server SHOULD filter the ExplanationOfBenefit resource to include only PDex Prior Authorization profiled records. e.g., ExplanationOfBenefit.use does not equal 'claim'." — which would have excluded claims from a $everything response. As the submitter observed, this directly contradicts the regulatory data-exchange obligation (claims and encounter data are required per CMS-9115 and CMS-0057), and also contradicts pdex-210 immediately above it, which states that each of the three retrieval methods (individual queries / $patient-everything / Bulk FHIR) SHALL support the same profiles and resources. The accompanying _type example list compounded the error by omitting ExplanationOfBenefit entirely. Resolved by (i) rewording §12pdex-214 to require — not forbid — that $everything return the full in-scope data set, including both Prior Authorization EOB records and Claims/Encounter EOB records (CARIN BB Non-Financial Basis profiles); (ii) explicitly stating that a server SHALL NOT silently exclude claim EOBs unless the requester is not permitted to access them under the access-control rules at pdex-218 / pdex-218 / MAY narrow the response by supplying the _type parameter or by client-side filtering after retrieval; (iv) updating the _type example list to include ExplanationOfBenefit, Coverage, Practitioner, and PractitionerRole so it matches the data-retrieval table. The §pdex-214 anchor is retained; the conformance level is upgraded from the prior SHOULD-exclude to SHALL include the full set in keeping with the regulation |
| FHIR-56438 | Payer-to-Payer Exchange (bulk) 7.5: 7.5: SHALL be included in the API response"). Fixed by splitting the paragraph into two clean sentences: a descriptive lead-in about internal status-change recording, then pdex-132 itself as the response-content requirement: "In both the Provider Access API and the Payer-to-Payer API, any Prior Authorization whose status has changed in the previous 12 months (measured from the date of the request) SHALL be included in the API response." A trailing sentence notes that §13pdex-132 reinforces the status-change portion of pdex-131. The pdex-131. The SHALL strength are unchanged; the substantive obligation (PA status-change-in-last-12-months is returned) is preserved |
| FHIR-56439 | Payer-to-Payer Exchange (bulk) 7.5: 7.5: 42 CFR 422.121(b)(4)(ii)(B) actually requires "active and pending prior authorization decisions and related clinical documentation and forms for items and services". As the submitter observed, "data" is narrower than the regulatory concept and elides the administrative-forms portion of the requirement. Reworded both statements to mirror the rule: pdex-133 now reads "Active and pending Prior Authorizations exchanged via the Payer-to-Payer Exchange API SHALL include the related clinical documentation and forms used in support of the prior authorization decision"; §14pdex-134 now reads "The supporting documentation SHALL include both structured and unstructured documentation — for example, clinical notes, lab reports, imaging interpretations, signed administrative forms, and other attachments — that was used in the prior authorization determination." A direct citation to 42 CFR 422.121(b)(4)(ii)(B) is added inline. The §pdex-135 data-types list item that previously read "Prior Authorizations and supporting clinical data as defined by this guide" was updated in parallel to "Prior Authorizations and the related clinical documentation and forms (structured and unstructured) used in support of the prior authorization decision, per 42 CFR 422.121(b)(4)(ii)(B)". A pointer to the PDex Prior Authorization profile narrative was added so readers see the recommended ExplanationOfBenefit.supportingInfo + DocumentReference linkage pattern (described under FHIR-56252) for connecting a PA record to its supporting documentation. Conformance levels (SHALL) unchanged; the change is terminological alignment with the CFR |
| FHIR-56440 | Payer-to-Payer Exchange (bulk) 7.5.1 (Performing Bulk Data Exchange): the closing sentence at 7.5.1 (Performing Bulk Data Exchange): the closing sentence at Payer-to-Payer (single Member) Exchange), SHALL exchange the same data." — was a fragment with a stray closing parenthesis, no clear subject, and was disconnected from the pdex-138 consent statement immediately above and the pdex-138 consent statement immediately above and the same data set (which pdex-140 then enumerates). Resolved by (i) splitting the consent sentence (pdex-140 then enumerates). Resolved by (i) splitting the consent sentence (SHALL exchange the same data set; the data set is enumerated in pdex-140 below. The two methods differ in how they move that data (bulk async export vs. per-member synchronous retrieval), not in what is moved." The pdex-140 below. The two methods differ in how they move that data (bulk async export vs. per-member synchronous retrieval), not in what is moved." The |
| FHIR-56441 | Payer-to-Payer Exchange (bulk) 7.5.2.1 (Cross-Referencing Match Results with Submitted Members) — and the parallel FSH ^comment on Group.contained for both PDexMemberMatchGroup and PDexMemberNoMatchGroup: the absolute "Responders SHALL NOT abridge, modify, or substitute the submitted Patient resource" at §15pdex-151 conflicted with the base FHIR R4 specification, which (per FHIR R4 References §3.5) prohibits contained resources from carrying meta.versionId, meta.lastUpdated, or meta.security and from themselves containing nested contained resources. A submitter that included any of those base-FHIR-prohibited elements on the submitted Patient resource would force a responder to either violate the IG or violate base FHIR. Resolved per the submitter's recommendation by enumerating exactly what MUST be preserved: pdex-150 now requires preservation of the id, all identifier elements, and all demographic elements (name, birthDate, gender, address, telecom, communication, and other Patient elements supplied by the requester); pdex-151 retains the SHALL NOT modify language but scopes it to those preservation-required elements; new §pdex-151a explicitly SHALL require the responder to remove the base-FHIR-prohibited elements (meta.versionId, meta.lastUpdated, meta.security, nested contained resources) when copying the submitted Patient into the response Group's contained[], and states that doing so is not a violation of the preservation requirement. The parallel Group.contained ^comment on both PDex Group profiles (PDexMemberMatchGroup, PDexMemberNoMatchGroup) was updated with the same wording. The Provider Access response profile (ProviderMultiMemberMatchResponseParameters) carried only descriptive (not normative-strict) language about contained Patient resources and did not have the same conflict, so no parallel fix was needed there |
| FHIR-56442 | Payer-to-Payer Exchange (bulk) 7.5.5.1.4 (_typeFilter): the submitter asked whether the MAY in §16pdex-180 ("The _typeFilter parameter MAY be used to further restrict the resources retrieved by the Payer") referred only to the requester's choice to specify the parameter, or also to the responder's discretion to support it. Disambiguated by separating the two concerns and anchoring both to the HL7 FHIR Bulk Data Access IG STU2 _typeFilter semantics. pdex-180 is now restricted to the requester's choice (a requesting Payer MAY include _typeFilter); new §17pdex-180a / pdex-180b / pdex-180b / _typeFilter support is OPTIONAL per the Bulk Data Access IG; requesters SHOULD consult the responder's CapabilityStatement to determine support; responders that support _typeFilter SHALL filter per the supplied search query; responders that do not support _typeFilter (or the specific search parameter requested) SHALL behave per the Bulk Data Access IG (typically returning an OperationOutcome) and SHALL NOT silently emit unfiltered data; where the responder does not support _typeFilter the requester MAY apply date-of-service filtering client-side on the returned NDJSON. pdex-181 was reworded to reference the date-of-service filter expressions added under FHIR-56499 in the same update; pdex-181 was reworded to reference the date-of-service filter expressions added under FHIR-56499 in the same update; |
| FHIR-56443 | Considered for Future Use — Deferred to a future major release. The submitter observed that US Core 3.1.1 expired on 2026-01-01 under 45 CFR 170.215(b)(1)(i) and proposed cleaning up references to it in the IG; the submitter also noted that such a change is too significant for an STU update. The work group agrees on both points. Removing US Core 3.1.1 would touch the Introduction §3.7 profile lists, the pdex-server CapabilityStatement (US Core 3.1.1 flavor), every per-resource data-mapping page that pairs a 3.1.1 link with a 6.1.0 link, the Payer-to-Payer (bulk) and Provider Access narratives that say "US Core 3.1.1 or US Core 6.1.0", the uscore3 dependency in sushi-config.yaml, and a number of examples. Plans with legacy data and downstream consumers that have not yet migrated may still depend on 3.1.1, so the cleanup is best done as a coherent pass in a major release rather than piecemeal in this STU update. No code or configuration changes are made for FHIR-56443 in this update; the ticket is recorded here so the disposition is visible and the work is registered for the next major-release planning cycle |
| FHIR-56480 | Persuasive with Modification (applied as proposed and extended for cross-operation alignment). The submitter observed that the $bulk-member-match output format changed between STU 2.1.0 (Parameters envelope wrapping the Group resources) and STU 2.2.0 (Group resources written directly as ndjson, no Parameters envelope) and that this is a breaking wire-format change with no functional difference in the data conveyed. Adopted the submitter's proposed backwards-compatible relaxation on the Payer-to-Payer Exchange (bulk) page ( 7.5.2 — "Bulk Member Match with Consent"): the responder SHALL include the Group resources as Group ndjson files in the async completion manifest (matching the current STU 2.2.0 format that fits the FHIR R4 Asynchronous Request Pattern naturally), and MAY additionally include a Parameters ndjson file (with manifest output[] "type": "Parameters") containing a PDexMultiMemberMatchResponseParameters-conformant Parameters resource that wraps the same Group resources, so a single response can serve both STU 2.1.0-style requesters and STU 2.2.0-style requesters from one responder. A new "Backwards-compatible Parameters envelope (optional)" subsection records the trade-off and instructs requesters that consume both formats to SHOULD prefer the Group ndjson files. The OperationDefinition is unchanged (it already declares no inline out parameters because the output is delivered via the async manifest). The parallel "Operation Definition" paragraph at §187.5.2 is updated to reference both the Group ndjson and the optional Parameters ndjson. The companion narrative on pdex-138 (Out: line) is also updated. Modification — Level A cross-operation alignment. Because implementers are converging Payer-to-Payer foundations into Provider Access deployments, the same Group-ndjson-SHALL + Parameters-ndjson-MAY allowance has been extended to the Provider Access v2 $provider-member-match operation (new §19pdex-288a / §pdex-288b on the Provider Access (v2) page), with cross-reference subsections added on both pages explicitly stating the wire-format alignment between the two operations and a future-direction note flagging deeper structural convergence (Group profile inheritance / single canonical $multi-member-match) as a future-cycle item. This extension provides a single reusable async-delivery code path for implementers who handle both operations |
| FHIR-56509 | Full removal is not adopted because the Member Opt-Out Group profile is the wire-format target profile bound to ConsentConstrainedMembers in the Provider-Member-Match OperationDefinition / response Parameters profile (per FHIR-56545); deleting it would break the API response contract. Instead, the profile is reframed and the contested narrative is rewritten so the IG no longer reads as prescribing a payer-internal mechanism. (i) The Member Opt-Out Group profile description now leads with "Intended use: a payer-internal FHIR-based scaffolding pattern for tracking opt-outs, offered to implementers whose existing platform cannot itself act as the authoritative reference source" and explicitly notes the secondary wire-format response use. (ii) Provider Access (v2) pdex-244 reworded so the FHIR Group profiles are explicitly framed as optional internal-tracking scaffolding, not a normative requirement, and the dual-use of Member Opt-Out Group is called out. (iii) pdex-245 rewritten — the SHALL is moved from "the list SHALL be a Group resource" to "the payer SHALL be able to determine opt-out status at request time"; using the Group profile is now an explicit MAY. (iv) pdex-252 rewritten to remove the contradictory "SHALL be used, unless …" pattern; payers using legacy systems are explicitly conformant. (v) §20pdex-273 / pdex-274 / pdex-274 / outcome (the payer's opt-out tracking is updated when a member opts out or revokes) rather than on the mechanism. No FSH/profile structural changes; narrative + profile-description only |
| FHIR-56511 | Fix formatting of the "how does provider access work" section |
| TC: FHIR-56504 | Various typo and minor wording corrections across narrative pages |
| FHIR-56545 | Reconcile Provider-Member-Match OperationDefinition, response Parameters profile, and "How does Provider Access Work?" narrative on outcome groups: 3-bucket response (Matched / NonMatched / ConsentConstrained) using ProviderMemberMatchGroup, ProviderMemberNoMatchGroup, and MemberOptOut profiles respectively. Narrative §pdex-276 also updated to distinguish the matched response Group used for $davinci-data-export from the long-lived Member-Provider Treatment Relationship Group the payer maintains for governance |
| FHIR-56540 | Align Group.type pattern across the PDex Group profile family. MemberProviderTreatmentRelationship.type changed from #device (incorrect — Group.member entries are Practitioner/PractitionerRole) to #practitioner. Added * type = #person and * actual = true to PDexMemberMatchGroup and PDexMemberNoMatchGroup (which previously left these unconstrained). MemberOptOut, ProviderMemberMatchGroup, and ProviderMemberNoMatchGroup were already correctly constrained to #person. Group.type now matches the type of entities each profile expects in Group.member[] |
| TC: FHIR-56537 | ProviderTreatmentAttestation Consent.scope fixed value changed from treatment to patient-privacy. The treatment code is defined as "Consent to undergo a specific treatment" — i.e., a patient's agreement to receive medical care — which does not match the use of this Consent. The Consent in this profile is a provider's attestation enabling access to / disclosure of patient information for the Provider Access API; patient-privacy ("Agreement to collect, access, use or disclose information") is the correct scope. Three example instances updated to match (Example-Provider-Treatment-Attestation-Consent, TreatmentAttestationExample1, TreatmentAttestationExample2) |
| FHIR-56536 | Persuasive with Modification. The submitter's concern (the response is one big Group containing every matched member, requiring an end-of-job merge) was based on an earlier example that has since been replaced. The current OperationDefinition, response Parameters profile, and Multimembermatchpayerresponseexample already convey the three-bucket categorical structure (MatchedMembers, NonMatchedMembers, ConsentConstrainedMembers). The submitter's proposed remedy (multiple JSON files per individual member) is not adopted — it would fragment the categorical outcome structure and depart from the FHIR Bulk Data manifest convention of partitioning by resource type rather than by subject. To prevent future readers from forming the same misimpression, the Bulk Member Match narrative now leads the response section with an explicit "Response shape: up to three categorical Group resources" subsection — including a per-category cardinality table and an implementation note that producers may write each Group's member[] references incrementally with no end-of-job consolidation step |
| FHIR-56510 | Persuasive with Modification. The submitter observed that the IG appears to define internal payer processes (the "Member-Provider TRL"). The IG's intent has always been to allow payers to use legacy systems/APIs OR FHIR Group resources to track treatment relationships and opt-outs; the Group profiles are demonstration patterns, not requirements. To make this scope crystal clear and prevent the same misreading, a prominent "Scope of this section — what is and isn't prescribed" callout has been added at the top of the Provider Access (v2) page, stating that the IG specifies only the API contract (operations, inputs, outputs, conformance expectations) and that payer-internal mechanisms for tracking treatment relationships and opt-outs are not prescribed. The MemberOptOut and MemberProviderTreatmentRelationship Group profiles remain in the IG as one valid implementation pattern. The submitter's proposed remedy (remove the TRL concept entirely) is not adopted — the FHIR Group representation is useful guidance for payers that choose to use FHIR throughout, and removing it would also reverse part of the FHIR-56545 design (which depends on the TRL profile being available as the long-lived governance artifact) |
| JIRA Ticket | Change |
|---|---|
| FHIR-56259 | Provider Access Consent.performer to use Identifier |
| FHIR-56242 | Change Bundle name in Provider Member Match |
| FHIR-56075 | $provider-member-match OperationDefinition parameter names are inconsistent with the Parameters profile |
| FHIR-55987 | Remove requirements to record export operation details as extensions on Patient/Group resources |
| FHIR-55981 | Use R5 specifications for async operations |
| FHIR-55928 | $member-match listed as both shall and may support |
| FHIR-55927 | Better handle multiple MemberBundles for the same member |
| FHIR-55640 | Two versions of provider member match? |
| FHIR-55620 | Why does the example show a CoverageToLink? |
| FHIR-53815 | Add search parameter and extension to enable easier retrieval of Provider Access Opt-Out |
| FHIR-53793 | Create a listing of all Conformance Requirements in the Narrative of the IG |
| FHIR-53655 | Allow performers of type RelatedPerson for Provider Access Opt-Outs |
| FHIR-53616 | Add more details to the Bulk Provider Request for Data showing the Asynchronous Response Pattern |
| FHIR-53311 | Change Provider Access to use Bulk Member Match |
| FHIR-53256 | Multi-member-match response spec does not fit with async pattern |
| FHIR-53087 | Clarify intent of Group.managingEntity |
| FHIR-52871 | Require input parameter in $bulk-member-match response |
| FHIR-52066 | Clarify data mapping requirements |
| FHIR-52056 | Provenance description on overview page is incorrect |
| FHIR-51845 | Add characteristic-value-reference SearchParameter for Group |
| FHIR-51571 | Clarify delta query responsibility after removal of export tracking extensions |
| FHIR-51377 | Differentiating between Consent resources |
| FHIR-50458 | NPI identifier type code is incorrect in examples |
| FHIR-50227 | Reconcile PDex single $member-match with HRex response profile |
| FHIR-50184 | Details related to notifications for bulk response missing for Provider access API and Payer to Payer API |
| FHIR-50183 | Provider access details in the payer-payer section of the IG at 6.4.4 |
| FHIR-49943 | Clarify async usage of $multi-member-match |
| JIRA Ticket | Change |
|---|---|
| FHIR-50105 | Clarify Asynchronous Response for Bulk Member Match |
| FHIR-49110 | Optional inclusion of Financials in Provider Access API to support VBC use cases |
| STU 2.1 Block Vote 3 | |
| FHIR-48991 | Fix broken Links and other issues identified in QA Report |
| FHIR-48922 | $davinci-data-export param exportType should be mandatory |
| FHIR-48088 | Code Systems should be in THO or be granted an exemption |
| FHIR-48079 | Separate API details from the Data payload section |
| FHIR-48063 | Member-authorized exchange is underspecified |
| FHIR-48061 | "PDex Implementation, Actors, Interactions, Data Payloads and Methods" page important or redundant? |
| FHIR-48057 | Missing must support definition |
| FHIR-48036 | Separate data mapping and patient matching discussion |
| FHIR-48023 | Sub-field must support language inconsistency |
| FHIR-47778 | Include the full HRex privacy and security requirements |
| FHIR-47761 | Security and Privacy and Access Permissions Page not accessible |
| FHIR-47562 | Please add a "Plain Language Summary about HL7 and this Guide" to the home page. |
| FHIR-47056 | Clarify OAuth2.0 workflow for Payer to Payer |
| FHIR-47053 | Require MemberId parameter to be returned in $member-match |
| STU 2.1 Block Vote 2 | |
| FHIR-48701 | AppointmentBook hook usage for Provider Access use case |
| FHIR-48313 | What are implementers supposed to follow for exportType |
| FHIR-48077 | provenance details are spread across several pages and are inconsistently linked |
| FHIR-48073 | Use Case Scenarios page not easily reachable |
| FHIR-48072 | Data Mapping Conformance Requirements |
| FHIR-48070 | integrate separate sections on data mapping |
| FHIR-48058 | Unclear references to Da Vinci ATR |
| FHIR-48037 | CapabilityStatements don't belong under Data Mapping |
| FHIR-47057 | Don't require mapping claims data to US Core resources if sending as ExplanationOfBenefit resources |
| FHIR-47055 | Don't require five year time limit on bulk Payer to Payer exchange |
| FHIR-47054 | Make saving Provenance information received through Payer to Payer optional |
| FHIR-46761 | Add Prev / bottom / Next to header/footer |
| STU 2.1 Block Vote 1 | |
| FHIR-48675 | Add Hyperlink to PDex Server Capability Statement |
| FHIR-48369 | Conflicting statements on OAuth-authorized exchange |
| FHIR-48076 | With Mod: Remove superseded CDS Hooks page |
| FHIR-48074 | With Mod: provider-controlled information requests and filtering page not easily reachable |
| FHIR-48056 | With Mod: Multiple CapabilityStatement descriptions not in sync and should be collapsed |
| FHIR-47794 | Change should to shall |
| FHIR-47792 | rewrite for clarity and grammar |
| FHIR-47789 | Not Persuasive: Change should to shall |
| FHIR-47787 | Clarify concept of changed status |
| FHIR-47786 | Change should to shall |
| FHIR-47785 | Change should to shall |
| FHIR-47784 | Confusing Phrase |
| FHIR-47783 | Clarify the Regulatory requirements |
| FHIR-46681 | Add US Core 7.0.0 support to the IG |
| STU 2.1 Technical Corrections | |
| TC:FHIR-48071 | Rendered text in the middle of example json |
| TC:FHIR-48068 | Reference to profile pages instead of data mapping pages |
| TC:FHIR-48067 | mebedded -> embedded |
| TC:FHIR-48065 | member health history us core sections should be subsections |
| TC:FHIR-48040 | device row in capability statement table shifted over incorrectl |
| TC:FHIR-48039 | un-rendered link on the capability statement page |
| TC:FHIR-48024 | Incorrect Section Numbering |
| TC:FHIR-48022 | Oral Basis Profile is the Dental Profile? |
| TC:FHIR-47973 | Large number of technical corrections |
| TC:FHIR-47788 | grammatical errors and typos |
| JIRA Ticket | Change |
|---|---|
| TC:FHIR-46479 | Change CARIN Blue Button IG link to 2.1.0-snapshot1 |
| FHIR-46476 | Provide guidance on handling of unstructured data for exchange via Payer-to-Payer API |
| FHIR-45992 | Overview page should mention different APIs instead of exchange methods |
| FHIR-42964 FHIR-43375 | Add more Clarity to Step 3- Request Access token for Member Access , How to communicate the Patient ID or Member id when Request Access token for Member Access |
| FHIR-45969 | Specify a means to search for different types of groups. |
| FHIR-46444 | Add Endpoint discovery expectations to index.html |
| Add links to C4BB Basis Profiles for use in Payer and PRovider APIs | Point to C4BB Basis (Non-Financial) Profiles to enable EOBs to be exchanged via Provider Access and Payer-to-Payer API. Update relevant narrative pages. |
| Updates from CMS Connectathon 2024-07-17 | Add comment about search parameters for _tchangehistory.mdypeFilter. Re-work introduction page to Explain the differences between the different APIs. Patient, Provider and Payer-to-Payer. Change Order Select to Encounter Start in Provider Access API Section. CDS Hooks. Should this be retired? Note to say it pre-dates CMS Regulations. Add scope for Single-member match add 6.4.6 to single-member match and change the scope to fit. Re-order Table of Contents - PDex IG not before introduction. |
| Updates from PDex community meeting 2024-07-12 | Use rendering provider NPI as minimum for Attribution Lists. Add EMR Role-based security Assumption. Add UDAP subject_id recommendation. |
| FHIR-45353 | Capturing adjudication (determination) date for pre-auth. Created WhenAdjudicated Extension to hold a DateTime element that can be used in EOB item.adjudication and adjudication. |
| FHIR-46132 | Define Consent Profile for Provider Access Opt-out. Make clear it is optional and provided as assistance for recording opt-out |
| Identify Provider Access and Payer-to-Payer as Async APIs | Add section to Payer-to-Payer Bulk and Provider Access API narrative pages to use HTTP POST and operate as Async Operations |
| Add new Data Payload section | Add Data Payload section to Provider Access Narrative and Payer-to-Payer bulk API narrative. |
| Add new Capability Statements | Add capability Statements for Provider Access and Payer-to-Payer API access. |
| Fix Payer-to-Payer bulk exchange workflow digram | Change from $pdex-p2p-export to $davinci-data-export |
| More specific Group.code value for Operation Scope | More specific Group.code value using CodeSystem URL for Operation Scope |
| Edited Scopes for Operations | Edited scopes for Operations used in Payer-to-Payer and Provider Access APIs |
| Added Informative Extension to Pages | Added Informative Extension to Pages in Sushi-config.yaml |
| Added Change History to Menu | Add Change History page to Menu |
| FHIR-45364 | Provide Use case examples for use of custom extensions in PDex Provider Group |
| Update Clinical-Financial picture in overview.md | Update Clinical Financial image on overview page. |
| FHIR-45356 | Change milsEndpoint examples to use correct code from NdhAssociatedServersTypeCS |
| FHIR-45355 | Removed copied NDH Extensions, Code Systems and Value Sets. Point to content in NDH 1.0.0-ballot, allowing replicated content to be removed from PDex. |
| FHIR-45352 | Added support for US Core 6.1.0 in addition to US Core 3.1.1. Based on L McKenzie Publishing Guidance |
| New MembersOptedOut Extension | Extension to capture number of Attributed Members excluded from the list through Opt-Out |
| TC: FHIR-44906 | Fix broken link to Bulk Data Access IG |
| Add DaVinci-data-export-operation to Other-igs.md | Add link to Da Vinci Data Export Operation in other-igs.md |
| Expand narrative for Provider Access and Payer-to-Payer APIs | Removed ExportModeVS and ExportModeCS, replaced by exportType with fragment |
| FHIR-44807 | Drop Must Support from item.adjudication[consumeUnits] In PDex Prior Authorization |
| Add Provider Access API Diagram | Created Plantuml for Provider Access API |
| Decision to remove optout members from Group | Remove OptOut Extension |
| Define OptedOut Extension to capture member optout | Added OptedOut Extension to PDexProviderGroup to record member opt out from data sharing with attributedproviders |
| JIRA Ticket | Change |
|---|---|
| Payer-to-Payer Bulk Exchange Draft | Draft of PDex Multi Member Match Operation and Request and Response Bundles |
| BallotRec-Vote7 | |
| TC: endpoint example | Update Endpoint example with new Trust Framework certificates in Base64Binary |
| TC: FHIR-41675 | Remove duplicate codes from Provenance Agent Type |
| TC: FHIR-41497 | Missing reference to CDS Hooks diagram |
| TC: FHIR-41399 | Text states "US Core v3.1.1" but URL behind "US Core FHIR R4" points to US Core V 6.0.0 |
| TC: FHIR-41398 | Typo at the bottom of section 5.0.4.3 ("4.2" vs. "5.2") |
| FHIR-41381 | Add narrative stating that the Prior Authorization profile also applies to the Payer to Payer use case |
| NDH Profiles and Extensions | Imported unpublished NDH Profiles, Extensions, CodeSystems and ValueSets into PDex for mTLS support |
| FHIR-41307 | Conflicting Links to HRex Coverage Profile |
| FHIR-41177 | Capturing adjudication (determination) date for pre-auth |
| FHIR-40517 | Section numbering is broken |
| Created Examples for mTLS | Created Examples for MtlsOrganization and MtlsEndpoint |
| FHIR-40357 | Possible typo in Data Mapping specification |
| FHIR-40239 | Missing endpoint URLs? |
| FHIR-36626 | Review all mappings as significant errors have been detected - Reviewed against CARIN-BB STU2 |
| FHIR-36602 | Review all mappings as significant errors have been detected in the above mappings and are expected in other mappings.- Reviewed against CARIN-BB STU2 |
| FHIR-36601 | Review all mappings for DiagnosticReport - Reviewed against CARIN-BB STU2 |
| FHIR-36598 | Review all mappings for Encounter - Reviewed against CARIN-BB STU2 |
| QA Report Fixes | Apply fixes to resolve QA Report Errors. |
| TC: FHIR-39434 | Update table of profiles for payer-to-payer exchange |
| FHIR-39424 | We need a new OperationDefinition for patient-export-pdex |
| FHIR-39314 | Need detail w.r.t. reconciling new session with Consent from earlier interaction |
| FHIR-36626 | Review all mappings as significant errors have been detected - fixed table layout and reconcile to CARIN-BB STU2 - CareTeam, Condition, Coverage, Encounter |
| BallotRec-Vote6 | |
| TC: FHIR-38767 | Typo in 5.2.1.3 Future Direction for Discovery and Registration |
| FHIR-38708 | Clarification on payer directory queries |
| FHIR-38707 | Clarifications on dynamic client registration and first token request |
| FHIR-38706 | Consent reference to DocumentReference in member match request clarification - |
| TC: FHIR-38705 | Endpoint bundle example is not valid |
| TC: FHIR-38696 | Wrong link - NationalDirectory Endpoint resource |
| FHIR-38650 | PDex defines an incorrect request pattern for Patient-level bulk export |
| FHIR-38097 | ExplanationOfBenefit description clarification for use of item level, header level adjudication |
| BallotRec-Vote5 | |
| FHIR-38096 | For Pdex Prior Authorization EOB, reviewAction extension not available at header level adjudication. |
| FHIR-37904 | Add Privacy and Security section to IG |
| FHIR-36598 | Review all mappings for Encounter. |
| FHIR-36495 | CDS Card should not return an access token |
| FHIR-36315 | Unclear definitions of filtering vs restricting cases |
| TC: FHIR-36174 | Correction in StructureDefinition-pdex-provenance |
| BallotRec-Vote4 | |
| Added mTLS Discovery Profiles | Added mTLS Discovery profiles and referenced in Payer-to-Payer Exchange page. |
| FHIR-37778 | Link to the HREX Coverage takes you to the Patient Demographic Profile |
| FHIR-37645 | Consent presentation for P2P |
| FHIR-37644 | Consent Revocation for P2P |
| FHIR-36599 | Review 835 and all mappings to diagnostics. |
| FHIR-36572 | Create a Formal Specification or Conformance Expectations page/section |
| FHIR-36462 | Incorrect Diagram, Consent considerations, everything operation (Duplicate of FHIR-36461) |
| FHIR-36254 | Missing details of payer-to-payer mutual authentication |
| FHIR-36223 | PDEX defined their own version of an already existing code system |
| TC: FHIR-36176 | Correction needed in ExplanationOfBenefit-PDexPriorAuth1.json |
| FHIR-36078 | CareTeam for a patient is not the same thing as "a random collection of Providers that treated the patient once" |
| BallotRec-Vote3 | |
| FHIR-37577 | Change use of _profile to ExplanationOfBenefit.use to filter on "preauthorization" |
| FHIR-37576 | Duplicate to FHIR-37577 |
| FHIR-37546 | Consent expiration for P2P Data Exchange |
| FHIR-36767 | $member-match operation conformance not defined |
| FHIR-36629 | change from are expected to shall |
| FHIR-36601 | Review all mappings for DiagnosticReport (MedicationDispense). |
| FHIR-36462 | Incorrect Diagram, Consent considerations, everything operation |
| BallotRec-Vote2 | |
| FHIR-36885 | ExplanationOfBenefit.use = preauthorization |
| FHIR-36772 | PDEX Provenance page. Broken section |
| FHIR-36767 | $member-match operation conformance not defined |
| FHIR-36600 | Review all mappings for Coverage |
| FHIR-36597 | Invalid data population instruction for Condition |
| FHIR-36596 | Invalid data population instruction for CareTeam |
| FHIR-36563 | No issues; this section is dense but necessary in defining scope. |
| FHIR-36352 | Expand CPCDS Undefined Acronym |
| FHIR-36337 | Update Name Column for Lab Result |
| TC: FHIR-36075 | Link to US Core 3.1.1 actually links to HL7 home |
| TC: FHIR-36314 | Formatting fixes in Care Team element table |
| Ballot-Rec-Vote1 | |
| TC: FHIR-37366 | Vital Signs not referenced in Capability Statement |
| FHIR-36603 | Note that CPCDS is external and informative |
| FHIR-36580 | Update references to HRex to published 1.0.0 version |
| TC: FHIR-36575 | Make the CapabilityStatement rendering more reader friendly |
| FHIR-36573 | Correction: Added pages to drop-down menu |
| TC: FHIR-36569 | Create a Change Notes or History page |
| FHIR-36564 | Add clarifying markup for CPCDS mapping tables |
| FHIR-36562 | Add CARIN Acronym on first use |
| TC: FHIR-36255 | Formatting issues for PDEX server capability statement |
| FHIR-36237 | Sending Duplicative Data |
| TC: FHIR-36080 | link to published FHIR v4.0.1 |
| TC: FHIR-36079 | removed double link to ChangeHistory |
Technical Corrections are prefixed with "TC: "
The following changes were applied in the Proposed STU 2.0.0 update:
| JIRA Ticket | Change |
|---|---|
| TC: FHIR-36026 | Multiple Technical Corrections |
| FHIR-35868 | Revert US Core References back to 3.1.1 |
| FHIR-34308 | Update US Core and PDex inter-relationship diagram to add Prior Auth in Overview page. |
| FHIR-33382 | Change references to US Core to link to the current 4.0.0 version. Reverted - see FHIR-35868 above. |
| FHIR-33218 | Update Payer-to-Payer Exchange section to clarify use of Bulk FHIR protocols for retrieval of data for a single patient/member only. The flow has been subject to substantial assessment at multiple connectathons and test events. |
| FHIR-33217 | Add a PDex Prior Authorization profile, based on the EOB resource to support the exchange of Prior Authorization information with Members. Added Slices to item adjudication and added consumedunits slice |
| FHIR-33141 | Revert PDex Provenance Recorded definition to the US Core Provenance version |
| FHIR-33173 | Add clarification to use of $everything operation - superceded by updates to Payer-to-Payer exchange |
| FHIR-33216 | Add guidance for use of Consent resource in $member-match operation - superceded by updated to Payer-to-Payer exchange |
| FHIR-33713 | Add Provenance custodian record for receipt of member data from prior payer |
First version of the PDex IG.
Draft of PDex IG
Skeleton version of PDex IG
IG © 2024+ HL7 International / Financial Management. Package hl7.fhir.us.davinci-pdex#2.2.0 based on FHIR 4.0.1. Generated 2026-05-08
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change