HIPAA requirements for software teams
The safeguards every EHR integration has to meet.
Healthcare / EHR Integration
EHR integration services
Your product is only as useful as its connection to the EHR, and every EHR vendor does it differently. Agnotic Technologies builds EHR and EMR integrations with Epic, Oracle Health, athenahealth and others, using FHIR, HL7 v2 and vendor APIs, with audit logging and PHI controls from the first interface.
FHIR R4 · HL7 v2
The standards EHRs actually expose
SMART on FHIR
Apps that launch inside the chart
Audit logged
Every PHI read and write recorded
Trusted by global innovators
Industry Overview
What are EHR integration services?
EHR integration services connect an application, device or data platform to an electronic health record so patient data moves between them without manual entry. Agnotic Technologies builds these integrations for Epic, Oracle Health (Cerner), athenahealth and other EHRs, choosing FHIR, HL7 v2, C-CDA or X12 for each data flow and adding audit logging and access controls.
Related work
Which compliance and product areas connect to EHR integration?
EHR integration rarely stands alone. These are the areas it most often touches.
Healthcare compliance software development
HIPAA, ONC and other frameworks as engineering work.
Femtech app development
Women's health products that need EHR data and results.
Revenue cycle management
Claims, eligibility and payments connected to the EHR.
Industry Challenges
What drives the scope, timeline and cost of an EHR integration?
We do not quote before we understand these. The code is rarely the slow part; access, sites and testing usually are.
Number of EHRs, sites and data flows: each one adds mapping, testing and go-live work.
Read-only or write-back: writing data into the chart needs more vendor approval and more testing than reading it.
Vendor access: app registration, sandbox access and production approval follow the vendor's process and calendar.
A client sponsor is needed: many EHRs only open production access through a hospital or practice that runs them.
Each site is different: the same EHR is configured differently at every organization, so mappings change per site.
Testing needs real workflows: an interface that passes sandbox tests can still fail on live data and edge cases.
Decision table
FHIR, HL7 v2, C-CDA or X12: which does your project need?
Most projects use more than one. We pick per data flow, based on what the EHR supports and what the data is for.
| Standard | Best for | How it works | Watch out for |
|---|---|---|---|
| HL7 FHIR R4 (HL7 International) | Apps that read and write patient data on demand | REST APIs over standard resources such as Patient, Observation and MedicationRequest | Write access and some resources vary by EHR vendor |
| SMART on FHIR | Apps that open inside the EHR with the patient in context | OAuth 2.0 launch from the chart on top of FHIR APIs | App registration and review with each vendor |
| HL7 v2 | Real-time event feeds: admissions, orders, results | Messages such as ADT, ORM and ORU sent through an interface engine | Each site's message variations need mapping and testing |
| C-CDA | Exchanging summary documents between organizations | Structured XML documents such as the Continuity of Care Document | Large documents; useful data must be parsed out |
| X12 | Claims, eligibility and prior authorization with payers | HIPAA standard transactions such as 837, 835, 270/271 and 278 | Usually runs through a clearinghouse, not the EHR |
Our Approach
How do you get access to an EHR vendor's APIs?
Access is a project in its own right. We run it in parallel with the build so it does not hold up go-live.
Register the app
Register with the vendor's developer program, for example Epic's at open.epic.com, and choose the APIs and scopes you need.
Build in the sandbox
Develop and test against the vendor sandbox with test patients before any real data is involved.
Find a client sponsor
Agree production access with the hospital or practice that runs the EHR; they approve and activate the app.
Go live site by site
Configure, test and launch at each site, with monitoring from the first message.
Capabilities
What do we build in an EHR integration?
The integration work we take on, from a single interface to a full integration layer.
SMART on FHIR apps
Apps that launch from the patient chart with user and patient context, for Epic, Oracle Health and other EHRs.
FHIR API integrations
Reading and writing patients, encounters, results and medications through each EHR's FHIR APIs.
HL7 v2 interfaces
ADT, orders and results feeds through your interface engine, with mapping and error handling.
CDS Hooks services
Decision support that appears in the clinician's workflow at the moment of ordering or signing.
Bulk data and analytics feeds
FHIR bulk export and scheduled extracts for population health and analytics.
Integration monitoring
Message tracking, alerting on failures and replay, so problems are found before clinicians notice.
How It Works
What does an EHR integration architecture look like?
Three patterns cover most projects. Many products combine them.
Direct API integration
Your app calls the EHR's FHIR APIs directly. Simple for one EHR, harder to maintain across many.
01
1
Interface engine
HL7 v2 and FHIR traffic routes through an engine such as Mirth Connect, which handles mapping, retries and monitoring.
02
2
Integration layer
Your own service normalizes data from several EHRs into one model, so the product does not depend on any single vendor.
03
3
Audit and security
Every pattern logs each PHI read and write, encrypts data in transit and at rest, and limits access by role.
04
4
Engineering Stack
Which systems and standards do we work with?
The EHRs, standards and tools that come up most in our integration work.
EHRs
EpicOracle Health (Cerner)athenahealthMEDITECHeClinicalWorksNextGen
Standards
HL7 FHIR R4SMART on FHIRCDS HooksHL7 v2C-CDAX12
Interface engines
Mirth ConnectYour existing engine
Identity
OAuth 2.0OpenID ConnectSAML 2.0
Backend
Node.jsPythonPostgreSQL
Infra
AWSAzureGoogle Cloud
Protecting PHI
How is PHI protected in an EHR integration?
Each control is an engineering decision we make with your security team, not a checkbox at the end.
| Control | What it answers | How we build it |
|---|---|---|
| Business associate agreement | Who is allowed to handle PHI | A BAA in place before any PHI moves, for us and for every vendor in the data path |
| Minimum necessary | Which data the integration really needs | Only the FHIR scopes and message types the use case requires |
| Access control | Who can see what | Role-based access, with user context passed from the EHR launch |
| Audit logging | Who read or changed which record, and when | A log of every read and write, exportable to your security tools |
| Encryption | How data is protected | TLS in transit and encryption at rest with managed keys |
| HIPAA Security Rule (HHS) | Which safeguards apply | Administrative, physical and technical safeguards documented for your security review |
| Information blocking (21st Century Cures Act) | Whether access can be restricted | Access and exchange designed to the ONC (ASTP) rules in 45 CFR Part 171 |
| ONC Health IT Certification and CMS rules | Which APIs EHRs and payers must offer | We build on the FHIR APIs that ONC certification and CMS interoperability rules require |
Measured Impact
How should you measure an EHR integration?
We agree these measures at kickoff and track them against your own baseline.
Delivery
Messages delivered
Share of messages and API calls that complete without manual fixes.
Latency
Time to the chart
Time from an event in one system to the data appearing in the other.
Errors
Failures resolved
How quickly failed messages are detected, fixed and replayed.
Sites
Time to the next site
Effort to bring the integration live at each additional organization.
My Lauren Maternal Health Platform | Built by Agnotic
A HIPAA-ready maternal health platform enabling remote patient monitoring, care coordination, and personalized engagement from pre-pregnancy through postpartum.
Case Study
LERA Health: Women's Health App Platform
A women’s health product experience focused on guided care journeys, education, and compliance-aware workflows to support long-term engagement.
Case Study
Use Cases
What do teams use EHR integration for?
The integrations we are asked to build most often.
01
Digital health apps
Startups whose product needs patient data from, and results back into, the EHR.
02
Clinician-facing tools
Apps and AI tools that open inside the chart through SMART on FHIR.
03
Labs and imaging
Orders and results exchanged with lab and imaging systems over HL7 v2.
04
Remote monitoring
Device readings written to the chart as FHIR Observations.
05
Analytics and population health
Bulk data feeds into a warehouse for reporting and quality measures.
06
EHR migration
Moving data from a retiring EHR or EMR into a new one.
Integrations
Which systems do we connect to the EHR?
Common systems on the other side of an EHR integration.
Patient
Patient apps and portals
Virtual care
Telemedicine platforms
Diagnostics
Lab information systemsPACS and imaging
Devices
RPM device platforms
Revenue cycle
Clearinghouses and payers
Analytics
Data warehouses
Exchange
Health information exchanges
What we check
How do you keep an EHR integration from disrupting clinical work?
You keep an EHR integration from disrupting clinical work by planning the cutover as carefully as the build: named owners, tests on the site's own configuration, a quiet go-live window, queued messages and an agreed rollback rule. Agnotic Technologies runs this cutover checklist with your clinical and IT leads.
1. Before cutover
- Every interface in scope is listed with its message types and an owner on each side
- End-to-end tests have passed in the EHR vendor's non-production environment with the site's own configuration
- Downtime procedures for each affected department are written and rehearsed with staff
- Rollback criteria, and the person who can call a rollback, are agreed in writing
2. During the go-live window
- Go-live is scheduled for a low clinical volume period agreed with the site
- Messages queue in the interface engine during the switch and replay in order afterwards
- A parallel run or shadow feed compares new output with the old path before the old path is switched off
- Super-users are on the floor in each department to answer questions as they come up
3. After go-live
- Interface monitoring alerts on failed, delayed or rejected messages from the first hour
- Queued and replayed messages are reconciled against the source, so none are lost or sent twice
- Issues reported by clinicians are triaged daily with the site until volumes settle
Compliance-First Development Services Backed by Global Standards
We build secure, scalable products designed for privacy, interoperability, and regulatory readiness from day one across every sector we serve.
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, and strict access controls.
Fast Healthcare Interoperability Resources
Enabling standardized health data exchange through standards-based API mappings.
Health Level Seven International
Supporting enterprise-grade interoperability for clinical messaging and record workflows.
Our Edge
Why Global Leaders Choose Us
We combine deep technical expertise with industry-specific knowledge to deliver solutions that aren't just functional, but transformational.
Enterprise-Grade Security
We implement rigorous security protocols and compliance standards (HIPAA, GDPR, SOC2) across all industrial solutions to protect sensitive data.
High-Performance Scaling
Our architectures are built to handle massive data loads and user bases, keeping performance steady whether you're serving ten or ten million.
Accelerated Time-to-Market
Using our suite of internal tools and proven frameworks, we cut setup work so your first release reaches users sooner.
Embedded AI Integration
Beyond simple wrappers, we build deep-learning integrations and predictive analytics directly into the core of your industry-specific workflows.
Engagement Model
How does an EHR integration engagement work?
Three stages, each with a clear output.
01
Scoping call
We agree the EHRs, data flows, standards and sites in scope, and start vendor access early.
02
Fixed-scope first interface
One data flow with one EHR, working end to end in the sandbox, then live at the first site.
03
Scale and support
More data flows, vendors and sites, with monitoring and support under agreed terms.
Facts and sources
Which rules and facts shape an EHR integration?
Short facts we design around, each linked to its primary source.
ONC certification criterion 170.315(g)(10) requires certified EHRs to offer a standardized API for patient and population services based on HL7 FHIR.
Source: 45 CFR 170.315 (eCFR)HHS adopts the United States Core Data for Interoperability (USCDI) as the standard set of health data classes and data elements for certified health IT.
Source: 45 CFR 170.213 (eCFR)The information blocking regulations restrict practices by health care providers, certified health IT developers and health information networks that interfere with access, exchange or use of electronic health information.
Source: 45 CFR Part 171 (eCFR)The HIPAA Security Rule requires administrative, physical and technical safeguards for electronic protected health information.
Source: 45 CFR Part 164 Subpart C (eCFR)Epic publishes its FHIR API documentation and developer resources for third-party applications on open.epic.com.
Source: Epic (open.epic.com)
Voice of success
We don't just build products; we forge lasting partnerships. See how we've helped industry leaders transform their vision into technical reality.
“I can clearly see how Agnotic has a unique way of handling end-to-end development. They are always active on quick chat and provide support quickly.”
Aaron Phelan
Founder, Benchmark
“Agnotic combines deep technical expertise with strong domain knowledge. They understand the business context, anticipate challenges, and make collaboration smooth and effective.”
John Pasmore
Founder, Latimer
“Agnotic is the best technical team we evaluated. Their engineering excellence made our work dramatically easier and allowed us to stay focused on what matters most for maternal care outcomes. They took full ownership of the technical execution, and we are always happy to continue working together.”
Kim Smith
Founder, My Lauren
By EHR vendor
Which EHR are you connecting to?
Each EHR has its own APIs, app programs and approval steps. These pages cover what an integration with each one involves.
Epic integration
FHIR APIs, SMART on FHIR apps, CDS Hooks and Epic's developer programs.
Oracle Health (Cerner) integration
Millennium FHIR APIs, SMART apps and HL7 v2 interfaces.
athenahealth integration
athenahealth's APIs and marketplace for ambulatory practices.
MEDITECH integration
Expanse APIs and interfaces for community hospitals.
eClinicalWorks integration
APIs and interfaces for eClinicalWorks practices.
NextGen integration
APIs and interfaces for NextGen ambulatory practices.
Practice Fusion integration
FHIR R4 patient access and SMART launch for independent practices.
Telehealth EHR integration
Virtual visit notes, orders and encounters written back to the EHR.
More in Healthcare
More Healthcare Solutions
Explore other production-grade engineering platforms we deliver across healthcare.
Interoperable Health Data Exchange
Multi-party exchange through HIEs, QHINs and TEFCA.
Revenue Cycle Management
Claims, eligibility and payments connected to the EHR.
Digital Health Startups
Products that need EHR data from their first release.
AI in Healthcare Software Development
AI features that read from and write back to the EHR, with human review.
Cross-Industry Reach
The Same Engineering Patterns, Across Other Industries
The technical patterns behind this platform translate naturally into adjacent verticals.
Frequently Asked Questions
It depends on the APIs you need, whether you need write access, and how quickly a client sponsor can approve production access. Vendor and site approval often takes longer than the build, so we start it in the first week.
Usually, yes. Most EHRs require you to register your app, and production access is granted by the hospital or practice that runs the EHR. Read-only patient access APIs have fewer steps than apps that write data back.
Use FHIR for apps that read and write data on demand, and HL7 v2 for real-time event feeds such as admissions and results. Many projects use both, depending on what each EHR supports.
An integration platform can be faster when you need many EHRs and standard data. Building your own integration layer gives more control over the data model and long-run cost. We build on either, or a mix, and help you compare them first.
We can, under a support agreement that covers monitoring, fixes and vendor upgrades, or we hand it to your team with documentation and runbooks. We agree this before go-live.
They wait in a queue instead of being lost. The interface engine holds inbound and outbound messages during the switch, replays them in their original order once the new connection is confirmed, and the replayed messages are reconciled against the source. Staff follow downtime procedures for anything urgent in that window.
Industries