[ HEALTHCARE CONSULTING ] // HIPAA + EHR + FHIR

Healthcare software that survives an OCR audit, not just a sprint demo.

Custom builds, EHR integrations, and AI workflows for hospital systems, payers, and digital-health startups — engineered against Epic, Cerner, Allscripts, HL7v2, and FHIR R4 with HIPAA controls baked in from commit one.

Veteran-Owned SDVOSB
[001 / 005] Field Conditions

Most healthcare software projects fail at the audit, not the architecture review.

// SITUATION

The pattern repeats. A digital-health team builds a slick product against a sandbox EHR, then discovers eight months in that audit logging is bolted on, PHI is leaking into Datadog, and the BAA chain has a gap at the third subprocessor. Or a hospital IT team kicks off a Cerner integration assuming HL7v2 ADT feeds are reliable, only to find the interface engine drops messages silently and reconciliation is a manual spreadsheet. The code works. The compliance posture doesn't. Remediation costs more than the original build.

  • ▸ PHI ending up in application logs, error trackers (Sentry, Rollbar), or LLM prompts sent to non-BAA endpoints.
  • ▸ HL7v2 listeners with no idempotency, no dead-letter handling, and no reconciliation against the source EHR.
  • ▸ Audit trails that capture writes but not reads, leaving 45 CFR 164.312(b) requirements unmet at audit time.
  • ▸ BAAs signed with the primary vendor but missing across subprocessors — analytics, observability, AI providers.
100%
PHI-bearing code reviewed against HIPAA Security Rule
4-6 wks
Typical first FHIR vertical slice in production
SDVOSB
Certified for VA and federal health set-asides
[002 / 005] Operational Approach

Build for the auditor first, the user second, the demo third.

  1. STEP-01

    PHI boundary and threat model

    Before any code, we map every system that touches PHI: EHR, billing, analytics, support tools, vendor SaaS. We draw the trust boundary, identify covered entity vs business associate roles, and lock down BAAs. AWS HealthLake, Azure Health Data Services, or self-hosted — pick once, document why.

  2. STEP-02

    FHIR-first integration, HL7v2 where forced

    We default to FHIR R4 against Epic on FHIR, Cerner Ignite, or Allscripts FHIR APIs. When an interface engine (Mirth, Rhapsody, Corepoint) is the only path, we write idempotent HL7v2 listeners with proper ACK/NACK semantics and dead-letter queues — not fire-and-forget.

  3. STEP-03

    Audit trail as a first-class system

    Every PHI read, write, export, and admin action emits an immutable audit event. We use append-only stores (CloudTrail + S3 Object Lock, or equivalent) and structure events to satisfy 45 CFR 164.312(b). Reviewers can answer 'who saw this chart' in under a minute.

  4. STEP-04

    Staging with synthetic PHI only

    Production PHI never touches dev or staging. We generate synthetic datasets using Synthea or de-identified extracts validated against Safe Harbor. Engineers debug against realistic data shapes without ever creating a breach notification trigger from a misrouted log line.

  5. STEP-05

    Pre-audit dry runs before go-live

    Six weeks before launch we run a mock HIPAA Security Rule audit against the system: access reviews, encryption at rest and in transit, key rotation, incident response runbooks, BAA inventory. Findings get fixed, not filed. Then we ship.

// TYPESCRIPT PATTERN 
// FHIR R4 patient lookup against Epic with audit logging
// Every PHI access emits an immutable audit event before returning data.

import { FhirClient } from './fhir-client';
import { auditLog } from './audit';

export async function getPatient(
  patientId: string,
  actor: { userId: string; role: string; sessionId: string },
  purpose: 'TREATMENT' | 'PAYMENT' | 'OPERATIONS'
) {
  // 1. Authorize BEFORE the read. Deny by default.
  if (!canAccess(actor, patientId, purpose)) {
    await auditLog.write({
      type: 'PHI_ACCESS_DENIED',
      actor, patientId, purpose, ts: Date.now(),
    });
    throw new ForbiddenError('access denied');
  }

  // 2. Emit audit event FIRST. If audit write fails, we do not read PHI.
  await auditLog.write({
    type: 'PHI_ACCESS',
    actor, patientId, purpose,
    resource: `Patient/${patientId}`,
    ts: Date.now(),
  });

  // 3. Read from Epic FHIR. SMART-on-FHIR token, short TTL.
  const client = new FhirClient(process.env.EPIC_FHIR_BASE!);
  const patient = await client.read('Patient', patientId);

  // 4. Strip fields the caller's role is not entitled to see.
  return redactByRole(patient, actor.role);
}

Audit-before-read is the pattern that survives an OCR investigation — losing the PHI read log is worse than losing the read itself.

[003 / 005] Common Questions

Field FAQ.

→ Do you sign a BAA, and what does your subcontractor chain look like?

Yes. We sign a Business Associate Agreement before any engagement that touches PHI, and we maintain BAAs with every downstream subprocessor (cloud provider, observability vendor, error tracker). We provide a full subprocessor list on request. We do not use offshore subcontractors for PHI-bearing work, and engineers on healthcare engagements complete HIPAA training annually with documented attestation.

→ Which EHR integrations have you actually shipped?

We've built production integrations against Epic (App Orchard / Showroom apps using SMART on FHIR and HL7v2 via Bridges), Cerner / Oracle Health (Ignite APIs and CCL where needed), Allscripts (Unity and FHIR), and athenahealth. We've also worked through Redox and Health Gorilla as integration intermediaries when direct EHR access wasn't on the table. We can speak to the specific quirks of each before you sign anything.

→ FHIR or HL7v2 — which should we use?

FHIR R4 if the EHR exposes the resources you need and the hospital IT team will provision API access. It's faster to build, easier to test, and the tooling is better. HL7v2 over an interface engine (Mirth, Rhapsody, Corepoint) is still the reality for ADT feeds, lab results, and most real-time clinical workflows in legacy environments. We frequently build hybrid systems — FHIR for reads, HL7v2 for event-driven writes.

→ How do you handle PHI in AI / LLM workflows?

Three rules. First, only use LLM endpoints covered by a signed BAA — Azure OpenAI, AWS Bedrock with Anthropic, or self-hosted models. The public OpenAI API is not HIPAA-eligible by default. Second, log every prompt and completion to your audit trail, not the vendor's. Third, redact or tokenize PHI before it leaves your trust boundary when the use case allows. We design the data flow before we pick the model.

→ Are you SDVOSB-certified for VA and federal health work?

Yes. VooStack is SDVOSB-certified through the SBA's Veteran Small Business Certification program, which makes us eligible for set-aside and sole-source awards at the VA, MHS GENESIS work under DHA, and other federal health contracts. We've worked within the VA's technical environment and understand the ATO process, FedRAMP boundary inheritance, and the documentation expectations that come with federal healthcare delivery.

→ What does a typical healthcare engagement timeline look like?

Discovery and threat modeling runs 2–3 weeks: data flows, BAAs, EHR access provisioning, environment setup. A first integrated vertical slice — one FHIR resource, audit logging, auth, deployed to a HIPAA-eligible environment — typically lands in weeks 4–6. Full production go-live for a focused scope is usually 3–5 months. EHR vendor approval cycles (App Orchard review, for example) can add 6–12 weeks and are scheduled in parallel.

→ Can you modernize a legacy clinical application without breaking workflows?

Yes, and the answer is almost never a rewrite. We typically strangle the legacy system: stand up a new service alongside, route specific workflows through it, and migrate data in shadow-write mode while clinicians keep using the original UI. We instrument both systems, compare outputs, and cut over per-workflow. Clinical staff don't tolerate big-bang migrations, and frankly neither does patient safety.

→ How do you handle de-identification for analytics and ML training?

We follow the HIPAA Safe Harbor method (removal of the 18 identifiers) by default, and Expert Determination when the dataset needs richer fields and we can justify the statistical re-identification risk. De-identification happens inside the trust boundary before data lands in the analytics warehouse. We document the method, keep the mapping keys (if any) separately encrypted, and review the determination annually as datasets evolve.

→ What happens if we have a breach or suspected breach during the engagement?

We have a written incident response runbook that activates within hours: containment, forensic preservation of logs, scope assessment (how many records, what identifiers, what window), and notification timeline tracking against the 60-day HIPAA breach notification rule. We coordinate with your privacy officer and counsel — we don't make disclosure decisions for you, but we provide the technical evidence cleanly and quickly.

[004 / 005] Adjacent Files

Continue recon.

REL-01

All Services

Custom builds, AI integration, modernization, and staff augmentation across regulated industries.

 REL-02

Case Studies

How we've shipped EHR integrations, audit pipelines, and clinical tools that hold up in production.

 REL-03

Engagement Packages

Fixed-scope discovery, integration sprints, and modernization packages with clear deliverables.

 REL-04

Start a Project

Tell us about the EHR system, the workflow, and the regulatory boundary you're working within.
[ NEXT ACTION ]

Have an EHR integration or HIPAA-bound build that needs to actually ship? Let's talk.

Talk to a VooStack operator. We respond within one business day.

Open a Channel Full Services