1. The need for a distributed
electronic medical record system
In the past half year or so, we have been working with a partner hospital (St. Mary's Polyclinic (SMPC), Lucknow, India) whose mission is catering to the poor. Like almost all such organizations, the hospital lacks a good electronic medical record (EMR) system. This poses a significant obstacle to the hospital's effective functioning.
Today, the hospital relies entirely on paper-based record keeping. The hospital may see hundreds of patients a day. While mountains of papers are piled up in a storage room, it is only feasible for the staff to examine a tiny fraction of the most recent records, kept under the admission counter (Figure 1(a)). The inability to access a patient's history results in many handicaps, such as unnecessary duplication of tests and inability for hospital staff to assess larger statistical trends.
In the past half year or so, we have been working with a partner hospital (St. Mary's Polyclinic (SMPC), Lucknow, India) whose mission is catering to the poor. Like almost all such organizations, the hospital lacks a good electronic medical record (EMR) system. This poses a significant obstacle to the hospital's effective functioning.
Today, the hospital relies entirely on paper-based record keeping. The hospital may see hundreds of patients a day. While mountains of papers are piled up in a storage room, it is only feasible for the staff to examine a tiny fraction of the most recent records, kept under the admission counter (Figure 1(a)). The inability to access a patient's history results in many handicaps, such as unnecessary duplication of tests and inability for hospital staff to assess larger statistical trends.
Figure 1. Scenes at St. Mary's Polyclinic. (a) Paper-based patient records. (b) Mobile van-based field operations.
For the most part, such hospitals and organizations are keenly aware of
the need of a good EMR system. Unfortunately, the current state of
art of available EMR systems is woefully inadequate: they are typically
expensive proprietary systems. In addition to cost, being closed and
proprietary has other severe disadvantages. First, each hospital has
its own unique needs; but it is difficult, if not impossible, to
thoroughly customize such closed systems to cater to these different and
specific needs. This difficulty is especially pronounced for the
kind of hospitals that we work with because of their lack of
resources. Second, the proprietary nature of such systems also makes
it difficult to make them communicate and share data with other peer
systems.
Furthermore, these systems lack good support for "distributed operations"--by "distributed operations," we mean the ability of sharing information and coordinating actions across many different sites. When they do support network access, these existing systems are typically constrained within the walls of a single hospital, on a single local area network (LAN). SMPC has many operations, such as mobile vans that run "camps" in the field (Figure 1(b)), or outlying clinics in rural areas, which are all beyond the confines of the main hospital (which we shall call the "mother-ship hospital"). The mobile camps and outlying clinics do not even have Internet access. Existing systems offer no way of information-sharing among these widely distributed and disconnected sites.
There has been increasing interest in online medical record systems that allow patients to, for example, easily take their records to a different hospital or doctor, as the likes of Microsoft and Google have recently launched their own initiatives in this space. These initiatives, however, have been mainly a "first-world" phenomenon. (The interface of Google Health, for example, is unfortunately inappropriate for the developing world context that we are targeting: it is designed for individual patients to manage their own records and is a fundamentally wrong fit for institutions that need to manage a large number of these records.) The irony is that those in the vast under-served areas of the world, those who have practically no access to quality health care today, may have the most to gain from a system that allows them to be heard and seen, but are below the radar screen of the current US-based initiatives. What we need is to design and engineer a distributed medical record system relevant for the needs of the local contexts. Digital Polyclinic is an attempt to plug this critical gap, and we believe this effort could also bring more awareness and interest in working on this important problem.
2. The Digital Polyclinic system
Furthermore, these systems lack good support for "distributed operations"--by "distributed operations," we mean the ability of sharing information and coordinating actions across many different sites. When they do support network access, these existing systems are typically constrained within the walls of a single hospital, on a single local area network (LAN). SMPC has many operations, such as mobile vans that run "camps" in the field (Figure 1(b)), or outlying clinics in rural areas, which are all beyond the confines of the main hospital (which we shall call the "mother-ship hospital"). The mobile camps and outlying clinics do not even have Internet access. Existing systems offer no way of information-sharing among these widely distributed and disconnected sites.
There has been increasing interest in online medical record systems that allow patients to, for example, easily take their records to a different hospital or doctor, as the likes of Microsoft and Google have recently launched their own initiatives in this space. These initiatives, however, have been mainly a "first-world" phenomenon. (The interface of Google Health, for example, is unfortunately inappropriate for the developing world context that we are targeting: it is designed for individual patients to manage their own records and is a fundamentally wrong fit for institutions that need to manage a large number of these records.) The irony is that those in the vast under-served areas of the world, those who have practically no access to quality health care today, may have the most to gain from a system that allows them to be heard and seen, but are below the radar screen of the current US-based initiatives. What we need is to design and engineer a distributed medical record system relevant for the needs of the local contexts. Digital Polyclinic is an attempt to plug this critical gap, and we believe this effort could also bring more awareness and interest in working on this important problem.
2. The Digital Polyclinic system
We are working on a distributed electronic medical record system, which we
call the Digital Polyclinic (DPC). DPC is designed to cater to the
unique needs of the hospitals like SMPC and address the inadequacies of
the current systems discussed above. Figure 2 is an illustration of
DPC.
2.1 Support for distributed operations
DPC has a number of unique advantages. First is its flexible support for distributed operations. For the sites that have access to the Internet, DPC allows these sites to synchronize and share patient records. For example, a rural clinic can easily share and synchronize its records with the mother-ship hospital's database.
But perhaps even more interestingly, DPC allows sites that do not have immediate Internet access to participate in the system as well. For example, a van, as part of a mobile camp, carries a laptop, which houses a component of the mother-ship database, into the field. During the field operation, the laptop can be entirely self-sufficient and support staff work without network connectivity. At the end of the trip, when the laptop returns to the mother-ship hospital, it rejoins the network and synchronizes with the mother-ship database. New patient records collected in the field earlier or updates are all automatically "uploaded" back into the mother-ship database.
Furthermore, even authorized US-based staff or volunteers (including volunteers from medical school students) can "log onto" the system and provide help. They may search, sort, and filter based on certain criteria, before they decide on what cases they might want to help with. Indeed, some of the records being examined could have been collected by a van-driven field trip earlier.
This approach may provide a useful complementary solution to conventional tele-medicine (although the database should be useful for the conventional tele-medicine case as well). Conventional tele-medicine has a potential scalability problem: there are simply not enough skilled doctors who are capable and willing to staff live teleconferencing-style sessions. DPC attempts to optimize the time of the most skilled staff as a hierarchy of trained front-line data collectors and back-office "triage staff" can offload a significant portion of the workload as they get to sift through the database first. The rank of these front-line workers can also grow more quickly through increased training through the system. The most skilled staff, as a result, gets to work only on the perhaps most demanding cases. In addition to "space-shifting," which refers to the ability of linking people from different places, DPC also provides valuable "time-shifting," which refers to the fact that the service seekers and the service providers do not necessarily have to "meet" each other at the same time: for example, records collected on a van trip can be examined later, after the van has returned and synchronized with the mother-ship. This approach can work well for the non-emergency and preventive cases that the system specifically targets. In some sense, one may think of the system as a distributed "Patient's and Doctor's Facebook" for the poor. (Such a "facebook" can be linked to other schemes such as collection of donation to fund certain procedures, or "micro-insurance," instituted through self-help groups.)
Of course, we do not expect a single exchange through the database can solve everything--instead, we consider DPC to be a mechanism to get people into "the system," where "the system" may entail repeated and regularly scheduled visits and checkups (probably effected by a van), drop-off of medicines, and pick up of patients for further tests at the mother-ship hospital, and all of these events are entered into a historical trail that gets recorded and coordinated by DPC.
A theme of DPC that we have described so far is a single coherent system seen by "everyone," regardless where they are. This "single system image" is important for a variety of reasons. For example, consider immunization records: villagers can get immunized by multiple organizations, and only when these organizations are sharing the same system can they effectively coordinate their activities. (And being part of the "network," the DPC system can, for example, easily link immunization records to an SMS system, so that the system can automatically send out immunization reminders via SMS.)
Being a single coherent system has other advantages: for example, public health professionals can mine the database for aggregate trends and plan activities such as targeted prevention and awareness campaigns. Case data from the database, particularly multimedia data, may help with education and training programs.
2.2 DPC architecture: open-source local databases plus a cloud-based back-end
Figure 2 may appear as a traditional client-server system; but DPC is not exactly like such a system. Without the network, a traditional client-server system cannot function. On the other hand, in DPC, for example, a mobile van, housing a laptop that is disconnected, needs to be self-sufficient. So DPC needs to support "disconnected operations." Consequently, each DPC "client" includes a local database, and most of the operations are executed locally. These local databases interact with "the cloud" only when necessary.
Both the "client" and "server" components in DPC are based on an existing open-source medical record system called OpenEMR. Our work on OpenEMR so far has been two-fold: (1) introducing distributed operation features into OpenEMR, and (2) tailoring OpenEMR for the context of serving the underprivileged in India, which entails mundane details such as the fact that traditional means of establishing a patient's identity using name, date of birth, or tax ID does not work--we have had to introduce features such as fuzzy matching in searches and picture IDs.
The use of an open-source system is significant. It goes to the heart of the problems associated with traditional conventional closed systems discussed in Section 1. It addresses the cost problem of closed systems: our open-source system is free. It addresses the customization problem of closed systems: the open-source system is easily customizable, and indeed, the OpenEMR system that we are working on will provide a framework specifically designed to facilitate customization (such as a mechanism that allows different hospitals to easily create new forms). It addresses the compatibility problem of closed systems: the different instances of the OpenEMR derivatives are designed to be able to easily communicate with each other to share data.
As as a result of employing this architecture, we hope to build a wide network of these databases, all inter-linked with each other and able to communicate with each other. We believe that this would be a significant improvement of the traditional approach of different organizations keeping expensive, inflexible, and incompatible isolated individual databases of their own. We hope that the DPC system will help the vast underprivileged population to be finally heard and seen and to have access to the kind of services that have been so far beyond their reach.
2.1 Support for distributed operations
DPC has a number of unique advantages. First is its flexible support for distributed operations. For the sites that have access to the Internet, DPC allows these sites to synchronize and share patient records. For example, a rural clinic can easily share and synchronize its records with the mother-ship hospital's database.
But perhaps even more interestingly, DPC allows sites that do not have immediate Internet access to participate in the system as well. For example, a van, as part of a mobile camp, carries a laptop, which houses a component of the mother-ship database, into the field. During the field operation, the laptop can be entirely self-sufficient and support staff work without network connectivity. At the end of the trip, when the laptop returns to the mother-ship hospital, it rejoins the network and synchronizes with the mother-ship database. New patient records collected in the field earlier or updates are all automatically "uploaded" back into the mother-ship database.
Furthermore, even authorized US-based staff or volunteers (including volunteers from medical school students) can "log onto" the system and provide help. They may search, sort, and filter based on certain criteria, before they decide on what cases they might want to help with. Indeed, some of the records being examined could have been collected by a van-driven field trip earlier.
This approach may provide a useful complementary solution to conventional tele-medicine (although the database should be useful for the conventional tele-medicine case as well). Conventional tele-medicine has a potential scalability problem: there are simply not enough skilled doctors who are capable and willing to staff live teleconferencing-style sessions. DPC attempts to optimize the time of the most skilled staff as a hierarchy of trained front-line data collectors and back-office "triage staff" can offload a significant portion of the workload as they get to sift through the database first. The rank of these front-line workers can also grow more quickly through increased training through the system. The most skilled staff, as a result, gets to work only on the perhaps most demanding cases. In addition to "space-shifting," which refers to the ability of linking people from different places, DPC also provides valuable "time-shifting," which refers to the fact that the service seekers and the service providers do not necessarily have to "meet" each other at the same time: for example, records collected on a van trip can be examined later, after the van has returned and synchronized with the mother-ship. This approach can work well for the non-emergency and preventive cases that the system specifically targets. In some sense, one may think of the system as a distributed "Patient's and Doctor's Facebook" for the poor. (Such a "facebook" can be linked to other schemes such as collection of donation to fund certain procedures, or "micro-insurance," instituted through self-help groups.)
Of course, we do not expect a single exchange through the database can solve everything--instead, we consider DPC to be a mechanism to get people into "the system," where "the system" may entail repeated and regularly scheduled visits and checkups (probably effected by a van), drop-off of medicines, and pick up of patients for further tests at the mother-ship hospital, and all of these events are entered into a historical trail that gets recorded and coordinated by DPC.
A theme of DPC that we have described so far is a single coherent system seen by "everyone," regardless where they are. This "single system image" is important for a variety of reasons. For example, consider immunization records: villagers can get immunized by multiple organizations, and only when these organizations are sharing the same system can they effectively coordinate their activities. (And being part of the "network," the DPC system can, for example, easily link immunization records to an SMS system, so that the system can automatically send out immunization reminders via SMS.)
Being a single coherent system has other advantages: for example, public health professionals can mine the database for aggregate trends and plan activities such as targeted prevention and awareness campaigns. Case data from the database, particularly multimedia data, may help with education and training programs.
2.2 DPC architecture: open-source local databases plus a cloud-based back-end
Figure 2 may appear as a traditional client-server system; but DPC is not exactly like such a system. Without the network, a traditional client-server system cannot function. On the other hand, in DPC, for example, a mobile van, housing a laptop that is disconnected, needs to be self-sufficient. So DPC needs to support "disconnected operations." Consequently, each DPC "client" includes a local database, and most of the operations are executed locally. These local databases interact with "the cloud" only when necessary.
Both the "client" and "server" components in DPC are based on an existing open-source medical record system called OpenEMR. Our work on OpenEMR so far has been two-fold: (1) introducing distributed operation features into OpenEMR, and (2) tailoring OpenEMR for the context of serving the underprivileged in India, which entails mundane details such as the fact that traditional means of establishing a patient's identity using name, date of birth, or tax ID does not work--we have had to introduce features such as fuzzy matching in searches and picture IDs.
The use of an open-source system is significant. It goes to the heart of the problems associated with traditional conventional closed systems discussed in Section 1. It addresses the cost problem of closed systems: our open-source system is free. It addresses the customization problem of closed systems: the open-source system is easily customizable, and indeed, the OpenEMR system that we are working on will provide a framework specifically designed to facilitate customization (such as a mechanism that allows different hospitals to easily create new forms). It addresses the compatibility problem of closed systems: the different instances of the OpenEMR derivatives are designed to be able to easily communicate with each other to share data.
As as a result of employing this architecture, we hope to build a wide network of these databases, all inter-linked with each other and able to communicate with each other. We believe that this would be a significant improvement of the traditional approach of different organizations keeping expensive, inflexible, and incompatible isolated individual databases of their own. We hope that the DPC system will help the vast underprivileged population to be finally heard and seen and to have access to the kind of services that have been so far beyond their reach.