ITI CPs 2014-02-20

ITI domain CPs for 2013-2014 are managed here: http://wiki.ihe.net/index.php?title=ITI_Change_Proposals_2014

This page contains the agenda and minutes for the Feb 20, 2014 meeting.

Feb-20-2014

9-11am Central US

Agenda

(1) CP Ballot 20 - review ballot comments - ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance-2014/CPs/Ballots/ballot-20/

ITI-ballot20-ConsolidatedComments.xls in the above directory contains all votes and comments received on CP Ballot 20
We will discuss each CP that received either No votes or comments. These are the ones not marked "Approved" in the Ballot 20 summary here: http://wiki.ihe.net/index.php?title=ITI_Change_Proposals_2014#Ballot_20

(2) Ballot 19 clean-up - ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance-2014/CPs/Ballots/ballot-19/

ITI-CP-674-03 - (François Macary) - One CP in ballot 19 had comments that were unresolved. François has provided an updated version for review. The updated CP and the comments (in *RECONSTRUCTED*.xls) are found under the ballot-19 link above.

(3) Other

ITI-CP-630 - Forcare - XTN data type should be more specific

(4) Next in CPs

March 7 is next CP call and will include a discussion of strategies for reducing the backlog of CPs

Minutes

Attendees: Nancy Ramirez, Mohammad Jafari (ESC, VHA), Amanda Nash (S&I), Gila Pyke, Karen Witting, Lynn Felhofer, Bill Majurski, Walco van Loon, Rob Horn, Carl Leitner, Elliott Lavy, John Moehrke, Vassil Peytchev

The udpated status spreadsheet dated 2014-02-20 is here: ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance-2014/CPs/Status/

(1) CP Ballot 20 outcome is documented here: http://wiki.ihe.net/index.php?title=ITI_Change_Proposals_2014#Ballot_20

Detailed review:

CP-ITI-638 - Karen agreed to make edits to address these comments. Approved for FT.
- N - Bill - According to 4.1.12.3 Formatting of UUIDs (Rev 9) hex digits in a UUID are to use lower case a-f. This example shows both upper and lower case. The examples should be made consistent with the profile text.
- N - Vassil - Small change requested - do not use 'localhost' as the Reply-To endpoint, as it makes no sense. Use 'example.com' instead. The rest of the CP is fine
- Y - Elliott - What's the V.4 header line doing in there?
- N - Rob - 1. New table editor instructions and purpose unclear. IHE WSP200 is already in Table 3.2-1 with identical contents. 2. There is no Example 2 in section V.3.2.1.3, so it's unclear what change is wanted for that and subsequent edits. Please make changes with respect to the latest published version. Editors will not be able to understand what to do otherwise.
CP-ITI-672 - Failed ballot 20 - move back to Assigned - Elliott will convene a call incl. Vassil, Walco, & Bill.
- N - Bill - Sorry I missed this (got buried in all the mustUnderstand discussions) but there is no technical value in making ReplyTo required. WS:Addressing labels it optional and it has a default value which indicates synchronous behaviour. This profiling restriction is without value to interoperability.
- N - Vassil - I don’t think IHE should recommend the following: "IHE recommends that the mustUnderstand attribute NOT be set for the <wsa:ReplyTo> element, as some tools cannot handle this." This is backwards incompatible - the systems that have made sure that they have the attribute set are now finding themselves as going against recommended practices. The rest of the CP is fine
CP-ITI-687 - Failed ballot 20; re-assign to Mauro to clean-up references to ID for consistency. Problem w/ length of CXi will be a separate CP to be submitted by Lynn.
- A - Karen - Concerned by the open issues in the rationale. Not sure it is clear what a workflow uniqueid is. This seems to be used without definition and later different term is used: 5.4.2.2 calls it workflowinstanceID. Using uniqueID in the term could confuse it with document uniqueID - that is what I thought originally. Maybe a different term would be better. And some statement that the Registry must support this option is needed somewhere, with this change XDW cannot work with a registry without this option.
- Y - John - There is a ill worded statement about the order of deprecate and publish in section 5.4.5.4 Update of a Workflow Document. It states: Content Updater A deprecates the previous version and publishes a new version updated with a new document uniqueId (e.g. document uniqueId 2). This gives the impression that deprecation happens before publishing. This is misleading as the XDS Registry deprecates as a consequence of accepting the replacement of a document. We suggest that it should read: <...>
- (non-ballot comment) - Table 5.4.6.1.1-1 says the value for referenceIdList shall be set to urn:ihe:xdw:2013:workflowId but the ID portion of the CXi datatype is limited to 15 characters.
CP-ITI-690 - Lynn will make edits based on Elliott's suggestion and John will review. Approved for FT
- Y - Elliott - w/ some rewording suggestions
- Y - Rob - 1. Suggest changing "policy of the participants in the exchange" to "policy of the affinity domain".
CP-ITI-707 - Approved for FT (zero "No" votes). Ask George to provide an updated version based on Elliott's comment.
- Y - Elliott - Recommend that "parameter" be replaced by "element" in table intro and column header. Specify the elements with a path, i.e. form/Structured. The "form" element (lower-case, not upper) should specify that it has no value, just sub-elements. The namespace should be specified in the intro to the table (something like, "all elements are in the "urn:ihe:iti:rfd:2007" namespace"). Value column should be renamed "Constraints". Move the "may be nil" comments into the Constraints column.
CP-ITI-714 - Approved for FT. We also need to make sure that these elements are not capitalized in the publication process - Lynn to contact Mary. John recommended making punchlist for the committee to check for things like proper case on parameter names, and others...
- Y - Karen - This is created from the editorial process and cannot be fixed in a CP
CP-ITI-715 - Approved for FT. As a follow-on, Karen suggested additional table is needed -> metadata enforcement by Registry on an association; to be added via a separate CP as an outcome of the MU work.
- N - Karen - I agree this should be removed but it should be replaced with something. Perhaps a table about Association Metadata Enforcement, where the rows are associationType, sourceObject, targetObject and the descriptions are similar to what is in the rows this CP removes
CP-ITI-718 - Move back to Assigned so that Vassil can consider these comments.
- Y - Sylvie - Why is the cardinality of Namespace ID equal to [1..1]? it should be [0..1].
- Y - Karen - The update results in a confusing sentence, I think it would read "Or with all at least two components" do you mean "Or with at least two components" fix editorial marks appropriately
- Y - Elliott - There are implications in the text ("this integration profile", "this profile") that Appendix N was originally intended for use by a specific profile. Its current placement implies more-general applicability. If the rules for Appendix N are really to apply to a specific profile, the better approach would be to rename the appendix and/or add text at the beginning of the appendix to refer to the profile, and to add a reference to the appendix in the relevant transactions. I found no references to "Appendix N" in volume 2a or 2b. If the rules in Appendix N are mostly intended to be more general, then the indicated modifications are fine, although text should be added to indicate that individual transactions may apply more stringent rules (and those transactions should be modified accordingly). Don't see any change in the table.
- Y - Rob - Correct typo, strike through "all three", not just "three"
CP-ITI-729 - Approved for FT w/ edits based on comments.
- Y - Elliott - Modification for Unique Entry Identifier also needs to reference the organization, since @oid represents a triplet. CP needs underlining of additions in first section.
- Y - Rob - The fonts look wrong on my system.
CP-ITI-730 - Approved for FT w/ edits based on comment.
- Y - Elliott - Editor notes should indicate that the highlighting is present only to aid in locating the changes. It is not to become part of the TF.
CP-ITI-731 - Walco withdrew "N" vote. Approved for FT with Rob's suggested edits. Lynn will facilitate setting up a wiki to enable implementors to provide input on schema differences that are causing problems so that they can be addressed by IHE or DICOM. The wiki page is here: http://wiki.ihe.net/index.php?title=ATNA_Audit_Format_Problems
- N - Walco - This introduces backwards-incompatible changes; two things known are (a) the requirement to have a codingScheme for a code, which, when applied to PurposeOfUse is difficult sometimes (see Masi's mail on the subject; in essence the code is a plain string (URN) in XSPA and since the URN is globablly unique anywy, the coding scheme is unnessary) and (b) the rename of some attributes, for no documented reason we could find. We'd rather first reconcile the DICOM/IHE/RFC-3881 audit content before we make extensive references to DICOM part 15...
- Y - Rob - 1. Revise "but the DICOM 2011 Standard" to read "the final text issued by DICOM in 2011" 2. Change "http://www.dclunie.com/dicom-status/status.html" to "http://medical.nema.org/standard.html" because NEMA changed the link (finally). The old link will probably continue to work for years, but the new link is the right one for us to use.
CP-ITI-736 - move to Assigned & Walco will check with other implementors on whether this switch will cause backward compatibility issues. John does not feel strongly.
- N - Walco - (We are open to debate on this one.) This one states that the BPPC classCode should really be a typeCode. However, to be able to retrieve BPPC documents, we (and potentially other consumers) have long depended on the classCode to be used in a query. That will break - a backwards incompatible change. In addition, I think classification of BPPCs on the classCode level would help with the following scenario (this is "real life"): the use case where different consents are used, particularly in an XCA setting; all consents are registered using the BPPC classCode, but the typeCode differs: the country-wide consent may have a different typeCode (typeCode=”COUNTRYWIDE”) form a regional consent for region ABC (typeCode=”ABC”). These consents can be handled similarly if the classCode "unifies" them, but they can still be presented differently in the UI or processed for access control based on their typeCode.
- Y - Elliott - In the "backward compatibility" section, there is no mention of codeSystem. Is there any guidance to give there?
CP-ITI-737 - Approved for FT based on edits made to address comments.
- Y - Karen - I think a word is missing in DocumentEntry.classCode description that is found in th table. Table says "classification of document type". Description shows "classification of document" . I believe "type should be added to the description as it was done in the table. In any case, these sentences should be the same.
- Y - Elliott & Rob - In the mod for table 4.2.3.2-1, instead of just saying "LOINC", it should say "a LOINC code".

(2) Ballot 19 clean-up

CP-ITI-674 - Review of François' changes were deferred to the March 7 so the updates can be reviewed by the committee in advance.