Your EHR is the source of truth. Everything around it still has to keep up.
The EHR go-live was the vendor's project. What lands on the health system afterward is the interface backlog, the FHIR app requests, the analytics extracts, the identity cleanup and the analyst roles that never stay filled. We work on that layer around Epic, Oracle Health and InterSystems.
HR and credentialinghires · privileges · exitsIdentity platformSailPoint · OktaSMART on FHIR appspatient · clinician apps
02 · EHR
EpicEHREpic · Oracle Health
03 · Integration
Interface engineHealthShare · IRIS for HealthDepartmental systemslab · imaging · pharmacyHIE and TEFCAQHIN exchange
04 · Analytics
Analytics platformSnowflake · Databricks
EpicOracle Health EHRInterSystems IRIS & HealthShareSnowflake
in short·15-second read
Healthcare provider platforms are the clinical and administrative systems hospitals and health systems run on, mainly EHRs such as Epic and Oracle Health and integration platforms such as InterSystems HealthShare and IRIS for Health.
Cohash builds HL7 and FHIR integrations, moves EHR data into analytics platforms, connects EHR access to your identity platform, supports interface engines, and staffs Epic, Oracle Health and InterSystems specialists.
you probably need this if
The interface backlog is months long and every new clinic adds more.
App vendors ask for FHIR access, and nobody owns the registration and scope review.
Analytics teams wait on EHR report extracts that one analyst builds by hand.
Interface catalog with message types, owners and failure procedures
FHIR app integration designs with scopes and registration steps
EHR-to-analytics data pipelines and documented data models
+ 2 more documents
who does it
Epic integration analystEpic application analystOracle Health Millennium engineer
InterSystems IRIS Development Professional
InterSystems EHR Integration Specialist
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Healthcare Provider Platforms, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · healthcare provider platforms3 open
openThe interface backlog is months long and every new clinic adds more.
recurringApp vendors ask for FHIR access, and nobody owns the registration and scope review.
blockedAnalytics teams wait on EHR report extracts that one analyst builds by hand.
exposure
FHIR API and app integrationInterface engine workEHR data into analytics platformsIdentity and access for clinical…Health information exchangeSpecialist staffing
EpicOH
startrehearsehandover
Map the estate
Prioritize
Build and test
Support and hand over
we are here
ready to hand over
New apps follow one review path.
A stalled interface now raises an alert before clinicians see a gap.
Interface catalog with message types, owners and failure procedures
FHIR app integration designs with scopes and registration steps
chapter 01 · where it hurts
Why teams reach out
The interface backlog is months long and every new clinic adds more.
App vendors ask for FHIR access, and nobody owns the registration and scope review.
Analytics teams wait on EHR report extracts that one analyst builds by hand.
chapter 02 · what we change
How we solve it
FHIR API and app integration
Interface engine work
EHR data into analytics platforms
Identity and access for clinical systems
Health information exchange
Specialist staffing
chapter 03 · how it runs
Our approach
Map the estate
Prioritize
Build and test
Support and hand over
chapter 04 · where you end up
What changes
New apps follow one review path.
A stalled interface now raises an alert before clinicians see a gap.
Interface catalog with message types, owners and failure procedures
FHIR app integration designs with scopes and registration steps
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
We build apps and services on Epic on FHIR or Oracle Health's FHIR APIs, using SMART on FHIR launch and scoped OAuth. Testing happens in the vendor sandboxes before anything is registered for production.
We build HL7 v2 interfaces on InterSystems HealthShare, IRIS for Health and other engines for ADT, orders, results and charges. The routing rules, transformations and alerting are ours to set up, and every interface goes in a documented catalog.
Extracts from EHR reporting databases into Snowflake or Databricks, with patient matching, de-identification where it's required, and data models clinicians and finance can actually use.
EHR user provisioning tied to HR and credentialing, single sign-on for clinicians, and access reviews for sensitive records, connected to your IGA platform.
Connections to HIEs and national networks, including TEFCA participation through a Qualified Health Information Network, and the consent and patient matching work that comes with them.
Epic analysts and integration staff, Oracle Health Millennium engineers, and InterSystems developers, on contract, contract-to-hire or permanent terms.
capability 01 / 06in production
EpicOH
FHIR API and app integration
We build apps and services on Epic on FHIR or Oracle Health's FHIR APIs, using SMART on FHIR launch and scoped OAuth. Testing happens in the vendor sandboxes before anything is registered for production.
We build HL7 v2 interfaces on InterSystems HealthShare, IRIS for Health and other engines for ADT, orders, results and charges. The routing rules, transformations and alerting are ours to set up, and every interface goes in a documented catalog.
Extracts from EHR reporting databases into Snowflake or Databricks, with patient matching, de-identification where it's required, and data models clinicians and finance can actually use.
EHR user provisioning tied to HR and credentialing, single sign-on for clinicians, and access reviews for sensitive records, connected to your IGA platform.
Connections to HIEs and national networks, including TEFCA participation through a Qualified Health Information Network, and the consent and patient matching work that comes with them.
Epic analysts and integration staff, Oracle Health Millennium engineers, and InterSystems developers, on contract, contract-to-hire or permanent terms.
We pieced these together from Healthcare Provider Platforms situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Forty FHIR app requests with no review process
composite · not a client story
Beforethe situation
Departments keep asking to hook third-party apps into Epic over FHIR. Whoever gets the email handles it and approves the scopes without a review. Nobody keeps a list of what's connected.
What we dothe work
Set up an intake form that goes through security and privacy review, with a standard scope checklist for each app type. Keep a register of every registered client. Review the apps already connected and revoke the scopes they don't use.
Afterwhere you end up
New apps follow one review path. The register shows which apps can reach which data, and access nobody was using has been removed.
case file 02
HL7 interfaces on an engine that doesn't alert anyone
composite · not a client story
Beforethe situation
Lab results and ADT feeds go through an InterSystems engine running dozens of interfaces. When a queue backs up overnight, clinicians spot the missing results before IT does.
What we dothe work
Catalog the interfaces with an owner and thresholds for each. Route queue depth and error alerts to the on-call engineer, and write runbooks for the failures that keep coming back.
Afterwhere you end up
A stalled interface now raises an alert before clinicians see a gap. The on-call engineer has a runbook for the usual failures.
The integration and data layer around a hospital EHR
The EHR trades HL7 v2 messages with departmental systems through an interface engine, and apps reach it through FHIR APIs. Reporting data flows to the analytics platform. User access is provisioned from HR through the identity platform.
HR and credentialing → Identity platform: lifecycle events
Identity platform → EHR: provision users
SMART on FHIR apps → EHR: FHIR R4 · OAuth
EHR → Interface engine: HL7 v2 ADT
Interface engine → Departmental systems: orders
Departmental systems → Interface engine: results
Interface engine → HIE and TEFCA: exchange
EHR → Analytics platform: reporting extracts
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Map the estate
We sit with IT and clinical informatics and write down the EHR version and modules, every interface, pending FHIR app requests, reporting extracts and identity flows.
step 02
Prioritize
Rank work by patient safety, regulatory deadlines and backlog age, and agree an order with the CMIO and IT leadership.
step 03
Build and test
We build interfaces and APIs against test environments with real message samples. Clinical users check them before cutover.
step 04
Support and hand over
We hand over to your integration team once monitoring and alerting are on the interfaces and runbooks cover common failures.
you keep
What you're left with
We write these for your Healthcare Provider Platforms setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
inventory01
Interface catalog with message types, owners and failure procedures
yours to keep
design02
FHIR app integration designs with scopes and registration steps
yours to keep
design03
EHR-to-analytics data pipelines and documented data models
yours to keep
design04
Clinical user provisioning and access review design
talent and delivery · healthcare provider platforms
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Put these to anyone bidding on your Healthcare Provider Platforms work. The ones who've done it answer differently from the ones who've read about it.
Q1
How will you review scopes for third-party FHIR apps before we register them?
FHIR access can expose a lot of patient data. Ask what the partner checks in the scopes each app requests, before anything gets registered.
Q2
What will our interface catalog look like at the end, and who owns each feed?
Interface estates grow without documentation. Support stays manageable when each feed has a named owner and a written failure procedure.
Q3
How do you keep PHI out of development and test environments?
A lot of HIPAA risk hides in test data. Ask how they de-identify, whether they use synthetic data and who can reach production.
Q4
How will EHR provisioning tie into our HR and identity platform?
When EHR provisioning is manual, access stays behind after clinicians leave. Ask how joiner, mover and leaver events reach the EHR.
Q5
Which work do you do, and which stays with the EHR vendor?
Overlap with the vendor's services means paying twice, and a support team that doesn't know whose number to dial.
01Do you implement Epic or Oracle Health?
Usually the vendor leads the EHR implementation. We work next to them on integrations, data, identity and support, and supply analysts and engineers who already know the platform.
02What FHIR versions does Epic support?
Epic on FHIR lists support for FHIR R4, STU3 and DSTU2. Most new integrations target R4. Check the specific resources and scopes your app needs in Epic's documentation, because support varies by resource.
03How long does a new EHR interface take?
It depends on the message type, the partner system, how much transformation is needed and how long testing with clinical users takes. A standard ADT feed is far simpler than a bidirectional orders and results interface.
04Do you work with InterSystems?
Yes. HealthShare and IRIS for Health interfaces from InterSystems are work we build and support. TrakCare sites work with us on integration too.
05Can you help with health plan systems too?
Yes. Our payer platforms practice works on TriZetto Facets, QNXT and HealthEdge, and many of the same integration patterns show up on both sides.
06How do you handle PHI with offshore staff?
We set data boundaries with your compliance team before work starts. Development often runs on de-identified or synthetic data, and production PHI access stays with approved US-based staff where your policies require it.
related
Often paired with
Projects on Healthcare Provider Platforms usually end up touching one of these, so they're worth a look.
