tag:blogger.com,1999:blog-733074358901582680.post6000785794394188404..comments2024-03-23T05:28:35.472-04:00Comments on Healthcare Standards: IHE Workshop ResultsKeith W. Boonehttp://www.blogger.com/profile/16883038460949909300noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-733074358901582680.post-84059764694449110182011-01-23T16:34:31.281-05:002011-01-23T16:34:31.281-05:00Hi Keith, it is good to see interest in the catara...Hi Keith, it is good to see interest in the cataract surgery project. In particular I agree with Ian McNicoll that we should work at 'establishing a workable cross-clinical domain approach to modelling based on DCMs/archetypes/templates, with CDA as an output, than fretting over which technical formalism (HL7/openEHR) should be used.' Eyecare data is often very straightforward; for example intra ocular pressure or length of the eyeball are simple numerals and machine dumps into the PMS so there is no agony about what data is like. Competing notations such as for visual acuity or corneal curvature have well known conversion factors. I proposed the project partly because the very simplicity of the data is well suited to the IHE process, because getting accord on what the data is should be easy. A cataract surgery profile also needs to use standards for the devices involved, as well the QA aspect and allow global contributions to the international bench marking process as suggested by a UK team: http://www.medscape.com/viewarticle/722931. If it can work for cataract, all kinds of health care domains might be facilitated using the same technology. Let's do it! Mike MairMike Mairhttps://www.blogger.com/profile/14615913207334117996noreply@blogger.comtag:blogger.com,1999:blog-733074358901582680.post-63654936920099671772011-01-17T13:42:17.831-05:002011-01-17T13:42:17.831-05:00The cataract surgery project sounds very interesti...The cataract surgery project sounds very interesting and ideally suited to DCM based clinical content work-up leading to an IHE/CDA profile.<br />The issue you have already raised about visual acuity (6/6 UK/AUS vs. 20/20 US) is key to this kind of detailed modelling effort. If you aim for a specific use-case e.g. US realm Cataract Surgery report, the traditional domain analysis approach can work reasonably well. The problem is, of course, that the models developed are applicable only in that domain and use-case, whereas, the need for a Visual Acuity model lies across the clinical practice from Diabetes care to Optometry. The difficulty is that all of these sub-domains may require somewhat different levels of granularity.<br /><br />I tried to find the DICOM models but drew a blank - any suggestions for locating the Eye Care Object definitions relatively easily.Ian McNicollhttps://www.blogger.com/profile/03869383870547032153noreply@blogger.comtag:blogger.com,1999:blog-733074358901582680.post-1360368917170580592011-01-17T09:28:37.623-05:002011-01-17T09:28:37.623-05:00Note that the eye care community has been active i...Note that the eye care community has been active in the DICOM Standards Committee. They have established DICOM Information Object Definitions for refractive and acuity measurements, as well as various ophthalmic diagnostic methods (ophthalmic photography and optical coherence tomography).Harry Solomonhttps://www.blogger.com/profile/01135539798417593756noreply@blogger.comtag:blogger.com,1999:blog-733074358901582680.post-72545034246078774662011-01-17T04:04:59.835-05:002011-01-17T04:04:59.835-05:00Hi Keith,
The Cataract Surgery project sounds ver...Hi Keith,<br /><br />The Cataract Surgery project sounds very interesting and ideally suited to openEHR archetype or HL7-DCM based clinical content work-up leading to an IHE/CDA profile.<br />The issue you have already raised about visual acuity (6/6 UK/AUS vs. 20/20 US) is key to this kind of detailed modelling effort. If you aim for a specific use-case e.g. US realm Cataract Surgery report, the traditional domain analysis approach can work reasonably well. The problem is, of course, that the models developed are applicable only in that domain and use-case, whereas, the need for a Visual acuity model lies across the clinical practice from Diabetes care to Optometry. The difficulty is that all of these sub-domains may require somewhat different levels of granularity. The wider the realm, the wider the clinical context, and the harder it is to reach clinical consensus.<br />This UK Cataract referral document http://bit.ly/ee3raS (page 16) shows the much more granular model demanded by an optometrist. This is not required for diabetes care, nevertheless we want all parties to communicate 'Visual acuity' at some minimal level of coherence. Traditionally, this will have been defined via a ‘minimal dataset’ but since there are multiple overlapping use-cases it becomes impossible to maintain semantic coherence and the more granular, detailed requirements not covered by the minimum standard are worked up by different groups in isolation losing 'information liquidity'.<br /><br />The paradigm of openEHR archetype development is to set a clear scope for the clinical content of the archetype but within that scope to model as inclusively as possible. This inevitably leads to a somewhat bloated model and we use openEHR templates to constrain the archetype down to specific use-cases. My understanding of HL7 Detailed Clinical Model development is that it follows a similar 'maximal dataset' approach. Whilst this approach cannot give wholesale interoperability in one sweep, it does force clinical debate into a clear and carefully scoped space. If you as a clinician want to add anything to the idea of 'Visual acuity', this is where you do it. If you have a radically new idea (perhaps yet another unit/scale) , this is where you discuss it. This does mean that competing 'standards' and legacy approaches will often sit alongside each other within an archetype/DCM where consensus cannot be reached e.g. multiple pain scales.<br />This might seem to encourage bad or legacy practice but I take the view that, at any point in time, clinical semantic models have to cope with a range of clinical practice which may be legacy, standard or innovative, and inevitably, at times in conflict. It is up to actual communities of care to apply more rigorous standards of common practice, via Templates (HL7 or openEHR).<br /><br />I think our shared DCM/archetype experience is that defining the scope of the detailed model or archetype is the hardest task - having defined the boundaries of what is in scope, getting clinical engagement and positive discussion is relatively easy.<br /><br />IanIan McNicollhttps://www.blogger.com/profile/03869383870547032153noreply@blogger.comtag:blogger.com,1999:blog-733074358901582680.post-47942206543797145852011-01-14T15:49:24.019-05:002011-01-14T15:49:24.019-05:00The Cataract Surgery project sounds very interesti...The Cataract Surgery project sounds very interesting and ideally suited to openEHR archetype or HL7-DCM based clinical content work-up leading to an IHE/CDA profile.<br />The issue you have already raised about visual acuity (6/6 UK/AUS vs. 20/20 US) is at the heart of this kind of detailed modelling effort. If you aim for a specific use-case e.g. US realm Cataract Surgery report document, the traditional domain analysis approach can work reasonably well, though still frustrating in trying to secure clinical consensus. The problem is, of course, that the models developed are applicable only in that domain and use-case, whereas, the need for a Visual acuity model lies across the clinical practice from Diabetes care to Optometry. The difficulty is that all of these sub-domains may require somewhat different levels of granularity. The wider the realm, the wider the clinical context, and the harder it is to reach clinical consensus.<br />This UK Cataract referral document http://bit.ly/ee3raS (page 16) shows the much more granular model demanded by an optometrist. This is not required for diabetes care, nevertheless we want all parties to communicate 'Visual acuity' at some minimal level of coherence. Traditionally, this will have been defined via a ‘minimal dataset’ but since there are multiple overlapping use-cases it becomes impossible to maintain semantic coherence and the more granular, detailed requirements not covered by the minimum standard are worked up by different groups in isolation losing 'information liquidity'.<br />The paradigm of openEHR archetype development is to set a clear scope for the clinical content of the archetype but within that scope to model as inclusively as possible. This inevitably leads to a somewhat bloated model and we use openEHR templates to constrain the archetype down to specific use-cases. My understanding of HL7 Detailed Clinical Model development is that it follows a similar 'maximal dataset' approach. Whilst this approach cannot give wholesale interoperability in one sweep, it does force clinical debate into a clear and carefully scoped space. If you as a clinician want to add anything to the idea of 'Visual acuity', this is where you do it. If you have a radically new idea (perhaps yet another unit/scale) , this is where you discuss it. This does mean that competing 'standards' and legacy approaches will often sit alongside each other within an archetype/DCM where consensus cannot be reached e.g. multiple pain scales. <br />Some modellers, even in the openEHR community find this uncomfortable, believing that it may encourage bad or legacy practice but I take the view that, at any point in time, clinical semantic models have to cope with a range of clinical practice which may be legacy, standard or innovative, and inevitably, at times in conflict. It is up to actual communities of care to apply more rigorous standards of common practice, via Templates (HL7 or openEHR).<br />As co-editor of the openEHR Clinical Knowledge Manager, along with Heather Leslie @omowizard, I would certainly be interested in helping to develop a Visual acuity archetype or DCM. I am more interested in establishing a workable cross-clinical domain approach to modelling based on DCMs/archetypes/templates, with CDA as an output, than fretting over which technical formalism (HL7/openEHR) should be used. I think our shared DCM/archetype experience is that defining the scope of the detailed model or archetype is actually the hardest task - having defined the boundaries of what is in scope, getting clinical engagement and positive discussion is relatively easy<br />IMO, SNOMED rather than LOINC would be a better option, if working internationally, and where non-lab terminology is required, but our experience is that there are big gaps in all reference terminologies when it comes to detailed modelling. This should not be seen as a criticism, just a reflection of the breadth and depth of coverage required, especially while post-coordination remains a challenge.<br />IanIan McNicollhttps://www.blogger.com/profile/03869383870547032153noreply@blogger.com