Hi One side point: >> Grahame advises that from a pure semantic view, pathology tests are really a >> subset of lab tests and justifies using a more specific term.
What I recall is that we said that In Australia "lab" and "pathology" are synonymous, and that everyone uses "pathology". However this is not at all true in the US, for instance, where common usage is that "pathology" = histopathology. I think we settled on "pathology" in the Australian ckm because we were having enough trouble with names without introducing international alignment there too. I expected that the name would revert to lab when the work was migrated to the main ckm. Grahame On 27/07/2012, at 11:47 PM, "Kalra, Dipak" <d.kalra at ucl.ac.uk> wrote: > Dear Heather, > > Thank you for sharing this challenge of defining good practice. > > Firstly it was very helpful to have your description of the background to the > changes made, and to be able to look at both archetypes side-by-side. This > makes it easy to see the details not only which nodes have changed, but also > to identify the impact that new nodes will have on what information might be > placed in nodes that have not changed. > > My reflections, some of which reiterate what you've said. > > 1) The NEHTA Pathology Test Result archetype is substantially different from > the original Laboratory test archetype. It is not a minor tweak, and it is > not "backwardly compatible". > > 2) The scope of both is sufficiently the same that it would not be justified > to retain both as current usable archetypes. > > 3) Even though it is classified as draft, for the reasons you give and the > fact that it has been accessible since 2009, the original Laboratory test > archetype should be deprecated but not purged. The NEHTA Pathology Test > Result archetype is the appropriate successor. > > 4) It is unfortunate that our archetype identifiers contain strings that > imply the concept. We seem here to have two Concept Name strings that are > physically different, but are colloquially often considered synonyms. One > would surely wish to find the NEHTA path archetype whether searching for a > pathology or a laboratory test result archetype? Ideally one would modify > both archetypes to include both concepts, or attach a synonym to each to > enable them to be cross-referenced (e.g. via the Keywords?). If that is felt > not to be appropriate, it would make sense for them both to be classified as > pathology test results. (These tests are no longer only done in laboratories!) > > 5) Any EHR system that has accumulated data according to the old archetype, > and any applications that present data or capture data fashioned according to > that archetype, will need significant change to use the new one. Changing > archetype IDs would seem to be a very small portion of the overall workload > involved and yet actually quite important for clinical governance. Whether > the NEHTA path archetype identifier includes letters that read like the word > "lab" or letters that read like to work "path", and contains a version > integer that is one or two, is less important than knowing that it is a > unique identifier which is not the same as the older archetype, and that > there is a means of knowing in the repository that one is deprecated and the > other has succeeded it. I appreciate that this is sometimes done by keeping > the archetype identifier string the same and notching up the version integer. > Surely this case illustrates why that might not always prove a robust method? > > I must confess that I have read your options a few times but haven't formed a > firm impression on which one is the right choice. I appreciate this may be > unhelpful, and apologise for this, but I hope my reasoning above at least > helps you, Ian and others to come to a good decision! > > Well done for pushing the challenges and quality assurance of archetype > development to such a high standard that these issues surface and cause us > difficulty. It's a real tribute to your success. > > With best wishes, > > Dipak > ________________________________________________________ > Dipak Kalra > Clinical Professor of Health Informatics > Director, Centre for Health Informatics and Multiprofessional Education > University College London > Holborn Union Building, Highgate Hill, London N19 5LW > Honorary Consultant, The Whittington Hospital NHS Trust, London > > Phone: +44-20-7288-5966 > > On 27 Jul 2012, at 01:29, "Heather Leslie" <heather.leslie at > oceaninformatics.com> wrote: > >> 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 >> Ocean Informatics >> Phone (Aust) +61 (0)418 966 670 >> Skype - heatherleslie >> Twitter - @omowizard >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120728/b5cc9bc7/attachment-0001.html>
