Hi! Very nice work Rong et.al. - and wonderful to see a full open source release of the tool so that it can be extended and experimented with by others. Credit to you, your team and Cambio for releasing this!
Now let's hope that the community uses this wisely and avoids running into the same decision support interoperability costs as "arden syntax" and MLMs did [1] the last time there was a hype about interoperable decision rules. GDL attempts to avoid similar problems by using archetyped data. The potential for easy/low-cost sharing of decision support solutions based on the GDL approach is dependent on the use of shared archetypes. I have seen examples of local archetyping projects all over the world using the "global" archetypes as inspiration but not understanding that it is in their own long term interest to plan and fund contributions of their extensions and improvements back to the global work. In my thesis I described this as a form of technical debt, see details in [2] below. This is not a critique of GDL, just a reminder of other important work that the success of GDL and other archetype-based reusable solutions are likely dependent on. On Tue, Mar 12, 2013 at 1:37 PM, Rong Chen <Rong.Chen at cambio.se> wrote: > > 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. > Perhaps an openEHR GitHub repository dedicated to GDL rule sharing, divided into suitable subdirectories, can be a fast and good start for rule sharing to begin with while considering other potential solutions? Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 *[1] Desperately seeking data - *Excerpt from page 13-14 of section 1.3.2 in http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-87702 *That the lack of semantic interoperability has an impact on reuse costs was illustrated by Hripcsak et al [Hripcsak 93] that for good reasons included the words ?Desperately seeking data? in their description of problems when linking a knowledge-based system (KBS) to a clinical database. The KBS provided alerts, interpretations, research screening, and quality assurance functions. The system used Arden Syntax Medical Logic Modules (MLMs) that were intended to make medical rules [...] reusable between different EHR systems. The MLMs contained both reusable medical knowledge-based logic rule sections and location specific data slot sections used to find and access actual data in the local databases. * *Defining and maintaining KBS-database links consumed a lot more resources than the medical logic in the MLMs in terms of coding, maintenance, and performance.* *Experiences like ?Desperately seeking data? and others [Ahmadian 2011] make it very interesting to also look at ways of standardizing the way data is stored in addition to standardizing ?instructions? like MLM-based decision support rules. * *Similar issues arise repeatedly when trying to reuse data for other kinds of decision making [Mawilmada 2012] and for computer instructions, for example when creating summaries or drawing a graphical EHR overview on a screen. * *[2] Technical debt - *Excerpts from pages 80-83 of section 14.3 in http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-87702 *The best documented origin of a definition of ?technical debt? comes from Ward Cunningham [Cunningham 2009] that used the metaphor of debt to explain to his boss that if the design team failed to continuously update the design to become aligned with increased updated knowledge of the problem at hand, than they were continually going to stumble over that disagreement. That would slow the team down, which was like paying interest on a loan. * *Cunningham argues that technical ?loans? in the form of rushed solutions can be well motivated by business needs or by wanting to get initial experience of the problem space. Loans let you ?do something sooner than you might otherwise, but then until you pay back that money you'll be paying interest? and if you keep borrowing and never repay by refactoring and updating the design then ?eventually all your income goes to interest and your purchasing power goes to zero?. He continues: ?By the same token, if you develop a program for a long period of time by only adding features and never reorganizing it to reflect your understanding of those features, then eventually that program simply does not contain any understanding and all efforts to work on it take longer and longer. In other words, the interest is total -- you'll make zero progress?.* *[...]* *When deciding to connect semantically incoherent systems it will not always be obvious to decision makers where (in which system) debt is built up (in things like new import/export conversion boxes to create and maintain). The debt may also be hidden until the next time systems are to be modified. [...]* *Technical debt in archetype management* *There are many aspects of and possible causes to technical debt. In open source projects technical debt can be considered to increase when local changes and improvements of source code is not shared and committed back to the main project. An interest rate manifests itself in the form of merging conflicts in the local version when wanting to update to using new code from the main project.* *Many users of open source software (including really big companies) with a need of local improvements and modifications have learned this and are thus actively contributing their local improvements back to the originating community. This form of giving back is thus not necessarily because of altruistic motivations but also in order to keep their own technical debt and interest rate in the form of merging costs down.* *If there is to be any real interoperability in archetyped systems, then archetypes and their development need to be shared. Currently a lot of archetyping is done at local levels. Most likely a big portion of that development is based on modifications of international openEHR archetypes. This is a situation analogous to locally modified versions of open source software.* *Archetyped systems are thus not immune to, but rather highly susceptible to the same kind of technical debt. I think there is currently a lack of insight regarding this among local archetyping projects. There is likely not enough awareness of the future interest costs that are being built up by an increasing technical debt. This is not so strange since it won?t become obvious until you for example want to do any of the following:* - *exchange or compare data (for example in multi centre studies)* - *reuse path/query-based solutions developed elsewhere (for example decision support, user interfaces and visualizations)* - *update your local archetype to include new features from updated international ones* *I do not think many local archetyping projects have set aside budgeted time or money for contributing back to the international work. This might be rectified for future projects if the reasoning above is considered as useful and is more widely discussed. I hope that these ideas can contribute to show that ?giving back? archetype improvements should be motivated not only by altruism but also by an awareness of risks associated with locally accumulating technical debt.* *This should not be seen as a reason to avoid going for archetyped systems. Perhaps a slightly unscientific parable can be allowed: Committing changes back and re-aligning local archetype modifications of shared origin is after all doable and could perhaps be compared to the work of re-aligning Linux or Unix branches that have parted temporarily, whereas aligning systems with different reference models perhaps can be compared to aligning Microsoft Windows and Mac OS-X.* *That brings me to a final remark about archetype management. Regarding archetype management I think more attention should be paid to how things like change tracking and code alignment in massively distributed software development projects like the Linux kernel are performed. Tool support and processes should be considered. Right now local and national archetyping is far too disconnected and future tracking- and merging-nightmares are to be expected.* *Transfer of patient records outside the local ?archetyping? domain (e.g. a regional or national health programme) may not be that very common, but the chance of easily running the same epidemiological and research queries or perform comparative effectiveness research (as mentioned section 1.2) in international multi-centre studies is likely a highly interesting use case that really can bring medical knowledge forward. The patient data won?t need to leave the site - only queries and the aggregated query results will need to be exchanged. It would be a pity if these wonderful possibilities were made a lot harder and slowed down just because the value of committing local changes back to the international work was not recognized.* *From: *Rong Chen <Rong.Chen at cambio.se> > *Sent: *12/03/2013 1:28 AM > *To: *openEHR-technical at lists.openehr.org; > openEHR-clinical at lists.openehr.org; openehr-implementers at > lists.openehr.org > *Subject: *Guideline Definition Language (GDL) specifications and > GDL-editor release announcement**** > > Dear all, > > 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. > > Some important links from this release:**** > > 1. GDL Specifications > (v.90)<https://github.com/openEHR/gdl-tools/blob/master/cds/docs/specs/gdl-specs.pdf?raw=true> > **** > > 2. GDL Editor <http://sourceforge.net/projects/gdl-editor/>**** > > 3. GDL sample > files<https://github.com/openEHR/gdl-tools/tree/master/cds/cm/guides> > **** > > 4. GDL Reference Implementation > Project<https://github.com/openEHR/gdl-tools/wiki> > > Rong Chen**** > > On behalf of the Informatics Team, > Cambio Healthcare Systems, Sweden > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130312/c40185f3/attachment-0001.html>
