This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

PHCR eICR R2 STU1.1 Update Comments

From HL7Wiki
Revision as of 10:07, 8 December 2016 by Minigrrl (talk | contribs) (→‎Comments)
Jump to navigation Jump to search

November 2016 - HL7 CDA® R2 Implementation Guide: Public Health Case Report, Release 1, STU Release 1.1 - US Realm - Available for Comment

This wiki page will support review and feedback for proposed updates to the HL7 CDA® R2 Implementation Guide: Public Health Case Report, Release 1, STU Release 1.1 - US Realm.

This IG consists 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.

For commenting prior to reconciliation and publication, the STU update Implementation Guide and its related files are available to HL7 members here: Update_for_Comment_CDAR2_IG_PHCASERPT_R2_D1.1_2016DEC.

As an STU update, this new version will not go through the usual HL7 balloting process but will use the STU Update Process with industry review on the HL7 wiki.

The changes in this update can be summarized as follows:

Volume 1 Typo corrections, non-substantive wording changes were made throughout the document but these changes will not be detailed.

  • New chapters/sections/appendices (only the top heading-level of the addition is noted):
    • 1.3 Organization of the Guide
    • 1.6 Current Project
    • 3 CDA R2 Background
    • 5.2 Stand-Alone Templates
    • 5.4 Trigger Code Templates
    • Appendix A — Acronyms and Abbreviations
    • Appendix B — High Level Change Log
    • Appendix C — Extensions to CDA R2
  • Updated chapters/sections:
    • 4 Using This Implementation Guide
      • replaced "Conventions used in this implementation guide" section
    • 4.1 Conformance Conventions Used in This Guide
    • 4.2 Templates and Conformance Statements
    • 4.3 XML Conventions Used in This Guide
      • Split chapter "Data Requirements and IG Template Specifications Organization" into the following two chapters:
    • 5 eICR IG Specific Conformance Guidance
    • 6 eICR Data Requirements
      • Updated tables and diagrams to reflect new data elements and added sections (see above)

Volume 2

  • Document-Level Templates
    • No new document-level templates were added.
    • Initial Public Health Case Report Document (eICR) was versioned to V2:
      • Added containment for C-CDA R2.1: Plan of Treatment (V2) Section
      • Added containment for Birth Sex Observation
      • Added @sdtc:deceasedInd
      • Updated constraint for @sdtc:deceasedTime
      • Added guidance for using county in an address
      • Updated examples
  • Section-Level Templates
    • One new section-level template was added:
      • C-CDA R2.1: Plan of Treatment (V2) Section
    • Entry-Level Templates
      • Five new entry-level templates were added:
      • C-CDA R2.1 Companion Guide: Birth Sex Observation
      • C-CDA R2.1 Based: Initial Case Report Trigger Code Lab Test Order
      • C-CDA R2.1 Based: Initial Case Report Trigger Code Problem Observation
      • C-CDA R2.1 Based: Initial Case Report Trigger Code Result Observation
      • Travel History
  • Value Sets
    • Seven new value sets were added:
      • Initial Case Report Trigger Code Result Status
      • ONC Administrative Sex
      • Reportable Conditions Trigger Code Value set
      • Trigger code for condition name (RCTC subset)
      • Trigger code for laboratory test names (RCTC subset)
      • Trigger code for laboratory test orders (RCTC subset)
      • Trigger code for organism or substance (RCTC subset)

Review Note: Travel History template: As this is a new template and not based on any existing template, we encourage detailed review and feedback around the utility and design of this template


During the one week comment period running from November xx-xx, 2016, please submit your comments below including at least your name, item, existing wording, proposed wording, and comment.


Thank you.

Enter your comments below this line by clicking on the Comments (edit) link.

Comments

Comment Number: xx

Example comment:

Name: HL7 Commenter

Item: Volume 2, Template XXXX

Existing wording: CONF: xxxxx-xx SHOULD contain exactly 1..1

Proposed wording: CONF: xxxxx-xx SHALL contain exactly 1..1

Comment Number: 1

Name: Sarah Gaunt

Item: Volume 1: 4.1 Templates and Conformance Conventions

Existing wording: This heading is at the wrong level - it needs to be indented on level so that it is nested under 4.1 Conformance Conventions Used in this Guide

Proposed wording: Indent 4.1 Templates and Conformance Conventions one level so that it is 4.1.1 Templates and Conformance Conventions

Proposed Disposition: Will fix heading as suggested.

Comment Number: 2

Name: George Cole

Item: Volume 2: Section 3.14 Travel History

Existing wording: The participant contains a location (either an address or a coded location)

ii. This participantRole MAY contain zero or one [0..1] code, which SHOULD be selected from ValueSet Geographical location history urn:oid:2.16.840.1.114222.4.11.3201 DYNAMIC (CONF:3284-263). Note: Coded value of the location

Figure 52: Travel History - Coded Location Example

Proposed wording: The participant may contain a location as an address.

Reason for proposal: The coding and exchange is simplified with only one approach for travel location, and we suggest using addr and removing the coded location text, constraints, and example.

Proposed disposition: The reasoning around allowing for more than one method of recording travel history is that we are trying to be as flexible as possible with the approach (we have also allowed for free text in the text element). The preferred method would actually be to have this coded, but it was considered that it is unlikely, at this point in time, that this information is stored in the EHR, or at least stored in EHRs in a consistent manner. The worry is, that if we do restrict the template to one method we will end up getting very little data.

Note: Emailed the above to George Cole who responded with the following: "We’re certainly ok with leaving that flexibility on the template as written. I entered the issue into the wiki mostly to get some discussion on the or condition, plus selfishly suggesting the single approach that I figured we could most easily support today."

Comment Number: 3

Name: George Cole

Item: Volume 2: Section 3.14 Travel History

Existing wording: ....ValueSet Geographical location history... (the hyperlink points to a nonexistent bookmark)

Proposed wording: https://phinvads.cdc.gov/vads/ViewValueSet.action?id=9CE75E17-176B-DE11-9B52-0015173D1785

Proposed Disposition: Persuasive with mod. This value set wasn't entered properly in Trifolia. I've fixed it and it will now export the first 10 codes in the usual table (linked by the link that wasn't working before). The table will have the following (with a working link to PHIN VADS):

Value Set: Geographical location history urn:oid:2.16.840.1.114222.4.11.3201

Locations out of US (Birth Country) and jurisdictions within US (states) that are potentially relevant to current condition. This value set is based upon ISO 3166 (Countries) as well as FIPS 5-2 (States).

Value Set Source: https://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.114222.4.11.3201


Comment Number: 4

Name: George Cole

Item: Volume 2: Section 3.14 Travel History

Existing wording: 7. SHALL contain exactly one [1..1] effectiveTime (CONF:3284-295). Note: Date(s) spent in the location

Proposed wording: 7. SHALL contain exactly one [1..1] effectiveTime (CONF:3284-295). Note: Date(s) spent in the location, using any format for effectiveTime that is supported by CDA. See Figure 54: effectiveTime Examples

Reason for proposal: Until we saw the examples, we wondered whether or not there were missing constraints on effectiveTime.

Proposed Disposition: Sarah Gaunt: Persuasive, will change wording to that suggested.

Comment Number: 5

Name: George Cole

Item: Volume 2: Section 3.14 Travel History

Existing wording: The participant contains a location

Question (not suggested change): We were a bit surprised to see Travel as an act with participants containing locations. It is a bit hard to see a country as a participant of an act. So, we just have to ask if other constructs were considered. For example, was coded observation with location as a value considered?

Proposed Disposition: Sarah Gaunt: Question Answered: We based this modeling on a SD listserv discussion from 2014 and a subsequent Kieth Boone blog post (http://motorcycleguy.blogspot.com.au/2014/10/on-process-for-rapid-template.html ). I'll send you the listserv discussion for your reference (hard to reference it here!)

Note: Emailed George Code who stated that "knowing that this has all been discussed makes me happy".

Comment Number: 6

Name: George Cole

Item: Volume 2: Section 3.11.1 3.11.1 Initial Case Report Trigger Code Result Observation, Figure 45: Initial Case Report Trigger Code Result Observation - Final Result Example

Existing wording: The example shows template ID's with and without extensions, as would be required for C-CDA R2.1

<templateId root="2.16.840.1.113883.10.20.22.4.2" />

<templateId root="2.16.840.1.113883.10.20.22.4.2" extension="2015-08-01" />

Question (not suggested change): Since this guide publishes Result Observation (V3), and other templates, without the C-CDA R2.1 requirement to have both templateId elements (with and without extension), does that mean that there is no requirement in this guide to publish both templateId elements?

Could Figure 45, and the example file distributed with the guide, be published with only <templateId root="2.16.840.1.113883.10.20.22.4.2" extension="2015-08-01" /> ? What is the thinking on inclusion or not of the unversioned templateId?

Proposed Disposition: In discussion through email, will update when a clear path forward has been decided upon

Comment Number: 7

Name: Justine Maxwell, TN Dept of Health

Item: 1.9 Contents of Package, Volume 1, (Table 2.)

Question: Should the table include an additional column that list the exact chapter and section the normative or informative material is located throughout volumes 1 and volumes 2? In Release 1.0 of the Implementation Guide, it clearly stated what chapters/sections were normative (e.g. “The examples and comments in Chapters 2 and 3, are not normative and any conflict between content therein and Chapters 1 or 4 should be favor the specifications in Chapters 1 and 4.”).

Proposed disposition: Sarah Gaunt: Persuasive. Sure - we can add another column that includes that information.

Comment Number: 8

Name: Justine Maxwell, TN Dept of Health

Item: Volume 1, 4.1 Conformance Conventions Used in This Guide

Existing wording: Only the title of the section is included. There is actually nothing in 4.1. It looks like the language starts in 4.2.

Proposed wording: Either include language conformance conventions used in this guide section under 4.1, or remove this section.

Proposed disposition: Sarah Gaunt: Persuasive. See Comment Number 1 - this header is at the wrong level. Will fix.

Comment Number: 9

Name: Justine Maxwell, TN Dept of Health

Item: Volume 1, 4 Using this Implementation Guide

Existing wording:

Suggestion/Proposed wording: Include a statement somewhere in Section 4 stating that “The reader of this implementation guide is expected to have available and use the Clinical Document Architecture, Release 2 (CDA R2) US Realm Standard and the Consolidated CDA (C-CDA) DSTU Release 2.1 Templates Standard” An example of why the reader may need to know that they need to go back to the base standards is this: For the “id” data element, the implementation guides only states that it “SHALL be a globally unique identifier for the document.” Does the “id” have to contain an extension, or is just a “root” without an “extension” sufficient? A reader may not realize that they have to go back to the base standards in order to figure out this information.

Proposed disposition: Sarah Gaunt: Persuasive. Will add wording as suggested.

Comment Number: 10

Name: Justine Maxwell, TN Dept of Health

Item: Volume 2, 1.1.1.5 informant (Assigned Healthcare Provider, volume 2, page 26) The example for the Assigned Health Care Provider Informant (volume 2, Figure 5, page 48) has data elements telecom and representedOrganization. However, there are no numbered list of constraints used in the eICR IG under Assigned Health Care Provider Informant that include conformance statements and cardinality indicators and identifiers. Is this missing information intentional? What constraints are used to generate the example (Figure. 5)

Existing Wording:

iii. This assignedEntity SHALL contain at least one [1..*] US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2) (CONF:1198-8220).

iv. This assignedEntity SHALL contain exactly one [1..1] assignedPerson (CONF:1198-8221).

1. This assignedPerson SHALL contain at least one [1..*] US Realm Person Name (PN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1.1) (CONF:1198-8222).


Proposed wording:

iii. This assignedEntity SHALL contain at least one [1..*] US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2) (CONF:1198-8220). iv. This assignedEntity SHALL contain at least one [1..*] telecom (CONF:1198-****).

1. Such telecoms SHOULD contain zero or one [0..1] @use, which SHALL be selected from ValueSet Telecom Use (US Realm Header) urn:oid:2.16.840.1.113883.11.20.9.20 DYNAMIC (CONF:1198-****).

v. This assignedEntity SHALL contain exactly one [1..1] assignedPerson (CONF:1198-8221).

1. This assignedPerson SHALL contain at least one [1..*] US Realm Person Name (PN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1.1) (CONF:1198-8222).

vi. This assignedEntity SHALL contain exactly one [1..1] representedOrganization (CONF:2218-**).

i. This representedOrganization SHALL contain exactly one [1..1] name (CONF:2218-**).

Proposed Disposition: Sarah Gaunt: Not related(?). This template (US Realm Header (V2)) is not open for comment in this IG as it is "Published as part of Consolidated CDA Templates for Clinical Notes (US Realm) DSTU R2.1". Please make this comment on the comment page here: C-CDA R2.1 Comments Page

Comment Number: 11

Name: Justine Maxwell, TN Dept of Health

Item: Volume 2, 1.1.1.15 Performer (volume 2, page 31) The example for the Performer (volume 2, Figure 14, page 53) has data elements telecom and representedOrganization. However, there are no numbered list of constraints used in the eICR IG under Perfomer that include conformance statements and cardinality indicators and identifiers. Is this missing information intentional? What constraints are used to generate the example (Figure. 14)?

Existing Wording:

ii. This serviceEvent SHOULD contain zero or more [0..*] performer (CONF:1198-14839).

1. The performer, if present, SHALL contain exactly one [1..1] @typeCode, which SHALL be selected from ValueSet x_ServiceEventPerformer urn:oid:2.16.840.1.113883.1.11.19601 STATIC (CONF:1198-14840).

2. The performer, if present, MAY contain zero or one [0..1] functionCode (CONF:1198-16818).

a. The functionCode, if present, SHOULD contain zero or one [0..1] @code, which SHOULD be selected from ValueSet ParticipationFunction urn:oid:2.16.840.1.113883.1.11.10267 STATIC (CONF:1198-32889).

3. The performer, if present, SHALL contain exactly one [1..1] assignedEntity (CONF:1198-14841).

a. This assignedEntity SHALL contain at least one [1..*] id (CONF:1198-14846).

i. Such ids SHOULD contain zero or one [0..1] @root="2.16.840.1.113883.4.6" National Provider Identifier (CONF:1198-14847).

b. This assignedEntity SHOULD contain zero or one [0..1] code, which SHOULD be selected from ValueSet Healthcare Provider Taxonomy (HIPAA) urn:oid:2.16.840.1.114222.4.11.1066 DYNAMIC (CONF:1198-14842).

Proposed wording:

ii. This serviceEvent SHOULD contain zero or more [0..*] performer (CONF:1198-14839).

1. The performer, if present, SHALL contain exactly one [1..1] @typeCode, which SHALL be selected from ValueSet x_ServiceEventPerformer urn:oid:2.16.840.1.113883.1.11.19601 STATIC (CONF:1198-14840).

2. The performer, if present, MAY contain zero or one [0..1] functionCode (CONF:1198-16818).

b. The functionCode, if present, SHOULD contain zero or one [0..1] @code, which SHOULD be selected from ValueSet ParticipationFunction urn:oid:2.16.840.1.113883.1.11.10267 STATIC (CONF:1198-32889).

3. The performer, if present, SHALL contain exactly one [1..1] assignedEntity (CONF:1198-14841).

a. This assignedEntity SHALL contain at least one [1..*] id (CONF:1198-14846).

i. Such ids SHOULD contain zero or one [0..1] @root="2.16.840.1.113883.4.6" National Provider Identifier (CONF:1198-14847).

b. This assignedEntity SHOULD contain zero or one [0..1] code, which SHOULD be selected from ValueSet Healthcare Provider Taxonomy (HIPAA) urn:oid:2.16.840.1.114222.4.11.1066 DYNAMIC (CONF:1198-14842).

c. This assignedEntity SHALL contain at least one [1..*] US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2) (CONF:1198-8220). d. This assignedEntity SHALL contain at least one [1..*] telecom (CONF:1198-****).

1. Such telecoms SHOULD contain zero or one [0..1] @use, which SHALL be selected from ValueSet Telecom Use (US Realm Header) urn:oid:2.16.840.1.113883.11.20.9.20 DYNAMIC (CONF:1198-****).

e. This assignedEntity SHALL contain exactly one [1..1] assignedPerson (CONF:1198-****).

1. This assignedPerson SHALL contain at least one [1..*] US Realm Person Name (PN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1.1) (CONF:1198-****).

f. This assignedEntity SHALL contain exactly one [1..1] representedOrganization (CONF:2218-**).

i. This representedOrganization SHALL contain exactly one [1..1] name (CONF:2218-**).

Proposed Disposition: Sarah Gaunt: Not related(?). This template (US Realm Header (V2)) is not open for comment in this IG as it is "Published as part of Consolidated CDA Templates for Clinical Notes (US Realm) DSTU R2.1". Please make this comment on the comment page here: C-CDA R2.1 Comments Page


Comment Number: 12

Name: Justine Maxwell, TN Dept of Health

Item: Volume 2, Figure 27, page 104, Example for No Known Problems Section

Question: The example for No Known Problems Section (volume 2, Figure 27, page 104) has a templateID for “Problem Section with Coded Entries Optional” and “Problem Section with Coded Entries Required,” however the implementation guidance (volume 2, page 102) only has a conformance statement and cardinality indicator for one templateID. Is having two templateIDs in the example intentional or is this an error?

Existing wording:

1. Conforms to Problem Section (entries optional) (V3) template (identifier: urn:hl7ii:2.16.840.1.113883.10.20.22.2.5:2015-08-01). 2. MAY contain zero or one [0..1] @nullFlavor="NI" No information (CodeSystem: HL7NullFlavor urn:oid:2.16.840.1.113883.5.1008) (CONF:1198-32864). 3. SHALL contain exactly one [1..1] templateId (CONF:1198-9179) such that it a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.2.5.1" (CONF:1198-10441). b. SHALL contain exactly one [1..1] @extension="2015-08-01" (CONF:1198-32510).

Proposed Disposition: Sarah Gaunt: Not related(?). In answer to the question though, the statement "1. Conforms to Problem Section (entries optional) (V3) template (identifier: urn:hl7ii:2.16.840.1.113883.10.20.22.2.5:2015-08-01). " is why the example has the two ids. Because this template is based on the (entries optional) template, it also takes conformance statements from its parent template.

This template (Problem Section (entries required)(V3)) is not open for comment in this IG as it is "Published as part of Consolidated CDA Templates for Clinical Notes (US Realm) DSTU R2.1". If you feel there is still an issue with this template, please make this comment on the comment page here: C-CDA R2.1 Comments Page


Comment Number: 13

Name: HL7 Commenter

Item: Volume 2, 1.1.1.2, record Target (volume 2, page 21) in regards to Reported Age of the Patient

Existing Wording: 3. This patient SHALL contain exactly one [1..1] birthTime (CONF:1198-5298). a. SHALL be precise to year (CONF:1198-5299). b. SHOULD be precise to day (CONF:1198-5300).

For cases where information about newborn's time of birth needs to be captured.

c. MAY be precise to the minute (CONF:1198-32418).

Proposed wording/suggestion: In the recordTarget there is a data element for the patient’s birth time, however, the implementation guide does not include the “Reported Age” of the patient. Is this data element missing intentionally? Having reported age of the patient would be useful if birth time is not available. This has been modeled previously in death reporting. It might be helpful to consult with the authors of the CDA Vital Records Death Reporting Implementation Guide for details on how to report age as an observation.

Proposed Disposition: Sarah Gaunt (I am the primary author of the latest CDA VRDR IG (the one going to ballot right now)).

The template in the new VR Death Reporting IG is called "Age at Death" and is based on the C-CDA Age Observation template. Really, the only suggestion that this template be used when the date of birth isn't known is a sentence in the C-CDA Age Observation that states (about a related person not about the record target): "This Age Observation represents the subject's age at onset of an event or observation. The age of a relative in a Family History Observation at the time of that observation could also be inferred by comparing RelatedSubject/subject/birthTime with Observation/effectiveTime. However, a common scenario is that a patient will know the age of a relative when the relative had a certain condition or when the relative died, but will not know the actual year (e.g., "grandpa died of a heart attack at the age of 50"). Often times, neither precise dates nor ages are known (e.g., "cousin died of congenital heart disease as an infant")."

Is there a reason this could be important to capture in the eICR, when the age could be derived from the date of birth (as birth year is required) and reported time (other than to align with Death Reporting)? Seems like this is just added work for implementers? Is this something that is captured in the EHR? Age Observation is not a required template in any C-CDA document type.

Comment Number: 14

Name: Justine Maxwell, TN Dept of Health

Item: Volume 2, Encounter Diagnosis (volume 2, page 127)

Existing Wording:

4. SHALL contain exactly one [1..1] code (CONF:1198-19182).

a. This code SHALL contain exactly one [1..1] @code="29308-4" Diagnosis (CONF:1198-19183).

b. This code SHALL contain exactly one [1..1] @codeSystem="2.16.840.1.113883.6.1" (CodeSystem: LOINC urn:oid:2.16.840.1.113883.6.1) (CONF:1198-32160).

5. SHALL contain at least one [1..*] entryRelationship (CONF:1198-14892) such that it

a. SHALL contain exactly one [1..1] @typeCode="SUBJ" (CodeSystem: HL7ActRelationshipType urn:oid:2.16.840.1.113883.5.1002 STATIC) (CONF:1198-14893).

b. SHALL contain exactly one [1..1] Problem Observation (V3) (identifier: urn:hl7ii:2.16.840.1.113883.10.20.22.4.4:2015-08-01) (CONF:1198-14898).

Question/suggestion:

The implementation guidance for the Encounter Diagnosis, does not have any conformance statements or cardinality indicators for statusCode or effectiveTime. However, the Encounter Diagnosis (V3) example (volume 2, Figure 33, page 128) includes a statusCode data element and an effectiveTime data element. Is this intentional that these two data elements are missing from the implementation guidance but are included in the example?

Proposed Disposition: Sarah Gaunt: Not related(?). I'm really not sure why these are not stated in the C-CDA template. It would seem to me that they should be and that this template should really follow the modeling of the Problem Concern Act (V2).

Unfortunately though - this template (Encounter Diagnosis (V3)) is not open for comment in this IG as it is "Published as part of Consolidated CDA Templates for Clinical Notes (US Realm) DSTU R2.1". Please make this comment on the comment page here: C-CDA R2.1 Comments Page


Comment Number: 15

Name: Justine Maxwell, TN Dept of Health

Item: Volume 1, page 64, Appendix C-Extensions to CDA –R2

In Appendix C it says the sdtc:deceasedInd is used to indicate if a family member is deceased. Should it also include in the table that the sdtc:deceasedInd is also can be used to indicate that the patient, in addition to a family member, in the recordTarget is deceased too? It looks like the sdtc:deceasedInd was added to the recordTarget in the conformance statement, but was not updated in this table. This also applies for deceasedTime.

Existing Wording:

The references to the extension for the deceasedInd are not consistent. In the Appendix C of volume 1 it is referenced in the table as the deceasedIndextension. The deceasedIndextension (= “true” or “false”) in the family history organizer on the related subject is used inside to indicate if a family member is deceased. Then in the recordtTarget on page 61, its referenced as sdtc:deceasedInd. This patient SHALL contain exactly one [1..1] sdtc:deceasedInd (CONF:3284-306).

Proposed wording/suggestion:

Be consistent with how extensions are referenced and documented throughout the text. We would suggest referencing this extension as always sdtc:deceasedInd. This could be a simple typo of a missing space in the table description. The deceasedInd extension (= “true” or “false”) in the family history organizer on the related subject is used inside to indicate if a family member is deceased.

Proposed disposition: Sarah Gaunt: Persuasive:

Will make all references consistent: "sdtc:decasedInd extension"

Will update table to say:

The deceasedInd extension is used to record that the recordTarget is deceased.

  • recordTarget/patientRole/patient

Will only show the use of the extension in this particular IG to remove any confusion about how it is used in the IG.

(Will also do the same for sdtc:deceasedTime)

Comment Number: 16

Name: Justine Maxwell, TN Dept of Health

Item: Volume 1, page 64, Appendix C-Extensions to CDA –R2

There seems to be a problem with consistency. In the Appendix C table from volume 1, the sdtc:deceasedInd is described as the extension for (= “true” or “false”) in the family history organizer on the related subject is used inside to indicate if a family member is deceased. However, in volume 2, on page 61, in the recordTarget, the same extension is listed for the patient. We couldn’t find any reference to this extension elsewhere in volume 2. So the use of this extension as described in volume 1 is not consistent with the conformance statements using this extension in volume 2. This also applies for deceasedTime.

Existing Wording:

The deceasedIndextension (= “true” or “false”) in the family history organizer on the related subject is used inside to indicate if a family member is deceased.

Proposed wording/suggestion:

The deceasedIndextension (= “true” or “false”) in the family history organizer on the related subject is used inside to indicate if a family member is deceased. This same extension is also used in the recordTarget. There should also probably be a conformance statement using this extension in the family history organizer of the related subject for the family member.

Proposed disposition: Sarah Gaunt: Persuasive with mod: The family history organizer is not used in this IG. There should be no reference to it the discussion of the extension.

Will update table to say:

The deceasedInd extension is used to record that the recordTarget is deceased.

  • recordTarget/patientRole/patient

Will only show the use of the extension in this particular IG to remove any confusion about how it is used in the IG.

(Will also do the same for sdtc:deceasedTime)

Comment Number: 17

Name: Justine Maxwell, TN Dept of Health

Item: Volume 1, page 64, Appendix C-Extensions to CDA –R2

Question:

The sdtc:raceCode in the table in Appendix C of volume 1 says that the extension should only be under the patient. However, the sdtc:ethnicGroupCode is listed as falling under the record target or subjectPerson. Why the difference? Is this correct?

Proposed disposition: Sarah Gaunt: The raceCode one is old wording, this was changed in 2014.

Will update them both to be the same, but will only mention the use of the extension in recordTarget as subjectPerson isn't in the eICR IG.

Comment Number: 18

Name: Justine Maxwell, TN Dept of Health

Item: Volume 1, Table 10, page 56-Mapping of Data Elements to Data Model

Question:

In Table 10, the class attribute name for the “Date of Diagnosis” data element is effectiveDate. Is this intentional or should it be effectiveTime? In volume 2, effectiveTime is used.

Proposed disposition: Sarah Gaunt: Persuasive with mod: This is intentional - this is a mapping to the eICR data model, not a mapping to the CDA model.

The heading to the section (and subsequent related sections) isn't clear and the introductory wording is wrong though: "The following table maps data elements identified by the CSTE task force to the CCDA class names and class attribute names used in the eICR."

Will change to: 6.4 Mapping of Data Elements to eICR Data Model The following table maps data elements identified by the CSTE task force to the iICR Data Model classes and attributes used in the eICR.

Will also change:

  • "6.4 Mapping of Data Elements to eICR Data Model" to "6.4 Mapping of CSTE Identified Data Elements to eICR Data Model"
  • "6.5 eICR Template Hierarchy" to "6.5 eICR CDA Template Hierarchy"
  • "6.6 Mapping of Data Elements to CDA R2 Templates" to "6.6 Mapping of CSTE Identified Data Elements to CDA R2 Templates"

to make sure that it is very clear what is being referred to in each of these sections.

Comment Number: 19

Name: Justine Maxwell, TN Dept of Health

Item: Volume 1, Figure 24, page 52-eICR Data Model

Question:

In Figure 24 (eICR Data Model), the Encounter Diagnosis box includes effectiveDate. Is this intentional or should it the effectiveTime data element? In volume 2, effectiveTime is used.

Proposed disposition: Sarah Gaunt: Persuasive with mod: This will be the same disposition as outlined in Comment Number 18.

Comment Number: 20

Name: Sarah Gaunt

Item: Pregnancy Observation

Existing wording: Re comment: STU Comment 1067 that has been disposed as persuasive.

Proposed wording: Pregnancy template will be added with additional guidance - remove guidance re pregnancy in Social History.

Recording here for completeness: Sarah Gaunt: Will update eICR template as disposed in above comment

Comment Number: 21

Name: Sarah Gaunt

Item: ServiceDeliveryLocationRoleType

Existing wording: Re comment: STU Comment 1234 that has been disposed as persuasive with mod. "Question whether the targeted information has left out key data elements that would be unique to a medical entity within a Correctional facility. Facility Type should include correctional facility type."

Proposed wording: This value set (ServiceDeliveryLocationRoleType) doesn’t contain a code suitable to represent Correction Facility. Language will be added to the IG to clarify: "Please note, however, that the binding to this value set is only SHOULD, so it would be possible to use another code here (such as 257656006 Correctional Facility: SNOMED) as long as the code system is a recognized one.

Recording here for completeness: Sarah Gaunt: Will update eICR IG with wording to clarify and suggest the use of the SNOMED code above.

Comment Number: 22

Name: George Cole

Item: Volume 2: Figure 17: eICR recordTarget Example

Existing wording: ... <languageCommunication> <languageCode code="eng" /> <XMLcomment "eng" is ISO 639-2 alpha-3 code for "English" XMLcomment> ...

Proposed wording: <languageCommunication> <languageCode code="en" /> <XMLcomment C-CDA R2.1 STU Comment 806 resolution calls for use of 2 character codes when they exist XMLcomment> Reason for proposal: For C-CDA R2.1, SDWG will bind the DYNAMIC value set to RFC 5646.

Additionally: the example xml file, CDAR2_IG_PHCASERPT_R2_D1.1_Sample.xml, should be changed

Proposed disposition: Sarah Gaunt: Persuasive. Will update example and sample file as suggested.

Comment Number: 23

Name: Riki Merrick, APHL

Item: Volume 1: page 12 - There seems to be part of the sentence missing:

Existing wording: Chapter 6— eICR Data Requirements. This section describes CSTE

Proposed wording: Please compete the sentence or paragraph

Proposed disposition: Persuasive. Will complete sentence: "This section describes the CSTE identified data elements, illustrates the eICR data model and the related CDA template hierarchy. It also provides mappings between the CSTE identified data elements and both the eICR data model and the CDA template hierarchy."

Comment Number: 24

Name: Riki Merrick, APHL

Item: Volume 1: page 40 - "in the" is doubled up

Existing wording: There is a discrepancy between the HL7 R1 Data Types and this guide in the in the implementation of translation code versus the original code.

Proposed wording: There is a discrepancy between the HL7 R1 Data Types and this guide in the implementation of translation code versus the original code.

Proposed disposition: Sarah Gaunt: Persuasive. Will remove repeated words.

Comment Number: 25

Name: George Cole

Item: Volume 2, Section 1.1.3.1 recordTarget

Existing wording: Although "county" is not explicitly specified in the US Realm Address, it is not precluded from use and for the purposes of this IG it is recommended to be included. See the eICR recordTarget example following this section for further details

Proposed wording: (remove this and remove comment from example file and from Figure 17)

Reason for proposal: I believe that county is derivable from zip code, so no need to ask for this to be collected and added to eiCR content. I believe that this is not currently collected by patient management nor EHR nor acute systems (when was the last time anyone filled in an address on a form that asked for county?)

Comment Number: 26

Name: John Stamm

Item: Volume 2: 4

Existing wording: Vol 2, item 4 in the table of contents is called “UNSPECIFIED”

Proposed wording: Should this be something other than "Unspecified"?

Proposed disposition: Sarah Gaunt: Persuasive: Indeed it should - it should be "Participation and Other Templates" - will fix.

Comment Number: 27

Name: John Stamm

Item: Volume 1: page 46

Existing wording: This lists the templates, and the labels are not consistent. The last one is called “Trigger Code Lab Test Order” and the others all start with “Initial Case Report Trigger Code”. It’s also missing a bullet.

Proposed wording: Make labels consistent and fix the bullet.

Proposed disposition: Sarah Gaunt: Persuasive with mod: The whole name of the template is actually there - it's just up on the line above. Will add carriage return between the line above and the name the of template which will fix both the name and missing bullet issue.

Comment Number: 28

Name: John Stamm

Item: General

Existing wording: Most HL7 specs have a section that lists all entries. For whatever reason, it seems like all five new templates here (three for trigger codes, birth sex, travel history) all link back to sections, but those sections *are not* listed as including those templates. This is mostly a hassle because it makes cardinalities unclear. How many trigger codes should be includee in one section if there is no cardinality?

Proposed wording: Link to the template in the sections instead of (or in addition to) linking to the section in the template.

Proposed disposition: Sarah Gaunt: Persuasive with mod.

This is Structured Document's new way of adding templates to an IG to lessen burden on implementers and standards authors. This was kind of started back in C-CDA R2.0 when the Author Participation template was added and included this note in its description:

Although it is not explicitly stated in all templates the Author Participation template can be used in any template.

This is how templates will be added to C-CDA going forward (See the Consolidated CDA Templates for Clinical Notes; Additional Templates IG that is going to ballot for January). Also: see Volume 1, Section 5.2 Stand-Alone Templates in the eICR IG for further details.

Basically, the templates can be used anywhere (due to the openness of the majority of templates in C-CDA - and most CDA templates), and the child (contained template) knows about its parent (containing template), but the parent doesn't know about the child. Any description of where the template can be used is contained in the description of the template. This means that every single template all the way up the hierarchy doesn't need to be versioned each time a new template is added to an IG (and in future, every time these "stand-alone" templates are versioned).

If we hadn't followed this approach, in the case of this eICR IG we would also have needed to create the following new templates to accommodate the 5 new templates (these templates would have been copies of the original templates with just a contains relationship for the new templates):

  • eICR Plan of Treatment Section
  • eICR Encounter Diagnosis
  • eICR Encounter Activity
  • eICR Encounters Section
  • eICR Problem Concern Act
  • eICR Problem Section (entries optional)
  • eICR Result Organizer
  • eICR Results Section (entries required)
  • eICR Social History Section

You are correct though - there is nothing in the new templates about cardinality. Just (for e.g.)

This template is for optional use in the Plan of Treatment Section (V2) contained in an Initial Public Health Case Report Document (eICR) (V2).

Will change all these statements to more clearly specify optionality and cardinality:

This template is designed for optional use in the Plan of Treatment Section (V2) contained in an Initial Public Health Case Report Document (eICR) (V2). This template MAY be included zero or more times [0..*] in the Plan of Treatment Section (V2).

This will apply to the following templates:

  • Initial Case Report Trigger Code Problem Observation (MAY [0..*])
  • Initial Case Report Trigger Code Result Observation (MAY [0..*])
  • Initial Case Report Trigger Code Lab Test Order (MAY [0..*])
  • Travel History (MAY [0..*])
  • Birth Sex (SHALL [1..1])


Comment Number: 29

Name: John Stamm

Item: Volume 2: Section 3.14

Existing wording: Inclusion of Travel history.

Proposed wording: It’s unclear to me how far in the past or how many entries are expected for travel history, partially because of the Editorial/cardinality issue.

Proposed disposition: Sarah Gaunt: Persuasive with mod(?)/Question answered(?). Will update cardinality as stated in Comment Number 28 (MAY [0..*]). We have not indicated how far in the past travel history should be collected, as presumably this would be left to the clinical judgement of the provider, who would make a determination based on the condition/situation being assessed.

Comment Number: 30

Name: John Stamm

Item: Volume 2

Existing wording:

Proposed wording: I may have missed it because of the Editorial/cardinality issue, but it seems like they aren’t clear how many conditions you can include in a single eICR. It would be easy for us to identify three trigger codes in one document (a lab test order, and two problems for example). This is likely to send three messages if tripped in real time (one with the order, one with the order and a problem and one with all three). Additionally, if they proceed as they’re talking for the Reportability Response (fka Notice of Reportability), we’ll be spammed back with the need to manually fill in more forms for the same patient over and over. That seems suboptimal for everyone.

Proposed answer: John Loonsk: Question answered. There may be more than one trigger code type and more than one trigger code of each type in an eICR CDA Document.

Some aspects of triggering will be worked though in prototypes that are being developed, but an attractive approach involves having EHR vendors do eICR transmission at some specific points in time having accumulated data and trigger codes up to those points and hence not “tripping” on each code individually. There are other positive aspects of this approach as it can enable more data accumulation before an eICR document is sent. It would reduce the quantity of eICR documents that are transmitted.

Even when there are multiple eICRs, we agree with the commenter that the number of Reportabilty Responses should be limited to only those that are necessary and actionable. Having multiple trigger codes in an eICR will allow for multiple conditions and jurisdiction reporting actions to be listed in a single Reportabilty Response. But, what is more, additional Reportabilty Responses should not be sent for any given condition unless its reportability status has changed. We are targeting inclusion of the data necessary for the latter in the Reportabilty Response document modeling.

Retrieved from "https://wiki.hl7.org/w/index.php?title=PHCR_eICR_R2_STU1.1_Update_Comments&oldid=129853"