Unique Identifiers (UIDs) provide the capability to uniquely identify a wide variety of items. They guarantee uniqueness across multiple countries, sites, vendors and equipment. Different classes of objects, instance of objects and information entities can be distinguished from one another across the DICOM universe of discourse irrespective of any semantic context.
The UID identification scheme is based on the OSI Object Identification (numeric form) as defined by the ISO 8824 standard. All Unique Identifiers, used within the context of the DICOM Standard, are registered values as defined by ISO 9834-3 to ensure global uniqueness. The uses of such UIDs are defined in the various Parts of the DICOM Standard.
Each UID is composed of two parts, an <org root> and a <suffix>:
UID = <org root>.<suffix>
The <org root> portion of the UID uniquely identifies an organization, (i.e., manufacturer, research organization, NEMA, etc.), and is composed of a number of numeric components as defined by ISO 8824. The <suffix> portion of the UID is also composed of a number of numeric components, and shall be unique within the scope of the <org root>. This implies that the organization identified in the <org root> is responsible for guaranteeing <suffix> uniqueness by providing registration policies. These policies shall guarantee <suffix> uniqueness for all UID's created by that organization. Unlike the <org root>, which may be common for UID's in an organization, the <suffix> shall take different unique values between different UID's that identify different objects.
posted on Wednesday, April 26, 2006 - 11:59 am
Thank you.So, can we say Study Instance UID shall created in RIS and send Modalities via Worklist response? Without such a RIS system and MWL Server how can a modality select a Study Instance UID?
A modality creates its own study instance UID if it doesn't receive one from RIS (via the DICOM modality worklist). The study instance UID can then be reconciled with RIS and PACS to maintain data integrity by the modality sending a modality performed procedure step (MPPS) message.
If the modality doesn’t support MPPS, the study instance UID can be reconciled in PACS using information PACS receives in the procedure scheduled transaction from RIS. PACS can also inform RIS of any instance UIDs it receives using an instance availability notification message.
These are all IHE specified transactions that can be used to maintain data integrity.
posted on Friday, April 28, 2006 - 11:02 pm
And we had ALL this reconciliation working fine between multiple vendors (just about everyone in the national program PACS/RIS world with the notable exception of HSS) this week in Barcelona - it was great to see how it could and should be done!
posted on Saturday, April 29, 2006 - 12:53 pm
I can't officially comment on who passed which of the IHE profiles for 2 reasons:
1) The official results have not been validated by the European project manager
2) The web site containing this year's details (including results) is currently "in limbo" between the connectathon event (finished yesterday) and being back on line on the Internet.
I can however say that GE had a few systems there (I genuinely cannot remember whether or not they had a PACS this year), but they certainly have participated and passed in this role (technically in IHE terms an image manager) in previous events - see www.ihe-Europe.org then click on the "Connectathon results" tab and select a company (remember then to press "go") to see the summary of their previous connectathon results.=20
I will try to remember to post a note on this forum once this year's results are officially validated and published, but do remember the note I have previously made on this site:
a) A connectathon pass is externally validated by one of us monitors, but it is not officially tied to any particular real-world product (it may be a prototype or development system), so such a pass only indicates that a company as a whole possesses the competence to make such a system.
b) Manufacturers' "integration statements" are what you need to assess a particular product, and whilst they are not independently verified in the same way, you can make a judgement call about their likely accuracy and plausibility based on connectathon results.
Margaret, Dave Harvey had an excellent posting on IHE a few months ago. Just seeing connectathon results can be misleading. Agfa has very good connectathon results (almost all boxes ticked). You need to see the Integration statement of the specific product. Impax 5.2 (available through the LSP to NHS) only supports Portable media for Imaging IHE profile (It does not even support SWF and PIR which are the cornerstones of IHE). I think the vendors use the connectathon results to their advantage.
Dave, it is good to see HSS did participate in IHE. I do hope other RIS vendore will follow suit and C4H will realise the importance of IHE in RIS.
Sorry if what I said was unclear, but HSS are the only one of the major NPfIT vendors who do NOT participate in the connectathon - and despite IHE conformance being supposedly mandatory for RIS (as specified in the OBS), no-one in authority in NPfIT seems to have taken the trouble to point out their total lack of IHE conformity (and perhaps claim large penalties off them for non-compliance!). As you correctly point out, it is the IHE functionality as defined in the integration statement which is important - the connectathon results merely give you an indication of how much credibility you can give to a manufacturer's claims. In this regard HSS are still lacking, as they fail to provide some of the basic services needed by IHE.