Data Sharing and Opt-Out Behavior

Patient360 manages how patient data is shared, accessed, and restricted across external data exchange networks, including opt-out behavior. Opting out stops new data from being shared going forward. It does not remove data already shared or stored in accordance with applicable network rules and organizational policies, nor prevent access to data previously retrieved in accordance with those rules.

Data Exchange Models

Health Gorilla supports multiple data exchange models that differ in how data is retrieved and shared. Patient consent is enforced across all models, but the impact of opt-out depends on how data is obtained and managed, as well as where enforcement occurs within the data flow.

• Patient360: Retrieves data from external networks (e.g., Carequality, CommonWell, eHealth Exchange) and combines it with data ingested through integrations.

  • Data is normalized, deduplicated, and stored for subsequent access
  • Data remains available after retrieval
  • Opt-out does not prevent querying external networks
  • Future queries may return fewer results after opt-out
  • Responder systems may limit results based on their own consent enforcement

• Other exchange models: Health Gorilla also supports contribution-based data sharing models (e.g., GorillaNet), where organizations submit data that is distributed to other participants. In these models, opt-out stops new data from being shared but does not remove data already contributed or previously distributed to other participants.

Functional Behavior

Applies to Patient360 and, where applicable, other contribution-based exchange models, with enforcement handled at the Master Patient Index (MPI) through platform-level consent enforcement.

• Data Sharing (Outbound): When an authorized user marks a patient as opted out, the system stops sharing new clinical data generated after that point with external networks and Health Gorilla-managed networks by excluding the patient from outbound exchange and contribution workflows.
• Data Retrieval (Inbound): Providers can continue to query and retrieve available patient data from external networks through Patient360. Results depend on network participation rules, responder consent enforcement, and patient matching outcomes.
• Non-Retroactive Effect: External organizations may retain access to data shared before opt-out if they previously retrieved and stored it in accordance with their own policies. The system does not revoke or delete previously exchanged data and does not issue recall or deletion events to external systems.
• Network Participation Model ("Give-to-Get"): Health Gorilla participates in networks that require contribution for access. When a patient is marked as opted out, the system removes that patient’s data from outbound contribution but does not restrict inbound query access where permitted by network rules and responder consent enforcement. This contribution model applies to certain exchange workflows and is distinct from Patient360 retrieval behavior.
• Product-Level Enforcement: Previously retrieved and stored data remains available in Patient360. Future queries may return fewer results after opt-out. In contribution-based exchange models, opt-out prevents new outbound sharing while leaving previously available data unchanged.

Key Rules

• Opt-out applies only to data generated after the change (forward-looking)
• Opt-out affects outbound data sharing only and does not prevent queries to external networks
• Providers can continue querying external data where permitted by network rules and organizational policies
• Data shared prior to opt-out cannot be revoked or deleted from external systems
• Opt-out is applied uniformly across all purposes of use (e.g., Treatment and IAS)

Consent Model

The consent model is configured at the tenant and patient levels and enforced through the MPI across Patient360 and other exchange models.

• Default Consent (Tenant Level): Organizations define consent during onboarding as either share (opt-out model; sharing enabled by default) or protect (opt-in model; sharing disabled by default), in accordance with applicable regulatory and organizational requirements. Additional consent validation may be required depending on configuration.
• Patient-Level Override: Authorized users can update the opt-out setting for individual patients, overriding the default consent configuration with patient-level settings taking precedence over tenant defaults.

Consent status is stored in the MPI and applied across workflows and products, including associated audit data.

Purpose of Use Scope

Patient consent and opt-out are not scoped by purpose of use in the current implementation.

• Opt-out is applied uniformly across all request types
• The same behavior applies to Treatment and IAS requests
• The system does not differentiate consent enforcement based on purpose of use

Opt-Out Process

1. Patient Request: A patient communicates a request to opt out of data sharing to the organization (practice or provider).
2. Administrative Action: An authorized user updates the patient’s opt-out status in the system using the Patient Chart (UI) or API.
3. System Enforcement: The platform records the change in the MPI and enforces opt-out behavior across Patient360 and, where applicable, other exchange workflows for subsequent data sharing events, including query response filtering, outbound exchange exclusion, and contribution controls.
4. Ongoing Management: Authorized users can update or reverse the opt-out status at any time based on patient direction or organizational policy, with changes tracked for audit and enforcement purposes.

Configuration and Control

Opt-out settings are managed within the Health Gorilla platform, either in the Patient Chart or via API. Only authorized users with appropriate role-based permissions can modify opt-out status.

Client organizations are responsible for managing consent, user access, and downstream use of data in accordance with their policies. Health Gorilla does not control how data is used or retained after it is accessed.

Audit and Tracking

Opt-out activity is tracked within the MPI. Each update to a patient’s opt-out status is captured with a timestamp. The system maintains a history of these changes to support compliance and audit requirements.

Scenario-Based Behavior

1. Patient opts out (sharing → not sharing): The system stops sharing new data generated after the opt-out with external networks; providers can continue to query and retrieve available data where permitted; external organizations may retain data previously retrieved in accordance with their policies, and responder systems may still return historical data based on their own rules.
2. Patient opts back in (not sharing → sharing): The system resumes sharing new data generated after the change; previously withheld data is not retroactively shared unless generated or re-sent through standard workflows or reintroduced through normal ingestion or exchange processes.
3. Default consent = share, patient opts out: Patient-level setting overrides tenant default; the system stops outbound sharing for that patient only.
4. Default consent = protect, patient opts in: Patient-level setting overrides tenant default; the system allows outbound sharing for that patient going forward.
5. External organizations previously accessed the data: External systems may retain previously retrieved data; opt-out does not trigger deletion or recall of data already obtained, and no system-level revocation mechanism is executed.
6. IAS request with existing opt-out: If a patient has opted out of data sharing, the same opt-out behavior applies to IAS requests. The responding organization may not return data based on the patient’s opt-out status.

Operational Impact

Opt-out may affect the data returned in Patient360 queries. Future queries may return fewer records after opt-out, while previously retrieved data may still remain available. Reduced or missing data may reflect patient consent settings rather than a system issue. Opt-out is expected system behavior and does not indicate a technical error.

Limitations

Current platform capabilities do not include built-in reporting for opted-out patients. Data shared prior to opt-out is not removed, and the system does not retroactively update or delete previously exchanged records. Client organizations are responsible for tracking opt-out populations as needed.

Industry Context

Industry interoperability and consent models follow similar patterns but vary by network, vendor, and regulatory environment.

• Opt-In vs Opt-Out Models: Opt-out states enable data sharing by default and require patients to decline; opt-in states require explicit patient consent before sharing.
• Forward-Looking Enforcement: Systems typically apply opt-out prospectively and do not retract previously shared data.
• Data Persistence: Receiving organizations retain data once they store it in their systems.
• Contribution-Based Networks: Many national networks (e.g., Carequality, CommonWell) require participants to contribute data to enable query access.
• Consent Management Variability: Systems may manage consent at the patient, organization, or network level depending on implementation.

Health Gorilla vs Industry Behavior

Summary

Health Gorilla enforces patient opt-out by preventing outbound data sharing for opted-out patients on a forward-looking basis while continuing to support permitted inbound data access. Opt-out is applied uniformly across all purposes of use in the current implementation and is enforced at the MPI level across Patient360 and related exchange workflows. Opt-out settings are configurable at both tenant and patient levels in accordance with applicable policies and network requirements, with enforcement occurring across query, ingestion, and exchange processing stages.