We are pleased to announce the immediate availability of the design specifications of Guideline Definition Language (GDL) and its reference implementation under open source software licenses. GDL is formal language designed to express and to share Clinical Decision Support rules across language and technical barriers by leveraging openEHR designs. CDS rules in GDL format is agnostic to natural languages, reference terminologies and rules engine languages.
There are considerable synergies in the development of clinical models and CDS rules. Semantically well-defined clinical models can provide reliable means of input and output of the rules. On the other hand, experiences from CDS rules development can lead to improvements of the clinical models as well as increased motivations to adopt structured and standardized clinical models. Reusing existing high-quality clinical models in the form of archetypes would hopefully increase the productivity in authoring and maintaining clinical rules.
Please note that GDL is still in development. We aim to submit the GDL specifications for review in openEHR in the near future. We look forward to the community’s feedback to further improve the specifications.
We are pleased to announce the immediate availability of the design specifications of Guideline Definition Language (GDL) and its reference implementation under open source software licenses. GDL is formal language designed to express and to share Clinical Decision Support rules across language and technical barriers by leveraging openEHR designs. CDS rules in GDL format is agnostic to natural languages, reference terminologies and rules engine languages.
There are considerable synergies in the development of clinical models and CDS rules. Semantically well-defined clinical models can provide reliable means of input and output of the rules. On the other hand, experiences from CDS rules development can lead to improvements of the clinical models as well as increased motivations to adopt structured and standardized clinical models. Reusing existing high-quality clinical models in the form of archetypes would hopefully increase the productivity in authoring and maintaining clinical rules.
Please note that GDL is still in development. We aim to submit the GDL specifications for review in openEHR in the near future. We look forward to the community’s feedback to further improve the specifications.
Thanks for the positive feedbacks so far. We really appreciate that.
Personally I am very fond of the idea to host GDL rules in CKM. CKM’s support of change management, distributed review, indexing and search, translation and release sets management (including archetypes/templates, rules and term refsets) will immediately benefit the development of rules.
Hi Rong, great work! Congratulations to you and your team, this will give more power to the openEHR tool stack, and can help big time to show how to use openEHR archetyped data.
Great work! As discussed at the last MIE, I am very fond of this as well.
Two questions:
Is there a way in GDL to define the archetype that is used more precisely than ‘just’ the archetype id? In CKM, there would be several revisions of the archetype and it may be important to know which of these the GDL refers to.
This may require openEHR archetype revisioning and possibly namespacing to be finalised first, of course.
I see that you are using a “1.0.3” Snapshot of the general openEHR RM java libs. I compared it with the current trunk of the java libs and it seems there are not many differences. Some where the openEHR trunk has moved on a bit, and very few places like the DADLBinding class where your 1.0.3 snapshot has been extended. Do you think this could and should be merged with the general java libs again?
It will be exciting to see GDL rules are hosted by CKM alongside with archetypes, templates and refsets.
Regarding your questions,
There are several things to be synchronized with the main stream openEHR artefacts regarding namespace, identification schemes, version/revision semantics etc. GDL rules should use the same design for all other openEHR artefacts. For short term, I would suggest we always assume that the latest revision of the archetype in CKM is the one referred by the GDL rules.
YES, that’s definitely our goal to merge the changes necessary for the GDL work back to openEHR java trunk. Sorry that we missed that message in our GDL announcement (we initially thought about mentioning it). As you rightly pointed out, the differences are small so the merge would be straight forward. In fact, the easiest way to do is perhaps to copy the java-openehr branch from gdl-tools repository back to the trunk of ref-java, then add what has been added (mostly by you I guess) to the public trunk since we branched about a year ago.
Congratulations with this very good work. It is one of the missing links in OpenEHR, and people in the company I work for, and I are very enthusiast about the your (and Cambio) approach in this work.
We will study it carefully because we are seriously considering implementation.
