Introducing the Spark Editor

Introduction #

Clinical Quality Language (CQL) is a domain-specific language targeted for healthcare. It allows developers to code clinical content mainly data retrieval and clinical decision support logic in a more user-friendly format that is easier for clinicians and guideline developers can read and understand.

CQL is widely used in WHO SMART guidelines which allows digitisation of clinical guidelines that can be executed in different health information systems. And the benefit of SMART guidelines and CQL is that once you code the clinical logic in CQL, developers don’t have to go through complex clinical guidelines and instead use the already coded CQL either by converting to a different programming language using a mediator or directly executing the CQL using a CQL engine.

The Problem #

However, support for CQL is very limited. With a small ecosystem, this is one challenge amongst many that leads to the lack of adoption of SMART guidelines.

Also using a standard VSCode is not easy because in order to write CQL, (ie: to parse, to autocomplete) you will have to connect to a terminology server that has all the clinical codes stored and available. Also, it’s difficult for clinicians and guideline developers to set setup an IDE and collaborate with developers in writing and collaborating on CQL using Git.

Clinicians and developers will go through the painful process of reading a data dictionrary a large Excel file with thousands or rows spread across multiple sheets, and another decision logic Excel file which is also equally large or larger and code this CQL, with no way of knowing wether it’s correct or not and detectable only at runtime. This also takes a long time, and one of the reasons why WHO is not publishing the CQL when they publish a SMART guideline Digital Adaptation Kit.

Developing a Solution #

As someone who faces these challenges every day at work when we tried to code a SMART guideline and with frustration of not having a proper platform to code and listening to all the complaints by users, I started working on a CQL Editor with collaborative features to make it easier to collaborate on writing CQL and clinical decision support logic that can be used by both clinical experts and developers to work together in developing clinical guidelines.

The initial version was something very simple that converts CQL to a human-readable format by doing some simple parsing, a view of the data dictionary as a split screen where people can search the data dictionary and copy the clinical concept to be pasted to the editor above. It had no backend and just ran on GitHub pages. Then it evolved to adding syntax highlighting and autocomplete.

Later on, I added the collaborative features so multiple CQL developers and clinicians can work on the CQL at the same time. I first released this on LinkedIn and BlueSky and quickly found some users outside of my organisation who are interested in CQL. Especially Ward from Firely was kind enough to test it and highlight some of the bugs that he found.

When you are developing something it’s easier to overlook the bugs and the user experience problems because you know the ins and outs of the tool. But only when someone uses your tool as a completely new user can they highlight the issues and improvements that one can make.

Even though it has been just three months since I wrote the first line of code, the tool has come a long way and quite fast. Looking back I am surprised how much I was able to create, especially me working on this outside of my working hours.

Today I am happy to launch a feature that allows one to quickly see the decision logic as a multi-step flowchart. This is especially helpful for clinicians to see the decision logic and understand it without needing to understand the CQL language, even though it is designed as a health domain-specific language.

Conclusion #

Is it perfect? Oh, no it’s far from perfect, buggy yes there maybe bugs and improvements I can do.

And that’s what I’m doing trying to develop it in my free time and sharing with my network on social media who are interested in similar digital health tools. I have a small group of users both internally at my organization and outside of it using the tool everyday, spread across multiple countries and continents.

I am enjoying building the Spark editor, and looking forward to where I can take this.