Resources
Anatomy of a closed-loop referral
The phrase “closed-loop referral” gets used as if everyone agrees what it means. In implementation, the disagreements are everywhere. This piece walks through what closed-loop actually requires, mapped to the standards that hospital information systems are converging on.
A referral is closed-loop when the ordering clinician can see, in their own system, what happened on the receiving end. That is the operational definition. Everything else (the standards, the resources, the protocols) is plumbing in service of that definition.
In practice, the loop has six stages, each of which is a place where the loop can break. Most production systems get one or two of them right and rely on phone tags or fax to bridge the rest.
Identification
A clinical or social need is identified during the ED visit. Most commonly, a structured screening instrument captures the need (AHC-HRSN, PRAPARE, or a CMS-aligned short form), or the clinician documents it directly in the encounter. The need is recorded in the EHR with structured terminology, ideally including the matching ICD-10 Z-code.
FHIR artifact: Observation resource with SDOH category, or Condition with Z-code.
Order
An eReferral is created and routed to the receiving service. For social referrals, that service is a community-based organization or a referral platform aggregator. For clinical home-based services, it is the hospital-at-home program, a home health agency, or a community health worker team.
FHIR artifact: ServiceRequest resource with intent = order, with the receiving service as performer.
Acceptance
The receiving service acknowledges the referral, confirms patient eligibility, and schedules an action. This is the first place a referral typically dies in practice: the order leaves the ED, but no acknowledgment ever returns. A closed-loop architecture treats acceptance as a structured event, not a missing data point.
FHIR artifact: Task resource with status transitions (received, accepted, rejected).
Encounter
The visit, call, or service actually happens. For home-based care, this is the dispatched visit; for a community resource referral, this is the connection with the agency. Closed-loop infrastructure captures the encounter as structured data, with timestamp, performer, and outcome.
FHIR artifact: Encounter or Procedure resource on the receiving system.
Outcome
The result of the encounter is recorded: the food box was delivered, the home visit was completed, the patient was connected with housing services, the IV antibiotic course was finished. Outcomes that are negative (no-show, refused, ineligible) are equally important to capture because they drive the next action.
FHIR artifact: Observation, Condition, or Goal resource tied back to the index ServiceRequest.
Reconciliation
The outcome is fed back to the ordering EHR and to the patient's longitudinal record. The original ServiceRequest is updated to a terminal status. The next clinician who sees this patient (in the ED, in primary care, or in a follow-up program) can see what happened.
FHIR artifact: Communication or DocumentReference linking outcome to the original order.
The standards that close the loop
Three bodies of work are doing the standardization that makes closed-loop referrals interoperable across systems:
- USCDI (United States Core Data for Interoperability). The current versions add SDOH assessments, goals, and interventions as required data classes. Receiving systems that comply can ingest the order and report outcomes back in a structured way.
- The Gravity Project. An HL7 FHIR Accelerator that maintains the social-determinants terminology, value sets, and FHIR implementation guides. The SDOH Clinical Care IG defines how the Observation, Condition, ServiceRequest, and Goal resources are profiled for SDOH workflows.
- HL7 eReferral and Da Vinci. The technical pipes that move ServiceRequest and Task resources between ordering and receiving systems with structured status transitions. This is what makes the acknowledgment and reconciliation steps automatable.
A program that wants to be honest about closing the loop should be able to produce the FHIR artifacts at every stage, on demand, for every referral it places. If the only evidence the loop closed is a phone-call note in the EHR free text, the loop has not been closed.
Where the loop actually breaks
In our experience and in the published literature, the failure points cluster in three places.
Stage 3 (Acceptance). The receiving organization has no inbound API and no FHIR endpoint. The referral arrives as a fax, a portal entry, or an email. There is no automatable acknowledgment back to the EHR, so the ordering clinician has no signal that anything is happening.
Stage 4 (Encounter). The visit happens but is recorded only on the receiving system, in a format that is not exchanged. This is especially common with community-based organizations whose case management systems are not interoperable with hospital EHRs.
Stage 6 (Reconciliation). Even when the outcome is captured, the link back to the original ServiceRequest is not preserved. The next clinician sees a Communication note with no obvious tie to the index visit.
Closing each of these breakpoints is a workflow problem first and a standards problem second. Standards make automation possible; they do not make it happen.
Related reading
Capillary Health for Emergency Medicine
How ED teams plug into closed-loop home-care referrals after discharge.
SDOH Z-codes for home-care referrals
Practical mapping of ICD-10 Z55 to Z65 codes to home-based response types.
The Gravity Project
HL7 FHIR Accelerator maintaining SDOH terminology, value sets, and implementation guides.
USCDI (HealthIT.gov)
The required data classes for certified health IT. Read which SDOH elements are in the current version.
Building a referral pathway that actually closes?
Capillary Health is the dispatch and routing layer for the response side of the loop. We talk to ED teams, hospital-at-home programs, and home health agencies about what closed-loop looks like in their workflow.