Home - nstudt/corpin-emr GitHub Wiki

Introduction

The project originated in September 2018, after I was unable to find an EMR solution for our healthcare system on a rather rural island in the Philippines. Due to the sporadic nature of Internet services and coverage, the primary requirement was offline first capability.

Two potential solutions were evaluated at length: _HopitalRun _and OpenEMR.

While OpenEMR does not support offline capabilities out of the box, it would be feasible to fork the project to do so. Unfortunately, the interface scared aware the physicians and the PHP code base is not worth hacking.

HospitalRun was a noble effort and served as inspiration for corpin-emr. Unfortunately, the project was emberfy'd making it impossible to replace the view layer. The second problem was, that it didn't actually work. It did provide some direction for base technologies though. Namely, pouchdb and electron.

Requirements Technology in medicine is mostly absent in the Philippines. The ubiquitous poverty and lack of government funding does not provide a good basis for technology. as such, the local hospitals are based mostly on the old-style of paper-records system and such is the case in the province of Suirgao del Nore, in the southern Philippines. The pilot site is JDC Clinic, a small, but very busy private clinic that provides healthcare to over 10k island residents. The namesake of the project, Dr Chloe Digal-Corpin is the sole practicing physician at the clinic and also provides medical mission services to the remote areas of the island. The medical missions require records access to existing patients data, which is not feasible on a paper-system that is based at the clinic. Thus, the first goal of the application:

  • Provide easy access to historical patient records. Additional requirements, specific to regional requirements are:
  • Ease of use. Scheduling, patient portals, e-prescribe and other high-tech appurtenances are not required.
  • Optimized workflow. Every aspect of Corpin-EMR should consider how the clinic/hospital and physician work and facilitate that workflow, not modify it to fit the technology. Thus, Corpin-EMR is designed to help the physician - providing automation, improved accuracy and efficiency.
  • Offline use. All applicable data must be available offline. Not HTML offline, where the application is active and connection is lost, but fully offline, when the computer is booted and application started without an Internet connection.
  • Multi-client capability. A reasonable number of distinct clients need to be supported in a master-less data model.
  • Data partitioning. While JDC Clinic is the only current subscriber, multi-branch, department and distinct organizations need to be supported for the future. The data must support appropriate partitioning and access control of the data to facilitate the legal relationships of the consumers. For example: JDC may need ubiquitous access to all data across multiple branch clinics, while a regional hospital should be allowed to submit a request for patient data to another entity who owns the patient data.
  • Data Considerations. Proper handling of patient data is the primary concern of the application. Replication to a centralized cloud server and backup and rapid recovery, along with basic journal is critical to allow relaxed point-in-time restore of the central data. Further, replication to and from the clients should be transparent to the user. Timeliness of replication is not a critical factor. Security is a concern, but the application does not need to meet HIPA compliance. Technical Implementation The client consists of a self-contained node.js/express/hbs/pouchdb application, which will be wrapped in Electron to facilitate ease of deployment and use. No additional frameworks are required. The server consists of two components.
  1. An ubuntu 16.04 server running a docker image of CouchDB.
  2. A distinct client implementation on a separate server that allows browser access from any client with an Internet connection. Patterns used for coding are Functional MVC, with the express intent of allowing replacement of individual components in the future, should better solutions arise.