Healthcare Compliance

This skill provides engineering guardrails for healthcare and e-health projects. It is not legal advice; use it to shape technical decisions and checklists.

How to Use This Skill

Use this skill whenever:

• The system stores or processes Protected Health Information (PHI).
• You touch patient data, clinical notes, lab results, prescriptions, imaging, or billing linked to a person.
• You design integrations with hospital systems (HL7, FHIR, LIS or RIS, PACS).

Combine it with:

• backend-specialist for API and access control decisions.
• database-architect for schema, retention, and indexing choices.
• security-auditor for security scans and secret management.

1. Regulatory Scope (High-Level)

Focus on common technical expectations across regulations:

• HIPAA (US) – Privacy Rule, Security Rule, audit and breach notification.
• GDPR or local privacy laws – data minimisation, consent, right to access or delete.
• HL7 v2.x – messaging standard used by many legacy hospital systems.
• FHIR (R4 or R5) – modern resource-based REST API standard for clinical data.

Principle: design for least privilege, auditability, and interoperability.

2. PHI Data Classification

Before coding, identify which fields and tables contain PHI:

• Direct identifiers: name, national ID, phone, email, full address.
• Quasi-identifiers: date of birth, postal code, gender, rare diagnosis combinations.
• Clinical content: encounters, diagnoses, prescriptions, lab results, vitals, imaging reports.
• Billing data tied to a person: invoices, insurance details, claim status.

Rules:

• Do not store PHI in free-text logs, analytics events, or error traces.
• Avoid PHI in URLs or document identifiers such as query strings or path parameters.
• Encrypt backups and exports containing PHI.

3. Access Control and Roles

Design role-based access control aligned with clinical workflows:

• Receptionist: schedule, basic demographics, no access to detailed clinical notes.
• Nurse: triage data, vitals, limited orders, partial record view.
• Physician: full clinical record, orders, notes, e-prescriptions.
• Lab or Imaging: orders, results entry, no financial data.
• Billing: invoices, payments, insurance, minimal clinical details.

Engineering guidelines:

• Enforce RBAC server-side, not just in the UI.
• Apply row-level access for sensitive records, for example filter by facility or organisation.
• Prefer allowlists, describing who may access, over blocklists.
• Log every access to high-risk objects such as patient, encounter, and medical record.

4. Audit Trails and Logging

For PHI-bearing objects, the system should answer who did what, when, and to which record.

Minimum requirements:

• Version history for key records, using before or after snapshots or field-level changes.
• Immutable audit log of security-sensitive actions such as login, impersonation, mass exports.
• Record of consent changes, privacy preference updates, and sharing revocations.
• Time-synchronised server clocks (NTP) to make logs reliable.

Logging rules:

• Do not log full payloads of clinical notes, prescriptions, or lab results.
• Prefer identifiers plus minimal context such as record id, action, module, user, timestamp.

5. Data Protection and Deployment

Checklist for secure-by-default deployments:

• Transport: enforce HTTPS or TLS everywhere, including internal APIs.
• At rest: use database encryption at rest and encrypted volumes or backups.
• Secrets: store credentials in a secret manager or environment variables, never in Git.
• Backups: regular encrypted backups with tested restore procedures.
• Retention: configure retention policies per data category such as clinical, billing, logs.
• Isolation: separate production and test datasets; never use real PHI in development.

For Frappe or ERPNext deployments, ensure:

• Site config (site_config.json) does not commit secrets.
• Background workers and schedulers run under least-privilege OS users.
• Only whitelisted hosts and IPs may reach the database and Redis instances.

6. HL7 and FHIR Integration Patterns

When integrating with hospital systems:

• HL7 v2:

  • Typically via TCP or file drops, with messages such as ADT, ORM, ORU.
  • Implement a translation layer that validates and maps segments to internal DocTypes.
  • Keep raw HL7 messages for traceability in a secure, access-controlled store.

• FHIR:

  • Prefer RESTful APIs with JSON.
  • Map DocTypes to FHIR resources such as Patient, Encounter, Observation, MedicationRequest, Appointment.
  • Maintain explicit mapping documentation at field level for every integration.

Security rules:

• Authenticate all integration clients using mutual TLS, OAuth2, or signed tokens.
• Throttle and monitor inbound and outbound traffic for abuse and leaks.

7. Pre-Release Compliance Checklist

Before launching or changing an e-health feature, verify:

• Data classification completed; PHI locations documented.
• RBAC implemented and enforced in backend for all health DocTypes.
• Audit logging enabled for access and modifications of PHI.
• Transport and at-rest encryption configured and tested.
• Backup, restore, and retention policies documented and tested.
• Integrations using HL7 or FHIR authenticated, authorised, and rate-limited.
• No PHI in logs, analytics, or URLs.
• Legal or compliance stakeholders have reviewed changes where required.

Use this checklist as a gate before considering an e-health feature done.