PHER RPT2CANCERREG DSTU R1 D1 1 Review

This Review is CLOSED as of Noon Eastern, 4/22/2015

This wiki page will support review and feedback for proposed updates to the HL7 Implementation Guide for CDA© Release 2: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1.1 US Realm. This IG consist of two volumes: Volume 1 provides narrative introductory and background material pertinent to this implementation guide, including information on how to understand and use the templates in Volume 2. Volume 2 contains the Clinical Document Architecture (CDA) templates for this guide along with lists of templates, code systems, and value sets used.

An update has been made to the implementation Guide. This update is available to HL7 members here: Cancer Registry CDA IG R1 D1.1 Draft as a DOT release for commenting prior to reconciliation and publication. As a DSTU update, this new version will not go through the usual HL7 balloting process but will use the DSTU Update process with industry review on the HL7 wiki. The full list of changes in this release are documented in the update and can be summarized as follows:

1. Many templates were versioned due to the versioning of contained templates (see the detailed section “Changes from Previous Version” in Volume 2 of this guide for a detailed view of these changes). Note that this release involves technical corrections to the original release, no new content has been included. Changes include:
2. Refactoring of the TNM Clinical Stage Observation into a nested series of smaller, easier to implement templates. The TNM Clinical Stage Observation template had grown into a largely, multi-level template that was difficult to implement and test. Refactoring into smaller templates makes each piece simpler to implement and test.
3. Refactoring of the TNM Pathologic Stage Observation into a nested series of smaller, easier to implement templates. The TNM Pathologic Stage Observation template had grown into a largely, multi-level template that was difficult to implement and test. Refactoring into smaller templates makes each piece simpler to implement and test.
4. There were several places in Release 1 of the specification that had contradictory use of nullFlavor attributes. This includes use of null flavors on the following:
   • Cancer Event Report Document Header - Birthplace, Place and Place/addr
   • Cancer Event Report Document Header - EncompassingEncounter/encounterParticiant/assignedEntity - For this item, a choice between a fully populate encounterParticipant and an unknown encounter participant was introduced to deal with the contradiction in the earlier use of null flavor.
   • There are several places with the specification where nullFlavors were explicitly allowed in CD data types in conjunction with very tight constraints on the use of the code, codeSystem, displayName and valueSet attributes. This combination effectively precluded the meaningful use of nullFlavor. Since it was the designers original intent to actually allow the use of null flavors when an actual value as not know, we have introduced conditional logic that allows the use of both in a consistent fashion. For example:
     • If value/@nullFlavor is not present then
     • This value SHALL contain exactly one [1..1] @code

1. A primitive constraints in the Cancer Diagnosis Observation that provided a choice between the TNM Clinical Stage Observation and a No Known TNM Clinical Stage Observation was replace by a choice of standard constraints on the same two templates. This results in both a cleaner easier to understand specification and simplifies the resulting schematron file used for validation.
2. A primitive constraints in the Cancer Diagnosis Observation that provided a choice between the TNM Pathologic Stage Observation and a No Known TNM Pathologic Stage Observation was replace by a choice of standard constraints on the same two templates. This results in both a cleaner easier to understand specification and simplifies the resulting schematron file used for validation.

Comments

Enter your comments below this line.

1. Austin Kreisler 4/22/2015
   • The example for 2.18 Social History Section (V2) - Cancer IG Specific Constraints (V1.1) - Draft section: identifier urn:hl7ii:2.16.840.1.113883.10.13.11:2015-01-29 (open) shows a social history observation 2.16.840.1.113883.10.20.22.4.38:2014-06-09) but the conformance statement seems to preclude inclusion of social history observations.
   • 4. SHALL NOT contain [0..0] entry (CONF:1169-33884) such that it
   • a. SHALL contain exactly one [1..1] Social History Observation (V2) (identifier: urn:hl7ii:2.16.840.1.113883.10.20.22.4.38:2014-06-09) (CONF:1169-33889).

Which is correct, the example or the constraint?

1. Cancer Registry Team (4/22/2015) - The example is incorrect, it should not include a Social History Observation.