Keywords

1 Introduction

Noncommunicable diseases (NCDs) represent one of the most formidable 21st Century public health challenges. As the worldwide infectious disease burden dwindles (thanks to modern medical advancements) and lifestyles adapt to globalization, NCDs will account for an increasingly large percentage of overall morbidity and mortality. NCDs (diabetes and hypertension in particular) were implicated in 80% of deaths in pre-conflict Syria (ca. 2010) [Sethi], and these problems persist even as the Syrian people face violence, displacement, and other consequences of war. Indeed, while the international media and medical communities remain keenly attuned to the conflict-related health concerns of Syria and other war-torn populations, little attention is paid to the relatively more “mundane” ravages of noncommunicable diseases.

Over the past several years, mobile health (“mHealth”) interventions have been touted as a possible means of delivering care to vulnerable and underserved populations, and there has been a great deal of evidence to support the efficacy of such tools in improving health outcomes along a variety of axes. An mHealth intervention in Somalia helped diagnose conditions that would have otherwise gone unnoticed in 25% of children participating in the study [Zachariah]. A digital nutritional questionnaire in Burma was similarly impactful [Selanikio]. Several studies conducted in among Palestinian refugees in Jordan used electronic medical records and cohort monitoring to improve diabetes and hypertension outcomes [Khader].

Sana is a cross-disciplinary organization, including clinicians and engineers as well as policy, public health, and business experts along the entire healthcare value chain. Hosted at the Laboratory for Computational Physiology at MIT’s Institute for Medical Engineering & Science, the Sana Project G Team—in conjunction with the International Rescue Committee and the Johns Hopkins Bloomberg School of Public Health—has devised a patient-controlled health records (PCHR) app that will allow physicians to monitor and impact their patients’ long-term health outcomes. Currently the only known mHealth tool for noncommunicable disease (NCD) management targeted towards gatekeepers in health care, the Sana.PCHR application has shown promise during its development in Lebanon. We intend to implement this technology solution in close collaboration with front-line healthcare workers, patients, local governments, and humanitarian organizations, so as to better understand the on-the-ground populations we are seeking to serve.

2 Methods

The Sana.PCHR app provides disease management guidelines as well as intuitive protocols for patient data storage. This application serves as a decision-making support tool for healthcare providers, thus promoting treatment adherence and ensuring a high quality of care. Patient-oriented outputs, such as printed reminders of a treatment regimen or daily text messages recommending behavioral changes, are also generated and delivered free of charge to patients. This is a particularly valuable component of NCD treatment, since many noncommunicable diseases depend heavily on lifestyles and personal habits. According to a recent article in the journal Science, “The United Nations Secretary-General’s report on prevention and control of NCDs is remarkably clear in recommending that ‘the greatest reductions in noncommunicable diseases will come from…population-wide interventions’ that address the risk factors of tobacco use, unhealthy diet, lack of physical activity, and harmful use of alcohol” [Chokshi]. The Sana.PCHR app also allows healthcare workers to avoid the hassle of maintaining paper records, which are unwieldy, error-prone, and susceptible to loss, damage, or disarray.

The Team: The Sana Research group is headquartered in the Laboratory for Computational Physiology at MIT’s Institute for Medical Engineering & Science. The Sana.PCHR team is comprised of students from the Harvard T. H. Chan School of Public Health and the Harvard-MIT Health Sciences and Technology Division. Other key partners include the Johns Hopkins Bloomberg School of Public Health and the International Rescue Committee (which provide support on the ground in our target locations), as well as students at the University of Waterloo (who are responsible for the technological implementation of the app).

Development Timeline: The first phase of product development and testing is slated to occur within 21 months of the project’s commencement. Below is a more detailed breakdown of the individual tasks and their estimated durations.

  • Months 0–6: The Sana.PCHR application will be iterated and optimized using available guidelines and inputs from country-based healthcare providers. At the same time, data on existing noncommunicable disease treatment will be collected at local healthcare facilities for comparison purposes.

  • Months 7–8: Frontline healthcare workers will be trained to use the app, which will be subsequently deployed in selected health care facilities.

  • Months 9–21: Use of the application will be monitored and supported by MIT Sana and JHU, and modifications made as needed. Related data will be collected for research purposes.

Website: Our team has developed a website to showcase our ongoing progress on the Sana.PCHR application. Hosted on a Wix platform, the site is accessible via the following https://sanapchr2018.wixsite.com/projectg.

2.1 Product Specifications

The Project G Group was responsible for drafting the product specifications, which will ultimately be sent to our partner cohort of software developers at the University of Waterloo for implementation. For the purposes of this deliverable, we will adhere to the standard “product specs” format used widely throughout the software industry.

Problem: Succinctly stated, our team has been tasked with the responsibility of building a product that will store a patient’s clinical data from visit to visit, with new healthcare information added at each physician interaction. In software engineering terms, this boils down to maintaining a database of patients and their associated information for each user of the app (i.e. healthcare provider).

Features and Functional Requirements:

  • Maintains a database of care providers for each healthcare facility, each with his or her own login information (via secure authentication protocols)

  • Maintains a database of patients for each care provider

  • Fully operational offline

  • Syncs data to the cloud once a network connection is available

  • Interoperability with a backend web interface for data analytics.

Workflow:

See Fig. 27.1.

Fig. 27.1
figure 1

High-level workflow

  1. (1)

    Log-in: The user can access his/her profile either with a username and password or through a QR code scan (see Fig. 27.2a). Possible actions:

    Fig. 27.2
    figure 2

    a Log-in, b Welcome

    • Log in with password

    • Log in with QR code.

  2. (2)

    Welcome: Once logged in, the Sana.PCHR welcome screen will appear, prompting the user to either access an existing patient profile or generate a new one (see Fig. 27.2b). Possible actions:

    • Add new patient

    • Access existing patient data.

  3. (3)

    Add New Patient: The Add New Patient screen will prompt the care provider to upload details of the patient’s medical history (see Fig. 27.3a). Possible actions:

    Fig. 27.3
    figure 3

    Add new patient and enter medical history

    • Input patient demographic data

    • Cancel entry and return to previous screen

    • Validate entry and proceed.

  4. (4)

    Enter Medical History: This portal will allow the physician to register the patient’s chief complaint, record previous diagnoses and medical problems, and flag any family histories of disease (see Fig. 27.3b). Possible actions:

    • Input medical history data

    • Cancel entry and return to previous screen

    • Validate entry and proceed.

  5. (5)

    Access Existing Patient Data: This portal will pull up the patient’s medical history, recorded during a previous session. Possible actions:

    • Return to previous screen

    • Proceed to the recording of clinical observations.

  6. (6)

    Record Clinical Observations: The physician can enter new physical measurements and clinical observations as well as record lab test results. Possible actions:

    • Input clinical measurement/observation data (see Fig. 27.4a)

      Fig. 27.4
      figure 4

      Record clinical observations

    • Input laboratory test results (see Fig. 27.4b)

    • Cancel entry and return to previous screen

    • Validate entry and proceed.

  7. (7)

    Adjust Treatment Plan: Here, the physician can make changes to existing treatment recommendations and medications (see Fig. 27.5a). She can upload a new prescription to the patient’s record, recommend lab tests following the consultation, add referrals to an external care provider, or recommend a return visit. Possible actions:

    Fig. 27.5
    figure 5

    Adjust treatment plan

    • Add advice item (see Fig. 27.5b)

    • Add prescription item (see Fig. 27.5c)

    • Add test recommendation item (see Fig. 27.5d)

    • Add referral item (see Fig. 27.5e)

    • Add follow-up appointment item (see Fig. 27.5f, h, g)

    • Cancel entry and return to previous screen

    • Validate entry and proceed.

  8. (8)

    Finish and Print: Finally, the healthcare provider can confirm the visit details she has just input and print the resulting electronic medical record (presuming printing facilities are available). Possible actions:

    • Continue editing medical history, clinical observations, or recommendations

    • Finish and finalize the assessment

    • Print the medical record.

  9. (9)

    Send Ongoing Treatment Reminders: Throughout the patient’s treatment, he will receive free text-message alerts about any upcoming follow-up appointments, medication management, and behavioral “nudges” that will help mitigate or forestall the effects of NCDs. Thus, data within the patient’s record should trigger a scheduling protocol that sends automated messages at predetermined intervals.

At any point throughout this workflow, the patient has the capacity to log out or sync their data with the underlying cloud-hosted database, should an internet connection be available.

Use Cases: We can explore hypothetical use cases by considering each possible stakeholder/actor and imagining their interactions with the app.

Actor

Scenario

Requirements

Individual care provider

A care provider wants to log into her account and access or amend existing patient data, so as to assess the patient’s disease progression

Each care provider has her own account with her own database of patients, whose data is stored securely and diachronically

Patient

A patient visits a different clinic and wishes to bring his treatment records along

Patient records should be centralized so that they follow a given patient through the local healthcare system

Local clinic

A clinic coordinator wants to track how many patients have been presenting with a particular set of complaints in the past year

Clinics should have access to high-level analytics about the patients that have visited their facility

Government

A national public health official wishes to track any changes in NCD incidence after the implementation of a new policy

Government partners (if authorized) should have access to high-level, anonymized data about disease progression

Humanitarian Organization

An international NGO wants to calculate the overall incidence of NCDs in a given locale, so as to allocate resources accordingly

Aid organizations should also have access to overall data trends

System Requirements: We have selected Android as our app development platform, given the wide availability of Android-driven devices in the developing world.

Graphic Design: We generated mock-ups of our application, representing the various possible program states as seen in Figs. 27.2, 27.3, 27.4, 27.5 and 27.6. This design will be iterated in conjunction with our colleagues at the University of Waterloo.

Fig. 27.6
figure 6

Finish and print

3 Results

Proposed Impact: We anticipate that the Sana.PCHR app will improve health outcomes along four key axes. Our technology seeks to enhance:

  1. (1)

    The overall quality of noncommunicable disease care by promoting adherence guidelines, both during patient-doctor interactions and throughout the patient’s longitudinal treatment;

  2. (2)

    Care coverage by supporting lesser-trained providers in lower-resource settings during care delivery;

  3. (3)

    Continuity of care by maintaining patient-specific information that can smooth transitions between healthcare providers; and

  4. (4)

    Data analytics so that in the long term, humanitarian organizations can apply machine learning to improve operations and outcomes.

So far, testing has been conducted among roughly 800 Syrian refugees in primary care settings in Lebanon [Doocy].

Monitoring and evaluation of the application will be conducted throughout the development process. The Sana.PCHR tool will upload data to the cloud during use (presuming an active network connection), enabling us to collect crucial data for impact assessment. Qualitative data will be acquired through interviews, abiding by the guidelines of the Lean Research Framework (developed by the MIT D-Lab, the Feinstein International Center, and the Fletcher School of Law and Diplomacy) [Lean]. Country-specific outcomes will be evaluated according to the following metrics:

  1. (1)

    Number and type of providers using the application.

  2. (2)

    Provider retention rates.

  3. (3)

    Number of consultations per provider.

  4. (4)

    Completeness of records and management (in accordance with guidelines provided by partner humanitarian institutions).

  5. (5)

    Health outcomes (disease control, risk categories) if feasible.

  6. (6)

    Patient perceptions of application and benefits (if any).

Longer-term results will be evaluated as follows:

  1. (1)

    Number of organizations using the application.

  2. (2)

    Number of countries where the application is in use.

  3. (3)

    Number of NCD patients benefiting from the application.

  4. (4)

    Awareness of and feedback from the stakeholders (e.g. patients, care providers, last-mile health facilities, local NGOs, government partners, and international humanitarian organizations).

4 Discussion

Technology is not a panacea, and clever apps alone will not solve all the world’s global health challenges. Far too often, resources are indiscriminately thrown at problems without a holistic understanding of what really works in a given context. Furthermore, technology cannot simply be transferred wholesale from developed countries to resource-limited settings; solutions that work in one context usually need to be adapted to suit the needs of another locale.

This is especially important when considering the different contexts in which the Sana.PCHR app will be used. While community health workers in Syria have a long history of managing chronic NCDs such as diabetes and hypertension and may be able to refer their patients to primary and secondary centers without outside guidance, community health workers in conflict settings such as the Democratic Republic of Congo are not as familiar with these diseases, and may therefore use Sana.PCHR as a medium through which to track lifestyle and behavioral changes. It will be important to consider the nature and purpose of the application in different contexts as we proceed with the scale-up of Sana.PCHR.

Sana.PCHR provides an innovative tool with which community health workers and physicians can manage complex, chronic diseases in a transient and dynamic patient population. It is widely known that diseases such as hypertension and diabetes mellitus are difficult to manage even in stationary populations with established primary care physicians, and management of such diseases requires special considerations among refugee populations in conflict scenarios. With the development of Sana.PCHR, we hope to provide healthcare providers in different scenarios with a streamlined approach for accessing and modifying a patient’s medical records, in order to provide patients with the best possible care, even in non-traditional and transient settings.