Botswana FHIR Implementation Guide
1.0.0 - ci-build
Botswana FHIR Implementation Guide, published by Jembi Health Systems. This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/jembi/botswana-hie-fhir-ig/ and changes regularly. See the Directory of published versions
Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
The following artifacts define the specific capabilities that different types of systems are expected to have in order to comply with this implementation guide. Systems conforming to this implementation guide are expected to declare conformance to one or more of the following capability statements.
Botswana HIE Capability Statement |
This section describes the expected capabilities of the Botswana HIE server actor which is responsible for providing responses to the queries submitted for lab orders. The list of FHIR profiles and operations supported by the Botswana HIE server are defined. |
These define constraints on FHIR resources for systems conforming to this implementation guide.
Bundle - Lab Orders |
This bundle contains all of the lab order profiles for managing lab orders. |
Bundle - Process Patient in FHIR |
While this bundle contains all of the lab order profiles for managing lab orders as defined in the bundle for "Lab Orders", it also includes the "RestrictedPatient" profile that will replace the "Botswana Patient" in the FHIR server. |
DiagnosticReport - Lab Order |
Represents the results for the lab order. |
Encounter - Initiated By The Facility Providing the Service |
Represents the current facility at which the patient is receiving health services. |
Observation - Lab Result |
Represents the patient's test result for a given lab order. |
Patient - Botswana Patient |
Is used to document demographics and other personal information about an individual receiving care or other health-related services. |
Patient - Patient Identity Cross Reference |
Is used by the Client Registry to re-identify the patient with his/her corresponding longitudinal clinical record. |
Practitioner |
Represents the practitioner who participated in the health related service. |
Requirements |
Represents the requirements for the use case described in this Implementation Guide. |
Service Provider |
Organization providing health related services. |
ServiceRequest - Lab Orders |
Represents the service request for lab orders. |
Specimen |
The specimen associated with the lab order. |
Task - Lab Orders |
Assists with tracking the state of the lab order and its completion status. |
These define constraints on FHIR data types for systems conforming to this implementation guide.
Actor Classification |
An extension to capture whether the actor is primary or secondary in the context of the requirements defintion. |
Actor Reference |
An extension to reference the Actor Resource describing additional details regarding the actor. |
Requirements Type |
An extension to capture the type of requirements contained in the Resource. |
These define sets of codes used by systems conforming to this implementation guide.
Actor Classification Codes |
A coded value that represents whether the actor is primary or secondary in the context of the requirements definition. |
Lab Order Codes |
Codes used during lab orders. |
Master Facility List (MFL) Codes |
Codes found in the MFL. |
Requirements Type Codes |
A coded value that represents the type of requirements contained in the Resource. |
These define new code systems used by systems conforming to this implementation guide.
Actor Classification Codes |
A coded value that represents whether the actor is primary or secondary in the context of the requirements definition. |
Connection Type Codes |
A coded value that represents the technical details of the usage of an endpoint. |
Master Facility List (MFL) Codes |
Codes found in the MFL. |
OpenMRS Lab Codes |
Codes used during OpenMRS lab orders. |
PIMS Lab Codes |
Codes used during PIMS lab orders. |
Requirements Type Codes |
A coded value that represents the type of requirements contained in the Resource. |
Scenario Operation Type Codes |
A coded value that represents the HTTP method when sending a request to a specified endpoint. |
These define groups of interrelated examples that demonstrate one or more of the workflows supported by this implementation guide.
Cancel Lab Order (Using a Bundle) |
Demonstrates the process flow to submit a cancellation request for an active lab order from the Point-of-Service application to the FHIR server. |
Lab Order Results (Using a Bundle) |
Demonstrates the process flow to submit lab results from the Point-of-Service application to the FHIR server. |
Register New Patient |
Demonstrates the process flow between the Client Registry and FHIR server during patient registration. |
Register New Patient (Using a Bundle) |
Demonstrates the process flow between the Client Registry and FHIR server during patient registration. |
Reject Lab Order (Using a Bundle) |
Demonstrates the process flow to submit a rejection request for an active lab order from the Point-of-Service application to the FHIR server. |
Retrieve Patient Record |
Demonstrates the process flow to retrieve a patient record from the Client Registry and FHIR server. |
Submit New Lab Orders (Using a Bundle) |
Demonstrates the process flow to submit a new lab order from the Point-of-Service application to the FHIR server. |
These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.
ActorDefinition - Birth and Death Registration System |
Represents the system used for recording births and deaths, ensuring that citizens are formally recognized and provided with legal identification. |
ActorDefinition - Client Registry |
Represents the system designed to uniquely identify individuals who receive healthcare services, often by maintaining a central record of patients and their demographics, assigning unique identifiers, and enabling healthcare workers to identify facilities where a patient has received care. |
ActorDefinition - Clinician |
Represents the individual responsible for the care of patient. |
ActorDefinition - Cross-Service API |
Represents the system used to provide a single entrypoint for demographic search queries that might have a mix of various query parameters. |
ActorDefinition - IPMS |
Represents a centralized electronic medical record (EMR) system implemented by the Ministry of Health and Wellness. It aims to enhance patient care by providing a unified platform for managing medical records across public health facilitie. |
ActorDefinition - Immigration and Citizenship System |
Represents the system used to manage the entry, stay, and exit of foreign nationals and to govern the acquisition and loss of citizenship in the country. |
ActorDefinition - Interoperability Layer |
Represents the architectural component responsible for coordinating transactions from one system to another during Health Information Exchange. |
ActorDefinition - Laboratory Technician |
Represents the individual responsible for conducting lab tests. |
ActorDefinition - Master Facility List |
Represents a comprehensive, standardized registry of all health facilities—both public and private—across the country. Managed by the Ministry of Health and Wellness, the MFL assigns unique codes to each facility, ensuring accurate identification and facilitating interoperability across health information systems. This system supports efficient health data management, reporting, and planning. |
ActorDefinition - Omang |
Represents the system used for national identification of the population in Botswana. |
ActorDefinition - OpenMRS |
Represents an open-source electronic medical record system that is used to manage patient data, support HIV care, and strengthen health information systems across the country’s healthcare facilities. |
ActorDefinition - PIMS |
Represents the system used to collect, manage, and track patient health records across healthcare facilities, supporting improved care, reporting, and decision-making. |
ActorDefinition - Shared Health Record |
Represents the system that stores a defined set of normalized patient data, serving as a longitudinal health record across different facilities, ensuring continuity of care. |
Birth and Death Registration System Requirements |
Birth and Death Registration System Functional Requirements |
Botswana Patient |
Is used to document demographics and other personal information about an individual receiving care or other health-related services. |
Bundle - Cancelled Lab Order |
Lab order has been cancelled |
Bundle - Create New Lab Order |
Submit new lab orders |
Bundle - Create New Lab Order (Incl. Conditional Patient Create) |
Submit new lab orders.
|
Bundle - Create New Lab Order (Incl. Conditional Patient Update) |
Submit new lab orders.
|
Bundle - Create New Lab Order (Uses System Generated IDs) |
Submit new lab orders.
|
Bundle - Create New Lab Order (incl. Patient Resource) |
Submit new lab orders (incl. Patient Resource) |
Bundle - Create New Lab Order (incl. Restricted Patient Create) |
Submit new lab orders and replace the patient profile resource that supplied the data with the "RestrictedPatient" profile resource. |
Bundle - Document Lab Result |
Lab order has been completed |
Bundle - Rejected Lab Order |
Lab order has been rejected |
Client Registry Requirements |
Client Registry Functional Requirements |
Clinician Requirements |
Clinician Functional Requirements |
Cross-Service API Requirements |
Cross-Service API Functional Requirements |
DiagnosticReport - Lab Result |
Represents the results for the lab order. |
Encounter - Initiated By The Facility Providing the Service |
Represents the current facility at which the patient is receiving health services. |
Excludes all personal patient data - After new patient submitted for creation. |
The patient resource that should be stored in the FHIR database when using a Client Registry. |
HIE System Requirements |
HIE System Functional Requirements |
Immigration and Citizenship System Requirements |
Immigration and Citizenship System Functional Requirements |
Includes all personal patient data - After being supplied by the Client Registry. |
The patient resource after having its data populated by the Client Registry. |
Integrated Patient Management System Requirements |
Integrated Patient Management System Functional Requirements |
Interoperability Layer Requirements |
Interoperability Layer Functional Requirements |
Laboratory Technician Requirements |
Laboratory Technician Functional Requirements |
Master Patient Index identifier issued by the Client Registry. |
Interoperability layer receives an MPI as part of the response from the CR when creating new patients. |
Non Functional Requirements |
Non Functional Requirements |
Observation - Diagnostic Test Result |
Documents the patient's diagnostic test result. |
Omang Requirements |
Omang Functional Requirements |
OpenMRS Requirements |
OpenMRS Functional Requirements |
Organization - Current Facility |
Current organization providing health related services. |
Patient Information Management System Requirements |
Patient Information Management System Functional Requirements |
Practitioner |
Represents the practitioners who participated in the health-related event. |
Process FHIR Bundle |
Point-of-Service systems can submit "PUT" or "POST" requests using a FHIR Bundle Resource. |
Response issued by FHIR after CRUD requests. |
Interoperability layer receives an outcome response for each CRUD request. |
Search Patient in Client Registry - Response. |
Interoperability layer receives a response from the CR for the search request. |
Search Patient in Client Registry. |
Interoperability layer searches for a patient in the client registry using business identifiers (Omang, BDRS, Immigration) or Demographics. |
Search Patient in FHIR. |
Point-of-Service systems can search for a patient in FHIR using one or more business identifiers (Omang, BDRS, Immigration) or Demographics. |
ServiceRequest - Lab Order (Active) |
Represents an active service request for the lab order. |
ServiceRequest - Lab Order (Completed) |
Represents a completed service request for the lab order. |
ServiceRequest - Lab Order (Revoked - Order Cancelled) |
Represents a service request that has been revoked before it could be fully attended to. |
ServiceRequest - Lab Order (Revoked - Unsatisfactory Specimen) |
Represents a service request that has been revoked before it could be fully attended to. |
Specimen - Unsatisfactory |
The specimen associated with the lab order that was considered ready for testing but the service request was revoked due to an unsatisfactory specimen. |
Specimen - Used During Testing (Completed Order) |
The specimen associated with the lab order that was used during testing. |
Specimen - Used During Testing (Order Cancelled) |
The specimen associated with the lab order that was used during testing. |
Specimen - Used During Testing (Order is Active) |
The specimen associated with the lab order that will be used during testing. |
Task - Lab Order Cancelled by Requester |
Indicates that the task that has been initiated for the lab request has been cancelled by the requestiong organization/practitioner. |
Task - Lab Order Completed |
Indicates that the task that has been initiated for the lab request has now been completed and the lab result issued. |
Task - Lab Order Rejected by Laboratory |
Indicates that the task that has been initiated for the lab request has been rejected by the receiving laboratory/lab technician. |
Task - New Lab Order Requested |
Represents a task that has been initiated to facilitate the overall progress of the new lab request. |
Validate Patient Resource in FHIR. |
FHIR uses its $validate operation to ensure that data provided in the Patient Resource is compliant with the specified FHIR Profile. |