Care Coordination and 360 Referrals (Proof of Concept) - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Overview Model

The information models and FHIR resources for a closed loop referral and the care it belongs to.

Information Models

Four logical models describe the information, independent of how it is exchanged. Each model's Mappings tab shows its elements in FHIR (and HL7 v2 where used).

flowchart LR
    CP[Care Plan<br/>who is doing what] -- "activity" --> CR[Clinical Referral<br/>ServiceRequest + Task]
    PS[Patient Summary<br/>EPS] -. "supportingInfo<br/>(input)" .-> CR
    DR1[Discharge Report / letter<br/>HDR - previous episode] -. "supportingInfo<br/>(input)" .-> CR
    CR -- "Task.output<br/>(outcome)" --> DR2[Discharge Report / letter<br/>HDR - this episode]
    DR2 -- "activity outcome" --> CP

How the Clinical Referral breaks down into FHIR resources, who owns each one and how they travel is described on the Clinical Referral model page.

The referral itself stays small; the clinical content travels as documents, which can also be published to a shared care record and retrieved by API instead of being sent (see EU Health Data API).

Not modelled on BaRS. None of these models takes its structure from BaRS. In particular: the referral's request, reason and requester are on the ServiceRequest (not a Task, Condition and Practitioner as in BaRS Application 5); workflow state is a Task, not a combination of ServiceRequest, Encounter and CarePlan statuses; a CarePlan is a plan, not an assessment; and the patient's local identifier always has a type and assigning organisation. See the BaRS review.

References

• FHIR Workflow, ServiceRequest, Task
• HL7 Europe Hospital Discharge Report, HL7 Europe Patient Summary and HL7 Europe Base
• IHE Dynamic Care Planning and FHIR CarePlan
• NW GMSA - Genetic Referrals: Target Referral Model

Resource Model

erDiagram
    ServiceRequest {
        Identifier referralId "ReferralIdentifier"
        Identifier ubrn "UBRN (eRS)"
        code status
        code priority
        CodeableConcept category "referral / virtual ward"
        CodeableConcept code "service referred to"
        CodeableConcept reasonCode
        dateTime occurrence "expected by"
    }
    Task {
        code status
        CodeableConcept businessStatus "360X state"
        CodeableConcept statusReason "decline / cancel reason"
    }
    Appointment {
        Identifier appointmentId
        code status "booked / noshow / cancelled"
        instant start
    }
    Composition {
        CodeableConcept type "Consult Note / Hospital Discharge Summary"
    }
    Encounter {
        Coding class "IMP for a virtual ward"
        CodeableConcept admitSource "step-up / step-down"
    }
    CarePlan {
        CodeableConcept category
    }
    Patient {
        Identifier nhsNumber
        Identifier mrn
    }
    PractitionerRole
    HealthcareService

    ServiceRequest }o--|| Patient : subject
    ServiceRequest }o--|| PractitionerRole : "requester (Referral Initiator)"
    ServiceRequest }o--o{ HealthcareService : "performer (Referral Recipient)"
    ServiceRequest }o--o| CarePlan : "basedOn (care plan activity)"
    Task }o--|| ServiceRequest : "basedOn / focus"
    Task }o--o| HealthcareService : owner
    Task ||--o{ Appointment : output
    Task ||--o{ Composition : output
    Appointment }o--|| ServiceRequest : basedOn
    ServiceRequest }o--o{ Composition : "supportingInfo (input documents)"
    Composition }o--o| Encounter : encounter
    Encounter }o--|| ServiceRequest : basedOn
    CarePlan }o--o| Encounter : encounter

Profiles

Identifier profiles: Referral Identifier and UBRN; the NW GMSA identifier data types (NHS Number, MRN, ODS code and others) are copied from the NW GMSA IG.

Identifiers

References to the referral SHOULD carry the Referral ID as Reference.identifier as well as (or instead of) a literal reference, because the Referral Recipient usually does not hold the Referral Initiator's ServiceRequest on a shared server.

Referral Status

The 360X HL7 v2 status codes, the Referral Workflow Status (Task.businessStatus) and the FHIR status elements:

Task.status follows the FHIR Task state machine; businessStatus carries the 360X detail. Open: ORC-5 to Task.status is not a one-to-one mapping (e.g. IP covers both accepted and in progress).

Examples