FHIR · TEFCA · USCDI integration
Production FHIR R4 server covering 42 resource types, SMART on FHIR v2.1 with PKCE, TEFCA QHIN handshake against Epic Nexus and CommonWell, and a tamper-evident audit chain scoped to the Consent that authorized each read. Passed external info-blocking review without remediation.
What is FHIR R4 healthcare interoperability?
FHIR R4 (Fast Healthcare Interoperability Resources, Release 4) is the HL7 standard that defines a REST API and resource model for exchanging clinical and administrative data across EHRs, payers, and public health networks. Combined with SMART on FHIR, TEFCA, and USCDI v3, it is the foundation for ONC-compliant patient access and provider interoperability in the United States.
The problem: FHIR R4 interoperability across multiple networks
An EHR partner needed to ingest and emit FHIR R4 across multiple healthcare networks, covering Patient Access, Provider Directory, Prior Authorization, payer-to-payer Member Match, and population-level Bulk Data. The wire stack pulled in TEFCA QHIN exchange against Epic Nexus, CommonWell, and eHealth Exchange. The client surface needed SMART on FHIR v2.1 with PKCE and asymmetric client credentials so any third-party app could launch with the right scopes.
The previous integration covered eight resources. Each new partner meant a fork in business logic to absorb their quirks: a custom Coverage extension here, a non-conformant Patient.identifier there, a Bundle ordering assumption that broke under partial responses. Onboarding ran for weeks. There was no terminology service for ValueSet $expand or $validate-code, so consumers shipped local code-system copies that drifted apart inside a quarter.
Logs leaked PHI across three subsystems. The audit trail did not scope reads and writes to the Consent resource that authorized them, so info-blocking review surfaced gaps the team could not close incrementally. Bulk $export ran on a synchronous worker that fell over above a few thousand records, and there was no $import path for inbound population pulls from payers.
How we built a production FHIR R4 platform
We built a strict FHIR R4 server on .NET with conformance to US Core 6.1.0, CARIN BB v1.2, HRex/PDex PlanNet, the Argonaut scheduling profiles, and five Da Vinci implementation guides: PAS for prior authorization, CRD for coverage requirements discovery, DTR for documentation templates and rules, CDex for clinical data exchange, and the Rules IG. Forty-two resource providers cover Patient, Encounter, Observation, Condition, Procedure, MedicationRequest, AllergyIntolerance, Immunization, DiagnosticReport, CarePlan, CareTeam, Goal, Device, Coverage, Claim, ClaimResponse, ExplanationOfBenefit, Appointment, Schedule, Slot, Practitioner, PractitionerRole, Organization, Location, Endpoint, HealthcareService, InsurancePlan, DocumentReference, Consent, AuditEvent, Task, Subscription, Questionnaire, QuestionnaireResponse, ResearchStudy, ResearchSubject, AdverseEvent, MedicationKnowledge, FormularyList, ValueSet, CodeSystem, and Library.
A native terminology service exposes $expand, $validate-code, and $lookup over a curated set of code systems: LOINC for observations, SNOMED CT for clinical findings, RxNorm for medications, ICD-10 for diagnoses, NDC for drug products, HL7 v3 ActCode for coverage and consent semantics, plus US Core ValueSets and CARIN BB benefit categories. Custom operations include Patient/$everything for chart pulls, Practitioner/$validate-npi for provider verification, and Patient/$match for payer-to-payer Member Match. Search parameters cover the full US Core surface plus 27 custom Patient parameters with conditional create and conditional update support across every resource provider.
SMART on FHIR v2.1 covers authorize, token, refresh, revoke, and userinfo with PKCE and asymmetric client confidential credentials per the SMART App Launch spec. Scopes are enforced at every endpoint via patient/*, user/*, and system/* token claims with per-tenant isolation. The TEFCA Common Agreement v2.0 layer wraps a typed adapter so QHIN-specific behaviour for $tefca-patient-discover and $tefca-document-query never leaks into business logic. Bulk Data Access supports both $export and $import with checkpointed background jobs; the FHIR Subscriptions backport delivers REST-hook, WebSocket, email, and message channels.
PHI redaction filters every log line at the Serilog enricher; tamper-evident audit events form a hash-linked chain stored in WORM archive and replayable for forensic review. Da Vinci PAS submits prior authorization round-trips against payer endpoints with X12 278 mapping; CDS Hooks v1.0 wires Da Vinci CRD discovery and invocation into clinical workflows. Member Match issues short-lived signed JWTs for payer-to-payer Patient/$match. The FDA Real World Data module emits CDIS and SDTM-shaped extracts from ResearchStudy, ResearchSubject, and AdverseEvent for regulatory submissions. Onboarding a new partner is a TrustedPartnerRegistry config row, not a code change.
Stack and engineering choices
- FHIR R4 server on .NET 10 (Hl7.Fhir.R4 5.11.4)
- US Core 6.1.0 + CARIN BB v1.2 + Argonaut
- Da Vinci PAS, CRD, DTR, CDex, Rules IGs
- PlanNet provider directory (HRex/PDex)
- SMART on FHIR v2.1, PKCE, asymmetric creds
- OAuth2 scopes: patient/*, user/*, system/*
- TEFCA Common Agreement v2.0 (QHIN handshake)
- Bulk Data $export and $import with checkpoints
- FHIR Subscriptions backport: REST-hook, WebSocket
- Terminology: LOINC, SNOMED CT, RxNorm, ICD-10, NDC
- Custom ops: $everything, $match, $validate-npi
- CDS Hooks v1.0 + Da Vinci PAS X12 278 mapping
- PHI redaction + tamper-evident WORM audit chain
- TrustedPartnerRegistry: config-driven onboarding
Outcome: info-blocking review passed, HIPAA posture held
The integration passed external info-blocking review without remediation. Every read and write traces back to the Consent resource that authorized it; PHI never appears in logs, only opaque request IDs. The audit chain replays end-to-end in CI as a regression check, so HIPAA posture never bit-rots between releases.
New TEFCA partners onboard via TrustedPartnerRegistry configuration, not core changes. Epic Nexus, CommonWell, and eHealth Exchange handshakes coexist behind one adapter contract; partner-specific quirks stay in the adapter layer. SMART app launches now stand up in hours instead of days because the OAuth2 surface is uniform across endpoints and self-discoverable through the well-known smart-configuration document.
The capability statement advertises FHIR 4.0.1 with R5 backport extensions for SubscriptionTopic and Permission. Bulk $export and $import run on background jobs that survive multi-million-resource pulls without timing out. Prior Authorization round-trips that previously took staff hours complete in seconds with a full PAS bundle. The platform now supports Patient Access, Provider Directory, Prior Auth, payer-to-payer Member Match, formulary queries, Bulk Data, and FDA Real World Data on one server, one auth surface, one audit chain.
Need something similar built and shipped?
For the controls behind these outcomes, see our HIPAA posture and audit chain practices and the wider security overview.
See more healthcare integration work at quadevs, including Multi-clinic web platform and HEDIS measurement pipeline.
Have a project that overlaps this work?
Send a one-paragraph brief. We reply within one business day.
hello@quadevs.com