EHR integration that survives the second hospital
Reading a patient record is a solved problem. Reading it the same way at two health systems, with an audit trail that holds up, is where most projects stall.
What you are actually buying
5 things that decide this
- 01Certified electronic health record software must expose a standard FHIR API, so the connection itself is rarely the risk. The risk is that two vendors fill the same fields differently and your logic quietly reads the wrong one.
- 02US federal rules set two hard clocks on a certified API. The authorisation server has to issue a refresh token good for at least three months to a confidential app, and it has to cut off an app within one hour when a patient asks (45 CFR 170.315(g)(10)).
- 03HIPAA does not ask whether you logged the access. It requires a mechanism that records and examines activity in any system holding electronic health information (45 CFR 164.312(b)).
- 04Documentation runs on a six-year clock, counted from creation or from the day it was last in force, whichever falls later (45 CFR 164.316(b)(2)(i)). Build the export path on day one.
- 05A signed business associate agreement is a contract, not a control. It obliges you to safeguard the data. It does not make the software compliant, and it does not survive a bad access model.
Two health systems, one standard, two answers
A standard says what a field is called. It does not say what a hospital puts in it. One site codes a medication as prescribed. The next codes it as dispensed. A third leaves the field blank, because the pharmacy runs on a separate system nobody mentioned at kickoff. Your code reads all three and reports a number that is wrong at two of them.
This is why an integration that demos beautifully at one site takes months at the next. The engineering was never the bottleneck. Data mapping was, and it is the line item most proposals leave out.
So we scope the mapping before the build. What fields you need, which system owns each one, what a blank means at that site, and who signs off when two sources disagree. Answer those four and the code is ordinary work.
- 01Sandbox access and production access are different projects with different queues. Ask for the production timeline in writing, early.
- 02Read scopes are granted per patient or per population, and the two paths behave differently under load.
- 03A field that is optional in the standard is mandatory in your product. Decide what happens when it is missing before a clinician finds out.
- 04Bulk export exists for population work. Do not build a loop over patients and call it a report.
- AuthorisePatient consents. Scope is recorded.
- Read and mapThe standard resource, then site meaning.
- ReconcileTwo sources disagree. One wins, on record.
- ActA person reviews before it counts.
- LogWho read what, and when.
- RevokeAccess off within the hour.
Most builds get the first two right on day one. Steps three and six are the ones that decide whether a second hospital ever goes live.
Rules with a number attached
Four requirements that carry a hard figure. Each one changes an architecture decision, so they belong in scoping rather than in a security review at the end.
| Requirement | What it says | What it changes in the build |
|---|---|---|
| Refresh token life | A certified authorisation server issues a refresh token valid for no less than three months to a confidential app (45 CFR 170.315(g)(10)). | Your app can hold a long-lived session. Store that token like a credential, because it now behaves like one. |
| Revocation window | Access is revoked at a patient's direction within one hour of the request (45 CFR 170.315(g)(10)). | Cached patient data needs an eviction path. A nightly job does not meet a one-hour promise. |
| Audit controls | Record and examine activity in systems holding electronic health information (45 CFR 164.312(b)). | Logging is a product feature with storage and retention, not a debug setting someone can turn down. |
| Documentation retention | Six years from creation or from last effective date, whichever is later (45 CFR 164.316(b)(2)(i)). | Retention outlives most software contracts. An export path is part of the deliverable. |
Where we are useful
Mapping before code
We start with the field list and the site that owns each field, because that is the work that decides the schedule. You get a written map you can hand to the next vendor.
Clinical AI with a person in the loop
On TrialTriage we ranked oncology trials from de-identified patient data and kept a nurse as the final decision-maker on every result. Speed only counts when someone signs off.
Audit trails built to be read
TrialTriage tracks 23 audit action types with field-level encryption and automatic masking. An audit trail nobody can query is storage, not evidence.
Role models that hold
Four user types on TrialTriage, five permission tiers on TankAware. Getting this wrong is a disclosure, so we model it before the first screen.
De-identified data is a design choice, not a checkbox
The cheapest way to reduce risk is to hold less. On TrialTriage the nurse enters de-identified patient data, so the ranking engine never sees a name. That decision shrank the blast radius of every later bug.
It has to be decided first. Retrofitting masking into a system already holding two years of identified records means the history stays identified, and you now own it. The same applies to any model you send data to. Decide what leaves your boundary before you pick the vendor.
Encryption in transit is the floor. Field-level encryption on the columns that identify a person is what limits a breach to the rows an attacker actually reached.
- Decide what the model sees before you choose the model.
- Mask on write, not on display. A masked view over an unmasked table is a screenshot away from failing.
Regulated systems where the record was the product
“I am extremely happy with the results and would highly recommend Hashlogics to anyone.”
Daniel Khin · CEO, PremiumAudit.io
The stack behind our regulated builds
Built with
Security on TrialTriage
Integration work
Questions buyers ask us first
01Can you connect our product to Epic or Cerner?
Yes, and we scope the data mapping before quoting the connection. Certified systems expose a standard FHIR API, so the wiring is well-trodden. What varies is what each hospital puts in each field, and that difference is where the schedule actually goes. Budget the mapping conversation with their analyst, not the API call.
02How long does hospital API access take to arrange?
Sandbox access is usually quick and production access is not, so treat them as two separate dependencies. The queue sits with the health system and their vendor, not with your engineers. Get the production timeline in writing before the build plan depends on it.
03Does a business associate agreement make our software compliant?
No. A business associate agreement is a contract in which you promise to safeguard the data, and it is required, but it is not a control. Compliance still comes from your access model, your audit trail and your retention policy. A signed agreement over a weak access model just means you agreed in writing to do something you have not done.
04Can we send patient data to a large language model?
Only after you decide what crosses the boundary, and the safer pattern is to send less. On TrialTriage the ranking runs on de-identified data, so no name reaches the model. Settle that before you pick a provider, because the decision is architectural and expensive to reverse.
05What happens when a patient revokes access?
A certified authorisation server must cut the app off within one hour of the request (45 CFR 170.315(g)(10)). That obligation reaches your cache as well as your session table. If you hold copies of patient data, you need a path that clears them inside the same window.
06How do you price this kind of work?
Scoping calls are free. Where we have to go into an existing codebase first, there is a paid two-week diagnostic. It ends in a fixed price rather than a range. We will not quote a schedule before seeing which systems hold your fields, because that answer is the schedule.
