Use of Identifiers in archetypes

Technical (archive)
1

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.

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?

Grahame

2

Hi Grahame

DICOM UIDs are globally unique ISO OIDS expressed in a specified text format. Also specified in an ISO standard called GUSI (Globally Unique String Identifiers). So storing them as ASCII text strings of max length 64 bytes is actually how DICOM uses them.

Within a department each four digit identifiers called Accession numbers are used as identifiers usually to identify a folder that holds the results arising from a specific request for an imaging procedure to be performed. When they get to 9999 they start again at 0001.

The IHE SWF Profile specifies a way to use DICOM and HL7 date elements to manage the process of creating results as a result of a request. It used DICOM UIDs to identify various data objects including any image data objects that are produced. DICOM has its own way of searching for images which requires a set of UIDs to identify the image and where it can be found. These were originally designed for use within a department but are now being used for communication between departments.

All data DICOM data object have to use the image data object structure even reports or notes.

Hope this helps

I am copying the supplier co-chair of the British Institute of Radiology (BIR) Medical Imaging and Radiation oncology committee who is a past director of an organsiation called PACSnet and is a key expert on these matters.

BTW so far as I know DICOM does not support the concept of different revisions of the same data object. (Called a SOP instance in DICOM speak.)

Best wishes
Nick

— On Tue, 18/1/11, Grahame Grieve grahame@kestral.com.au wrote:


> From: Grahame Grieve grahame@kestral.com.au
> Subject: Use of Identifiers in archetypes
> To: “For openEHR technical discussions” openehr-technical@openehr.org
> Date: Tuesday, 18 January, 2011, 4:31
>
> 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.
>
> 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?
>
> Grahame
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

|

3

Thanks Nick

The question here really isn’t about the semantics of the DICOM identifiers,
though I thank you for reviewing those. The question is about how these
interact with an openEHR system and with other users of the archetype

One interesting aspect concerning the OIDs is that though they are supposed
to be globally unique, unless you have a oid root ↔ issuing system registry,
you still need to track the issuing system (and I’ve never heard of such a
registry in practice)

Grahame

4
Grahame Each national standards body such as BSI will issue an ISO OID root that is globally unique. DICOM uses a root for it spec. Companies can purchase a root to use when identifying each DICOM object such as an image that they create. This work well if appropriate care is taken in designing the system and the algorithm for creating the non root components.

It seemed to me hat you needed to know some of teh background when thinking about when you actually need to use DICOM UIDs
Best wishes
Nick

5

HL7 Australia will issue companies unique OID roots based on the HL7 branch
At present this is a free service

Dr Vincent McCauley MB BS, Ph.D
CEO, McCauley Software Pty Ltd www.mccauleysoftware.com
Chair, IHE Australia www.ihe.net.au
Treasurer, Medical Software Industry Association www.msia.com.au
p: +61298186493
f: +61298181435

Jan. 2011 HL7 International Meeting: Sydney www.HL7.org.au/Sydney2011

6 
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’ :wink:

  • thomas
7

Grahame Grieve wrote:

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.

Hi Grahame,

I believe what you're saying is right. This sounds exactly like what
the FEEDER_AUDIT class was designed for. See the the Common IM spec.

Each LOCATABLE has an attribute called 'feeder_audit', of type
FEEDER_AUDIT. Within the FEEDER_AUDIT class, there are lists of
DV_IDENTIFIER where systems can store ids generated by the originating
system and other systems. The FEEDER_AUDIT also has an attribute
called 'original_content', where an image or a reference to the image
would be stored.

Because COMPOSITION inherits from LOCATABLE, an obvious place to set
the 'feeder_audit' attribute might be on the composition. You could of
course prefer to set it on, say, the imaging exam OBSERVATION.

This is an excellent example of something that is already catered for
in the reference model, and so it probably shouldn't be modelled in
archetypes. Unfortunately, current tools don't make the feeder_audit
attribute visible visible to modellers, so they are likely to
"reinvent the wheel", unaware that it's already available. (They're
designing "wheels" for the "car", but the car already has wheels.)
This is a problem to modellers: an important part of the model that
they are designing is to all intents and purposes invisible to them in
the archetype.

- Peter

8

Hi Peter,

Using FEEDER_AUDIT was actually discussed as part of deciding how best
to handle Placer and Filler Order numbers in lab tests etc . The
problem we have is that we also need to add these identifiers to
outgoing order /referral messages (and track those within the EHR),
and FEEDER_AUDIT was deemed unsuitable for this purpose.

Personally I like the idea of using FEEDER_AUDIT and there is growing
recognition that we need to expose more of the RM in the models for
specific archetypes but the current specs seemed to debar the use of
FEEDER_AUDIT for outgoing identifiers.

Ian

Dr Ian McNicoll
office +44 (0)1536 414994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical analyst, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org

9

Just take care to use FEEDER_AUDIT for ids generated in external systems, rather than assigned within the openEHR system, including by users of apps talking directly to the openEHR system. If we don’t stick to the rules, software architects won’t write software that does the right thing. If we want to change the rules, that is possible as well, but it needs to be documented within the RM.

  • thomas
10

hi Tom

thanks

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).

ok ta

I don't know about any such advice, and I am surprised by that, I would have
said use DV_IDENTIFIERs.

ok ta

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.

the identifier is a pointer to a thing. The thing has a type. The pointer
to the type shouldn't carry the type of the thing it points to. (though I
often think that debugging/troubleshooting would be simpler if it did!)

You say that the type is the *type of the identifier*. Well, that's interesting.
How can a pointer have a type?

In the ISO datatypes, we added two properties to the II data type, "scope"
and "reliability". Reliability is under appreciated, but adding scope has
had a series of interesting consequences. Possible values for scope:
BUSN : Business identifier
OBJ : Object identifier
VER : Version identifier
VW : View specific identifier

The really interesting one here is "BUSN". Here's the full definition:

An identifier whose scope is defined by business practices
associated with the object. In contrast to the other scope
identifiers, the scope of the use of the id is not necessarily
restricted to a single object, but may be re-used for other
objects closely associated with the object due to business
practice.

Making this property explicit has forced everyone to re-evaluate
their use of identifiers, and some interesting things have emerged.
Firstly, we are crucially interested in two different types of identifier
usage: what you might call "direct" and "indirect". (At one time you
referred to this division as "real world identifier" and "technical
identifier", but this isn't obvious in the tools, and I'm too lazy to look
it up again). We have come to recognise that this is the same as
a "business identifier" vs one of the other types. On further examination,
we've found that business identifiers are almost exclusively linked
with "roles" (RIM speak, sorry), and then where there are external
registration authorities for the roles (patients, people, doctors,
companies, etc)

If by "type", you mean things like "scope" or "reliability", then ok.
But the possible values need to be enumerated to make them
useful to implementers.

if by "type" you are referring to the kind of registration authority... then
the lack of a controlled vocabulary field forces archetype designers
to make the kind of registration authority explicit in the archetype so
that the identifiers can be found and exchanged when required

So the type is useless - in practice either it is not relevant or
it's value is implicitly fixed. At least, I think so. I suppose I should
scan the archetypes to check my assertion, particularly the
demographics ones which are generally directly concerned
with external registration authorities.

anyhow, that's a side issue.

Grahame

11

Hi Peter, Tom

thanks

Just take care to use FEEDER_AUDIT for ids generated in external systems,
rather than assigned within the openEHR system, including by users of apps
talking directly to the openEHR system.

I'm not sure which way to parse that sentence

Generally, about FEEDER_AUDIT, it's something I had missed, so I'll go
and review it, but how does it manifest in the archetype editor?

Ian:

Using FEEDER_AUDIT was actually discussed as part of deciding how best
to handle Placer and Filler Order numbers in lab tests etc . The
problem we have is that we also need to add these identifiers to
outgoing order /referral messages (and track those within the EHR),
and FEEDER_AUDIT was deemed unsuitable for this purpose.

because the identifiers weren't explicitly identified? Can you say why it
was deemed unsuitable?

thanks
Grahame

12

Grahame Grieve wrote:

Generally, about FEEDER_AUDIT, it's something I had missed, so I'll go
and review it, but how does it manifest in the archetype editor?

FEEDER_AUDIT isn't shown in the Archetype Editor at all. It's one of
many parts of the reference model invisible within the tools, and so
easily overlooked by modellers. As Ian said, there's growing
recognition that future tools need to rectify this.

- Peter

13

Hi Grahame,

The concern about FEEDER_AUDIT related to its use in outgoing service
requests e.g. within referrals / lab requests etc. This is
technically possible but against the intentions within the
specifications as Thomas suggested in his eralier reply. Personally I
would be happy to see the specifications change to allow FEEDER_AUDIT
used in this way.

Ian

Dr Ian McNicoll
office +44 (0)1536 414994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical analyst, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org

14 
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.


the identifier is a pointer to a thing. The thing has a type. The pointer
to the type shouldn't carry the type of the thing it points to. (though I
often think that debugging/troubleshooting would be simpler if it did!)

Although the type information is redundant, it can be reasonable to have it in the reference. Consider that the ‘thing pointed to’ may be buried in the state motor vehicle database, or some other inaccessible (to you) system…

You say that the type is the *type of the identifier*. Well, that's interesting.
How can a pointer have a type?

in the common understanding of the term, most people would understand the question ‘what id is that you are giving me’, and the answer would ‘that’s my drivers license number’ (DVLA) or social security number (SSN) or whatever. Most real world entity identifiers around today are not Oids, but some custom id system, like your license number, veterans number and so on, and it is usually helpful to know what kind of id it is. I agree that this field might overlap with the ‘issuer’ and / or ‘assigner’, and maybe one day it will never be needed. But there appear to be uses for it now.

In the ISO datatypes, we added two properties to the II data type, "scope"
and "reliability". Reliability is under appreciated, but adding scope has
had a series of interesting consequences. Possible values for scope:
 BUSN : Business identifier
 OBJ : Object identifier
 VER : Version identifier
 VW : View specific identifier


The really interesting one here is "BUSN". Here's the full definition:

An identifier whose scope is defined by business practices
associated with the object. In contrast to the other scope
identifiers, the scope of the use of the id is not necessarily
restricted to a single object, but may be re-used for other
objects closely associated with the object due to business
practice.

this is related to the openEHR distinction between real world entity (RWE) identifiers, and Instance Identifiers (IIs) - see http://www.openehr.org/releases/1.0.2/architecture/rm/support_im.pdf - OBJ & VER are part of Instance Ids (i.e. system internal ids) while BUSN is a RWE id. I don’t know what a VW corresponds to… The various types in the Identification package in this PDF plus the DV_IDENTIFIER cover all of these types I think.

Making this property explicit has forced everyone to re-evaluate
their use of identifiers, and some interesting things have emerged.
Firstly, we are crucially interested in two different types of identifier
usage: what you might call "direct" and "indirect". (At one time you
referred to this division as "real world identifier" and "technical
identifier", but this isn't obvious in the tools, and I'm too lazy to look
it up again). We have come to recognise that this is the same as
a "business identifier" vs one of the other types. On further examination,
we've found that business identifiers are almost exclusively linked
with "roles" (RIM speak, sorry), and then where there are external
registration authorities for the roles (patients, people, doctors,
companies, etc)

that may be true in reality, but it isn’t often a useful thing to record. E.g. if someone comes along with a Driver’s license, you normally just record the id, and what kind of id it is, e.g. UK drivers license; you don’t want to model any role connection between the patient and the DVLA or DMV or whatever.

If by "type", you mean things like "scope" or "reliability", then ok.
But the possible values need to be enumerated to make them
useful to implementers.

I agree. I think it may emerge that ‘scope’ is the most useful thing to use it for. I expect its utility to be better defined in the future.

  • thomas
15

Short brain dump on FEEDER_AUDIT:

  • main fact to know: FEEDER_AUDIT is an optional thing hanging off any LOCATABLE (i.e. any node down to ELEMENT level)
  • UML picture here
  • proper description here (PDF) - see rm.common.archetyped package

FEEDER_AUDIT was orginally conceived to carry ids over which the target system has no control, that come in from external systems, e.g. lab systems or whatever. Peter’s point is that it would be nice if it were symmetric, so that the openEHR system sending out and order used the same place to record e.g. order_id.

Superficially this would appear to be so, however the FEEDER_AUDIT is meant to carry the external system’s idea of its ids, possibly attached to ENTRYs or some lower level of data, not just COMPOSITIONs. The openEHR system does need to record order ids in the outgoing order, but this is nearly always an HL7 message or similar. Putting it in openEHR FEEDER_AUDIT is not useful.

Being able to record order_id on any CARE_ENTRY type has turned out to be a useful thing to do (Grahame and others with long experience in lab messages might be smiling, but we like evidence to support things in openEHR;-) Anyway, it isn’t there now, but will go in as a change request for the next release.

Note that there are all kinds of placer, filler, lab, session, who knows what else ids in HL7 and IHE. Most of these will just be archetyped fields. But the concept of an ‘order’ and therefore an ‘order_id’ is a strong enough one to go in the RM.

  • thomas
(attachments)

OceanInformaticsl.JPG

16

If you get the ADL workbench and view an archetype Definition, with ‘+class properties’ radio button turned on you will see FEEDER_AUDIT. If you click on a class rather than an archetype in the left hand explorer, e.g. OBSERVATION, you will see the full tree structure of FEEDER_AUDIT (same info as the UML obviously, but coming from the tool RM schema).

  • thomas
17

Short brain dump on FEEDER_AUDIT:

  • main fact to know: FEEDER_AUDIT is an optional thing hanging off any LOCATABLE (i.e. any node down to ELEMENT level)
  • UML picture here
  • proper description here (PDF) - see rm.common.archetyped package

FEEDER_AUDIT was orginally conceived to carry ids over which the target system has no control, that come in from external systems, e.g. lab systems or whatever. Peter’s point is that it would be nice if it were symmetric, so that the openEHR system sending out and order used the same place to record e.g. order_id.

Superficially this would appear to be so, however the FEEDER_AUDIT is meant to carry the external system’s idea of its ids, possibly attached to ENTRYs or some lower level of data, not just COMPOSITIONs. The openEHR system does need to record order ids in the outgoing order,

sorry, mistype; I meant if the openEHR system recorded the order_id of e.g. a COMPOSITION containing an INSTRUCTION, how would the receiver system read this? It will typically be expecting an HL7 message.

18

Hi

There have been a few issues with DV_IDENTIFIER - largely that all fields
are mandatory. This may mean that users puts stuff in that is not helpful.
There is also no known set of things to use at any point although this could
be expressed in a template (or archetype although this would not be
appropriate).

There is a WORKFLOW_ID on every entry that Ocean have been using to link
data around a particular workflow - this is the PLACER_ID in HL7 v2. It
allows observations, actions etc to be related to a particular instruction.

This is working well and keeps things relatively simple. Feeder_audit is a
great way to find information about feeder systems and is present in 13606
as well. It is not in the archetype (constrained) but should be visible soon
in CKM.

I would also suggest that we allow people to use the HL7/ISO datatype names
for the models to aid use and familiarity. It will be a diminished set
(openEHR compatible) but should meet all the needs of the modellers.

Cheers, Sam

19

There have been a few issues with DV_IDENTIFIER - largely that all fields
are mandatory

that's pretty remarkable. really?

This may mean that users puts stuff in that is not helpful.

sure would.

Grahame

20

In any realistic implementation, this needs to be relaxed to allow empty String fields.

  • thomas