ABCDEFGHIJKLMNOP
1
Please complete this spreadsheet by September 16, 2022
To submit your entry, scroll right and add your votes/comments in the next available column...		Ballot contents:
2
https://drive.google.com/drive/folders/10vklPdEJ8mPEf6LrmNSC9A899wsrt6Ic?usp=sharing
3
4
Organization-->By Lightahdis agArsenàl.ITEpicGEPhilipsANSIHE SuissePATH
5
CP-ITI-Descr.Your name-->John MoehrkeOliver EggerGregorio CanalSpencer LaGesseSteve NicholsChris MeloMeriem MaaroufiMartin SmockLuke Duncan
6
1014Fix XCDR Auditing SpecifiationYes/Abstain/NoYesYesNoAbstainAbstainYesAbstainYesAbstain
7
Comments:
(Req'd if No)		1) Rationale is not clear on what should we do... seems it is still pending on Ballot 60
2) Usally we put the homeCommunityId in the AuditMessage/ParticipantObjectIdentification not in the AuditMessage/ActiveParticipant in order to be consistent with other transactions i suggest to put the homeCommunityId in the AuditMessage/ParticipantObjectInfo/ParticipantObjectDetail of the SubmissionSet.
8
1226XDR/XCDR: Clarify “without any context”NoAbstainNoAbstainAbstainAbstainAbstainAbstainAbstain
9
The goal is to allow for the transaction to contain the elements that the transaction supports (the referenced context). Yet the inserted sentence is not understandable. It is unclear what is mean by "..reference historic metadata". What does that mean? What is a "reference" and what is "historic" and is "metadata" meaning all of Volume 3 or more than IHE defines?
If the goal is to indicate that the recipient can not impose rules beyond those stated in Volume 3, then this seems self evident. If it means to say something beyond that which is expressed in Volume 3, then it is unclear what it is saying.		Clarify wording as Johns indicatesAgree with jhon the sentence added iti is not clear and do not clarify the without any context.
10
1252Clarify use of LID Attribute in ITI-41 TransactionAbstainYesNoAbstainAbstainYesYesYesAbstain
11
I think ITI should make a choice of either:
- not use the lid attribute if they don't support the Metadata Options.
- or implement the restrictions on the lid attribute defined in the Metadata Update extension of they support the Metadata Update option.
Just adding a note will leave the interoperability issue there. Since MU is still in trial implementation we can do something that it is not percieved as a breaking change.
Maybe we could add the Metadata Update Option also to the document Source, in order to explain that if a Document Source works with a registry that support Metadata Update Option should either:
- not use lid attribute
- assign to the lid attribute the same value of the id
A better solution would be good, but I am not enough of an MU expert to offer one.
12
1279ITI-19 updates to remove mention of User Authentication and add generic rolesNoAbstainAbstainAbstainYesAbstainAbstainAbstain
13
There are options in ATNA for STX that are not strictly "Network". It is very possible to use the non-TLS (S/MIME, WSSecurity, AS4) security in a way that is independent of the identity of that network identity of the Secure Node/Application. Thus I am not liking the use of the word "Network" in this CP. Historically "Secure Node" was the term used for this, and the addition of "Secure Application" was implying the identity was associated with the application (if not the node). The idea of defining a role is good, just not using the word "network". How about "Entity", "Agent", "Actor", "System", or just "Node". Seems the concept of a Agree with John.
14
1274RMD: Clarify conditions for metadata removal for Doc Registry in ITI-62AbstainYesAbstainAbstainAbstainYesAbstainYesAbstain
15
it is not clear to me if adding the bullet it is requiring the document administrator to also remove SubmissionSetObjects that are referenced by the HasMemeber Association. if so this is a possible breaking change and my vote change to NO (see closed issues RMD_016 (MV038))
16
1275Align Metadata Update with Restricted Metadata Update in context of CP-ITI-1190AbstainYesAbstainAbstainAbstainYesYesAbstainAbstain
17
Comment from Lynn to text of MV037 should be considered
18
1278Delayed Document Assembly – hash and size inconsistencyYesYesyes, butYesYesYesYesYesAbstain
19
Should we also update the first sentence in section 10.2.10 ?:
A Document Consumer declares the Delayed Document Assembly Option when it is able to understand that some documents included in the response to a Registry Stored Query will have a zero size and hash value but once retrieved those attributes will be updated to the correct values.		Agree with Gregorio. Also, does this make a final text profile (XDS.b Delayed Document Assembly) dependent on a TI profile (MU)? Is that a problem?
20
1280Clarify implication of grouping with ATNA Secure Node/ApplicationYes, ButYes, but alsoyesAbstainYesYesAbstainYesAbstain
21
section 9.1.1.1 is really Secure Node. Suspect a copy/paste problem.
Also, the inserted sentence uses "product" at the beginning and "implementation" at the end of the sentence in a way that seems to imply they are the same thing, but may not be read by everyone as the same thing. Recommend againt "product" as some in the open-source community don't feel that applies to them (although we use "product" in describing an IHE Integration Statement, So possibly use "product" in both places).
Not clear why section 9.3.1 needs to be removed. 		When a product claims conformance to Secure Note -> Secure Node
22
1260ITI-18 – clarify that datetime parameter values can have single quotesYesYesyesYesYesYesYesYesYes
23
24
1269XDS: Clarify DocumentEntry.uniqueId encoding for URIsYesYesyesYesYesYesYesYesAbstain
25
26
1273Move guidance on service dates for On demandYesYesyesYesYesYesYesYesAbstain
27
28
1282XDS-MU - Fix Section ReferenceAbstainYesyesAbstainAbstainYesAbstainYesAbstain
29
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