ABCDEFGHIJKLMNOPQRSTUVWXYZAAABACADAEAFAGAHAIAJAKALAMANAOAPAQARASATAUAVAWAXAYAZBABB
1
Please complete this spreadsheet by Fri July 15, 2016.
To submit your entry, scroll right and add your votes/comments in the next available columns...
Ballot contents:
2
ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance-2016/CPs/Ballots/ballot_35/
3
4
y/n/aCP-ITI-Descr.ProfileDoc updatedCompanyYour nameYes/No/
Abstain
CommentsCompanyYour nameYes/No/
Abstain
CommentsCompanyYour nameYes/No/
Abstain
CommentsCompanyYour nameYes/No/
Abstain
CommentsCompanyYour nameYes/No/
Abstain
CommentsCompanyYour nameYes/No/
Abstain
CommentsCompanyYour nameYes/No/
Abstain
CommentsCompanyYour nameYes/No/
Abstain
CommentsCompanyYour nameYes/No/
Abstain
CommentsCompanyYour nameYes/No/
Abstain
CommentsCompanyYour nameYes/No/
Abstain
CommentsCompanyYour nameYes/No/
Abstain
Comments
5
5/0/0927-03
Mark additional attributes with Security & Privacy purpose
XD*Vol 3
Ready Computing
Karen WittingYes A couple of my comments on 935 might also apply here.
McKessonElliot SilveryesI'm not sure about characterizing all of these elements as security-related. Why is DocumentEntry.availabitlityStatus security related, but not SubmissionSet.availabilityStatus? Why are mimeType/formatCode not included? I think any field could conceivably be security related. Perhaps the table should only flag the elements that are most security related.ASIP SantéNader CheaibYes
Philips Healthcare
Chris MeloYes AllscriptsGeorge ColeYes
6
4/1/0935-02
Improve the document sharing metadata descriptions in tables
XD*Vol 3
Ready Computing
Karen WittingNo (changed to yes after text updates)I can't find any change in 4.2.3.2.22, why does the editorial block say there is a change?
For entryUUID, the descrption is changed for SubmissionSet but not for Document, why?
For SubmissionSet.patientId - why was the word "primary" added?  I disagree with this addition, it implies there might be more than one subject of care in a Submission Set and this is a misleading suggestion.  Same comment for Folder.
McKessonElliot SilveryesSection 4.2.3.2.22 DocumentEntry.sourcePatientId has no markup. Is there an intended change?

Section 4.2.3.4.8 Folder.title: the text says that 'the title is "title"', but the code says 'value="this is the title of the Folder"', so they don't match.
ASIP SantéNader CheaibYes
Philips Healthcare
Chris MeloYes AllscriptsGeorge ColeYes
7
2/1/1936-01
Add new optional parameter to ITI-34 Retrieve Form Request
RFDVol 2b
Ready Computing
Karen WittingNo (changed to yes after text updates)-Why do you have @ in front of the parameter name?  Maybe because it is an attribute and not a parameter?  The @ is very confusing, especially in the text just above the example - the example does not include @ in the name.
-The new "parameter" should be indented below encodedResponse in the same way that workflowData has its elements indented below it.  For clarity, we could write the description as : An attribute of encodedResponse which specifies the type of expected encoded reponse.  The phrase "Shall not be sent" should be instead "Shall not be specified"
- The Value column should suggest a type for the attribute.  I believe the type is string, true?  Below there is a suggestion that more than one can be specified, if this is true the Value column should indicate that multiple are allowed and should specifiy how you would indicate more than one.  Also need to say something in expected actions that the responder can choose the encoding that it prefers?
- Context has been changed to an upper case C and this should be fixed in this CP.
- The text above the example needs sigificant work, here is my suggestion:
The responseContentType attribute may be specified only when the value of the encodedResponse parameter is “true”.  The value(s)(???) for responseContentType specifies the encoding of the response from the Form Manager or Form Processor.   Acceptable values are defined by content
profiles.  An example of its use is to specify whether the expected response is an XML form definition or an XHTML form.  Below is an example if its use.

McKessonElliot SilverAbstainThis CP adds mandatory behavior on the recepient based on the presence of the optional parameter. This is a non-compatible breaking change. CP rationale appears to indicate that the authors have attempted to confirm recipients will behave correctly in the presence of the parameter. Is the committe confident that no implementations will be adversely affected?ASIP SantéNader CheaibYesTypo in : "Accpetablevalues are defined by content profiles", in the paragraph added before the section 3.34.4.1.3
Philips Healthcare
Chris MeloAbstainAllscriptsGeorge ColeYes not really enthusiastic, but that Robert Barr and OZ have no issues then I have no issues.
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
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