What is medical ocean 🌊

This is why I decided to build an electronic health (patient) record system instead of buying.

I confess to be an internet addict and Open Source software fan. Early in the infancy of open source projects I stumbled on a project called Care2X around the year 2002. That was a Devine moment for me, like finding a gold mine, birds and angels singing. Built using the LAMP stack when PHP was a the thing. on top of Drupal CMS. However, the project is sadly not actively maintained and feels like heading to the open source grave yard. RIP CARE2X.

Care2x sourceforge page

Fast forward, I tried building my own database using FileMaker 12 for our family practice. In 2015, we started using cliniko as an EHR, it was amazing for a solopractice easy to use and navigate system, great notifications and amazing appointments and billing functionality. But, clinically Cliniko fails miserably when it comes to clinical notes, no coding no CDSS and no standard.

Three years later 2018, I teamed up with Mekom solutions (brilliant team understands open source healthcare) involved in OpenMRS and Bahmni dev. They customized a version of OpenMRS for our use case.

Buy VS Build

Deciding between buying an off-the-shelf Electronic Health Records (EHR) system or building a custom one is a significant decision for healthcare organizations. Here are some key factors to consider in the “buy vs. build” debate for EHR systems:

Buying an Off-the-Shelf EHR System

1. Time to Implementation: Commercial EHR systems are typically ready for quicker deployment compared to building one from scratch. This can be crucial if there’s an urgent need to digitalize patient records.
2. Proven Reliability and Functionality: Off-the-shelf EHR systems usually come with a track record of performance, having been tested and used in real-world settings.
3. Compliance and Security: Established EHR vendors often ensure their systems are compliant with healthcare regulations like HIPAA in the U.S., and they invest in strong security measures.
4. Cost: The initial cost may be lower compared to building a system, but recurring costs for licenses, updates, and support should be considered.
5. Vendor Support: Provides professional support and training, which can be beneficial, especially for organizations without extensive IT resources.
6. Limited Customisation: While some customization is possible, these systems may not fit perfectly with every unique workflow or need of an organization.

Building a Custom EHR System

1. Tailored Solutions: A custom-built EHR can be designed to fit the specific needs and workflows of the organization, offering more flexibility and efficiency.
2. Integration with Existing Systems: It can be tailored to integrate seamlessly with other software systems already in use.
3. Long-term Cost Efficiency: While the upfront cost is usually higher, over time, owning the software can be more cost-efficient as there are no ongoing license fees.
4. Scalability and Adaptability: A custom system can evolve with the organization’s needs without being dependent on a vendor’s update cycle.
5. Resource Intensive: Requires significant investment in terms of time, money, and skilled IT staff for development, testing, and maintenance.
6. Compliance and Security Challenges: The organization is responsible for ensuring that the system meets all regulatory compliance and security standards, which can be complex and resource-intensive.

The decision largely depends on the specific needs, resources, and long-term strategy of the healthcare organization. Buying an off-the-shelf EHR offers quicker deployment and proven reliability, but may lack customisation. Building a custom EHR provides tailored solutions but requires more resources and carries greater responsibility for maintenance and compliance. Often, organizations conduct thorough cost-benefit analyses and consider their IT capabilities and future growth plans to make this decision.

EHRs are not born equal. not every EHR on the internet works in reality. Many of the EHR systems lack the auditing. roles in authentication and authorisation. terminology and clinical coding.

Now that is the minimum requirement for viable true EHR. Followed by clinical decision support systems (CDSS), automations, customised workflows, Notifications and dictation.

After all of that, if you are building you need to do some shopping. choose your standard, you terminology servers, infrastructure and devOps etc…

I always think of the EHR standards. HL7 FHIR, OpenEHR, schema.org, ISO, openMobile to name a few. FHIR is like MySQL (the most popular) on the other hand OpenEHR is like Postgres (the most advanced). FHIR is more focused on developers and follows the 80/20 principle but OpenEHR focuses on clinicians and follows a maximum data set (max clinical points).