Hi everyone,
Ian McNicoll and I, as openEHR CKM Knowledge Administrators, are seeking some feedback regarding a complex governance process in the openEHR CKM. It is a complex area and we will still be learning for some time to come. Your thoughts will help us to develop our current processes further. We have had many archetypes in the draft state for some time in CKM. We think it likely that a number have been used within systems, despite the draft status. We don't have any metrics on the extent of the use - there is no reliable way to tell from downloads of the models, nor any voluntary usage system - but that issue is for solving in the future and not the purpose of this email. While we have a specific use case in mind at present, this scenario has the potential to re- occur with some of the current archetypes that have been in draft state for a length of time. So principles of governance are of high priority, not just reacting to management of one specific model in isolation. Within the Australian context, Grahame Grieve has collaborated to update the current OBSERVATION.lab-test archetype -http://www.openehr.org/knowledge/OKM.html#showarchetype_1013.1.350 - (first authored in 2009), consistent with his knowledge of lab systems and HL7 practice. While there are many data elements consistent with the openEHR archetype, the new NEHTA archetype - http://dcm.nehta.org.au/ckm/OKM.html#showarchetype_1013.1.1019_5 (and currently on a branch) - has had to change in a number of ways to cater for additional use cases and including more alignment with v2 messaging etc - all very useful, I'm sure you'll agree. The NEHTA archetype therefore really reflects our current understanding of 'best practice', although the archetype will no doubt undergo some further refinement in a collaborative review process. So, the major changes affecting implementers: . The ID and concept name of the new archetype has been changed to OBSERVATION.pathology_test and 'Pathology Test Result'. Grahame advises that from a pure semantic view, pathology tests are really a subset of lab tests and justifies using a more specific term. . Unfortunately, the data changes are not backwardly compatible, especially the 'Result' node - largely because of the creation of new paths, rather than deletion of data elements. In the data elements that persist, the atcodes have been carried through into the new archetype to minimise potential confusion, although sometimes the names have been finessed a little J. . There are some new data elements, but these will not impact implementers in the same way as the first two dot points. Our usual governance policy, which I think works sensibly in principle, is that while an archetype is in a draft state, any implementation is at risk as until collaboration has taken place and consensus reached by the review team, it is possible and indeed very likely that the archetype will undergo significant change from its initial upload, and this usually involved breaking changes as we update structure and change paths etc during the refinement process. While Editors seek to ensure only reasonable models are uploaded in the first place, there is no guarantee that they will not change significantly as domain experts impart their wisdom! Further, once an archetype is published as v1, then the current policy requires that backwardly compatible changes can be managed by creating a new revision of the archetype but non-backwardly compatible changes require a new version of the archetype as v2, v3 etc. So in this special situation, where we suspect that there has been a number of implementations of the original draft archetype, we are interested in receiving your feedback as to process you prefer. In all situations, implementers will need to manage the new archetype data element structure in their systems. All options have pros and cons: . Option 1: Reject the original draft 'Laboratory test' archetype and upload the new 'Pathology Test Result' archetype, making sure there is adequate supportive information for implementers to understand why the archetype has been rejected and what has replaced it. All provenance of the original 'Laboratory test' archetype will be preserved. The new "Pathology Test Result' v1 archetype will contain a reference to the openEHR 'Laboratory Test' v1 archetype and the NEHTA archetype in its metadata to support provenance (ie provenance will be preserved and the location will be made explicit). o Implementers: will have to modify their systems with the new archetype ID and structure o Knowledge Governance: Semantically clean way to ensure that the CKM pool of archetypes is representing academic best practice. . Option 2: Update the current archetype ID (lab_test.v1 to pathology_test.v1) and Concept name from 'Laboratory test' to 'Pathology Test Result', then upload the new 'Pathology Test Result' archetype content - keeping the same CKM internal ID including directly preserving all provenance and associated details accumulated to date. o Implementers: will have to modify their systems with the new archetype ID and structure o Knowledge Governance: Another semantically clean way to ensure that the CKM pool of archetypes is representing academic best practice. . Option 3: Keep the current archetype ID (lab_test.v1), update the Concept name only to 'Pathology Test Result', then upload the content of the Pathology Test Result' archetype as a new iteration of the lab_test.v1 o Implementers: will have to modify their systems with the new archetype structure only. o Knowledge Governance: The structure of the archetype represents academic best practice. There is a mismatch between the archetype ID (which effectively has no semantics) and the Concept Name - this may cause some confusion, especially with clinicians. We might have to explain this mismatch for a very long time and it may be perpetuated throughout other related CKM national instances! This option will result in a non-alignment between the NEHTA CKM and the openEHR CKM. While it is probably inevitable that this kind of diversion of models will happen over time, the question is whether this is acceptable or desirable in this relatively early phase of model development and governance. . Option 4: Same as Option 3 but upload the 'Pathology Test Result' archetype as a new version, ie lab_testv2, even though the lab_test.v1 has never been published. o Implementers: will have to modify their systems with the new archetype ID and structure. The new version will be a visual indication of significant change in the structure of the archetype. o Knowledge Governance: As with Option 3, the structure of the archetype represents academic best practice, but the ID (which effectively has no semantics) and the Concept Name are still mismatching - this may cause some confusion, especially with clinicians. Creating a new version in this situation breaks our fledgling governance policy principles, but may be viewed as a pragmatic solution. As in Option 3, there will again be a non-alignment between the NEHTA CKM and the openEHR CKM resulting from this approach. While it is probably inevitable that this kind of diversion of models will happen over time, the question is whether this is acceptable or desirable in this relatively early phase of model development and governance. Needless to say this has caused some lively discussion amongst those I have asked so far. There has been no real consensus arising from those limited discussions, hence my request for feedback from the broader community. Teasing it out we are dealing with a number of issues tied in together: . We need to manage inclusion of breaking changes to a draft archetype that has probably been implemented in a number of systems, despite the draft state. We are pretty sure that this situation is not unique and we will need to apply government principles here - either keep it as v1 draft (as justified by a 'draft model users beware' notion) or update it to v2. This is covered by Options 3 & 4 . We want to potentially change the Concept Name of the archetype, and it possibly makes sense to change the Archetype ID to keep them aligned - this additional change provides us with Options 1 and 2 above, in addition to Options 3 & 4. There are tensions. We have to make pragmatic decisions where there is real impact on implementers, we want to develop and apply governance principles systematically, and at the same time we have a responsibility to set these models up to be as rigorous and semantically sensible as we can, while we can. We know that over time, we will have to make compromises - the art (or science) is working out how much compromise and when! Many thanks Heather and Ian Dr Heather Leslie MBBS FRACGP FACHI Director of Clinical Modelling <http://www.oceaninformatics.com/> Ocean Informatics Phone (Aust) +61 (0)418 966 670 Skype - heatherleslie Twitter - @omowizard -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120727/54e183dc/attachment-0001.html>
