A note on "HIPAA certified"
There is no such thing, and we would rather say so than trade on the confusion. The US Department of Health and Human Services does not accredit vendors and no body issues a HIPAA certificate that HHS recognises. Organisations attest to compliance and are assessed against the Security Rule; independent assessments like HITRUST CSF or SOC 2 are real and verifiable, but they are not HIPAA certification either.
What we can tell you concretely: which Security Rule safeguards a system implements, whether we will operate under a Business Associate Agreement, and what the audit evidence looks like. Experienced hospital CIOs already know the distinction, and a vendor claiming certification signals inexperience rather than confidence.
The audit log is the part that fails assessments
Encryption in transit and at rest is universally implemented. The technical safeguard that actually fails assessments is audit controls, because the requirement is not "log access" — it is to record activity in systems containing protected health information in a way that supports later review.
In practice: who viewed which patient record, when, from where, under what access justification, in a store the viewer cannot alter. Application logs mixed into general telemetry on a 30-day retention will not satisfy this. A separate append-only PHI access log will, and it is dramatically cheaper to build in the first sprint than to reconstruct after an assessment finding — reconstruction being, in the strict sense, impossible.
FHIR: native model or translation layer
HL7 FHIR replaces bespoke point-to-point integration with defined RESTful resources — Patient, Encounter, Observation, Condition, MedicationRequest — exchanged over ordinary HTTP. The decision that matters is whether FHIR resources are your data model or whether you map to them at the boundary.
Modelling natively gives the cleanest interoperability story and removes a class of mapping bugs, but FHIR resources are shaped for exchange rather than transactional workloads. For a platform with substantial clinical workflow, a translation layer over a domain-appropriate internal model is usually the better trade — provided mapping tests are treated as first-class tests, because a silently dropped code system produces an observation that looks right and means something else.
The genuinely hard part is terminology. LOINC, SNOMED CT, ICD and RxNorm mapping is clinical judgement, not data engineering, and it needs clinical review time in the budget. A platform exchanging structurally valid FHIR that carries unmapped local codes is interoperable in form and useless in substance.
What is included
- EHR and EMR platform development
- HIPAA Security Rule safeguard implementation
- Append-only PHI access logging and audit evidence
- HL7 FHIR resource modelling or translation layer design
- HL7 v2 to FHIR migration
- Clinical terminology mapping support (LOINC, SNOMED CT, ICD, RxNorm)
- Telemedicine platforms with clinical-grade video
- e-prescribing and medication workflows
- Laboratory and diagnostic system integration
- Medical billing and claims integration
Technologies and standards
Related case studies
- HIPAA EHR Platform Rolled Out Across a Hospital Network — An EHR platform where the PHI access log was built in the first sprint and FHIR interoperability was designed as a translation layer over a clinical model.
- Telemedicine Platform Built for Low-Bandwidth Consultations — Telemedicine where the video stack was designed for the network the patients actually have, not the one in the specification.