RYAN ZERNACH

Senior AI Systems Engineer

Ryan_Zernach_2025_Senior_AI_Systems_Engineer_Remote_United_States

šŸ” Healthcare HIPAA Compliance and AI Systems Engineering

As a Healthcare AI Systems Engineer, HIPAA compliance is not a legal footnote after implementation. It directly shapes my architecture, my delivery process, and my release gates. Every design choice is filtered through one hard question: does this protect ePHI while still helping clinicians move faster and make better decisions? I design systems so privacy, security, and operational reliability are built into the default behavior instead of relying on people to remember extra steps under pressure. In practice, that means I engineer for privacy rule constraints, security rule controls, and auditable operational discipline across data access, model workflows, and infrastructure.

Related Links
GitHub Profile
Healthcare Mission
AI Engineering Methodologies
Healthcare software engineers designing AI systems that protect sensitive patient data

How HIPAA Changes My Engineering Decisions

In healthcare AI, speed alone is not a success metric. A workflow is only successful if it is useful to clinicians, safe for patients, and defensible in an audit. I make compliance concrete by translating policy language into system behavior that is testable and observable during daily operations.

  • Minimum necessary by default: every service boundary and UI query returns only the ePHI fields needed for the current task, not the full patient record.
  • Role-scoped access control at multiple layers: identity provider claims, API authorization policies, and database row/column rules must all agree before protected data is released.
  • Encryption in transit and at rest, with explicit key ownership, rotation windows, and separation between application operators and key-management authority.
  • Comprehensive, immutable audit trails for every ePHI access, including who accessed what, why, from which workflow, and whether access succeeded or failed.
  • Data-retention and deletion policies encoded into jobs, not just policy docs, so ePHI is not retained longer than the legal and clinical need.

Concrete Examples of Software Respecting ePHI

Respecting ePHI means software intentionally limits exposure at each step: collection, processing, inference, storage, observability, and support operations.

  • Clinical summarization agent: before prompt assembly, middleware strips direct identifiers when not required, injects only relevant chart sections, and blocks prompt logging when protected values are present.
  • Nurse triage inbox: the UI masks phone, DOB, and address by default, then reveals fields with an explicit user action tied to role and encounter context.
  • Model observability pipeline: traces persist tool timing, model version, and rubric scores, but replace patient identifiers with irreversible tokens so debugging stays useful without exposing raw ePHI.
  • Support tooling: internal admin consoles use just-in-time access grants with auto-expiration and mandatory reason codes; every privileged ePHI lookup is reviewable.
  • File export workflows: generated PDFs are encrypted, watermark-stamped, and signed with download events tied to user identity so outbound ePHI movement is provable.
  • Incident response automation: suspected overexposure events trigger immediate access revocation, scoped record re-audit, and notification workflows aligned with breach response obligations.
Related Links
SOC 2 Compliant Mobile App
Book Time with Ryan

Architecture Patterns I Apply in Healthcare AI

I structure healthcare systems so compliance survives real-world pressure. That includes shift handoffs, incident response, on-call debugging, and production changes at speed. The goal is to make the safe path the easiest path for engineers, clinicians, and operators.

  • Treat HIPAA as an architecture constraint, not a final compliance checklist. I design for privacy boundaries from day one.
  • Place policy enforcement close to the data and repeat it at each trust boundary so a single missed guard does not become a full exposure.
  • Separate deterministic controls from model behavior: policy gates must never depend on model correctness or cooperative outputs.
  • Build de-identification and re-identification as explicit services with strict authorization, not ad hoc utility functions.
  • Require end-to-end lineage from user action to datastore read so audits can explain exactly how ePHI moved through the system.

Implementation-Level Safeguards for ePHI

At implementation level, I enforce strict boundary controls: API schemas reject unapproved ePHI fields, queue payload contracts disallow full-record replication, and ETL jobs validate redaction before analytics sinks accept events. In model-serving paths, protected fields are explicitly classified so prompt assembly cannot accidentally include disallowed identifiers. In observability, sampling and retention policies are configured to preserve signal while suppressing sensitive values. When these controls are combined with clear runbooks and audit-friendly telemetry, teams can ship meaningful AI capabilities while staying trustworthy, legally defensible, and operationally resilient.