Third-party infrastructure
Evaluating open-source clinic infrastructure.
OpenEMR and Cal.com are open-source projects built by their respective communities — not authored by Lloyd. What is his own work here is narrow: importing each platform for evaluation, and analysing OpenEMR's role-based access model against how a real clinic's roles actually work.
What was evaluated
Two platforms, two different questions
A clinic booking product needs either a scheduling layer or a full EMR, depending on scope. Both categories have mature open-source options, so the evaluation started there rather than from a blank page.
Open-source electronic medical record system
A mature, widely-deployed EMR. Imported for evaluation of its data model and access-control system — not modified or extended.
Open-source scheduling infrastructure
The self-hostable community edition of Cal.com. Evaluated as a scheduling layer; no changes were made to the upstream codebase.
The one original piece of analysis
Mapping OpenEMR's access control onto real clinic roles
OpenEMR ships a role-based access control layer (gacl). The useful question for a clinic product isn't whether that layer exists, but whether its role definitions match how a clinic's front desk, clinicians, and admin actually divide work — which required walking the permission model against a real operational structure.
This produced a role-by-role workflow analysis: which OpenEMR permissions map cleanly onto front-desk, clinician, and admin responsibilities, and where the built-in roles are coarser than a real clinic needs. That analysis — not the EMR itself — is the output worth showing.
Let's build the next healthcare system.
I'm running a multi-site hospital equipment-tracking and analytics system in production, and I'm open to healthcare data, analytics, AI, and application engineering roles — remote, hybrid, or on-site. The best way in is a short conversation.
Start a conversation