Research Article - Diabetes Management (2021) Volume 11, Issue 7
Identifying functional and non-functional specifications of a telehealth software application for diabetes mellitus
- Corresponding Author:
- Dimitris Folinas
Department of Supply Chain Management, International Hellenic University, 60100 Katerini, Greece
E-mail: folinasd@ihu.gr
Abstract
The study aims to identify and present the functional and non-functional technical and medical specifications of the software application that supports the clinical care of Diabetes Mellitus (DM) patients and maintain clinical information for monitoring, evaluation, and administration purposes in a research project titled cometech. The proposed software application belongs to the Electronic Health Management Information Systems (eHMIS) category that is designed to fulfill the need for an automated national health information management system. It is used for public health-related decision-making. Its main users are public policymakers, health officers, researchers, planning departments of health offices, eHMIS focal persons, data entry clerks, and many others ranging from health facility to federal management levels. The identification and analysis of the functional and non-functional requirements will help researchers to design and develop similar software applications that aim to introduce telehealth tools and services to achieve continuity of health care and to provide consultation and patient education (society awareness).
Keywords
•diabetes mellitus •electronic health management information systems •diabetes
Introduction
Diabetes Mellitus (DM) and Obesity are metabolic diseases with serious health impacts and they both comprise cardio-vascular (CVD) risk factors. DM is also a risk factor for developing small and large vessel complications (e.g., nephropathy, retinopathy, heart disease, stroke, peripheral arterial disease). In the EU, the total costs for DM are over 150 billion Euros/ year (11% of the total health costs) (OECD, 2018). The mean DM-related expenditure/ person in Greece is about 2,450, and in North Macedonia it is 390 Euros/year (WHO, 2013). The majority of the expenditures are due to the treatment of diabetes complications, like endstage renal failure and dialysis, peripheral arterial disease and amputations, retinopathy, etc. The costs for the provision of continuous health care are higher for people living in rural than in urban areas, which can be attributed in part to the greater transport costs in order to reach health system services. Furthermore, patients with type 2 DM are usually asymptomatic and the diagnosis of diabetes delays until serious complications develop. Therefore, the assessment of DM, Obesity and Cardiovascular risk factors and the providing of up to date information on these diseases will increase the awareness of the population. This will reduce the occurrence of above diseases in the targeted isolated areas.
According to many research initiatives, telehealth systems can support the effective and efficient application of continuity of care in diabetes [1- 3]. “Continuity of care in Metabolic diseases through modern Technology” (Cometech) project, is a research project founded by Interreg IPA Cross-border Cooperation Programme Greece - the North Macedonia 2014-2020, which is co-financed by the European Union under the Instrument for Pre-Accession Assistance (IPA II). Cometech is implemented by a partnership consisted of five partners from both participating countries: International Hellenic University, Florina Prefectural General Hospital, and Medical Association of Thessaloniki from Greece, as well as, Clinical Hospital Bitola and General Hospital Veles from Republic of North Macedonia. Total Project budget amounts 1.018.189 EUR. The project duration is 24 months.
Cometech project aims to address the problem of inadequate access to the health system services to people who live in isolated communities at Greece- Republic of North Macedonia crossborder areas. The project will establish 4 e-health units -2 in each country- at isolated and deprived communities collaborated each other, aiming at introducing “Continuity of Care” in the border region between Republic of North Macedonia and Greece. In order to accomplish the above, the provision of medical devices capable of telemedicine is essential. The establishment of the e-health units allows affordable access to medical services within Greece- Republic of North Macedonia cross-border area. These units (equipped by state-of-the-art medical devices, supported by an advanced software application and medical staff) record data of local people, inform them about environmental and other risk factors, and offer valuable and high quality medical care services.
The proposed software application belongs to the Electronic Health Management Information Systems (eHMIS) category. These systems are designed to fulfill the need of automated national health information management system. They helps to accurately and timely collect, aggregate, store, analyze and evaluate health related data from health facility to federal level. Its main users are public policy makers, health officers, researchers, planning departments of health offices, data entry clerks and many others ranging from health facility to federal management levels. These systems can provide useful information for decision making to health professionals [4-6].
The above prerequisite services can be supported through the above infrastructure: a) Tele-consulting, and b) Remote medical data management as illustrated in the following Figure 1 (architecture of the e-health units).
Figure 1: Cometech architecture.
In order to achieve these purposes, an EHMIS must fulfill interoperability standards, quality, security, scalability, reliability and timeliness in data storage and processing terms [7]. Both functional and non-functional requirements (also called quality attributes) should be considered when developing software applications in general. In the following sections these types of functionalities of the cometech Project are examined.
Methods
Functional requirements are statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations [8]. Specifically, functional requirements are those processes that a user wants a system to perform. Functional requirements for any given organization can be described at a high level, in five or 10 functions, or at a very detailed level, potentially numbering in the hundreds [9].
At the end of 2003, the Institute of Medicine (IOM) Committee on Data Standards for Patient Safety developed recommendations on core medical functionalities for four types of care settings: hospitals, ambulatory care, nursing homes, and care in the community - now referred to as the personal health record. There are eight core functions identified by the IOM are probably the closest to what may be considered a standard set of functionality for an e-health unit:
1. Health information and data.
2. Results management.
3. Order entry/management.
4. Decision support.
5. Electronic communication and connectivity.
6. Patient support.
7. Administrative processes.
8. Reporting and population health management.
An important resource for greater specificity in functionality is the Health Level Seven (HL7) EHR-System Functional Model and Standard List of Functional Statements. This set of functional statements is described as a set of functional descriptors applicable in an ideal EHR for all types of providers. It describes functions applicable both to clinics and hospitals, but not all functions needed by a hospital would be needed by a clinic. The Certification Commission for Healthcare Information Technology (CCHIT) has compiled criteria for functionality, interoperability, and security for ambulatory EHR products and for the foundation of inpatient EHRs. These criteria draw from the IOM and HL7 as well as other standards. Products that are certified according to these criteria must demonstrate that they meet the requirements.
Functional requirements of the cometech eHMIS
Based on the above, the following list presents the required functionalities for the cometech project: Creation of registration with the personal data of the medical and nursing staff that will be involved in the pilot implementation of the project in the four health units.
• Management of medical staff users.
Recording by the doctors of the patients, they are attending, as well as, registration of the respective examinations that they will perform.
Management of medical records of patients.
Receiving Medical Data from Recording Devices (Glucose, Arterial Pressure, Cardiogram, Oximetry, Spirometry, Thermometry, Stethoscopy, Otolaryngology, Pelvic Painting, Electrolyte Dilochronate Measurement, from Camera, etc. Regarding the health record, the following data must be recorded (Table 1).
| Visit details |
|---|
| Social - demographic data. |
| Anthropomorphic data. |
| Hematological Examinations. |
| Biochemical tests. |
| General urine test. |
| Glycosylated Hemoglobin. |
| Display a total number of active participants. |
| Monitoring goals for all participants during the project and its completion. Objectives to be followed: Glycosylated Hemoglobin ≤ 7%, Decrease in the number of hypoglycemia per month, Compliance with the proposed number of telemedicine measurements (AP, Blood Glucose, Oximetry, Spirometry, etc.) Score of dietary questionnaires, Take glucose tapes per month, and Evaluation of physical activity. |
| Display automatic notification on receiving/sending and managing medical parameters software whenever a goal is not achieved. |
| Visit and appointment management. |
Table 1. Recorded data.
• Easy to use Graphic Environment in Greek and English.
• Ability to store data locally and send it to another time it is within network coverage.
• Ability to view locally stored exams in the form of a history.
• Get answers from health professionals and view locally.
• Possibility of synchronization with the Medical Electronic Integrated Diabetes Folder.
• Connect the software with the recording devices of at least Glucose, Arterial Pressure, ECG, Oximeter, Spirometer, Thermometer, Stethoscope, Pediatrician, AGE reader age reader and by bottom fundus camera for receiving wireless medical signals.
• Ability to complete algorithmic questionnaires and synchronize with the Medical Electronic Integrated Diabetes Folder.
• Introduction of personalized limits and selection of notifications per patient.
• Possibility of receiving notifications/ reinforcing messages from the Medical Electronic Comprehensive Diabetes File.
• Possibility to select goals from a nutritionist, immediate information through the Medical Electronic Integrated Care Diabetic File.
• Nutritional knowledge questionnaire based on scientific methodology.
• Ability to assess the current situation using a scaled barrier incentive scale.
• Produce automatic messages according to the options in the questionnaire.
• Ability to track targets set by diabetologist and dieticians nutritionists and diabetologists through the Integrated Diabetic E-Medical Medical File.
• Integration of the following algorithmic questionnaires: Quality of life questionnaire, Self-efficacy questionnaire for selfmanagement of diabetes, Questionnaire on eating habits and Questionnaire on patients’ health status.
• User access control to certify and identify the user’s rights when accessing the application at system level and application of telemedicine.
• Authorization to access information different by user and by type of information.
• Observance of the provisions of Law 2472/1997, EU 2016/679 (GDPR) regarding the Protection of Personal Data.
• Preservation of medical data in encrypted form.
• User interface friendliness.
• The error messages that the applications present to the end users, should be in Greek and English and the users should be notified in terms familiar to them.
• The technologies that will be used for the development of the application to ensure its easy maintenance and allow the expansion of its functionality by adding additional subsystems that will cover possible future needs.
• Open standard support: ensuring the viability and future expansion of the system, all offered development tools, server software as well as the application are based on open templates and are available under the terms of the GNU/GPL license.
• Systemic article architecture to allow future extensions and replacements, integrations, upgrades or changes to separate software or hardware components.
• Open architecture where the proposed/ offered software services, security and the database management system and application are based on proven mature and tested systems platforms in the open to facilitate its support and maintenance.
• Access to system functions should also be possible via BlueTooth portable devices at least for ECG, spirometry, oximetry, glucose, blood pressure, weighting and BMI tests.
• Find the files of the examinees/patients in a fast and easy way (e.g. use of demographics, etc.).
Moreover, the software application should meet different roles’ requirement and access authority management, which will be used as a basic model in some specific application in the future. For example, different roles such as diabetes patients, doctors and administrator can be created, and the discussion between patients and doctors should be available. Moreover, the authenticated doctor can access the specified items of the patients, which will solve the problem of security.
1. Patient’s requirements: The patients need an e-health unit model, which they can view their electric record and get self-care education, moreover, the patients need advice from specify doctors, so they hope that they can manage the access authority. The patient need to have the right to assign some specific authorities for the doctors, for example when a diabetes patient want to share their medical record like glucose, exercise, weight vary and daily diet during some periods, sometimes, they just want to share part of their information like glucose, and they don’t want the doctor to see the others’ privacy data. When the patients do not want the doctor to access their medical record, they can cancel the doctors’ authorities. An authority’s record history is needed to remind the patients whom they has given the authorities to. Search function is also needed in this system; the patients can find the registered doctor, as they want to give access control. In our E-health model, the patient can view the record whenever they want and share their own thought with other patients in the communication platform.
2. Doctor’s requirements: To the doctor, they would like the system to be flexible that they can also access the website at anywhere and get the information from the patients who they give the authority, they also don’t want to view a handwritten record because of it will always led some mistakes and wastes time, which can reduce the medical accident caused by misunderstanding, the doctors hope that they can share their experience and view the patients record clearly.
3. Administrator’s requirements: The e-health model need an administrator, who can manage and monitor the software application. The administrator would like to monitor the application in case of change the patient information for illegal purpose and has the power to manage the register users. In Cometech project, the administrator can manage roles and users (e.g. delete some illegal users) and can publish a global notification to all the users to remind some important things. The administrator also can view all the information of the registered users except password.
4. Security requirements: To avoid abusive registration, all the users in the proposed system can register only one account for each person. In addition, a security mechanism for the users can be offered when they want to change the password or forget their password. In cometech project, users need to answer the security questions and give the email so that when users want to change their password. Moreover, it is general idea that only the person who knows the password can login the account. The password is encrypted during the transmission. In the transmission of medical records and personal information, those information are encrypted.
Finally, patients’ personal data needs to be stored in the encrypted database based on a common standard. One reliable solution is the AES256 standard, which describes a symmetric secret key encryption block process. The encryption process is repetitive. This means that in each data block a processing is performed which is repeated a number of times depending on the key length. Specifically, the Rijndael 256 is the encryption algorithm used for AES encryption. In addition, the code uses block segregation through the “Electronic Code Book” and encrypts them separately, which increases security. The communication with the servers is done through https security protocols and the start SSL PKI (128bit). Both User-Id and user passwords are stored in encrypted form in the database. To increase security, an active connection test will be used, so that after the connection to the application a certain idle time has elapsed without any execution.
Non-functional requirements of the Cometech eHMIS
Non-functional requirements are attributes that either the system or the environment must have [4]. IEEE (1993) defines non-functional requirements in software system engineering, “a software requirement that describes not what the software will do, but how the software will do it, for example, software performance requirements, software external interface requirements, design constraints, and software quality attributes”.
A number of research initiatives identified the non-functional requirements
Some of these are requirements that many stakeholders gravitate to, and some are requirements few if any end users recognize are needed. Non-functional requirements and their descriptions for the Cometech Project (adapted from are presented in the following (TABLE 2) [10].
| Non-Functional Requirement | Description |
|---|---|
| Usability | Describes the ease with which the system can be learned, managed or used. Usability gives the measure of how much user friendly the system is. This also includes the Internationalization/localization requirements such as, languages, spellings, etc. This is critical for the COMETECH project because doctors and nurses are not experienced software application users and they are working based on a rotation-based schedule. Therefore, the system should be sufficiently intuitive to allow new users to learn basic operations within one day of use; users must need no more than two screens to complete a task and/or one measurement. Moreover, the application should support the monitoring of the procedures for ensuring quality service, through the database management tool and the administrators can have access directly to the application. |
| Reliability | Describes the degree to which the system must work for users. It also refers to the mean time between failures, means what can be the maximum down time. For example, two hours in six months etc. It also deals with the time taken by the system to recover if failure occurs; this is also termed as mean time to recovery. Therefore, specifications for reliability typically refer to availability, downtime, time to repair, accuracy, etc. For the COMETECH project for example, in case of a power outage e-health units and software application will have sufficient local and remote redundancy to power down all none critical systems. All critical systems will run on a backup generator or local battery power (UPS) for at least 12 hours. |
| Performance | Performance specifications typically refer to response time, transaction throughput, and capacity. They deal with response time, which means the time taken by the system to load, reload, screen open and refresh times etc. The processing time, which is due to functions, calculations, imports, exports. Query and reporting time is also accountable for system’s performance. For example in the COMETECH and during the pilot project, while executing a search for a medication, the system must be able to display all the main results of a patient examination. |
| Supportability | It refers to the application’s ability to be easily modified or maintained to accommodate typical usage or change scenarios. For example, the software application will allow users to create new workflows without the need for additional programming. In addition, the system will allow the medical staff to modify a clinical decision support rule after obtaining applicable approval. |
| Compatibility | Compatibility of a system deals with what ease the system is able to operate with shared applications. These shared applications can be the 3rd part applications as well. This also covers the system’s compatibility on different-different platforms. The platforms can be either hardware, software or both. In the COMETECH project, compatibility mainly refers to the connection with the medical devices. |
| Interoperability | It refers to the ability of one application to exchange data with another. Interoperability requires the adoption of standards that enable interfaces to be written. Interoperability may also incorporate concepts of connectivity, messaging, and interactive portals. For example, in the COMETECH project a medical examination in one e-health unit must provide oversight of services between the other two e-health units and the central e-health unit. |
| Scalability | It refers to the ability of the proposed software application to increase the number of users or applications associated with the product. For the COMETECH project, the software can provide more functionalities to the users in the future and can support more medical devices. |
| System | These requirements generally include required operating systems, commercial-grade software development tools (e.g., reusable components), specific hardware or platform requirements, and any environmental requirements. Some would include reliability and performance requirements in system requirements, but these may be issues that end users are particularly concerned about and may best be separated. In the COMETECH project one non-functional requirement can be the ad-hoc printing options, as well as, dashboard capabilities. |
| Modularity | Modular architecture of the system, allows future extensions and replacements, integrations, upgrades or changes of distinct software or equipment. One good approach is the adaptation of the modular architecture of MVC Model, the use of which in combination with Database Abstraction Layer is possible to fully separate the structural elements of the portal and user interface with the business logic of the system and mechanism processing, analysis and completion of procedures. Database Abstraction Layer is essential for uninterrupted reading from different sources and recording them. The adoption of the model by the offered software of the system as well as by the framework that will be used for the development of code igniter but also the general construction of the architecture in multiple subsystems show the modular character of the proposed architecture. |
| Open standards | It ensures the viability and future expansion of the system, all offered development tools, server software, as well as, the application are based on open templates and are available under the terms of the General Public License. |
| Open architecture | Open architecture, the proposed / offered software services, security and DBMS and the application are based on proven mature and tested systems platforms in the open to facilitate its support and maintenance, such as:
|
| Availability | Availability tells the operating hours of the system and when it is available. High availability, in terms of ensuring the high availability of the services of the system, the proposed architecture combines applications that can work perfectly in Network Load Balancing layout. High security, integrity, this must be achieved at the data level by the efficient use of integrity and graded access rules in the database, at the business logic level by enforcing graded access rules and controlling and certifying users and at the level of graphical interface data by imposing rules in their system entry forms. |
| Legal/Regulatory | Requirements include the capability to generate an acceptable representation of a legal health record, intellectual property rights, adherence to telecommunication requirements, and other features. This is a requirement of critical interest to the COMETECH project. The system must be able to support upgrades to any required data collection process, rules for regulatory review, and new code sets as they may become mandated (such as ICD-10-CM). |
| Security | It refers to the ability to provide confidentiality, data integrity, and data availability. Reference is often made to the national and European Union (EU) policies and law. Clinicians who do not have a treatment relationship with a client will be permitted to access the client’s protected health information through a break-the-glass function only in a documented emergency and only with a separate audit log being generated. For the COMETECH Project the software application must follow the CE 0653 Class IIa, according to EU law of MDR 2017/745. Also, of the Ν.2472/1997, EU 2016/679 of the General Data Protection Regulation (GDPR). |
| Maintainability | Maintainability of a system is the level of ease with which a system can be modified or some changes may be brought into. This change or modification can be due to the addition of some new functionality to the system or for the sake of bug fixing. |
| Recovery | Recovery is the ability of the software system to recover after some damage. The time taken by the system to recover back to its original shape is the recovery time. |
| Robustness | Robustness is the ability of a computer system to cope with errors during execution or the ability of an algorithm to continue to operate despite abnormalities in input, calculations, etc. |
| Resilience | Resilience is the ability to provide and maintain an acceptable level of service when some faults occurs and performs normally. |
Table 2: Non-Functional Requirements.
Results and Discussion
This paper aims to present one of the deliverables of a research project titled “Continuity of care in metabolic diseases through modern technology” (Cometech), founded by Interreg Ipa Crossborder Cooperation Programme Greece - the North Macedonia 2014-2020. Cometech project aims to address the problem of inadequate access to health system services to people who live in isolated communities in Greece- Republic of North Macedonia cross-border areas. It introduces the setup of four (4) e-health units (two per country) collaborated, aiming at introducing “Continuity of Care” in the border regions via a specialized web application.
Specifically, this report presents the functional and non-functional user requirements of the application software system for the cometech Project. In general, the examined software application is a telemetry system that uses the latest wireless communication technologies (Mobile Phone Network), a Tablet PC or a Smartphone device, and medical monitoring devices. It belongs to the Electronic Health Management Information Systems (eHMIS) category that is designed to fulfill the need for an automated national health information management system. It is specially designed to allow patients and physicians to monitor the patient’s health anywhere and anytime. It is an Internet-based application (web), through which specialized staff easily access data, thanks to the user-friendly environment, through a browser [11-19].
Authorized users of the Hospitals of the program (Bitola, Florina, Veles) can access the web application to evaluate the medical data and patient measurements to provide medical advice to the physician of the telemedicine units where required. The system has been installed and operated on a central server of the International Hellenic University in Thessaloniki, Greece where they will be collected, tested for quality and stored measurements of biological parameters of patients, which will be sent wirelessly from remote locations, i.e. health units and the Hospitals (Bitola, Florina, Veles), as well as, the Central Coordination Center in Thessaloniki will have authorized access.
Conclusion
In remote locations, trained nurses/medical staff record data on the patient’s health (history, personal memory, etc.) via a laptop or tablet, as well as the results of measurements of medical devices installed at remote telemedicine points and sync them to the central server (web application). In the web application, specialized doctors of the aforementioned health units have access, order to evaluate the medical data and the measurements of the patients to provide where necessary medical advice to the doctor of the telemedicine units.
There are also challenges that need to be addressed for the effective and efficient application of the eHMIS in the ehealth units, based on Moucheraud (2018) and Khubone, Tlou and Mashamba-Thompson (2020), Aldholay, Isaac and Abdullah (2018), Ouedraogo, Kurji and Abebe (2019) and Meri, Hasan and Danaee (2019) studies, such as legislation, lack of funds (financial investment), staff resistance (and staff training), political leadership, complexity of the intervention and lack of technical consensus, acceptability of technology, quality of data, performance expectancy, compatibility factors, and social influence among professionals.
The authors strongly believe that the findings of this study will help researchers to design and develop similar software applications that aim to introduce telehealth tools and services to achieve continuity of health care and to provide consultation and patient education (society awareness).
Funding
This research was funded by Interreg Pre- Accession Assistance (IPA) Cross Border Cooperation (CBC) Programme “Greece- Republic of North Macedonia 2014–2020” co-financed by the European Union under the Instrument for Pre-Accession Assistance (IPA II). Project co-funded by the European Union and national funds of the participating countries.
References
- Hanlon P, Daines L, Campbell C, et al. Telehealth Interventions to Support Self-Management of Long-Term Conditions: A Systematic Metareview of Diabetes, Heart Failure, Asthma, Chronic Obstructive Pulmonary Disease, and Cancer. J Med Internet Res. 19(5),172-181 (2017).
- Tang, P, Overhage J, Chan A, et al. Online disease Management of Diabetes: Engaging and Motivating Patients Online with Enhanced Resources-Diabetes (Empower-D), A Randomized Controlled Trial. J Am Med Inform Assoc. 20(3), 526-534 (2013).
- Odom J, Stancil M, Nelson B, et al. Improving Diabetes Control through Remote Glucose Monitoring in a Diabetes Self-Management Program for Employees of a Health System. Clin Diabetes. 37(3), 203-210 (2019).
- Berges I, Bermúdez J, Illarramendi A. Towards Semantic Interoperability of Electronic Health Records, IEEE T. Inf Technol B.16 (3), 424-431 (2012).
- European Commission. OECD Health at a Glance: Europe State of Health in the EU Cycle.
- Ford E, Menachemi N, Phillips T. Predicting the Adoption of Electronic Health Records by Physicians: When Will Health Care be Paperless? J Am Med Inform Assoc.13 (1),106-112(2006).
- Jardim, S. The Electronic Health Record and its Contribution to Healthcare Information Systems Interoperability. Proc Technol. 9, 940-948 (2013).
- Sommerville I. Software Engineering, Addison-Wesley, Harlow, England, 9th edition (2010).
- IEEE IEEE Recommended Practice for Software Requirements Specifications. IEEE Standard. (1993).
- McEwen S. Metasys Technologies, IBM DeveloperWorks, Requirements: An Introduction (2004).
- OECD organisation. Health at a Glance: Europe, state of health in the EU cycle (2020).
- Aldholay A, Isaac O, Abdullah Z. An extension of Delone and McLean IS success model with self-efficacy: Online learning usage in Yemen. Int J Inf Learn Technol. 35(4), 285–304 (2018).
- Katehakis DG, Kouroubali A, Fundulaki I. Towards the Development of a National eHealth Interoperability Framework to Address Public Health Challenges in Greece. SWH@ISWC (2018).
- Khubone T, Tlou B, Mashamba-Thompson TP. Electronic Health Information Systems to Improve Disease Diagnosis and Management at Point-of-Care in Low and Middle Income Countries: A Narrative Review. Diagnostics. 10(5),327 (2020).
- Lamine E, Guédria W, Rius SolerA, et al. An Inventory of Interoperability in Healthcare Ecosystems: Characterization and Challenges. In: Archimède B, Vallespir B (eds). Enterprise Interoperability: INTEROP-PGSO Vision. Wiley-ISTE. New Jersey. United States. (2017).
- Le Pape M, Núñez J, Mhayi A, et al. Developing an HMIS Architecture Framework to Support a National Health Care eHealth Strategy Reform: A Case Study from Morocco. Health car sys. 3:1, 56-67(2017).
- Meri, A., Hasan, M. and Danaee, M. (2019) Modelling the utilization of cloud health information systems in the Iraqi public healthcare sector. Telematics and Informatics 36. Elsevier Ltd. 132–146(2019).
- Moucheraud C, Schwitters A, Boudreaux C, et al. Sustainability of health information systems: A three-country qualitative study in southern Africa. BMC health services research. BMC Health Serv Res. 17,23 (2017).
- Ouedraogo M, Kurji J. Abebe L. A quality assessment of health management information system (HMIS) data for maternal and child health in Jimma Zone, Ethiopia. PLoS ONE. 14(3), 1–12 (2019).
