The shared API is being built and is not generally available.
Conceptual design · being built
Your productCare, notes or revenue cycle
↓
One request formatInteroply
↓
EpicTarget
Oracle HealthTarget
athenahealthTarget
Each EHR keeps its own access, mappings and write rules.
Your next customer should move you forward
The connection can become the buying decision.
Founder, sales and CTO
The hospital says yes. Then asks about Epic.
Without it The deal waits on a connection.
What is needed A customer sponsor and approved vendor access.
Hospital ready
Epic access needed
Deal waiting
Product and engineering
New customer. Different EHR. Another rebuild.
Without it Roadmap time goes into another integration.
What is needed A common format with mappings for each site.
Customer A · Epic
Customer B · Oracle Health
Customer C · athenahealth
AI scribe teams
The note is ready. The chart is still empty.
Without it Clinicians copy and paste your output.
What is needed Document writes with site-specific review rules.
Note created
Review required
Chart destination
Specialty and dental software
Your market has a long tail of systems.
Without it Each unsupported system can hold back a sale.
What is needed Vendor access and a connection scoped per system.
Specialty practice
Dental practice
Local system
RCM product teams
Your user leaves your product for a portal.
Without it Eligibility and claim status still need staff.
What is needed X12 access and a clearinghouse contract.
Your product
Eligibility
Claim status
The path to a connection
One format. Real work at every site
01
Customer sponsor
A person at the hospital who can sponsor access.
02
Vendor programme
Agreements, application registration and permissions.
03
Per-site mapping
Match records, identifiers and local fields.
04
Write rules
Agree allowed writes, review and acceptance checks.
Your product speaks one format
A unified healthcare API aims to absorb differences between systems so your product can keep a common integration model.
EHR API integration still depends on the permissions and behavior of each destination. The diagram describes the intended design.
Conceptual design · being built
EpicDifferent local format
Oracle HealthDifferent local format
athenahealthDifferent local format
→
One shared formatFor your product
Still agreed per siteAccess and permissionsIdentifiers and field mappingsAllowed writes and review
Start with the records your product needs
First shared records in the proposed design. Scope and operations will be agreed with design partners.
Patient
Who the record belongs to
Appointment
When care is scheduled
Coverage
How care may be covered
Observation
Clinical values and results
Document
Notes and supporting records
Which EHRs come first?
Epic, Oracle Health and athenahealth are initial targets. This is a design direction, not connector coverage.
Epic
Target · connection not validated
Oracle Health
Target · connection not validated
athenahealth
Target · connection not validated
What a unified API cannot remove
Vendor and site approvalsLocal identifiers and field meaningsRead and write permissionsPatient matching and clinical reviewClearinghouse contractsAcceptance testing at each site
Choose the layer for the job
ApproachThe jobWhat remains
Unified APIKeep a common format across EHRsVendor access and site-specific differences
Direct FHIRBuild to one system's FHIR interfaceYour team owns vendor differences
A networkRetrieve records across participating providersMembership, coverage and permitted purposes
An engineRoute and transform messagesProduct-facing records and site operations
Our team builds with your team
We implement with you under your vendor agreements.
Custom code built for you is yours once paid, per our terms.
YOUR TEAMProduct decisions, vendor agreements and customer sponsorship
OUR TEAMConnection design, mapping and implementation with you
AGREED TOGETHERAcceptance evidence, support and operating ownership
Data handling: agree the route before PHI flows +
Your productAgreed processing environmentCustomer EHR
Hosting, storage, retention, access and support responsibilities need to be agreed for your engagement. We sign a BAA before PHI flows. Do not assume a generally available API or hosting arrangement.
A working conversation
Bring the connection holding your product back
What you bring
A product workflow and required records.
The target EHR and a customer sponsor.
Your access status and write requirements.
What you get
A review of feasibility and access gaps.
A proposed first-site scope.
Acceptance checks and ownership to agree.
The conversation carries no promise of launch dates, pricing, program places or vendor approval.
Questions before we connect
What is a unified healthcare API?+
A common request format across different healthcare systems. Interoply is building this shared format with design partners; it is not generally available.
Is an EHR integration API the same as FHIR?+
FHIR is a healthcare data standard. An EHR integration API may use FHIR, vendor-specific interfaces, HL7 v2 or other transports. A common format still needs mappings and site acceptance checks.
Do EHR APIs cover reads and writes?+
It depends on the vendor, record type, application permissions and site. Read access does not establish write access. We scope each required operation with you.
Do I still need approval from Epic or Oracle Health?+
Yes, applicable vendor programs, agreements and customer site approvals remain. We implement with you under your vendor agreements; a common format cannot grant access.
Is the API available now?+
The shared API is being built and is not generally available.
Can I use it with HL7 v2 and X12?+
FHIR, HL7 v2 and X12 are part of the intended scope. Transport, clearinghouse access and per-site mapping still need review. This is not a promise of a working connection.
Who owns the integration code?+
Custom code built for you is yours once paid, per our terms. Vendor agreements stay in your name. Ownership and operating responsibilities are agreed in the scope.
We use cookies to enhance your browsing experience, serve personalized content, and analyze our traffic. By clicking "Accept All", you consent to our use of cookies. Read our Privacy Policy
