Hi All, While I read every email on this list I do not usually get involved in the conversations.
However, this reply from Sam Heard so very concisely, yet completely captures all of the components of the difficulty in using computers to record health care information. While the specifics of archetype Ids may not be appropriate for all venues, IMHO, it should be turned into an article for publication or at the very least a guest blog post somewhere in the health informatics space. I know that Sam's time is limited (like many of us) but I believe that this would be WELL worth the effort. --Tim On Tue, 2008-12-09 at 00:08 +1100, Sam Heard wrote: > Hi William > > > > Thomas? point here is very important ? the data compatibility and the > clinical concept continuity are not mutually dependent. If it is a new > clinical concept then we need to have a new name for it (and therefore > a new id). > > > > So the first important point is that the ontological ID must remain > true to the clinical concept that is being modelled even if the data > associated with that might change or evolve and at times even become > incompatible with old data (remember this is a formal mathematical > consideration ? not a loose worded thing). So even making something > that was optional mandatory (something we would hope to see with time) > will make prior data incompatible and require a new version of an > archetype. > > > > The second issue I have is using the terminology space as the anchor > of meaning beyond value set content. Blood pressure is an ideal thing > to consider for this purpose. We all know if you ask 99% of clinicians > on the planet what a blood pressure observation is they will tell you > that it is a measure of the person?s systemic arterial pressure (they > might say it another way). > > > > The blood pressure archetype has all the data points, lots of > descriptions and other metadata. It is highly recognisable to > clinicians. > > > > The term blood pressure in SNOMED is defined by relationships with > other terms. It may even be primitive (ie have no defining > characteristics). If you look at the terms that are children of blood > pressure (ie they are a blood pressure) you will find many things that > most clinicians will argue are not blood pressures. > > Abnormal blood pressure (finding) > > > Blood pressure alteration (finding) > > > Decreased pulmonary arterial wedge pressure (finding) > > > Finding of arterial pulse pressure (finding) > > > Finding of decreased blood pressure (finding) > > > Finding of pulmonary arterial pressure (finding) > > > Finding of systemic arterial pressure (finding) > > > Finding of venous pressure (finding) > > > Increased pulmonary arterial wedge pressure (finding) > > > Normal pulmonary arterial wedge pressure (finding) > > > On examination - blood pressure reading (finding) > > > Unequal blood pressure in arms (finding) > > > > If you look beneath these you will find things that are even less > related to blood pressure from a clinicians view point. You then have > the idea of invasive and non-invasive all mixed in. Pressures are not > invasive ? the methods of measuring them are. > > > > The problem for terminologists is that they have had to differentiate > terms from other terms in a theoretical space and have made decisions > in a context free environment (pure). As content for health record > items these definitional characteristics are useful ? but they are not > knowledge in the traditional sense. > > > > Take for example the idea of Pneumonia and the idea of Streptococcal > pneumonia. To differentiate these terms, it has been decided to create > an intermediate term Baterial pneumonia. This term is differentiated > by the causal agent bacteria. Now streptococcal pneumonia can be seen > as a type of bacterial pneumonia that has cause Steptococcus. This is > immensely useful when you want to query for bacterial pneumonias. But > it does not tell you the causes of pneumonia. Some Streptococci do not > cause pneumonia (or have not done so yet) and many that do cause > pneumonia have no such relationship. > > > > The net result of these definitional relationships and overloaded use > of them in theoretical statements about the uses of terminology is > that we have to be absolutely clear what we are talking about. The > result is that an id of an archetype is not the same as the words used > to describe things in medicine. We should allow it to be what it is ? > link it to terminology but not confuse the recordings of something > with its names. As Satre said (perhaps while intoxicated) ?Belief is > confusing things with their names?. > > > > An archetype ? with an id x ? records information about some things > which may exist more or less in one or more terminologies. If we are > to have archetype ids in SNOMED then they must have a unique code ? > for that archetype. But using a meaningless id for an archetype has > major consequences that must be considered, > > > > One such consideration is the utility of specialisation. Computing has > come a long way by giving classes names and understanding the > relationship between a class and a specialisation. The number of > archetypes shared in the international community will be the > determinant of whether we should use extended ids for specialisations. > If we do not then we need to keep registers of all archetypes ever > used anywhere ? something that makes me sweat a little. > > > > Not many people yet understand the pragmatic approach to health > information representation that is required for as yet humble > computers to really offer us assistance. We need to ensure that it can > work in practice. > > > > Cheers, Sam > > > > > > From: openehr-clinical-bounces at openehr.org > [mailto:openehr-clinical-bounces at openehr.org] On Behalf Of > Williamtfgoossen at cs.com > Sent: Wednesday, 3 December 2008 6:19 PM > To: openehr-clinical at openehr.org > Subject: Re: poor version management in archetype editor > > > > > Hi Tom, > > This looks good! > > My only question here is that if BPv1 and BPv2 are not compatible, > they are probably 2 different concepts. The idea to use concept as the > identifier is fine. > Using Snomed CT here would be excellent. > > then we can have > openEHR-EHR-Observation-SnomendCTConceptNameSNomedCTconceptId87654321. > > If the concept is non existing in Snomed CT, there are procedures to > ask for the addition. > > Due to fine grainedness of SNomed CT to a high level it is probably a > lot that can be handled with this, also avoiding the same concept used > for 2 different archetypes. > > I agree with the world wide management of this, but then again the > ISO / CEN / HL7 / CDSIC DCM approach (IHTSDO invited) would be > helpful. > > If we move this way and identify the concept as such, we can have the > clinical material specified, modeled in different formats but > DCM-Concept-conceptID, OpenEHR-Concept-ConceptID.adl, and > HL7templateIDConcept-ConceptID.xml would be identified as clinically > exactly the same information, but technically fitting to another > reference information model and technology, each with the > peculiarities necessary to have it work for purpose. > > > > > > > > Sincerely yours, > > dr. William TF Goossen > director > Results 4 Care b.v. > De Stinse 15 > 3823 VM Amersfoort > the Netherlands > email: Results4Care at cs.com > phone + 31654614458 > fax +3133 2570169 > www.results4care.nl > Dutch Chamber of Commerce number: 32133713 > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical -- Timothy Cook, MSc Health Informatics Research & Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ************************************************************** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ************************************************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20081208/cef2b031/attachment.asc>
