Compliance is a feature, not a binder
EKLIS is built security-first against a written security register. Every code change is checked against these requirements before it ships.
Regulatory landscape
| Regime | What it requires of the LIS | EKLIS posture |
|---|---|---|
| HIPAA | PHI security & privacy: encryption, access control, audit, breach notification, BAAs | US-region hosting under a signed BAA before any real data; TLS everywhere; immutable audit on every PHI access; role-based access, deny by default |
| CLIA (42 CFR 493) | Positive patient ID through the cycle; report content rules; record retention ≥ 2 years; corrected-report handling | Two-identifier verification at collection and accessioning; released results immutable with linked corrected versions; retention holds on deletion flows |
| CAP accreditation | LIS validation, interface validation, audit trails for amendments, downtime procedures, QC documentation | Validation and interface evidence generated continuously; amendment trails built into the result model; inspection-readiness pack at P4 |
| COLA | Accreditation path common for physician office labs | Primary target segment — the onboarding flow assumes COLA-accredited moderate-complexity labs |
| FDA | LIS software historically low-risk; blood-bank software is a regulated device (510(k)) | Blood bank / transfusion module deliberately out of scope; AI features stay advisory to remain clear of CDS lines. LDT rule vacated Mar 2025 — oversight stays under CLIA |
| SOC 2 | Organizational security controls | SOC 2 Type II targeted by general availability |
Result integrity — patient-safety critical
TRUST-01
Results you can defend
A released result is immutable. Corrections create a clearly-labeled new version linked to the original; both remain visible with full history. No silent edits, ever.
TRUST-02
Every access on the record
Every view of patient data — staff, portal, batch job, or interface — writes an immutable audit entry. Critical-value notifications capture who was told, when, with read-back.
TRUST-03
Rules with receipts
Auto-verification runs only via explicit, versioned, auditable rule sets. Every auto-released result records the exact rule version that passed it.
Access control & engineering practice
Access control
- Role-based access on every endpoint, deny by default — lab roles map to CLIA personnel responsibilities (director, pathologist, technologist, phlebotomist, accessioner, billing)
- Tenant identity derived server-side from the authenticated session — never from request data
- Tenant isolation at the data layer (schema-per-tenant); cross-tenant attempts return 404, not 403
- Minimum necessary: physicians see their patients; clients see their accounts; patients see themselves
Engineering practice
- Written threat model per phase; every threat mitigated or formally accepted with rationale before the phase ships
- No secrets, credentials, or real patient data in code, fixtures, logs, or tests — enforced by automated secret scanning in CI
- All input validated server-side; interface traffic (HL7/ASTM) treated as untrusted input
- Zero-mock rule: no hardcoded clinical data in production paths, swept and recorded per phase
HIPAA-compliant hosting (BAA)
CLIA-aligned workflows
CAP / COLA inspection support
Encryption in transit & at rest
SOC 2 Type II by GA
Phase exit gates
Every phase ships only after:
threat model closed→
green CI (lint · tests · security scans · build)→
zero-mock data sweep→
hero flow human-verified on the deployed stack