This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Consolidated CDA R2 DSTU, Oct 2014 version, final pre-publication QA comments"

From HL7Wiki
Jump to navigation Jump to search
Line 91: Line 91:
'''''SG''': Removed as suggested.''
'''''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.
== Vocabularly and Values ==
== Vocabularly and Values ==

Revision as of 13:04, 5 November 2014

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).

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

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.

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.