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 <http://terminology.vetmed.vt.edu/SCT/ISA.cfm?SCT_ConceptID=38936003> blood pressure (finding) Blood <http://terminology.vetmed.vt.edu/SCT/ISA.cfm?SCT_ConceptID=129899009> pressure alteration (finding) Decreased <http://terminology.vetmed.vt.edu/SCT/ISA.cfm?SCT_ConceptID=55973006> pulmonary arterial wedge pressure (finding) Finding <http://terminology.vetmed.vt.edu/SCT/ISA.cfm?SCT_ConceptID=392571003> of arterial pulse pressure (finding) Finding <http://terminology.vetmed.vt.edu/SCT/ISA.cfm?SCT_ConceptID=12763006> of decreased blood pressure (finding) Finding <http://terminology.vetmed.vt.edu/SCT/ISA.cfm?SCT_ConceptID=301141002> of pulmonary arterial pressure (finding) Finding <http://terminology.vetmed.vt.edu/SCT/ISA.cfm?SCT_ConceptID=301140001> of systemic arterial pressure (finding) Finding <http://terminology.vetmed.vt.edu/SCT/ISA.cfm?SCT_ConceptID=366161004> of venous pressure (finding) Increased <http://terminology.vetmed.vt.edu/SCT/ISA.cfm?SCT_ConceptID=30261008> pulmonary arterial wedge pressure (finding) Normal <http://terminology.vetmed.vt.edu/SCT/ISA.cfm?SCT_ConceptID=9027003> pulmonary arterial wedge pressure (finding) On <http://terminology.vetmed.vt.edu/SCT/ISA.cfm?SCT_ConceptID=163020007> examination - blood pressure reading (finding) Unequal <http://terminology.vetmed.vt.edu/SCT/ISA.cfm?SCT_ConceptID=102584008> 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: [email protected] [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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20081209/3dabdab5/attachment.html>
