Notice C

Promoting the collaborative development of proposals for investments in digital health global goods

Blood Safety Information System (BSIS) data exchange and device interfacing project

Notice C Opportunity: 
Announcement C0: Global Good Software Development and Support
Application Status: 
Approved - partially funded

Executive Summary

Safe blood has been listed as an essential medicine by the World Health Organisation (WHO) and is used for treatment of things like; postpartum haemorrhage, trauma, childhood malaria and severe anaemia and malnutrition. Adequate access to safe blood can have a significant impact on developing countries ability to provide lifesaving care to vulnerable populations. For instance, the WHO and other international organisations estimate 25% of maternal deaths on the African continent could be prevented should health facilities have access to safe blood. This equates to an estimated 60,000 women's lives saved every year.

The Blood Safety Information System (BSIS) is designed as an Open Source digital health software tool to support low resource Blood Services to manage data about blood donors and blood donations from the point of donation to the point of transfusion. This includes the core blood services functions of transfusion transmissible infections (TTI) testing, serology testing and component processing, pack labelling and blood bank inventory management. It provides a low-cost option for information management and barcoded pack label printing for resource constrained blood services who cannot afford high cost proprietary systems built in and for the developed world, while maintaining the global standards for information management required to ensure that only safe blood can be labelled and issued.

BSIS has been successfully implemented and is in operational use in blood service centres in three countries Sub-Saharan Africa (Lesotho, Ghana and Ethiopia) with new implementations happening in Zambia and Cameroon this year. To date over 134,000 safe units have been processed, labelled and issued through BSIS. The Ghanaian, Ethiopian and Zambian blood services have plans to rollout BSIS to all their blood service centres in these countries (a total of 60+ additional sites) over the next few years. Jembi has also had interest in BSIS from blood services globally, including; Nigeria, Tanzania, Burkina Faso, South Sudan, Cambodia, Suriname and Mexico.

The proposed project will focus on both the development of significant new functionality for the Blood Safety Information System (BSIS) as well as the maintenance of the core product, including the existing codebase, over a 12-month period. The new functionality centres on 3 key areas: laboratory device interfacing, data synchronisation capability and multi-site interoperability. The requirements for the additional functionality proposed for BSIS have been identified and prioritised through a robust community-led process that includes the implementing Blood Services, their blood safety technical assistance organisations and the Africa Society for Blood Transfusion (AfSBT) accreditation requirements. In addition to meeting Blood Services' established requirements the additional laboratory device interfacing functionality should open up new possibilities for the BSIS business models by presenting an opportunity to generate revenue for sustainability through potential partnerships with laboratory device manufacturers, thereby facilitating the ongoing maintenance of the BSIS product.

Consortium Team

The BSIS product and technical team is housed at Jembi Health Systems in Cape Town, South Africa. This team works as part of a community of practice that includes Blood Service personnel from across Africa, their blood safety technical assistance organisations (AABB, Safe Blood for Africa and the WHO) and the Africa Society of Blood Transfusion (AfSBT). The team develop requirements for additional functionality in BSIS and manage the BSIS product roadmap according to community priorities to ensure that the new functionality will provide the most benefit to Blood Services where BSIS has been, and will in future, be implemented. Jembi is exploring possibilities to expand the technical development team to include contributors from in-country organisations in countries where BSIS has been, and will be, implemented. Jembi is also actively pursuing partnerships with lab equipment manufacturers. This forms part of our wider BSIS sustainability strategy.

Going forward we would like to expand this community of practice to include the OpenHIE community, AeHIN and additional members of the AfSBT. We will do this by making use of the existing community platforms (in which Jembi is currently active) to demonstrate the application and elicit feedback on the solution design, interoperability specifications and use cases, as well as the implementation design.

Jembi Health Systems NPC Capability and Experience Statement

Jembi is an African non-profit organisation registered in South Africa with country offices in Mozambique, Rwanda and Zambia. Since 2009, Jembi has established a reputation as one of the leading specialist health information systems organisations in Africa, delivering needs-driven solutions. Jembi has country programs in South Africa, Mozambique, Rwanda and Zambia, and a rapidly growing continental footprint through projects in other African countries. Our core competencies include: needs assessment and requirements gathering, analysis, system and solution architecture design, software development, implementation and capacity building, and monitoring and evaluation.

We act as ethical mediators, develop software, analyse and re-engineer health systems and undertake research on the application of health information systems (HISs) in developing countries. We are committed to independence and impartiality, and the utilisation of good practices in the digital health domain.

We have extensive experience in collaborative projects and implementation with inter-sectoral and multi-disciplinary groups of stakeholders from national governments, local and international organizations and consortia, academic and research institutions, non-profits and private companies. Our partners include: the Rwandan Ministry of Health, Rwanda Biomedical Center and the University of Rwanda, School of Public Health; the Mozambican Ministries of Health, Justice and Woman and Social Affairs; the South African National and Provincial Departments of Health; Broadreach; Health Enabled; K4Health; University of Eduardo Mondlane; University of Zimbabwe (HITRAC); the University of KwaZulu Natal Health Enterprise Architecture Lab; InSTEDD; HISP-South Africa; Partners in Health; Management Sciences of Health (MSH); University of California, San Francisco; Duke University; Greenfield Management Solutions; PLAN International, Tech4Life and the Regenstrief Institute.

Jembi's South African office manages several regional and international programmes including the Blood Safety Strengthening Programme (BSSP), the Open Health Information Exchange (OpenHIE) community and an Open Civil Registration and Vital Statistics (OpenCRVS) Initiative.

Key team members for this proposed project include:

  • Linda Taylor - Linda has been the BSIS Product Manager for the last 4 years and is responsible for gathering, analysing and documenting requirements as well as management of the software development roadmap. She acts a liaison between the community, programme staff and the technical development team and plays the role of scrum Product Owner during the agile development phase.
  • Rhonwyn Cornell - Rhonwyn is the BSIS Programme and Implementation Manager and has been responsible for the implementations in Lesotho, Ghana, Ethiopia and now Zambia and Cameroon. She is responsible for stakeholder management, capacity building and grant management.
  • Daniel Futerman - Daniel has been the technical lead on the BSIS project for 4 years and has been responsible for the overall design of both the front and back end of BSIS. While he has expanded his responsibilities into other programmes he remains the backup/standby product lead. Please see Appendix D for summary CVs for these team members.

Project Description

Why is BSIS needed?

Safe blood is critical to treatment of postpartum haemorrhage, a condition estimated to be the cause of 23% of maternal deaths in Africa annually. Safe blood is also used for the treatment of childhood malaria, severe malnutrition, emergency medicine and surgery. Most countries in Africa collect only half of the blood needed to meet their transfusion requirements. BSIS facilitates the production of safe blood by managing information within blood services from the point of donation to the point of transfusion. In this way BSIS facilitates improved blood collection processes as well as ensuring that only safe blood is labelled and released to health facilities. The BSIS implementation models ensures that the system is safely and sustainably implemented at low resource blood services. This approach focuses on capacity building that promotes local ownership of the information system as well as building skills and knowledge required for system use, management and maintenance.

In a landscape where expensive proprietary products are predominant BSIS is a license free open source software system that offers low resource blood services a low cost alternative for electronically managing their data regarding donors and donations. BSIS incorporates the requirements for Africa Society for Blood Transfusion (AfSBT) Accreditation standards, enabling the accreditation process for blood services using BSIS. BSIS is also designed specifically for low resource settings. While the initial recommended BSSP implementation model for introducing BSIS into blood services, with its intensive capacity building and validation phase, is resource intensive the open source nature of the system, which has no associated ongoing license fee, makes BSIS a frugal long term innovation for blood services in low resource settings. The focus of the of the implementation on capacity building in all aspects of the system’s use, management and maintenance also ensures that blood services are not locked into long term expensive support contracts. BSIS functionality and user interface is designed to be simple, intuitive and easy to use and focuses on the core processes of a safe blood service. In addition, the infrastructure and hardware requirements take into account cost and environmental factors, including low or on internet connectivity and generic hardware specifications. The data produced by BSIS supports the blood services’ operational planning and management reporting needs, including reporting requirements of the WHO Global Database on Blood Safety database and CDC. Very importantly BSIS provides blood services with the ability to produce printed, standardised, easily readable and accurate labels for safe blood units and discard labels for units flagged by BSIS as unsafe.

Where is BSIS already in use?

 

BSIS has been in operational use for a minimum of one year in three sites; the Lesotho Blood Transfusion Service Centre in Maseru, the National Blood Service Ghana’s Southern Area Blood Centre in Accra and the National Blood Bank of Ethiopia’s Addis Ababa Centre. Since BSIS was first implemented a total of 134,070 units have been issued to health facilities from these three sites. Of these blood services estimate that since BSIS went live in their services, 27% of units (36,198 units) they have issued went to maternal and child care services, benefitting women and children.

 In operational use BSIS has proved to be very stable with minimal requests for technical support from Jembi. The capacity building activities undertaken as part of the BSSP implementations have resulted in a strong sense of local ownership and the long-term operational use of the BSIS at these facilities. Local staff are confident to provide system user training as well as troubleshoot problems and can adapt local processes as needed. The feedback from these staff who were trained on system management and maintenance is that they feel confident to roll-out the system to other blood centres, with limited support from Jembi.  To find out more about these implementations, please see the Implementation profiles in Appendices A-C, as well  as the WHO Digital Health Atlas entries  for Lesotho,Ethiopia and Ghana.

What does BSIS do?

The Blood Safety Information System (BSIS) is designed as an open source digital health software tool to support low resource Blood Services to manage data about blood donors and blood donations from point of donation, through transfusion transmissible infections (TTI) and serology testing and component processing to labelling and inventory management.  BSIS is licensed under the OSI-compliant BSD licence. When changes to the critical blood testing and blood labelling algorithm are being made, for safety reasons the repository is temporarily closed until the quality assurance testing is complete and the version has been signed off for release. The latest version (v1.4) is due for release at the end of September 2018. 

 

Figure: component overview of BSIS functionality


 

How mature is the BSIS product?

Based on the Global Goods Maturity Model promoted by Digital Square BSIS is a medium matured global good. It is already in use in a number of African countries, with more implementations underway or planned. BSIS software development, quality assurance and implementation documentation are extensive and freely available under a creative commons license, on request. The software is scalable and is in use nationally via a secure WAN in Lesotho. The below diagrams illustrated the key maturity indexes for BSIS pre and post Digital Square Investment. Please see the detailed breakdown in the appendices attached.


 

Pre Digital Square Investment

Post Digital Square Investment


 

Proposed Project

The proposed project is to maintain the existing BSIS product as well as develop three additional sets of functionality for BSIS that will benefit all current and future implementing Blood Services. The proposed functionalities are (i) data synchronisation capability for system use at mobile sites and (ii) multi-fixed site interoperability (iii) the ability to electronically interface with laboratory analysis equipment. In addition to the above feature development, the BSIS team will create a model for the integration of BSIS into national level health information systems architectures. This work will focus on modelling and defining the data exchange patterns for BSIS to be interoperable with an OpenHIE compliant HIS and which components BSIS would be able to leverage to better support national health objectives.

These features have been identified as high priority needs by the Blood Services themselves and have been on the technical roadmap for the software from its early stages, although not as part of the initial critical functionality requested. The roadmap for BSIS has been developed and maintained using requirements gathered from African Blood Services, their blood safety technical assistance providers (AABB, Safe Blood for Africa and the WHO), AfSBT and independent international blood safety and system validation experts. We have already developed the business requirements and the initial technical specifications for these features based on our analysis of country needs and we already have a technical backlog of work that is dev-ready.

Data Synchronisation for mobile clinics

 A priority requirement for blood services is to have the ability to synchronise donor and donation data between the central database and laptops that can be used at mobile clinics where the majority of blood donations take place. These mobile clinics are often held in areas with no internet connectivity so real time access to the central database is not possible.  Currently, data is collected on paper forms and must be back-entered at the central service when the mobile team sends the blood packs, samples and forms back to the central service, often at the end of the work day.

Access to the donor database at point of blood collection is important in that it:

  • Enables correct identification of the repeat donor and verification of the donor’s eligibility to donate
  • Reduces the cost of collecting blood from ineligible donors that must then be discarded
  • Facilitates counsellors to provide on-site TTI and blood grouping results to repeat donors at remote donation clinic
  • Data capture can be done on site and does not require additional data capture staff for back entry of data, reducing costs and providing data to lab staff more quickly.

Multi-site Support

For the blood services where BSIS is in operational use and rollout to further sites within the country is already planned, a key priority is to be able to exchange data between the different instances of BSIS. BSIS has already been implemented in the Southern Area Blood Center (SABC) in Ghana with an implementation planned by the National Blood Service Ghana (NBSG) for a second site later this year in Tamale in the northern part of the country; the multi-site functionality with enable the blood service to track donors who are mobile between these regions. The Zambian National Blood Transfusion Service (ZNBTS) has included the rollout of BSIS to all 9 ZNBTS sites in its strategic plan for 2020. In Ethiopia the National Blood Bank Service (NBBS) has up to 50 sites that it plans to include in its national rollout of BSIS. Each of these countries has a considerable mobile population, so ensuring that donors can be tracked across sites is critical to ensuring blood safety and operational efficiency.

BSIS is currently designed to be used at a single site, but can also be used effectively in a client-server model on a larger scale across sites, with the conditions that it is hosted on a central server, and all sites have reliable network connections to the central server, usually through a secure Wide Area Network.  Network infrastructure and connectivity are issues in many countries, so this centrally-hosted client-server model is not feasible for many services. Individual site instances that can operate independently but can also exchange data when connectivity allows is a more context-appropriate solution. The requirement is for a solution that would allow for separate instances of the system to be setup in a distributed architecture, with data synchronisation across these instances enabling a connected system.

Proposed Solution for Data Synchronisation

We believe there are synergies with these two requirements, whereby both problems could be solved by developing data synchronisation capabilities between regional sites, as well as between mobile clinic laptops and the site database.  Some of the overlapping, key requirements for these features include:

  • The ability to generate globally unique identifiers and donor numbers
  • The ability for an authorised user to synchronise data between regional databases, or between a regional database and a mobile clinic laptop
  • The ability to identify and indicate if a record has been transferred between databases
  • The ability to identify and indicate if a record has been updated or voided on a database before or after data synchronisation
  • The ability for an authorised user to identify, manage and resolve data conflicts
  • The ability to transmit data between databases securely

 To date, a significant amount of work has been done on identifying a solution and preparatory work.  This work includes:

Technology Review

Having reviewed suitable approaches and technologies for data synchronisation, it is evident that other related applications have taken one of two approaches:

  • Develop custom data synchronisation functionality within the application, e.g.:
  •      OpenMRS – API-level data sync module
  •      Bahmni – Atom-feed based data sync
  •     DHIS2 – Custom data and metadata synchronisation functionality
  • Leverage existing database replication technologies
  •      OpenBoxes – Leverage SymmetricDS
  •      OpenMRS – GSoC project to leverage SymmetricDS

In trying to keep things agile and lean, leveraging existing database replication technologies shows benefits over trying to develop this internally within the BSIS application, and this approach been prioritised.

Several open-source and commercial database replication tools were reviewed, including:

  • Postgres-R
  • Slony-I
  • ESCADA Replication Server
  • Pgpool-II
  • DBReplicator
  • SymmetricDS
  • Sybase Replication Server
  • Q-Replication Tools

In this review, we considered criteria including product maturity, features, stability, support, adoption rates, user reviews and success stories. JumpMind’s SymmetricDS was found to be the preferred option and capable of supporting the high-level requirements for data synchronisation in BSIS.

JumpMind’s SymmetricDS is an open-source database replication software licensed under the GPL license. A Pro (paid) version of the product is also available that adds a web interface GUI and a few additional features on top of the application.

Some of the benefits to using SymmetricDS as a data sync tool for BSIS include:

  • External application - there is minimal impact on the BSIS implementation qualification processes, which means it will not place an additional burden on blood services over installation and upgrades.
  • Can be phased in iteratively - it’s possible to focus on key use cases, and then extend those to cover more of the blood safety workflows and data elements.
  • Can be switched out for an improved solution at a later stage if needed.
  • Use of SymmetricDS is optional - for those blood services that do not require data synchronisation functionality, BSIS can be implemented as is.

SymmetricDS high-level features include:

  • Data Synchronisation - Change data capture for relational databases and file synchronisation for file systems can be periodic or near real-time, with an initial load feature to fully populate a node.
  • Central Management - Configure, monitor, and troubleshoot synchronisation from a central location where conflicts and errors can be investigated and resolved.
  • Automatic Recovery - Data delivery is durable and low maintenance, withstanding periods of downtime and automatically recovering from a network outage.
  • Secure and Efficient - Communication uses a data protocol designed for low bandwidth networks and streamed over HTTPS for encrypted transfer.
  • Transformation - Manipulate data at multiple points to filter, subset, translate, merge, and enrich the data.
  • Conflict Management - Enforce consistency of two-way synchronisation by configuring rules for automatic and manual resolution.
  • Extendable - Scripts and Java code can be configured to handle events, transform data, and create customised behaviour.
  • Deployment Options - The software can be installed as a self-contained server that stands alone, deployed to a web application server, or embedded within an application.


Proposed Architecture


 

Proof of Concept

An initial proof of concept was completed to evaluate the capabilities and suitability of SymmetricDS. The outcome of this proved positive, but highlighted some limitations with the free version and the lack of a graphical user interface (GUI):

  • The GUI adds major value - it makes it much quicker and simpler to develop and implement the data synchronisation solution, and provides an excellent interactive interface to monitor, manage and support use of the tool in production.
  • With the free version, the exact same solution can be developed, but it will take a lot more time and effort to do this programmatically.

Our development strategy therefore is:

  • Provide the BSIS technical team with access to the Pro version of SymmetricDS to effectively and efficiently develop the initial sync solution, which can be then exported for use in production.
  • SymmetricDS will run as a separate application to BSIS, using the “Standalone" or “Web Archive” approach that does not integrate or embed SymmetricDS within the BSIS application. Using this approach provides minimal impact on BSIS implementation qualification processes, and should avoid any issues with integrating software with conflicting licenses (BSIS uses BSD, SymmetricDS uses GPL). SymmetricDS will operate at the database level when used with BSIS. Implementing the sync solution has the effect of adding a set of database tables to each BSIS database that makes use of it. These database tables are used in managing and coordinating the synchronisation of data between data sources.
  • The free version of the software will be used in production, but will make use of, or import, the data synchronisation solution developed above. There will still be the limitation whereby there is no interface to monitor, manage and support use of the tool in production. Our goal therefore is the development of a basic application (separate to BSIS) to provide a simple means of monitoring the status of SymmetricDS, to allow administrators to ensure that data sync is operating as expected. This can be extended over time, if needed, to provide additional high priority monitoring and support features (essentially to provide some of the functionality that the Pro version web interface currently provides).
Use of UUIDs

In addition to the proof of concept, the development team have also adapted BSIS to make use of UUIDs in preparation for the use of a synchronisation tool. A universally unique identifier (UUID) is a generated number used to identify information in computer systems and is, for practical purposes, globally unique. This means that records can be created and shared across many instances of BSIS without the problem of duplicate identifiers. This work is complete and is due to form part of the next release in the last quarter of 2018.

Laboratory Device Interfacing

Currently one of the risk areas identified by stakeholders is laboratory staff transcription errors of blood sample test results, either from the automated testing machine printouts or from paper records used in manual testing. Although there is a is double-entry feature in BSIS which minimises this risk, supported by standard operating procedures (SOPs) to ensure only authorised staff can verify these results in BSIS before releasing a batch of blood samples, there is still a small risk that the incorrect test result may be captured. In addition, this double entry process is time consuming and requires two lab staff to be available. Laboratory device interfacing with BSIS will provide the ability to extract TTI test data from the automated testing machines and automatically populate these results in BSIS, thereby eliminating the risk of data transcription errors by the laboratory staff, reducing processing time and freeing up staff resources by reducing manual data entry. The laboratory testing machine/analyser identified as a priority use case is the Abbott Architect machine that is currently widely in use in the African blood services. Our aim however is to design and develop this feature in such a way that other manufacturers’ machines/analysers could be supported with as little customisation as possible. The first priority is to focus on Transfusion Transmissible Infections (TTI) testing as this is the type of testing that is most commonly automated in the blood services, followed by blood group serology testing in a later phase.

Abbott Architect, ASI and ASTM

The most common TTI analyser in use in African blood services is the Abbott Architect, so that will be the first analyser we will focus on. The Abbott Architect instruments support the Abbott Standard Interface (ASI), designed to enable interfacing Architect analysers to hospital or laboratory information systems using the serial RS-232 communications port. The ASI is implemented using the ASTM standards, specifically:

  • ASTM E 1381-91 - “Specification for Low-Level Protocol to Transfer Messages Between Clinical Laboratory Instruments and Computer Systems”
  • ASTM E 1394-91 - “Standard Specification for Transferring Information Between Clinical Instruments and Computer Systems”

Proposed Solution for Device Interfacing

The proposed solution seeks to leverage the OpenHIM as the means to exchange data between the analyser and BSIS but further analysis is needed to validate and describe the following to refine exactly what the solution would look like.  The initial design is as follows:


This would require the development of an ASTM E 1394 mediator to accept, parse and transform messages received from the Architect. With similarities to HL7v2, HAPI / HAPI-FHIR) could potentially be adapted for this.  The format that the ASTM messages are transformed to that BSIS will consume would have to be investigated and agreed. Possible candidates are ASTM to HL7v2 or possibly ASTM to FHIR (See the FHIR DiagnosticReport Resource.)  BSIS would require the addition of HL7v2 / FHIR support so that BSIS can consume output from the ASTM mediator.

A lower priority is to develop an ASTM message generator to simulate and test the solution so that the development and testing phases are not dependant on having access to an Architect machine. We have had prior communications with the Abbott Johannesburg office about the possibility of collaborating with them to beta-test in their own simulation environment, but a message generator would be helpful to reduce the dependency on Abbott for further testing.

The following diagram describes the expected networking requirements to interface the Abbott Architect testing machine to BSIS.



 

Jembi has been in discussion with other groups who are also working on open source solutions for device interfacing to LIMS, and that have been utilising the OpenHIM as part of the solution.  This project would provide an opportunity to harmonise efforts and share knowledge with the parties involved in:

 


System Interoperability

Whilst the initial country implementations of BSIS did not require an interoperable system, the long term vision has always included interoperability with other systems as an important feature. The technical design of BSIS already incorporates a web API (see Technical Architecture diagram below) that can support interoperability use cases and this new feature will build on this work. The device interfacing work would be a prelude to this. The core areas that we aim to focus on are:

 Improvements to security, specifically implementing the use of self-signed certificates over https. 

  • Minor changes to the BSIS REST API to make it public and also easier for developers to interact with
  • Document the potential / most likely interoperability use cases, for example:
  1. ○ Hospital patient system - for managing order and returns of blood units; for exchanging blood transfusion data to support haemovigilance.
  2. ○ Referral use case - sharing referral information about TTI positive donors with referral services to ensure linkage to further testing, treatment and care.  
  3. ○ Device interfacing - with other laboratory devices such as weighing scales, in addition to the automated testing machines documented above. 
  4. ○ DHIS2 aggregate reporting.
  5. ○ Shared Health Record - the ability to store a donor’s blood group
  • Investigate the use of the FHIR Diagnostic Resource as an appropriate standard for data exchange for blood service information.
  • The value of mapping this data exchange to OpenHIE profiles could also be considered.

BSIS Technical Architecture

Product Maintenance

In addition to this new functionality the technical team will maintain the existing core BSIS Product in line with the product roadmap. This includes four main areas:

  • Technical Maintenance, including dependency management, security updates and code maintenance as well as provide core technical support.
  • Product documentation already consists of

○        Software Roadmap

○        Requirements Specifications

○        Developer Guides

○        Implementation Guides

○        User Manuals

○        Release Notes

  • These will require updating to include the new features. 
  • Quality assurance has been a critical aspect of the development of BSIS and our aim is to update and maintain the QA strategy documents, develop additional test cases and improve performance testing, and to introduce integration testing to support interoperability use cases.

Promotion of the BSIS, including the maintenance of the BSIS demo site demo.bsis.jembi.org, provision of demos to interested parties and updating promotional material in line with releases. 

Conclusion

BSIS is a medium mature global good software that is having a substantial impact on improving blood safety in several Sub Saharan African countries. Investment in increasing the functionality of BSIS to include all the proposed new features will increase the ability of BSIS to improve blood safety in low resource setting and expand the ever growing potential user base for the system.

Work Plan and Schedule

The work plan consists of 4 separate work streams/work packages as shown in the diagram below. These are: Overall product and programme management, the Data Synchronisation work and the Device Interfacing and Interoperability work. Please see the work plan in excel spreadsheet format attached in Appendix E.

Key deliverables

  • Initial version of a synchronisation solution ready for beta testing
  • Basic application to monitor status of the synchronisation solution in operational use
  • A mediator that manages messages from the Abbott Architect machine to BSIS
  • Message specification for device interfacing, most likely in FHIR
  • Improvements to the existing REST API to support interoperability
  • Documented interoperability use cases
  • Updated versions of all product documentation including; systems specifications, quality assurance documentation, implementation/installation guides and user manuals

2-sentence overview of project

The project’s goal is to develop three additional sets of functionality for BSIS that will benefit all current and future implementing Blood Services, as well as supporting basic maintenance of the existing BSIS product. The proposed functionalities are (i) data synchronisation capability for system use at mobile sites and (ii) multi-fixed site interoperability (iii) the ability to electronically interface with laboratory analysis equipment.

Tagging:

  • Laboratory and diagnostic information system  
  • Knowledge management system
  • Data interchange interoperability and accessibility
  • Shared health record and health information repositories
  • Client identification and registration
  • Referral coordination
  • Data storage and aggregation

Comments

Thank you for your proposal and looking forward to the full proposal! Here a couple of questions and comments:

Will the BSIS make use of the OpenLabConnect for its lab hard device interfacing? see https://wiki.digitalsquare.io/index.php/Digital_Square_Investments_in_Gl...

What is the gap between what is in OLC and what AfSBT requires? The proposal mentions the issue of transcription errors for results of blood tests - what data exchange standards are proposed to be used here? Is there a potential Device -> OpenLabConnect -> FHIR -> BSIS route here?

For the offline/multi-site functionality, what is the tech stack that is being proposed? It seems liekly that BSIS could leverage an existing stack (e.g. DHIS2 Tracker, ODK2, etc) that already handles the data sync issues. It is not clear if new data-sync technology is being proposed here or not.