ITI CP Ballot 34 Consolidated Comments
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
$
%
123
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ABCDEFGHIJKLMNOPQRSTUVWXYZAAABACADAEAFAGAHAIAJAK
1
Please complete this spreadsheet by Wed July 6, 2016.
To submit your entry, scroll right and add your votes/comments in the next available columns...
Ballot 34 contents:
2
ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance-2016/CPs/Ballots/ballot_34/
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
Comments
5
5/1/0767-02Fix errors in CXi datatype and referenceIdList attribute examplesXD*Vol 3ICWTarik IdrisNo (no vote was withdrawn after CP update based on comments)In the ":uniqueId" section, remove ", and homeCommunityID is '1.2.3.4'" - currently it is removed in the example but not in the text above it, which may confuse readers.ASIP Santé
Nader Cheaib
YesIntraHealth
Carl Leitner
non-voting member
Ready Computing
Karen Witting
YesAllscriptsGeorge ColeYesMcKessonElliot SilverYesDidn't we agree to discourage homeCommunityId? If we are keeping it, the uniqueId example should include it. If we are not keeping it, the uniqueId example should not include it, or list that "homeCommunityId is '1.2.3.4'"; and, we should change the CXi.6 bullet point to indicate that it is discouraged.

RESOLUTION: Text updated to remove bullet referring to homeCommunityId, Also updated rationale with reason for this change.
N. Harris Computer Corporation (formerly QuadraMed)Elliott LavyYesThe new wording in CXi.4 isn't clear. Better would be something like, "If present, subcomponent 1 and/or both subcomponents 2 and 3 shall be present."

RESOLUTION: wording updated; will confirm w/ Elliott via email or at F2F
AgfaRob Horn(see below)
6
6/0/0821-03Add specification for ITI-32 audit messageXDMVol 2bICWTarik IdrisYesMinor quibble (only consider this if we need to switch back to assigned for other reasons): I would recommend rephrasing the 3.32.5.1 section to clearly map the event (PHI-Export) to the actor (PMCreator)
RESOLUTION: Fixed
ASIP Santé
Nader Cheaib
YesIntraHealth
Carl Leitner
non-voting
Ready Computing
Karen Witting
YesAllscriptsGeorge ColeYesMcKessonElliot SilverYesWhat happens to existing implementations with different auditing? Are they no longer valid?

RESPONSE: When we add clarification that was missing (eg ITI-32 must be audited but we weren't clear on the specifics), it may result in a software change to an implementation that was done w/o IHE guidance because . We aren't making interoperability any worse by adding these specifics
N. Harris Computer Corporation (formerly QuadraMed)Elliott LavyYes
7
6/0/0846-09Clarify Base64 Required/XOPXDS2x, 2bICWTarik IdrisYesASIP Santé
Nader Cheaib
YesIntraHealth
Carl Leitner
non-voting
Ready Computing
Karen Witting
YesAllscriptsGeorge ColeYesMcKessonElliot SilverYesV.8.3 "In order to optimize a specific piece of binary data:...Place the optimized content…Replace the optimized content": This is confusing because it doesn't distinguish between the optimized content in the Infoset with the optimized content in the new MIME part, and it isn't clear what is being replaced (the base-64 encoded binary content?).

RESPONSE: Discuss @ F2F when Elliot & Bill are present
N. Harris Computer Corporation (formerly QuadraMed)Elliott LavyYes
8
4/0/2873-08ATNA Vol 1 RedocATNAVol 1ICWTarik IdrisAbstainASIP Santé
Nader Cheaib
YesIntraHealth
Carl Leitner
non-voting
Ready Computing
Karen Witting
AbstainAllscriptsGeorge ColeYesMcKessonElliot SilverYesThis is a loooong comment -- keep reading until the end.
* CP contains tracked changes.
* It isn't clear whether the editor's box below the start of section 9 is meant to be incorporated into final text.
* Fig. 9.1-1 "grouped with Any IHE Actor": Can you claim compliance with Secure Node/Secure Application and not be grouped with another IHE actor? Consider if I want to make a statement about my security, but the remainder of my functionality isn't governed by a defined profile/actor. (This applies throughout, e.g., sections 9.1.1.1, 9.1.1.2.)
* 9.1.1: I think I understand what this paragraph is requiring, but am not totally sure. Is the following correct, and clearer? "When an implementation claims support of the SN, SA, or ARR actors, and support of any other IHE-defined actor, the ATNA actor requirements-- ... --apply to the implementation of the each of the non-ATNA actors. For example, an implementation that claims, SN, PIX Manager and PDQ Supplier, must support node authentication on each of the SN, PIX Manager, and PDQ Supplier network interfaces; conversely, if that implementation does not support node authentication on the PIX Manager interface, or does not record PDQ Supplier-related audit events, it does not meet the SN requirements. When an implementation that claims support of the SN, SA, or ARR actors, has functionality or capabilites that are not specified by any claimed IHE actor, the ATNA actor requirements may apply to that functionality." (Also, both the en-dash and the double hyphen in this paragraph should be em-dashes.)
* 9.1.1.1 l.84 "This permits... This includes...": the subject of the second sentence is unclear; I think it is supposed to reference "the entire relevant hardware and software stack."
* 9.1.1.1 l. 91: Does this mean that an US machine needs a user login? I've never seen that.
* 9.1.1.2 l. 106: Why is the language in item 1 here different than item 1 in section 9.1.1.1 (other than the obvious "to or from the grouped actors")?
* 9.1.1.2 l. 108: Does authorization need to be level-based? Suggest: "Provide protected authentication and authorizaton methods for the grouped actors to ensure that application functionalities are only accessible by appropriately authorized users."
* 9.1.1.3 l. 116: "analysis, *query,*and reporting capabilities" * 9.2.2 l. 136 "The Radiology Audit Trail Option provides...": I'm having trouble reading the latter part of this sentence-- is it missing something? am I parsing "profile" as a noun instead of a verb? "based on the *specific* Radiology actor" * 9.4 l. 159 "enables communications participants to:...": the bullets do not match with the introductory phrase. Consider "participants to: *confirm that a server is indeed the server expected by the client system; *confirm that a client is indeed a client expected by the server system" * 9.4.2.1 l. 304ff. "the node": This term in ambiguous in the list, particularly for the "the node generates audit records" items. The diagram shows 3 "nodes". * Fig 9.4-1: The "record audit event (retrieve images)" and "record audit event (instances used)" lines have odd T-breaks in them; they should go directly to the ARR. The query and retrieve transactions should be audited on both the ID and the IM/IA sides. Confirm if node authentication should be audited, and if so add to diagram and to previous list. Congratulations, this is the end.
N. Harris Computer Corporation (formerly QuadraMed)Elliott LavyYes* Actor name is wrong in the diagram
* #3 in sections 9.1.1.1 and 9.1.1.2 are not clear
* In 9.4, "Node authentication", remove "clients can" and "servers can"
* 9.4, "event audit logging" says that standard events "should" be reported. Should this be "shall"? (changed to "to be reported" in this overview section
* 9.4, "encryption" talks about the negotiation of no encryption, but ITI TF-2a: 3.19.6.2 says, "When configured for use on a physically secured network, the normal connection mechanisms may be used." To me, this implies that TLS is not required at all in this situation.
9
6/0/0882-02Fix merge references from PIX Feed(s) to XDSXDS2a, 2bICWTarik IdrisYesWhy is 3.42.4.1.3.5 referenced?ASIP Santé
Nader Cheaib
YesIntraHealth
Carl Leitner
non-voting
Ready Computing
Karen Witting
Yes, with reservationsI am unclear as to why there is a reference to 3.42.4.1.3 from either section 3.8.4.2.4 or 3.44.4.2.4. The text states that the 3.42 sections describe "how it affects the Register Document Set-b [ITI-42] transaction", but in reading those sections I was not enlightened regarding how a merge affects that transaction. My conclusion is that a merge does not affect ITI-42, but if this is true the text in the CP is misleading.
Also, Section 3.18.4.1.2.3.9 has references to TF-3: 4.3.1.2.4 and ITI TF-3: 4.3.1.2.5 that should be fixed to point to 3.42 (?).
AllscriptsGeorge ColeYesMcKessonElliot SilverYes3.44.4.2.4 "processing of future Stored Query" should read "processing of future RegistryStored Query" Should the CP include references to the Register On-Demand Document transaction, or are they included indirectly because ITI-61 is based on ITI-42?N. Harris Computer Corporation (formerly QuadraMed)Elliott LavyYes
10
6/0/0894-03Object List Description ImprovementXD*Vol 3ICWTarik IdrisYesASIP Santé
Nader Cheaib
YesIntraHealth
Carl Leitner
non-voting
Ready Computing
Karen Witting
YesAllscriptsGeorge ColeYesMcKessonElliot SilverYesN. Harris Computer Corporation (formerly QuadraMed)Elliott LavyYes
11
6/0/0909-03Restrict ITI 41 and 42 from carrying on-demand
XDS-ODD
1, 2b, 3ICWTarik IdrisYesASIP Santé
Nader Cheaib
YesIntraHealth
Carl Leitner
non-voting
Ready Computing
Karen Witting
YesAllscriptsGeorge ColeYesMcKessonElliot SilverYesN. Harris Computer Corporation (formerly QuadraMed)Elliott LavyYes10.1.2.2: Prior to the first insertion, replace "an" with "a".
General: Be consistent on capitalization of "on-demand" and "DocumentEntry" vs. "Document Entry"

RESOLUTION: Fixed
12
4/0/2914-04Value of Content-Type HTTP header action parameterXD*severalICWTarik IdrisYesASIP Santé
Nader Cheaib
YesIntraHealth
Carl Leitner
non-voting
Ready Computing
Karen Witting
AbstainAllscriptsGeorge ColeYesMcKessonElliot SilverAbstainN. Harris Computer Corporation (formerly QuadraMed)Elliott LavyYes
13
5/1/0924-01Fix TF Reference in XCDR supplement
editorial
XCDR-TIICWTarik IdrisYesThe urn "urn:ihe.net:iti:xdr:2014" doesn't follow the naming convention, but this doesn't really concern this CPASIP Santé
Nader Cheaib
YesIntraHealth
Carl Leitner
non-voting
Ready Computing
Karen Witting
YesTypos!!! Who wrote this? Have sent typo fixes to Lynn.AllscriptsGeorge ColeYesMcKessonElliot SilverYesN. Harris Computer Corporation (formerly QuadraMed)Elliott LavyNoIn the example, wsa:Action has the wrong value and Slots are not coded properly. (In general, this is not anywhere close to being a valid ITI-41.) Instead of using "ihe" as a namespace prefix, use a better mnemonic, i.e. "xcdr".

In general, I found the new section 3.41.4.1.2.2 to be unclear. (Also the numbering in the numbered list needs to be fixed.)

14
2/0/3926-06CSD - Update rqmts for transport plus additional implementer feedbackCSDCSD-TIICWTarik IdrisAbstainASIP Santé
Nader Cheaib
YesIntraHealth
Carl Leitner
non-voting
There is text "The function shall be executed against the root node of the CSD document managed by the Care Services InfoManager. Any parameters passed to the function are accessible in the dynamic context of the function under the variable $careServicesRequest." in the .xsd in the Appendix. It should also appear in 3.73.4.1.3 Expected Actions
Ready Computing
Karen Witting
AbstainAllscriptsGeorge ColeAbstainMcKessonElliot Silver* Rationale "xforms:submissios": submissions?
* 35.1.1.1 through 35.1.1.4: The new text is imprecise. For example, in 35.1.1.1, the actor doesn't respond using "at least one of", it responds using "exactly one of"; however which one it uses depends on which protocols the actor supports, there is no mention of accepting the request in one of those protocols, and nothing tying the requesting and responding protocols together. The following paragraph are suggested replacements. (Also, 35.1.1.3 contains the incorrect "SOAP POST and HTTP transport.") -- 35.1.1.1: "A Services Directory shall support at least one of the HTTP POST or SOAP protocols as defined Section ITI TF-2c: 3.74.4.2, for receiving Query for Updated Services [ITI-74] requests, and shall respond to each request using the received protocol." -- 35.1.1.2: "A Services Finder shall support at least one of the HTTP POST or SOAP protocols as defined Section TF-2c: 3.73.4.1.4, for issuing Find Matching Services [ITI-73] requests." -- 35.1.1.3: "A Care Services InfoManager shall support both of the HTTP POST or SOAP protocols as defined Section ITI TF-2c: 3.73.4.1.4, for receiving Find Matching Services [ITI-73] requests, and shall respond to each request using the received protocol.¶A Care Services InfoManager shall support both of the HTTP POST or SOAP protocols as defined Section TF-2c: 3.73.4.1.4, for issuing Query for Updated Services [ITI-74] requests. The protocol for a particular request could be selected, for example, by configuration."
* 3.73.3: The editor's box preceeding this unnumbered section should include text indicating that the section includes bolded text which is not markup. The 5th bullet in this section ("the data model...") contains ", submission," which, I think, should be bolded. * 3.73.4.1.1.1: Are the details in this section for the information of implementors or for the IHE to remember when adding capabilities? Specifically, does the implementor care how to construct the URNs, or do they just use the URNs we tell them to use? "Sections 3.73.4.1.2.1 – 3.73.4.1.2.4" is difficult to read; suggest replacing with "Section 3.73.4.1.2.1 through Section 3.73.4.1.2.4." In the last bullet of the section ("by the jurisdiction...initiating a the Find...") remove either "a" or "the" before "Find", and confirm transaction name/numbers are correct. (Is Find Matching Services ITI-73 or 74?) * 3.73 general: I see the csd: namespace prefix used throughout, as if use of this prefix is required. Is "csd" just a regular alias for an xml schema definition? If so, we should make it clear that "csd" is an example used throughout to refer to the schema defined at http://some.schema/location.xsd". Or better, use the approach used in XDS redoc in combination with appendix V. * 3.73.4.1.2 "ITI TF-2x: Appendix Y, Figure Y.3-1 – Y.3-4.": the dash is confusing mixed in with all the hyphens; suggest replacing with "Figure Y.3-1 through Figure Y.3-4." 3.73.4.1.2 "The Service Finder shall convey...": Why is HTTP POST in a differnt font here, but nowhere else? Why aren't other acronyms or initialisms in that font? 3.73.4.1.2.1 I notice that the next text, as well as existing text say "result set should be restricted." Should those be "shalls"? 3.73.4.1.2.3, etc.: Why is "any-number" hyphenated throughout? Consider removing throughout CP and supplement. Also "if there is at least one present, and it...": Two issues: (1) does each item in the result set have to match all of the organizations in the organizations list, or any of them? (2) "it" doesn't work if there are more than one present; reword. If same language us used in supplement, reword supplement too. 3.73.4.1.4: when inserting an entire section, do not bold/underline it. The editor instructions are sufficient. However, you should indicate where it should be inserted (following section 3.73.4.1.3, immediately before section 3.73.x.x.x) 3.73.4.1.4.1: Are the spaces in the xforms elements "bind[ starts-with(@nodeset ,"instance..." significant? * "generate a unique UUID": Is "unique" redundant? * "The jurisdiction shall determine...may be used": is this a shall or a may? suggest changing to "...protocols are used." * "Implementors using the SOAP protocol shall comply...": "implementors" or "implementations"? This whole section is describing SOAP, so including it in the statement is redundant. Suggest changing to "Implementations shall comply..." Two references to Appendix V in one paragraph is excessive. "The following requirements apply to this transaction.": should end with a colon. * "For informative WSDL...": add missing "an". * "A full XML Schema Document for the CSD types is available online on the IHE FTP site...": Informative? 3.73.4.1.4.2 and 3.73.4.1.4.3 "The jurisdiction shall determine...may be used": is this a shall or a may? suggest changing to "...protocols are used." * "The requesting actor shall": add colon at end of fragment.
N. Harris Computer Corporation (formerly QuadraMed)Elliott LavyAbstain
15
4/0/2932-01SeR - fix URN encodingSeRSeR-TIICWTarik IdrisYesASIP Santé
Nader Cheaib
YesIntraHealth
Carl Leitner
non-voting
Ready Computing
Karen Witting
AbstainAllscriptsGeorge ColeAbstainMcKessonElliot SilverYesN. Harris Computer Corporation (formerly QuadraMed)Elliott LavyYes
16
5/0/1933-00XPID-Fix Expected Actions for sourcePatientIdXPIDXPID-TIICWTarik IdrisYesASIP Santé
Nader Cheaib
YesIntraHealth
Carl Leitner
non-voting
Ready Computing
Karen Witting
YesAllscriptsGeorge ColeAbstainMcKessonElliot SilverYesN. Harris Computer Corporation (formerly QuadraMed)Elliott LavyYes
17
5/0/1934-00ITI-61 Human Requestor AuditXDSVol 2bICWTarik IdrisYesASIP Santé
Nader Cheaib
YesIntraHealth
Carl Leitner
non-voting
Ready Computing
Karen Witting
AbstainAllscriptsGeorge ColeYesMcKessonElliot SilverYesN. Harris Computer Corporation (formerly QuadraMed)Elliott LavyYesAgfaRob HornYes In ODD Source audit msg, update cardinality for Human Requestor to be 0..1 (not 0..n)

RESOLUTION: DOne
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
Loading...
Main menu