ABCDEFGHIJKLMNOPQRST
1
Please complete this spreadsheet by May 17, 2017
To submit your entry, scroll right and add your votes/comments in the next available column...		Ballot contents:
2
ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance/CPs/Ballots/2017/Ballot_41/
3
4
Organization-->Change HealthcareICWN. Harris Computer Corp.ASIP SantéMerge/IBMBy LightAgfaPhilips
University Bank
ForcareReady ComputingArsenàl.ITAllscripts
IntraHealth International, Inc.
5
RESULTS
Y/A/N		CP-ITI-Descr.ProfileDoc updatedYour name-->Elliot SilverTarik IdrisElliott LavyNader CHEAIBKen MeyerJohn MoehrkeRob HornChris MeloMick TalleyMark SinkeKaren WittingMauro ZanardiniGeorge ColeLuke Duncan
6
13/1/0624-03
Appendix V needs update to reference recent standards
Webservices-basedVol 2x
Yes/Abstain/No
YesNo (vote changed to Yes after fix)YesYesAbstainyesYesYesYesYesyesYesYesYes
7
624-04 approved w/ updatesComments:
(Req'd if No)		Table V.2.4-1 still contains a reference to wsoap11 in the line starting with wsoap, which is no longer properly defined.
RESOLUTION: fixed;
8
8/6/0839-05Clarify XPID audit messagesXPIDXPID-TIAbstainYesYesYesYesyesYesabstainYesYesabstainabstainAbstainAbstain
9
839-06 approved w/ updates"The ParticipantObjectDetail element will occur twice" -> use SHALL.
The URN "urn:ihe:iti:xpid:2016:patientIdentifierType" seems to be new. Therefore it was defined in 2017 and should not say 2016. Also, the URN should be added to the IHE ITI URN list.
RESOLUTION: Updated will to shall and 2016 to 2017
will add VOl 3 namespace additions section for new URN		3.64.5.1.1 - Can we require RoleIDCode for Human Requestor?
RESOLUTION: changed back to U
Destination UserIsRequestor can remain "false".
RESOLUTION: John & Ken disagree; no change
For PatientObjectDetail, change "will occur twice" to "shall occur at least twice".
RESOLUTION: done
3.64.5.1.2 - Same as 3.64.5.1.1. PLUS, add an optional Human Requestor element.
RESOLUTION:		Human Reqestor - User - RoleIDCode should not be made Manditory. It should be provided if known, but not manditory. Change this back to U and not specialized.
RESOLUTION: Agree
10
13/1/0923-09
Redoc aggressive validation specification
XD*Vol 3YesyesYesYesYesyesYesyesYesYesyesyesYesAbstain
11
923-10 approved w/ updatesEditorial Changes: Please add to Rationale For Change (at end):
Opinion was to go back to 'silence'. That means the following for 923:
· Remove all of the "shall not" sentences.
· Remove Section 4.2.3.1.11
We should also modify 1016 to remove the text that refers to 4.2.3.1.11.
RESOLUTION: Added to rationale
12
8/5/0937-13
DSUB - corrections for audit messages
DSUBVol 2bAbstainabstainYesYesyesYesyesYesYesabstainyesAbstainAbstain
13
937-14 approved w/ updates
DSUB-Ext-TI
3.52.3.1.1 and 3.52.3.1.2: Query Parameters ParticipantObjectQuery is indicated as conditional, but no condition is given.
RESOLUTION: Agree. C changed back to M.

3.53.5.1.1, etc.: In the DocumentEntry SubmissionSet table should it be "DocumentEntry/SubmissionSet" RESOLUTION: Agree; fixed

It looks like Folder is no longer a possile object type for these audit messages in the TF. Is that correct? Why not? Was it incorrectly included before, or has something changed?
RESOLUTION: The folder-related updates are applied in the DSUB Extensions TI Supplement		3.53.5.1.1, 3.53.5.1.2, 3.54.5.1.1, 3.54.5.1.2, 3.70.5.1.1, 3.70.5.1.2 - Shouldn't ParticipantObjectIDTypeCode just indicate that it's an entryUUID? The specific type could be added to ParticipantObjectDetail, if desired.
RESOLUTION: John indicated that the current CP follows the established pattern in the TF, so we should continue using the pattern (though it is not correct/ideal). Comment withdrawn.		Editorial Changes:
1) Correct 3.52.6.1.1 & 3.52.6.1.2 - Query Parameters-"Subscribe message only" should be underlined
RESOLUTION: fixed
2) Rationale For Change - add item #3 - "Editor instructions updated."
RESOLUTION: fixed
14
12/1/1956-02
IsSnapshotOf association documentation clean up
XD*Vol 3YesyesYesYesNoyesYesyesYesYesYesyesYesAbstain
15
Not approved; rationale updated; back to assigned
I am not sure of the usage of "Stable"
with capital S. Has it always been used
this way?
RESOLUTION: No change; confirmed ok
Disagreeing with removing shall and bullets from 4.2.2.2.6 at this time (also a bullet that was not changed for 3.43). Shall language used in other document relationship sections. These sections are references by Volume 2. (e.g.: 3.42 - "If the Integrated Document Source / Repository supports the Document Replacement Option, it shall be able to generate replace semantics as defined in ITI TF-3: 4.2.2.2.3."). See comments for CP-ITI-1034.
RESOLUTION: Rationale updated with issues that need to be addressed. No vote stands
16
9/5/0999-02
Make ITI-51 audit scheme conformant with DICOM
MPQVol 2bAbstainAbstainYesYesYesyesYesyesYesYesabstainyesAbstainAbstain
17
999-03 approved w/ updatesSuggest leaving audit EventTypeCode as "EV(“ITI-51”, “IHE Transactions”, “Multi-Patient Query”)" (multiple locations) to improve compatibility with existing implementations. Using the correct transaction name isn't enough of an improvement to break compatability.
RESOLUTION: Keep as it. It is a correct change and the string is just a description so John said we should fix it.
For Source UserID (multiple locations), is there a conditional optionality we can use instead of M or U? It's only manditory when Async.
RESOLUTION: Agree; changed M to C		Keep "false" for UserIsRequestor for the destination
RESOLUTION: Disagree; no change.
Add "Home Community ID" to ParticipantObjectDetail, to match 3.18.5.
RESOLUTION: agree; CP will be updated to add homeCommunityId using ITI-18 as a model
18
13/1/01016-01
Clarify Extra Metadata Attributes Section
XD*Vol 3YesNo (vote changed to Yes after fix)YesYesNo (vote changed to Yes after fix)yesYesyesYesYesyesyesYesAbstain
19
1016-02 approved w/ updatesSection 4.2.3.1.11 no longer exists in CP-923, therefore the reference in this CP in 4.2.3.1.6 no longer makes sense. Remove the whole sentence.
RESOLUTION: Agree
Instead of urn:nist:extraMetadataSlot the example should use the official RFC 6963 example namespace: urn:example:extraMetadataSlot - this avoids the risk of readers assuming they are allowed/meant to use the NIST namespace.
RESOLUTION: fixed		Remove references to 4.2.3.1.11 in editor box and text. Adjust the rationale accordingly.
RESOLUTION: fixed		References to "new section" in CP-ITI-923 that did not survive TC need to be removed: 1) Rationale For Change, 2) Editor Instructions, & 3) Added text-Paragraph #1. In CP-ITI-923, the new section was taken out after approval of this CP. This CP was not updated to eflect this change.
RESOLUTION: fixed		ditto (references to new section need to be fixed)
RESOLUTION: duplicate; fixed
20
11/3/01020-00
Remove “temporary” homeCommunityId restriction
XCAVol 2bYesyesYesYesYesyesYesabstainYesYesyesAbstainYesAbstain
21
1020-00 Approved
22
11/1/21026-02
Correct ITI-18 references to missing TF-3 sections
EditorialVol 2aYesyesNoYesNoyesYesyesYesYesyesYesYesAbstain
23
Not approved; CP title and rationale updated; back to assignedThe text is left over from XDS.a. The whole sentence should be removed.
RESOLUTION: CP rationale and title updated to reflect new scope; no vote stands		Believe it should be Section 4.2.3.2 through 4.2.3.4 . This more closely matches the Revision 9 references.
RESOLUTION: Elliott L disagrees. Section 4.1.3.2 and 4.1.3.4 reference the 4.2.3.2 and 4.2.3.4 sections.
There are other TF-3 references in 3.18 that are also outdated (search "TF-3" in Volume 2a ). Fix them now in this CP? A couple might not have a direct match.
RESOLUTION: CP rationale and title updated to reflect new scope; no vote stands
24
13/1/01032-00
Update Volume 3 Section 4.2.3.1.2 - Creating Coded Attributes For Associations
XD*Vol 3YesyesYesYesYesyesYesyesYesYesyesYesYesAbstain
25
1032-00 Approved
26
12/2/01034-00UniqueId in RelationshipsXD*Vol 3YesNo (vote changed to Yes after fix)YesYesNo vote withdrawn; change to abstainyesYesyesYesYesyesYesYesAbstain
27
1034-10 approved w/ updatesI don't find the Appendix B reference helpful here - it doesn't discuss what it means to have a different or identical uniqueId in XDS. We should instead reference 4.2.3.2.26.
RESOLUTION: Agree fixed.
I would also make the meaning of "equal" more explicit. E.g., "The uniqueId of the new document shall be different than the uniqueId of the existing document, unless the two documents' byte sequences are identical (e.g., when replacing a document with a copy of itself to change the metadata)."
RESOLUTION: Agree; fixed		Disagree with removing sentence - "The entryUUID shall be unique or a symbolic Id as described in Section 4.2.3.1.5."
RESOLUTION: Elliott says that this sentence contains info that also exists elsewhere. Comment withdrawn.
Comment - Section needs a full rewrite, ecspecially given the number of changes made this year. Need to decide if normative vs imformative (ref CP-ITI-956).
RESOLUTION: Ken will write a new CP to apply to version 14 of Vol 3.. Ken withdraws No vote on this CP
28
13/1/01035-00
Volume 3: Correct Section 4.1.4-Submission Request
EditorialVol 3YesYesYesYesYesyesYesyesYesYesyesYesYesAbstain
29
1035-00 Approved
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100