A referral platform lives between many adjacent systems, not just between one sender and one receiver
Designing referral software means mapping the ecosystem around it. The platform usually receives intent from an EHR or practice system, checks identity against enterprise services, coordinates with departmental systems for fulfillment, and pushes outcomes into portals, repositories, or back to the originating record.
Referral ecosystem around the core workflow
Loading diagram...
What adjacent systems often contribute to patient-referral workflows
| System | Contribution | If missing or weak |
|---|---|---|
| EHR or PMS | Clinical intent, patient demographics, originator identity | Weak order context and hard-to-close communication loops |
| MPI or national identity layer | Identifier cross-reference and demographics lookup | Duplicate or mismatched patient records across domains |
| Provider directory or service catalog | Destination routing and endpoint trust | Referrals sent to the wrong team or channel |
| Departmental servicing system | Acceptance, scheduling, execution, and operational state | No trustworthy downstream workflow view |
| Repository or portal | Cross-enterprise sharing and consumer access | Results trapped inside one local application boundary |
Identity federation is what lets adjacent systems talk about the same patient without sharing one local id
Many referral designs fail because teams assume every connected system already agrees on patient identity. In reality, an ICU, a practice system, and a hospital registration system may all use different local identifiers for the same person. Referral software either resolves that difference explicitly or spends its life in reconciliation queues.
Identity resolution is necessary but not sufficient
Knowing which patient the request belongs to does not mean the referral is complete, authorized, or clinically accepted. Keep identity and workflow decisions separate.
Document-sharing and repository patterns matter when the referral ecosystem extends beyond one departmental API
Not every referral consumer needs direct access into a servicing system. Some need standardized document query and retrieve behavior for referral letters, reports, summaries, or regional copies of results. That is where IHE document-sharing patterns add value alongside direct HL7 or FHIR workflow APIs.
Direct workflow APIs and document-sharing patterns solve different layers
| Pattern | Best for | Typical example |
|---|---|---|
| Direct order or task API | Operational control of live workflow state | Submitting or updating a referral work item |
| Scheduling API or Appointment contract | Capacity offers, booking, and rescheduling | Finding slots and reserving a patient visit |
| MHD or XDS-style exchange | Document publication, search, and retrieval across organizations | Finding referral letters or results in a regional document domain |
| Imaging-sharing profile such as XDS-I | Cross-enterprise access to images and related manifests | Retrieving prior imaging context from another facility |
PIXm implementation guide
Official IHE guide for mobile patient identifier cross-reference, including multiple identifier-domain use cases.
Read the PIXm guidePDQm implementation guide
Official IHE guide for patient demographics query over RESTful patterns that often complements PIXm.
Read the PDQm guideMHD actors and transactions
Official IHE MHD page showing the publish, query, and retrieve actors used in modern document exchange.
Read the MHD actor modelXDS.b integration profile
Official IHE XDS.b chapter for affinity domains, registries, repositories, and cross-enterprise document sharing.
Read the XDS.b profileKnowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.