ITI Change Proposals 2014: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
← Older editNewer edit →
Line 262: Line 262:
* 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.
* 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) Next in CPs'''
'''(3) Other'''
* ITI-CP-630 - Forcare - XTN data type should be more specific
 
'''(4) Next in CPs'''
* March 6 is next CP call and will include a discussion of strategies for reducing the backlog of CPs
* March 6 is next CP call and will include a discussion of strategies for reducing the backlog of CPs


Revision as of 09:47, 20 February 2014

Introduction

The ITI Change Proposal (CP) process follows the general IHE CP process described on the Change Proposal process page. The following sections give more detail on the general process for ITI participants involved in the CP process.

The ITI-specific CP Process

The following text explains what the process used by the ITI commitee in processing submitted CPs. It is consistent with the general IHE CP process and is informative only.

  1. Write a change proposal. Here is IHE's Change_Proposal_Template
  2. Submit into the Incoming directory. This is typically done by directly updating the directory if you have access; otherwise send it an email to the ITI Technical Committee members in charge of CPs (currently Erik Pupo and Lynn Felhofer).
  3. The new CPs are considered by the committee at periodic CP review calls. If CP is accepted it is given a CP #, assigned an editor, renamed to CP-ITI-xxx-00.doc and placed in Assigned. If CP is rejected it is moved to Rejected and submitter is informed of explanation for rejection. Likely reasons for rejection are: duplicate, merged, withdrawn or not enough information to understand the request. Rejected CPs can be resubmitted with more information for reconsideration.
  4. Committee works with editor to draft the CP. Versions are kept in Assigned directory and numbered -00, -01, -02, etc.
  5. Committee decides CP is ready for ballot. Latest version of CP is moved to Completed diretory and old versions are moved to old_versions.
  6. Co-chair collects Completed CPs into a ballot. The Ballot directory will be used for this.
  7. Ballot is released to the general community for voting
  8. Votes and comments are collected. All yes votes means the CP passed ballot and moved to FinalText. No votes are resolved by the committee. Sometimes CP is withdrawn, sometimes NO voter changes to yes vote after explanations. CP may be updated in this process. If updates are insignificant (clarification only) the CP is considered passed. If updates are significant the CP is submitted for another ballot.
  9. CP approved in ballot are put in FinalText and scheduled to be integrated into the Technical Framework or Supplement.

Directory Structure

As CPs are processed through various statuses they move from one directory to another. The directories involved are:

Incoming
contains CPs which have been submitted but have not been assigned a CP number or an editor. This is the place that new incoming CPs are placed prior to the first stage of processing by the committee.
Assigned
contains CPs that have been assigned an editor and are being actively worked on by the committee, i.e. Assigned status
Completed
contains the last version of a CP that is in Completed status. It is waiting to be put in a ballot
FinalText
contains the last version of a CP that is in FinalText status. It is has been approved by ballot and is waiting to be integrated into the TF.
Integrated
contains the version of the CP that was integrated into the TF.
Rejected
CPs that have been submitted by rejected by the committee
Canceled
contains CPs that have been canceled, i.e. Canceled status
Ballots
contains Ballots that have been released for voting by the general community
Status
contains spreadsheets describing the status of CPs.

Change Proposal pages from previous years

Ongoing work on CPs is placed on the current year CP page. Prior years work can be accessed at:

ITI CP Tracking

All Change Proposal management is done in ITI CP ftp site. The tracking spreadsheet can be accessed at Status directory. It is the file with the most recent date in that directory.

Integrated CPs 2014

This section will document all CPs integrated into the Version 11.0 of the Technical Framework and the 2014 version of Supplements in August 2014

Ballots

Ballot 19

Balloted in Aug 2013.

Ballot 19, including ballot comments, is archived here: ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance-2014/CPs/Ballots/ballot-19/

CP Title Profile or Volumes Affected Ballot Result
581-02 DSUB correction for event ID in audit message DSUB Failed, see comments in archive link above
655-02 Modify field predicate logic for conditional fields PID-29, PID-30 (Patient Death) of IHE PAM 2a,2b Failed, see comments in archive link above
657-04 Consistency of HD and CX datatype definitions in the appendix. 2b Approved Final Text
673-02 Corrections of the usage code of some fields in segments PID, PV1, OBX, for PAM 2b Approved Final Text
674-03 (updated version to be reviewed) New option “Diagnostic Imaging Aware” for PAM to facilitate adoption by other domains (RAD, CARD, …) 2b Approved for Final Text with updates from ballot comments
681-02 XDW Actor Definition 1 Accepted ballot comments; -02 was integrated into XDW in 2013

Ballot 20

Ballot reviewed Jan 7 - Feb 7, 2014

Ballot 20 CPs and consolidated comments received during review are archived here: ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance-2014/CPs/Ballots/ballot-20

Comments will be reviewed at the Feb 20, 2014 CP call.

CP Title Profile Vol Ballot Result
CP-ITI-516-02 Correct hyperlinks to point to TF sections XUA 1 Approved for FT
CP-ITI-586-01 MU Typo MU 2b Approved for FT
CP-ITI-638-01 Async Supplement update to Appendix V Async 2x
CP-ITI-660-03 XCPD diagram shows single when should be multiple XCPD 2b Approved for FT
CP-ITI-672-01 mustUnderstand many 2x
CP-ITI-678-00 Correction of the example illustrating the URL of Find document Dossiers message MHD 2c Approved for FT
CP-ITI-687-03 Use referralIdList as specified by CP-ITI-659 instead of folders in XDW XDW 1,3
CP-ITI-690-05 Document Sharing Metadata Enhancement for Security/Privacy Tags XD* 3
CP-ITI-707-00 Document Retrieve Form Response RFD 2b
CP-ITI-708-01 Update Appendix V with current versions of WS-I profiles many 2x Approved for FT
CP-ITI-713-00 Correct labelling of XCA IG in query attribute optionality XCA 3 Approved for FT
CP-ITI-714-00 Correct capitalization of Document Sharing Attribute names XD* 3
CP-ITI-715-00 Remove parentDocument references XDS 3
CP-ITI-717-00 Incorrect section reference ATNA 2a
CP-ITI-718-00 Namespace ID required even if ISO OID set PDQv2, PAM 2x
CP-ITI-719-00 Typo in audit message for Document Registry/Recipient in Metadata Update supplement MU 2b Approved for FT
CP-ITI-729-00 Typo in FacilityServices CSD 2x Approved for FT
CP-ITI-730-00 Limited Metadata Audit XDS 2b
CP-ITI-731-00 DICOM Audit Differences ATNA, many 2a
CP-ITI-736-00 clarification of BPPC typeCode BPPC 3
CP-ITI-737-00 clarification of classCode from typeCode XD* 3

Assigned CPs

For a list of CPs that are currently assigned see the latest CP-ITI-Tracking-201x-nn-nn.xls file in the Status directory.

Upcoming CP discussions

ITI CP review calls are typically held the 1st and 3rd Thursday of each month from 9-11am Central US. Additional sessions may be scheduled during ITI Tech F2F meetings.

Feb-20-2014

9-11am Central US

Webex link: https://himss.webex.com/himss/j.php?J=921161852&PW=NZDYyMzlkNTk1

Dialin (US): 866-469-3239

Meeting number: 921 161 852

Password: meeting

Agenda

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

(1) CP Ballot 20 - review ballot comments - ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance-2014/CPs/Ballots/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 6 is next CP call and will include a discussion of strategies for reducing the backlog of CPs

Minutes

Attendees:

(1) CP Ballot 20 - review ballot comments:

  • CP-ITI-638 -
    • 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 -
    • 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 -
    • 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 consequnce 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 -
    • 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 -
    • 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 -
    • Y - Karen - This is created from the editorial process and cannot be fixed in a CP
  • CP-ITI-715 -
    • 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 -
    • 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 -
    • 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 -
    • 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 -
    • 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 -
    • 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 -
    • 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 -

Mar-6-2014

9-11am Central US

Agenda

(1) Assigned CPs ready for review: ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance-2014/CPs/1_Assigned/

  • CP-ITI-685-02 HPD Error codes - (Christian Orr)

...

(2) Review of Incoming CPs: ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance-2014/CPs/0_Incoming/

  • CP-ITI-tbd

...

(3) Strategy for reducing CP backlog

Agenda and Minutes from past CP calls

Feb-14-2014 (Vienna F2F)

Agenda and minutes are here: http://wiki.ihe.net/index.php?title=ITI_CPs_2014-02-14

Feb-10-2014 (Vienna F2F)

Agenda and minutes are here: http://wiki.ihe.net/index.php?title=ITI_CPs_2014-02-10

Feb-6-2014

Agenda and minutes are here: http://wiki.ihe.net/index.php?title=ITI_CPs_2014-02-06

Jan-16-2014

Agenda and minutes are here: http://wiki.ihe.net/index.php?title=ITI_CPs_2014-01-16

Dec-19-2013

Agenda and minutes are here: http://wiki.ihe.net/index.php?title=ITI_CPs_2013-12-19

Dec-5-2013

Agenda and minutes are here: http://wiki.ihe.net/index.php?title=ITI_CPs_2013-12-05

Nov-21-2013

Agenda and minutes are here: http://wiki.ihe.net/index.php?title=ITI_CPs_2013-11-21

Retrieved from "http://wiki.ihe.net/index.php?title=ITI_Change_Proposals_2014&oldid=74522"