b.well consumer-mediated exchange needs consent-version receipts

Define the authorization before acquiring the data

The direct answer is to create a consent record that identifies who authorizes what data movement, for which purpose, recipient, duration, and downstream use. b.well Connected Health's official site describes a consumer-mediated data network and a Fast Healthcare Interoperability Resources-based foundation for acquiring, normalizing, managing, and activating health data. It also says patient consent is central to named life-sciences workflows. Those are provider statements, not evidence that one generic consent governs every product or exchange.

Retain the person and representative where applicable, identity-proofing method, requesting and receiving organizations and applications, data categories and sources, purpose, permitted actions, recipients, onward-disclosure rule, geographic and program scope, start and expiry, revocation method, consent text and version, language and accessibility context, signature or affirmation, policy and legal basis, and verification receipt. An account agreement or app login should not silently stand in for a specific data authorization.

Bind each exchange to the consent it used

Every query, push, import, normalization job, application access, disclosure, and export should reference the evaluated consent version and the exact decision result. Record requester, purpose, source, destination, data scope, patient match, time, route, standard and version, response, denied or omitted data, segmentation behavior, errors, and downstream recipient. If another authority permits or requires exchange, label it separately rather than describing all access as consumer-mediated.

Normalization and aggregation do not erase source restrictions. Keep provenance from each normalized element to its source record, acquisition event, applicable authorization, corrections, and permitted uses. When multiple records have different consent or sensitivity rules, do not infer that a unified view has one uniform sharing state. Missing, restricted, expired, and uncertain authorization should remain visible to the workflow instead of becoming empty data or a generic connection failure.

Propagate changes and revocation to downstream holders

Consent can expire, narrow, expand, or be revoked after data has moved. Preserve the earlier valid state and the effective change rather than rewriting history. Identify open requests, cached or derived data, connected applications, research activities, exports, alerts, and scheduled jobs affected by the change. Send a machine- and human-readable notice where required, retain destination acknowledgement, stop future use under the revoked basis, and route ambiguous retention or deletion questions to accountable privacy and legal owners.

A revocation receipt is not proof that every downstream system deleted data or that deletion is always the correct action. Some records may be subject to retention, legal, clinical, research, or regulatory duties. Record the disposition for each holder: access stopped, future acquisition blocked, use restricted, data deleted, retained under another authority, de-identified under an approved method, or unresolved. Keep that decision separate from the technical success of the notice.

Test one authorization across a changed purpose

A useful evaluation authorizes records from two sources for a care-navigation purpose, normalizes them, sends a subset to an application, then requests research use, changes one recipient, revokes the original authorization, and introduces a source correction after revocation. Reviewers should reproduce every authorization decision, block an unapproved purpose, preserve clinical and legal retention rules, trace derived data, and obtain downstream receipts without erasing exchanges that were valid when they occurred.

b.well's public site supports the attributed description of its consumer-mediated network, FHIR-based data foundation, modular platform, and consent-centered life-sciences positioning. It does not establish a customer's identity proofing, consent language, legal basis, network reach, source completeness, normalization accuracy, segmentation, downstream controls, revocation behavior, security, privacy, regulatory compliance, research validity, clinical use, implementation effort, or outcome. Patients, providers, plans, researchers, privacy, security, data, clinical, compliance, regulatory, and legal owners retain those judgments.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.