Radiology Technical Framework Supplement Pu
Use the table below to submit comments on 2010 Radiology Technical Framework Supplements to the IHE Radiology Technic
Implementation versions of these supplements to be published in August 2010.
Enter you comments using the table below and post to: http://forums.rsna.org/forumdisplay.php?f=12 or send by email to r
Notes:
1. The 2010 Radiology Supplements include:
Multiple Image Manager/Archive (MIMA)
They are available for download at http://www.ihe.net/Technical_Framework/public_comment.cfm.
2. Designate Volume, Section and Line Number for each comment (or designate as "general").
3. Issue: Be brief, but do include enough information to indicate the issue of concern to you.
4. Designate Priority of each comment as High (H), Medium (M), Low (L)
L: Typo or other minor correction that an editor can manage. Requires no group discussion.
M: Medium issue or clarification. Requires discussion, but should not lead to long debate.
H: Important issue where there is major issue to be resolved. Requires discussion and debate.
5. Proposal: Any new text or explanation you have. Suggestions for rewording or improvement are greatly encouraged. Havin
Submitter Profile Vol Section # Line # Issue
Lynn F MIMA 1 Table 3.2-1 217 We usually don't refer to transactions having options.
Note 4 Rewording suggestion at right-->
Lynn F MIMA 1 Table 3.2-1 221 Need a full TF Reference, since Appendix X does not appear
Note 4 in Vol 1.
Lynn F MIMA 1 3.2.1 237 Redundant bullet items. I think the first can be eliminated.
Lynn F MIMA 1 3.2.1 246 The Institution Name is also required to be configurable, so
that should be called out here.
Lynn F MIMA 1 3.2.1 283 Wrong word. See-->
Lynn F MIMA 1 3.2.1 290 I think it would be very helpful here in the Vol 1 use cases to
point to the Vol 2 material which describes the
implementation of the technical details you are summarizing
here.
Lynn F MIMA 1 3.2.1.2 313 grammar fix -->
Lynn F MIMA 1 3.2.1.2.1.5 386 Change to active voice to make this a bit clearer-->
Lynn F MIMA
Lynn F MIMA 1 4.2 668 I think the contents of Note 1 and 2 would be better included
in Sec 4.2.1, which is the description of the option.
Lynn F MIMA 1 4.4.x 700 You say, "In this example, the centralized archive Image
Manager does not subscribe to notifications from the PIX
700 Manager so it uses the PIX Query [ITI-9] transaction
to obtain all cross-referencing of patient identifiers."
In PIX, a PIX Consumer that receives ITI-10, doesn't
'subscribe' to receive notifications . Rather, it is the PIX
Manager that is configured...for each PIX Consumer the PIX
Manager is configured for the 'domains of interest' to the PIX
Consumer.
See suggested update-->
Lynn F MIMA 1 4.4.x 710 grammar fix-->
Lynn F MIMA 4.4.x 722 I was confused by these bullets. Suggested update--> Also,
maybe changing John Smith to a more un-John-Doe-like
name would be preferable.
Lynn F MIMA 2-3 various sometimes you reference DICOM 2008, others DICOM
Referenced 2009
Standards
sections
Lynn F MIMA 2 4.8.4.1.2.y.1 747 Adding the specific section numbers will make it easier for
implementers to find rqmts.
Lynn F MIMA 2 4.14.4.1.2.1 756 Consider moving this option-specific section under Expected
Actions rather than under Message Semantics. If you agree,
then the section number would change to 4.14.4.1.3.1.
Also, if you agree, this would apply to the other transactions
modified: RAD-15, -16, -18, -19, -29, -30, -31, RAD-aa,
RAD-bb,
Lynn F MIMA 2 4.14.4.1.2.1.1 760 Adding the specific section numbers will make it easier for
implementers to find rqmts.
Lynn F MIMA 2 4.15.4.1.2.1.1 775 Adding the specific section numbers will make it easier for
implementers to find rqmts.
Lynn F MIMA 2 4.16.4.1.2.1.1 789 Adding the specific section numbers will make it easier for
implementers to find rqmts.
Lynn F MIMA 2 4.17.4.1.2.1.1 804 Adding the specific section numbers will make it easier for
implementers to find rqmts.
Lynn F MIMA 2 4.18.4.1.2.y.1 816 Adding the specific section numbers will make it easier for
implementers to find rqmts.
Lynn F MIMA 2 4.19.4.1.2.y.1 829 Adding the specific section numbers will make it easier for
implementers to find rqmts.
Lynn F MIMA 2 4.29.4.1.2.y.1 842 Adding the specific section numbers will make it easier for
implementers to find rqmts.
Lynn F MIMA 2 4.30.4.1.2.1.1 855 Adding the specific section numbers will make it easier for
implementers to find rqmts.
Lynn F MIMA 2 4.31.4.1.2.1.1 870 Adding the specific section numbers will make it easier for
implementers to find rqmts.
3 4.aa.2 and 885 and I like how you included 2 Image Manager boxes in the use
4.bb.2 and 930 and case roles diagram for the Image Manager Storage
4.cc.2 and 984 and Commitment section. Repeat the convention for the other 3
4.dd.2 1049 image mgr to img mgr transactions.
Lynn F MIMA 3 4.aa.4.1.2.4 905 Adding the specific section numbers will make it easier for
implementers to find rqmts.
Lynn F MIMA 3 4.bb.4.1.2 961 Adding the specific section numbers will make it easier for
implementers to find rqmts.
Lynn F MIMA 3 4.bb.4.1.2 971 As far as I can tell, this is the only place you reference the
RAD-26 transaction (Query Reports). Should it be
elsewhere? Also, note that an Image Manager actor is not
currently in RAD-26.
Lynn F MIMA 3 4.bb.4.1.2 973 You have no "Expected Actions" section in this transaction.
Lynn F MIMA 3 4.cc.4.1 1001 Since this is in the RAD-cc transaction, and that transaction
is not referenced for any actors in the XDS-I.b profile, this
requirement does not belong in this section.
Lynn F MIMA 3 4.cc.4.1.2 1023 do you intend to say "is expected to support…" or "shall
support…"? The C-MOVE Destination retrieving Image
Manager is expected to support at least one of the SOP
Classes specified in table 4.8-1.
Lynn F MIMA 3 4.cc.4.1.2 1027 Copy/paste error -->
Lynn F MIMA 3 4.cc.4.1.2 1030 Adding the specific section numbers will make it easier for
implementers to find rqmts.
Lynn F MIMA 3 4.cc.4.1.2 1033 You have no "Expected Actions" section in this transaction.
Some of the content of Message Semantics probably belongs
in this section.
Lynn F MIMA 3 4.dd.4.1.2 1071 suggested clarification-->
Lynn F MIMA 3 4.dd.4.1.2 1077 suggested clarification-->
Lynn F MIMA 3 4.dd.4.1.2 1086 Adding the specific section numbers will make it easier for
implementers to find rqmts.
Lynn F MIMA 3 Appendix X In some sections, it is hard to tease the requirements out of
the narrative text.
Lynn F MIMA 3 x.1 You say, "An Image Manager/Archive does not have to
support all possible patient identifier Assigning Authority
domains that could be encountered in order to conform to
this option."
In fact, I think that an IM supporting this option DOES have
to support all POSSIBLE patient identifier Assigning
authority domains THAT COULD BE ENCOUNTERED.
Right?????\
Lynn F MIMA 3 X.1 1104 In this first reference to the PIX rqmts, consider
adding a TF reference and the full actor name.
Lynn F MIMA througho Replace "PIX Notification" with "PIX Update
ut Notification" which is the real name of the ITI-10
transaction.
Lynn F MIMA 3 X.1 1099 I'm not sure that this section is explicit enough on the
expected actions of an Img Mgr when it supports the
ITI-9 or ITI-10 transaction. When you say that it
supports these transactions "as a PIX Consumer", I (as
an implementer) am sent to ITI Vol 2a and I read the
requirements of a PIX Consumer actor in those
transactions. I think you intend the Img Mgr to do
some specific things in the context of this profile, and
those need to be enumerated here.
Lynn F MIMA 3 X.1 1109 You say, "If supporting the PIX Notification
transaction, it shall support registering for
notifications related to all the patient identifier
domains that the Image Manager/Archive claims to
support."
I'm not sure what you mean by "registering". In ITI-
10, it is the PIX Manager that keeps track of which PIX
Consumers receive notifications for the different
domains. ie at ITI TF-2a:3.10.4.1.2: "The
configuration of the domains of interest to a Patient
Cross-reference Consumer is maintained by the
Patient Cross-reference Manager Actor."
Lynn F MIMA 3 X.1 1115 See previous issue. …at line, you say "Thus, an Image
Manager/Archive does not have to support all
possible patient identifier Assigning Authority
domains that could be encountered in order to
conform to this option."
In fact, I think this sentence can be eliminated. Since
the PIX Mgr is responsible for only sending
notifications that an individual PIX Consumer is
interested in, the PIX Consumer should not
"encounter" via ITI-10 Assigning Authority values that
are not of interest to it.
Lynn F MIMA 3 X.1 1119 Preferably use full actor names. (This comment could
also apply to your use of "PIX Consumer" elsewhere in
the document, but in the end I decided that the full
actor name is too unwieldy to easily use.)
Lynn F MIMA 3 X.2 1125 Suggested rewording-->
Lynn F MIMA 3 X.2 1136 Change to active voice so that the Img Mgr actions are
clearer-->
Lynn F MIMA X.2.2 1187 Incorrect table reference.
Lynn F MIMA 2 X.2.3 1217 & Incorrect table reference (table was probably moved
1227 during editing), and invalid table number.
Also, suggested changes to clarify the rqmts in this
paragraph-->
agfa-pas MIMA 0 general Is an IM/ IA allowed to support the Multiple Identity
Resolution option as ONLY a Sender or Receiver? Or are
IM/IAs always required to support BOTH sender & receiver
BOTH? If they CAN support only 1 or the other, how will
that be distinguished on an integration stmt?
agfa-pas MIMA 0 general Since there is only one default Assigning Authority
configured for a given destination, it implies that the Sending
Image Manager can only support a receiving system that
manages a single Patient ID domain. This may not always be
true in practice. For example, a reading center can support
multiple patient ID domains.
agfa-pas MIMA 0 open issue #3 Open issue #3: HL7 v3 version of PIX transactions vs. HL7
v2.x?
agfa-pas MIMA 0 open issue #4 Open issue #4: Should the Multiple Identity Resolution
option be added to the Reporting profiles and their
transactions?
agfa-pas MIMA 0 open issue #6 Open issue #6: What fields should be used to convey
assigning authority?
agfa-rayb MIIMA 0 general Should the ability to localize / coerce the patient ID to the
local domain of the recipient also apply to WADO retrieve
or Web Service Retrieve (RAD-69)
agfa-rayb MIMA 0 general Although DICOM specifies Patient ID and issuer of Patient
ID to be Type 2 and Type 3 respectively, in practice, we
have seen a number of systems that do no handle null patient
ID well. Should MIMA follow PDI to mandate that Patient
ID and Issuer of Patient ID must be set in the C-Find or C-
Store response?
agfa-kh MIMA 1 3.2.2.2.1 All the examples are patient centric, meaning either Patient
ID or Patient Name is one of the key constraints. Is the
Sending Image Manager also required to return the
longitudinal view even if the query is not patient centric? For
example, what if the query is Study Date and Modality? Is
the Image Manager required to determine the longitudinal
view for each studies that matches the query constraint?
agfa-kh MIMA 1 3.2.2.2.1.2 The text after the table should be 'The query request
identifier specifies a Patient Name … (not Patient ID)'
agfa-kh MIMA 1 3.2.2.2.1.4 Suggest to add a statement above the table indicating that
there is no preconfigured Assigning Authority for Site B.
This will make the explanation of the result after the table
correct.
agfa-kh MIMA 1 3.2.2.2.1.5 In this example, the first response (Study 1.2.9) should not
be returned because the query includes an explicit Site B
issuer constraint
agfa-kh MIMA 1 3.2.1.2.1 and There is no example that is a study level query, using Patient
3.2.2.2.1 ID as a query constraint, and the patient has a number of
different records (e.g. John Smith). This example would
show the use of PIX query to provide a longitudinal record.
Currently none of the example makes use of PIX result.
agfa-pas MIMA 1 2.5 The bullet item specifies a conditionally required actor
grouping of IM/IA with the PIX Consumer (when the
Multiple Identity Resolution Option is supported). Yet there
is no corresponding profile dependency of SWF on PIX.
agfa-pas MIMA 1 3.2 Notes 4 and 5 following table 3.2-1 are simply requirements
for the IM/IA when supporting the Option, which is also true
of the text in section 3.2.1
agfa-pas MIMA 1 4.2 Note 1 after table 4.2-1 a redundant restatement of what is
listed in the table, and thus is unnecessary.
agfa-pas MIMA 1 3.2.1.2.1 There are a lot of good details provided in the examples, but
there seem to be a lack of "clinical situation description"
under which these examples would be necessary/ used.
agfa-pas MIMA 1 3.2.1.2.1.7 In this example the patient ID and issuer are shown as blank
in the retrieved SOP instances. Why is this since the patient
ID can be fully qualified with the issuer of patient ID
attribute that is (can be) included in the objects?? NOTE:
The following rationale is given for including the accession
number in the objects (the rationale holds equally well for
the patient ID): "The Accession Number for the Study is sent
regardless of the preconfigured Accession Number
Assigning Authority for the C-MOVE Destination AE. The
reason for this is that the Issuer of Accession Number
Sequence (0008,0051) can always be included in the SOP
Instances whereas this is not the case for C-FIND
Responses (where it can only be returned if specified in the
query request identifier). "
agfa-pas MIMA 1 3.3.7.1 Figure 3.3-15: The interaction showing the "ignored"
notification from the PIX Mgr to the IM/IA could simply be
removed from the diagram, since according to Note 5 in
section 3.2, it is perfectly OK for an IM/IA to only support
one of the PIX transactions (ITI-9 only in this case). (I.e., the
IM/IA (PIX Consumer) is not required to support both).
agfa-pas MIMA 1 3.3.7.1 2nd bullet (MPPS) after Figure 3.3-16: Shouldn't the PPS
Mgr that is forwarding the PPS to the Centralized IM/IA be
required to add patient ID and accession number issuers to
the MPPS messages it forwards? Otherwise, there may be
collisions at the central IM/IA.
agfa-pas MIMA 1 3.3.7.2 2nd paragraph: Mention is made of "an acquistion modality
in the following process flow". The following process flow
(figure 3.3-16 (17)) doesn't include an acquisition modality.
Plus the figure has the same number as the previous figure.
agfa-rayb MIMA 1 3.2.1.2.1.7 For a receiving system (e.g. Image Display) that does not yet
support the issuer of Patient ID or issuer of Accession
Number, including the information in the returned object
does not necessarily help. So although the rationale for
including Accession Number as stated makes sense from the
Sending Image Manager perspective, it can still be a problem
on the receiving Image Manager.
agfa-kh MIMA 3 4.dd.2 If the Image Manager Storage Commitment transaction stays,
then the Use Case Roles diagram is inconsistent with the
other new transactions. This transaction separates the
sending and receiving Image Manager but these other
transactions do not have this separation in the Use Case
Roles diagram.
agfa-pas MIMA 3 4.bb.3 DICOM standard reference should be to 2009 (not 2008).
(This also occurs is a number of other sections.
agfa-pas MIMA 3 4.cc.4.1.2 Bulleted list of Appendix X requirements at the end of this
section are missing the following:
"Handling of Assigning Authority when Sending SOP
Instances"
agfa-pas MIMA 3 4.dd I don't believe a specialized version of Storage Commitment
is needed as there are no patient identifiers or accession
number conveyed in the N-ACTION or N-EVENT-REPORT
primitives used by Storage Commit.
agfa-pas MIMA 2/ 3 4.aa, 4.bb The editorial instructions should have these new transactions
added to volume 3 (not volume 2)
agfa-kh MIMA App X2.4 On returning a C-Store response, if the Patient ID and Issuer
of Patient ID have been coerced to a local domain for the
receiving Image Manager, the Sending Image Manager
should also include the Original Attribute Sequence
indicating that the two attributes have been modified, similar
to what defined in IRWF
agfa-kh MIMA App X.1 Typo: If supporting the PIX Notification …
agfa-kh MIMA App X.2 Need to choose one of the statements about how to handle
unconfigured Aes. Suggest to use the 'shall' statement
agfa-kh MIMA App X.2.3 How can the Sending Image Manager correlate different
accession number from different domains? For Patient ID,
there exists PIX Manager which handles cross referencing.
However, there is no equivalent service for Accession
Number. That means even though the Sending Image
Manager knows about different accession number on
different domains, it does not know if they are equivalent.
Siemens MIMA General Since a transisition to HL7 2.5 is planned, these should be
applied before releasing this supplement
Siemens MIMA General Query/Retrieve use cases are difficult to understand for
somebody reading them for the first time. Should be more
details on the description
Siemens MIMA Open Issue Open issue 4: Sure else the profile only deals with half of the
integration issues in the enterprise.
Siemens MIMA Open Issue Open issue 5: Don't understand this issue: Is it expected that
the image manager adds information to the stored instances?
Annex A part 2 (Table A.1-x) specifies, that Request
Attribute Sequence shall be filled in the IODs
Siemens MIMA Open Issue Open issue 6: This is an internal IHE issue: I do not care
what is used: be consistent!!!!
Siemens MIMA Closed Issue Closed Issue 4: typo: Requested Attribute Sequence
Siemens MIMA Closed Issue Closed Issue 6: This is a real issue! 2.3. is really getting
outdated. IHE card uses higher version. Difficult for multi-
specialty Image Managers!
Siemens MIMA 1 2.4 Table 2.4- Why is Storage Commitment required in the PIR Integration
1. Profile
Siemens MIMA 1 3.2.1 page 27 Mandatory inclusion of the Institution Name attribute and the
3rd bullet Institution Code Sequence. -->Usually Institution name is
filled by the Modality. It may well be, that this is an
Institution Name that differs from the Institution where the
images are stored. This way you LOSE original information
from the device that created the images!
Siemens MIMA 1 3.2.1 page 27 Coercion of the Patient ID to the appropriate value for the
7th bullet Assigning Authority. plus two next bullets --> This sounds
dangerous
Siemens MIMA 1 3.2.1 page 27 The DICOM Fuzzy Semantic Matching of Person Names
10th bullet option. --> Why is this required? Not seen any conformance
Statement that describes this option!
Siemens MIMA 1 3.2.1.2 Figure 3.2- typo in drawing: PIX Notification [ITI-
2.
Siemens MIMA 1 3.2.1.2.1 Q/R use All the use cases would need some more descriptive text
case
Siemens MIMA 1 3.2.1.2.1 Table with What criteria are used to define that the first two entries in
Patient the table really mean the same patient? Name and DoB?
examples What if these two in reality would be different patients?
Siemens MIMA 1 3.2.1.2.1.1 page 32 "Since the Issuer of Patient ID (0010,0021) is not present in
the request, the Image Manager/Archive uses the
preconfigured patient identifier Assigning Authority
associated with the querying system as if it were included, in
this case “Site B”. Thus it only returns the single matching
patient and its Study information." --> This seems to be
correct for this one example.
Siemens MIMA 1 3.2.1.2.1.7 page 35 Section number is used twice
and 37
Siemens MIMA 3.2.1.2.1.7 page 37 The aim of this supplement was not to change the behavior
of the Image Display, however, it would be nice to add some
guidance/advice for image displays as how to deal with these
use cases (eg if a blank patient id is returned)
Siemens MIMA 1 3.2.1.2.1.7 Response 1 Why is Accession number filled in; comes from site A?
in table
Siemens MIMA 1 3.2.1.2.1.7 Page 38, This means, the objects include the Accession number from
last the other site, whereas this is not displayed in the query
Acc.Numb response? Again this seems risky, since now someone could
er in table start dictating a report for an accession number that is in the
local system not available!
Siemens MIMA 1 3.2.2.2 page 39 "However, the Acquisition Modality may not, as it is not
mandatory for an Acquisition Modality to send these in the
Modality Image Stored transaction. In addition it is not
mandatory for the Image Display to include Assigning
Authority information in its communication with the
centralized Image Manager/Archive." --> Could these be
options to the transactions? Seems unfair to put the burden
ONLY on IM/IA.
Siemens MIMA 1 3.2.2.2. page 39 What if Modality would fill this information, since it
received it in a DMWL?
Siemens MIMA 1 3.3.7.1 figure 3.3- This is also new: sending Proc. Scheduled notifications to
14 multiple destinations.
Does it need to be send to ALL image Managers or only
local and 'centralized'.
If so: do we need to specify new actor: Centrlaized IM/IA
Siemens MIMA 1 3.3.7.1 page 50 "Schedule Procedure: The Procedure Schedule transaction
must go to both the local Image Manager and the regional
archive Image Manager so that the centralized archive can
also manage the procedure workflow properly.
are communicated to both the local PACS Image Manager
and the regional archive Image Manager so that both systems
receive this information and are notified of its status.
Modality Procedure Step information may be essential for
the regional archive to manage such workflow as specified in
the Presentation of Grouped Procedures." -->significant
changes o existing behavior of DSS and MPPS Manager
Siemens MIMA 1 3.3.7.1 Figure 3.3-16 exists twice
3.3.7.2
Siemens MIMA 1 3.3.7.2 Figure 3.3- "Update DICOM SOP Instances..." at central IM/IA -->
17. Does this mean that Patient ID is filled with a value that does
not exist in the domain of the image display site or is it left
blank s described in the use cases 3.2.2.2.1
Siemens MIMA 1 4.2 Please add note, that DSS and MPPS Manager need to be
able to communicate messages tomultiple destinations!
Siemens MIMA 1 4.4.x Figure 4.4- "Note that the Performed Procedure Step Manager is not
x. shown on the Process Flow diagrams and is presumed to be
grouped with the Image Manager. It maybe grouped with the
Department System Scheduler/Order Filler with
corresponding changes in the flow of PPS related
transactions between the Image Manager and Department
System Scheduler/Order Filler." --> nevertheless it should be
indicated that MPPS also needs to be communicated to
centralized IM/IA, since this is new!
Siemens MIMA 2 X.2 "There is also a recognized need to be able to determine the
actual site where data was originally acquired. The
Accession Number Assigning Authority does not necessarily
indicate this information as the Accession Number could be
differ from that when the data was acquired due to Import
Reconciliation Workflow or other undefined workflow use
cases. Therefore, the Institution Name (0008,0080) shall be
used to determine where data was acquired. This is not a
mandatory DICOM attribute though so the Image
Manager/Archive shall also support configurable mapping to
a default Institution Name." --> If this is the case, do we
need to mandate, that receiving SOP Instances ALWAYS
need to overwrite existing information in the local system?
This is quite an interpretation that is now given to Institution
Name, which differs to the current usage of this tag!
Siemens MIMA 2 X.2 "An Image Manager/Archive shall support the ability to be
configured to not communicate with AEs for which there is
no default Assigning Authority." --> What is the purpose of
this requirement? How will this be used in the use cases
before?
Siemens MIMA 2 X.2.1 "The Image Manager/Archive receiving a SOP Instance shall
establish the Assigning Authority of the Accession Number
from the Issuer of Accession Number Sequence (0008,0051)
attribute or, if absent, from the preconfigured Assigning
Authority of the Accession Number associated with the
source system." --> What, if there is a mismatch between the
information in (0008,0080) and Assigning Authority of the
Accession Number (0008,0051)?
Siemens MIMA 2 X.2.3 Is this really a SHALL support Fuzzy Semantic Matching?
Siemens MIMA 2 X.2.4 Why is Patient/Study Only Root mentioned. Shows up
nowhere else in IHE
Hitachi MIMA 2 X.2.4 page 33 Page 33 & 34 There are two different sections labeled
and 34 3.2.1.2.1.5
Hitachi MIMA 2 X.2.4 page 35 Page 35 & 37 There are two different sections labeled
and 37 3.2.1.2.1.7
Radiology MIMA 2 X.2.4 General There was not time to make the edits for the Public
TC Comment text but in the Technical Committee we had
discussed the idea of simplying the Use Cases in the Part I
text and making them more general, and then moving the
particular scenario Use Cases and Query-Retrieve examples
to the Annex.
ework Supplement Public Comment Form
o the IHE Radiology Technical Committee. Comments submitted by July 17, 2010 will be considered in refining the Trial
p?f=12 or send by email to radiology@ihe.net.
fm.
e greatly encouraged. Having a new proposal makes it easier for committee members to address the issue at hand.
Priority Proposal Status
L Note 4: An Image Manager/Image Archive claiming to that Accepted
supports the Multiple Identity Resolution option shall support the
Image Manager Instances Stored, Image Manager Storage
Commitment, Image Manager Instances Query, and Image
Manager Instances Retrieval transactions. It shall also support the
requirements associated with the Multiple Identity Resolution
option of in the Modality Images Stored, Query Images, Retrieve
Images, and Creator Images Stored transactions.
Note 5: An Image Manager/Image Archive claiming to that
L supports the Multiple Identity Resolution option shall...Option
RAD TF-2: Appendix X: Multiple Identity Resolution Accepted
defines common specifications for any Image Manager/Image
Archive supporting this option.
L - Storage of SOP Instance from one Image Manager/Archive Accepted, but with emphasis that this
to another. includes Image Manager to Image
- Capability to both send and receive SOP instances…. Manager communication.
L Configurable, per source and destination of Mandatory Accepted, but added an additional new
inclusion of the Institution Name attribute and the Institution bullet item so that there is one for the
Code Sequence and mandatory inclusion of these in DICOM fact that Institution must be specified
objects. and a second for configuration of value
to be used for some sources.
L In the example illustrated below there is an Acquisition Modality Accepted
and an Evidence Creator that are sending imaging data to the
Image Manager/Archive. The Acquisition Modality and Evidence
Creator are in different patient identify identity domains.
M ...The Image Manager/Archive thus use the preconfigured Accepted. Existing Use Cases have been
Assigning Authority information associated with the Image moved to Appendix X. Volume I Use
Display to determine how to handle the query-retrieve requests. Cases have been simplified and do not
The patient identifier cross-referencing allows the Image contain the query-retrieve examples.
Manager/Archive to support query-retrieval of a patient‟s data
regardless of which particular patient id was used to acquire it.
See RAD TF-2: X.2. (David: note this section number would
change if you accept my edits to Appendix X).
L The following tables describe describes DICOM query-retrieve Accepted
requests…
L The querying Image Display is configured to be associated with Accepted
the “Site B” patient identifier Assigning Authority so the Image
Manager/Archive returnsed the Patient ID is that for Site B.
L Rejected. Notes follow convention of
other Profile Options. Did add bullet
points though.
In this example, the PIX Manager is not configured to send Accepted
PIX Update Notifications to the centralized archive Image
Manager does not subscribe to notifications from the PIX
Manager so it the Image Manager uses the PIX Query [ITI-9]
transaction to obtain all cross-referenceding of patient identifiers.
L The Department System Scheduler/Order Filler. then sends the Rejected. It sends the PIR Update to two
PIR Patient Update/Merge messages to the local Image Manager, Image Managers so this should be
and the centralized archive Image Manager to inform them it of plural.
the merge.
L - If the patient, John Smith, already existed and had a permanent Accepted with slight changes. Change
Patient ID in the ADT system, then once the unknown patient was first name to not be "John" as John
identified as John Smith, the ADT would not send the PIX Smith si too close to "John Doe"
Patient Identity Feed [ITI-8] for the creation of this patient. It
would also not have to send the Patient Registration [RAD-1]
transactions to the Order Placer and DSS/Order Filler.
- If a permanent Patient ID was assigned to the unidentified
patient John Doe then the ADT only sends Patient Identity Feed
[ITI-8] and Patient Update [RAD-12] transactions to update the
Patient Name and other demographics associated with that
Patient ID.with proper information.
Accepted, changed to DICOM 2009.
David - note that the section references in the comments
below from 747 to 961 have been changed in the change-
tracked document I sent you. Those are correct (not
these) if you accept my other edits.
L - Cross-Referencing of Patient Identifiers in Section X.1 Accepted
- Configurable Mapping to Default Assigning Authoritiesin
Section X.2
-Handling of Assigning Authorities in Received when Receiving
SOP Instances in Section X.2.1
M Left as-is for now as existing
transactions are very inconsistent in
terms of what goes in Message
Semantics rather than Expected Actions.
In addition, some of the tables in
Appendix X combine both in that they
list attributes (message semantics) but
also include how these attributes shall be
handled (expected actions). Have added
Expected Actions sections that just list
high-level points about actions that must
be supported.
L - Cross-Referencing of Patient Identifiers in Section X.1 Accepted
- Configurable Mapping to Default Assigning Authoritiesin
Section X.2
- Handling of Assigning Authorities in ReceivedQueries in
Section X.2.3
L - Cross-Referencing of Patient Identifiers in Section X.1 Accepted
- Configurable Mapping to Default Assigning Authoritiesin
Section X.2
- Handling of Assigning Authorities in ReceivedQueries in
Section X.2.3
L - Cross-Referencing of Patient Identifiers in Section X.1 Accepted
- Configurable Mapping to Default Assigning Authoritiesin
Section X.2
- Handling of Assigning Authorities in Received Retrieval
Requests in Section X.2.4
L - Cross-Referencing of Patient Identifiers in Section X.1 Accepted
- Configurable Mapping to Default Assigning Authoritiesin
Section X.2
- Handling of Assigning Authorities in Received Retrieval
Requests in Section X.2.4
L - Cross-Referencing of Patient Identifiers in Section X.1 Accepted
- Configurable Mapping to Default Assigning Authoritiesin
Section X.2
-Handling of Assigning Authorities in Received when Receiving
SOP Instances in Section X.2.1
L - Cross-Referencing of Patient Identifiers in Section X.1 Accepted
- Configurable Mapping to Default Assigning Authoritiesin
Section X.2
-Handling of Assigning Authorities in Received when Receiving
SOP Instances in Section X.2.1
L - Cross-Referencing of Patient Identifiers in Section X.1 Accepted
- Configurable Mapping to Default Assigning Authoritiesin
Section X.2
-Handling of Assigning Authorities in Received when Receiving
SOP Instances in Section X.2.1
L - Cross-Referencing of Patient Identifiers in Section X.1 Accepted
- Configurable Mapping to Default Assigning Authoritiesin
Section X.2
- Handling of Assigning Authorities in ReceivedQueries in
Section X.2.3
L - Cross-Referencing of Patient Identifiers in Section X.1 Accepted
- Configurable Mapping to Default Assigning Authoritiesin
Section X.2
- Handling of Assigning Authorities in Received Retrieval
Requests in Section X.2.4
L Do the same for 4.aa.2 with "Image Manager (sending)" and Rejected. Drawing two Image Managers
"Image Manager (receiving) in the actor boxes. is actually not the proper convention for
For 4.bb.2 with "Image Manager (querying)" and "Image Manager these diagrams.
(receiving)"
For 4.cc.2 with "Image Manager (retrieving)" and "Image
Manager (receiving)"
For 4.dd.2, change the diagram to be consistent with the text that
follows, ie. "Image Manager (requesting)" and "Image Manager
(receiving)"
L - Cross-Referencing of Patient Identifiers in Section X.1 Accepted
- Configurable Mapping to Default Assigning Authoritiesin
Section X.2
- Handling of Assigning Authorities when Sending SOP Instances
in Section X.2.2
L - Cross-Referencing of Patient Identifiers in Section X.1 Accepted
- Configurable Mapping to Default Assigning Authoritiesin
Section X.2
- Handling of Assigning Authorities in Queries in Section X.2.3
M
Reference is to Table 4-26. The
problem is that the RAD-26
transaction does not support any of
the SWF Actors. I looked at what
Cardiology does to see if their
approach could be used however,
Cardiology does not actually add
any new Actors. It just adds new
options for existing Actors and their
transactions, whereas MIMA is
actually adding new transactions.
To deal with this issue, I clarified the
text regarding how the SWF
Multiple Identity Resolution Actors
correspond to the 'SCU' and 'SCP'
actors for this and other tables that
are referenced in Appendix X.
H Kept current approach using
Message Semantics. However, all
transactions have at least an
Expected Actions section added
with high-level overview.
This text is copied from the Retrieve
Images transaction which is in XDS-
I.b. Modified XDS-I.b Trial
Implementation text (as a separate
document for now) to include the
new Image Manager Instances
Retrieval transaction.
Eliminated the table reference as it
causes confusion.
L The querying retrieving and receiving Image Manager shall
meet the requirements defined in Appendix X: Accepted
L - Cross-Referencing of Patient Identifiers in Section X.1
- Configurable Mapping to Default Assigning Authoritiesin
Section X.2
- Handling of Assigning Authorities in Received Retrieval
Requests in Section X.2.4 Accepted
There should still be an Expected
Actions section. Keep all existing
text in Message Semantics but put
high-level statements in Expected
Actions.
L The Storage Commitment AE Title used by the receiving
Image Manager may or may not be the same AE Title as
the one it used as C-STORE SCP for the Image Manager
Instances Stored (C-STORE) RAD-aa transaction service.
Accepted
Under normal circumstances, in the event that the
receiving Image Manager cannot service the storage
commitment request, it shall send the reason inwhich can
be determined by the "Failure Reason
Attribute". In this case, the requesting Image Manager
shall not delete nor modify the affected respective SOP
instance(s). Accepted but used 'referenced'
rather than 'affected'
L - Cross-Referencing of Patient Identifiers in Section X.1
- Configurable Mapping to Default Assigning Authoritiesin
Section X.2
Accepted
M I have submitted a separate document to David containing change-
tracked updates to Appendix X as a proposal to make the content
more readable. Accepted but with revisions.
H
Removed this text as it causes
confusion. Added text to use case
X.1.3 to clarify how a local Image
Manager/Archive can be deployed
to only support its particular local
patient identifier domain.
L The Image Manager/Archive shall support the PIX Query
[ITI-9] (see ITI TF-2a: 3.9) or PIX Update Notification [ITI-
10] (see ITI TF-2a: 3.10), or both transactions as a Patient
Identifier Cross-Reference (PIX) Consumer in order to
obtain the cross-referencing of patient identifiers. Accepted
L
Accepted
M
Look at how IRWF incorporates the
PDQ query into its volume II text.
Appendix X must make it clear
exactly what an IM supporting PIX
Query or PIX Notification must do.
MPPS and Worklist have 'bridging'
requirements. Consider using this
model to see if it can work in Annex
X. i.e. link Other Patient IDs
Sequence to results of PIX Query.
IRWF just states that: "The Patient
information is received through
a Patient Demographics Query" for
Unscheduled Import (4.59.4.1.2.3.2)
and "The reconciled information
provided from the Modality
Worklist transaction (see RAD TF-2:
4.5) or the Patient Demographics
Query (see ITI TF-2:4.21) shall be
included in the
headers of the generated images."
for Imported Objects Stored
(4.61.1).
M
Changed Image Manager/Archive to
be Grouped with a PIX Consumer.
Modify the language to make it
clear that an Image Manager can
still use PIX Notification to get cross-
referencing but it still must be able
to show that it supports PIX Query
in order to be conformant. Focus on
the functionality that an Image
Manager must demonstrate.
Accepted. In addition though, add
language that makes it clear what
an Image Manager must do when
supporting PIX Query and/or PIX
Notification.
L Support for this option does not require support for Import
Reconciliation Workflow or XDS-I.b Imaging Document
Consumer or Imaging Document Source functionality by
the Image Manager/Archive.
If an Image Manager/Archive supporting the Multiple
Identity Resolution option is also acting as an XDS-I.b Accepted. Correct Actor names
Imaging Document Consumer or Imaging Document throughout document.
L Source then...Identity Resolution option mandates that
The Multiple
tThe Image Manager/Archive that supports the Multiple
Identity Resolution option shall maintain a list of
preconfigured Assigning Authorities for peer systems. This
allows enables the Image Manager/Archive to support
systems that do not convey or handle Assigning Authority Accepted
L related attributes in transactions.
There is also a recognized The Image Manager/Archive
needs to be able to determine the actual site where data
was originally acquired. The Accession Number Assigning
Authority does not necessarily indicate this information as
the Accession Number could be differ from that when the
data was acquired due to Import Reconciliation Workflow
or other undefined workflow use cases. Therefore, the
Image Manager/Archive shall use Institution Name
(0008,0080) shall be used to determine where data was
acquired. Because tThis is not a mandatory DICOM
attribute, though so the Image Manager/Archive shall also
support configurable mapping to a default Institution
Name to each Acquisition Modality, Evidence Creator,
and Image Display.
Accepted with revision. Image Display actor does not sen
L Change X-1 to X.2.2-1.
Check Table references throughout.
TF seems to be inconsistent in
regards to Table numbering.
Sometimes it uses the full section
numbering and in other cases just
the main section number (i.e.
should a table in X.2.3.2 be
numbered X.2-n or X.2.3.2-n?)
The matching keys and return keys that shall be supported
by the querying Image Manager (Query SCU) and the
receiver Image Manager (Query SCP) are defined in Table
4.14-1. and the Table X.2-1 4.bb-1 below contains
additional requirements for Image Managers supporting
the Multiple Identity Resolution option when they are a Check Table references throughout.
H Make the text clear about whether an IM/IA has to be able to do No, it must support both. Clarified in
both sender & receiver roles. This will affect how the "Use Case Volume I, 3.2.1 bullet point. The
Role" diagrams in sections 4.aa.2, 4.bb.2 and 4.cc.2 are drawn. transactions talk about a sending and
receiving Image Managers to make it
easier to understand however an IM
supportign this option shall support
being both a sender and a receiver.
H Suggest to explicitly stated that it is out of scope for MIMA to Already does require this support
support multiple default assigning authority for a given receiving through configuration of different AEs.
system. Called this out with text in X.2.2.1.
M Recommend that only the HL7 v2.x be required to improve the
likelihood of adoption of the Multiple Identity Resolution option.
M Suggest that given the lack of adoption of the IHE Reporting Discussed on Tues. Refer to those
profiles, it is not a wise use of time to spend time specifying the comments
option for the Reporting Profile.
H The issue lists some XDS-based references regarding PIX Manager requires all three to be
inconsistencies. While that's interesting, the more applicable/ sent. HL7 Normalization CP will change
relevant TF parts with respect to the population of the assigning SWF transactions to mandate all three.
authority inlcude: RAD TF-2: 4.1.4.1.2.3 (last paragraph), and ITI MIMA mandates all three so this
PIX transactions ITI-8 and ITI-9 which only require the source Supplement will be dependent on this
system send EITHER the namespace ID (subcomponent 4.1) or CP. May need to add language clarifying
universal ID & universal ID type (subcomponents 4.2 & 4.3). that mapping must provide all 3
Since the supplement doesn't change the HL7 transactions coming components, and how a system shall
into the IM/IA, it must be made capable of supporting the handle a transaction that does not
namespace ID, include all three (i.e. a query request
from an actor that is not conformant).
Also need to modify all the query-
retrieve examples where the query
currenlty includes Issuer of Patient ID to
also include the Issuer of Patient ID
Qualifiers Sequence. Add example
where only Issuer of Patient ID is
included.
H Yes, philisophically. But how do we
document this as this would be a change
to XDS-I transactions? Could decide not
to address changes needed to XDS-I for
this Supplement, and address those later.
However one of the original goals of this
was to add 'centralized archive' support
to XDS-I.
H Suggestion: If there is no matching patient ID for the domain for Not possible for C-FIND Response. For
the consumer, then the Sending Image Manager should either C-STORE we revised the text during
leave the original Patient ID and Issuer of Patient ID in the Tuesday's discussions.
response.
H Suggest to include text that Sending Image Manager is only NOTE: check that query text is clear
required to return longitudinal view for patient centric query. what the IM should do if the querying
Otherwise, the impact on the Sending Image Manager can be systems does have a preconfigured
significant that degrades the responsiveness of handling query assigning authority but includes Issuer
requests. of Accession Number Sequence in the
query but with no values. Should add a
query example for this issue (i.e. query
has just Study date range).
L Correct the text Accepted.
M Accepted.
H Rejected. However a number of
questions have been raised about how
Issuer of Patient ID should be properly
handled when it is included in a DICOM
query. A decision had been made that a
DICOM CP was not needed regarding
this however this has been questioned.
In particular is the DICOM Standard
clear how a query that includes an Issuer
of Patient ID value but no value for
Patient ID should be handled? Review
of prior discussions makes me think that
a DICOM CP is actually needed. This
Profile elevates Issuer of Patient ID and
other Assigning Authority related
attributes to be Required Matching
Keys. The DICOM Standard currently
appears to be ambiguous as to what this
actually means in cases where the
corresponding attribute (i.e. Patient ID)
is left blank. For now, the MIMA
Supplement continues with the
behaviour that was documented in the
Public Comment text.
H Add an study level query example to search for John Smith Accepted. Add the example.
records using Patient ID as a query constraint.
M Since required IHE behaviors are specified by the combination of Keep text as-is. TC will consider
an Actor in a Profile, and since the PIX Consumer is not revising current text in the future to deal
introduced as an Actor in SWF (or PIR) by the MIMA with the inconsistent way that
supplement, I think there must be a profile dependency of SWF on 'dependencies' are dealt with.
PIX in order to give "context" to the desired behaviors.
L Suggest moving the text from Notes 4 & 5 into section 3.2.1 Accepted.
L Suggest removing Note 1 to avoid possible inconsistency between Option 1: Add a dependency, if an IM
the note and the rows in the table. supports the SWF MIR option then it
must also support the PIR MIR option.
Option 2: Put a note in PIR that
everything you do to support PIR must
support the underlying options
supported for SWF. So an IM
supporting the SWF MIR option and
supporting PIR, must support PIR for
MIR. Preference is for Option 1. Maybe
don't even need to add MIR to PIR.
Could be obvious once the HL7 process
flow to centralized archive is added in
SWF MIR. The revised text incorporates
Option 1.
L For each example, suggest adding a brief description of what the Accepted. Still need to revise text.
end user (or querying system) is trying to accomplish.
H Make the handling of patient ID and accession number consistent Accepted.
in this case.
L Accepted. Remove from Volume I
diagram. However, add text (or
diagram?) to Vol II. Think it is useful to
talk about a real case where an IM might
want to implement 'real' support for PIX
Query even though it is normally relying
upon PIX Notification.
H Add the necessary requirements to have the PPS Manager Need to research. Could accept this
augment MPPS messages forwarded to the central IM/IA based suggestion but then would have to add
on the assigning authority configuration associated with the MIR option to the MPPS Manager.
modality that initiated the MPPS message. Another possible approach would be to
somehow mandate than an IM
supporting the MIR option must only
'match' MPPS by using Study UID.
L Remove the 2nd paragraph (it is unneeded). Renumber the figure's Accepted.
caption to 3.3-17.
H Blank out the accession number if there is no accession number on Already discussed. Specifications for
the configured domain for the receiving system. handling of Accession Number in sent
SOP Instances have been revised.
M Make the diagram consistent with other transactions. Accepted, been fixed.
L Replace ALL occurences of DICOM 2008 with DICOM 2009 Accepted.
L Needed since part of the retrieve transaction is actually a Accepted.
CSTORE of DICOM SOP instances
M Remove the unneeded transaction section and replace references Rejected. Decision was made to keep
to it with the normal Storage Commit Transaction [RAD-10]. MIMA consistent by adding all new
transactions for the option.
L Accepted. Edited MIMA Supplement to
put new Transactions and Appendix X
in Vol 3.
H Add text to inject Original Attribute Sequence when Patient ID Decided to use Original Attribute
and Issuer of Patient ID have been coerced. Sequence only to indicate that new
attribute values were added based on the
preconfigured Assigning Authority
information. Make sure these
requirements are clearly stated. Find out
if DICOM Standard is clear or needs a
CP to specify how the Original Attribute
Sequence can be used to indicate that
attributes were added, rather than having
been deleted or modified.
L Accepted.
H Handled by changes.
H Suggest to remove coercion of Accession Number. There is no coercion of Accession
Number. Text was already added.
H Proposal is to complete HL7 2.5 CP
before MIMA goes beyond Trial
Implementation, another is to complete
CP before even going to TI. What
dependency if any should there be on the
2.5 CP?
H Accepted. Examples will be revised to
make it clearer which use case scenario
they are examples of, and the purpose of
the particular example.
Reword open issue 5 to reflect the fact
that the Sequence is already required.
The open issue should just talk about
whether Order Filler and Placer Number
and their assigning authorities should be
added.
h Liase (and cleanup) with ITI definitions! David Heaney will create an ITI CP for
this particular issue. Sounds like all
three can be mandated as namespaceID
should also be globally unique. Need to
verify that this is really the case. Look
into why ITI TF-3, section 4.1.7, table
4.1-3 specifies that the Registry shall not
use the namespace ID.
l Request Attribute Sequence Accepted
h Reject MIMA, until cleanup of IHE has been performed! Accepted. MIMA will rely upon HL7
Normalization CP.
l Good question. Create a CP that
removes Storage Commitment and
Image Manager Storage Commitment as
being required for PIR. MIMA
Supplement itself should stay as-is
though.
m Do we want to mandate any behaviors
regarding handling of an included value
in the case where Institution Name is
sent but Institution Code Sequence is
not? i.e. The Image Manager shall be
capable of doing a lookup to test if the
included value is valid, and if so ...
Mandate putting it in the Original
Attributes Sequence (0400,0561). This
would have to be mandated on the
Image Managers Instances Stored
transaction. Decision was not to do this.
IM shall use Institution Code Sequence
if it is provided but will always replace
Institution Name it only it is included.
l Rejected, but add some clarification
regarding Patient ID 'coercion'.
m Add some wording about why Fuzzy
Matching was added. Add some more
clinical information about use cases.
l PIX Notification [ITI-10] Accepted
Try to fix.
h Please specify how patients are identified to be the same! The Image Manager has found out the
cross-referencing from the PIX
Manager. Add descriptive text about
this. Make sure it is clear that the Image
Manager uses the cross-referencing from
the PIX Manager and is not required to
support internal heuristic based patient
matching.
m Not sure if this really covers all possible use cases, esp. if patient See above.
identification is not clear as in comment above.
l Accepted. Fix section numbering.
m Look into whether or not there is
existing text dealing with blank Patient
IDs. How can we get Image Display
implementors to look at this Supplement
and comment on the implications.
Consider adding text to RAD-14 and
RAD-16 so that Image Display's are
aware of this. Should we consider using
some standard id value or tag to
differentiate this use case. Idea
discussed is to add informative text for
Image Display, Modality, and Evidence
Creator. Volume I may be best. Have a
look. Add general language about blank
patient ids. There are already notes in
the Retrieve transaction.
m I would expect Acc,. Number is left empty. Accepted. Text will be revised.
Accession Number behaviour will
depend upon configuration.
m Should there be a display requirement? Accepted. Text will be revised.
Accession Number behaviour will
depend upon configuration.
m Consider adding Acquisition Modality,
Image Display, and Evidence Creator to
this named option so it would be clear
how they should support the option (by
sending the necessary 'issuer' attributes).
m Consider adding Acquisition Modality,
Image Display, and Evidence Creator to
this named option.
m The Profile needs to be clarified. The
DSS/Order Filler needs to be able to
send to the local and centralized IM.
Add wording or process flow to show an
example that illustrates why this is
necessary (i.e. a Procedure Update
example or two).
l Do need DSS/Order Filler to be added
to the Multiple Identity Resolution
Option. This option needs to make it
mandatory to include the Issuer of
Accession Number. It is already
mandatory for it to include the Issuer of
Patient ID (maybe call this out). Add a
configurable option so that Image
Managers can support DSS/Order Fillers
that do not supporty this option by
associating different ports. Mention
somewhere about DSS/Order Filler
having to support sendign to multiple
IMs, about MPPS Manager having to be
able to send to both 'local' and the
centralized IM.
Renumber figures Accepted. Renumber the figures.
m Need to make the diagram clearer.
Either it finds a local patient id for the
domain of the Image Display from the
PIX Manager or it does not. If it does
then it returns this in the query responses
and in the retreived SOP Instances. If it
does not then the Patient ID will be
blank.
m Make sure this is clear. Sounds like we
need to modify the text. Possibly have to
add new options. However, a receiving
Image Manager supporting multiple
domains could still link a received
MPPS to the correct patient and study
through the included Study Instance
UID. So are the 'issuer' attributes really
required to be included in MPPS
messages for the Multiple Identity
Resolution option?
m Update diagram to at least show message send to central IM/IA Accepted. Update diagrams.
h Think that revised text deals with this
comment.
m Drop this requirement. Consider adding
a note though to deal with the original
intended use of this requirement.
m No longer relevent. Determining Patient
ID issuer or Accession Number issuer
by Institution Name is no longer a
requirement.
Yes.
Removed Patient/Study Only. Still a
question of whether this sentence is
needed at all. Can 'Issuer' attributes even
be added to a C-MOVE Request?
Thought they could not but could not
find any language in DICOM that
explicitly forbids it. Review previous
notes as I know this issue was
researched during an earlier meeting.
L Fix
L Fix
H Accept. Simplify the Volume I content.
ining the Trial
e at hand.
mage Display actor does not send objects to an Image Manager/Archive.