On 18/01/2011 04:31, Grahame Grieve wrote: > hi Tom > > I was working with Heather today on the imaging exam archetype. Two > different considerations associated with identifiers came up during our > work. > > The first is that in the archetype design we came up with (still be posed > on CKM yet), there's a lot of identifiers present. These identifiers are > required to deal with the interoperability aspects of the imaging exam > report (i.e. PACS reigsters images with RIS, RIS provides report to > EHR, EHR tracks identifiers so it can provide links to RIS/PACS > resources as required). In particular, in several places there's slots > for various DICOM UIDs. To me, these are IT issues, not clinical > issues, so they shouldn't be part of the archetype design (on the basis > that archetypes are *clinica* knowledge)- but I do know that we > absolutely need these identifiers. Is there a policy about this? > Note that I ask this question with wider issues about whether IT and > interoperability concerns should be explicitly represented in archetypes.
so let's be a bit more careful about what we mean by 'clinical knowledge'. The following distinctions could be made (not trying to be academic - just go with me a bit here): * (bio)medical knowledge: facts about reality, expressed in an ontological form, e.g. OBO Foundry ontologies, SNOMED CT (bigger, a bit weaker, but still trying to do the same thing), ICDx (classification only). The key distinction of such knowledge if it is done properly (improper things are creeping into SNOMED CT) is that it is a 'description of reality', i.e. biological, physical and chemical phenomena that correspond to our best scientific understanding, and therefore pretty stable (every so often medical science figures it got something wrong, e.g. the etiology of stomach ulcer 15 years ago, and the knowledge base has to be revised. * clinical knowledge: if we were to build proper ontologies of this it would cover the 'methods in medicine' aspect of reality, i.e. the (current) way to do a breast biopsy, etc; it would still be a description of reality, but now, about investigative and remedial processes and methods, which are modes of scientific problem solving; they facts in such a knowledge base are obviously more volatile, e.g. when a new procedure replaces an old one; Now, what are archetypes about? They are 'clinical knowledge' about information recorded during (or due to) clinical processes occurring. Everything you find in any EHR archetype is a description of information structures that could potentially be recorded by some clinician during an exam, a procedure, or by a machine, or the patient. So the distinction here is that they are not knowledge artefacts about real (physical) things like how to do a caesarian section, but about what would be recorded in notes relating to this procedure actually being performed on a patient. I.e. they are 'knowledge about information'. So considering the notion of order and filler ids, and whatever other ids are required in a typical clinical process, it is clear that such things need to be accommodated in archetypes, if they are not already in the underlying reference model, because they are part of the information recorded. The clinical process can't proceed without them (and remember, they would still be needed with no computers and no IT - some identification system is unavoidable). > The second question is that there seemed to be some operating > guidance to archetype designers to use the Text data type rather than > the Identifier type for these fields talked about above on the basis that > they are "foreign" identifiers. There didn't seem to be particular > consensus on where this policy came from (and I don't want to point > fingers...) but it seems pretty nuts to me. These things should be > identifiers, and we should insist on tracking the issuer of them (though > I couldn't care less about the type, and indeed, the presence of type > on DV_Identifier represents confused modeling). In our archetype, we > changed all the identifiers from Text to Identifier. Is there any rules > about this? I don't know about any such advice, and I am surprised by that, I would have said use DV_IDENTIFIERs. The spec is as follows: * *issuer*: String - Authority which issues the kind of id used in the id field of this object. * *assigner*: String - Organisation that assigned the id to the item being identified. * *id*: String - The identifier value. Often structured, according to the definition of the issuing authority's rules. * *type*: String - The identifier type, such as "prescription", or "SSN". One day a controlled vocabulary might be possible for this. I don't think the 'type' is confused modelling; it just indicates what kind of identifier it is. I agree it is not well defined at the moment, but being realistic, having 'SSN' or other familiar type names is likely to be very useful in dealing with real data. It may be that in well controlled ecosystems it is not needed at all (and of course the type should be properly indicated and coded in the containing ELEMENT). Anyway, the main point is that we should be using this type rather than DV_TEXT. I would have said that the rule was 'common sense' ;-) - thomas * * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110118/5d244055/attachment.html>