DRAFT - The specification is currently in development and subject to significant change. It is not ready for limited roll-out or production level use.
Glossary of Terms
| Term / Acronym | Meaning |
|---|---|
| API | Application Programming Interface |
| Central Intake | A Central Intake model to manage eReferrals may be implemented (provincially, regionally, or locally at organization level) for specific health care specialties/services. When a central intake model is used for eReferrals, Central Intake serves as a centralized mechanism or intermediary to manage eReferral requests, ensuring incoming requests are assigned to an appropriate specialist/service provider. |
| Central Access and Triage (CAT) | A centralized service which may include both automated and manual activities to receive, maintain, manage and disseminate referral and/or eConsult requests across all participants. The CAT service may originate and/or contribute to the contents of the referral or eConsult; and is the sole party responsible for assignment of requests to the responsible service provider. As the owner of the referral record, the CAT has responsiblity to the Referring Provider, Patient and Service Provider for ensuring that the record is complete, that the services are appropriate and are performed. |
| Central Infrastructure | A Central Infrastructure collects health information from participating organizations and stores the information in a centralized place. The Infrastructure also provides access control. Typically, the Central Infrastructure is under jurisdictional control. |
| Central System | A system (typically an RMS) that is used by a Case Assigner to receive, triage and assign service requests to Performer HCPs to be completed. Some business and deployment models (e.g.: Central Access and Triage) treat the Central System as the definitive source of the Service Record throughout the service lifecycle to support the use of Source System and/or Target System with limited RMS functionality. |
| Chaining | Chaining is a mechanism used when a referral is received, and after the service is performed, it results in one or more additional new distinct requests for downstream services created to fulfill the initially requested service. Chaining occurs after a service is performed, and the need was identified for additional services. |
| Connected System | A system that receives event based notifications containing Service Record information from an RMS without contributing content to or progressing the state of the record. |
| eConsult | Electronic request from a physician to receive advice from a specialist (i.e., provider-to-provider consultation). Enables asynchronous electronic communication between the requesting physician and specialist. |
| eReC Informer | The eReC Informer technical actor produces and sends FHIR messages to eReC Recipient(s) with a need to retain a copy of the referral record or to receive notifications as the state or content of the referral records changes. |
| eReC Performer | The eReC Performer is the technical actor that receives and responds where appropriate to the related FHIR Messages sent by the eReC Requester. This actor also produces and sends FHIR Messages to the eReC Requester corresponding to actions undertaken by Performer HCPs, Case Assigners or their delegates during the course of processing eReferral/eConsult requests and performing the requested services. In a closed loop electronic referral process, FHIR messages sent by the eReC Performer primarily serve to close the loop on the referral process by progressing the state of the referral, providing a mechanism to request additional information and to share information about appointments booked and outcomes. |
| eReC Requester | The eReC Requester is the technical actor that produces and sends FHIR Messages to an eReC Performer corresponding to actions taken by a Requester HCP during the referral lifecycle starting with transmission of a request for eReferral/eConsult services. The eReC Requester also receives and responds where appropriate to the related FHIR Messages sent by the eReC Performer. In a closed loop electronic referral process, FHIR messages sent by the eReC Requester primarily serve to provide Performer HCP's, Case Assigners and their delegates with information needed to triage the request and perform the requested service. |
| eReC Recipient | The eReC Recipient is technical actor that receives FHIR messages from the eReC Informer. In real world architectures, eReC Recipients may correspond to a broad range of systems that either seek to retain a copy of the referral record captured in an RMS (e.g.: Point of Service systems used for record keeping by HCPs participating in the referral process or at the patient's medical home or data repositories) or that may act upon notifications of business events |
| eReferral | Electronic request for a patient to receive care from a specialist or other services (e.g., home or community care, diagnostic exam, etc.) Patient referrals are created, submitted, tracked and managed electronically. |
| HCP | Healthcare Provider |
| Health Service Directory | Used by HCP or service provider to discover services and service providers to address eReferral needs. RMS typically bundle in HSD functionality to better support referral/consult workflows, or in cases where the POS system has the required capabilities to support the referral/consult workflow, the HSD could be centrally managed (i.e. jurisdictional) or provided by a 3rd party and integrated with the POS system. An HSD may provide one or more of multiple functions, including:
|
| HL7® Fast Healthcare Interoperability Resources (FHIR®) | Expected to be a next generation standards framework created by HL7. FHIR® combines the best features of HL7‘s Version 2, Version 3 and product lines while leveraging the latest web standards and applying a tight focus on implementability. (Source: http://www.hl7.org/implement/standards/fhir/) |
| Patient Portal | A patient portal is a web-based access point that enables secure patient access to personal health information and other self-serve health IT services. For example, a patient portal can be hosted on an EMR solution. |
| Performer HCP | A Health Care Provider or delegate (e.g. medical office assistant), or other service provider that receives the referral request and performs the requested services |
| POS | Point of Service system Used by HCPs to view and manage personal health information (PHI). These systems include hospital information systems (HIS), primary care electronic medical record systems (EMR), community and ambulatory health information systems, and provincial/regional EHR viewers. May also be called a Point of Care system (POC). |
| Requester HCP | A Health Care Provider or delegate (e.g. medical office assistant), or other service provider that initiates the eReferral workflow for a patient by sending a referral request. |
| RMS | Referral Management System. An information system that supports and enables the electronic referral process by storing the "Referral Record" and providing capabilities needed to maintain, manage and disseminate the referral information throughout the referral lifecycle, or the relevant lifecycle portion as supported by a given RMS implementation. |
| Routing | Routing is the mechanism used by a Central System when a referral is received and passed to a new Performer or destination as the same referral as the original. Routing occurs before a service is performed. |
| Service Record | Within this specification, Service Record refers to a definitive set of information that is collected, maintained and managed throughout the referral or consultation process. The Service Record includes information about the: - Patient who is the subject of the service request - Referring Practitioner who sent the service request - Service Request with a clinical Reason - Supporting documentation to support triage and processing of the request - Service Provider who has been assigned to performs the service with a location - Status of the request with a status reason - Appointment information (for referrals only) - Outcome (optional) |
| Source System | A POS or RMS that is used by a Requester HCP to initiate a service request and to receive and access information about the request's status with related information and appointments. |
| Splitting | Splitting is the mechanism used by a Central System when a referral that contains several different services gets split into multiple referrals for processing. |
| Target System | A POS or RMS that is used by a Performer HCP to receive and process service requests. |
| Technical Actor | An integration component of a system that implements applicable required or optional transactions from an integration profile that supports interoperability use cases. e.g. eReC Requester, eReC Performer |
| Terminology | Collection of uniquely identifiable concepts with associated representations, designations, associations and meanings. |
| Use Case Actor | People and systems that have high-level interactions or "conversations" when participating in an interoperability use case. e.g. Source System, Target System |