ABCDEFGHIJKLMNOPQRS
1
Please complete this spreadsheet by Sep 11, 2017.
To submit your entry, scroll right and add your votes/comments in the next available column...		Ballot 44 contents:
2
ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance/CPs/Ballots/2018/Ballot_44/
3
4
Organization-->N. Harris Computer CorporationKen MeyerInterComponentWare AG (ICW)Arsenal.ITChange HealthcareAmerican Association of OrthodontistsPhysician Technology Services, Inc.IntraHealth International, Inc.Ready Computing Inc.ASIP Santé
5
Y/N/ACP-ITI-Descr.ProfileDoc updatedYour name-->Elliott LavyIBM Watson HealthTarik IdrisGregorio CanalElliot SilverKirt Simmons DDS, PhDMichael McCoy, MDLuke DuncanKaren WittingNader CHEAIB
6
5/0/5795-05
Fix ITI-44 text to match the schema
PIXv3, XDSVol 2b
Yes/Abstain/No
AbstainYesAbstainYesAbstainYesYesAbstainAbstainYes
7
Comments:
(Req'd if No)
8
8/1/1917-01
Clarify use of Coding Scheme in metadata
XD*Vol 3YesYesNo (changed to Yes)YesYesYesYesAbstainYesYes
9
Make the URL for the hyperlink be visible text. The visible URL can be a hyperlink.
RESOLUTION: Done		While this is a great improvement, it still does not express a preference when it comes to common coding schemes. I would suggest language like: 'If the Code Value is from a Coding Scheme in this table, the value for Coding Scheme should be taken from the “Coding Scheme UID” column. Alternatively, the value from the “Coding Scheme Designator” may be used.'
RESOLUTION: Updated; No vote withdrawn		But maybe there is more text, after the example, that needs to be changed.
Line 1054 says Name of the coding schememaybe needs to be changed inIdentifier of the coding scheme
RESOLUTION: Fixed to be consistent		Suggest changing hyperlink to http://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_8.html to avoid loading a huge web page.
RESOLUTION: Fixed
10
9/0/1976-01
Fix Folder.codeList example
XD*Vol 3YesYesYesyesYesYesYesAbstainYesYes
11
 adjust to: specifies code="Examplecode", display name="codeDisplayName" and coding scheme="Example codeList coding scheme", for the Folder with id="ExampleFolder".
RESOLUTION: withdrawn		Technically correct, but can we come up with a better example? Use CP-ITI-917? Suggested wording...
The following example describes a Folder labeled "ExampleFolder" by specifying a code, "Examplecode", from the coding scheme, "Example codeList coding scheme". The code's display name is "codeDisplayName".
RESOLUTION: Updated
12
6/2/2977-01
XTN datatype clarification for phone number
XD*Vol 3YesNoNo ( Changed to Yes after resolutions below)Yes (was no)AbstainYesYesAbstainYesYes
13
Pending Rob's recommendation
Instead of making XTN.7 and XTN.12 optional, make them "conditionally required". The following paragraph can then say, "Either XTN.7 or XTN.12 shall be provided.
RESOLUTION: YES. Updated		See other columns1. Table 201 in HL7 2.5.1 does not contain a code PRS. It does contain a code PRN for "Private Home Number" AGREE: FIXED

2. We first say that XTN.12 is unstructured, but then say that it should use the ITU E.123 notation (which is "structured"). Note that HL7 2.5 never says that XTN.12 is unstructured. It is called "unformated". I would prefer to tell implementors to use XTN.12 for all formats that are not following the Hl7 2.5 XTN rules. AGREE: FIXED

3. The new text is a bit confusing. The list entries should not just say that XTN.7 and XTN.12 are optional, they should either say "(see below)" or explain it inline e.g., "XTN.7 Subscriber Number (Required, unless XTN.12 is used)" and "XTN.12 ... (Required, unless XTN.7 is used)."
Then follow this up with an explicit statement "Either XTN.7 or XTN.12 shall be included, but not both. XTN.7 shall be used for telephone numbers in the structured format defined by HL7 2.5 XTN, except that leading zeros “0” are permitted for all types of numbers. XTN.12 shall be used for all other formats. Use of ITU E.123 notation for telephone numbers is recommended in XTN.12."
RESOLUTION: Agree.. suggested text is used in the CP		for telephone: HL7 define XTN.12 as Conditional and not as Optional. But because we are requiring XTN.7 or XTN.12 we could state that as condition and set both as C.
for email:
right now we shall use XTN.3 as "Internet" and the use of XTN.2 as "NET" is optional. But HL7 for XTN.3 says for the value "Internet" Use Only If Telecommunication Use Code Is NET. Maybe we should set XTN.2 as Required and change the example.
RESOLUTION: Fixed		"This is a breaking change since previously XTN.12 was prohibited. I'm not convinced that the demand for this change is worth the break. Wouldn't it be easier to relax the validation? Or require that ""international"" phone number be correctly coded in XTN.5, .6, and .7 and remove the recommendation for E.123 notaton? R

RESOLUTION: Comment withdrawn

Please add ""telephone"" before ""numbers"" in ""leading zeros “0” are permitted for all types of numbers.""

RESOLUTION: DONE

The original email example contained two "".org"" domains. The CP changes that to none. Can we compromise on one?"

RESOLUTION: Comment withdrawn
14
8/0/2985-11
Relationship Association Target in SubmissionSet
XD*Vol 2b, 3YesYesYesAbstainYesYesYesAbstainYesYes
15
Wording doesn't quite match between 3.41 and 3.42. Suggest rewording both a bit: If the associationType of a Relationship Association in the Submission Request is RPLC, XFRM_RPLC, or IsSnapshotOf, the targetObject shall be a DocumentEntry already in the Document Registry.
RESOLUTION:Agree. Updated		This note needs to be moved up or removed: "Note: For "RPLC" and "XFRM_RPLC" relationships, earlier versions of the Technical Framework referenced the error XDSReplaceFailed for most of the above conditions. That error has been deprecated."
RESOLUTION: Note moved and reworded.
16
9/0/1994-01
Increase XDS.b DocumentEntry.uniqueId maximum length
XD*Vol 3YesYesYesyesYesYesYesAbstainYesYes
17
Change title, because this no longer has anything to do with length. Make the two dot points sentences, each beginning "The uniqueId for"
RESOLUTION: Updated as suggested		The structure and format of uniqueId shall be consistent with the specification corresponding to the formatCode attributefor the submitted document.
RESOLUTION: Updated as suggested
18
9/0/1995-02
Align entryUUID descriptions
XD*Vol 3YesYesYesyesYesYesYesAbstainYEsYes
19
20
8/0/21026-05ITI-18 cleanupXDSVol 1, 2aYesYesYesabstainYesYesYesAbstainYEsYes
21
In the ballot review meeting, please discuss whether responses were received on the Word comment in 3.18.4.1.2.3.9.
RESOLUTION: Yes; Tarik confirmed		s/b bulleted
Query for DocumentEntry objects by patient (Id) for a time interval on creation time and/or service time, by document type(s), by practice setting(s), by author person
Query for SubmissionSets by Document Source
Query for XDS Folders updated during a time interval
Query for all documents contents in a Folder or SubmissionSet Submission Set
Query for SubmissionSets by time of submission
Also...s/b objects and blend in entryUuids
• Object references, entryUuids, for one or more types of registry objects
RESOLUTION: bullets added; sentence updated		1. [style] In section 3.18.4.1.2.3: remove "the" from "Query ID - a UUID from the Section 3.18.4.1.2.4"
2. The reference to section 3.42.4.1.3.3 seems sufficient. The previous references were more expansive, but it was never clear why they were included and how they would be helpful. This new reference helps readers understand the impact of merges onto ITI-42, nothing more, nothing less.
RESOLUTION: updated as suggesed		"Corrected diagram for 3.18.4 is not included. This should be called out in editor instructions.
REOLUTION: Agree. Diagram is updated to show the change with markup

In 3.18.4.1.2.3.5, is a space pemitted following the comma for multiple values? Is it prohibited? Suggest allowing whitespace after the comma to preserve existing implementations that may expect it.
RESOLUTION: Comment rejected. Keep change as is (no whitespace). If there is a desire to address the question of significant whitespace, write a new CP.

3.1.8.4.1.2.3.9: The first sentence of this section needs work. I would suggest rephrasing as ""The results of this transaction shall reflect patient IDs changes known to the recipient, such as through ..."" (That's still not great, but...)
RESOLUTION: Comment rejected; this change is out of scope for this 'cleanup' CP. During ballot resolution, the group acknowledged that there was room for improvement in the specification for merge.

No, the reference to 3.42.4.1.2.3.3 is not sufficient. That only talks about having the same Id all across objects in a submission, it doesn't cover feed updates or queries. There is existing vol. 1 text we could reference, but it isn't normative. We should go back to see what was in old vol. 3, and include that text here -- this is the section where we should give the requirements for what merge does in XDS.
RESOLUTION: Elliott is willing to include additional references if you can identify them.

Regardless of outcome, remove Elliott's comment."
RESOLUTION: Agree. Done. Several updates done based on Elliot's comments, including a small update to Vol 1
22
8/0/21057-00
Fix coded values in XDS author role and specialty
XD*Vol 3YesYesYesyesNo (withdrawn; now marked as Abstain)YesYesAbstainYes
23
Remove strikeout on capital "R".
RESOLUTION: 		I object to the requirement that the code scheme must be an OID. I don't see the justification for disallowing non-OID-identified coding schemes.

Is it intentional that display name is not included?

What are we supposed to say to people who have represented code and scheme some other way? code^scheme, (code, scheme), etc. I guess we could say, yup, that's just a "string", and you can go on using your string-as-code representation if you want. In that case, since string can hold any representation of codes, and coded string can only hold one specific representation of codes, what is the value of the coded string type? Why not just use string?

If an implementation/deployments followed the old rules, and encoded as CX, but didn't use an OID, how can new systems find that content if they are only expecting OID-containg coded strings.
RESOLUTION: After discussion, Elliot withdrew this comment. During the review, Joe Lamy noticed a correction needed on the encoding of the & in the example, and that has been fixed.
24
9/0/11058-02
ATNA Audit Message Optionality Definitions
ATNAVol 2aYesYesYesyesYesYesYesYesAbstainYes
25
For "U", start the sentence, "The optionality of this field…"Please remove the last sentence from the rationale. The propsed change no longer matches DICOM.
26
8/0/21061-01
ITI-18: Correct Queries for "AvailabilityStatus" Attribute
XDSVol 2aYesYesYesyesYesYesYesAbstainAbstainYes
27
XDS-MU-TI
MU FindDocuments: Don't change the footnote in this CP. (I also think the change is incorrect.)

MU FindFolders and others: Since the original text includes markup, all additions/deletions for this CP need to use colors.

RESOLUTION: discussion of color to make editor actions clearer for markup on exising marked up text		Please note that GetAll and FindFolders in TF-2a Final Text separate multiple footnotes using comma, while MU uses "and" (GetDocuments, GetFolders, GetDocumentsAndAssociations, GetFolderAndContents; and with this CP also FindDocuments).

RESOLUTION: suggestion to be taken into account in post-ballot update
28
8/0/21065-00
Fix CXi example for Referral
editorialVOl 3YesYesYesyesYesYesYesAbstainAbstainYes
29
if we need to use the correct OID for examples why don't we start changing at least all the examples in this table. And keep making this change in every future CP that needs it?
RESOLUTION: No change will be made at this time. We acknowledge that there is inconsistency in the examples, but we had earlier decided update them as we find them in future CPs rather than to expand the changes to this one.
30
7/0/31066-00
XUA definitions of urn from XSPA
XUA Vol 2bYesAbstainYesyesYesYesYesAbstainAbstainYes
31
32
7/0/31067-00
Small fix to ITI-54 audit message
DSUBVol 2bYesYesAbstainyesYesYesYesAbstainAbstainYes
33
34
7/0/31068-00
Small fix to ITI-86 audit message
RMDRMD-TIYesYesAbstainyesYesYesYesAbstainAbstainYes
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