Visit the HL7 website
Visit the FHIR website

Pan-Canadian eReferral-eConsult (CA:eReC) v1.1.0-DFT-Ballot

1.1.0-DFT-Ballot   Canada flag
  • Index
  • Home
  • Business Context
    • Business Models
    • Use Cases
    • Business Events
    • Business Rules
    • Privacy and Security Guidance
    • Provincial Considerations
  • Technical Context
    • Technical Foundation
    • Integration Patterns
    • Messaging
    • Sequence Diagrams
    • Conformance Requirements
  • FHIR Artifacts
    • Messaging Events
    • Resource Profiles
    • Extensions
    • Terminology
    • Examples
    • Capability Statements
    • Downloads
    • ---
    • Appointment (CA:eReC)
    • Bundle (CA:eReC)
    • Communication (CA:eReC)
    • DocumentReference (CA:eReC)
    • Location (CA:eReC)
    • MessageHeader (CA:eReC)
    • Organization (CA:eReC)
    • Patient (CA:eReC)
    • Practitioner (CA:eReC)
    • PractitionerRole (CA:eReC)
    • HealthcareService (CA:eReC)
    • QuestionnaireResponse (CA:eReC)
    • ServiceRequest (CA:eReC)
    • Task (CA:eReC)
  • Change Log
    1. Index
    2. Business Context
    3. Business Models
    4. Single Entry Models

preBallot - The specification is currently in ballot review and subject to change. . . . For a full list of available versions, see the Directory of published versions

Single Entry Models

Single Entry Models aim to provide more equitable access to services and enable load balancing between service providers (etc.) by having a centralized entity perform services in support of the Requester HCP and/or Performer HCP within a service area and/or referral pathway.

Services performed by this centralized entity may include:

  • Providing a single point for Requester HCPs to send service requests to for a defined geographic area or pathway with the centralized entity performing the Case Assigner role
  • Providing a quality assurance step by reviewing / triaging requests for completion and appropriateness before the Case Assigner assigns the request to a Performer HCP, and/or
  • Providing load balancing and potentially reducing wait times as Case Assigners delegate requests to the next available or most appropriate provider for the requested service.

Single Entry Models may be implemented using the Single RMS Model or within a network of RMS solutions integrated using the Point to Point Model.

Service Record "ownership" in the Single Entry Models

In Single Entry Model workflows the roles of Requester HCP and Case Assigner are performed by different people or organizations. In these cases, there will be two (or more) separate "requests" that need to be appropriately managed by the Case Assigner and Central System (RMS).

In the case of a routed referral, the two requests would be:

  • A service request from the Requester HCP to the Case Assigner (e.g.: to accept the service request, assign it appropriately, keep the Requester HCP updated as the service is performed), and
  • A service request from the Case Assigner to the Performer HCP (e.g.: to accept the service request, perform it, keep the Case Assigner updated as the service is performed).

To support this, an integrated "Central System (RMS)" used by the Case Assigner will employ separate messaging approaches to:

  1. Enable the Case Assigner to receive the service request from the Requester HCP / Source System, communicate acceptance (etc.)
  2. Enable the Case Assigner to transmit the service request to the Performer HCP / Target System and receive, acceptance, (etc.)
  3. Enable the Case Assigner to notify the Requester HCP / Source System of its interactions with the Performer HCP as the service request is assigned, accepted, completed (etc.)

Table of Contents | IG © based on FHIR R4 | Package package:ca.infoway.io.erec@1.1.1-dft-ballot | Version History
HL7® and FHIR® are the registered trademarks of Health Level Seven International