Profiles & Operations Index > Artifacts
FHIR Artifacts
FHIR resources serve as the core components for information exchange between healthcare systems. These resources support clinical records, patient identification, provider management, and more. The profiles below are organized by registries and source systems. Each section includes the artifact name, specifying whether it represents a FHIR profile, operation, or terminology; a description; and a source column, which indicates whether the profile is internal (created by LRA) or external (leveraged from source system artifacts). Even when external profiles are used, the LRA may adopt different interaction patterns, preferring a RESTful approach over custom operations where applicable.
Client Registry
For the Patient, LRA uses Client Registry FHIR profiles. While the underlying source systems follow operations-based approach, LRA adopts a RESTful approach to manage and access resources (except merging patients).
| Artifact Name | Description | Source |
|---|---|---|
| Patient (Client Registry) | Identifies patients in the client registry. The profile page outlines different interaction capabilities supported by LRA (such as Search, Create, Update and Merge) | External |
| Operation: $MergePatient | This operation is used to merge patients. | External |
Provider Location Registry
Provider Location Registry (PLR) is a fully pass-through integration with LRA. The profiles and operations in this section use the same format as PLR, with no modifications by the LRA.
| Artifact Name | Description | Source |
|---|---|---|
| Operation: Practitioner $entityQuery | This operation is used to query for a practitioner and will return the information for that practitioner without following associations to other providers, organizations, or facilities. | External |
| Operation: Organization $entityQuery | This operation is used to query for an organization and will return the information for that organization without following associations to other providers, organizations, or facilities. | External |
| Operation: Location $entityQuery | This operation is used to query for an location and will return the information for that location without following associations to other practitioner, organizations, or locations. | External |
Following are the list of profiles referenced by the above operations:
| Artifact Name | Description | Source |
|---|---|---|
| BC Practitioner | General constraints on the Practitioner resource for use in the BC Provider Registry project. | External |
| BC PractitionerRole | General constraints on the PractitionerRole resource for use in the BC Provider Registry project.. | External |
| BC Role Relationships | General constraints on the PractitionerRole resource for use in the BC Provider Registry project to describe relationships. | External |
| BC Organization | General constraints on the Organization resource for use in the BC Provider Registry project. | External |
| BC Organization Affiliation | General constraints on the OrganizationAffiliation resource for use in the BC Provider Registry project. | External |
| BC Location | General constraints on the Location resource for use in the BC Provider Registry project. | External |
Medical Service Plan (MSP)
The Health Insurance British Columbia (HIBC) and Medical Service Plan (MSP) Eligibility team have developed a new service for the Provincial Health Services Authority (PHSA), called the PHSA Eligibility Service. This service provides the LRA Platform with eligibility information directly from the source of truth (HIBC MSP), as the Ministry of Health's EMPI system does not include this information in their FHIR package. These profiles have been developed by the LRA project to manage data related to the MSP (Medical Services Plan).| Artifact Name | Description | Source |
|---|---|---|
| CoverageEligibilityResponse (MSP) | Provide the LRA Platform the same information currently provided to the MoH EMPI Provincial System to determine Medical Service Plan (MSP) Eligiblity | Internal |
Provincial Attachment System (PAS)
The Provincial Attachment System (PAS) enables healthcare providers to manage a patient’s membership in their panel or roster at a specific healthcare facility. Through seamless messaging interactions, providers can ensure that their Electronic Medical Records (EMR) systems are aligned with PAS, eliminating the need for manual updates and ensuring panel data is consistent across both systems. PAS allows providers to retrieve and manage the Most Responsible Provider (MRP) status, helping improve administrative efficiency and care coordination.
Using FHIR messaging protocols encapsulated in Bundles, requests and responses are exchanged between the systems, enabling smooth communication. This page provides documentation on the structure of PAS (Request) and PAS (Response) messages, and the resource profiles that form the foundation of these interactions.
Request
A PAS (Request) is transmitted as a Bundle that contains a set of PAS FHIR profiles. The request message is designed to be flexible, enabling providers to perform actions such as adding or removing patients from their roster, or querying their current panel.
| Artifact Name | Description | Source |
|---|---|---|
| PAS Request Bundle | A PAS Request Bundle is a FHIR message containing resources like MessageHeader, Group, Practitioner, Organization, and one or more Patient resources to manage patient panel membership actions such as adding, removing, or querying patients. | Internal |
| PAS Request MessageHeader | Identifies the PAS request and its primary resource. | Internal |
| PAS Request Group | Represents the relationship between the provider (Group.managingEntity) and the patient (Group.member.entity) under a specific facility. | Internal |
| PAS Practitioner | Represents the provider responsible for the patient's panel management. | Internal |
| PAS Organization | Identifies the facility associated with the provider’s panel. | Internal |
| PAS Patient | Represents the individual whose membership is being added, removed, or queried within the panel. | Internal |
Response
A PAS (Response) follows a similar bundle structure, confirming the success or failure of the actions requested. The PAS Response Bundle includes essential resources, such as the MessageHeader, Group, Practitioner, Organization, and OperationOutcome, which reflect the outcome of the operation.:
| Artifact Name | Description | Source |
|---|---|---|
| PAS Response Bundle | A PAS Response Bundle is a FHIR message containing resources like MessageHeader, Group, OperationOutcome, and other related resources to confirm the outcome of the requested actions. | Internal |
| PAS Response MessageHeader | Identifies the PAS response and its related request, indicating the status of the operation (e.g., success or failure) and the type of response (e.g., add, remove, or query patient panel status). | Internal |
| PAS Response Group | Confirms the updated relationship between the provider (Group.managingEntity) and the patient (Group.member.entity) within a provider's panel, based on the requested action. | Internal |
| PAS Practitioner | Represents the provider responsible for the patient's panel management. | Internal |
| PAS PractitionerRole | Represents the role of the practitioner within the facility, linking the practitioner to their responsibilities within the organization and patient panel. | Internal |
| PAS Organization | Identifies the facility associated with the provider’s panel. | Internal |
| PAS Patient | Represents the individual whose membership is being added, removed, or queried within the panel. | Internal |
| OperationOutcome | Provides detailed information about the success or failure of the requested operation, including any errors or warnings encountered during processing. | Internal |
Immunization (Panorama)
Immunization profiles are created and maintained external to the LRA project and is provided here as an aid for implementers of the LRA in finding the base profile definitions. The reader should always verify the profile on the BCY Immunization Distribution Service implementation guide.
The scope of this integration is to store all immunizations and related resources retrieved from the Immunization Distribution Service (IDS) into the LRA Platform's Smile CDR. The IDS publishes immunization records from Panorama to a First-In-First-Out (FIFO) queue, which the LRA Platform consumes. Once stored in Smile CDR, it provides technical capabilities to read and query these resources based on various search parameters. Although LRA has the technical capability to retrieve FHIR resources, aligning this with business query requirements and addressing how clients will query immunization-related data will be tackled in the next release.