DFT - The specification is currently in development 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.

Notes:

• Single Entry Models primarily supporting routing referrals.
• Single Entry Models could provide support for splitting and chaining referrals, but is not a requirement.

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 acknowledgement, acceptance, status updates (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.)