# Change History - Da Vinci Payer Data Exchange v2.2.0

* [**Table of Contents**](toc.md)
* **Change History**

## Change History

| |
| :--- |
| *Page standards status:*[Informative](http://hl7.org/fhir/R4/versions.html#std-process) |

[Previous Page - Member-Authorized OAuth2 Exchange](member-authorizedoauth2exchange.md)

### STU 2.2.0 Release Overview

#### Summary of changes between STU 2.1.0 and STU 2.2.0

The PDex IG has been the subject of significant industry feedback. The latest Peer review generated over 50 tickets. As a result the IG has benefited from contributions from industry. indeed the primary driver for creation of this STU 2.2.0 version of the PDex IG was the request from the industry to create a Provider Access API that more closely matched Provider workflows, and was significantly easier for Payers to maintain the Treatment Relationships lists that the CMS-0057 regulation required. . The focus for the post STU2.1.0 changes to the PDex IG can therefore be summarized as follows:

* The addition of a new Provider-member-match operation, enabling Providers to submit a list of patients they wanted to receive information about. This is the Provider Access V2 addition to the IG. It does not change the operation of the original Provider Access API (now named V1). The Provider Access V2 match operation simply creates a dynamic group, that is evaluated and agreed by the payer, before returning the group identifier to enable the davinci-data-export operation. Without this refinement a unparameterized request by a provider to the davinci-data-export operation could result in all information for all attributed members to be returned to the provider. This is a dramatically bigger API request that could result in entire histories for thousands of members to be compiled and returned to the requesting provider. Provider Access V2 therefore enables a provider to request information for the members they are actively treating in the immediate/near future.
* Provider Access V1 has not been removed. It is still planning to be used by Payers to enable information about a fixed group of members to be communicated to a Provider. This use case is well-suited to the sharing of information with providers engaged in Value-based Care contracts.
* The other change implemented in PDex STU 2.2.0 is intended to simplify alignment with federal regulation. PDex initially supported Da Vinci PAS STU 2.1.0. However, CMS-0062-F is proposing that IG's STU 2.2.1 version become a required version. This latest version of the PDex IG therefore implements support for Da Vinci PAS STU 2.2.1. This required the addition of new PAS ClaimResponse extensions, introduced in PAS STU 2.2.1. This is being done to simplify the conversion of resources from Da Vinci PAS ClaimResponse to PDex Prior Authorization ExplanationOfBenefit profile. This change may however require a minor technical correction in Da Vinci PAS to expand the context for use of the newly added extensions. Currently those extensions are limited to use in a Claim Response. A similar change had to be accommodated in a previous version of the Da Vinci PAS IG.

### STU2.2.0 Peer Review Reconciliation

All items in this section were reconciled and approved as Block Vote 2 at the HL7 Financial Management Working Group meeting (FM WGM) on 2026-05-18. Motion: Mark Scrimshire / Rick Geimer. Vote: 5-0-0 (Affirmative-Negative-Abstain).

> **Note:** Changes to Provider Access v2, `$provider-member-match`, and all associated profiles (ProviderMemberMatchGroup, ProviderMemberNoMatchGroup, MemberProviderTreatmentRelationship, ProviderTreatmentAttestation, MemberOptOut Group) are **not** breaking changes — Provider Access v2 is entirely new in STU 2.2.0 and has no STU 2.1.0 installed base to affect.

#### Breaking Changes

**The following items affect features that existed in STU 2.1.0. Implementers with existing Payer-to-Payer or Patient Access deployments should review these before upgrading.**

| | |
| :--- | :--- |
| [FHIR-56480](https://jira.hl7.org/browse/FHIR-56480) | **`$bulk-member-match` response wire format (Payer-to-Payer).**STU 2.1.0 returned a Parameters envelope; STU 2.2.0 mandates Group ndjson as the primary format.**Mitigation:**responders**MAY**additionally include the legacy Parameters ndjson file, allowing a single endpoint to serve both STU 2.1.0 and STU 2.2.0 requesters. |
| [FHIR-56437](https://jira.hl7.org/browse/FHIR-56437) | **`$everything` must return claims EOBs.**Prior IG said the server**SHOULD**filter to Prior Authorization-only records; revised IG says the server**SHALL**return the full in-scope data set including claims EOBs. |
| [FHIR-56505](https://jira.hl7.org/browse/FHIR-56505) | **Payer-to-Payer data payload: SHOULD → SHALL.**The full data payload requirement (US Core clinical data, CARIN BB claims, PDex Prior Authorization records) is now mandatory rather than recommended. |
| [FHIR-56496](https://jira.hl7.org/browse/FHIR-56496) | **5-year data window reframed.**Previous IG required responders to cap returned data at 5 years; revised IG establishes 5 years as a floor on the requestor's obligation — responders must be capable of returning at least 5 years and may return more. |
| [FHIR-56441](https://jira.hl7.org/browse/FHIR-56441) | **Contained Patient handling in `$bulk-member-match` response.**Responders**SHALL**now actively remove base-FHIR-prohibited elements (`meta.versionId`,`meta.lastUpdated`,`meta.security`, nested contained resources) from the submitted Patient before placing it in the response Group's`contained[]`. The previous rule was passive ("SHALL NOT modify"). Removal is explicitly not a violation of the preservation requirement. |
| [FHIR-56185](https://jira.hl7.org/browse/FHIR-56185) | **OAuth scope URL for `$bulk-member-match` corrected.**The documented scope was`…/OperationDefinition/bulk-member-match`(lower-case); the correct canonical URL is`…/OperationDefinition/BulkMemberMatch`(CamelCase). Authorization servers configured with the old URL must be updated. |
| [FHIR-56456](https://jira.hl7.org/browse/FHIR-56456) | **17 narrative pages promoted from `informative` to `trial-use`.**Conformance language (SHALL / SHOULD / MAY) on the main specification pages is now normative. See the full ticket entry below for the list of affected pages. |
| [FHIR-56540](https://jira.hl7.org/browse/FHIR-56540)**(partial)** | **`PDexMemberMatchGroup` and `PDexMemberNoMatchGroup` (Payer-to-Payer profiles) tightened.**`* type = #person`and`* actual = true`added where previously unconstrained. Low practical impact — conformant instances already use these values. |
| [FHIR-56497](https://jira.hl7.org/browse/FHIR-56497)**(partial)** | **`Group.managingEntity` restricted to `Reference(Organization)` on `PDexMemberMatchGroup` and `PDexMemberNoMatchGroup`.**Low practical impact — the managing entity is always a payer Organization in these profiles. |

#### Substantive Changes

**Behavior changes, new features, new artifacts, expanded conformance obligations, or significant narrative additions that change the implementation surface. None of these are backwards-incompatible with STU 2.1.0; the Breaking Changes that ARE backwards-incompatible are listed in the section above.**

| | |
| :--- | :--- |
| [FHIR-57521](https://jira.hl7.org/browse/FHIR-57521) | Persuasive (applied). Bumped the Da Vinci PAS dependency from 2.1.0 to 2.2.1 in`sushi-config.yaml`and adopted three new ClaimResponse-side extensions on the[PDex Prior Authorization profile](StructureDefinition-pdex-priorauthorization.md)for improved member-facing transparency of inpatient prior authorization and reviewer attribution:`extension-admissionDates`(0..1 MS) and`extension-dischargeDate`(0..1 MS) on`item.extension`to convey the authorized admission and discharge dates for inpatient PA; and`extension-claimResponseReviewer`(0..1 MS) at the root`extension`to attribute the responsible reviewer practitioner. Pairs with PAS Technical Correction[FHIR-57522](https://jira.hl7.org/browse/FHIR-57522)to broaden the three new extensions' context to include`ExplanationOfBenefit`(the PAS 2.1.0 precedent for the seven existing PAS extensions PDex re-uses on its PA EOB profile). The residual context-mismatch information messages are suppressed in`input/ignoreWarnings.txt`with a WHY rationale that references FHIR-57522 and notes the suppressions will be removed once a corrected PAS package is published and PDex consumes it |
| [FHIR-56545](https://jira.hl7.org/browse/FHIR-56545) | Persuasive (applied as proposed). 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-56536](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/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) |
| [FHIR-56509](https://jira.hl7.org/browse/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) §pdex-273 / §pdex-274 / §pdex-277 reworded so the requirement is on the**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-56507](https://jira.hl7.org/browse/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](artifacts-by-api.md)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-56499](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/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-56498](https://jira.hl7.org/browse/FHIR-56498) | Persuasive (applied as proposed). 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-56493](https://jira.hl7.org/browse/FHIR-56493) | Persuasive (applied as proposed). 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-56492](https://jira.hl7.org/browse/FHIR-56492) | Persuasive (applied as proposed). Payer-to-Payer Exchange (bulk) §7.5: §pdex-129 previously stated "Bulk Payer-to-Payer exchange**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)](http://hl7.org/fhir/uv/bulkdata/STU2/)as the specification whose async-delivery semantics are required (operation kick-off via HTTP POST, status polling per the[FHIR R4 Asynchronous Request Pattern](https://hl7.org/fhir/R4/async.html), 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](https://jira.hl7.org/browse/FHIR-56491) | Persuasive (applied as proposed; interpretation 1 confirmed and made explicit). Payer-to-Payer Exchange (single member) §7.4: §pdex-191 previously read "Payers**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 is the method required by that rule). Reworded §pdex-191 to make this explicit: a Payer that implements single-member Payer-to-Payer Exchange (for example, to support legacy CMS-9115-style member-initiated payer-to-payer requests or any other use case for which single-member exchange is more appropriate than multi-member bulk exchange) SHALL do so by following the content of this section, and a Payer that implements only the Bulk Payer-to-Payer Exchange remains conformant with this IG. The §pdex-209 narrative below already states that the three data-retrieval methods (individual queries /`$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](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/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 §pdex-261a). The default is: where the payer determines that disclosing opt-out status would itself constitute a disclosure the member did not authorize (under applicable state privacy law, the member's stated preference, or the payer's privacy policy), the payer**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-56453](https://jira.hl7.org/browse/FHIR-56453) | Persuasive (applied as proposed). 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](https://jira.hl7.org/browse/FHIR-56452) | Persuasive (applied as proposed). 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](https://jira.hl7.org/browse/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-56391](https://jira.hl7.org/browse/FHIR-56391) | Persuasive with Modification (narrative-only; structural addition deferred). The submitter observed that the[PDex Prior Authorization profile](StructureDefinition-pdex-priorauthorization.md)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](StructureDefinition-pdex-priorauthorization.md)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-56258](https://jira.hl7.org/browse/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-154b / §pdex-154c) that codifies the rule, gives the worked 3-member example from the ticket (2 valid Consent → MatchedMembers; 1 expired Consent → ConsentConstrainedMembers; the expired-Consent member is**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](https://jira.hl7.org/browse/FHIR-56486)). No FSH structural changes; the §pdex-154 / §pdex-155 / §pdex-156 anchors are unchanged. The submitter's suggestion to also reflect this guidance on the Implementer Support page is supported by the on-page subsection but is not a separate page edit |
| [FHIR-56252](https://jira.hl7.org/browse/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-56184](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/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 |

#### Non-Substantive Changes

**Technical corrections (typos, link fixes, wording cleanup), narrative-only clarifications that don't change conformance, parallel-narrative alignments, and dispositions of "Already Addressed" / "Duplicate" / "Considered for Future Use" tickets.**

| | |
| :--- | :--- |
| [FHIR-56546](https://jira.hl7.org/browse/FHIR-56546) | Persuasive (applied as proposed). Added a link from the Provider-Member-Match OperationDefinition page narrative to the Provider $multi-member-match Response Parameters profile so readers can navigate directly between the operation and its response shape |
| [FHIR-56543](https://jira.hl7.org/browse/FHIR-56543) | Duplicate of[FHIR-56545](https://jira.hl7.org/browse/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.35.1), and the "How does Provider Access Work?" narrative (§7.3.2) — specifically that the three artifacts disagreed on how non-matched members and opt-out members are returned. This was reconciled under FHIR-56545 (also in this STU 2.2.0 update), which aligned all three artifacts on the 3-bucket response model:`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 |
| TC:[FHIR-56537](https://jira.hl7.org/browse/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-56511](https://jira.hl7.org/browse/FHIR-56511) | Persuasive (applied as proposed). Fix formatting of the "how does provider access work" section so list-item indentation renders correctly in the published narrative |
| TC:[FHIR-56504](https://jira.hl7.org/browse/FHIR-56504) | Various typo and minor wording corrections across narrative pages |
| [FHIR-56495](https://jira.hl7.org/browse/FHIR-56495) | Persuasive (applied as proposed; correction extended to sibling Group example instances for consistency). 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-56479](https://jira.hl7.org/browse/FHIR-56479) | Persuasive (applied as proposed). Use Case Scenarios §8.2 ("Useful Patient History for Providers"): §pdex-386 previously read "These types of data**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 §pdex-386 anchor is retained for stability of any external references; the table itself is unchanged |
| TC:[FHIR-56455](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/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" |
| [FHIR-56444](https://jira.hl7.org/browse/FHIR-56444) | Persuasive (applied as proposed — disambiguation; no normative levels changed). The submitter observed an apparent inconsistency between §pdex-05 ([PDex Provenance](PDexProvenance.md), "A Provenance resource**SHOULD**be provided with each member-related resource…") and §pdex-127 ([Overview](overview.md), "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](PDexProvenance.md)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-05, §pdex-87 — SHOULD**(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-127 Transmitter Provenance, not a substitute. The parallel statement at §pdex-87 on the[Handling Data Provenance](handlingdataprovenance.md)page was reworded the same way and now explicitly cross-references §pdex-127. No conformance levels were changed (§pdex-127 remains SHALL, §pdex-05 / §pdex-87 remain SHOULD); the change is purely disambiguation |
| [FHIR-56443](https://jira.hl7.org/browse/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)](https://www.ecfr.gov/current/title-45/part-170/section-170.215#p-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](introduction.md)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-56442](https://jira.hl7.org/browse/FHIR-56442) | Persuasive (applied as proposed — disambiguation; no normative levels changed for the requester-side MAY). Payer-to-Payer Exchange (bulk) §7.5.5.1.4 (`_typeFilter`): the submitter asked whether the**MAY**in §pdex-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](https://hl7.org/fhir/uv/bulkdata/STU2/)`_typeFilter`semantics. §pdex-180 is now restricted to the requester's choice (a requesting Payer**MAY**include`_typeFilter`); new §pdex-180a / §pdex-180b / §pdex-180c / §pdex-180d cover, respectively: responder`_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-182 is unchanged. No structural artifact (CapabilityStatement, OperationDefinition) changes |
| [FHIR-56440](https://jira.hl7.org/browse/FHIR-56440) | Persuasive (applied as proposed). Payer-to-Payer Exchange (bulk) §7.5.1 (Performing Bulk Data Exchange): the closing sentence at §pdex-139 — "[Payer-to-Payer (single Member) Exchange](payertopayerexchange.md)),**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-140 data list immediately below. The intended meaning, supported by the surrounding paragraph, is that the Bulk Payer-to-Payer Exchange and the Single-Member Payer-to-Payer Exchange exchange the**same data set**(which §pdex-140 then enumerates). Resolved by (i) splitting the consent sentence (§pdex-138) into its own paragraph for readability; (ii) rewriting §pdex-139 as a complete sentence: "The Bulk Payer-to-Payer Exchange described in this section and the Payer-to-Payer (single Member) Exchange**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-138 and §pdex-139 anchors are retained for stability of any external references |
| [FHIR-56439](https://jira.hl7.org/browse/FHIR-56439) | Persuasive (applied as proposed). Payer-to-Payer Exchange (bulk) §7.5: §pdex-133 / §pdex-134 used the term "supporting clinical data" / "supporting data" where[42 CFR 422.121(b)(4)(ii)(B)](https://www.ecfr.gov/current/title-42/part-422/section-422.121#p-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"; §pdex-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](StructureDefinition-pdex-priorauthorization.md)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-56438](https://jira.hl7.org/browse/FHIR-56438) | Persuasive (applied as proposed). Payer-to-Payer Exchange (bulk) §7.5: §pdex-132 was a garbled run-on sentence that fused a descriptive clause about how status-change dates are recorded internally with a normative clause about what the API response must include, with mangled punctuation in between ("If the Prior Authorization processor changes the status of the Prior Authorization then the date of change will be recorded, In the Provider and Payer-to-Payer APIs and Prior Authorization that has changed status in the previous 12 months (from the date of enquiry)**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 §pdex-132 reinforces the status-change portion of §pdex-131. The §pdex-132 anchor and its**SHALL**strength are unchanged; the substantive obligation (PA status-change-in-last-12-months is returned) is preserved |
| [FHIR-56436](https://jira.hl7.org/browse/FHIR-56436) | Persuasive (applied as proposed). Two parallel narrative locations — Provider Access (v1) §7.2.5 (§pdex-350) and Payer-to-Payer Exchange (bulk) §7.5.3 (§pdex-157) — claimed implementers**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-350 now state that implementers**SHALL**support the`Group`search parameters enumerated in the[PDex Server CapabilityStatement](CapabilityStatement-pdex-server.md)(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](http://hl7.org/fhir/R4/group.html#search)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-350 conformance ID anchors are retained; conformance level (SHALL) is unchanged but the obligation is now precisely defined |
| [FHIR-56435](https://jira.hl7.org/browse/FHIR-56435) | Persuasive (applied as proposed — scope clarification; SHALL strength unchanged). Overview §2.3 (§pdex-127): the submitter asked whether §pdex-127 ("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") 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 §pdex-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](PDexProvenance.md)section added under FHIR-56444 is included so readers see how §pdex-127 (per-exchange SHALL) and §pdex-04 / §pdex-05 (per-resource Author/Source SHOULD) fit together. The §pdex-127 anchor and SHALL strength are unchanged; the change is purely scope clarification |
| TC:[FHIR-56434](https://jira.hl7.org/browse/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 |
| [FHIR-56433](https://jira.hl7.org/browse/FHIR-56433) | Persuasive (applied as proposed). Two parallel narrative locations carried directly contradictory conformance levels for the same expectation: Provider Access (v1) §7.2.2 §pdex-326 said "Health Plans**SHALL**implement the pdex-provider-consent" while Provider Access (v2) §7.3.3 §pdex-275 said "Health Plans**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 §pdex-275 (v2), since the**MAY**is consistent with the IG's overall scope (per[FHIR-56509](https://jira.hl7.org/browse/FHIR-56509)and the[Scope of this section](provider-access-api-v2.md)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-326 anchors are retained for stability of any external references |
| TC:[FHIR-56425](https://jira.hl7.org/browse/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-56400](https://jira.hl7.org/browse/FHIR-56400) | Already Addressed by[FHIR-56545](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/FHIR-56107)also reported (about`MatchedMembers`); both halves were corrected under[FHIR-56545](https://jira.hl7.org/browse/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-56380](https://jira.hl7.org/browse/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-56299](https://jira.hl7.org/browse/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](provider-access-api-v2.md)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](https://jira.hl7.org/browse/FHIR-56480)Level B (deeper Group-profile alignment).**Q2 (MemberOptOut discriminator):**the[`MemberOptOut` profile description](StructureDefinition-pdex-member-opt-out.md)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](https://jira.hl7.org/browse/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 |
| [FHIR-56177](https://jira.hl7.org/browse/FHIR-56177) | Not Persuasive (with clarifying narrative). The submitter asked why the[PDex Provider Access Consent profile](StructureDefinition-pdex-provider-consent.md)uses`patient-privacy`on`Consent.scope`rather than the[v3 PurposeOfUse ValueSet](http://terminology.hl7.org/ValueSet/v3-PurposeOfUse)used by TEFCA. The premise conflates two structurally distinct elements:`Consent.scope`is bound by FHIR R4 to the[ConsentScope](http://terminology.hl7.org/CodeSystem/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](https://jira.hl7.org/browse/FHIR-56537)resolution on the`ProviderTreatmentAttestation`profile. Resolved by adding`^short`/`^definition`narrative on the`scope`element in the[PDex Provider Access Consent profile](StructureDefinition-pdex-provider-consent.md)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 |
| TC:[FHIR-56160](https://jira.hl7.org/browse/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-56138](https://jira.hl7.org/browse/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](provider-access-api-v2.md), 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 §pdex-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](provider-access-api.md)`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-56107](https://jira.hl7.org/browse/FHIR-56107) | Already Addressed by[FHIR-56545](https://jira.hl7.org/browse/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 |

### STU 2.2.0 Update

All items in this section were reconciled and approved as part of PDex-Vote-1 (block vote).

#### Significant Design and Behavioral Changes

**Implementers with STU 2.1.0 deployments should review these items.**

| | |
| :--- | :--- |
| [FHIR-53311](https://jira.hl7.org/browse/FHIR-53311) | Persuasive (applied). Redesigned Provider Access API to use`$provider-member-match`as the first step, replacing static Attribution List Group resources. |
| [FHIR-55987](https://jira.hl7.org/browse/FHIR-55987) | Persuasive (applied). Removed requirements to record bulk export tracking details (`lastTransmitted`,`lastResources`,`lastFilters`) as extensions on Patient and Group resources. |
| [FHIR-53256](https://jira.hl7.org/browse/FHIR-53256) | Persuasive with Modification (applied). Clarified that`$bulk-member-match`is asynchronous per the FHIR R4 Async Request Pattern; the OperationDefinition declares no inline`out`parameters. |
| [FHIR-56242](https://jira.hl7.org/browse/FHIR-56242) | Persuasive (applied). Renamed Provider Member Match v2 input parameter from`MembersToMatch`to`MemberBundle`and`Consent`to`TreatmentAttestation`to align with Payer-to-Payer naming. |
| [FHIR-56075](https://jira.hl7.org/browse/FHIR-56075) | Persuasive (applied). Reconciled`$provider-member-match`OperationDefinition IN parameters with the Parameters profiles; added links to IN and OUT profiles from the OperationDefinition page. |
| [FHIR-55927](https://jira.hl7.org/browse/FHIR-55927) | Persuasive with Modification (applied). Added provision for (patient + coverage) pairs to be returned in all three Bulk Member Match response Group resources to support cross-referencing when multiple MemberBundles are submitted for the same member. |

#### New Capabilities

| | |
| :--- | :--- |
| [FHIR-53815](https://jira.hl7.org/browse/FHIR-53815) | Persuasive (applied). Added`SearchParameter-pdex-consent-action`and a supporting extension to enable direct retrieval of a member's Provider Access opt-out Consent by`provision.type`. |
| [FHIR-53793](https://jira.hl7.org/browse/FHIR-53793) | Persuasive (applied). Added a navigable index of all SHALL / SHALL NOT / SHOULD / SHOULD NOT / MAY conformance requirements from the narrative pages. |
| [FHIR-51845](https://jira.hl7.org/browse/FHIR-51845) | Persuasive with Modification (applied). Added`SearchParameter-pdex-group-characteristic-value-reference`to enable Group searches by`characteristic.valueReference`. |
| [FHIR-51377](https://jira.hl7.org/browse/FHIR-51377) | Persuasive (applied). Added`pdex-consent-api-purpose`CodeSystem and ValueSet bound to`Consent.category`to distinguish Consent resources across Provider Access, Payer-to-Payer, and Patient Access APIs. |
| [FHIR-53655](https://jira.hl7.org/browse/FHIR-53655) | Persuasive (applied). Expanded`Consent.performer`in the Provider Access Consent profile to allow`RelatedPerson`for opt-outs exercised by a legally recognized personal representative. |

#### Clarifications and Non-Breaking Updates

| | |
| :--- | :--- |
| [FHIR-49943](https://jira.hl7.org/browse/FHIR-49943) | Persuasive with Modification (applied). Clarified that`$multi-member-match`is synchronous;`$davinci-data-export`is the async step. Made the sync/async boundary explicit in the narrative. |
| [FHIR-50183](https://jira.hl7.org/browse/FHIR-50183) | Persuasive with Modification (applied). Corrected §6.4.4 to describe the Payer-to-Payer workflow; removed Provider Access content that had been incorrectly placed there. |
| [FHIR-50184](https://jira.hl7.org/browse/FHIR-50184) | Persuasive with Modification (applied). Added async polling guidance for Provider Access and Payer-to-Payer bulk APIs; corrected workflow diagrams to show poll-until-complete / retrieve NDJSON. |
| [FHIR-50227](https://jira.hl7.org/browse/FHIR-50227) | Persuasive (applied). Reconciled PDex single`$member-match`with the HRex response profile; clarified must-support vs. should-support for`MemberIdentifier`and`MemberID`. |
| [FHIR-51571](https://jira.hl7.org/browse/FHIR-51571) | Persuasive with Modification (applied). Clarified #delta exportType responsibility following removal of tracking extensions (FHIR-55987); providers supply`_since`; added guidance for edge cases. |
| [FHIR-52056](https://jira.hl7.org/browse/FHIR-52056) | Persuasive (applied). Corrected §2.3 Provenance from`SHALL incorporate`to`SHOULD accept and retain`, aligning with §6.1 and the outcome of FHIR-47054. |
| [FHIR-52066](https://jira.hl7.org/browse/FHIR-52066) | Persuasive (applied). Restructured Data Mapping to provide explicit SHALL/SHOULD obligations separately for clinical data (US Core), claims data (CARIN BB), and prior authorization data (PDex Prior Auth). |
| [FHIR-52871](https://jira.hl7.org/browse/FHIR-52871) | Persuasive (applied). Tightened`matchedMember`contained-Patient extension cardinality from`0..1`to`1..1`in response Group profiles. Updated response example to use New Payer identifiers. |
| [FHIR-53087](https://jira.hl7.org/browse/FHIR-53087) | Considered — Question answered (no change applied). Clarified that`Group.managingEntity`references the Payer, not the Provider. Provider references use`Group.characteristic.valueReference`. |
| [FHIR-53616](https://jira.hl7.org/browse/FHIR-53616) | Persuasive (applied). Updated §6.2.1 diagram to show the correct async pattern: HTTP POST → poll content-location → retrieve NDJSON. |
| [FHIR-55928](https://jira.hl7.org/browse/FHIR-55928) | Persuasive (applied). Removed conflicting`§pdex-182`SHALL for`$member-match`; single-member Payer-to-Payer`$member-match`is optional (MAY at §pdex-176). |
| [FHIR-55981](https://jira.hl7.org/browse/FHIR-55981) | Considered for Future Use. Adopting the FHIR R5 Async Bundle pattern for`$bulk-member-match`is deferred to a future major release; PDex targets FHIR R4. |

#### Technical Corrections

| | |
| :--- | :--- |
| TC:[FHIR-50458](https://jira.hl7.org/browse/FHIR-50458) | Persuasive (applied — Technical Correction). Corrected Provider examples to replace non-conformant v2-0203`NPI`code with the correct`PRN`code from the FHIR identifier-type ValueSet. |
| TC:[FHIR-55620](https://jira.hl7.org/browse/FHIR-55620) | Persuasive (applied — Technical Correction). Removed`CoverageToLink`from the Provider Member Match example; providers are not a new payer. |
| TC:[FHIR-55640](https://jira.hl7.org/browse/FHIR-55640) | Persuasive (applied — Technical Correction). Consolidated Provider Member Match examples to use`MemberBundle`consistently; removed the conflicting`Parameters-provider-bulk-member-match-in`example. |
| TC:[FHIR-56259](https://jira.hl7.org/browse/FHIR-56259) | Persuasive (applied — Technical Correction). Updated Provider Access Consent examples so`Consent.performer`references the Practitioner by identifier (NPI) rather than by resource reference. |

### STU 2.1.0-ballot Reconciliation

| | |
| :--- | :--- |
| [FHIR-50105](https://jira.hl7.org/browse/FHIR-50105) | Clarify Asynchronous Response for Bulk Member Match |
| [FHIR-49110](https://jira.hl7.org/browse/FHIR-49110) | Optional inclusion of Financials in Provider Access API to support VBC use cases |
| STU 2.1 Block Vote 3 |   |
| [FHIR-48991](https://jira.hl7.org/browse/FHIR-48991) | Fix broken Links and other issues identified in QA Report |
| [FHIR-48922](https://jira.hl7.org/browse/FHIR-48922) | $davinci-data-export param exportType should be mandatory |
| [FHIR-48088](https://jira.hl7.org/browse/FHIR-48088) | Code Systems should be in THO or be granted an exemption |
| [FHIR-48079](https://jira.hl7.org/browse/FHIR-48079) | Separate API details from the Data payload section |
| [FHIR-48063](https://jira.hl7.org/browse/FHIR-48063) | Member-authorized exchange is underspecified |
| [FHIR-48061](https://jira.hl7.org/browse/FHIR-48061) | "PDex Implementation, Actors, Interactions, Data Payloads and Methods" page important or redundant? |
| [FHIR-48057](https://jira.hl7.org/browse/FHIR-48057) | Missing must support definition |
| [FHIR-48036](https://jira.hl7.org/browse/FHIR-48036) | Separate data mapping and patient matching discussion |
| [FHIR-48023](https://jira.hl7.org/browse/FHIR-48023) | Sub-field must support language inconsistency |
| [FHIR-47778](https://jira.hl7.org/browse/FHIR-47778) | Include the full HRex privacy and security requirements |
| [FHIR-47761](https://jira.hl7.org/browse/FHIR-47761) | Security and Privacy and Access Permissions Page not accessible |
| [FHIR-47562](https://jira.hl7.org/browse/FHIR-47562) | Please add a "Plain Language Summary about HL7 and this Guide" to the home page. |
| [FHIR-47056](https://jira.hl7.org/browse/FHIR-47056) | Clarify OAuth2.0 workflow for Payer to Payer |
| [FHIR-47053](https://jira.hl7.org/browse/FHIR-47053) | Require MemberId parameter to be returned in $member-match |
|   |   |
| STU 2.1 Block Vote 2 |   |
| [FHIR-48701](https://jira.hl7.org/browse/FHIR-48701) | AppointmentBook hook usage for Provider Access use case |
| [FHIR-48313](https://jira.hl7.org/browse/FHIR-48313) | What are implementers supposed to follow for exportType |
| [FHIR-48077](https://jira.hl7.org/browse/FHIR-48077) | provenance details are spread across several pages and are inconsistently linked |
| [FHIR-48073](https://jira.hl7.org/browse/FHIR-48073) | Use Case Scenarios page not easily reachable |
| [FHIR-48072](https://jira.hl7.org/browse/FHIR-48072) | Data Mapping Conformance Requirements |
| [FHIR-48070](https://jira.hl7.org/browse/FHIR-48070) | integrate separate sections on data mapping |
| [FHIR-48058](https://jira.hl7.org/browse/FHIR-48058) | Unclear references to Da Vinci ATR |
| [FHIR-48037](https://jira.hl7.org/browse/FHIR-48037) | CapabilityStatements don't belong under Data Mapping |
| [FHIR-47057](https://jira.hl7.org/browse/FHIR-47057) | Don't require mapping claims data to US Core resources if sending as ExplanationOfBenefit resources |
| [FHIR-47055](https://jira.hl7.org/browse/FHIR-47055) | Don't require five year time limit on bulk Payer to Payer exchange |
| [FHIR-47054](https://jira.hl7.org/browse/FHIR-47054) | Make saving Provenance information received through Payer to Payer optional |
| [FHIR-46761](https://jira.hl7.org/browse/FHIR-46761) | Add Prev / bottom / Next to header/footer |
| STU 2.1 Block Vote 1 |   |
| [FHIR-48675](https://jira.hl7.org/browse/FHIR-48675) | Add Hyperlink to PDex Server Capability Statement |
| [FHIR-48369](https://jira.hl7.org/browse/FHIR-48369) | Conflicting statements on OAuth-authorized exchange |
| [FHIR-48076](https://jira.hl7.org/browse/FHIR-48076) | With Mod: Remove superseded CDS Hooks page |
| [FHIR-48074](https://jira.hl7.org/browse/FHIR-48074) | With Mod: provider-controlled information requests and filtering page not easily reachable |
| [FHIR-48056](https://jira.hl7.org/browse/FHIR-48056) | With Mod: Multiple CapabilityStatement descriptions not in sync and should be collapsed |
| [FHIR-47794](https://jira.hl7.org/browse/FHIR-47794) | Change should to shall |
| [FHIR-47792](https://jira.hl7.org/browse/FHIR-47792) | rewrite for clarity and grammar |
| [FHIR-47789](https://jira.hl7.org/browse/FHIR-47789) | Not Persuasive: Change should to shall |
| [FHIR-47787](https://jira.hl7.org/browse/FHIR-47787) | Clarify concept of changed status |
| [FHIR-47786](https://jira.hl7.org/browse/FHIR-47786) | Change should to shall |
| [FHIR-47785](https://jira.hl7.org/browse/FHIR-47785) | Change should to shall |
| [FHIR-47784](https://jira.hl7.org/browse/FHIR-47784) | Confusing Phrase |
| [FHIR-47783](https://jira.hl7.org/browse/FHIR-47783) | Clarify the Regulatory requirements |
| [FHIR-46681](https://jira.hl7.org/browse/FHIR-46681) | Add US Core 7.0.0 support to the IG |
| STU 2.1 Technical Corrections |   |
| TC:[FHIR-48071](https://jira.hl7.org/browse/FHIR-48071) | Rendered text in the middle of example json |
| TC:[FHIR-48068](https://jira.hl7.org/browse/FHIR-48068) | Reference to profile pages instead of data mapping pages |
| TC:[FHIR-48067](https://jira.hl7.org/browse/FHIR-48067) | mebedded -> embedded |
| TC:[FHIR-48065](https://jira.hl7.org/browse/FHIR-48065) | member health history us core sections should be subsections |
| TC:[FHIR-48040](https://jira.hl7.org/browse/FHIR-48040) | device row in capability statement table shifted over incorrectly |
| TC:[FHIR-48039](https://jira.hl7.org/browse/FHIR-48039) | un-rendered link on the capability statement page |
| TC:[FHIR-48024](https://jira.hl7.org/browse/FHIR-48024) | Incorrect Section Numbering |
| TC:[FHIR-48022](https://jira.hl7.org/browse/FHIR-48022) | Oral Basis Profile is the Dental Profile? |
| TC:[FHIR-47973](https://jira.hl7.org/browse/FHIR-47973) | Large number of technical corrections |
| TC:[FHIR-47788](https://jira.hl7.org/browse/FHIR-47788) | grammatical errors and typos |

### STU 2.1.0 Update

| | |
| :--- | :--- |
| TC:[FHIR-46479](https://jira.hl7.org/browse/FHIR-46479) | Change CARIN Blue Button IG link to 2.1.0-snapshot1 |
| [FHIR-46476](https://jira.hl7.org/browse/FHIR-46476) | Provide guidance on handling of unstructured data for exchange via Payer-to-Payer API |
| [FHIR-45992](https://jira.hl7.org/browse/FHIR-45992) | Overview page should mention different APIs instead of exchange methods |
| [FHIR-42964](https://jira.hl7.org/browse/FHIR-42964)[FHIR-43375](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/FHIR-45969) | Specify a means to search for different types of groups. |
| [FHIR-46444](https://jira.hl7.org/browse/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 _t[changehistory.md](changehistory.md)ypeFilter. 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](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/FHIR-45356) | Change milsEndpoint examples to use correct code from NdhAssociatedServersTypeCS |
| [FHIR-45355](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/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 opt-out members from Group | Remove OptOut Extension |
| Define OptedOut Extension to capture member opt-out | Added OptedOut Extension to PDexProviderGroup to record member opt out from data sharing with attributed providers |

### STU 2.0.0-ballot:Ballot Reconciliation

| | |
| :--- | :--- |
| 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](https://jira.hl7.org/browse/FHIR-41675) | Remove duplicate codes from Provenance Agent Type |
| TC:[FHIR-41497](https://jira.hl7.org/browse/FHIR-41497) | Missing reference to CDS Hooks diagram |
| TC:[FHIR-41399](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/FHIR-41398) | Typo at the bottom of section 5.0.4.3 ("4.2" vs. "5.2") |
| [FHIR-41381](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/FHIR-41307) | Conflicting Links to HRex Coverage Profile |
| [FHIR-41177](https://jira.hl7.org/browse/FHIR-41177) | Capturing adjudication (determination) date for pre-auth |
| [FHIR-40517](https://jira.hl7.org/browse/FHIR-40517) | Section numbering is broken |
| Created Examples for mTLS | Created Examples for MtlsOrganization and MtlsEndpoint |
| [FHIR-40357](https://jira.hl7.org/browse/FHIR-40357) | Possible typo in Data Mapping specification |
| [FHIR-40239](https://jira.hl7.org/browse/FHIR-40239) | Missing endpoint URLs? |
| [FHIR-36626](https://jira.hl7.org/browse/FHIR-36626) | Review all mappings as significant errors have been detected - Reviewed against CARIN-BB STU2 |
| [FHIR-36602](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/FHIR-36601) | Review all mappings for DiagnosticReport - Reviewed against CARIN-BB STU2 |
| [FHIR-36598](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/FHIR-39424) | Update table of profiles for payer-to-payer exchange |
| [FHIR-39424](https://jira.hl7.org/browse/FHIR-39434) | We need a new OperationDefinition for patient-export-pdex |
| [FHIR-39314](https://jira.hl7.org/browse/FHIR-39314) | Need detail w.r.t. reconciling new session with Consent from earlier interaction |
| [FHIR-36626](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/FHIR-38767) | Typo in 5.2.1.3 Future Direction for Discovery and Registration |
| [FHIR-38708](https://jira.hl7.org/browse/FHIR-38708) | Clarification on payer directory queries |
| [FHIR-38707](https://jira.hl7.org/browse/FHIR-38707) | Clarifications on dynamic client registration and first token request |
| [FHIR-38706](https://jira.hl7.org/browse/FHIR-38706) | Consent reference to DocumentReference in member match request clarification - |
| TC:[FHIR-38705](https://jira.hl7.org/browse/FHIR-38705) | Endpoint bundle example is not valid |
| TC:[FHIR-38696](https://jira.hl7.org/browse/FHIR-38696) | Wrong link - NationalDirectory Endpoint resource |
| [FHIR-38650](https://jira.hl7.org/browse/FHIR-38650) | PDex defines an incorrect request pattern for Patient-level bulk export |
| [FHIR-38097](https://jira.hl7.org/browse/FHIR-38097) | ExplanationOfBenefit description clarification for use of item level, header level adjudication |
| BallotRec-Vote5 |   |
| [FHIR-38096](https://jira.hl7.org/browse/FHIR-38096) | For Pdex Prior Authorization EOB, reviewAction extension not available at header level adjudication. |
| [FHIR-37904](https://jira.hl7.org/browse/FHIR-37904) | Add Privacy and Security section to IG |
| [FHIR-36598](https://jira.hl7.org/browse/FHIR-36598) | Review all mappings for Encounter. |
| [FHIR-36495](https://jira.hl7.org/browse/FHIR-36495) | CDS Card should not return an access token |
| [FHIR-36315](https://jira.hl7.org/browse/FHIR-36315) | Unclear definitions of filtering vs restricting cases |
| TC:[FHIR-36174](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/FHIR-37778) | Link to the HREX Coverage takes you to the Patient Demographic Profile |
| [FHIR-37645](https://jira.hl7.org/browse/FHIR-37645) | Consent presentation for P2P |
| [FHIR-37644](https://jira.hl7.org/browse/FHIR-37644) | Consent Revocation for P2P |
| [FHIR-36599](https://jira.hl7.org/browse/FHIR-36599) | Review 835 and all mappings to diagnostics. |
| [FHIR-36572](https://jira.hl7.org/browse/FHIR-36572) | Create a Formal Specification or Conformance Expectations page/section |
| [FHIR-36462](https://jira.hl7.org/browse/FHIR-36462) | Incorrect Diagram, Consent considerations, everything operation (Duplicate of[FHIR-36461](https://jira.hl7.org/browse/FHIR-36461)) |
| [FHIR-36254](https://jira.hl7.org/browse/FHIR-36254) | Missing details of payer-to-payer mutual authentication |
| [FHIR-36223](https://jira.hl7.org/browse/FHIR-36223) | PDEX defined their own version of an already existing code system |
| TC:[FHIR-36176](https://jira.hl7.org/browse/FHIR-36176) | Correction needed in ExplanationOfBenefit-PDexPriorAuth1.json |
| [FHIR-36078](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/FHIR-37577) | Change use of _profile to ExplanationOfBenefit.use to filter on "preauthorization" |
| [FHIR-37576](https://jira.hl7.org/browse/FHIR-37576) | Duplicate to FHIR-37577 |
| [FHIR-37546](https://jira.hl7.org/browse/FHIR-37546) | Consent expiration for P2P Data Exchange |
| [FHIR-36767](https://jira.hl7.org/browse/FHIR-36767) | $member-match operation conformance not defined |
| [FHIR-36629](https://jira.hl7.org/browse/FHIR-36629) | change from are expected to shall |
| [FHIR-36601](https://jira.hl7.org/browse/FHIR-36601) | Review all mappings for DiagnosticReport (MedicationDispense). |
| [FHIR-36462](https://jira.hl7.org/browse/FHIR-36462) | Incorrect Diagram, Consent considerations, everything operation |
| BallotRec-Vote2 |   |
| [FHIR-36885](https://jira.hl7.org/browse/FHIR-36885) | ExplanationOfBenefit.use = preauthorization |
| [FHIR-36772](https://jira.hl7.org/browse/FHIR-36772) | PDEX Provenance page. Broken section |
| [FHIR-36767](https://jira.hl7.org/browse/FHIR-36767) | $member-match operation conformance not defined |
| [FHIR-36600](https://jira.hl7.org/browse/FHIR-36600) | Review all mappings for Coverage |
| [FHIR-36597](https://jira.hl7.org/browse/FHIR-36597) | Invalid data population instruction for Condition |
| [FHIR-36596](https://jira.hl7.org/browse/FHIR-36596) | Invalid data population instruction for CareTeam |
| [FHIR-36563](https://jira.hl7.org/browse/FHIR-36563) | No issues; this section is dense but necessary in defining scope. |
| [FHIR-36352](https://jira.hl7.org/browse/FHIR-36352) | Expand CPCDS Undefined Acronym |
| [FHIR-36337](https://jira.hl7.org/browse/FHIR-36337) | Update Name Column for Lab Result |
| TC:[FHIR-36075](https://jira.hl7.org/browse/FHIR-36075) | Link to US Core 3.1.1 actually links to HL7 home |
| TC:[FHIR-36314](https://jira.hl7.org/browse/FHIR-36314) | Formatting fixes in Care Team element table |
| Ballot-Rec-Vote1 |   |
| TC:[FHIR-37366](https://jira.hl7.org/browse/FHIR-37366) | Vital Signs not referenced in Capability Statement |
| [FHIR-36603](https://jira.hl7.org/browse/FHIR-36603) | Note that CPCDS is external and informative |
| [FHIR-36580](https://jira.hl7.org/browse/FHIR-36580) | Update references to HRex to published 1.0.0 version |
| TC:[FHIR-36575](https://jira.hl7.org/browse/FHIR-36575) | Make the CapabilityStatement rendering more reader friendly |
| [FHIR-36573](https://jira.hl7.org/browse/FHIR-36573) | Correction: Added pages to drop-down menu |
| TC:[FHIR-36569](https://jira.hl7.org/browse/FHIR-36569) | Create a Change Notes or History page |
| [FHIR-36564](https://jira.hl7.org/browse/FHIR-36564) | Add clarifying markup for CPCDS mapping tables |
| [FHIR-36562](https://jira.hl7.org/browse/FHIR-36562) | Add CARIN Acronym on first use |
| TC:[FHIR-36255](https://jira.hl7.org/browse/FHIR-36255) | Formatting issues for PDEX server capability statement |
| [FHIR-36237](https://jira.hl7.org/browse/FHIR-36237) | Sending Duplicative Data |
| TC:[FHIR-36080](https://jira.hl7.org/browse/FHIR-36080) | link to published FHIR v4.0.1 |
| TC:[FHIR-36079](https://jira.hl7.org/browse/FHIR-36079) | removed double link to ChangeHistory |

Technical Corrections are prefixed with "TC: "

### STU 2.0.0

The following changes were applied in the Proposed STU 2.0.0 update:

| | |
| :--- | :--- |
| TC:[FHIR-36026](https://jira.hl7.org/browse/FHIR-36026) | Multiple Technical Corrections |
| [FHIR-35868](https://jira.hl7.org/browse/FHIR-35868) | Revert US Core References back to 3.1.1 |
| [FHIR-34308](https://jira.hl7.org/browse/FHIR-34308) | Update US Core and PDex inter-relationship diagram to add Prior Auth in Overview page. |
| [FHIR-33382](https://jira.hl7.org/browse/FHIR-33382) | Change references to US Core to link to the current 4.0.0 version. Reverted - see[FHIR-35868](https://jira.hl7.org/browse/FHIR-35868)above. |
| [FHIR-33218](https://jira.hl7.org/browse/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](https://jira.hl7.org/browse/FHIR-33217) | Add a[PDex Prior Authorization profile](StructureDefinition-pdex-priorauthorization.md), 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](https://jira.hl7.org/browse/FHIR-33141) | Revert[PDex Provenance](StructureDefinition-pdex-provenance.md)Recorded definition to the US Core Provenance version |
| [FHIR-33173](https://jira.hl7.org/browse/FHIR-33173) | Add clarification to use of $everything operation - superseded by updates to[Payer-to-Payer exchange](payertopayerexchange.md) |
| [FHIR-33216](https://jira.hl7.org/browse/FHIR-33216) | Add guidance for use of Consent resource in $member-match operation - superseded by updated to[Payer-to-Payer exchange](payertopayerexchange.md) |
| [FHIR-33713](https://jira.hl7.org/browse/FHIR-33713) | Add[Provenance custodian](Provenance-1000101.md)record for receipt of member data from prior payer |

### STU 1.0.0

First version of the PDex IG.

### STU 0.1.0

Draft of PDex IG

### STU 0.0.1

Skeleton version of PDex IG

[Next Page - Credits](credits.md)