| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | AB | AC | AD | AE | AF | AG | AH | AI | AJ | AK | AL | AM | AN | AO | AP | AQ | AR | AS | AT | AU | AV | AW | AX | AY | AZ | BA | BB | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Please complete this spreadsheet by Oct 31, 2016. To submit your entry, scroll right and add your votes/comments in the next available columns... | Ballot contents: | |||||||||||||||||||||||||||||||||||||||||||||||||||||
2 | http://wiki.ihe.net/index.php/ITI_Change_Proposals_2017#Ballot_37 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
3 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
4 | Votes Y/N/A | CP-ITI- | Descr. | Profile | Doc updated | Company | Your name | Yes/No/ Abstain | Comments | Company | Your name | Yes/No/ Abstain | Comments | Company | Your name | Yes/No/ Abstain | Comments | Company | Your name | Yes/No/ Abstain | Comments | Company | Your name | Yes/No/ Abstain | Comments | Company | Your name | Yes/No/ Abstain | Comments | Company | Your name | Yes/No/ Abstain | Comments | Company | Your name | Yes/No/ Abstain | Comments | Company | Your name | Yes/No/ Abstain | Comments | Company | Your name | Yes/No/ Abstain | Comments | Company | Your name | Yes/No/ Abstain | Comments | Company | Your name | Yes/No/ Abstain | Comments | ||
5 | 6/2/1 | 559-04 | MPQ profile queries vs Metadata Update option | XDS | XDS-MU TI | McKesson | Elliot Silver | No (withdrawn) | Consider the following equivalent alternate text which I think makes the connection between the use case and support for the parameter clearer (along with some other tweaks): The $MetadataLevel parameter (see ITI TF-2a: 3.18.4.1.2.3.5.1.1) is not included in any of the queries in this transaction. Only current information is of interest in the public health use cases which this transaction supports, and thus, the parameter is not necessary. Requiring support could impose security risks and have a negative performance impact. However, I'd challenge the notion that these queries are only for public health. Isn't one use of the queries to do departmental queries (especially when used with workflow)? If so, and there are non-public health uses, do any of them have a use for historical data? Synchronization of content use cases? Finding changed metadata, when there is a new version is relatively simple; what about finding document metadata which has been deprecated without replacement? If there are MPQ use cases which need historical information, then this CP should be failed. Otherwise, if there are non-public health use cases for MPQ, then this CP should be modified to not focus on public health use cases. Otherwise, if MPQ is only for public health, and only for current information, then consider the suggested text change. RESOLUTION: CP was updated based on these comments. Elliot confirmed & withdrew no vote | Allscripts | George Cole | Yes | ASIP Santé | Nader Cheaib | Yes | The text added to section 3.18.4.1.2.3.5.1.1 should maybe say that there is no specific use case where the metadata update option is used instead of saying that the use case is public health (wouldn't it too generic to refer to public health as a use case?). RESOLUTION: CP updated based on this comment | Harris/QuadraMed | Elliott Lavy | Yes | Remove "bold" from the editor box. DONE | Ready Computing | Karen Witting | No (withdrawn) | 1) the change should go before 3.57 rather than 3.62. 2) the text should be formatted as a real Note and should go after all other text in the section 3) the wording of the sentence should be improved: Note: The $MetadataLevel parameter (see ITI TF-2a: 3.18.4.1.2.3.5.1.1) is not included in any of the queries below because these queries support public health use cases which do not require this parameter. In addition, adding support for this parameter would impose security risks and have a negative performance impact. I have provided the author with a version of the CP with my proposed changes applied. RESOLUTION: CP updated based on this comment; No vote withdrawn. | Merge | Ken Meyer | Yes | Arsenàl.IT | Mauro Zanardini | Yes | TSHA | Eric Heflin | Abstain | Philips Healthcare | Chris Melo | Yes | Forcare | Walco van Loon | Yes | ICW | Tarik Idris | Yes | Although I would generally be OK with the CP, I agree with Karen that the wording should be improved. I don't feel that saying "public health doesn't need it" is sufficient. I would more actively state that nobody had a use case for it and therefore it wasn't just included for completeness sake. RESOULUTION: CP updated based on this comment | IntraHealth | Luke Duncan | Abstain | |||||||||
6 | 8/2/2 | 765-07 | Metadata Update Queries with MU level not set/set to 1 | XDS | XDS-MU TI | McKesson | Elliot Silver | No | I think all the Word tracked changes should all be approved before this CP is approved. 3.18.4.1.2.3.5.1.1: For the bullet list that follows the paragraph "If $MetadataLevel is 1 (one)...", what is returned if the latest Folder is deprecated, since this is not a possible condition in the absence of MU, but is with MU. 3.18.4.1.2.3.7.5, and 3.18.4.1.2.3.7.6, Note 3: there is already a note 3 on this table in the current TF. Are we replacing it, or should this be renumbered? 3.18.4.1.2.3.7.5 Note 4: The TF contains a non-numbered note between numbered notes 2 and 3, discussing multiple results when querying by uniqueId. I suggest we remove that note and expand note 4 to cover the non-MU case as well. Add the unnumbered TF note to the CP, marked up to remove it; and modify the inserted note 4 text as follows: "Specifying this parameter in a query to a Document Registry that supports the Document Metadata Update option A query which specifies this parameter, may result in a response returning multiple DocumentEntry objects, if the same document has been registered multiple times. Additionally, if the Document Registry supports the Document Metadata Update option, the responsemay return multiple DocumentEntry objects each representing a different version of the metadata. See ITI TF-3: 4.1.4 for guidance on interpreting these results.' | Allscripts | George Cole | Yes | ASIP Santé | Nader Cheaib | Yes | Harris/QuadraMed | Elliott Lavy | Yes | Section 3.18.4.1.2.3.7.5, footnote 3: If the Registry doesn't support the option, then use of the parameter will be a problem, as neither of the other two parameters will be present. Simply ignoring the parameter doesn't work. The Registry must return an error. (Also, the editor box for this section improperly says "remove sentence".) Same for 3.18.4.1.2.3.7.6. | Ready Computing | Karen Witting | Yes, with comments | In 3.18.4.1.2.3.7.5 Note 3 you changed "is not allowed" to "shall be ignored". If it is ignored, the consequence is that the registry will return an error because none of the "required" parameters is specified. Not allowing it seems clearer to me but I guess adding the phrase "shall be ignored and thus cause an error" would be acceptable. Same comment for 3.18.4.1.2.3.7.6 | Merge | Ken Meyer | Yes | Arsenàl.IT | Mauro Zanardini | Yes | TSHA | Eric Heflin | Abstain | Philips Healthcare | Chris Melo | Yes | Forcare | Walco van Loon | Yes | ICW | Tarik Idris | No | 1. The reference to ITI-TF3 4.1.4 doesn't help anymore. This hasn't been change d (and is also wrong in current final text, but it really gave me problems understanding the section). It should probably point to 3.42.4.1.3.3.1 2. For GetDocuments, the new attribute cannot be ignored, it leads to an error, since it is there instead of the other mandatory attributes. Saying it can be ignored, sounds like a registry not implementing this supplement should suppress throwing an error. Why are we specifying what a registry that doesn't know this supplement should do? The doc consumer would be better served by informing them that queries with that query parameter will fail if the registry doesn't know MU. | IntraHealth | Luke Duncan | Abstain | ||||||||||
7 | 7/0/3 (2 blank votes) | 810-05 | Update ITI Security Considerations in MU Supplement | XDS | XDS-MU TI | McKesson | Elliot Silver | Yes | Allscripts | George Cole | Yes | ASIP Santé | Nader Cheaib | Yes | Harris/QuadraMed | Elliott Lavy | Yes | In the editor box, replace "as follows" with "with the following. Note that the prior text simply said, TBD." Human Requestor should be 0..1 and should say "if known" in the detail section. NetworkAccess* should be unspecialized, not NA. ParticipantObjectIDTypeCode should reference the actor appropriate to the section. "XDS Document Registry", not "XDS Registry". Can the Doc Admin know whether it's deleting a stable or on-demand docEntry? Or what about the Registry if the requested DocEntry doesn't exist? This should be changed to optional OR we should create a new URN for "unspecified DocEntry". Remove the "These codes are already defined" and "Any ebXML" sentences. RESOLUTION: These comments were resolved during ballot resolution; cardinality of Human Requestor not changed. | Ready Computing | Karen Witting | Abstain | Merge | Ken Meyer | Yes | Arsenàl.IT | Mauro Zanardini | Yes | TSHA | Eric Heflin | Abstain | Philips Healthcare | Chris Melo | Yes | blank vote | ICW | Tarik Idris | blank vote | IntraHealth | Luke Duncan | Abstain | |||||||||||||||
8 | 8/0/4 | 939-05 | Update MU Supplement to adjust for redoc of ITI-41 and 42 | XDS | XDS-MU TI | McKesson | Elliot Silver | Abstain | 3.57.4.1.3.1.2 "Accessing the Registry Object behind the targetObject attribute UUID is the only way to know which of these three kinds of objects is being updated.": Strictly speaking, querying the Registry isn't the only way to know; a combined Source/Admin or Repository/Admin could track submitted entities and thus know whether the target is a Doc Entry, etc. I think what is meant is that the type of the object is not conveyed in the update request. RESOLUTION: The text is just being moved. If it needs to be reworked, that is a separate CP. | Allscripts | George Cole | Yes | ASIP Santé | Nader Cheaib | Yes | Harris/QuadraMed | Elliott Lavy | Yes, if changed for clarity | 3.57.4.1.3.1.2: Switch to active voice ("The receiving actor shall…"). I'm wondering about the placement of this section, since we haven't talked about Trigger Associations yet. A foreward reference ("If a Trigger Assocation (see Section 3.57.4.1.3.3) triggers an update...") might resolve this, too. "availability status" -> one word. Is the word "annotation" appropriate? For the examples, an "id" attribute is required on Association. Change smart quotes to regular quotes. For OriginalStatus and PreviousVersion, there's no indication of any validation that the recipient shall/may do or what to do on mismatch. The text starting with "PreviousVersion" is unrelated to the section title (UpdateAvailabilityStatus). Should this be a new section? Same for AssociationPropagation. Section 4.3.1. Instead of adding text after the table, add the two actors into the table on the appropriate lines. Since XDS Doc Admin will appear on two lines, use a footnote to distinguish its two cases. | Ready Computing | Karen Witting | Yes | Merge | Ken Meyer | Yes | Arsenàl.IT | Mauro Zanardini | Yes | TSHA | Eric Heflin | Abstain | Philips Healthcare | Chris Melo | Yes | Forcare | Walco van Loon | Yes | ICW | Tarik Idris | abstain | IntraHealth | Luke Duncan | Abstain | ||||||||||||
9 | 8/0/4 Elliott | 962-01 | MU - Add parameters for SQ-FindDocumentsByReferenceId | XDS | XDS-MU TI | McKesson | Elliot Silver | Abstain | Allscripts | George Cole | Yes | ASIP Santé | Nader Cheaib | Yes | Harris/QuadraMed | Elliott Lavy | Yes | 3.18.4.1.2.3.7.14: Type and Status are not in the same order as in CP 955. Markup on the footnote for Type is unclear, but probably should not be changed. (Old value=6). The new footnotes should be 7 and 8. For clarity, the CP should either include the full table and all the footnotes (as in 955) or should give an indication of the gap (i.e., <snip>) (After any changes, review the editor box for accuracy.) | Ready Computing | Karen Witting | Abstain | Merge | Ken Meyer | Yes | Arsenàl.IT | Mauro Zanardini | Yes | TSHA | Eric Heflin | Abstain | Philips Healthcare | Chris Melo | Yes | Forcare | Walco van Loon | Yes | ICW | Tarik Idris | Yes | IntraHealth | Luke Duncan | Abstain | |||||||||||||
10 | 10/0/2 Elliott, Elliot | 965-00 | MU - Actor Requirements | XDS | XDS-MU TI | McKesson | Elliot Silver | Yes | 10.2.10 "A Document Registry declares the Document Metadata Update Option when it is able to": This phrasing is inconsistent with how options are currently introduced. Although there is expected to be a separate MU Redoc, it is trivial to correct this now. Change to: "A Document Registry which declares the Document Metadata Update Option when it is shall be able to" Similarly: "A Document Consumer which declares the Document Metadata Update Option when it is shall be able to..." Also, the removal of the text following "See ITI TF-2a: 3.18.4.1.2.5.1 for details" should not remove the period. The opening two paragraphs of 10.2.11 (one existing, one new) and opening paragraph of 15.2.5 are different, but it isn't clear why. I suggest updating both to the following, which is a re-ordering of the 15.2.5 text (markup omitted): A Document Administrator shall support the Update Metadata Option or the Delete Metadata Option or both. A Document Administrator that supports the Update Metadata Option shall be able to generate at least one of the operations documented in ITI TF-2b: 3.57.4.1.3.3 for the Update Document Set [ITI-57] transaction. RESOLUTION: Clean-up type issues are not being done in the context of this CP. Deferred to a future (not yet planned) redoc effort | Allscripts | George Cole | Yes | ASIP Santé | Nader Cheaib | Yes | Harris/QuadraMed | Elliott Lavy | Yes | 10.2.10: Change first line to "A Document Registry that supports the Document Metadata Update Option shall:" 10.2.10: Change "Doc Consumer" line to "A Document Consumer that supports the Document Metadata Update Option shall be able to…" 10.2.11: Instead of adding a new sentence, make it look like 15.2.5 (farther down in the CP) 15.2.4: Correct section title in editor box. Instead of a new sentence, make it look like 15.2.5 (except saying "all" instead of "at least one"). For clarity in the English, it might help to mention ITI-62 before ITI-57. Possibly remove the word "both". RESOLUTION: Clean-up type issues are not being done in the context of this CP. Deferred to a future (not yet planned) redoc effort | Ready Computing | Karen Witting | Yes | Merge | Ken Meyer | Yes | Arsenàl.IT | Mauro Zanardini | Yes | TSHA | Eric Heflin | Abstain | Philips Healthcare | Chris Melo | Yes | Forcare | Walco van Loon | Yes | ICW | Tarik Idris | Yes | IntraHealth | Luke Duncan | Abstain | ||||||||||||
11 | 8/0/4 | 966-00 | MU – Correct ATNA Message-No Async | XDS | XDS-MU TI | McKesson | Elliot Silver | Yes | Allscripts | George Cole | Yes | ASIP Santé | Nader Cheaib | Yes | Harris/QuadraMed | Elliott Lavy | Yes | Ready Computing | Karen Witting | Abstain | Merge | Ken Meyer | Yes | Arsenàl.IT | Mauro Zanardini | Yes | TSHA | Eric Heflin | Abstain | Philips Healthcare | Chris Melo | Yes | Forcare | Walco van Loon | Yes | ICW | Tarik Idris | abstain | IntraHealth | Luke Duncan | Abstain | ||||||||||||||
12 | 9/0/3 | 967-00 | Update XDS-MU for newer XDR content in ITI TF Vol 1 | XDS | XDS-MU TI | McKesson | Elliot Silver | Yes | The new diagram for figure 15.1-1 needs to be resized. RESOLUTION: diagram fixed | Allscripts | George Cole | Yes | ASIP Santé | Nader Cheaib | Yes | Harris/QuadraMed | Elliott Lavy | Yes | Ready Computing | Karen Witting | Yes | Merge | Ken Meyer | Yes | Arsenàl.IT | Mauro Zanardini | Yes | TSHA | Eric Heflin | Abstain | Philips Healthcare | Chris Melo | Yes | Forcare | Walco van Loon | Yes | ICW | Tarik Idris | abstain | IntraHealth | Luke Duncan | Abstain | |||||||||||||
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 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||