---
description: >-
  Columns for the member consent feed as flat files: the Provider Access
  opt-out and the Payer-to-Payer opt-in, mapped to the Da Vinci PDex STU 2.1.0
  and HRex 1.2.0 Consent profiles, plus the previous coverage a member
  names and the signed forms and documents of authority behind the decisions.
---

> For the complete documentation index, see [llms.txt](https://www.health-samurai.io/docs/payerbox/llms.txt).
> Use it to discover all available pages before guessing URLs.

---

# Member Consent (CSV)

## Datasets

A member **opts out** of [Provider Access](../../interop-apis/provider-access.md) and **opts in** to [Payer-to-Payer](../../interop-apis/payer-to-payer.md). Each decision becomes one FHIR Consent. Whoever holds the record delivers this feed. Members can also record both choices themselves on the member portal's [Data sharing page](../../fhir-app-portal/member-portal/consent-panel.md), which writes Consents of the same profiles. A system that already holds the decisions as FHIR writes the records itself instead: see [Member Consent (FHIR)](fhir.md).

| Dataset | Target profile |
|---|---|
| [`provider_access_opt_outs`](#provider_access_opt_outs) | [PDex Provider Consent](https://hl7.org/fhir/us/davinci-pdex/STU2.1/StructureDefinition-pdex-provider-consent.html), read by [`$provider-member-match`](../../api-reference/operations/provider-member-match.md) and by every Provider Access export |
| [`payer_to_payer_opt_ins`](#payer_to_payer_opt_ins) | [HRex Consent](https://hl7.org/fhir/us/davinci-hrex/1.2.0/StructureDefinition-hrex-consent.html), the member authorization used to build outbound Payer-to-Payer requests |
| [`previous_coverages`](#previous_coverages) | [HRex Coverage](https://hl7.org/fhir/us/davinci-hrex/1.2.0/StructureDefinition-hrex-coverage.html): which payer to ask, and about whom |
| [`consent_documents`](#consent_documents) | [US Core DocumentReference](https://hl7.org/fhir/us/core/STU6.1/StructureDefinition-us-core-documentreference.html): the signed form a decision points to, and a representative's document of authority |

## Data conventions

| Rule | Detail |
|---|---|
| History | A decision is never edited. A change of mind is a new row with its own `record_id` and a later `captured_at`; the latest `captured_at` per member and switch is the state in force. |
| Freshness | Within one business day of capture. Faster delivery, including event-driven, per engagement. |
| Delivery | One backfill of every decision on file, then deltas with rows new since your last successful load. |
| Keys | `record_id` is your consent system's identifier for the decision, unique across the feed. |
| References | `patient_identifier` from [`patients`](../uscdi/patient-demographics.md#patients), `signer_related_person_id` from [`related_persons`](../uscdi/patient-demographics.md#related-persons), `*_document_id` from [`consent_documents`](#consent_documents). |
| Documents | The signed form and a representative's document of authority travel in [`consent_documents`](#consent_documents), referenced from here by key. The opt-in cannot be built without its signed form: HRex Consent requires a source document. |
| Dates | `date` columns are `YYYY-MM-DD`. `datetime` columns are ISO 8601 with a timezone offset. |

## provider_access_opt_outs

One row per decision on the Provider Access switch.

| Column | Required | Format / values | Example |
|---|---|---|---|
| `record_id` | Yes | your identifier for this decision | `PAC-000117` |
| `patient_identifier` | Yes | patient key from `patients` | `MBR0000012` |
| `choice` | Yes | `opt-out`, `share` (opt back in) | `opt-out` |
| `captured_at` | Yes | datetime the decision was made | `2026-11-03T14:22:00-05:00` |
| `effective_start` | Yes | date the decision takes effect | `2026-11-03` |
| `signer_type` | Yes | `member`, `personal-representative` | `member` |
| `signer_related_person_id` | If `personal-representative` | key from `related_persons` | `RP-88012` |
| `authority_document_id` | If `personal-representative` | key from `consent_documents`; power of attorney, guardianship order or equivalent | `DOC-55190` |
| `signed_form_document_id` | If available | key from `consent_documents` | `DOC-55191` |
| `last_updated` | Yes | datetime this row last changed in your system | `2026-11-03T14:22:00-05:00` |
| `is_deleted` | If retracting | `true` retracts a row delivered in error | |

`opt-out` becomes `provision.type` = `deny`, `share` becomes `permit`. `captured_at` is `Consent.dateTime`, `effective_start` is `provision.period.start`. `performer` is the member's Patient; a `personal-representative` row adds the RelatedPerson as a `provision.actor` with the role of their authority (`POWATT`, `GUARD` or `RESP`). The rest of the profile is filled from plan configuration, not from the row: `status` `active`, `scope` `patient-privacy`, the two category codes (`IDSCL`, which PDex 2.1.0 requires, and the API purpose `provider-access` from the PDex 2.2.0 draft, which tells the two decisions apart: IDSCL alone does not), your Organization as `organization` and as the `source` actor, `provision.action` = `disclose`, and `policyRule` = `cric`, the value the profile fixes. The check the operation runs is [documented with the operation](../../api-reference/operations/provider-member-match.md#matching-behavior).

## payer_to_payer_opt_ins

One row per decision on the Payer-to-Payer switch. One election covers previous and concurrent payers.

| Column | Required | Format / values | Example |
|---|---|---|---|
| `record_id` | Yes | your identifier for this decision | `P2P-000342` |
| `patient_identifier` | Yes | patient key from `patients` | `MBR0000012` |
| `choice` | Yes | `opt-in`, `withdraw` | `opt-in` |
| `scope` | If `opt-in` | `all`, `non-sensitive` (everything except what state or federal law treats as sensitive) | `all` |
| `captured_at` | Yes | datetime the decision was made | `2026-11-03T14:22:00-05:00` |
| `effective_start` | If `opt-in` | date the consent takes effect | `2026-11-03` |
| `effective_end` | If `opt-in` | date the consent expires, set by your policy; the record cannot be built without it | `2027-12-31` |
| `signer_type` | Yes | `member`, `personal-representative` | `member` |
| `signer_related_person_id` | If `personal-representative` | key from `related_persons` | `RP-88012` |
| `authority_document_id` | If `personal-representative` | key from `consent_documents` | `DOC-55190` |
| `signed_form_document_id` | If `opt-in` | key from `consent_documents` | `DOC-55192` |
| `last_updated` | Yes | datetime this row last changed in your system | `2026-11-03T14:22:00-05:00` |
| `is_deleted` | If retracting | `true` retracts a row delivered in error; a withdrawal is a `withdraw` row | |

An `opt-in` becomes an HRex Consent with `provision.type` = `permit`, `provision.period` from `effective_start` and `effective_end`, `sourceReference` to the signed form, and `policy.uri` from `scope`: `all` maps to `#sensitive`, `non-sensitive` to `#regular`. The names are the profile's: `#sensitive` is the wider grant. `performer` is the member's Patient, or the RelatedPerson for a `personal-representative` row. Both required actors are populated for each exchange: each plan named in `previous_coverages` is a `source` actor, and your Organization is `recipient`; `provision.action` is `disclose`; the categories are `IDSCL` and the API purpose `payer-to-payer`, as above. A `withdraw` row closes the election from `captured_at`: the opt-in's Consent is [retired](../../api-reference/resources/consent.md#retire-a-record), `status` `inactive` without its profile.

## previous_coverages

One row per previous or concurrent coverage the member names when opting in.

| Column | Required | Format / values | Example |
|---|---|---|---|
| `record_id` | Yes | your identifier for this entry | `PCV-000342-1` |
| `consent_record_id` | Yes | `record_id` of the `opt-in` row it was named on | `P2P-000342` |
| `patient_identifier` | Yes | patient key from `patients` | `MBR0000012` |
| `payer_name` | Yes | as the member gives it, ideally as printed on the member ID card | `Anthem Blue Cross` |
| `payer_id` | If known | the payer's identifier in the payer directory you use | `00060` |
| `member_id` | Yes | the member's ID with that payer; required to build the HRex Coverage used for member match | `XYZ123456789` |
| `relationship` | Yes | `self`, `spouse`, `child`, `other`; whether the coverage was in the member's own name [subscriber-relationship](https://terminology.hl7.org/CodeSystem-subscriber-relationship.html) | `self` |
| `coverage_kind` | Yes | `previous`, `concurrent` | `previous` |
| `last_updated` | Yes | datetime this row last changed in your system | `2026-11-03T14:22:00-05:00` |
| `is_deleted` | If retracting | `true` retracts this row | |

`relationship` is required by HRex Coverage and only the member can supply it. `member_id` becomes both `subscriberId` and the `MB` identifier. `coverage_kind` becomes `status`: `cancelled` for a previous plan, `active` for a concurrent one. The plan becomes `payor`: the Organization of a plan registered in [Consent Settings](../../fhir-app-portal/consent-settings.md#other-health-plans-members-can-pick) when `payer_id` or `payer_name` identifies one, otherwise an HRex Organization named `payer_name` and numbered by `record_id`; the same Organization is the opt-in's `source` actor. No coverage dates: the match runs on demographics and identifiers. The member's Patient must declare the HRex Patient Demographics profile, which `beneficiary` requires.

## consent_documents

One row per document behind a decision: the signed form, and the document of authority a personal representative acts under. The document itself is the file; this row is its index card.

{% file src="../../assets/data-integration/consent_documents.89132cfe.csv" %}
consent_documents.csv Data template with example rows
{% endfile %}

| Column | Required | Format / values | Example |
|---|---|---|---|
| `record_id` | Yes | your stable key for this document | `DOC-55191` |
| `patient_identifier` | Yes | patient key from `patients` | `MBR0000012` |
| `type_code` | Yes | LOINC document type: `59284-0` Consent Document for a signed form; `64298-3` Power of attorney; `64299-1` Legal document for a guardianship order or another document of authority; `UNK` when none fits [US Core DocumentReference Type](https://healthsamurai.github.io/fhir-valueset-viewer/#url=http://hl7.org/fhir/us/core/ValueSet/us-core-documentreference-type) | `59284-0` |
| `type_text` | If `UNK` | what the document is | `Conservatorship order` |
| `attachment_file` | Yes | path relative to the delivery root; PDF, JPEG or PNG | `attachments/DOC-55191.pdf` |
| `document_date` | Recommended | datetime the document was signed or issued | `2026-11-03T14:22:00-05:00` |
| `is_deleted` | If retracting | `true` retracts this row | |

- `type_code` has a required binding, so the type must come from that value set. Two codes cover the feed: `59284-0` for every signed form, `64298-3` for a power of attorney; `64299-1` for the other documents of authority.
- `author` is not a column: it comes from the decision row that names the document, the member's Patient for `member` and the RelatedPerson for `personal-representative`. A document named by several decisions, such as one power of attorney for both switches, is delivered once.
- Payerbox sets `status` to `current`, `category` to `clinical-note` (the profile requires a category, and that is the one code in the US Core category value set), `custodian` to your Organization and `content.format` to `urn:ihe:iti:xds:2017:mimeTypeSufficient`, and reads the attachment's content type and size from the stored file. None of those are columns.
- A decision points to its documents, so they must load first: deliver `consent_documents` in the same window as the decisions, before them or with them. An `opt-in` without its signed form is not built.

These resources are read by [Provider Access](../../interop-apis/provider-access.md) and [Payer-to-Payer](../../interop-apis/payer-to-payer.md).