POC: Private Hospital EMR (Electronic Medical Record) System

This is a POC project for a custom EMR system to replace the aging and fractured digital and paper medical record system currently in place for a hospital network. The new solution will better facilitate Doctor <> Patient, Doctor <> Doctor, Patient <> Laboratory, and Doctor <> Laboratory communications, follow up, and record keeping.

Project details

Problem Or Issue To Solve

The current system for tracking Doctor <> Patient <> Laboratory interactions is spread across multiple systems and oftentimes handled by manual processes such as shipping of laboratory results. Because of this, results and follow ups can be delayed more than necessary. The hospital needed a new EMR to facilitate faster communication, better data and record integrity, and enhanced security.

Solution

As there are existing systems and procedures, a solution needed to be developed that would allow for a transition of historical information as well as maintain record continuity through the transition of the old system to the new system. A custom EMR was created that facilitates a streamlined approach for Doctors/Patients/Laboratories while maintaining access and integrations to the historical systems until they can be moved into the new data structure. This was all done while updating security standard and maintaining HIPAA compliance.

Technologies

The plan was to create a distributed architecture of microservices domains based on each department in the hospital. Preparing the system to not only take the current load from the current inside use of the system but also be ready for external access by third-party providers, doctors, and partner clinics.
We met with the hospital´s IT division to discuss the current system and create a complete chart as the initial point of the system design. From there, we identified the different areas to create a possible microservice list to be developed and to be able to visualize the various data connections between the services.
We separated the microservices between transactional type (CRUD operations to databases, third-party integrations, system telemetry, etc.) and data processing (reports, daily summary, image processing, file generation, etc.). This ultimately would determine the technology we would use: NodeJS for quick development of transactional endpoints and Python or PowerBi for any data-related needs on data processing services.
From there, we analyzed the data structures currently being saved on the system and determined the best way to store them (NoSQL, SQL, or file storage); with any third-party tools required for communication, we completed our Kubernetes cluster for each service.
This created a solution ready to be deployed to any cloud provider or even on-premise

Team Composition

Results

Notes

Most Recent Entries

All 3 /Alternative medicine 1 /EHR 2 /HealthTech 3 /Lab software 2