This is an open-access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in JMIR Formative Research, is properly cited. The complete bibliographic information, a link to the original publication on https://formative.jmir.org, as well as this copyright and license information must be included.
Electronic record (eRecord) systems and mobile health (mHealth) apps have documented potential to improve health service delivery, resulting in increased global uptake. However, their interoperability remains a global challenge hindering diagnosis, monitoring of health conditions, and data access irrespective of geographic location. Given the widespread use of mobile devices by patients and health care providers, linking mHealth apps and eRecord systems could result in a comprehensive and seamless data exchange within a health care community. The Botswana National eHealth Strategy recognizes interoperability as an issue and mHealth as a potential solution for some health care needs but is silent on how to make mHealth apps interoperable with existing eRecord systems. A literature review and analysis of existing mHealth interoperability frameworks found none suitable for Botswana. As such, it was critical to conceptualize, design, and develop an mHealth-eRecord Interoperability Framework (mHeRIF) to enhance the interoperability pillar of the Botswana National eHealth Strategy and leverage the full benefits of linking mHealth apps with other health information systems.
This study aimed to validate the developed mHeRIF and determine whether it requires further refinement before consideration towards enhancing the National eHealth Strategy.
Published framework validation approaches guided the development of a survey administered to 12 purposively selected local and international eHealth experts. In total, 25% (3/12) of the experts were drawn from Botswana, 25% (3/12) were drawn from low- and middle-income countries in sub-Saharan Africa, 25% (3/12) were drawn from low- and middle-income countries outside Africa, and 25% (3/12) were drawn from high-income countries. Quantitative responses were collated in a Microsoft Excel (Microsoft Corp) spreadsheet for descriptive analysis, and the NVivo software (version 11; QSR International) was used to aid the thematic analysis of the qualitative open-ended questions.
The analysis of responses showed overall support for the content and format of the proposed mHeRIF. However, some experts’ suggestions led to 4 modest revisions of the mHeRIF.
Overall, the experts’ reviews showed that the mHeRIF could contribute to the National eHealth Strategy by guiding the linking of mHealth apps to existing eRecord systems in Botswana. Similarly, the experts validated an architectural model derived from the mHeRIF in support of the first mobile telemedicine initiative considered for national rollout in Botswana. The mHeRIF helps identify key components to consider before and after linking mHealth apps to eRecord systems and is being considered for use as the foundation of such interoperability in Botswana.
Bidirectional communication between and among eHealth solutions (eg, electronic health-related records and service delivery solutions such as telemedicine) is a desirable goal for access to and portability of functional eHealth. Such functionality is of particular importance for electronic record (eRecord) solutions and mobile health (mHealth) apps as their increased use is inevitable in today’s era of digitally empowered communities. Indeed, eHealth (“the use of Information and Communication Technologies (ICT) for health”) [
In this study,
More recently, the COVID-19 pandemic has presented numerous challenges requiring interaction between eHealth components [
Similar to other
mHealth initiatives previously implemented in Botswana supported priority health programs, including cervical cancer screening, oral health, ophthalmology, dermatology, radiology, and tuberculosis, through a coalition of public and private partners [
Interoperability is the ability of 2 or more systems or components to exchange information and use the information that has been exchanged [
A previous literature review identified several eHealth interoperability frameworks [
The proposed mHeRIF highlights the need for governance and regulation of mHealth and eRecord systems. It further shows the need for and role of a national health information exchange (HIE) and is aligned with the established Refined eHealth European Interoperability Framework [
The utility of the mHeRIF was demonstrated by developing an interoperability architecture supported by the Open Health Information Exchange (OpenHIE) framework [
Having demonstrated its utility, it is important to validate the proposed mHeRIF and its OpenHIE-based architecture for Botswana. No specific guidance from the literature addresses the validation of interoperability frameworks linking mHealth apps to eRecord systems. However, literature does exist on the topic of “validation,” and published validation approaches can be considered and either adopted or adapted.
Framework validation approaches have involved psychometric assessment [
In this study, “validation” refers to a process of establishing evidence that confirms that the mHeRIF is “fit for purpose”—capable of consistently guiding the process it is supposed to—and meets the operational needs of its intended users. Given the absence of a specific and accepted validation approach, the recommendation of Inglis [
The mHeRIF validation process entailed a survey conducted with 12 purposively selected eHealth proponents from academia, industry, and the government. Each was selected based on their experience and expertise in the field within their respective countries or regions. Although the participants’ years in the field were considered, their demonstrable activity within the field (eg, conferences, publications, and reports) was the major consideration. To obtain diverse perspectives, 25% (3/12) of the experts were from Botswana, 25% (3/12) were from LMICs within sub-Saharan Africa (SSA), 25% (3/12) were from LMICs outside SSA, and 25% (3/12) were from high-income countries.
The survey comprised 51 closed-ended questions (26 Likert scale questions and 25 multiple-choice questions [dichotomous or trichotomous]) and 3 open-ended questions. The Likert scale questions related to the design of the proposed mHeRIF. The multiple-choice questions addressed fundamental concepts that guided the framework design and intent, participants’ demographic location, their role in the digital health field, and their years of experience in the field. A total of 3 open-ended questions sought opinions on whether the framework in its current form was suitable to achieve its intent and on areas of possible improvement of the mHeRIF and the associated architecture.
A 4-point Likert scale with a fifth option of “unable to assess” was used for the 26 Likert scale questions (ordinal scale: 4=strongly agree, 3=agree, 2=disagree, and 1=strongly disagree). Closed-ended questions were either dichotomous (
The survey was first reviewed by 4 colleagues (nonparticipants in the formal survey) and refined to avoid noted ambiguities. The refined survey was administered on the web using REDCap (Research Electronic Data Capture; Vanderbilt University) forms from March 8, 2022, to June 10, 2022. Survey responses were collated in a Microsoft Excel (Microsoft Corp) spreadsheet, and quantitative data were summarized using descriptive statistics. The NVivo software (version 11; QSR International) was used to aid the thematic analysis of responses to the open-ended questions. The final themes were agreed upon by consensus among all authors and were used to refine the framework.
This study was approved by the Botswana Ministry of Health Research Office (reference HPDME 13/18/1) and the Humanities and Social Sciences Ethics Committee of the University of KwaZulu-Natal, South Africa (reference HSS/0818/015D). All survey participants provided web-based consent. Before participating in the survey, a preliminary personalized email invitation was sent to each potential participant. Those who expressed interest in participating were then sent a formal letter of invitation, a consent form, the developed mHeRIF (with accompanying explanatory notes), and access to a web-based self-administered survey. The explanatory notes (
A total of 21 eHealth experts were invited to participate. In total, 13 experts agreed to participate, and 12 (92%) responded to the survey. A total of 17% (2/12) of the experts were in academia, 33% (4/12) were executive leaders, 25% (3/12) were technical officers (eg, analysts or programmers), and the remaining 25% (3/12) were technical managers. Almost all (11/12, 92%) had either 11 to 15 years or >15 years of experience in the field, and 8% (1/12) had 6 to 10 years of experience.
As judged by the median Likert scale scores and most “yes” dichotomous or trichotomous responses, the experts were in agreement with the general format and content of the mHeRIF. All experts (12/12, 100%) “agreed” (
Most eHealth experts (11/12, 92%) further agreed that the mHeRIF offered guidance for linking mHealth solutions to eRecord systems, all the essential interoperability layers were addressed within the mHeRIF, and leveraging open-source eHealth applications such as “Global Goods” (universally available software, services, and content) was an important consideration for LMICs such as Botswana (
Of the 12 experts, 3 (25%) indicated that they would be unable to use the mHeRIF (
Similarly of note is that half (6/12, 50%) of the experts agreed that the mHeRIF satisfactorily addressed fundamental aspects for linking mHealth solutions to eRecord systems (eg, essential communication and network protocols), whereas 17% (2/12) were “unable to assess,” and the remaining 33% (4/12) “disagreed” (
A total of 12 dichotomous questions related to “were framework components essential?” The 144 responses are shown in
Likert scale responses from eHealth experts on the fundamental concepts that guided the framework development (framework design).
Statement | Likert scale responsesa | Median score | |||||||||||||||
|
Botswana | LMICb within SSAc | LMIC outside SSA | High-income countries |
|
||||||||||||
|
Expert 1 | Expert 2 | Expert 3 | Expert 4 | Expert 5 | Expert 6 | Expert 7 | Expert 8 | Expert 9 | Expert 10 | Expert 11 | Expert 12 |
|
||||
Having read the mHeRIFd description, I am able to understand its structure (interoperability layers, themes, concepts, and their relationships). | 4 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 4 | 3 | 3 | 3 | 3 | ||||
The mHeRIF offers guidance to linking mHealthe solutions to eRecordf systems. | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 4 | 3 | 3 | 2 | 3 | ||||
I would be able to use the mHeRIF. | 4 | 3 | 3 | 3 | 2 | 3 | 2 | Ug | 3 | 3 | 2 | 3 | 3 | ||||
The mHeRIF addresses all of the necessary interoperability layers (technical, syntactic, semantic, organizational, and legal). | 4 | 3 | 3 | 3 | U | 3 | 3 | 3 | 4 | 3 | 3 | 3 | 3 | ||||
The mHeRIF promotes leveraging of existing infrastructure such as “on-site” servers and “cloud” technologies to support health care service delivery. | 4 | 3 | 3 | 4 | 3 |
|
2 | U | 4 | 3 | U | U | 3 | ||||
Leveraging open-source eHealth applications such as the “Global Goods” (universally available software, services, and content) is an important consideration for developing countries such as Botswana. | 4 | 4 | 4 | 4 | 4 | 1 | 3 | 4 | 4 | 4 | 3 | 4 | 4 | ||||
The mHeRIF satisfactorily addresses fundamental aspects to linking mHealth solutions to eRecord systems (eg, essential communication and network protocols). | 4 | 3 | 3 | 3 | U |
|
2 | U | 4 | 3 | 2 | 2 | 3 | ||||
The mHeRIF could contribute to enhancing a National eHealth Strategy interoperability pillar. | 4 | 3 | 3 | 4 | 3 |
|
3 | 3 | 4 | 4 | 3 | U | 3 | ||||
The mHeRIF satisfactorily aligns with key national policy documents (eg, the “Data Protection Act” and “National ICT policy”) in Botswana. | 4 | 3 | 3 | 3 | U |
|
3 | U | 4 | U | U | U | 3 | ||||
“Governance and regulation” is a relevant component of the mHeRIF. | 4 | 4 | 4 | 4 | 4 | 4 | 4 | 4 | 4 | 4 | 3 | 3 | 4 | ||||
The “National Health Information Exchange (NHIE)” in the mHeRIF is an essential component to linking mHealth solutions to eRecord systems. | 4 | 4 | 3 | 3 | 3 | 3 | 3 | 4 | 4 | 4 | 4 | 2 | 4 | ||||
“Human resource capacity building” is a relevant component of the mHeRIF. | 4 | 4 | 3 | 4 | 4 | 4 | 3 | 4 | 4 | 4 | 2 | 4 | 4 | ||||
Security, privacy, and confidentiality issues are important components within the mHeRIF. | 4 | 4 | 4 | 4 | 4 | 3 | 3 | 4 | 4 | 4 | 3 | 4 | 4 | ||||
Organizational issues such as “collaboration agreements” and “workflow agreements” are important components within the mHeRIF. | 4 | 3 | 3 | 4 | U | 3 | 3 | 4 | 4 | 4 | 3 | 3 | 3 | ||||
“Usability” of mHealth applications and eRecord systems is an important component of the mHeRIF. | 4 | 3 | 4 | 3 | U | 3 | 3 | 4 | 4 | 4 | 3 | 4 | 4 | ||||
“mHealth-eRecord Workflow Agreements” are important components within the mHeRIF. | 4 | 3 | 3 | 3 | U | 3 | 3 | 4 | 4 | 4 | 3 | 3 | 3 | ||||
Fundamental “mHealth-eRecord” standards for interoperability are essential components within the mHeRIF. | 4 | 3 | 3 | 4 | 4 | 3 | 3 | 4 | 4 | 4 | 4 | 3 | 4 | ||||
The use of terminologies is an important component to achieve semantic interoperability of mHealth solutions and eRecord systems. | 4 | 4 | 4 | 4 | 4 | 4 | 3 | 4 | 4 | 4 | 3 | 4 | 4 | ||||
“Data formats” and “Data models” are important components to linking mHealth solutions and eRecord systems. | 4 | 4 | 3 | 3 | 4 | 3 | 3 | 4 | 4 | 4 | 3 | 3 | 4 | ||||
The need to audit, accredit, and align standards for “Applications” and “IT Infrastructure” within the mHeRIF is essential. | 4 | 3 | 3 | 3 | 4 | 3 | 3 | 4 | 4 | 3 | 3 | 3 | 3 | ||||
The need to review and align “mHealth-eRecord collaboration agreements” and “mHealth-eRecord workflow agreements” within the mHeRIF is essential. | 3 | 3 | 3 | 3 | U | 3 | 3 | 4 | 4 | 3 | 2 | U | 3 | ||||
“Governance and Regulation” is appropriately placed within the mHeRIF. | 4 | 3 | 3 | 3 | 4 | 3 | 4 | 4 | 4 | 3 | 2 | 3 | 3 | ||||
“Human Resource Capacity Building” is appropriately placed within the mHeRIF. | 4 | 3 | 3 | 3 | 4 | 3 | 4 | 4 | 4 | 3 | 3 | 3 | 3 | ||||
“Legislation (Security, privacy, and confidentiality)” considerations are appropriately placed within the mHeRIF. | 4 | 3 | 3 | 3 | 2 | 3 | 3 | 4 | 4 | 3 | 3 | 2 | 3 | ||||
The “unique patient identifier” (UPI) is appropriately placed within the mHeRIF. | 4 | 3 | 3 | 3 | 2 | 3 | 3 | 3 | 4 | 4 | 2 | 2 | 3 | ||||
Considering the intent of the mHeRIF, which is to guide linking of mHealth apps to eRecord systems in the context of developing countries (using Botswana as the exemplar), and considering the provision that specifics of the content may need to be modified to be context specific: is the framework in its current form suitable to achieve the intent? | 3 | 3 | 3 | 3 | 2 | 2 | 3 | 3 | 4 | 3 | 3 | 2 | 3 |
aA 4-point Likert scale: 4=strongly agree, 3=agree, 2=disagree, and 1=strongly disagree.
bLMIC: low- and middle-income country.
cSSA: sub-Saharan Africa.
dmHeRIF: Mobile Health–Electronic Record Interoperability Framework.
emHealth: mobile health.
feRecord: electronic record.
gU: unable to assess.
hItalicized Likert scale responses indicate no comments posted for any disagreement (disagree or strongly disagree).
Validation experts’ responses to multiple-choice questions related to were framework components essential?
Statement | Yes or no responses from local and globally identified eHealth experts | |||||||||||
|
Botswana | LMICa within SSAb | LMIC outside SSA | High-income countries | ||||||||
|
Expert 1 | Expert 2 | Expert 3 | Expert 4 | Expert 5 | Expert 6 | Expert 7 | Expert 8 | Expert 9 | Expert 10 | Expert 11 | Expert 12 |
The mHeRIFc shows that “Governance and Regulation” is essential? | Yd | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Ne |
The mHeRIF shows that the “National Health Information Exchange (NHIE)” is an essential component to linking mHealthf solutions to eRecordg systems? | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y |
The mHeRIF shows that “Human resource capacity building” is a relevant component? | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y |
The mHeRIF clearly shows that security, privacy, and confidentiality issues are essential? | Y | Y | Y | Y | Y | Y | Y | Y | Y | N | Y | N |
The mHeRIF shows that organizational issues, such as “collaboration agreements” and “workflow agreements,” are essential? | Y | Y | Y | Y | —h | Y | Y | Y | Y | Y | Y | N |
The mHeRIF shows that “Usability” of mHealth applications and eRecord systems is an important component? | Y | Y | Y | Y | — | Y | Y | N | Y | N | N | N |
The mHeRIF shows that “mHealth-eRecord Workflow Agreements” are essential components? | Y | Y | Y | Y | — | Y | Y | Y | Y | Y | Y | N |
The mHeRIF shows that “mHealth-eRecord” standards for interoperability are essential? | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | N |
The mHeRIF shows that use of terminologies (eg, SNOMED-CTi and LOINCj) is essential to linking mHealth solutions to eRecord systems? | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | N |
The mHeRIF shows that “Data formats” and “Data models” are essential to linking mHealth solutions and eRecord systems? | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | N |
The mHeRIF shows the need to audit, accredit, and align standards for “Applications” and “IT Infrastructure”? | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y |
The mHeRIF shows the need to review and align “mHealth-eRecord collaboration agreements” and “mHealth-eRecord workflow agreements”? | Y | Y | Y | Y | — | Y | N | Y | Y | Y | Y | Y |
aLMIC: low- and middle-income country.
bSSA: sub-Saharan Africa.
cmHeRIF: Mobile Health–Electronic Record Interoperability Framework.
dY: yes.
eN: no.
fmHealth: mobile health.
geRecord: electronic record.
hNot available.
iSNOMED-CT: Systematized Nomenclature of Medicine–Clinical Terminology.
jLOINC: Logical Observation Identifiers Names and Codes.
Of the 3 open-ended questions, 2 (67%) related to the framework (“Is the framework in its current form suitable to achieve the intent?” and “Any suggestions for improvement of the mHeRIF?”) and 1 (33%) related to the architecture (“Any suggestions on how the proposed mHeRIF architecture could be improved to achieve its intent?”). Collectively, the experts provided 15 optional comments to these 3 specific open-ended questions. Considering that the utility of the mHeRIF application was retrospectively demonstrated by developing an architectural model for the Kgonafalo program, none of the experts disagreed with the fundamental concepts that guided the interoperability architecture design and development (
In addition, experts sometimes provided optional explanatory comments on their closed-ended responses. Of the 312 opportunities for comments on open-ended questions (26 Likert scale questions × 12 experts), only 98 comments (31.4%) were made. Of the 300 opportunities for comments on dichotomous and trichotomous questions (25 closed-ended questions × 12 experts), 52 (17.3%) were made. Each comment was reviewed by 1 author (KN), and through the process of reflective review, they were categorized into themes. The process was subsequently critically reviewed and revised by a second author (RES). Final agreement was by consensus, with guidance categorized into 7 themes to aid further analysis: “governance and regulation,” “interoperability standards,” “eHealth software and infrastructure,” “unique patient identifier,” “human resource capacity development,” “usability,” and “security, privacy and confidentiality.”
Some of the comments provided informative suggestions for potential framework revision, whereas others provided only general statements that did not offer guidance or require framework revision (eg, “Patient de-duplication generates accurate statistics,” “It is a central factor,” and “I do not have knowledge of these policies”). All comments were reviewed a second time by 2 authors (KN and RES) to parse those that provided potential guidance (
Some comments led to the revision of the mHeRIF (
Experts’ opinions on fundamental concepts that guided the interoperability architecture design and intent (N=12).
“Does the interoperability architecture design show evidence of the following:” | Yes or no responses (local and global eHealth experts), n (%) | ||
|
Yes | No | Don’t know |
Master patient index (MPI), Health Worker Registry (HWR), Master Facility List (MFL), and Shared Health Records (SHRs) are important registries within the mHeRIFa architecture. | 11 (92) | 0 (0) | 1 (8) |
An interoperability layer (OpenHIMb) is appropriate within the mHeRIF architecture to support linking mHealthc solutions to eRecordd systems. | 11 (92) | 0 (0) | 1 (8) |
The OpenHIEe framework within the mHeRIF architecture is ideal to support linking of mHealth solutions to eRecord systems. | 10 (83) | 0 (0) | 2 (17) |
Security, privacy, and confidentiality within the mHeRIF architecture should be prioritized when linking mHealth applications and eRecord systems. | 11 (92) | 0 (0) | 1 (8) |
The mHeRIF architecture should support different mobile devices (eg, smartphone, mobile tablet, etc) and platforms (eg, iOS, Microsoft, and Android) as well as future mobile platforms. | 11 (92) | 0 (0) | 1 (8) |
The Mobile Device Translation Layer FHIRf Interface supporting implementation of various mobile devices and platforms (eg, iOS, Microsoft, Android) is necessary within the mHeRIF architecture. | 10 (83) | 0 (0) | 2 (17) |
Inclusion of the Integrating the Healthcare Enterprise (IHE) profiles within the mHeRIF architecture could enhance interoperability of mHealth solutions and eRecord systems. | 9 (75) | 0 (0) | 3 (25) |
The “Mediator” service of the HIEg handling queries and responses between different database systems and resolving complex orchestration of communications between multiple mHealth solutions and eRecord systems is appropriate within the mHeRIF architecture. | 10 (83) | 0 (0) | 2 (17) |
Use of telecommunication technologies (eg, SMS, USSDh, voice, etc) should form a part of the mHeRIF architecture. | 9 (75) | 0 (0) | 3 (25) |
The Case Notification Service (CNS) responsible for sending bidirectional medical case notifications across mHealth and eRecord systems, for example, when a new case is registered using the mHealth solution and resolved through the eRecord system (eg, an EMRi) is appropriate within the mHeRIF architecture. | 10 (83) | 0 (0) | 2 (17) |
The HL7j FHIR standard in the mHeRIF architecture is ideal for linking mHealth solutions to eRecord systems. | 11 (92) | 0 (0) | 1 (8) |
ISOk/IEEEl 11073 standards within the mHeRIF architecture are ideal to support interoperability of mHealth solutions and eRecord systems. | 7 (58) | 0 (0) | 5 (42) |
The Digital Imaging and Communications in Medicine (DICOM) standard is appropriate within the mHeRIF architecture. | 10 (83) | 0 (0) | 2 (17) |
amHeRIF: Mobile Health–Electronic Record Interoperability Framework.
bOpenHIM: Open Health Information Mediator.
cmHealth: mobile health.
deRecord: electronic record.
eOpenHIE: Open Health Information Exchange.
fFHIR: Fast Healthcare Interoperability Resources.
gHIE: health information exchange.
hUSSD: Unstructured Supplementary Service Data.
iEMR: electronic medical record.
jHL7: Health Level 7.
kISO: International Organization for Standardization.
lIEEE: Institute of Electrical and Electronics Engineers.
Governance and regulation
“Issues of investment should be covered to detail how funding for the projects will be sustained” (Expert 1; Botswana).
“An investment case through donor funding or PPP arrangements could be suggested for low income countries” (Expert 1; Botswana).
“It places it at the top and all encompassing from left to right—Author may wish to make it the largest rectangle containing all of the other boxes inside (ala COBIT 2019)” (Expert 7; low- and middle-income country [LMIC] outside sub-Saharan Africa [SSA]).
Interoperability standards
“Yes for now, but the mHeRIF design should accommodate for a standard component not necessarily tightly coupled to HL7 FHIR” (Expert 4; LMIC within SSA).
“In principle, I would say yes, however this is not my area of expertise. I have a feeling that depending on the architectural approach, it is not necessarily the role of the exchange to support a wide range of third-party systems. Rather, I believe an approach is for the exchange to expose APIs and publish communication standards/protocols using open standards and then it is the responsibility of the third-party systems to do the work to be able to communicate with the exchange. You may want to check this to make sure I’m not talking nonsense” (Expert 5; LMIC within SSA).
“I don’t see ‘IHE Profiles’ mentioned anywhere in the figure. Might be good to add it” (Expert 5; LMIC within SSA).
“The author is also referred to ISO TR 14639 as another target state for eHealth architecture” (Expert 7; LMIC outside SSA).
eHealth software and infrastructure
“Consider just using the more encompassing and standard term ‘digital health’ and then differentiate their delivery methods and tool such as online/offline (including on-premise/cloud), hardware device such as mobile devices, etc” (Expert 4; LMIC within SSA).
Telecommunication technologies such as SMS text messaging, Unstructured Supplementary Service Data, and voice “...could be independently mapped by an outer layer in the mobile device/interface” (Expert 10; high-income country).
Security, privacy, and confidentiality
“I like the place that ‘Security, privacy and confidentiality’ are shown, and I believe these are extremely important. I would not put include ‘Legislation’ where it is. The legislation is already covered under the regulation part of ‘Governance and Regulation.’ Also the role of Security, privacy and confidentiality here are not to engage with or produce the legislation but rather to put practical, technical measures in place that fulfil the requirements of the legislation that is already mentioned in the heading ‘Governance and Regulation’” (Expert 5; LMIC within SSA).
Usability
“I suggest you align the position and design of the parts of figure 1 and figure 2. This will make the logic easier to follow. For example, security is on the right in Fig 1 and on the left in Fig 2. Audit also moves as do the HIE components” (Expert 5; LMIC within SSA).
“The framework needs to be further simplified” (Expert 6; LMIC within SSA).
“There are other aspects such as AI [Artificial Intelligence] and HCI [Human-Computer Interaction] not explicitly provided for” (Expert 10; high-income country).
“Perhaps there should be also some user/patient layer?” (Expert 10; high-income country).
Unique patient identifier
“In your figure, is there a master patient registry as a component of the Exchange? If so, I would leave the UPI there, and not repeat it, and all systems in the ecosystem would use that UPI” (Expert 5; LMIC within SSA).
Miscellaneous comments
“The word ‘levels’ makes me visualise 4 horizontal levels, one above or below the other, rather than the 4 verticals in the diagram. Next, these four ‘levels’ are divided into six ‘sub-layers,’ and I wonder why the word ‘level’ is now replaced by the word ‘layer,’ though my guess is that the ‘sub-layers’ are one hierarchical step below the ‘levels.’ This is a bit confusing when reading it. And once again, the word ‘layers’ makes me imagine six horizontal layers rather than the six vertical ones” (Expert 5; LMIC within SSA).
Revised Mobile Health (mHealth) to Electronic Record (eRecord) Systems Interoperability Framework for Botswana presented “primarily” from an enterprise architecture perspective. CSV: comma-separated values; DICOM: Digital Imaging and Communications in Medicine; HL7 FHIR: Health Level 7 Fast Healthcare Interoperability Resources; HWR: Health Worker Registry; ICD-10: International Classification of Diseases, 10th Revision; ICT: information and communications technology; IEEE: Institute of Electrical and Electronics Engineers; IHE: Integrating the Healthcare Enterprise; ISO: International Organization for Standardization; LOINC: Logical Observation Identifiers Names and Codes; MFL: Master Facility List; MPI: master patient index; NHIE: national health information exchange; PHD: Personal Health Data; SHR: Shared Health Record; SNOMED-CT: Systematized Nomenclature of Medicine–Clinical Terminology; SSL: Secure Sockets Layer; TLS: Transport Layer Security; TR: Technical Report; UPI: unique patient identifier.
With respect to the “Governance and Regulation” theme, 17% (2/12) of the experts (expert 7, LMIC outside SSA, and expert 1, Botswana) made 3 suggestions. Expert 7 suggested that this should be the largest theme and contain all other themes, whereas expert 1 suggested the adoption and inclusion of sustainable funding or investment models suited for LMICs. The recommendation of expert 7 was adopted, and the rectangular shape for “Governance and Regulation” was extended to cover all other themes (
Regarding the “Interoperability Standards” theme, 25% (3/12) of the experts made 4 suggestions. No changes were made as a result of the suggestion to make the mHeRIF accommodate non–Health Level 7 Fast Healthcare Interoperability Resources standards as the framework already suggests other standards (eg, the International Organization for Standardization and Institute of Electrical and Electronics Engineers 11073 and Digital Imaging and Communications in Medicine). However, suggestions to consider the International Organization for Standardization Technical Report 14639 standard and the inclusion of “IHE Profiles” were adopted and reflected within the mHealth and eRecord standard and the national HIE themes, respectively (
For the “eHealth Software and Infrastructure” theme, 17% (2/12) of the experts made 1 suggestion each. These were to use the term “digital health” as opposed to
Regarding “Security, privacy and confidentiality,” 8% (1/12) of the experts provided a suggestion. This was to remove “Legislation” as it is already covered under the “Regulation” part of the “Governance and Regulation” component. The premise is debatable—regulations may have no legal standing. Regardless, there will be specific legislation that will affect mHealth and eRecords that must be recognized and considered. To accommodate this issue, a change was made by renaming the “Legislation (Security, Privacy and Confidentiality)” theme (rightmost cross-cutting theme initially) to read “mHealth/eRecords specific legislation (Security, Privacy and Confidentiality)” (
Only 1 suggestion was made regarding the enhancement of the “Unique Patient Identifier” theme. After consideration, no change was made to the mHeRIF. Given that it is almost impossible to have a perfect universal master patient index (MPI), especially within LMICs, it might be more appropriate to enforce the uniqueness of patient records at the individual system level.
A miscellaneous comment was considered overarching and not specific to any theme as it highlighted a general concern over some terminology used within the framework. However, the terms applied were chosen as they were in alignment with terms commonly used in the literature (eg, Refined eHealth European Interoperability Framework). No adjustment of the mHeRIF was considered necessary.
Overall, eHealth experts showed general agreement with the structure and components of the mHeRIF (
Although other interoperability frameworks exist, the overall contribution of the mHeRIF is that it extends the generic and adaptable framework to different country contexts. Similar to the mHeRIF, the OpenHIE specifies mobile devices as an exemplar “point of service application.” However, importantly, the mHeRIF further highlights other considerations (eg, mHealth security and transport standards, data formats and database models, and governance and regulatory considerations) for linking mHealth apps to eRecord systems. These are key for countries seeking to link mHealth apps to other eRecord systems.
As a conceptual framework, the mHeRIF identified core components and themes by arranging them in a logical structure to provide a visual display of how each relates to the others. Therefore, it is essential that the mHeRIF’s components be interpreted in totality and not in isolation. However, the mHeRIF is not prescriptive in terms of what LMICs such as Botswana should do. The first mobile telemedicine initiative to be considered at a national scale in Botswana, the Kgonafalo program [
In this study, eHealth experts also contributed important considerations for the improvement of the mHeRIF, and these were categorized according to six themes (
The recent WHO Global Strategy on Digital Health (2020-2025) [
Considering that all experts (12/12, 100%) indicated that “fundamental ‘mHealth-eRecord’ standards for interoperability are essential components within the mHeRIF” (
The WHO Global Strategy [
According to the WHO Digital Health Platform handbook, the HIE should build upon a country’s national eHealth strategy or similar digital health road map and use a requirement-gathering process to determine which applications and components are needed to realize national objectives [
The need for a UPI was highlighted by most experts (9/12, 75%;
Security, privacy, and confidentiality issues were considered important components of the mHeRIF by all eHealth experts in this study (12/12, 100%;
Several comments were made pointing to “usability” of the mHeRIF. An expert even suggested the inclusion of a
A few negative responses were also noted, mostly related to the experts’ lack of knowledge of Botswana-specific policy documents. There were also differing interpretations of the framework’s intent. For example, an expert from an LMIC within SSA expected the mHeRIF to function as an interoperability model versus a framework. However, the terms “model” and “framework” are not considered synonymous. Both are simplified visual tools intended to describe but not explain. However, a “model” portrays something more definitive (often a physical representation) to be used as an example to follow or imitate closely and that simplifies the
Interestingly, some seeming contradictions identified a potential issue. An expert (expert 7) from an LMIC outside SSA gave a “No” response to question 12 (“The mHeRIF (
The mHeRIF was considered essential by most eHealth experts in this study (9/12, 75%;
There were few eHealth experts to choose from with the requisite knowledge of interoperability concepts. Furthermore, the mHeRIF does not provide finer technical details for implementation but, rather, offers guidance on key considerations for linking mHealth apps to eRecord systems. This was considered a limitation by an eHealth expert from a high-income country but is in alignment with the concept of a “framework.” Finally, there is no national experience of linking mHealth apps to eRecord systems in Botswana, necessitating empirical testing of the mHeRIF.
The mHeRIF provides an opportunity to enhance the Botswana National eHealth Strategy by informing the linking of mHealth apps to existing eRecord systems, an essential component of the “Standards and Interoperability” pillar within the strategy. The framework will inform implementation approaches while considering all essential components, standards, and varying infrastructure needs, hence reducing the failure rates of most mHealth and eRecord initiatives in Botswana. Given the absence of a national framework for linking mHealth apps to the eRecord system in Botswana, this gap has been filled by introducing the mHeRIF—which is intentionally generic in its design. Considering its generic nature, the mHeRIF may require adaptation to suit varying use-case scenarios within Botswana and elsewhere. The mHeRIF and its exemplar architecture model were validated by eHealth experts, and their suitability in the context of Botswana was confirmed. The study findings offered valuable insights and suggestions for enhancing the mHeRIF. Further studies could confirm its efficacy in ensuring the linking of mHealth apps to eRecord systems as the mHeRIF is applied in Botswana.
National eHealth Strategy, digital health platform architecture published by the International Telecommunication Union.
Original Mobile Health–Electronic Record Interoperability Framework.
mHeRIF Explanatory Notes.
electronic health record
electronic record
health information exchange
low- and middle-income country
mobile health
Mobile Health–Electronic Record Interoperability Framework
master patient index
Open Health Information Exchange
Research Electronic Data Capture
sub-Saharan Africa
unique patient identifier
World Health Organization
The authors would like to acknowledge the Fogarty International Center of the National Institutes of Health for their financial support. The research reported in this publication was supported by the Fogarty International Center of the National Institutes of Health under award D43Tw007004–13. The funding agency had no role in the study design, collection or analysis of the data, data interpretation, or writing of the manuscript. The content is solely the responsibility of the authors and does not necessarily represent the official views of the National Institutes of Health.
The data collected and analyzed during this study are available from the corresponding author upon reasonable request.
KN, RES, and MM conceptualized and designed the study. KN collected the study data, and all authors contributed to data analysis. KN wrote the initial manuscript, and all authors contributed to subsequent revisions. All authors approved the final manuscript.
None declared.