Botswana FHIR Implementation Guide
1.0.0 - ci-build
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
Functional requirements describe the capabilities the system must have in order to meet the end-users’ needs and achieve tasks within the business process.
Actor 1: Birth and Death Registration System (BDRS)
Actor 1: Interoperability Layer (IL)
Actor 2: Client Registry (CR)
Actor 3: Cross-Service API (API)
Actor 4: Omang
| Key | Requirement |
|---|---|
| BOTS.FR-BDRS.001 | Should be able to provide a status check that indicates uptime and connection status. |
| BOTS.FR-BDRS.002 | Should be able to authenticate with and connect to the appropriate Oracle View with BDRS registry data. |
| BOTS.FR-BDRS.003 | Should be able to translate the BDRS registry data model into valid FHIR resources. |
| BOTS.FR-BDRS.004 | Should be able to provide a FHIR Search API layer for handling queries for Omang patients by all identifiers and demographic parameters available in the BDRS Oracle View. |
| BOTS.FR-BDRS.005 | Should be able to integrate with an HIE interoperability layer for incoming and outgoing communication. |
| BOTS.FR-BDRS.006 | Should be able to connect with a FHIR-based Client Registry through the HIE. |
| BOTS.FR-BDRS.007 | Should be able to synchronize patient data on demand between the BDRS registry and a FHIR-based HIE Client Registry, with a configurable refresh timespan. |
Actor 1: Client Registry (CR)
Actor 1: Shared Health Record (SHR)
| Key | Requirement |
|---|---|
| BOTS.FR-CR.001 | Should be able to support configurable entity matching, a service to assist in identifying duplicate patients. |
| BOTS.FR-CR.002 | Should be able to support patient linking and de-duplication. |
| BOTS.FR-CR.003 | Should be able to support the ability to track and monitor inbound/outbound transactions. |
| BOTS.FR-CR.004 | Should be able to support synchronization of client IDs with a Shared Health Record (SHR). |
| BOTS.FR-CR.005 | Should be able to manage a full audit log of changes to data as well as configurations as well as users. |
| BOTS.FR-CR.006 | Should have functions including user management and access controls. |
| BOTS.FR-CR.007 | Should be able to persist the parent/child relationship, birth order, and multi-birth indicator. |
| BOTS.FR-CR.008 | Should support a UI to review and manually adjudicate uncertain (“potential”) matches, and override incorrect matches. |
| BOTS.FR-CR.009 | Should support configurable attributes that form a patient record and are used for matching. |
| BOTS.FR-CR.010 | Should support configurable attributes to make it easy to add attributes to the schema. |
| BOTS.FR-CR.011 | Should support configurable attributes to make it easy to remove attributes from the default model (or start over from scratch). |
Actor 1: Clinician
Actor 1: Shared Health Record (SHR)
Actor 2: Patient Information Management System (PIMS)
| Key | Requirement |
|---|---|
| BOTS.FR-C.001 | I want to be able to log in to system and access the laboratory module. |
| BOTS.FR-C.002 | I want to be able to open the lab order form in the lab module. |
| BOTS.FR-C.003 | I want to be able to capture patient details at the facility using the system. |
| BOTS.FR-C.004 | I want to be able to capture lab order details at the facility using the system. |
| BOTS.FR-C.005 | I want to be able to submit lab order details to the SHR. |
| BOTS.FR-C.006 | I want to be able to access the lab test results from PIMS. |
| BOTS.FR-C.007 | I want to be able to receive pop up notification from PIMS indicating that new - results have been received. |
Actor 1: Cross-Service API (API)
Actor 1: Birth and Death Registration System (BDRS)
Actor 2: Immigration and Citizenship System (ICS)
Actor 3: Omang
| Key | Requirement |
|---|---|
| BOTS.FR-CSAPI.001 | Should be able to handle a valid FHIR search query that includes parameters across the Omang, BDRS, and Immigration services. |
| BOTS.FR-CSAPI.002 | Should be able to return a search bundle with results representing a union of results from the three services. |
| BOTS.FR-CSAPI.003 | Needs to provide a separate endpoint that returns a single patient resource based on the first match, using a hierarchical matching algorithm. |
Actor 1: Shared Health Record (SHR)
Actor 2: Patient Information Management System (PIMS)
Actor 3: Integrated Patient Management System (IPMS)
Actor 4: Interoperability Layer (IL)
| Key | Requirement |
|---|---|
| BOTS.FR-HIE.001 | Should be able to send SMS notifications to patients that require urgent attention-(PIMS). |
| BOTS.FR-HIE.002 | Should be able to allow capturing of certain specific specimen-(PIMS). |
| BOTS.FR-HIE.003 | Should be able to ping SHR for available lab test results and avail them to the clinicians- (PIMS). |
| BOTS.FR-HIE.004 | Should be able to send lab test results to the SHR-(IPMS). |
| BOTS.FR-HIE.005 | Shall include an interface into which a workflow engine can be connected. |
| BOTS.FR-HIE.006 | Should support the ability to be extended by allowing additional mediation functions to be added or removed as they are needed. |
| BOTS.FR-HIE.007 | Shall support a mechanism for error management and tracking, e.g. a console for viewing failed transactions. |
| BOTS.FR-HIE.008 | Shall allow for failed transactions to be grouped by error type and reason so that errors can be rectified efficiently by finding the root cause of the error, fixing the problem, and re-running those transactions. |
| BOTS.FR-HIE.009 | Should support the ability for a user to re-run errored transactions through the HIE once the reason for their failure has been rectified. |
| BOTS.FR-HIE.010 | Shall provide authorized users with a view of metrics for monitoring the flow of messages through the HIE. |
| BOTS.FR-HIE.011 | Shall manage the security of the HIE through authentication (identity verification), authorization (permission to interact with specified HIE components) and encryption and decryption of messages. |
| BOTS.FR-HIE.012 | Shall support Authentication and Authorization of systems trying to send data to the HIE. |
| BOTS.FR-HIE.013 | Should support the encryption of data in flight (when not on a physically secure network) and at rest (whenever data is stored, e.g. when transactions are stored for logging). |
| BOTS.FR-HIE.014 | Should capture monitoring statistics, such as transaction loads and performance metrics, and provide a view of these for monitoring the flow of messages through the HIE. |
Actor 1: Integrated Patient Management System (IPMS)
Actor 1: Omang
Actor 2: Master Facility List (MFL)
| Key | Requirement |
|---|---|
| BOTS.FR-IPMS.001 | Must receive a new lab order from the HIE as an ORM Hl7v2 message over MLLP. |
| BOTS.FR-IPMS.002 | Must send an ACK message to the HIE with the IPMS-specific lab order number for the lab order generated on the IPMS side by the ORM message AND the IPMS-specific MRN for the existing patient. |
| BOTS.FR-IPMS.003 | On registration of a new patient on IPMS, IPMS must send an HL7 v2.3 - Admit, Discharge and Transfer 04 message that includes IPMS-specific MRN and the patient’s Omang and/or passport number to the specified IP and Port number. |
| BOTS.FR-IPMS.004 | Should be able to send a HL7V2 ORU message to the HIE with lab order result information as soon as this information is available in IPMS. The message must include IPMS-specific identifiers for the patient and the lab order that correspond to the identifiers sent with the ACK for the ORM messages and with the ADT messages. |
| BOTS.FR-IPMS.005 | Must ensure that IPMS-specific facility identifiers are sent with the ADT and ORU messages, and that these identifiers can be mapped to the BW MFL. |
Actor 1: Interoperability Layer (IL)
Actor 1: Shared Health Record (SHR)
Actor 2: Patient Information Management System (PIMS)
Actor 3: Integrated Patient Management System (IPMS)
| Key | Requirement |
|---|---|
| BOTS.FR-IL.001 | Should be able to cache and store data from various interfacing systems in the shared health record (SHR). |
| BOTS.FR-IL.002 | Should be able to synchronise and update data set in the interoperability layer with other systems such as the MPI. |
| BOTS.FR-IL.003 | Should be able to ping IPMS for available lab test results and pull them to the SHR. |
| BOTS.FR-IL.004 | Should be able to update SHR with results from IPMS and push the updated record to PIMS. |
Actor 1: Laboratory Technician
Actor 1: Integrated Patient Management System (IPMS)
| Key | Requirement |
|---|---|
| BOTS.FR-LT.001 | I want to be able to log in to access the lab module in IPMS. |
| BOTS.FR-LT.002 | I want to be able to enter lab order details in to IPMS from facilities that do not have IPMS. |
| BOTS.FR-LT.003 | I want to be able to obtain lab order ID generated by IPMS. |
| BOTS.FR-LT.004 | I want to be able to enter results in to IPMS after processing the received specimen. |
| BOTS.FR-LT.005 | I want to be able to submit the lab test results to the SHR through IPMS. |
Actor 1: Omang
Actor 1: Interoperability Layer (IL)
Actor 2: Client Registry (CR)
Actor 3: Cross-Service API (API)
| Key | Requirement |
|---|---|
| BOTS.FR-OMANG.001 | Should be able to provide a status check that indicates uptime and connection status. |
| BOTS.FR-OMANG.002 | Should be able to authenticate with and connect to the appropriate Oracle View with Omang registry data. |
| BOTS.FR-OMANG.003 | Should be able to translate the Omang registry data model into valid FHIR resources. |
| BOTS.FR-OMANG.004 | Should be able to provide a FHIR Search API layer for handling queries for Omang patients by all identifiers and demographic parameters available in the Omang Oracle View. |
| BOTS.FR-OMANG.005 | Should be able to integrate with an HIE interoperability layer for incoming and outgoing communication. |
| BOTS.FR-OMANG.006 | Should be able to connect with a FHIR-based Client Registry through the HIE. |
| BOTS.FR-OMANG.007 | Should be able to synchronize patient data on demand between the Omang registry and a FHIR-based HIE Client Registry, with a configurable refresh timespan. |
Actor 1: OpenMRS
Actor 1: Client Registry (CR)
Actor 2: Shared Health Record (SHR)
| Key | Requirement |
|---|---|
| BOTS.FR-OMRS.001 | Must be able to create new patients and save patient details in the CR/MPI. |
| BOTS.FR-OMRS.002 | Must be able to create lab orders after validating patient details against CR. |
| BOTS.FR-OMRS.003 | Should be able to send lab orders to the SHR through the PIMS service layer. |
| BOTS.FR-OMRS.004 | Should be able to update lab records in the SHR with specimen details. |
| BOTS.FR-OMRS.005 | Should be able to query the shared health record for available lab order results. |
| BOTS.FR-OMRS.006 | Should be able to store lab results. |
Actor 1: Patient Information Management System (PIMS)
Actor 1: Client Registry (CR)
Actor 2: Shared Health Record (SHR)
| Key | Requirement |
|---|---|
| BOTS.FR-PIMS.001 | Must be able to create new patients and save patient details in the CR/MPI. |
| BOTS.FR-PIMS.002 | Must be able to create lab orders after validating patient details against CR. |
| BOTS.FR-PIMS.003 | Should be able to send lab orders to the SHR through the PIMS service layer. |
| BOTS.FR-PIMS.004 | Should be able to update lab records in the SHR with specimen details. |
| BOTS.FR-PIMS.005 | Should be able to query the shared health record for available lab order results. |
| BOTS.FR-PIMS.006 | Should be able to store lab results. |