Stanford University



Nectar: Extensions to ButterflyNet for Rural Patient Data Collection

Dhyanesh Narayanan

CS376 Project Milestone 1

dhyanesh@cs.stanford.edu

Abstract

This document presents Nectar, a system that motivates the use of ButterflyNet in Health Care applications, specifically in the context of patient data collection from remote rural areas of developing countries such as India. A suitable case in point would be “Village of the Month” programs organized by Indian hospitals in which a specific village is chosen for survey to collect indicative health parameters from villagers. During such visits, doctors face certain key pain-points: simple & rapid acquisition of rural patient data, reliable & consistent transfer of the acquired data to the Hospital Patient Information System, intelligent post-processing of collected data, and maintenance of patient records for future retrieval & analysis. Nectar leverages and complements the ButterflyNet infrastructure to target these specific pain-points, thereby increasing the efficiency of Village of the Month programs and helping hospitals to capture and analyze rural patient data more intelligently & effectively.

1. Introduction

Indian hospitals organize “Village of the Month” programs in which a specific village is chosen for survey to collect indicative health parameters from villagers. The collected data has to be consolidated and acted upon for gauging village health conditions and taking suitable measures. In addition, the data has to be maintained over time in the Hospital Patient Information System (PIS), for future retrieval and analysis.

2. Existing Pain Points

During visits to villages as part of the Village of the Month program, doctors and medical professionals face the following key pain-points.

2.1 Simple, Rapid, Dependable data-collection

Typically, a specific building in the village (like the Panchayat Office) is selected as a location for the Village of the Month program to be conducted. Villagers queue up at booths where hospital officials interact with them and gather indicative patient data.

However, the information is gathered in an adhoc manner in the form of rough notes with pen and paper. The health official experiences significant cognitive overhead in asking the questions in the first place; he has to make sure that the villager (who is mostly illiterate) understands his questions and may sometimes need to speak with the villager in vernacular. Also, since the villager would likely get annoyed if asked to repeat some piece of information or may not repeat it with the same level of accuracy as the first time s/he said it, the health official has to be really quick in jotting down the points. To achieve this, the official may need to resort to some cryptic short forms, which when looked at later may not be understood by the official himself.

Moreover, some of the notes made by doctors may be lost before they are brought back to the hospital for entry into the Hospital PIS. It is more often the case that notes get damaged because they may get accidentally dropped on muddy ground, drenched in rain etc (typical of village settings).

Thus there is a huge pain point in terms of just gathering the data in a simple, fluid, rapid and dependable manner. Also, this data has to be in an intelligible form when analyzed at the end of the day; the health official should be able to make out unambiguously what he has noted about a patient.

2.2 Reliable, Consistent transfer of collected data to PIS

This process is typically done manually. The health officials finish their visit to the village and return to the hospital with a roster of notes containing the observations they made in the village. Then, each official physically goes through each note he had made and feeds the data into the PIS. There are a couple of serious problems associated with this model:

• This is highly inefficient, roughly doubling the time spent per patient and slashing individual productivity by half

• It is highly error prone – If the official makes an error in interpreting a note he had made earlier (likely because it is cryptic), not only can it introduce an error in the diagnosis of the patient in question but will also hamper the overall gauging studies that the health officials plan to do for the entire village.

An alternate model is employing an assistant to perform the data entry. This model also has a severe disadvantage because the notes that are made are hardly structured/clear. So the assistants might frequently have to seek clarifications about the notes with the health official who made the notes. This can be a pain for the health official and can cause the assistant to stall, waiting on the health official, if the latter is unavailable for some reason. Repeated clarifications and unavailability can lead to a tendency where the assistant may likely start guessing what the health official might have meant by a piece of his notes. This is a recipe for disaster and one wrong interpretation can spin off a series of erroneous diagnosis and results, which would be very difficult to backtrack.

The consistency of the data transfer process is also a major issue. When the health official makes notes in the village, he hardly remembers the schema and data types of the PIS database. He may make notes that are related to the PIS schema, but during actual data entry, a high amount of disambiguation is required and data type inconsistencies, schema variations have to be reconciled manually. This again calls for active participation of the health official in the data transfer process, the disadvantages of which have already been discussed.

2.3 Perform Intelligent Post-processing on Collected Data

Once we have got the data into the PIS, it needs to be analyzed in an intelligent manner so that individual villagers can be offered treatment/prescriptions, and overall descriptive statements can be made about the health status of the village. Such population studies provide useful insights into prevalence of endemic diseases. In addition, they are rich inputs for demographic studies of health conditions in various regions of a vast country such as India. Based on the results of such studies, hospitals can gauge the health conditions in villages and can tailor their preventive/corrective health measures and programs appropriately. It can also provide directions on how to budget a fixed amount of health relief funds across multiple villages.

Since the data is gathered in an adhoc manner and the entry process of the collected data into the PIS is also inefficient and error prone, there is successive loss of information at each step of the operation, in terms of data type reconciliation, schema reconciliation etc. Hence, the data is not rich enough for active post processing and rarely yields any useful results.

2.4 Maintain Collected Data for Future Retrieval & Analysis

Usually hospitals round-robin through a collection of villages. Hence it is useful to keep the data gathered in earlier visits to a village and take a look at it again when officials revisit the village. This would help in comparing and studying whether the health conditions have improved/remained same/deteriorated over time. Suitable actions can be taken based on these observations. In addition, such comparative studies help the hospitals gauge the effectiveness of any health programs they may have launched in the village based on their earlier visit. However, the data that makes it into the PIS is not rich (as explained earlier). So, between successive snapshots of the data about a particular village, there is not much useful inferencing that can be made.

3. Nectar: Extensions to ButterflyNet for Rural Patient Data Collection

|[pic] |

|Figure 1: Nectar Architecture |

Nectar leverages and extends the ButterflyNet infrastructure to target the aforementioned pain-points. Nectar entails the use of a Pocket PC to gather data during surveys in villages. Doctors use a simple interface on a handheld Pocket PC, to quickly fill out key details for each rural patient they screen. The data is stored locally on the Pocket PC, and synchronized with the PIS in batch mode. The PIS data can be aggregated & mined to extract descriptive information on village health conditions & suitable health measures can be taken.

3.1 Architecture

Nectar is built to leverage the ButterflyNet infrastructure and is consequently architected as a two-tier system viz. the Pocket PC Front End and the Hospital Back-End. These components are explained below:

1. Pocket PC Front End: This component of Nectar is built as consisting of three sub-components:

1.1 Nectar Data Capture Interface: The Nectar Data Capture Interface provides the necessary UI to gather indicative rural patient data. This interface is intended to be convenient and intuitive, whilst making optimal use of the limited real estate available on the Pocket PC.

1.2 Nectar Local Store: Nectar Local Store is an efficient local store on the Pocket PC, of the information obtained on the Nectar Data Capture Interface. It comprises database table(s) with a schema suited to store indicative rural patient data. The Nectar Local Store is intended to be a robust, feature-rich mobile database with a relatively small footprint.

1.3 Nectar XML Web Service Client: In order that the patient data stored in Nectar Local Store be meaningfully analyzed and subsequent treatment to villagers be provided, it is necessary that this data be synchronized with the Patient Information System of the hospital. Nectar provides a XML Web Services-based mechanism for this purpose through a XML Web Service made available on the hospital server (as we shall discuss soon). The Nectar XML Web Service Client is a client of this XML Web Service and runs on the Pocket PC. In batch mode, the Pocket PC can dial up to the Internet, make a call to the XML Web Service running in the hospital servers and upload the rural patient data.

2. Hospital Back-End: This component of Nectar is built as consisting of the following two sub-components:

2.1 Nectar XML Web Service: As mentioned earlier, Nectar provides a XML Web Service based solution for synchronizing rural patient data gathered on the Pocket PC with the Hospital Patient Information System. Nectar XML Web Service is the XML Web Service which runs on the hospital server and enables the Pocket PC to upload the rural patient data.

2.2 Hospital Database: The Hospital Database is the persistent store at the hospital site which houses the data for the Patient Information System. The rural patient data obtained from the Pocket PC is stored in this database for further analysis by the doctors. Once the data is analyzed, suitable treatment can be offered to the villagers.

4. Implementation Plan

The motivation for Nectar stems from a similar effort undertaken by the author in 2003 called Rural Data Capture System (RDC). RDC was a minimal functional prototype built as part of a health care application suite (), using requirements gathered from doctors at IIT Madras Hospital (India). Nectar is the result of rethinking RDC system design for complete leverage and full-fidelity integration with the ButterflyNet infrastructure.

4.1 Requirement Analysis

The user base of Nectar would essentially consist of the doctors & health officials who go on Village of the Month programs. There are two basic set of requirements that need to be gathered:

- What is the data to be captured during a survey?

- How would the user ideally like a tool to help in the data collection process?

Fortunately, both these classes of requirements can be elicited from the same set of people viz. the health officials who conduct the survey. Not only are they informed about the domain and can give inputs on what data is critical to be gathered during a survey, but also they are the end-users of Nectar and hence can give inputs on features they would want in a system like Nectar. For example, to build the RDC prototype, inputs for both classes were gathered from the doctors in IIT Madras Hospital. The following summarizes the requirements that were gathered:

Indicative Rural Patient Data (What needs to be captured)

• First Name

• Last Name

• Age

• Sex

• Known Medicine Allergies

• Frequently faced ailments

• Blood Group

• Occupation

• Religion

• Vegetarian/Non-Vegetarian

• Description of Surroundings in the place where he lives

• Current Ailments

• Bowel/Bladder Habits (Regular/Irregular/Occasionally problematic…)

• Food Habits (Balanced Diet/Impoverished Diet/Regular/Irregular…)

• Regional Diseases that he has seen prevalent in the village

• Smoking Habits

• Drinking Alcohol

• Short Family Medical History (such as whether parents had diabetes/asthma etc)

Feature Wish List (How should a tool help)

• Convenient data entry

• Quick data entry

• Easy to use interface requiring minimal learning

• Easy integration with Hospital/individual workflow

• Responsive UI (the last thing you want when you are doing a health survey on a rainy day in a village filled with mosquitoes is a frozen UI)

• Easy and reliable synchronization with Hospital PIS

• Helpful messages to signal success/failure of operations

4.2 Software Design Methodology

As far as building the system goes, a Spiral Model of software development would be appropriate. While the functional architecture can be frozen to a reasonable extent in round 1, the UI requirements including interface templates, choice of UI widgets, their positioning etc. needs to be decided in multiple iterations driven by usability studies with focus groups of health officials on prototype implementations. Not only would this yield useful inputs on designing a fluid and easy to use interface, but would also enable semantic aggregation of relevant data that needs to be gathered and hence provide a pointer to schema design for the local data store.

4.3 Nectar Data Capture Interface Design

Nectar System Design has been highly user-driven and focused on adding efficiency to an existing task that health officials routinely perform. An important point to be borne in mind when designing a system like Nectar is that it is a replacement technology – the user would always compare the new system with what he was using earlier and if he finds the new system even slightly annoying and getting in the way, he would revert back to the old system. Thus the new system has to provide significant advantages for the user to decide to switch over. Nectar has been expressly designed with this lesson in mind. Accordingly, considerable effort has to be dedicated for designing the UI for the health official or more specifically the Nectar Data Capture Interface.

Beginning with the requirements gathered in the Requirements Analysis phase in Section 4.1, the requirements relevant to the UI are as follows:

• Convenient data entry

• Quick data entry

• Easy to use interface requiring minimal learning

• Responsive UI

• Helpful messages to signal success/failure of operations

A closer look at the above requirements highlights that much of the interaction with Nectar is in terms of data rather than control – there just two control actions: one to commit the data to the local store and other to synchronize the data with the Hospital server at the end of the day. It is hence a better design choice to focus more on the data and build a data-centric UI rather than a task-centric UI. The following discussion is driven by this design choice and presents the UI design involved in Nectar.

• Convenient and Quick data entry: To make for convenient and quick data entry, a smart design decision would be to group together the patient data to be gathered, into semantic clusters that localize to a particular bunch of data about the patient. This would enable minimal cognitive overhead in filling out details relevant to one semantic cluster whilst enabling a simple direct jump to another cluster once finished with the current cluster. This is easier for the official on the field rather than gathering the data in some random order.

Revisiting the Indicative Rural Patient Data that needs to be captured in Section 4.1, the following semantic clusters can be identified:

|Cluster 1: Personal Information |Cluster 2: Related Information |

|First Name |Religion |

|Last Name |Vegetarian/Non-Vegetarian |

|Age |Description of Surroundings |

|Sex |Regional Diseases that the patient has seen prevalent in the |

|Blood Group |village |

|Occupation | |

|Cluster 3: Habits Information |Cluster 4: Medical Information |

|Bowel/Bladder Habits (Regular/Irregular/Occasionally |Frequently faced ailments |

|problematic…) |Current Ailments |

|Food Habits (Balanced Diet/Impoverished Diet/Regular/Irregular…) |Short Family Medical History (such as whether parents had |

|Smoking |diabetes/asthma etc) |

|Drinking Alcohol |Known Medicine Allergies |

Clusters of information that need to be gather map elegantly to the tab UI widget where a set of semantically related information is grouped as a single tab and a meaningful name is associated with the tab. In addition, a tabbed interface is very appropriate in this context because it roughly quadruples (assuming 4 tabs, one each for each cluster identified above) the use of the limited real estate available on the Pocket PC. Thus a lot of useful data can be gathered in a semantically grouped manner.

• Easy to use interface requiring minimal learning: The key to ensuring minimal learning in using Nectar is to build the Nectar Data Capture Interface using components that health officials are already familiar with. Typically, any contemporary health official is conversant with using products like Word, Outlook and filling out electronic forms online. Thus they have a basic UI skill set in terms of entering text into text boxes, picking items from a dropdown list, navigating through simple forms. The Nectar Data Capture Interface will be built using these simple UI widgets so that there is minimal learning involved on the part of the health official.

• Responsive UI: Typically, one can expect that during a survey a large number of villagers are screened. With the use of Nectar, the rate at which the screening process happens will also increase considerably. Thus the Nectar Data Capture Interface must be responsive enough to handle the steady stream of patients whose data is being entered. One might consider having separate threads of execution for data capture and data storage to increase concurrency and responsiveness.

• Helpful messages to signal success/failure of operations: One of important things the health official needs to know is whether patient records are successfully committed or not. In addition, during synchronization the health official may need to know the status of synchronization process (dialing up to the Internet, connecting to the Hospital server, invoking Nectar XML Web Service, funneling the data). If there are any errors, they should be promptly reported.

Nectar provides useful dialog boxes with meaningful messages indicating status of an operation. This helps the user to smoothly cross the “Gulf Of Interpretation” [4]. In addition, progress bars and status messages are used to signal the extent of completion and current state of the synchronization process and hence the user is kept well-informed.

To handle errors, Nectar employs a consistent exception handling mechanism to propagate errors across modules in the application. Therefore if one module encounters an error, it throws an exception which can be caught by another module and appropriately handled.

5. Scale via Synchronization

Scale is a very important issue in Nectar System Design. As pointed out earlier, there are a large number of patients to be screened during Village of the Month surveys, each patient providing a considerable amount of data. With the use of Nectar, the rate at which the screening process happens will also considerably increase and consequently Nectar must be geared to handle both high volume and high throughput.

Nectar handles the issue of scale by providing a simple mechanism for synchronization. During a multi-day visit when a large volume of data is expected to be gathered, the health official can synchronize the data nightly and clean up the local store every day. It is worth mentioning that this is an interesting trade-off in Nectar system design where one decides to burn some CPU and bandwidth each day for freeing up local disk space and increasing reliability. This is enabled by the simple synchronization procedure made available in Nectar. In addition, this task makes minimal demand on infrastructure support – the bare minimum that one needs is a phone line to dial up to the Internet.

By providing a simple and easy mechanism to shed data volume acquired each day on the Pocket PC to the Hospital server, Nectar helps maintain sufficient storage on the Pocket PC for handling large volume patient screens during the survey.

6. Nectar Use Case

A typical use case would be when the medical official uses Nectar on field, to quickly fill out certain key details for each rural patient he screens. At the end of the day, the health official would synchronize the collected data with the Hospital PIS. If the survey lasts for a single day, the official can take the Pocket PC back to the Hospital and synchronize it with the Hospital PIS by connecting the Pocket PC to the hospital internal network. However, if the visit spans multiple days, it may be advisable to synchronize the data nightly. Not only would this free up local storage on the Pocket PC for data to be collected in subsequent days of the survey, but also ensure that each day of work is immediately committed to a reliable store (Hospital PIS), lest the Pocket PC accidentally gets damaged during the course of the visit and all valuable collected data gets lost. However, the health official is located in a remote rural village & has no direct access to the Hospital network. So how can the synchronization be performed?

This is where the power of XML Web Services kicks in. By designing the synchronization module on the Hospital server as an XML Web Service and the synchronization module on the Pocket PC as a client of that XML Web Service, Nectar provides a mechanism for using the Internet to funnel the data from the Pocket PC to the Hospital PIS.

An XML Web Service can be invoked by using the SOAP protocol which can itself be sent as a payload on an HTTP request. The Hospital likely has a website and would have allowed entry via its firewall to port 80 (the HTTP port) and closed all other ports for security reasons and to prevent break-ins. Since SOAP can be carried via HTTP, the Hospital server need open no other ports thus averting any potential security risks.

In addition, since the Nectar XML Web Service is callable via the Internet, all that the health official needs is a connection to the Internet. Currently there are efforts underway in Indian villages to have at least a couple of points of Internet connectivity (The Reliance Internet Kiosks are a good example). So, the health official can leverage this connectivity, hook up the Pocket PC to the Internet, and synchronize the patient data by calling the XML Web Service. Even the extreme case where such Internet connectivity is not available, the health official can simply get access to a phone line (which can definitely be assumed to be available), dial up to the Internet and funnel the data across to the Hospital PIS. Thus the Nectar System architecture is highly resilient in the sense that it makes minimal demands in terms of infrastructure support, yet delivers a full potential value add.

The user role in Nectar is dual – not only is he responsible for gathering the data on field but also responsible for using it to do some useful post-analysis at the hospital. After the survey is complete, the health officials return to the Hospital and find all the data they collected during the survey has reached before them and is available in full-fidelity Hospital PIS schema for them to start immediate post-processing. No manual transfer of data from paper-based notes, No handwriting disambiguation, No context recollection, No schema reconciliation hassles etc – Nectar simply eliminates all these hurdles so that the health official can spend his/her time more productively.

Compare this with the traditional paper-based system. As noted earlier, there were several pain points in using the traditional system. In addition, if the survey lasts multiple days, there is no immediate mechanism to ensure that the data collected each day is reliably made available at the hospital and if midway during the visit, the notes made by the officials get damaged (due to rains etc), a lot of valuable data, time and human effort is lost.

7. System Evaluation

Nectar is best evaluated against the requirements it was intended to meet. A large portion of the user requirements presented in Section 4.1 deals with providing a rich user experience. Hence, as we move along the Spiral model, we need to build prototypes, perform focus group studies using those prototypes, get user feedback on their experience in using Nectar. Users must be requested to perform data gathering using Nectar and also synchronization of the collected data with a database. The feedback obtained from this evaluation should be incorporated into the development loop.

However, it was realized that getting real user feedback from medical professionals in developing countries with Nectar prototypes might be beyond the scope of possibilities for the course project. Nevertheless, an important realization opens up an equally powerful option of simulated evaluation.

One may observe that, from an abstract point of view, it doesn’t really matter if the data being entered is rural patient data or not – its just the process of data entry in a device of small form-factor that we want to study and find out how easy/difficult health officials find that process. Consequently, one may envisage building Nectar prototypes for related tasks for which a user group is immediately available for study, for example, field-biologists who might want to perform targeted surveys and could use Nectar tools to collect and synchronize relatively structured information.

Some criteria that are appropriate for use in evaluating Nectar are:

• How convenient do the health officials/field biologists find the data entry process

• Do they feel that it improves their individual productivity as compared to a conventional paper-based system

• How rapidly are they able to enter the data

• Are there any specific points about the UI that are non-intuitive

• Is there any part of the interface which they think they can use more help with

• How fluid do they find the interaction process

• How much learning are they required to perform to use Nectar

• How easily does Nectar integrate with their workflow and individual working style

• Do they find the UI to be responsive or were there specific times/operations when it was frozen

• How easy do they find the synchronization process

• Are the dialog boxes and error messages useful – does it help the user cross the “Gulf of Evaluation” easily

• Any other general comments

8. Post-Processing of the Collected Data: A birds-eye view

The primary focus of Nectar is on improving the task of rural patient data collection and its seamless synchronization with the Hospital PIS. The post-processing that can be performed on the collected data is an interesting problem in itself and is beyond the scope of Nectar.

Nevertheless, for the sake of completeness, a short discussion of the data processing possibilities is presented below. It also highlights the role of Nectar in getting full-fidelity data across (in a form that is syntactically and semantically usable by the Hospital PIS) thus enabling the tools to perform better post-processing.

8.1 Microsoft Excel Data Cubes:

Microsoft Excel comes provides data analysis tools out-of-the-box. One interesting method for modeling data is using Excel Data Cubes. Rural Patient Data from the Hospital PIS is imported into Excel using the Data Import feature. Then data cubes can be defined to analyze the data in multiple dimensions and gain insights into trends such as distribution of different diseases in the village, gender variations of food habits etc. Such data and trends can also be pictorially studied by representing them as bar graphs, pie charts to gain better insights.

8.2 Data Mining Algorithms:

A variety of data mining algorithms can be executed on the rural patient data to gain valuable insights. For example, a typical data mining task could be to find out patterns in the data such as “All those who suffered from disease A in the village also suffered from disease B” or “All those who had habit H also had disease D” etc.

9. Related Work

[1] presents CAM, a mobile document processing system that employs a camera-equipped mobile phone as an image capture and data entry device. The TIER project [2] aims to address the challenges in bringing the Information Technology revolution to the masses of the developing regions of the world. [3] describes projects in which handheld PCs were used as data collection, management, and analysis tools.

The benefits of technology-enhanced health services are not being utilized to the fullest potential, especially in developing countries like India. This rather grim situation owes itself in part to illiteracy and general lack of awareness among the public. It is also a consequence of the relatively shallow penetration of technology into the health care sector. While health-care plans have emphasized the importance of technology in providing quality health care [5], from the point of view of what actually gets implemented, there is much to be desired. It is our belief that projects such as CAM, TIER, Nectar etc. are significant steps towards widening the reach of the IT Revolution to the developing world.

10. Conclusion

Nectar leverages and extends the ButterflyNet infrastructure for purposes of Rural Data Collection and consequently brings quality health care to Indian villages. Nectar helps hospitals to capture indicative rural patient data in a simple and quick manner using a Pocket PC. The data that is locally stored data on the Pocket PC is easily synchronized with zero manual effort with the Hospital Patient Information System through XML Web Services. In addition, data type and schema reconciliation can be performed on the fly in a fully automated manner.

The data collected is saved to persistent storage for further analysis and suitable treatment can be offered to the villagers based on the results of such analysis. The data can be mined to gauge the overall health conditions of a village or presence of regional diseases etc and appropriate preventive or corrective measures can be taken. As discussed earlier, Nectar effectively addresses the pain points that hospitals face in Village of the Month programs in terms of the following:

• Providing a Simple, Fluid, Rapid, and Dependable means for the collection of indicative rural patient data

• Reliable transfer of collected data in a consistent manner to the Hospital PIS

• Making the data available in a form that is amenable to rich, intelligent post-processing

• Maintaining the collected data, health records and prescriptions, for future retrieval and analysis.

References

[1] Tapan S. Parikh, CAM: A Mobile Paper-based Information Services Architecture for Remote Rural Areas in the Developing World, Doctoral Consortium, IEEE Symposium on Visual Languages and Human-Centric Computing, September 20-24, 2005, Dallas, Texas

[2] Eric A. Brewer, TIER: Technology and Infrastructure for Emerging Regions,

[3] Clay Spinuzzi, Using a Handheld PC to Collect and Analyze Observational Data, ACM Special Interest Group for Design of Communications, Proceedings of the 21st annual international conference on Documentation, San Francisco, CA, USA

[4] Norman, D.A, Draper S.W, User Centered System Design: New Perspectives on Human-Computer Interaction

[5] World Health Organization (WHO): Country Health Profile – India

[6] Butler W. Lampson, Hints for Computer System Design

Appendix: Thoughts on Paper

[pic]

[pic]

[pic]

[pic]

-----------------------

Hospital

Database

Nectar

XML Web Service

Nectar

Local Store

Nectar

XML Web Service Client

Nectar

Data Capture

Interface

Pocket PC Front-End

Hospital Back-End

Rural Patient Data

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download