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>
