We studied the use of openEHR technology in checking compliance with clinical practice guidelines through the example of acute stroke care in an experimental environment. We implemented guideline knowledge and patient cases as instances of the openEHR RM based on openEHR archetypes to retrospectively check compliance with guidelines through openEHR. We thus integrated a semantic EHR technology based on archetypes and a reference information model with automatic guideline execution. Overall, we tested a novel approach to providing exchangeable guideline-oriented CDS components that can be integrated with openEHR-based EHRs.
GDL in relation to other guideline representation models
Additional file7 contains a table that uses a couple of selected features to put GDL and other guideline formalisms – languages that create computer-interpretable guidelines - in relation to each other.
This table draws on our own experiences, descriptions by some of the guideline formalisms’ creators[2–5, 7, 21, 31], the review by Isern and Moreno[10], chapter 13 of[8] and a scan of recent literature.
GDL vs. GELLO
We consider GELLO[31] to be the counterpart of GDL in the HL7 world. Although comparing GDL and GELLO thoroughly is beyond the scope of this study, the following could be possible points of comparison for future research: expressiveness for CDS purposes, availability of tools and development environments for the two CDS languages, wealth of experiences in their use, quality of documentation and accessibility. The latter criterion made it easier for us to choose GDL in this study, as it is freely accessible like the rest of the openEHR specifications and so is one of its development environments (the GDL Editor has been released as open-sourced software).
Mei et al. report that GELLO was useful within a CDS engine for chronic disease management while criticising the lack of tools that support GELLO use[32]. Koutkias et al. report deficiencies in GELLO’s expressiveness when modelling adverse drug events, could not use GELLO to implement dynamic CDS behaviour where different rules depend upon each other in their execution and notice the lack of a way to represent alerts in GELLO and its CDS information model (the vMR)[33]. A direct comparison with GDL concerning these criteria from this work would not be useful yet, as GDL is in its early stages compared to GELLO and the studies mentioned covered different clinical demands.
What’s new with this automated compliance checking?
Several research efforts have been published to demonstrate automated retrospective checking of compliance with guidelines, e.g. in[34] and[35]. What is novel in the present work is that it provides a solution based on openEHR, a semantic technology for facilitating semantic interoperability that has been contributing to international standards such as ISO 13606 and receiving attention in industry, academia and nation-wide or regional initiatives of different countries such as Sweden, Brazil and Russia.
Lessons learned
A reflection regarding availability of clinical knowledge using this technology is that GDL provides a straightforward way of obtaining clinical EHR data elements due to its openEHR-archetypes underpinning. For example, if a rule evaluated whether or not a blood glucose value has exceeded a certain threshold, then all that needed to be done was to access the necessary blood glucose data instance from its corresponding archetype and check its magnitude and unit against the threshold.
Also, GDL allows reuse of archetypes both for reading data values as a part of checking guideline conditions (CDS input) and for setting data values as actions to be taken upon fulfilling guideline conditions (CDS output). For example, if a rule required that an MRI imaging test be ordered (CDS output) if the Glasgow Coma Scale score reaches a certain value (CDS input), then GDL can use the OBSERVATION Glasgow Coma Scale archetype to check its score and the INSTRUCTION imaging archetype to record the imaging order entry.
Furthermore, GDL could be used to enhance openEHR archetypes by uncovering shortcomings they have, leading to a feedback loop from CDS to clinical models (cf. section ‘openEHR archetypes based on the openEHR reference information model’ in Results above).
Deciding whether a component of a GDL rule is going to be an archetype data element or GDL construct is not ambiguous in our experience. GDL constructs are only needed to compare data elements against each other or constant values, check the existence of data elements or set the values of data elements. So the data elements as such were always archetype elements and that was straightforward to derive.
Stroke limitation
Compared to guidelines from other clinical domains, acute stroke care guidelines are rather straightforward to transfer to computer-interpretable formats. The structure of recommendations in acute stroke care guidelines is often transferrable to simple rules that satisfy basic if-then statements. Guidelines from other clinical domains may have more complex demands on guideline modelling and could thus be more challenging to computerise. We are aware of this limitation, but think that it does not significantly compromise exploring the overall feasibility of combining a semantic EHR technology with rules for automatic guideline compliance checking. Still, there is a need to represent and execute guidelines from other clinical areas in order to further validate GDL’s usefulness for guideline-oriented CDS generally (cf. section ‘Future directions’ below).
Utilisation of reference information models and standard terminologies
The reviews of different guideline representation models in[9] and[10] emphasize the need for an effective way to work with patient data when modelling computer-interpretable guidelines. They state that there is a lack of a standard way to represent patient data and achieve integration with EHRs. The advantage of our proposal is that it uses the openEHR RM, one of the available reference information models that are meant to standardise data types and data structures in EHRs (there are others like ISO 13606’s reference information model and the HL7 RIM).
The recent study by Zhou et al.[11] shows the lack of ‘rule authoring environments’ that allow for shareable and standardised rules. The rule language for guidelines that we use, GDL, directly tackles that issue by creating rules that are shareable and standardised, as they rely on shareable clinical knowledge content models that tend to get standardised over time in the form of archetypes and use a reference information model for healthcare data in the form of the openEHR RM.
Using other information models such as ISO 13606’s or the HL7 RIM should work with GDL, as long as certain features are provided by the respective information model: data types have to allow set and get operations on them; it should be possible to compare data elements of the same data type; a data element has to be accessible through unique string paths. Having other information models than the openEHR RM as a basis for GDL has not been tested anywhere and there are currently no tools to support that. Archetype data paths, for instance, containing attribute names from openEHR RM classes would hinder executing guideline content directly from archetypes created using other information models. In such cases, mappings between the openEHR RM and other information models would be required.
Additionally, GDL and openEHR archetypes support the utilisation of terminologies such as SNOMED CT and ICD, which further increases shareability and standardisation. Terminology bindings can be vital in providing the different levels of data abstraction or granularity that guidelines often demand. Extensive hierarchies, such as SNOMED CT’s, can be of good help there. For example, it might be important for a guideline to know whether a certain diagnosed disease is a cardiovascular disease. Intra-terminological relations can make it easy to say that ‘Pathological condition X is a cardiovascular disease’, for instance. As mentioned above under the section ‘Tools used’ in Methods, current tools like the GDL Editor need to be developed further to take full advantage of such features.
Separation of data from rules leads to shareability
We achieved improved shareability of CDS rules through using archetypes, a reference information model and reference terminologies. GDL tackles the well-known curly braces problem mentioned in the background as it separates data – which come from archetypes – from rule logic – provided by GDL expressions.
Furthermore, GDL achieves a separation between rule logic and natural languages (e.g. English, Spanish, Chinese, Arabic, Portuguese…) as well as between rule logic and reference terminologies such as ICD.
This solution vs. manual compliance checking methodology
Typically manual checking of compliance with guidelines involves checking whether certain conditions evaluate to yes or no, true or false, fulfilled or not fulfilled, i.e. it involves dichotomous or Boolean logic. Checklists often provide the means of Boolean data collection and those data can then be analysed in various ways, as Luker and Grimmer-Somers also show[36]. This sort of compliance checking matches the compliance checking our method performs, where our computerised approach provides all the advantages of automatisation.
However, manual compliance checks can also be more sophisticated. They can involve the derivation of quality indicators and the aggregation of expert opinions as well as various clinical data to obtain compliance scores[37, 38]. We did not incorporate such checks into this study, but think that integration of various such metrics would be possible with the same set-up, yielding valuable insights for decision makers in healthcare that may not be possible with merely manual efforts. The inclusion of quality indicators, results of expert opinions and compliance scores will usually rely upon the integration of relatively simple mathematical formulae.
Rule maintainability and knowledge scalability
There is too little experience with GDL to be able to judge how easily knowledge captured in GDL rules can be maintained and extended. That is a matter that needs evaluation over time. The good news is that there are already some governance models for openEHR archetypes[30], which can possibly be applied to GDL knowledge artefacts too. Furthermore, if these governance models prove successful with archetypes, a part of the rule knowledge would already be maintained, since GDL relies on reusable openEHR archetypes.
Whichever the case, it will always take a considerable amount of time to reach a computable format of the guidelines from their published form, as guidelines tend to be published mostly as narrative text nowadays. Reaching a representation like the one shown in Figure 1, for example, will probably constitute the majority of the time and cost burden involved in maintaining GDL rules. This is due to the time-intensive process of communication between the medical informatician and physician needed for removing vagueness as well as concretizing temporal aspects.
Closely related studies
There are a couple of research groups that have been working within tightly related research areas to the one this work belongs to. Marcos and Martínez-Salvador[39] developed their own methodology for arriving at the archetypes needed for a certain guideline as well, where their methodology had less of a graphical character than ours in[20] but followed an iterative algorithm for searching archetype repositories and creating new archetypes based on guideline content. Marcos, Maldonado et al.[40] developed a mapping technique to reach interoperability between EHRs and CDS systems that used concepts from the guideline representation model PROforma as well as openEHR together. Their solution had a focus on database data mapping, which had also been the idea behind the knowledge-data ontological mapper (KDOM) developed by Peleg et al. for relational databases in particular[41].
Future directions
To test the usefulness of GDL for the expression of clinical guideline knowledge in a shareable manner, GDL has to be used to computerise various guidelines from several clinical areas. This would challenge GDL’s ability to represent guideline knowledge in general, which is the primary prerequisite for its success.
Also, GDL seems just as suitable to implement CDS rules to be used at the point of care as it is to implement CDS rules for retrospective compliance checking; the representation of rules in GDL does not differ for those two use cases. However, evaluation studies within clinical practice would be needed to verify at-the-point-of-care CDS through GDL.
When it comes to tools that facilitate working with GDL, there are two obvious demands that tool developers may find interesting to address in the future for purposes of semantic interoperability. The first is the provision of functionality for binding data elements to terms from standard terminologies, e.g. 1) implementing algorithms for pre-coordination and post-coordination using SNOMED CT’s extensive hierarchy, the former helping to find useful relationships (e.g. is-a relationships) between terms in order to avoid the need to manually identify all fitting term concepts, and the latter making it possible to aggregate terms for forming unavailable ones; 2) using lexical and context-based techniques to find suitable terms in a terminology to bind to archetype data elements, as Meizoso García et al. demonstrated with promising success[42]; 3) identifying interesting terms through visualisation techniques[43]. Secondly, current GDL editing and execution tooling does not support using other standard information models than the openEHR RM. Thus, efforts to advance existing GDL tools or create new ones may want to facilitate designing and running GDL content using, for example, the HL7 RIM or ISO 13606’s information model.
Our study fits the context set by Mandl and Kohane in 2012: ’The IT foundation required for health care is the core set of health data types, the formalization of health care workflows, and encoded knowledge (e.g. practice guidelines, decision-support tools and care plans)’[44].