No, you do not need a Domain Specific Language (DSL) for Clinical Decision Support or Clinical Calculators.

Image credit — unknown (image link) — found through searching ‘useless tools’

Reasons TO use a custom DSL

  • If you choose $LANGUAGE you will never stop having to explain to irate people why you chose that ugly/slow/insert-insult-here language $LANGUAGE.
  • “Building a clinical decision support DSL avoids tying the entire project to a single mainstream language” — by simply creating a whole new problem of tying the entire project to your bespoke language, which nobody else on the planet uses. Neat. Well done you.
  • “It avoids having to teach clinicians to code”. Hello, it’s 2021 and children in primary school are being taught mainstream programming languages without any problems. And clinicians, who can read, understand, and actually make some useful clinical decisions on the basis of 35 pages of NICE guidance, are probably intelligent enough to learn some code.
  • Using a DSL for clinical decision support prevents the mainstream language chosen being PHP. (This is the only valid reason in this list)
  • (In the DSL sales brochure) “multiple implementations of $SOME_ACADEMIC_DECISION_SUPPORT_DSL runtime can exist, built in various languages, so users in all languages are equally well catered for”. (Reality) Welcome to your new multilingual maintenance and clinical safety nightmare, population: 1.
  • On the other hand, nobody ever got 17 academic papers, a decade of conference talks, and a professorship for writing some calculators in Python. And nobody got a nice sideline in their private consultancy from implementing clinical calculators in Python. For that you need a really arcane and difficult DSL — ideally one only you understand.

Reasons TO just write it in a language

  • If you choose a DSL you will never stop having to explain to irate, professorial/academic types why you didn’t use $SOME_ACADEMIC_DECISION_SUPPORT_DSL :-)
  • A lot of what you’re having to do in the DSL looks like a programming language to me. Just get over yourself and use one that already exists. The job of writing clinical calculators and decision support is hard enough without making it significantly harder by inventing your own language.
  • When you use an existing language, you benefit from inbuilt language ecosystem and text editor features to solve problems like:
  • Coding has been taught in schools for at least 5 years. Next-generation clinicians will have at least a basic understanding of coding, which those clinicians who want to develop digital clinical tools will extend.
  • Languages are real and executable and many of them have been around for decades already. The latest $SOME_ACADEMIC_DECISION_SUPPORT_DSL may not be around in 5 years time.
  • Writing a DSL is the easy bit. Maintenance of a runtime which interprets the DSL and turns it into something usable is the hard bit, and a problem not to be underestimated. If you just use a mainstream language, you don’t need to build and maintain this.
  • If there is even one critical error in the runtime of your DSL interpreter, you can harm thousands of patients. And with a DSL you are going to have to implement a lot of basic functionality. Simple conditionals, branching logic… all there for you to implement from scratch and ripe for you to make an error in doing so.
  • The kind of clinicians that would get involved in this type of slightly technical work would learn whatever language is necessary. If a clinician can learn to understand $SOME_ACADEMIC_DECISION_SUPPORT_DSL then why is it presumed that they cannot learn to understand $LANGUAGE.
  • You can leverage existing ‘make it easier’ frameworks around existing languages (eg EduBlocks for Python) — just in case your clinicians do end up needing that GUI or visual toolkit for designing digital clinical tools. Again no need to write the whole thing from scratch.
  • Existing languages may have useful medical tools already built for things like handling of clinical terminologies (libraries like PyMedTermino), and the shared language can form a nucleus around which a clinical coding community can form. This will never happen with a single-purpose DSL, simply because it is not comprehensive enough.
  • If you need the clinical calculator to be technology stack independent there are many strategies to achieve this while still allowing you to use a mainstream programming language. For example, you could use REST as the ‘agnostic’ layer, or transact JSON via stdin/stdout (both of which I’ve used myself)

Declarations of Interest

  • I have written a lot of clinical calculators in Python. When you’ve done a few real calculators you realise all the things that would be really hard to implement in your own DSL interpreter. (Unfortunately these particular calculators were not open sourced, I have since parted ways with the company for whom I wrote them, partly for this reason)
  • Simon Chapman and I wrote the RCPCH Digital Growth Charts internal logic in Python. There is no way we could have built the complex statistical logic required in our own DSL.
  • I have never written a Clinical Decision Support or Clinical Calculators DSL. And I never will. Who’s got the time?

General tech articles which sort-of agree with me

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store