HI Colin thanks. The problem is that this makes a lot of sense in Australia, but much less in, e.g. USA/Canada I can't speak to how it would work in UK or other non-english speaking countries.
Grahame On Sat, Jul 28, 2012 at 11:19 AM, Colin Sutton <Colin.Sutton at ctc.usyd.edu.au> wrote: > Hi Grahame, > > I was only suggesting not to use the term 'Laboratory results' , since > information from other devices could match the pattern: the accepted usage of > 'Pathology' is better, in my opinion; I agree that separate constructs are > more useful for imaging - and DNA results. > > regards, > Colin > > ________________________________________ > From: openehr-technical-bounces at lists.openehr.org > [openehr-technical-bounces at lists.openehr.org] On Behalf Of Grahame Grieve > [grahame at healthintersections.com.au] > Sent: Saturday, 28 July 2012 10:55 AM > To: For openEHR technical discussions > Subject: Re: Feedback on an archetype governance issue please > > hi Colin > > The trouble with "diagnostic tests" is that this also includes other things > that > are contained in a different archetype - Imaging - and also other things for > which the requirements were not in our scope, and therefore I'd have > no confidence > in it's use for them. > > Note that the imaging archetype and the pathology archetype are very similar, > but they also differ in some minor but important ways. > > Grahame > > > On Sat, Jul 28, 2012 at 10:50 AM, Colin Sutton > <Colin.Sutton at ctc.usyd.edu.au> wrote: >> 'Histopathology test results' should by definition only include cell/tissue >> sample diagnostics, which would exclude molecular tests. >> >> As measurement devices become available outside the laboratory, simpler to >> operate and cheaper, 'Laboratory results' become a subset of diagnostic >> tests. >> >> 'Pathology' and 'Laboratory Results' are both subsets of 'Diagnostic tests': >> those diagnostic tests that use devices or processes that need monitoring by >> lab assistants or device auditors. >> The results should be communicated to the eHR using the same protocol. >> >> On Heather's original question, I agree with Option 1, making it clear that >> the old archetype is a 'deprecated draft', annotating it with a reference to >> the new archetype. >> >> Regards, >> Colin Sutton >> ________________________________________ >> From: openehr-technical-bounces at lists.openehr.org >> [openehr-technical-bounces at lists.openehr.org] On Behalf Of Grahame Grieve >> [grahameg at gmail.com] >> Sent: Saturday, 28 July 2012 7:14 AM >> To: For openEHR technical discussions >> Cc: For openEHR technical discussions; openehr-implementers at openehr.org >> Subject: Re: Feedback on an archetype governance issue please >> >> 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<mailto: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<mailto: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 ?. >> >> ? 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<http://www.oceaninformatics.com/> >> Phone (Aust) +61 (0)418 966 670 >> Skype - heatherleslie >> Twitter - @omowizard >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org<mailto: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<mailto:openEHR-technical at >> lists.openehr.org> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> ##################################################################################### >> This e-mail message has been scanned for Viruses and Content and cleared >> by MailMarshal >> ##################################################################################### >> >> #################################################################################################################### >> >> IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to >> be read or used by the named addressee. >> It is confidential and may contain legally privileged information. No >> confidentiality or privilege is waived or lost >> by any mistaken transmission to you. The CTC is not responsible for any >> unauthorised alterations to this e-mail or >> attachment to it. Views expressed in this message are those of the >> individual sender, and are not necessarily the >> views of the CTC. If you receive this e-mail in error, please immediately >> delete it and notify the sender. You must >> not disclose, copy or use any part of this e-mail if you are not the >> intended recipient. >> >> ##################################################################################################################### >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > -- > ----- > http://www.healthintersections.com.au / > grahame at healthintersections.com.au / +61 411 867 065 > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > ##################################################################################### > This e-mail message has been scanned for Viruses and Content and cleared > by MailMarshal > ##################################################################################### > > #################################################################################################################### > > IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to > be read or used by the named addressee. > It is confidential and may contain legally privileged information. No > confidentiality or privilege is waived or lost > by any mistaken transmission to you. The CTC is not responsible for any > unauthorised alterations to this e-mail or > attachment to it. Views expressed in this message are those of the individual > sender, and are not necessarily the > views of the CTC. If you receive this e-mail in error, please immediately > delete it and notify the sender. You must > not disclose, copy or use any part of this e-mail if you are not the intended > recipient. > > ##################################################################################################################### > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- ----- http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065
