Health Data Beyond HIPAA: Multi-Regulation Medical Data Governance

HIPAA is usually the first compliance label teams mention when they discuss medical AI. It is rarely the only one that matters. Real healthcare workflows mix clinical content, payment context, employee access concerns, regional transfer restrictions, and contracts that promise more than the law strictly requires. Keeptrusts helps by turning that broad policy discussion into enforceable technical controls at the AI gateway: sanitize sensitive text, narrow the provider lane, constrain risky output, and preserve review-ready evidence.

Use this page when

You run AI workflows that touch clinical notes, patient support requests, utilization review, or medical operations data.
You need runtime controls that address health-data handling beyond a simple HIPAA checklist.
You want one operating model for minimization, provider restrictions, medical-output safety, and evidence exports.

Primary audience

Primary: Technical Leaders
Secondary: Technical Engineers, compliance and privacy reviewers

The problem

Medical AI programs rarely fail because a team forgot the word HIPAA. They fail because the team treated HIPAA as the whole operating model. In production, health data is bundled with many other constraints: regional privacy rules, payer obligations, data-processing agreements, retention limits, and internal governance over who may review the resulting records.

The request path itself is also messy. A single prompt can contain a patient narrative, an MRN-like identifier, an appointment artifact, a support transcript, and payment details copied from another system. If that request is forwarded unchanged, the provider receives more context than it needs, and the organization loses the ability to explain later which elements were necessary, which were removed, and which route handled the surviving request.

There is an output-side problem as well. Even if input minimization is strong, a model can still produce diagnosis-like or dosage-like language that your organization does not want delivered without a disclaimer or an explicit block. Health-data governance is therefore not only about what goes in. It is also about how medically risky output is constrained before it reaches a user.

The solution

Keeptrusts gives you a practical split of responsibilities.

Use PII Detector with healthcare_mode to redact or block personal and health-adjacent identifiers in the request stream. The current implementation explicitly adds HIPAA-style heuristics for names, addresses, MRNs, device identifiers, and text mentions of biometric or photo identifiers. That is useful when operators send messy real-world text rather than perfectly structured records.

Use DLP Filter for the identifiers and terms that are unique to your environment, such as study codes, internal patient-routing markers, or phrases that should never leave your network. Built-in PII matching is strong, but it cannot know your local naming schemes.

Use Data Routing Policy to ensure sanitized medical traffic only reaches provider targets that declare zero retention, no training, in-memory handling, and other required constraints. This matters whenever the legal answer is not just "is the content protected" but also "which provider path is allowed to see it."

Finally, add Healthcare Compliance so output that looks like diagnosis or treatment advice can be blocked or automatically prefixed with the right disclaimer. That makes the program safer and easier to explain during review.

Implementation

This stack works well for patient-support, clinical-operations, and utilization-review prompts that need both input and output controls:

pack:
  name: multi-reg-medical-governance
  version: "1.0.0"
  enabled: true

providers:
  targets:
    - id: medical-zdr
      provider: openai
      model: gpt-5.4-mini-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0
        in_memory_only: true
        sanitized: true
        accepts_tokenized_input: true
        allow_internet_egress: false
        local_only_processing: true

policies:
  chain:
    - pii-detector
    - dlp-filter
    - data-routing-policy
    - audit-logger
    - healthcare-compliance

policy:
  pii-detector:
    action: redact
    healthcare_mode: true
    pci_mode: false
    redaction:
      marker_format: label
      include_metadata: true

  dlp-filter:
    detect_patterns:
      - 'SITE-[A-Z]{2}-PAT-[0-9]{8}'
      - 'STUDY-[0-9]{6}'
    blocked_terms:
      - raw pathology image export
      - full dicom dump
      - external claims attachment
    action: block
    fuzzy_matching: true
    max_distance: 1
    sensitivity_level: high

  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    require_in_memory_only: true
    sanitize_before_provider: true
    tokenize_sensitive_fields: true
    allow_internet_egress: false
    local_only_processing: true
    on_no_compliant_provider: block
    log_provider_selection: true

  audit-logger: {}

  healthcare-compliance:
    blocked_patterns:
      - diagnose you with
      - prescribe
      - increase the dose
      - stop taking
    required_disclaimers:
      - This is not medical advice.
      - Consult a licensed clinician for diagnosis or treatment decisions.
    fda_class: III

The ordering is deliberate. Sanitize the request before routing. Route only to compliant providers. Then govern the output for diagnosis-like language. That sequence keeps the system from treating medical safety and data handling as separate projects.

From an operations perspective, pair the runtime controls with evidence collection. kt events gives you the governed decision stream, and kt export-jobs lets you package event, escalation, or audit-log evidence asynchronously for monthly or quarterly review. That evidence trail is often what distinguishes a mature medical AI program from a promising demo.

Results and impact

Teams that move beyond a HIPAA-only lens usually see two immediate improvements. First, fewer raw medical identifiers and internal routing artifacts are exposed upstream because redaction and blocking happen before the provider call. Second, governance conversations become more precise because the control set now addresses minimization, provider handling, output safety, and evidence as separate requirements rather than one vague compliance promise.

There is also a practical audit benefit. When a reviewer asks how patient-support prompts are handled, you can point to the policy chain, the provider metadata, and the exported evidence window instead of relying on tribal knowledge or application-specific logging.

Key takeaways

Health-data governance for AI is broader than HIPAA and should include minimization, provider handling, output controls, and evidence retention.
PII Detector with healthcare_mode handles common health-adjacent identifiers and heuristic text patterns.
DLP Filter covers organization-specific study, routing, or export markers that built-in detectors do not know.
Data Routing Policy enforces provider-side promises such as zero retention and no training.
Healthcare Compliance adds output-phase protection when the model starts sounding like it is diagnosing or prescribing.

Health Data Beyond HIPAA: Multi-Regulation Medical Data Governance

Use this page when​

Primary audience​

The problem​

The solution​

Implementation​

Results and impact​

Key takeaways​

Next steps​