According to legend, the Inuit people have more than 50 words for different kinds of snow. It makes sense, after all: having an expressive vocabulary that supports the description of a range of snow conditions is essential to solving problems in the Arctic domain. Though our offices are warm and welcoming by comparison, we less-hardy software developers have nonetheless developed a similar concept. To optimize our ability to solve problems in particular domains, we've invented Domain-Specific Languages (DSLs) such as CQL (Clinical Quality Language).
In the words of the HL7 Language Specification, CQL "is a high-level, domain-specific language focused on clinical quality and targeted at measure and decision support artifact authors". As such, CQL isn't a general-purpose computing language like Python or Java. CQL is not Turing-complete, which means it can't be used to solve general computing problems. Instead, it’s designed specifically to express clinical logic in a way that is comprehensible to subject matter experts such as nurse informaticists.
There are several very common domain-specific languages that we've all worked with or been exposed to. Consider HTML, for example: it's a DSL that allows the definition of the structural semantics of documents and text. CSS, another domain-specific language, describes the way that structural elements of documents should be presented in various media. These two DSLs work together to power the Web. Similarly, SQL is a DSL that was originally designed to support the management of data stored in a relational database. Over more than 40 years, SQL has become the ubiquitous standard for querying, analyzing, and transforming data in a very broad variety of contexts.
We all expect a long lifespan for CQL, and it is already growing in its use and adoption within the healthcare domain. Yet CQL is still in its infancy when compared to long-established technologies such as HTML, CSS, and SQL. What can we learn from the history of these technologies? How do they inform our view of CQL and how can we avoid problems and pitfalls that they've been victim to?
One failed expectation for other DSLs has been the hope that software developers would be rendered unnecessary! Famously, the designers of SQL believed that truly casual users would interact with databases via SQL, in the sexist terms common not so long ago, that SQL would be suitable for the "housewife who wants to make enquiries about this week's best buys at the supermarket." SQL was originally named "SEQUEL", which stood for "Structured English Query Language" and was intended to emphasize its simplicity. Similarly, HTML arose from the SGML markup language, a standard for authoring technical documentation, and was intended as a personal publishing tool for academics. It involved just a handful of tags that anybody could learn and required only Notepad to create.
Neither DSL remained a tool for the masses. Both SQL query writing and HTML page creation have become the province of specialized software developers. However, by empowering experts rather than amateurs, the growth of massive business segments has been enabled. The widespread adoption of database technologies and the global transformation wrought by the Internet were made possible by the standardization the DSLs created and the powerful problem-solving abstractions they provide. At the same time, the focused nature of the DSLs has provided a basis for communication between domain experts and software developers that both streamlines the development process and results in applications that more accurately capture domain requirements.
This points the way towards the most successful future for CQL. We should not expect that subject matter experts like clinicians and measure designers will author substantial artifacts in CQL without the support of developers. Instead, we should work towards an environment where CQL provides the means for seamless communication between SMEs and developers, while it enhances the efficiency and capabilities of those developers. Our tools should create the most effective development environment for those programmers. We should expect and encourage the evolution of a class of professional CQL developers who work in support of clinical computing efforts.
Another major trend in common DSLs has been the tendency for vendors to "embrace and extend" the language specification as a competitive tool used to lock customers into a particular implementation...or worse. In the course of the browser wars, Microsoft acquired a particularly bad reputation: the Department of Justice found that, at Microsoft, the full phrase was "embrace, extend, extinguish!"
Even when vendor behavior is benign, DSLs tend to enjoy periods when standards compliance is seen as positive, punctuated by intervals when implementations diverge in response to new challenges or changing business conditions. CQL is likely to be a victim of this pattern, too. Though the language is supported by a much stronger standards process than SQL or HTML were in their infancy, there are still many gaps that vendors may decide to close through the implementation of proprietary extensions to the language, and perhaps even more opportunities to add specialized tooling to make the language more capable and powerful.
Vendor-specific innovations aren't necessarily a bad thing. They can provide a way forward when the standards process is slow or blocked. In HTML, for example, the IMG tag which allows the display of images on Web pages was originally an extension created by the Netscape team. The HTML community had argued for a much broader approach to object embedding, but Netscape needed to ship a product! As it turns out, the IMG tag has finally been superseded, but that took more than 20 years during which it provided a bridge to the ideal implementation.
There are two extremes to avoid, then: a standards process that chokes off innovation, or a Wild West in which vendors destroy the standards. Our goal for CQL should be to chart a middle path, where our standards bodies aim for the right balance of clear standards that include and support extensibility, tolerance of experimentation, and rapid adaptation to evolving uses for the language. If this can be achieved, we can avoid pitfalls such as the bad behavior of Microsoft, as well as its subsequent demonization, which (however well-deserved) set back browser-based development by almost a decade.
One sign that the trajectory of CQL has been well-managed will be the broadening of its scope. Other DSLs have expanded their focus over time: HTML has become the preeminent foundation technology for application presentation, while SQL has come to express queries over diverse data formats including flat files, documents, structured data, and real-time event streams. CQL already addresses a wide variety of quality measurement and decision support use cases. It’s easy to see how CQL could power ad-hoc query and on-demand data retrieval, cohort definition, rule-based systems, reporting and visualization, and machine learning applications.
Perhaps the most important lesson learned from our experience with DSLs is that, when successful, they tend to have a very long lifespan. That's because they capture the higher-level abstractions that are essential to their domains. It's that domain logic that has lasting value, while more rapidly-changing underlying technology is just an implementation detail. In that long-term context a robust clinical computing industry can evolve, with an assortment of powerful tools, a cadre of skilled practitioners, and broadly reusable clinical logic artifacts.
Have a question, comment or request for future blog topics? Let us know!