I wanted to introduce a project I’ve been building, MedikQuantis (https://medikquantis.me): a free, open-source collection of validated clinical calculators. It currently covers around fifty scores, including CHA2DS2-VASc, CKD-EPI, SCORE2, MELD and NIHSS.
It started because I wanted validated scores that were actually usable at the bedside, and it grew from there. A few things that make it a bit different from the usual calculator sites:
Every score is cited from the original paper, not from a secondary source.
It is trilingual (Catalan, Spanish and English). Most open calculators are English-only, and that gap matters more than it sounds.
There is a free REST API and SMART on FHIR support, so it can be embedded rather than just visited.
The whole thing is MIT-licensed and has a permanent Zenodo DOI.
If you work on clinical decision tools, terminology, or anything in this space, I would genuinely like to hear how you handle the boring-but-important parts: keeping scores in sync with guideline updates, citing sources properly, and validating across languages. And if any of the calculators would be useful to you, they are all open.
Love the work you’ve done on MedikQuantis - it is something that has been needed for decades but the health tech industry seems to have been very slow to see the need. Similarly, governments, regional and national health agencies and similar have also failed to grasp the need here.
It’s infrastructural stuff - we should not be implementing all of these clinical calculators again and again inside proprietary EHR systems, there should be reusable, shared, open-source libraries of clinical calculator code published by trusted organisations, either for direct integration into EHRs or for consumption as APIs.
There is even a business model around providing these APIs which can make it sustainable, as demonstrated by the RCPCH Digital Growth Charts, which has a revenue-generating model around the API, at a cost which is fair and sustainable both ways - on the consumer and on the provider.
It is not good enough for EPR vendors (and those people who procure EPRs on clinicians’ behalf) to assume we as clinicians will be happy to manually input data into MDCalc, and manually transcribe the results back into the EPR - forever.
It’s dangerous (even though it never gets a risk assessment and avoids medical device registration)
It’s slow (even though nobody seems to care how much our bad computers slow down clinical care)
Other work that’s going on in this area that you might find of interest is listed below. I think it would be great to try to establish some simple functional standards around the way data flows in these tools so that we end up with a low-friction, implementable standard with several reference implementations in different languages, all of which have a similar ‘contract’. That way we can build convention and consensus around how we handle:
extensible internationalisation and multilingual options
ensuring library-level implementation → :right CLI implementation → GUI implementation → API implementation are fluid and don’t require re-engineering
open source licensing so that these calculators are available to the entire world
provenancing of the underlying reference data, algorithm, calculation, and implementation to assure quality and safety
communication of this provenancing and safety assurance in a way that makes computable Medical Device Registration much easier. Currently the global variation in Medical Device regulation rules makes it very hard to integrate “someone else’s code” into your EPR or app without introducing risk.
Publication: What we really need is for a trusted global authority to fund and publish these: WHO? UN? Linux Foundation?
This application appears to support industry infrastructure - the comment ‘SMART on FHIR’ may imply it can be launched from an EHR (probably only EPIC, Meditech and Oracle/Cerner).
That list should get wider as EU is following similar US infrastructure requirements on EHR systems e.g. Home - EU Health Data API v1.0.0-ballot
thanks @pacharanero, that really made my day. you’ve basically described why i built medikquantis. i was tired of the same scores rebuilt inside closed systems with no link back to the paper they came from, so provenance and languages ended up being the backbone of it. every calculator cites its source (pmid plus full citation, no exceptions), and the ca/es/en strings are kept apart from the calculation logic. a small shared schema for what a calculator actually is, meaning its inputs, units, references and output bands, sounds very doable and i’d love to help.
@mayfield.g.kev, good point, and i’d agree the simpler pattern is the one that actually travels. it’s why every calculator can already be opened click-through style. each one round-trips its inputs through a single ?p= url, so a local system can deep-link straight into a pre-filled score with a plain web address, no oauth or fhir server needed. right now that param is a base64url json blob, which works but isn’t a clean contract, exactly the kind of thing the shared schema above could standardise. the smart on fhir launch then sits on top, for when you do want a structured Patient/Condition read. so i see them as one idea at two levels rather than competing. thanks for the handbook link.
It’s a bit annoying how far behind we really are on tech interoperability.
Your app really needs a ecosystem which I’ve called 2a Resource Exchange below - this is tech from around 2015 (and XML).
What we are probably going to see in the NHS (as Single Patient Record) is 2b Document Exchange from around 2005 (and JSON).
On a practical level, I see to be in a ‘battle’ to move from 1. Document Messaging from around 1995 - to present day (and mostly glorified CSV).
Both 2a and 2b are probably key foundations for AI, Workflow and Data Sharing. I’m hopeful we see some movement here but I do expect ‘we need a database answers to start attacking this basic requirments’
