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 --- On Tue, 18/1/11, Grahame Grieve <grahame at kestral.com.au> wrote: From: Grahame Grieve <grah...@kestral.com.au> Subject: Re: Use of Identifiers in archetypes To: "For openEHR technical discussions" <openehr-technical at openehr.org> Cc: "Dewinder.Bhachu" <Dewinder.Bhachu at gmail.com> Date: Tuesday, 18 January, 2011, 9:39 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 <grah...@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 -----Inline Attachment Follows----- _______________________________________________ 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/7ab32f85/attachment.html>
