Health IT

In anticpation of a stimulating and informative panle discussion on the topic of Implementation of EMR/EHRs the next four postings are the biosketchs of the panellists.

JAMES ARBAUGH-James Arbaugh graduated with a Bachelor of Science degree in Computer Science Engineering Technology from Le Tourneau University in 2001. He is currently the Chief Information Officer (CIO) at Hospital Albert Schweitzer (HAS), located in Deschapelles, Haiti. He is responsible for various servers, wired/wireless networks, about 100 client stations, multiple databases and software applications. James has lead the implementation of OpenMRS at HAS in a process that began late 2006. Even today, his OpenMRS implementation boasts the largest number of registered patients; at nearly 700,000. Showing commitment to the OpenMRS community, James frequently receives prospective OpenMRS users, and has even hosted a Haiti OpenMRS Implementers Conference. James has specialized in making OpenMRS fit the needs in his developing country without significant modification to the software. HAS is currently testing OpenMRS-JR (data collection with a mobile phone into OpenMRS) with community health workers under the direction of James Arbaugh.

EVELYN CASTLE-Evelyn Castle is the founder and director of eHealth Nigeria, an NGO based in Kano, Nigeria that works with government and NGO's to implement, manage, and evaluate health programmes and interventions. eHealth Nigeria specialize in integrating technology (both mHealth and eHealth) into their health projects. All of the technology platforms that eHealth Nigeria uses are open-source platforms, which are enhanced and modified to meet the needs of the project. Some of the platforms that eHealth Nigeria works with are RapidSMS, OpenMRS, Open Data Kit, iHRIS, DHIS2, and TileMill.
For more details on Evelyn Castle’s work, please see her recent GHDonline Member Spotlight at: http://www.ghdonline.org/tech/discussion/member-spotlight-evelyn-castle-and-e...

DAVE THOMAS-Dave Thomas is a software engineer for Partners In Health (PIH)/Inshuti Mu Buzima (IMB) who has been software architect, manager and implementer for an OpenMRS-based medical records system for 2+ years in rural Rwanda. Before Rwanda, Dave build a custom OpenMRS implementation to track up to 27,000 participants in a prospective tuberculosis contact-tracing study in Lima, Peru, and was the original author of the OpenMRS MDR-TB (multi-drug resistant tuberculosis) module. Prior to PIH, Dave built and implemented an application that standardized and consolidated all waiting lists for subsidized childcare in San Francisco, California including all San Francisco public school district programs, giving parents greater choice and access to available programs. Dave has a Masters in Epidemiology of Infectious Diseases from the Yale University School of Public Health and has recently returned to San Francisco from Rwanda to start a family.

BURKE MAMLIN-Burke Mamlin was a full-time programmer on Regenstrief Institute's computerized physician order-entry system before enrolling in medical school and completing a residency in Internal Medicine. As a practicing physician, he returned to Regenstrief and completed a fellowship in Medical Informatics. In 2004, Burke was asked, along with Paul Biondich, to assess the information system supporting AMPATH, an HIV treatment program in Kenya set up by a partnership between Indiana University and Moi University. In response to the growing information needs of AMPATH, Burke and Paul created the AMPATH Medical Record System, which, in collaboration with Partners In Health, became OpenMRS. Burke continues to work with AMPATH in support of their growing system, which now spans dozens of clinics throughout Western Kenya, serving hundreds of thousands of patients and contains well over 100 million discrete clinical observations. AMPATH is the largest single implementation of OpenMRS and faces many ongoing challenges including large database management, synchronizing data across many disconnected sites, handling data from dozens of different care programs across AMPATH, a large & growing home-based care program with mobile data requirements, and integration with a reference laboratory, pharmacy & hospital.

Why did Hospital Albert Schweitzer Haiti choose OpenMRS for their electronic medical record?

We evaluated VistA (http://en.wikipedia.org/wiki/VistA), visited other hospitals in Haiti to evaluate their custom records system, and got quotes from other proprietary health info systems. We chose OpenMRS for several reasons. 1.) Partners in Health (a nearby and very similar hospital) planned to use it. 2.) It is free. 3.) It uses an SQL database (MySQL to be specific which I had used before and liked), which can support the quantity of data we needed to capture. 4.) It fit our needs better than a US based system which included capability for insurance and other things that we will never need here. 5.) It was configurable and customizable without programming. We could design our own forms and reports for the data needed to collect.

* Why did AMPATH choose OpenMRS for their electronic medical record?

The AMPATH Medical Record System (AMRS) was actually used as the codebase to start OpenMRS. When we met & chose to collaborate with Partners In Health, we took the existing AMRS codebase and renamed it OpenMRS. At that time, the system was barely functional and has not yet been put into production. We spent a year collaborating on the codebase for OpenMRS and, in early 2006, we deployed OpenMRS at AMPATH as the first production implementation of OpenMRS. Over the years, AMPATH has benefited greatly from using a platform shared by the community.

* Why did PIH choose OpenMRS for their electronic medical record?

OpenMRS is the second EMR built (or co-developed, in the case of OpenMRS) by Partners In Health (PIH). The first PIH EMR was implemented successfully in Haiti and Peru, but was too inflexible to expand past these sites without massive customisation costs. PIH partnered with Regenstrief to co-found OpenMRS because there was a clear need for a more configurable, flexible system. OpenMRS is incredibly adaptable – the 'concept dictionary' allows an implementer to configure the EMR's terminologies to reflect the terminologies used by the local health system, while mapping to international terminology standards at the same time. Additionally, the modular architecture of OpenMRS allows implementations to use the OpenMRS API to develop applications or extensions (or override virtually any part of the out-of-the-box OpenMRS install) as needed (google 'openmrs module repository' to see an example of this). For these reasons, I think of OpenMRS as an EMR platform, rather than as an EMR application.

OpenMRS is also fully open-source – a term sometimes (or maybe often and sometimes intentionally) misused in the developing world. There are mechanisms in place that allow implementations to share OpenMRS functionality at both the application and ...

* Why did PIH choose OpenMRS for their electronic medical record?

OpenMRS is the second EMR built (or co-developed, in the case of OpenMRS) by Partners In Health (PIH). The first PIH EMR was implemented successfully in Haiti and Peru, but was too inflexible to expand past these sites without massive customisation costs. PIH partnered with Regenstrief to co-found OpenMRS because there was a clear need for a more configurable, flexible system. OpenMRS is incredibly adaptable – the 'concept dictionary' allows an implementer to configure the EMR's terminologies to reflect the terminologies used by the local health system, while mapping to international terminology standards at the same time. Additionally, the modular architecture of OpenMRS allows implementations to use the OpenMRS API to develop applications or extensions (or override virtually any part of the out-of-the-box OpenMRS install) as needed (google 'openmrs module repository' to see an example of this). For these reasons, I think of OpenMRS as an EMR platform, rather than as an EMR application.

OpenMRS is also fully open-source – a term sometimes (or maybe often and sometimes intentionally) misused in the developing world. There are mechanisms in place that allow implementations to share OpenMRS functionality at both the application and the source code levels. The community around OpenMRS is extremely active and open to sharing ideas, technology, and even resources, around shared requirements. This has facilitated OpenMRS having a much greater global impact than it might have had otherwise.

At PIH's implementation site in Rwanda (Insuti Mu Buzima, IMB), we were one of the earliest implementations sites for OpenMRS (maybe the 2nd, after AMPATH?), and we were the first site to pilot a number of core OpenMRS architectures, like sync, htmlformentry and the reporting module. We've currently got tens of thousands of patients, and about 6 million observations. We do HIV, PMTCT and exposed infants, TB, primary care, non-communicable diseases, and we're moving into oncology this year. We're also adding a module for managing community health workers. We do direct entry into the EMR from the hospital lab through an OpenMRS lab entry module. And, we're often asked to support research as well as clinical programs. We're currently preparing to upgrade to OpenMRS 1.9, and we're going to have 3 parent servers located at district hospitals, 18 or more child servers situated in remote clinics, and 3 reporting servers in our sync network.

Why did we choose OpenMRS for our electronic medical record?
We initially chose OpenMRS for a few reasons. 1) it was free, 2) it was fairly easy to set-up, 3) it was advertised for resource-constrained environments.

The responses of the panellists provide information and knowledge on an "evolutionary" e-health model based around clinical decision making, data capture, evaluation (report generation) and the need for data standardisation. Despite markedly diverse environments these projects have succeeded in adhering to the core design goals for e-health systems in resource poor environments (Biondich & Mamlin). These are Collaboration, Scalability,Flexibility, Rapid Form Design (data capture adaptability) and Clinically Useful System (if it is not 'clinically useful' it will not be used). The use of Standardisation to faciltate the systems flexibilty and extensibility and there for supports high quality research (to improve care you have to be able to measure it). Finally there are two more critical factors for success. Web-based support (Implementers group) where connectivity is often intermittent and finally the system must be affordable (low cost) so as not to prohibit adoption.

* What benefits has HAS seen since the implementation?

Since implementation, we have seen a major benefit; accessibility of information. Our old system was built in Paradox for DOS. The reports that were built into the system were what we had available without writing custom queries or opening the Paradox tables in Excel or importing them into Access. It was also a static system, inflexible for adding additional fields for data collected. Because of how well OpenMRS worked in our initial data collection points we are slowly migrating additional info that is collected into OpenMRS so we have a one-stop source of information which various staff know how to access. As an added benefit, we can use OpenMRS-JR on J2ME capable phones and synchronize cohorts from OpenMRS and enter forms for patients that then synchronize into OpenMRS appearing as a standard encounter.

* What benefits have AMPATH seen since the implementation?

We've been able to grow and sustain and enterprise level medical record system, enjoying many features that required no coding effort by AMPATH. We've been able to support literally dozens of ongoing healthcare programs across a spectrum of medical conditions without having to change systems. Clinicians get patient summaries that help in clinical care. The data team is able to generate reports from the data that help guide the implementation, provide data for the Ministry of Health, and supply data to granting agencies.

A couple of questions.

Dave, you mentioned the offline syncing capability of OpenMRS, and then you
mentioned you had 3 parent servers and 3 reporting servers. Do the three
parent servers have the same information between each of them and the same
for the 3 reporting servers? What's the benefit of that?

James, in using OpenMRS-JR, how long did the setup take? Is there a link
where we could see more about it, like for example does it work on android
phones? and can you create patients with openMRS-JR?

Thanks,

Joaquín
___________________________________________________________________
Gerente de Desarrollo, eHealth Systems <http://www.ehs.cl/>
Research Fellow, Escuela de Medicina de Harvard <http://hms.harvard.edu/>
Moderador, GHDOnline.org <http://www.ghdonline.org/>

I wanted to share some of our experiences, too, even though MVP was not specifically included on the discussion panel. MVP operates in ten sub-saharan african countries serving clusters of approx 50,000 people in each country. We work only through locally-hired teams in each country. The decision to use OpenMRS was based primarily on the open source, extensible design and the data model. The use of a concept dictionary was critical for us working across different countries and languages. We share a common dictionary among all the sites as well as with many other organizations. This provides semantic interoperability and includes maps to international reference codes such as ICD-10 and SNOMED CT.

MVP uses OpenMRS as the core of an open source stack of applications called the Millennium Villages Global Network (MVG-Net). We have an ecosystem of applications which all integrate within OpenMRS including ChildCount+ (www.childcount.org) for community health worker information, ODK (clinic and collect) for verbal autopsy and some clinic-based entry, and we are integrating other applications include CommCare, MoTeCH, DHIS2 and the Pentaho data warehousing solutions. We are also exploring connecting the Baobab touchscreen application to our database in Malawi.

MVP currently has over 400 ...

I wanted to share some of our experiences, too, even though MVP was not specifically included on the discussion panel. MVP operates in ten sub-saharan african countries serving clusters of approx 50,000 people in each country. We work only through locally-hired teams in each country. The decision to use OpenMRS was based primarily on the open source, extensible design and the data model. The use of a concept dictionary was critical for us working across different countries and languages. We share a common dictionary among all the sites as well as with many other organizations. This provides semantic interoperability and includes maps to international reference codes such as ICD-10 and SNOMED CT.

MVP uses OpenMRS as the core of an open source stack of applications called the Millennium Villages Global Network (MVG-Net). We have an ecosystem of applications which all integrate within OpenMRS including ChildCount+ (www.childcount.org) for community health worker information, ODK (clinic and collect) for verbal autopsy and some clinic-based entry, and we are integrating other applications include CommCare, MoTeCH, DHIS2 and the Pentaho data warehousing solutions. We are also exploring connecting the Baobab touchscreen application to our database in Malawi.

MVP currently has over 400,000 patients and 8 million observations across the different servers. We currently do not use Synch between servers, but do push out the CIEL/MVP dictionary to all the servers. We report using pivot tables, SQL and will soon be using the Pentaho warehouse.

Our major problems continue to be around infrastructure and training. We have now hired an eHealth Specialist for each of the countries to assist the local teams with implementation, but power and connectivity remain a big issue which is pushing us towards a more offline solution such as using CommCare and ODK as primary data collection/presentation. We have not tried OpenMRS-JR.

In short, we feel that although for MVP, OpenMRS does play a large part directly in point-of-care collection, we do feel it is absolutely essential for data organization, interoperability and the longer-term scalability and sustainability of an integrated health information system.

Hi Joaquín. In answer to your questions, OpenMRS-JR didn't take very long to setup. But, it has taken a lot of time to have OpenMRS-JR customized to our needs, and we are still awaiting bug fixes. It uses the XForms module for OpenMRS to design the forms and talk to OpenMRS so it's pretty simple and doesn't require any programming. You can create patients with OpenMRS-JR, but we have not done extensive testing on this and are not using that feature currently in production. OpenMRS-JR works on J2ME capable phones (specifically the Nokia C3 in our deployment). ODK is a more advanced alternative which works with more powerful (and more expensive) Android phones.

You can find more info about OpenMRS-JR at...
https://wiki.openmrs.org/display/docs/OpenMRS-jr

Hi Joaquin. To answer your question about our multiple reporting servers, we currently have two sync networks -- one for the north and one for the east -- but we're splitting the east by district, into Southern Kayonza, and Kirehe. Per the Rwandan MoH, we're moving to a decentralised model where each district is essentially autonomous. Administratively this is already true, so we're adjusting our sync networks to match. We've considered creating a reporting server that is the parent of the district parent servers, but this would take some hacking at this point because the merge between the east and the north, in order to create a reporting server that can accept information from multiple sync networks, would be a manual process. We assume that we've had metadata drift between our two current networks, which have been independent for 3+ years, and we haven't fully quantified this yet.

* What benefits have we seen at IMB since adopting OpenMRS

There are myriad benefits, from ease of reporting, to better support for longitudinal care, to being able to do operational research that would have been otherwise almost impossible. We found a significant positive difference in the turnaround time and reduction of errors for CD4 test results entered by lab technicians into OpenMRS vs. returning test results to clinicians on paper (IMB has published this result). We assign unique identifiers to patients at each health center during a patient's first visit and print barcodes that the patient keeps on their carne (their personal health record). Just figuring out who's who longitudinally can be surprisingly problematic with only paper-based systems. For HIV care, the EMR allows us to look at longitudinal CD4 counts and viral loads for patients, which facilitates algorithmically looking for treatment failure. Looking for missed visits is easier with the EMR than manually going through paper charts. We also print 'consultation sheets' for clinicians, so that they know who is expected on a given day, and who may be experiencing HIV treatment failure. And in terms of research, we're fairly consistently being asked to export SAS ...

* What benefits have we seen at IMB since adopting OpenMRS

There are myriad benefits, from ease of reporting, to better support for longitudinal care, to being able to do operational research that would have been otherwise almost impossible. We found a significant positive difference in the turnaround time and reduction of errors for CD4 test results entered by lab technicians into OpenMRS vs. returning test results to clinicians on paper (IMB has published this result). We assign unique identifiers to patients at each health center during a patient's first visit and print barcodes that the patient keeps on their carne (their personal health record). Just figuring out who's who longitudinally can be surprisingly problematic with only paper-based systems. For HIV care, the EMR allows us to look at longitudinal CD4 counts and viral loads for patients, which facilitates algorithmically looking for treatment failure. Looking for missed visits is easier with the EMR than manually going through paper charts. We also print 'consultation sheets' for clinicians, so that they know who is expected on a given day, and who may be experiencing HIV treatment failure. And in terms of research, we're fairly consistently being asked to export SAS or STATA-ready datasets that have been used for operational research and clinical program monitoring.

We thank the panelists for their thoughtful contributions to the discussion so far, and hope others in the Health IT community with experience or questions about OpenMRS implementation, or other projects, will chime in and share there thoughts on this discussion as well. I am adding a series of summary points for the discussion so far.
Summary points:
• B.Mamlin-addresses growth and sustainability of the e-health system. He also refers to the continuing value of Summarisation as a decision support tool in clinical care (known since the 1980s). The other important point is how ‘clinical care data’ supports government agencies in health planning with no additional health data acquisition costs.
• J. Arbaugh-his term “accessibility of information” reaffirms the WHO definition of health care. “There is no health without management, and there is no management without information. “ He also highlights the critical importance of how OpenMRS has introduced the flexibility of data management that was not possible in earlier data management systems. He also introduces the rapidly developing filed o mm-health and the use of mobile technologies in Health IT implementations which is very relevant to resource poor communities.
• D. Thomas-highlights the benefits from the availability of real-time, longitudinal clinical data ...

We thank the panelists for their thoughtful contributions to the discussion so far, and hope others in the Health IT community with experience or questions about OpenMRS implementation, or other projects, will chime in and share there thoughts on this discussion as well. I am adding a series of summary points for the discussion so far.
Summary points:
• B.Mamlin-addresses growth and sustainability of the e-health system. He also refers to the continuing value of Summarisation as a decision support tool in clinical care (known since the 1980s). The other important point is how ‘clinical care data’ supports government agencies in health planning with no additional health data acquisition costs.
• J. Arbaugh-his term “accessibility of information” reaffirms the WHO definition of health care. “There is no health without management, and there is no management without information. “ He also highlights the critical importance of how OpenMRS has introduced the flexibility of data management that was not possible in earlier data management systems. He also introduces the rapidly developing filed o mm-health and the use of mobile technologies in Health IT implementations which is very relevant to resource poor communities.
• D. Thomas-highlights the benefits from the availability of real-time, longitudinal clinical data. This relates to all areas of the health care domain. These include direct patient care, reporting, research, error reduction, clinician involvement and many more. He also refers to summarisation (Consultation charts) as a clinical decision support tool.
• A. Kanter-his input summarises the concept previously described by Charlie Safran. “Technology is not the problem. Implementers need to address the ‘information management ‘issues relating to Health IT. With the data presented by Andy in his response it is important to grasp the profound influences have had on the local communities involved in the MVP projects. Success and sustainability are multi-tiered and involve the intense human commitment and sacrifices of people who can think laterally. They also fit with the philosophy that “hope does not lie in a way out, but in a way through” (R. Frost).
• E. Castle- defines the practical core points for choosing a system like OpenMRS. We initially chose OpenMRS for a few reasons. 1) it was free, 2) it was fairly easy to set-up, 3) it was advertised for resource-constrained environments. The overall success of the projects she is involved in fit in with the philosophies of the other panellists.

· What were unexpected (or perhaps expected) problems that arose?

We've dealt with what often feels like a mountain of problems at every level. In terms of hardware issues, we've seen melted solar batteries, slow and unstable internet (less than 500 BYTES pers second, on a bad day), lightning strikes, 110-volt machines plugged into 220 power, shortages of gas needed to run generators, burned-out UPS's, unstable grid power, etc... Additionally, some of our sites are quite remote, and it can take a day or two bouncing around in the back of an ambulance to get there.

We spent the early years running a 'sync' branch of OpenMRS, before merging into the OpenMRS mainstream with OpenMRS 1.6 (when sync became a module). This was painful period because we weren't receiving the benefit of the community moving the OpenMRS core code-base forward. Since then, we've pushed through migrating from infopath (the first form entry strategy) to htmlformentry (a newer, html-driven form entry strategy), and from as many as 5 different reporting mechanisms to the new OpenMRS reporting module. Keeping up with the advancing OpenMRS community, while expanding the services provided by the IMB EMR is a constant ...

· What were unexpected (or perhaps expected) problems that arose?

We've dealt with what often feels like a mountain of problems at every level. In terms of hardware issues, we've seen melted solar batteries, slow and unstable internet (less than 500 BYTES pers second, on a bad day), lightning strikes, 110-volt machines plugged into 220 power, shortages of gas needed to run generators, burned-out UPS's, unstable grid power, etc... Additionally, some of our sites are quite remote, and it can take a day or two bouncing around in the back of an ambulance to get there.

We spent the early years running a 'sync' branch of OpenMRS, before merging into the OpenMRS mainstream with OpenMRS 1.6 (when sync became a module). This was painful period because we weren't receiving the benefit of the community moving the OpenMRS core code-base forward. Since then, we've pushed through migrating from infopath (the first form entry strategy) to htmlformentry (a newer, html-driven form entry strategy), and from as many as 5 different reporting mechanisms to the new OpenMRS reporting module. Keeping up with the advancing OpenMRS community, while expanding the services provided by the IMB EMR is a constant challenge. Its an endless process, really, and it can be hard to explain why building a substantial EMR can have a longer time horizon than building a new hospital. It also took us a while to get to a reasonable set of user roles and permissions -- it has been a couple of years now since someone in the field has uninstalled a key module on a remote server, just out of curiosity.

Also, open-source doesn't mean 'free'. While you can download and install the software for free, if you run into problems, you either have to interface with the community to try to push through a fix, or you have to fix it yourself. So, the costs around implementing open-source software can sometimes start to resemble what the costs might have been if a software package had simply been purchased – especially during the initial rollout phase. However, on the positive side, local ownership and control of what the software actually does is much greater with open-source software, and this can be much cheaper in the long run, relative to paying for international consultants year after year. But this can be frustrating sometimes, and also hard to explain. 'EMR evolution' consumes resources annually, and we're constantly (but gently) pushing back against 'why isn't the stupid thing finished, already?'.

I'm interested in hearing from Burke about scaling OpenMRS. I know there are some mysql tricks that make indexing faster (an alternate innodb plugin), and that you can bypass mysqldump by just copying the datafiles. Other than these, are there any lessons learned at the application server or openmrs layers that have been particularly useful? And, how has a massive number of obs affected ad-hoc querying of the database?

I really like the quote "Technology is not the problem. Implementers need to address the information management issues relating to Health IT." Its a nice way to sum up a whole bunch of problems around everything from staffing, training and change management; to managing expectations amongst stakeholders and partners; to data modelling of clinical problems and systems design. Our jobs would be easier if there were more consistent ideas about what Health IT even means.

* What were unexpected (or perhaps expected) problems that arose?

Our implementation has been full of little bumps along the way. One were the limitations of OpenMRS in the early days. At one point, we were running off of less than stable builds because we needed the latest features. Even now, we cannot merge our blood bank data into the system because you can’t configure which user roles can view/edit which types of encounters. This is still a work in progress. Another problem we encountered was rejection by staff because it was different from the old system, and they felt threatened by new technology. Another challenge that we imposed on ourselves was to force-fit OpenMRS into our particular work-flow as opposed to modifying the programming. This required flexibility on everyone’s part.

We too felt the pain David Thomas mentioned of migrating through various reporting mechanisms and form entry methods.

* What were unexpected (or perhaps expected) problems that arose?

Problems, both expected and unexpected, are nearly a weekly occurrence when trying to grow and maintain an information system serving hundreds of thousands of patients across dozens of treatment programs. One of our bigger problems has been with connectivity and power. We've also had problems with consistency on reporting – i.e., ensuring that indicators with complex definitions are consistent across reports for different programs.

A popular misconception of Open Source solutions is that they are "free" as stated by Evelyn Castle in Point 9 above. The reality is that only certain components of such Open Source solutions are 'free', which would be mainly the 'to-be-developed' application software modules. Whereas, the hardware, the training, the communications, the infrastructure, the MOH overhead, etc., and all of the on-going technical support for the software and hardware, do have real measurable costs. Studies show that the 'packaged' application software modules - from software vendors - constitute about 10% of the TOTAL cost of an HIS implementation.

Evelyn further states that she selected OpenMRS because "it was advertised for resource-constrained environments" - which means for developing countries. When the application software is priced to the annual per-capita health budget of the country the eHealth solution becomes affordable and 'sustainable', and has the huge advantage of being available immediately - not ten years from now, if ever. Developing countries may care to look at this reality more closely if they wish to use the HIS to assist in meeting their MDGs by 2015.

OpenMRS may well be an excellent "EMR platform" as stated by David Thomas. It is being used in both developing and ...

A popular misconception of Open Source solutions is that they are "free" as stated by Evelyn Castle in Point 9 above. The reality is that only certain components of such Open Source solutions are 'free', which would be mainly the 'to-be-developed' application software modules. Whereas, the hardware, the training, the communications, the infrastructure, the MOH overhead, etc., and all of the on-going technical support for the software and hardware, do have real measurable costs. Studies show that the 'packaged' application software modules - from software vendors - constitute about 10% of the TOTAL cost of an HIS implementation.

Evelyn further states that she selected OpenMRS because "it was advertised for resource-constrained environments" - which means for developing countries. When the application software is priced to the annual per-capita health budget of the country the eHealth solution becomes affordable and 'sustainable', and has the huge advantage of being available immediately - not ten years from now, if ever. Developing countries may care to look at this reality more closely if they wish to use the HIS to assist in meeting their MDGs by 2015.

OpenMRS may well be an excellent "EMR platform" as stated by David Thomas. It is being used in both developing and developed countries, however the challenge is to get accurate and timely data into it, which can be enabled much more quickly - and inexpensively - with field-proven application software modules, at the point-of-care, developed over the past thirty years in the developed countries. As noted above, appropriate product pricing will ensure sustainability.

Food for thought and consideration.

Respectfully submitted

Ron Hebert

To Ron Hebert. Your points add further clarification to the concepts surrounding "free" and you have delineated these clearly. When one observes the OpenMRS developers and Implementers sites it seems as if 'adaptable forms' for data capture is a signficant component of the developments. Does this not reflect a strength of this system that enables it to adapt to local 'point of care' data capture needs? Also is it possible to have references with evaluations of "field-proven application software modules, at the point-of-care"? The reason I raise these points is that 'clinician involvement' at the point of care data capture (CPOE) is a signficant stumbling block to e-Health implementations (See Leape, Five Years after To Err is Human. What have we Learned?"

I wish to challenge the implementers on what has been the place of unstructured data (in text reports) that are in the systems eg. Pathology reports, surgical notes . Do you think OpenMRS implementations should focus on this (especially now that the reporting tools have improved.)?

Ron, traditional EMRs have singularly failed to be adopted in resource poor settings for numerous reasons. One hypothesis is that they need to be locally owned and supported. Open source provides an opportunity for local capacity building, local modification, and local ownership of application and data. I wonder what other readers think. Are there examples of any sustainable, scalable and usable that have actually succeeded in low and middle income countries? This is a discussion about OpenMRS experiences, but one question is whether a platform like OpenMRS can succeed at scale. I guess countries like Rwanda and Kenya are soon going to find out. I think the other question is whether any ONE application can do everything anyway... it seems more and more that an ecosystem of different applications will be required to meet all the requirements and then it matters more about use of standards and "how well your application plays in the sandbox with others." The OpenMRS community certainly has been trying to play. Has it worked?

@judy, the use of unstructured or "free" text within an EMR is an important decision for those managing information systems. Some systems use unstructured text for nearly everything, making it difficult or, at best, unreliable to the computer to understand or re-use information. In other cases, implementations can push structured data collection beyond it's return on investment (collecting structured data takes more energy than collecting unstructured data, so its important to avoid structuring something when the structure is not necessary). OpenMRS encourages the collection of structured data through codified observations (where both the question & answer(s) are dictionary concepts that the computer can understand and re-use) but also allows for collecting unstructured data as text-based observations.

In general, if there is any plan for the computer to re-use information beyond just re-displaying it to humans – e.g., for decision support, reporting, research, etc. – then it's useful to collect the data in codified format.

In some cases, the most important use of information is simply re-displaying it to users and the computer doesn't need to understand it (just regurgitate it). Examples can include hospital discharge summaries, visit notes, and radiology impressions. While either codifying these data or creating ...

@judy, the use of unstructured or "free" text within an EMR is an important decision for those managing information systems. Some systems use unstructured text for nearly everything, making it difficult or, at best, unreliable to the computer to understand or re-use information. In other cases, implementations can push structured data collection beyond it's return on investment (collecting structured data takes more energy than collecting unstructured data, so its important to avoid structuring something when the structure is not necessary). OpenMRS encourages the collection of structured data through codified observations (where both the question & answer(s) are dictionary concepts that the computer can understand and re-use) but also allows for collecting unstructured data as text-based observations.

In general, if there is any plan for the computer to re-use information beyond just re-displaying it to humans – e.g., for decision support, reporting, research, etc. – then it's useful to collect the data in codified format.

In some cases, the most important use of information is simply re-displaying it to users and the computer doesn't need to understand it (just regurgitate it). Examples can include hospital discharge summaries, visit notes, and radiology impressions. While either codifying these data or creating codified data to go along with these can make the information more useful to the computer, failing to recognize the cost of gathering codified data and blindly pushing for codified data when the benefits are not well-defined, can lead to frustrated (or even rebellious) users.

Cheers,
-Burke

Hi Ron
You raise some important points about the TCO and the relative cost of the software and other factors. I think what is interesting is why people have so much difficult using and adapting existing health information systems in high, middle or low income countries. When you get into the adaption business then the 10% can go up fast... that's when local ownership and programming makes more sense I think. How much adaption and programming have you had to do when you moved to new countries with your systems? Do you continue to support them or do local companies or the MOH take on the support? What do you think about modular EMR systems where more than one company or organization can contribute components?
Regards

Hamish

In response to Ron's comment: Ultimately any package or platform's pros and cons are specific to that package or platform. Open-source doesn't mean bad quality, nor does success in the developed world automatically translate to success in the developing world -- there are plenty of examples where this has proven to not be the case. Any argument about open-source vs proprietary software is no substitute for proper evaluation and cost analysis.

However, in the long run (past MGD 2015), I'd argue that as technical education becomes globally decentralised, technological uptake in places like Africa continues to accelerate, and technically literate segments of the workforce grow exponentially over the next decade(s), home-grown solutions are going to become increasingly appropriate and successful, especially in terms of sustainability. Open-source is already a buzz word across much of Africa, and where there is available capacity, is going to be adopted more and more, across all domains. I also think there's a cultural component to this adoption -- one can see why using open-source platforms to develop local solutions to local problems might be attractive in a post-colonial country sensitive about foreign dependence. Nobody picked up on my previous quip about ...

In response to Ron's comment: Ultimately any package or platform's pros and cons are specific to that package or platform. Open-source doesn't mean bad quality, nor does success in the developed world automatically translate to success in the developing world -- there are plenty of examples where this has proven to not be the case. Any argument about open-source vs proprietary software is no substitute for proper evaluation and cost analysis.

However, in the long run (past MGD 2015), I'd argue that as technical education becomes globally decentralised, technological uptake in places like Africa continues to accelerate, and technically literate segments of the workforce grow exponentially over the next decade(s), home-grown solutions are going to become increasingly appropriate and successful, especially in terms of sustainability. Open-source is already a buzz word across much of Africa, and where there is available capacity, is going to be adopted more and more, across all domains. I also think there's a cultural component to this adoption -- one can see why using open-source platforms to develop local solutions to local problems might be attractive in a post-colonial country sensitive about foreign dependence. Nobody picked up on my previous quip about 'open-source' being misused across Africa to describe non-open-source software -- this is happening because it helps get a foot in the door.

· What were some of the challenges in implementing an EMR?

I think any implementation in a resource-poor setting is going to have challenges around infrastructure, staffing (operational and management), how to facilitate successful adoption of the EMR at all appropriate levels of the health system, how to make sure that the EMR itself is clinically and culturally appropriate/accurate, and how to build successful rollout and maintenance strategies. Each of these is probably worthy of its own panel discussion.

Infrastructure I mentioned a bit above, but in a nutshell, we use laptops as servers in remote sites (because of batteries and graceful shutdown mechanisms), and we've dealt with some of our internet issues by running a private APN on the MTN network, meaning that our servers can talk to each other through the cell phone towers (which provide reasonably good coverage in Rwanda – its a small country).

In terms of staffing, IMB has a large number of data officers and coordinators. We have a decentralised model, where each district has an EMR coordinator who is responsible for the EMR use and data quality in that district, and to make sure that data officers and clinicians are adequately supported. We ...

· What were some of the challenges in implementing an EMR?

I think any implementation in a resource-poor setting is going to have challenges around infrastructure, staffing (operational and management), how to facilitate successful adoption of the EMR at all appropriate levels of the health system, how to make sure that the EMR itself is clinically and culturally appropriate/accurate, and how to build successful rollout and maintenance strategies. Each of these is probably worthy of its own panel discussion.

Infrastructure I mentioned a bit above, but in a nutshell, we use laptops as servers in remote sites (because of batteries and graceful shutdown mechanisms), and we've dealt with some of our internet issues by running a private APN on the MTN network, meaning that our servers can talk to each other through the cell phone towers (which provide reasonably good coverage in Rwanda – its a small country).

In terms of staffing, IMB has a large number of data officers and coordinators. We have a decentralised model, where each district has an EMR coordinator who is responsible for the EMR use and data quality in that district, and to make sure that data officers and clinicians are adequately supported. We then have a centralised team of four programmers, and a dedicated IT support person, who only deals with OpenMRS-related issues.

We monitor clinician use of the system where we have the EMR in consultation rooms, and try to incorporate as much feedback as we can around point-of-care usage. Clinician training and change management is critical to a successful implementation. My friend Liz Peloso calls this 'last mile connectivity' – meaning connecting the EMR to its end point: the users. I think in resource-poor countries where some of the people being asked to interface with the EMR may never have typed with more than two fingers, or even used a mouse, this can be more than ½ the battle, and it is incredibly easy, but ultimately a mistake, to cut corners in this area.

Getting clinical buy-in additionally involves having some easy-to-use features that provide an instant benefit to clinicians and administrators. This is the 'glue' that is required to achieve a reasonable level of data quality. Without this, data entry just feels like extra work, and data quality will deteriorate quickly. There is also an inverse relationship between quantity of information required during data entry, and data quality. I'd argue that the best approach is to determine a few key clinical items and model these well, rather than trying to model every data point in a clinical domain up front. With clinician and administrator buy-in, it becomes a lot easier to build in research-level data collection later on – if the primary users of the system are happy, this facilitates everything else.

The last thing I want to mention is terminology, which is a deceptively massive issue. Modelling of clinical programs, especially when you're trying to concurrently support local clinical protocols and international coding systems like ICD-10, SNOMED, LOINC, or ICPC-2 is a bit of an art. This is where it is extremely useful to setup a clinical advisory board (or at least recruit a few interested clinicians) who can make determinations about local terminology, reporting requirements and modelling of clinical protocols, in addition to determining the appropriateness of electronic clinical interfaces.

There are many other areas that deserve discussion as challenges, and others on the panel may touch on these – items like interoperability with other systems, using data exchange formats like SDMX-HD and HL7, integrating mobile technologies, developing partnerships, etc...

In reply to Judy's question, I wanted to express some insight into coded versus non-coded (unstructured data) information being entered into OpenMRS. There is a time that entering non-coded (text) is appropriate, for example on comments related to a surgery procedure or lab test that was done. Text fields are going to be fairly useless for aggregate statistics as we discovered (the hard way). At one time, we didn't have an exhaustive list of possible procedures, instead we had a text field for procedures. I've attached what was actually entered so you can see first hand the type of problems we ran into. For example there were the following number and types of procedures...
1 - circoncisi0n
2 - Circoncision
2 - circoncision
1 - circoncision hernia repair
1 - circonscision
2 - circumcision

They were all trying to describe the same procedure, but in the aggregate statistics, they described 6 different procedures because of typos and spelling mistakes.

Our proposed solution to this problem is entering coded procedures where they exist, and if they don't exist then choosing OTHER NON-CODED and entering the actual procedure in the comment field for the observation. This is requested in the ticket HTML-62. This will ...

In reply to Judy's question, I wanted to express some insight into coded versus non-coded (unstructured data) information being entered into OpenMRS. There is a time that entering non-coded (text) is appropriate, for example on comments related to a surgery procedure or lab test that was done. Text fields are going to be fairly useless for aggregate statistics as we discovered (the hard way). At one time, we didn't have an exhaustive list of possible procedures, instead we had a text field for procedures. I've attached what was actually entered so you can see first hand the type of problems we ran into. For example there were the following number and types of procedures...
1 - circoncisi0n
2 - Circoncision
2 - circoncision
1 - circoncision hernia repair
1 - circonscision
2 - circumcision

They were all trying to describe the same procedure, but in the aggregate statistics, they described 6 different procedures because of typos and spelling mistakes.

Our proposed solution to this problem is entering coded procedures where they exist, and if they don't exist then choosing OTHER NON-CODED and entering the actual procedure in the comment field for the observation. This is requested in the ticket HTML-62. This will allow us to collect structured data for reporting, and non-structured data for humans to read.

I fully agree with Burke when he says...
In general, if there is any plan for the computer to re-use information beyond just re-displaying it to humans – e.g., for decision support, reporting, research, etc. – then it's useful to collect the data in codified format.

The only quibble I have with James... and I totally agree with his fundamental premise... is that structured data CAN be human readable. The reason most people assume that structured data does not carry sufficient clinical specificity or is not clinician-friendly is that many software developers push administrative terminologies like ICD on to users and ask them to select from it directly. The whole point of the CIEL/MVP dictionary is that it provides an interface between the reference terminologies and coding classifications and the clinician. You CAN capture very useful clinical information without free-text and still have the necessary maps to ICD, SNOMED, LOINC, etc.

And to Dave, you didn't mention the use of terminologists and services such as the CIEL OpenMRS dictionary in your comment. In my experience I have seen very few examples of where local management of terminology (without some assistance) actually leads to long-term sustainable and manageable data/dictionaries. I strongly recommend that people consider working with others to standardize and share terminological resources.

* What were some of the challenges in implementing an EMR?

One of the challenges in implementing an EMR has been my (and my staff’s) limited medical knowledge. Many of our concepts were created from lists given to us with incomplete details. This lead to duplicate concepts because we didn’t know what the medical terms were. To make matters worse, sometimes they were given to us in French, and other times English, and sometimes we couldn’t even distinguish which language they were in. Recently our medical director reviewed our diagnosis and procedures as well as causes of death. I spent a day making corrections to them based on her feedback. Had the MVP dictionary existed at the time that could have saved us a lot of trouble. Sometimes, I reflect now on the possibility of transitioning to the MVP dictionary. What a great resource to the community!

Another challenge has been limited/no computer knowledge by users. It's easy enough to show someone how to fill out a form in OpenMRS, but to cover all the background to get them to that point is a lot of work. We had users that didn't even know how ...

* What were some of the challenges in implementing an EMR?

One of the challenges in implementing an EMR has been my (and my staff’s) limited medical knowledge. Many of our concepts were created from lists given to us with incomplete details. This lead to duplicate concepts because we didn’t know what the medical terms were. To make matters worse, sometimes they were given to us in French, and other times English, and sometimes we couldn’t even distinguish which language they were in. Recently our medical director reviewed our diagnosis and procedures as well as causes of death. I spent a day making corrections to them based on her feedback. Had the MVP dictionary existed at the time that could have saved us a lot of trouble. Sometimes, I reflect now on the possibility of transitioning to the MVP dictionary. What a great resource to the community!

Another challenge has been limited/no computer knowledge by users. It's easy enough to show someone how to fill out a form in OpenMRS, but to cover all the background to get them to that point is a lot of work. We had users that didn't even know how to hold a mouse or what the keyboard was. This was problematic because all of this training had to be done during their usual working hours, leaving the patients unattended. I continue to reflect how we could teach them to type (with more than 1 finger).

People hired as data entry clerks work great, but trying to integrate the task into existing workers has had poor results. Because the quality of data entered on the hospital ward into the computer hasn't been improved to match the paper reports, they are required to continue doing the the old paper methods too, so truly the computer is more work for the users. Our ward data entry clerks can't grasp that it will be less work as soon as they start doing it right, so they don't have to continue doing the redundant tasks. Administration hasn't supported the idea of making the clerks do it right, and has instead hired temporary data clerks to correct the data. With more recent versions of the HTML form entry module, we have been able to do additional error checking which is reducing some of the errors, but there are still shortcomings in the HTML Form Entry module that prevent us from doing additional error checking.

Power changes caused us a problem with our infrastructure which took a while to resolve. If the thin-client terminals lost power they couldn't open Firefox again because Firefox was already running. There were other bugs in OpenMRS that caused a lack of confidence in the system, like slow form load time for forms with autocomplete fields and fields not being deleted if the clerk actually deleted them. This gave the ward clerks an excuse for not entering the data, and the appearance that the system was bad.

Implementing an EMR in a resource poor setting is challenging, but possible!

* What were some of the challenges in implementing an EMR?

Concept and form management is an ongoing challenge. Robust form design requires an iterative approach involving clinicians, data managers, and researchers. Getting patients reliably identified and avoiding duplicate identifiers, especially for an implementation that spans many different remote clinics, has been very challenging. Power and connectivity (or lack thereof) has required creative solutions and compromises. Integrating our EMR with external applications (ancillary systems) has required working closely with vendors and has been aided by OpenMRS' modular architecture. We owe most of our success to unwavering support ("buy-in") from leadership along with a dedicated and skilled team of implementers.

In response to Terry's comments on " 'adaptable forms' for data capture" I
respond that it is an objective of eHealth to get rid of the manual
paper-based forms for data capture and enter patient data direct to the
computer where the patient presents, either via a thin-client screen at the
hospital/clinic, or via a PDA-like device such as an iPhone at other
locations where the patient is - perhaps at home. Computerized data input is
far more flexible than forms, and entirely 'adaptable' to any format in any
country. Manual paper-based forms are not a "strength" - being just the
opposite. Addressing "field-proven application software" refers to health
application software that has been proven through tens of thousands of
end-user years of use, for superior system design does not come from
programmers - it comes from the users after use in hundreds of locations
over many years. Since all of the developed countries started to use
computers in health in the early 1970s there is lots of application software
to choose from. The PAS (Patient Administration System) software - the key
first clinical module - that am I referring to has been in use for over 30
years in the developed countries, and ...

In response to Terry's comments on " 'adaptable forms' for data capture" I
respond that it is an objective of eHealth to get rid of the manual
paper-based forms for data capture and enter patient data direct to the
computer where the patient presents, either via a thin-client screen at the
hospital/clinic, or via a PDA-like device such as an iPhone at other
locations where the patient is - perhaps at home. Computerized data input is
far more flexible than forms, and entirely 'adaptable' to any format in any
country. Manual paper-based forms are not a "strength" - being just the
opposite. Addressing "field-proven application software" refers to health
application software that has been proven through tens of thousands of
end-user years of use, for superior system design does not come from
programmers - it comes from the users after use in hundreds of locations
over many years. Since all of the developed countries started to use
computers in health in the early 1970s there is lots of application software
to choose from. The PAS (Patient Administration System) software - the key
first clinical module - that am I referring to has been in use for over 30
years in the developed countries, and 15 years in developing countries,
accordingly it can be expected to be very comprehensive, user-friendly, and
bug-free. All edits are accurately done at the point of data capture,
whether entered by a clerk, nurse or doctor. I hope that I have answered
your question to your satisfaction.

Andrew, I understand your hypothesis "that they (EMRs) need to be locally owned and supported", however I do not at all agree with such a hypothesis, for such an approach only sets the developing countries economically further behind the developed countries. Since it can easily be proven that better health is a major economic advantage for every country (Dr. Jeffrey Sachs, 2001 UN Millennium Project - 'Macroeconomics and Health: Investing in health for Economic Development'), the Open Source approach must be looked at closely from an economic perspective.

The unfortunate delays being encountered today in the developing countries in improving their health systems via eHealth is costing both lives and economic development for almost all of the developing countries. OpenMRS may in fact turn out to be an excellent 'EMR platform', and time will tell. I am referring to the 'feeder' systems for the EMR which are the application software modules (PAS; Pharmacy; General Ledger; Materials Management: Laboratory; Radiology; Business Intelligence; etc., etc., etc., which all exist today in the developed countries. Why would anyone wish to reinvent the wheel? You note that "Open source provides an opportunity for local capacity building, local modification, and local ownership of application and data ...

Andrew, I understand your hypothesis "that they (EMRs) need to be locally owned and supported", however I do not at all agree with such a hypothesis, for such an approach only sets the developing countries economically further behind the developed countries. Since it can easily be proven that better health is a major economic advantage for every country (Dr. Jeffrey Sachs, 2001 UN Millennium Project - 'Macroeconomics and Health: Investing in health for Economic Development'), the Open Source approach must be looked at closely from an economic perspective.

The unfortunate delays being encountered today in the developing countries in improving their health systems via eHealth is costing both lives and economic development for almost all of the developing countries. OpenMRS may in fact turn out to be an excellent 'EMR platform', and time will tell. I am referring to the 'feeder' systems for the EMR which are the application software modules (PAS; Pharmacy; General Ledger; Materials Management: Laboratory; Radiology; Business Intelligence; etc., etc., etc., which all exist today in the developed countries. Why would anyone wish to reinvent the wheel? You note that "Open source provides an opportunity for local capacity building, local modification, and local ownership of application and data" which is commendable in some respects, but not a very good economic strategy if it takes another 30 years to get to where the developed countries are today in Health Informatics. 'Health Informatics' and 'Reverse Engineer the Brain' are in the same group of 14 Grand Engineering Challenges for the 21st Century
http://www.engineeringchallenges.org/ , so one can see how difficult the challenge here is for the developing countries to develop their own HIS.

The developing countries will then be even farther behind. A friend of mine from Nigeria and I had the following dialogue with my comment at the beginning: "*The developing countries can then start to create new health application software modules to compliment the already existing HIS software. To try to create an HIS from scratch, in any developing country, would vastly hinder any progress in health informatics in the country so inclined to build its own HIS.*

I believe it works the same way wireless technologies, and GSM (Global System for Mobile Communications) in particular, helped connect Africa to the rest of the world, albeit, expensively. But I agree with you: instead of re-inventing the wheel, it is better to build on existing solutions.

There are today no developing countries where an HIS (Health Information System) has been implemented nationally in public health. In some developing countries such as India and Thailand the private hospitals are all highly computerized - just as advanced, or more so - than in the developed countries. This is strictly an economic issue, and not a technical issue. The other point that you raise "I think the other question is whether any ONE application can do everything anyway.." The answer - as you state - is NO. The concept of 'middleware' (an integration engine) was introduced to the health sector in 1995, permitting 'best-of-breed' - or as I call it 'best-of-budget' - application software modules from any number of specialized software vendors to be integrated into one overall HIS. Standards are important as you note, and deserve a lot of attention.

In reply to David's comment I would certainly agree that any package has
pros and cons. What I have tried to present are concepts that are 'food for
thought', with a focus on the economic side of such developments,
particularly when functionality and timeframes are taken into account.

Building on what exists today may provide economic advantages today, and
even bigger economic advantages in the future - when the scientists and
technicians in Africa have added the many important features to software and
methodologies that don't exist today.

Hi Hamish, Application software, when properly developed by a software
vendor, is very easy to implement in any country. I can name dozens of
software vendor firms that have done their development in their home country
and have easily moved the software to many other countries. Examples
include: Cerner (USA) >> UK hospitals; Alert (Portugal) >> UK hospitals;
Ormed (Canada) >> USA hospitals; Siemens (Germany) >> South Africa
hospitals; Meditech (USA) >> Canada, South Africa; ORION (New Zealand) >> UK
hospitals, Canada; Schuyler House (USA) >> 10 Caribbean countries: Heron
Technology (Canada) >> Jamaica, Montserrat, Dominica; iSoft (UK) >> Mexico;
etc., etc. Another interesting aspect of application software for
hospitals/clinics is that all 53 Commonwealth countries have today - and for
the past 150 years - have the same manual paper-based systems. We developed
our PAS in Canada in the 1980s, and when it was installed in Jamaica ( a mid
range developing country) in 1997 no changes to the software code were
required. A few 'tables' were changed such as Province was changed to
Parish.

All software vendors always support their own software products, and there
never is local software support, however there perhaps will be local
training and technical support. I think your comment about a 'modular' EMR
system ...

Hi Hamish, Application software, when properly developed by a software
vendor, is very easy to implement in any country. I can name dozens of
software vendor firms that have done their development in their home country
and have easily moved the software to many other countries. Examples
include: Cerner (USA) >> UK hospitals; Alert (Portugal) >> UK hospitals;
Ormed (Canada) >> USA hospitals; Siemens (Germany) >> South Africa
hospitals; Meditech (USA) >> Canada, South Africa; ORION (New Zealand) >> UK
hospitals, Canada; Schuyler House (USA) >> 10 Caribbean countries: Heron
Technology (Canada) >> Jamaica, Montserrat, Dominica; iSoft (UK) >> Mexico;
etc., etc. Another interesting aspect of application software for
hospitals/clinics is that all 53 Commonwealth countries have today - and for
the past 150 years - have the same manual paper-based systems. We developed
our PAS in Canada in the 1980s, and when it was installed in Jamaica ( a mid
range developing country) in 1997 no changes to the software code were
required. A few 'tables' were changed such as Province was changed to
Parish.

All software vendors always support their own software products, and there
never is local software support, however there perhaps will be local
training and technical support. I think your comment about a 'modular' EMR
system is possible, however not very practical, since the EMR has to be
supported by some firm/organization with whom the users work closely. A
'modular' HIS is absolutely the best way to go, since middleware will
connect application software modules from many specialized
developers/vendors.

One of the issue that concerns me most regarding "Global eHealth" is the lack of evaluation of almost any of the projects to indicate what is working and what needs to be changed. Between $3 and $5 Billion has been spent by development agencies like the World bank, USAID, PEPFAR, Global Fund etc. on eHealth projects in low and middle income countries in the last decade. Virtually all that money has been spent on proprietary systems or in house development with open source projects getting a very small fraction, but there is no obvious winner among proprietary EMRs, ADT, Lab systems or others. It would be useful to know how much was spent of organizations building their own systems from scratch however. One of the main points of an open source project is Not to build from scratch but reuse successful components from previous projects.

As we have discussed earlier on GHDonline, we are working to ensure there is evaluation data for OpenMRS and other systems in a variety of environments so that individuals and organizations can make informed choices.
Regards

Hamish

Hi, Everybody .Thank to the panelists for sharing their experience.
I’m an Italian MD. I graduated in Bologna University in 1981.
From the very beginning of my clinical and research activity as an anesthesiologist in cardiac surgery, I have been “dreaming” of giving my contribution to the development and implementation of an EMR for clinical and research purposes.
I haven’t reached my aim yet. Although, I’ve never quitted studying and monitoring the topic.
After 11 years as employee within the research field of the University of Chieti, I left it and, I turned into an entrepreneur, partnering with a software company and working mainly on proprietary information and decision support systems, whose purpose were, among others, e-health application .
My aim is to exploit my experience and be updated with the state-of-the-art development of IT for health. So, two years ago, after the company was wounded up, I started serving the European Commission as an expert evaluator for research and technology projects, funded under the FP7 framework program.
I agree with Ron Hebert , when he says “ Application software, when properly developed by a software vendor, is very easy to implement in any country”. However, there are thousands of ...

Hi, Everybody .Thank to the panelists for sharing their experience.
I’m an Italian MD. I graduated in Bologna University in 1981.
From the very beginning of my clinical and research activity as an anesthesiologist in cardiac surgery, I have been “dreaming” of giving my contribution to the development and implementation of an EMR for clinical and research purposes.
I haven’t reached my aim yet. Although, I’ve never quitted studying and monitoring the topic.
After 11 years as employee within the research field of the University of Chieti, I left it and, I turned into an entrepreneur, partnering with a software company and working mainly on proprietary information and decision support systems, whose purpose were, among others, e-health application .
My aim is to exploit my experience and be updated with the state-of-the-art development of IT for health. So, two years ago, after the company was wounded up, I started serving the European Commission as an expert evaluator for research and technology projects, funded under the FP7 framework program.
I agree with Ron Hebert , when he says “ Application software, when properly developed by a software vendor, is very easy to implement in any country”. However, there are thousands of proprietary EMR/EHR software around the world, and their problem is not that they don’t workproperly for specific or “general” purposes in a certain hospital or clinical pathway. Rather, their problem is that they are “siloed”, namely they neither share a common infostructure (reference model), nor are modular parts of an ecosystem of different applications. Plus, they behave like a sort of “animal specimens in a zoo”. As a consequence, they are not able to exchange “structurally organized data” and, finally - let me use this term - they possess this “autistic” nature, as their “parents” would want them to be like that.
Reversing this kind of architecture when it has already been implemented and data have populated the system could be technically possible, but it is not plausible for many reasons (e.g. would you take pieces of the Colosseum to build up the tower of Pisa?)
In my opinion, semantic data interoperability is currently one of the main issues that high income countries are coming across in the broader e-health domain .
Developing countries (but also the high income countries too, which have currently reached an e-health adoption level which is still below average) could be spared by this mess, enjoying the “quantum leap” offered to those who are not restrained by legacy systems.
I can say that It is possible to hypothesize a gamut of solutions to be promoted in this settings:

One is to reproduce what Microsoft has made to the PC environment, that is, imposing a monopoly for general purposes and business applications, to the whole world. This paradigm shows some gaps, nowadays. In fact we wouldn’t even imagine something like that, notably in the medical field, where no obvious winner among proprietary EMRs, ADT, Lab systems or others emerged despite 'best-of-budget' application software have been funded with huge amounts of money.

Another one is to crowdsource modular OSS EMR system and mobile applications. That means, both of them would be supported by some community of developers / implementers / educators / trainers, including also available firms with whom the users work closely.
I believe that this is the topic that needs to be expanded, and I look forward that an increasing portion of investments, made both by development agencies and the European Commission, will fund its boost both in high and low income settings as soon as possible.
With this premise, I carried out a deep desk research using environmental scanning in four selected areas ( i.e. Technology and Applications, Medical and Clinical Guidelines, User Acceptance, number and implementations’ locations, and Security, Socio-Economic and Policy Framework).
My vision is somehow radical and, synthetically. I’ll outline it hereafter:
1. OSS is the solution on which to work with (o on which to work, o to work with!!meglio la seconda) for a sustainable future global e-health. The Momentum is changing and I believe that many developers and vendors will understand that participating as an “atom” in a huge global market can give them bigger revenues at lower risks than trying to keep a local market under their thumb. This means that all the people working in the e-health field are invited to address , join and share incremental and evolutionary targets. These challenge them in switching the paradigm from proprietary to open source software.
2. Between several other options, OpenMRS is my favorite (as a EMR/PHR platform). The reasons sustaining my choice are many and I have very little to add to this panel, apart from considering the active OpenMRS community as a competitive advantage ;
3. Needless to say that OSS (e.g. OpenMRS , Sana platform for mhealth ) has pros and cons, compared to proprietary software and both of them need to be adequately addressed.
However, there are still some issues which could serve as a checklist in order to draw guidelines for newcomer implementers:
• I live in a country where e-health is still underfunded, snoozing in the hands of inconclusive commissions. Issues such as medical uptake, user acceptance, security, organization, quality of healthcare, reimbursement, etc. are far to be effectively addressed by the decision makers;
• I’m an expert bridging the gap between medical knowledge and information technology;
• I’m not an OpenMRS implementer yet, although I want to contribute to make the platform succeed at scale.
• I had the opportunity to test by myself only partially OpenMRS. Honestly, I found it not that easy to do and to create mock use cases, in order to put modules and functionalities together, without experts support.
• I am willing to propose ready-to-use OS solutions to stakeholders in the medical field. Some of them whom I met are eager to solve their practical problems and are confused by concomitantly using three or four proprietary systems in the clinical setting, each accomplishing a vertical and siloed application.
• I got some attention when talking about OpenMRS and Sana platform for e-health to local health Authorities and I consulted some software developers in Italy who are available to support me technically and build custom implementations.
• I’m available to travel towards those who invite me in order to cooperate wherever is possible to exchange experiences.
• I can be autonomously funded for this investment in further education, practice and cooperation.
• I would like to be involved in field work and, after adequate training, to become an implementer, a trainer and a developer.
• I‘m also available to start from contributing to structure the information contained in the manual paper-based system, that all 53 Commonwealth countries possess today.
• I can start these activities in few months.
Regards

I think it is important as part of this discussion to consider the competitive landscape in terms of open-source electronic health records targeted to developing countries.

OpenMRS needs to be viewed as one of many possible competing solutions in the marketplace. This discussion - or a future one - should also compare the strengths and weaknesses of OpenMRS against the competing alternatives in a transparent and unbiased manner. If there are no other alternatives at the same level of development, that should be a red flag to the international health IT community.

It is critical that health IT investment funds be directed to ensuring the health IT software marketplace consists of multiple competing vendors -- each with real, enterprise-grade systems, and not homegrown MS Access databases. International health IT solutions have to be bought and sold in the context of a global enterprise software marketplace, rather than be treated as a charitable or humanitarian undertaking.

Such systems need to be purchased and implemented using a solution-oriented paradigm, with appropriate investments in the consulting, professional services and technical support systems that are critical-to-success for enterprise software implementation and maintenance.

The current donor aid model impairs long-term market development and only reinforces dependency on handouts ...

I think it is important as part of this discussion to consider the competitive landscape in terms of open-source electronic health records targeted to developing countries.

OpenMRS needs to be viewed as one of many possible competing solutions in the marketplace. This discussion - or a future one - should also compare the strengths and weaknesses of OpenMRS against the competing alternatives in a transparent and unbiased manner. If there are no other alternatives at the same level of development, that should be a red flag to the international health IT community.

It is critical that health IT investment funds be directed to ensuring the health IT software marketplace consists of multiple competing vendors -- each with real, enterprise-grade systems, and not homegrown MS Access databases. International health IT solutions have to be bought and sold in the context of a global enterprise software marketplace, rather than be treated as a charitable or humanitarian undertaking.

Such systems need to be purchased and implemented using a solution-oriented paradigm, with appropriate investments in the consulting, professional services and technical support systems that are critical-to-success for enterprise software implementation and maintenance.

The current donor aid model impairs long-term market development and only reinforces dependency on handouts -- as does the 'free' software movement. Rich countries are sending mixed messages to local developers by promoting the use of 'free' software, and then sending (relatively) highly-paid consultants to deliver this message.

Software developers everywhere in the world should earn real money from participating in a real labor market, where they build, sell and maintain software within a real healthcare IT marketplace. These are critical skills that are undermined by the donor aid paradigm.

Unless a real health IT marketplace is developed, OpenMRS -- despite best intentions -- also risks turning in the long-term into the Microsoft, Google or Facebook of international healthcare, with potentially the same level of entrenchment and sense of unchallenged entitlement to market share.

The risk is the international health IT community will create a structural risk arising from the monopolistic influence of having a single dominant vendor. It will also create a type of vendor 'lock-in' -- where the OpenMRS 'paradigm' for what is considered standard architecture for an EHR system becomes accepted and unchallenged.

Another risk is that the OpenMRS community of supporters will split into factions or separate competing groups, resulting in a spaghetti code of unmaintainable and incompatible forks and branches in the code base. There already appears to be lots of 'customizations' in the field, which will create serious maintenance, upgrade and interoperability problems going forward.

OpenMRS currently has a legacy architecture and poor interoperability capabilities. It's core resembles a monolithic software application, rather than providing a platform or component-based services-oriented architecture. The interoperability work undertaken to date seems fairly ad hoc.

Interoperability standards will be critical in moving toward a more modern architecture, and this is where the healthcare industry is still in the dark ages, with HL7 representing an unsuitable candidate for international use.

Appropriate interoperability standards will spur innovation that will lead to a robust marketplace of healthcare IT vendors competing on price and quality. Over-reliance on a single vendor will lead to complacency, stagnation, bureaucracy, and eventually raise important antitrust concerns.

Its unclear whether the initiative's current governance model can address such scalability challenges - its really a question about the organizational capacity and strategic roadmap of stakeholders backing OpenMRS.

Given its current market presence, OpenMRS is well-positioned to provide a starting point for new standards development work, but it really depends on the priorities of international health IT funders and their willingness to make long-term investments in developing the healthcare IT software marketplace globally.

Hello Mikhail, Your comments are right on the mark in my opinion, for I have
been in health informatics now for 40 years fulltime, with 150+ HIS
implementations under my historical responsibility, in both the developed
and developing countries, so I have seen and heard a lot of ideas -
including from current OpenMRS contributors - that did not, and will not
stand the test of time, based mainly on economic principles.

Insofar as this session is still underway, I would like to reserve my
summary comments until this session has closed, and I will comment further
then if possible.

--------------------------------------------------
From: "GHDonline (Mikhail Elias)" <>
Sent: Saturday, May 19, 2012 4:47 PM
To: "Ron Hebert" <>
Subject: Re: [Health IT] Expert Panel: OpenMRS Implementers: Experiences and
Lessons Learned, May 14th to 18th 2012.

> Mikhail Elias replied to the discussion "Expert Panel: OpenMRS
> Implementers: Experiences and Lessons Learned, May 14th to 18th 2012." in
> the Health IT community.
>
> Reply contents:
> "I think it is important as part of this discussion to consider the
> competitive landscape in terms of open-source electronic health records
> targeted to developing countries.
>
> OpenMRS needs to be viewed as one of many possible competing solutions ...

Hello Mikhail, Your comments are right on the mark in my opinion, for I have
been in health informatics now for 40 years fulltime, with 150+ HIS
implementations under my historical responsibility, in both the developed
and developing countries, so I have seen and heard a lot of ideas -
including from current OpenMRS contributors - that did not, and will not
stand the test of time, based mainly on economic principles.

Insofar as this session is still underway, I would like to reserve my
summary comments until this session has closed, and I will comment further
then if possible.

--------------------------------------------------
From: "GHDonline (Mikhail Elias)" <>
Sent: Saturday, May 19, 2012 4:47 PM
To: "Ron Hebert" <>
Subject: Re: [Health IT] Expert Panel: OpenMRS Implementers: Experiences and
Lessons Learned, May 14th to 18th 2012.

> Mikhail Elias replied to the discussion "Expert Panel: OpenMRS
> Implementers: Experiences and Lessons Learned, May 14th to 18th 2012." in
> the Health IT community.
>
> Reply contents:
> "I think it is important as part of this discussion to consider the
> competitive landscape in terms of open-source electronic health records
> targeted to developing countries.
>
> OpenMRS needs to be viewed as one of many possible competing solutions in
> the marketplace. This discussion - or a future one - should also compare
> the strengths and weaknesses of OpenMRS against the competing alternatives
> in a transparent and unbiased manner. If there are no other alternatives
> at the same level of development, that should be a red flag to the
> international health IT community.
>
> It is critical that health IT investment funds be directed to ensuring the
> health IT software marketplace consists of multiple competing vendors --
> each with real, enterprise-grade systems, and not homegrown MS Access
> databases. International health IT solutions have to be bought and sold in
> the context of a global enterprise software marketplace, rather than be
> treated as a charitable or humanitarian undertaking.
>
> Such systems need to be purchased and implemented using a
> solution-oriented paradigm, with appropriate investments in the
> consulting, professional services and technical support systems that are
> critical-to-success for enterprise software implementation and
> maintenance.
>
> The current donor aid model impairs long-term market development and only
> reinforces dependency on handouts -- as does the 'free' software movement.
> Rich countries are sending mixed messages to local developers by promoting
> the use of 'free' software, and then sending (relatively) highly-paid
> consultants to deliver this message.
>
> Software developers everywhere in the world should earn real money from
> participating in a real labor market, where they build, sell and maintain
> software within a real healthcare IT marketplace. These are critical
> skills that are undermined by the donor aid paradigm.
>
> Unless a real health IT marketplace is developed, OpenMRS -- despite best
> intentions -- also risks turning in the long-term into the Microsoft,
> Google or Facebook of international healthcare, with potentially the same
> level of entrenchment and sense of unchallenged entitlement to market
> share.
>
> The risk is the international health IT community will create a structural
> risk arising from the monopolistic influence of having a single dominant
> vendor. It will also create a type of vendor 'lock-in' -- where the
> OpenMRS 'paradigm' for what is considered standard architecture for an
> EHR system becomes accepted and unchallenged.
>
> Another risk is that the OpenMRS community of supporters will split into
> factions or separate competing groups, resulting in a spaghetti code of
> unmaintainable and incompatible forks and branches in the code base. There
> already appears to be lots of 'customizations' in the field, which will
> create serious maintenance, upgrade and interoperability problems going
> forward.
>
> OpenMRS currently has a legacy architecture and poor interoperability
> capabilities. It's core resembles a monolithic software application,
> rather than providing a platform or component-based services-oriented
> architecture. The interoperability work undertaken to date seems fairly ad
> hoc.
>
> Interoperability standards will be critical in moving toward a more modern
> architecture, and this is where the healthcare industry is still in the
> dark ages, with HL7 representing an unsuitable candidate for international
> use.
>
> Appropriate interoperability standards will spur innovation that will lead
> to a robust marketplace of healthcare IT vendors competing on price and
> quality. Over-reliance on a single vendor will lead to complacency,
> stagnation, bureaucracy, and eventually raise important antitrust
> concerns.
>
> Its unclear whether the initiative's current governance model can address
> such scalability challenges - its really a question about the
> organizational capacity and strategic roadmap of stakeholders backing
> OpenMRS.
>
> Given its current market presence, OpenMRS is well-positioned to provide a
> starting point for new standards development work, but it really depends
> on the priorities of international health IT funders and their
> willingness to make long-term investments in developing the healthcare IT
> software marketplace globally."
>
> --
> View this post online:
> <http://www.ghdonline.org/tech/discussion/expert-panel-openmrs-implementers-ex...>
>
> Unsubscribe or change your email notification settings:
> <http://www.ghdonline.org/users/ron-hebert/edit/>
>
> Contact the GHDonline team:
> <http://www.ghdonline.org/contact/>
>
> You can reply to this discussion by responding directly to this e-mail; it
> will be shared with all community members and posted as is. Files cannot
> be added via email attachment and must be uploaded directly to GHDonline.
>
>

In summary, there are many options and alternatives for medical records systems. They may not be a perfect fit for every health care organization. There will always be things that we wish would be different or could be changed. OpenMRS has been a good "force" fit for Hospital Albert Schweitzer Haiti. (I say "force" fit because we decided to make OpenMRS work for us rather than making programming changes.)

The greatest benefit of OpenMRS is the community around which it revolves. The community is a source of wisdom and knowledge of how to use OpenMRS best (and even more generally, how to collect/report data best). As being fairly new in medical informatics, I have learned a ton from them! It is made up of implementers and programmers around the world. It is made up of people who are truly interested in the best clinical treatment of patients, especially those in underprivileged situations. I give OpenMRS my highest vote of confidence. It is a pleasure to call myself an OpenMRS implementer.

As the Moderator for the recent Expert Panel discussion on OpenMRS implementation I would like to thank all participants.
Firstly, to the panel members, Evelyn Castle, Burke Mamlin, Dave Thomas and James Arbaugh I would like to express on behalf of GHDonline our deepest thanks for your commitment of time, energy and knowledge. We are aware of your daily commitments to your ‘routine’ daily activities, not that they are routine by normal standards. Therefore your desire and willingness to be a panel member cannot be underestimated or undervalued.
The online discussion was extensive and revealed much of what is probably not clearly understood about this complex process of Health IT implementation both in developing and developed economies.
The value of the interactions was demonstrated by those who chose to participate in the discussion and add their knowledge and insights on this topic. To these people we also say thanks.
The importance of this topic has led to the creation of a Discussion Brief which will be submitted to the site in coming weeks after all the topics in the discussion have been correlated. Terry Hannan

Ron I disagree with your comment about "OpenMRS may in fact turn out to be an excellent 'EMR platform', and time will tell. I am referring to the 'feeder' systems for the EMR which are the application software modules (PAS; Pharmacy; General Ledger; Materials Management: Laboratory; Radiology; Business Intelligence; etc., etc., etc., which all exist today in the developed countries. Why would anyone wish to reinvent the wheel?"

Issues like business intelligence are just but new int the US. In the oncology clinic i sit in there is a big patient file, with dictations at the end of the day

One observation is the presumptions that the 'experts' bring with to developing countries. The model of health care in the west is mainly financially driven, hence the emphasis and motivation for codified systems. Patient outcomes and quality indicators are now an agenda due to the compensation received for these initiatives. Health information exchanges are just but at the phase of being implemented

Local ownership, understanding workflows can assist implementers. I was an implementer before graduate school, and with medical training, concepts and terminologies were a big challenge. I would like to see more effort on understanding workflows around patient care ...

Ron I disagree with your comment about "OpenMRS may in fact turn out to be an excellent 'EMR platform', and time will tell. I am referring to the 'feeder' systems for the EMR which are the application software modules (PAS; Pharmacy; General Ledger; Materials Management: Laboratory; Radiology; Business Intelligence; etc., etc., etc., which all exist today in the developed countries. Why would anyone wish to reinvent the wheel?"

Issues like business intelligence are just but new int the US. In the oncology clinic i sit in there is a big patient file, with dictations at the end of the day

One observation is the presumptions that the 'experts' bring with to developing countries. The model of health care in the west is mainly financially driven, hence the emphasis and motivation for codified systems. Patient outcomes and quality indicators are now an agenda due to the compensation received for these initiatives. Health information exchanges are just but at the phase of being implemented

Local ownership, understanding workflows can assist implementers. I was an implementer before graduate school, and with medical training, concepts and terminologies were a big challenge. I would like to see more effort on understanding workflows around patient care. As an intern i had an average of 30 children to see every night in my clinic, and if anyone asked me to type in my notes (direct data entry) i would never agree to this. The work was too much, and i would say i type in more than one word per second. How can we implement systems that make such a health worker effective?

Hi Prof. Terry Hannan,
I am Emran from GIZ, Health sector programme, Bangladesh. I randomly
followed the very useful and rich discussion on Open MRS. I also forwarded
to some of our colleagues. Do you have plan to compile all the discussions
into one document? It may act as a good reference documents for future
users of Open MRS.

Regards
Emran

Emran, thank you for this positive response. As Moderator I also as did others find that this was an informative and vigorous discussion.
I have already begun with my colleagues to compile a discussion brief to be posted to the site soon.
I have also collected all the Reply statements and can consider putting them in a single document however I believe these remain on the GHDonline site for permanent access. Terry

Not sure if this is a relevant topic to raise but I am sure relevant answers will follow.

In the organization I was working for they were using Care2x as their primary HMIS tool and had expanded to a number of sites within Tanzania. I am not into figures as I am neither their spokesperson nor an employee there but they had more than one consultant hospitals, about six(6) regional/district hospitals and a couple of smaller health facilities.

The project was semi-dependent as it was run by donor-funds while being on transition to self-sustained mode via charging for service delivery to the hospitals that are willing to participate in the project. What was done there was not government supported thus the need for a central server was minimal even though the capacity to do so was/is still there as the entire tool is web-based and MySQL databases are constantly synced with a central backup server.

As to why I am posting this, my role in that project was an analyst in my early years there, at one point I raised the issue of riding a healthier horse which in my opinion was seeking a better HMIS tool ...

Not sure if this is a relevant topic to raise but I am sure relevant answers will follow.

In the organization I was working for they were using Care2x as their primary HMIS tool and had expanded to a number of sites within Tanzania. I am not into figures as I am neither their spokesperson nor an employee there but they had more than one consultant hospitals, about six(6) regional/district hospitals and a couple of smaller health facilities.

The project was semi-dependent as it was run by donor-funds while being on transition to self-sustained mode via charging for service delivery to the hospitals that are willing to participate in the project. What was done there was not government supported thus the need for a central server was minimal even though the capacity to do so was/is still there as the entire tool is web-based and MySQL databases are constantly synced with a central backup server.

As to why I am posting this, my role in that project was an analyst in my early years there, at one point I raised the issue of riding a healthier horse which in my opinion was seeking a better HMIS tool (I specifically said OpenMRS). I did not have any backup evidence on OpenMrs being a healthier choice other than that my friends over GTalk and Social networks were mostly blah blah-ing about it. Care2x on the other hand had/still has a quite 'moot' community support in terms of implementers and users. Most forums established for it have nothing going on in them. Some other parties whom we used to work with came against that idea and asserted some issues about OpenMRS, such issues as:

It is primarily for epidemiological records (eg TB and HIV)
Having very few (in-country) developers (I think a point was raised about it being in Java) compared to PHP-MySQL technologies used in Care2x.

As I said I did not have any solid evidence on OpenMRS being a healthier choice, I was not able to convince the project to switch tools. This very discussion has given me such an insight as to how responsive the community surrounding this EMR is plus the fact that it has gained usage and attention in a lot of places. I do not say that Care2x is not a reliable tool anyway, It has been deployed in some hospital to almost(paper-less) level. It is an open source EMR and it has shown that it can work with other tools if necessary (In one hospital they have a different Financial MIS tool - WebERP) to achieve some specific and well handled transactions.

What I am asking?
For those who are familiar with both systems (others can read the links I have included to see how far is the other EMR gone), is it a viable choice for one to choose OpenMRS as a healthier horse and abandon Care2x(In a strategic shift of-course)? If yes to question one, for the projects that have invested heavily in Care2x, is the switch worth the sunk-costs? If no/uncertain, isn't it almost proven that having alternatives is a better thing for the end-users?(I have asked this as I have seen some over-enthusiastic members dreaming of OpenMRS becoming a one-and-only choice in the future)

Hello Judy, My comments relate to the 'development' of 'feeder' systems (to
an EHR) application software modules - such as a Patient Administration
System, Pharmacy, etc. - which have existed for over 30 years in all of the
developed countries, and have been enhanced considerably by the feedback
from end users. The developing countries could use this same software to
start to benefit now from the great economic advantages that enhanced health
systems bring to all countries. My point is - why wait another 10 years to
start to receive the economic benefits which are being experienced today by
all of the developed countries! Also, the developing countries do not spend
as large a percentage of their budgets on health care as do the developed
countries. An example would be Kenya vs Canada. Kenya spends 5.8% on health
vs Canada which spends 17.2%. Incidentally, the health systems in Canada -
and in the other Commonwealth countries - are essentially the same, and are
not overly 'financially' driven, for we have a universal government-led
health system in Canada, and patients do not have to pay anything to receive
services at a hospital or doctor's office.

I am not referring to clinical notes - as ...

Hello Judy, My comments relate to the 'development' of 'feeder' systems (to
an EHR) application software modules - such as a Patient Administration
System, Pharmacy, etc. - which have existed for over 30 years in all of the
developed countries, and have been enhanced considerably by the feedback
from end users. The developing countries could use this same software to
start to benefit now from the great economic advantages that enhanced health
systems bring to all countries. My point is - why wait another 10 years to
start to receive the economic benefits which are being experienced today by
all of the developed countries! Also, the developing countries do not spend
as large a percentage of their budgets on health care as do the developed
countries. An example would be Kenya vs Canada. Kenya spends 5.8% on health
vs Canada which spends 17.2%. Incidentally, the health systems in Canada -
and in the other Commonwealth countries - are essentially the same, and are
not overly 'financially' driven, for we have a universal government-led
health system in Canada, and patients do not have to pay anything to receive
services at a hospital or doctor's office.

I am not referring to clinical notes - as you describe - for this type of
information continues to be accumulated on manual paper-based documents in
almost all of the developed countries, as I observe here in Canada when I
visit a hospital or my doctor's office. As you note, understanding workflows
is very important, and in some advanced developed countries workflows are
being computerized now following 40 years of computer usage and experience.