This wiki has undergone a migration to Confluence found Here

Consolidated CDA R2 DSTU, Oct 2014 version, final pre-publication QA comments

From HL7Wiki
Jump to navigation Jump to search

Please post any QA comments to this page so they can be tracked and reviewed. Comments sent via email to the listserv or individual co-chairs may be missed. Please include your name so that we may contact you if there are questions.

There is also a Doodle poll with proposed times for reviewing comments. If you post a comment, please also respond to the poll to show what times you are available to review your comments.

Comments from Benjamin Flessner

Medication Timing

Comment 155 (flessner). The guide has no indication of the single-administration timestamp model and as such, is back to the 1.1 version's problem of being unable to convey this information. Now, I know the "xsi:type='TS'" approach doesn't work because "TS" is not a valid specialization of "SXCM_TS," but the following example schema-validates just fine and continues to convey the intended information of a "single-administration" timestamp which was vetted by Structured Docs and Pharmacy.

<effectiveTime value="20141103142615+0500" />

Race Code ValueSet

Comment 592 (flessner). RaceCategory and Race were differentiated into two separate code systems, but the MU2 list explicitly excluded 2131-1:Other Race as an allowed code. If this ValueSet was created to mimic the requirements of MU2, then this code should be stricken from the ValueSet.

Vital Signs

Comment 103 (flessner) Vital Signs Observation interpretationCode (CONF 1098-7307) should have the same ValueSet conformance as Result Observation interpretationCode (CONF 1098-32476)

SG: Comment 103 specifically said to fix CONF:7147 and the valueSet binding was added to that element. Looks like there was some confusion as to the section/template this comment referred to. Makes sense to align the two templates. Have now also bound 7307 to the same value set.

Comment 104 (flessner) (missing examples). This is less serious, but C-CDAR1.1 included LOINC codes for BMI and BSA. It would be helpful to keep these in the R2 document, especially since BMI is required by MU2. (And also because the voc.xml file distributed with the publication does not actually contain this ValueSet at all...)

SG: This is a tooling issue. Only the first 10 values get printed out in the IG. (We are working on the ability to set this number individually by IG/valueSet but for now it is set the same for all). The "..." at the end of the table indicates that this is not a complete print out of the value set. The value set does not get exported in voc.xml as the binding to this value set is dynamic and thus do not get checked by Schematron. We could possibly force BMI and BSA to show up by manually changing the order of the table (but then two of the currently displayed values would disappear).

flessner: I vote pulling BMI up and dropping Height (Lying). That way at least the core MU2 vitals codes are present in the guide (especially since the ValueSet only links to LOINC).

Mis-aligned serviceEvent/performer functionCode

In US Realm header, functionCode SHOULD be selected from ParticipationFunction (1098-16819) and assignedEntity/code SHOULD be selected from Healthcare Provider Taxonomy (HIPAA) (1098-14842). This pattern is repeated in several other templates (namely, that Healthcare Provider Taxonomy goes in assignedEntity/code).

In Transfer Summary, however, it says functionCode SHOULD be selected from Healthcare Provider Taxonomy (1098-32651). This seems like a clear error, since everywhere else functionCode is... ParticipationFunction.

SG: Think this was added due to this dispo from comment 1011:

Will add additional explantion covering: 1) Pre-coordinated document codes are those that indicate the specialty or service provided in the LONG_COMMON_NAME. We will be changing all display/print names where using LOINC to the LONG_COMMON_NAME 2) We will clarify that when using a generic type of code such as 18761-7 Provider-unspecified Transfer summary, and there is a desire to know the types of services and providers involved in the care, this specialization/specification is handled in documentationOf/serviceEvent and with the use of serviceEvent code (example: using a snomed procedure code such as "69031006 excision of breast tissue (procedure)" and performer(s) can be identified with functionCode and binding to NUCC roleCodes 3)Will add conformace statements to the transfer notes serviceEvent and performer to reflect the above.

(an aside, CONF 1098-16819 is clearly incorrect as it's constraining @codeSystem instead of @code...or rather just functionCode itself. Reported as DSTU comment 546)

Missing Hyperlinks

Incredibly minor, but I did post these as ballot comments originally... (flessner)

Comment 11 – new CONF 1098-31484 – missing hyperlink to ValueSet

Comment 333 – new CONF 1098-8559 – missing hyperlink to ValueSet

Comment 89 – UnitsOfMeasureCaseSensitive is still missing the hyperlink to

SG: Comment 11, 333: Comment was to change the value set from UCOM to UnitsOfMeasureCareSensitive. This has been done. There is no hyperlink because this constraint is a primitive (due to the "IF") and thus far the tooling does not allow a document hyperlink to be placed in a primitive constraint.

SG: Comment 333: Fixed - Added link

Bad Samples

PCP sample needs to be updated in Figures 14 and 26.

Incorrect: <functionCode code="PP" displayName="Primary Performer" codeSystem="2.16.840.1.113883.12.443" codeSystemName="Provider Role">...

Correct: <functionCode code="PCP" codeSystem="2.16.840.1.113883.5.88" codeSystemName="ParticipationFunction" displayName="Primary Care Provider">...

Comment from Harry Solomon (sent to SDWG listserv)

The section numbering in Volume 2 is all screwed up.

  • 1.1.2 should be 1.2
  • 1.1.3 should be 1.2.1
  • 1.1.4 should be 1.3
  • 1.1.5 should be 1.3.1
  • 1.1.6 should be 1.4
  • 1.1.7 should be 1.4.1
  • 1.1.8 should be 1.5
  • 1.1.9 should be 1.5.1
  • etc.

SG: The way the templates are exported is hierarchically. So US Realm Header is the top level template (1.1). Care Plan "implies" (or is a child of) US Realm Header, thus its numbering is 1.1.2. (If anything 1.1.3 should probably be In any case, this is a tooling issue.

Comments from George Cole, Emma Jones

Typos and Content Display Issues

Thank you - many comments with a disposition of Not Related, referred to Tooling, were actually resolved and this greatly improved readability.

Comment 939 (marked as not related) but goes straight to document readability

Relating to Vol 2, Chapter 1

Our comment remains: the outlining of this entire section is wrong. Documents should not be children of U.S. Realm Header, and properties of documents should be children of the documents instead of siblings in the outline.

Yes, perhaps many of these issues are Tooling problems, but they still must be fixed in order to present a more professional and consistent publication.


  • 1.1 US Realm Header (V2) - Draft
  • 1.1.1 Properties
  • 1.2 Care Plan - Draft
  • 1.2.1 Properties
  • 1.3 Consultation Note (V2) - Draft
  • 1.3.1 Properties
  • ...

also note: the table of contents should not be in the document navigation showing Headings - Word currently includes this all under the Header of October 30; afraid this will impact PDF navigation

Comments 933, 934: (marked as not related)

Relating to Vol 2, Chapter 1 informant informant

Issue: confusing to see two sections named the same

Proposed: Suggest rewrite in manner similar to author, which in one section covers person and device authors….for informant we need to cover healthcare provider and non-provider.

Vol 2 Section still has what looks like extraneous test.

Issue: 10. SHALL contain exactly one [1..1] documentationOf (CONF:1098-31901) such that it Note: serviceEvent

Proposed: remove line feed following the word it, as well as the phrase Note: serviceEvent

SG: Removed as suggested.

placement and numbering of Figure 14 and Figure 15

Issue: Figure 14: performer Example looks to be in the correct location inside section

However, Figure 15 documentationOf Example should have been in section

Proposed: move Figure 15 documentationOf Example into section and then renumber both Figures 14 and 15.

Care Plan constraints on Chief Complaint wording

minor issue, but addition of the word "both" into the following would really help, and make it read similar to the constraint that follows

Current: xxviii. SHALL NOT include a Chief Complaint Section (templateId: with a Chief Complaint and Reason for Visit Section (templateId:2.16.840.1.113883. (CONF:1098-28940).

Proposed: xxviii. SHALL NOT include both a Chief Complaint Section (templateId: with a Chief Complaint and Reason for Visit Section (templateId:2.16.840.1.113883. (CONF:1098-28940).

(of course, now that we write this we see that the wording on xxvii, xxviii and xxvix would benefit from using the same pattern, so suggest using the SHALL NOT ... both .... AND .... pattern used in xxix)

Vocabularly and Values

Comment 987 (persuasive with mod)

about Healthcare Provider Taxonomy, CONF:1098-16788), and others...

Issue: There is no additional guidance in guide on how to narrow this value set.

Table 18 gives a URL, but are we to believe that the entire set of ~ 800 values is to be used?

The disposition comments says: The NUCC codes (aka healthcare provider taxonomy codes) are the codes for providers used since 2008 in CDA guides. Will continue to use for now.

However, that's not really useful to narrow this down.

Comment 1012 (persuasive with mod)

Transfer Summary, Table 56: TransferDocumentType

Request: Please provide the parent code for this code set so we can identify the codes that below to this set. Currently unable to identify the rest of the possible codes that belong in this set. Will the Specific URL provide this?

Resolution Comment:

Will add to value set description:

  • All LOINC codes whose Component = Transfer Summary Note* and SCALE_TYPE = Doc
  • There currently is no hierrachy easily accesable
  • However, this link appears to lead to the proper set of codes via the LOINC web browser.
  • We will add the link.
  • Additionally, for future use - if VSAC adds this value set we will provide a link in a future release
  • *Note that the LOINC component name has changed from Transfer Suumarization Note to Transfer Summary Note

Issue: No additional content was provided to help identify the set of codes for Table 56: TransferDocumentType, and the Value Set Source is just, which is not useful.

SG: Apologies - for some reason the last two comments (1012 and 1013) didn't get loaded into JIRA. Added the link and fixed value set description.

Template Versioning

Comment 931 (George Cole), and maybe even Keith's comment

see section 4.2.1 where is says ..."New and versioned templates also have an @extension value, which is a date identifying the version of this template;"...

Issue: there are no @extension values for new templates

Proposed: add @extension values to the new, Draft, templates for consistency across the set of templates as well as consistency with the text in 4.2.1

SG: I understood not adding the extension to new templates to be a SD decision (made at the same time as the choice of using 2014-06-09 was made). (Could always remove "new and" from the prose?) Though it would be nice to have consistency across all templates, agreed.

Comments from David Tao

Erroneous links to value set source

I was checking out one of my previous comments about smoking status and tobacco use, and decided I was OK with retracting my objection. However, I wanted to take a look at the value sets again, and noticed that the value set OID is 2.16.840.1.113883. (same as in CCDA 1.1) but that the Value Set Source is (which was not mentioned in CCDA 1.1).

So I went to that URL and was surprised to find that it is a Veterinary terminology services laboratory, and the web page talks about incorporating veterinary extensions to SNOMED-CT and defining veterinary-specific subsets of terminologies. I was also even more surprised to find listed as the "Value Set Source" for MANY value sets in CCDA 2.0. I did not see it mentioned at all in CCDA 1.1. It occurs 50 times in CCDA 2.0 volume 2.

Is it really correct to state that Veterinary Terminology Services Lab as the value set source for all those value sets, including very common ones such as Allergy/Adverse Event Type, Body Site, Encounter Planned, Goal Achievement, Current Smoking Status, Patient Education, Problem Status, etc.? Or is that a typo that somehow crept in through tooling, etc? Should it have referred to VSAC rather than VTSL?

In email conversations, both Rob McClure and Mark Roche felt that my comment is correct

Typo in Figure 194 in Volume 2

Figure 194 in volume 2 has a typo, "Suststance" which should be "Substance"

SG: Actually changed this to "Planned Medication Activity (V2) Example" which is the proper name for this example.

Comments Brett Marquard (Spot QA)

Comment 972: Advanced Directives

Doesn't say remove organizer from entries optional template

Comment 40: Healthcare Provider Taxonomy (HIPAA) 2.16.840.1.114222.4.11.1066 Binding

1098-17000 and 1098-16826 are STATIC. DYNAMIC everywhere else? 1098-32651 is missing binding 1098-32781 is to 2.16.840.1.113883.6.101 instead of NUCC.

Comment 65: Tobacco Use

2.16.840.1.113883. missing DYNAMIC definition

Comment: 228: Hospital Consultations Not Done

Comments Larry Garber

Comment 498: Goals

An Entry Reference needs to be added as an option to several templates so that goals can be linked to them: a. Problem Concern Act (Condition) (V2) (because this may be used in a Problem Section template) b. All of the templates within the Plan of Treatment Section (V2):

                                                              i.      Planned Act (V2)
                                                            ii.      Planned Encounter (V2)
                                                           iii.      Planned Immunization Activity (NEW)
                                                          iv.      Planned Medication Activity (V2)
                                                            v.      Planned Observation (V2)
                                                          vi.      Planned Procedure (V2)
                                                         vii.      Planned Supply (V2)
                                                       viii.      Handoff Communication (NEW)
                                                          ix.      Instruction (V2)
                                                            x.      Nutrition Recommendations (NEW)

SG: The original comment was as follows:

Currently, this template can be part of 3 other templates: Goals Section (NEW) (required) Intervention Act (NEW) (optional) Outcome Observation (NEW) (optional)

I think this leads to much confusion as to where to place Goals. I believe that the purpose of adding these 2 templates (besides the Goal Section) was to show that Goals can be linked to an Intervention or and Observation. Isn't there a way to do that without needing to repeat the Goal? Also related to this issue is the fact that the Goal Observation needs to also be part of the Transfer Summary, Referral Request and Consultation Note documents. I suggest that the Goals Section be made optionally available in those 3 document types in order to maintain consistency.

b. All of the templates within the Plan of Treatment Section (V2): i. Planned Act (V2) ii. Planned Encounter (V2) iii. Planned Immunization Activity (NEW) iv. Planned Medication Activity (V2) v. Planned Observation (V2) vi. Planned Procedure (V2) vii. Planned Supply (V2) viii. Handoff Communication (NEW) ix. Instruction (V2) x. Nutrition Recommendations (NEW)

The dispo was "Persuasive with mod":

a) Agreed, this template can be part of the other 3 templates.

Remove the reference to the actual Goal template to remove confusion and replace it with an Act Reference template with a note that this particular act reference is a goal. This will be done for all the sections in Care Plan - where there are references to templates that will be in other Care Plan sections, remove these references and replace with Act reference template with a note stating the specific type of template.

b) put Goal into Plan of Treatment section (I think it is meant to be there, it just wasn't put in)?. Remove moodCode of GOL from Planned Observation.

SG: The diposition changes have been made. For Care Plan all of the "Planned" templates are contained in the "Intervention Act" which has an Entry Reference that is specifically designed to point to a Goal. The Plan of Treatment Section contains an optional Goal Observation. The Entry Reference template can be used in any other template where needed. We have only specifically specified the Entry Reference template in the Care Plan templates. Do we really want to specify it anywhere it can be used? Not sure we can add them as they weren't part of the original disposition?