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
----- Original Message -----
From: Grahame Grieve
To: For openEHR technical discussions
Cc: Dewinder.Bhachu
Sent: Tuesday, January 18, 2011 8:39 PM
Subject: Re: Use of Identifiers in archetypes
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
On Tue, Jan 18, 2011 at 8:24 PM, Nick Brown <nbrown.mimic at btinternet.com>
wrote:
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 at kestral.com.au> wrote:
From: Grahame Grieve <grahame at kestral.com.au>
Subject: Use of Identifiers in archetypes
To: "For openEHR technical discussions" <openehr-technical at
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
MailScanner has detected a possible fraud attempt from "mc"
claiming to be MailScanner has detected a possible fraud attempt from "mc"
claiming to be openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
--
-------------
Grahame Grieve, Health Intersections Pty Ltd.
grahame at healthintersections.com.au | http://www.healthintersections.com.au
------------------------------------------------------------------------------
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110118/fb9e534e/attachment.html>
