Digital Health & Interoperability. Standards-first systemsthat talk to each other.
We connect EHRs, payers, devices and national networks using the standards US health data runs on: FHIR, HL7, X12 and TEFCA. Payer APIs, hospital systems and devices become one connected, governed flow.
A short call with a senior expert. No patient information needed.
Systems that must talk
- EHR & hospital systems
- Payers & plans
- Labs & imaging
- Devices
- Networks & public health
The standards layer we build
- 1Connect: HL7 v2, FHIR, X12, APIs
- 2Map to USCDI and US Core
- 3Authorize: SMART, consent, audit
- 4Monitor and fix every exchange
What flows
- Prior authorizations
- Patient access
- Quality & claims data
- Device data in the chart
Built on the standards US health data runs on
- HL7 FHIR and US Core
- USCDI
- SMART App Launch
- HL7 v2
- X12 (837, 835, 278)
- TEFCA
- Da Vinci implementation guides
- IHE profiles
- HIPAA
Watch 46 seconds
Systems that talk to each other: how we connect health data on open standards
Read the film as text
- Your systems hold the data.Getting them to talk is the hard part.
- Why it matters$1M maximum civil penalty per information-blocking violation. Source: HHS For health IT developers, exchanges and networks.
- Standards first, then connected.Standards first. EHR & hospital systems. Payers & plans. Labs & imaging. Devices. Networks & public health. FHIR, HL7, X12 and TEFCA, with authorization, consent and audit.
- What flows.Prior authorizations. Patient access. Quality & claims data. Device data in the chart.
- During Health.Standards-first systems that talk to each other. Book an interoperability review, or Free readiness scorecard, at duringhealth.com.
What is changing in interoperability right now
Dated facts, each with its source. This part of the page is refreshed regularly; the rest is built to last.
70,000+
sites exchanging data on TEFCA
More than 474 million documents shared since go-live in December 2023. Payment and health care operations, including HEDIS reporting, are now authorized exchange purposes.
ASTP/ONC TEFCA update, Feb 19, 2026As of Oct 202613 hours
a week spent on prior authorization per physician
The AMA’s 2025 survey of 1,000 physicians found about 40 requests a week, 95% of physicians reporting care delays and 40% employing staff who work only on prior authorization.
July 4, 2026
when the CMS Interoperability Framework’s technical criteria took effect
Networks that want to be listed as CMS-Aligned Networks provide FHIR API access following US Core and USCDI v3, return documents as FHIR attachments, support encounter notifications and keep HITRUST or an equivalent. The framework is voluntary and does not override HIPAA.
CMS, Interoperability FrameworkAs of Oct 2026$1M
maximum civil penalty per information-blocking violation for developers, exchanges and networks
HHS announced a crackdown on September 3, 2025. Providers in certain CMS programs can face disincentives, and developers with certified products can lose certification. ASTP/ONC and the HHS Office of Inspector General share enforcement.
HHS, crackdown on health data blockingAs of Oct 2026
Jan 1, 2027
payer FHIR APIs go live
CMS-0057-F requires Patient Access, Provider Access, Payer-to-Payer and Prior Authorization APIs: new, structured data streams that only organizations with a ready foundation can use.
Every number links to its source.
What most teams get wrong about interoperability
Myth
“Our EHR vendor handles interoperability for us.”
Fact
Vendors provide the interfaces. Someone still has to decide what data to send, map it correctly, handle the errors and prove it works with each partner.
Myth
“FHIR means we can plug anything into anything.”
Fact
FHIR is a common language, not a finished conversation. Each partner uses it a little differently, so testing every connection is still the work.
Myth
“Interoperability is an IT project.”
Fact
It changes revenue, quality reporting, prior authorization and patient access. It needs an owner from operations and compliance, not only from IT.
Four things you can hold us to.
Payer & prior-auth API readiness
Prepare provider systems to work with payers’ new FHIR-based prior-authorization and data-exchange APIs.
What you get
- An inventory of your payers and the APIs each one offers
- A prior authorization workflow with a portal fallback
- Written readiness questions and a test plan for your EHR vendor
- Turnaround and denial measurement by payer
HIMS build & maintenance
Deploy, integrate and maintain hospital information systems on-site, full-lifecycle.
What you get
- Selection, configuration and rollout of hospital and clinical systems
- Data migration and cutover planning
- Training and go-live support
- Ongoing maintenance and a service desk
Device & hardware integration
Connect medical devices and hardware to administrative and clinical software.
What you get
- Monitors, analyzers and imaging devices connected to clinical and billing systems
- Standards-based capture, with device data landing in the chart
- Validation, security testing and uptime monitoring
- Support for hardware rollouts
Interoperability
FHIR and HL7 integration across systems and partners.
What you get
- Interface and API design for HL7 v2, FHIR and X12
- Mapping to USCDI and US Core
- Connections to health information exchanges and national networks
- Monitoring dashboards and error queues
Everything we do in digital health and interoperability
Ten service areas, from the first payer connection to the monitoring that keeps every interface healthy. Most engagements start in one and grow into the others.
Payer API & prior authorization readiness
Using payers’ new APIs without breaking today’s workflow.
- Payer and API inventory
- Electronic prior authorization workflow design
- EHR vendor readiness and testing
- Portal and fax fallback
Interface & integration engineering
Reliable plumbing between systems.
- HL7 v2, FHIR and X12 interfaces
- Interface engine design and build
- Interface inventory and rationalization
- Error handling and replay
FHIR & API development
Opening your data the standard way.
- FHIR servers and facades
- Bulk data export
- SMART apps and API gateways
- API documentation and developer onboarding
HIE, TEFCA & national network connectivity
Exchanging with organizations you do not know yet.
- Connecting through an existing network
- Record location and query response
- Exchange-purpose policy
- Measuring response quality
Terminology & data mapping
Making the same word mean the same thing.
- USCDI and US Core mapping
- SNOMED CT, LOINC, RxNorm and ICD-10
- Gap analysis against partner specifications
- Mapping governance
Clinical systems & EHR rollouts
New systems that go live without drama.
- Selection and configuration
- Data migration and cutover
- Training and go-live support
- Ongoing maintenance and a service desk
Device & remote monitoring integration
Device data where the clinician needs it.
- Bedside and imaging devices
- Remote monitoring platforms
- Standards-based data capture
- Security and uptime monitoring
Consent, security & information blocking compliance
Sharing what you should, protecting what you must.
- Consent and sensitive-data segmentation
- SMART authorization and audit logging
- Information blocking policy and exceptions
- Security testing of interfaces
Patient access & app enablement
Patients and their apps, connected safely.
- Patient access API and app connections
- Digital front door integration
- Identity proofing and digital insurance cards
- Patient-generated data intake
Testing, monitoring & operations
Interfaces that stay up.
- Test environments and partner certification
- Alerting and error queues
- Service levels and incident response
- Change control for interfaces
How an engagement runs: start with one connection that matters
You see a working, monitored connection before you widen the program.
Map
List the systems, partners and data flows, and which standards each one uses.
You get
An integration map and a gap listDesign
Agree the data to exchange, the mapping and the security model.
You get
Specifications and a test planConnect
Build the first interface or API, test it with a real partner and fix what breaks.
You get
A working, monitored connectionRun
Operate it with alerts and error queues, add partners and hand over the runbooks.
You get
Runbooks, dashboards and a transfer option
Who we connect for
Hospitals and health systems
The problem
Dozens of point-to-point interfaces that nobody fully understands.
A good first project
An interface inventory and a prior authorization workflow with a fallback.
Physician groups and MSOs
The problem
Several EHRs, and payers asking for new connections.
A good first project
One integration approach for every site.
Payers and health plans
The problem
Required to publish and run APIs, and to exchange data with providers and other plans.
A good first project
API testing and provider onboarding support.
Health-tech companies
The problem
Every health-system customer wants a slightly different integration.
A good first project
A standards-based integration layer that works across customers.
Is your integration ready for what is next?
If you cannot tick most of these today, the foundation is the project, before any new connection.
- You can list every interface and who owns it.
- You know which payers offer APIs and which of your systems can use them.
- Your EHR vendor has told you in writing what it will support, and when.
- Prior authorization has a documented workflow, with a fallback.
- You can receive and store FHIR data without a custom project each time.
- Interface errors are monitored and fixed the same day.
- Consent and sensitive-data rules are applied to everything you share.
- Someone owns information-blocking compliance.
Three questions to ask your team on Monday
- 01
If one of our interfaces failed tonight, who would know, and how fast?
- 02
Which of our payers can accept an electronic prior authorization today?
- 03
Are we sharing data we should not, or blocking data we should share?
If the answers are slow or different in every room, that is where we start.
Check our thinking before you call us
We publish how we read the rules and give away the tools. Judge the depth for yourself.
- Article
CMS-0057-F and prior authorization: what providers must be ready for
The four FHIR APIs, the dates and a 90-day checklist.
- Article
Medicare EDI and HIPAA transactions explained
Every message in the life of a claim, and what each reply means.
- Tool
HIM technology readiness scorecard
Score a new technology in 15 minutes. Nothing is stored.
- Download
HIM technology readiness self-assessment
A 15-page workbook with vendor questions and red flags.
Do we need to build our own FHIR APIs?
Not necessarily. Your EHR vendor may provide them. The work is deciding what to expose, mapping the data correctly, authorizing access and testing with partners, which is where we help.
What do providers have to do about the payer APIs?
Payers must provide them, and providers are not required to build anything. Providers benefit by connecting their workflow, and CMS has tied a prior authorization measure to provider reporting programs. Our CMS-0057-F guide keeps the current dates.
What is TEFCA, and do we need to join?
TEFCA is a national framework for exchanging health information through designated networks. Participation is voluntary today, and most organizations connect through an existing network rather than becoming one.
What is information blocking?
A practice likely to interfere with access, exchange or use of electronic health information, outside defined exceptions. Providers, health IT developers and exchanges are covered, with different consequences for each. Ask your counsel which exceptions apply to you.
How long does an integration take?
It depends on the systems, the partner and how clean the data is. We estimate after mapping the flows and agree a first milestone before building.
How do you protect PHI?
Only under a written agreement, including a business associate agreement where HIPAA applies, signed before any PHI is shared. We use the minimum necessary, role-based access, encryption and audit logging.
Can you work with our current vendors?
Yes. We are vendor-neutral and work with your EHR, interface engine and cloud, and we do not require you to switch.
Start with one connection that matters.
Tell us which exchange hurts most: a payer, a lab, a device or a national network. We will tell you what it takes to make it reliable.
Please do not send patient information. Describe the situation without identifying anyone.