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

This comment list is closed as of 5pm ET on Nov 7, 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.

Comments from Benjamin Flessner

Done: 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" />

Proposed change: create a primitive stating either @value or low SHALL be present.

SG: Fixed. Wrote some Schematron for the primitive and also the effective time (the branch stuff ended up broken because of the way we are specifying these constraints). This is what it looks like now: http://screencast.com/t/Lq3lt15Q9

Done: Race Code ValueSet

Comment 592 (flessner). RaceCategory and Race were differentiated into two separate value sets, 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.

Proposed change: bind raceCode to FHIM_RaceCategory (2.16.840.1.113883.3.2074.1.1.3) (hand typed OID, please double check).

SG: Have bound recordTarget/raceCode (the only one in the IG) to 2.16.840.1.113883.3.2074.1.1.3 (This was already in Trifolia and is called "Race Category Excluding Nulls"). The constraint: http://screencast.com/t/rh4LhqShg and the value set: http://screencast.com/t/ngbvpBXRBx

Done: 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.

Proposed change: Sarah Gaunt already fixed this one.

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

Proposed change: Sarah will move BMI up in the value set in Trifolia so it appears in the example table.

SG: Done: http://screencast.com/t/XD3S4oYM

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

Proposed resolution: will leave for now because the ballot disposition is implemented as written, but will consider discussing further since several people think the disposition was wrong.

Done - 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 http://unitsofmeasure.org/ucum.html

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 89: Fixed - Added link

Proposed resolution: Sarah fixed some, is good enough now.

Done: Bad Examples in the IG

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" displayName="Primary Care Provider" codeSystem="2.16.840.1.113883.5.88" codeSystemName="ParticipationFunction">...

Proposed resolution: Sarah will fix.

SG: Fixed in both examples.

Closed - 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 1.1.2.1). In any case, this is a tooling issue.

RG Proposed resolution: changes to tooling should be brought up with the publishing committee and moved into the publishing criteria if deemed appropriate. Publishing committee should review all such comments in the ballot and hold an open meeting soon.

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.

Closed: 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.

Proposed:

• 1 DOCUMENT-LEVEL TEMPLATES
• 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

RG Proposed resolution: changes to tooling should be brought up with the publishing committee and moved into the publishing criteria if deemed appropriate. Publishing committee should review all such comments in the ballot and hold an open meeting soon.

Closed - Comments 933, 934: (marked as not related)

Relating to Vol 2, Chapter 1 1.1.1.6 informant 1.1.1.7 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.

RG Proposed resolution: changes to tooling should be brought up with the publishing committee and moved into the publishing criteria if deemed appropriate. Publishing committee should review all such comments in the ballot and hold an open meeting soon.

Closed - Vol 2 Section 1.1.3.5 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.

Closed - placement and numbering of Figure 14 and Figure 15

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

However, Figure 15 documentationOf Example should have been in section 1.1.1.14.

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

RG Proposed resolution: changes to tooling should be brought up with the publishing committee and moved into the publishing criteria if deemed appropriate. Publishing committee should review all such comments in the ballot and hold an open meeting soon.

Done: 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:1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1) with a Chief Complaint and Reason for Visit Section (templateId:2.16.840.1.113883.10.20.22.2.13) (CONF:1098-28940).

Proposed: xxviii. SHALL NOT include both a Chief Complaint Section (templateId:1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1) and a Chief Complaint and Reason for Visit Section (templateId:2.16.840.1.113883.10.20.22.2.13) (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)

RG Proposed resolution: Sarah will fix as a typo.

SG: Standardized as follows (in Transfer Summary, Care Plan, Discharge Summary, History and Physical, Procedure Note, Progress Note, Transfer Summary) :

This structuredBody *SHALL NOT* contain an Assessment and Plan Section (V2) (2.16.840.1.113883.10.20.22.2.9:2014-06-09) when either an Assessment Section (2.16.840.1.113883.10.20.22.2.8) or a Plan of Treatment Section (V2) (2.16.840.1.113883.10.20.22.2.10:2014-06-09) is present.

This structuredBody *SHALL NOT* contain a Chief Complaint and Reason for Visit Section (2.16.840.1.113883.10.20.22.2.13) when either a Chief Complaint Section (1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1) or a Reason for Visit Section (2.16.840.1.113883.10.20.22.2.12) is present

This structuredBody *SHALL* contain either an Assessment and Plan Section (V2) (2.16.840.1.113883.10.20.22.2.9:2014-06-09), or an Assessment Section (2.16.840.1.113883.10.20.22.2.8) and a Plan of Treatment Section (V2) (2.16.840.1.113883.10.20.22.2.10:2014-06-09).

This structuredBody *SHALL* contain a Chief Complaint and Reason for Visit Section (2.16.840.1.113883.10.20.22.2.13) or a Chief Complaint Section (1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1) or a Reason for Visit Section (2.16.840.1.113883.10.20.22.2.12)

This structuredBody *SHALL* contain an Assessment and Plan Section (V2) (2.16.840.1.113883.10.20.22.2.9:2014-06-09), or an Assessment Section (2.16.840.1.113883.10.20.22.2.8) and a Plan of Treatment Section (V2) (2.16.840.1.113883.10.20.22.2.10:2014-06-09)

Vocabularly and Values

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

RG Proposed Resolution: Ballot comment disposition seems to be implemented correctly. No change required.

Closed - 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. http://search.loinc.org/search.zul?query=transfer+summary+note
• 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 www.loinc.org, 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

Done (pending SD clarification as stated below): 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.

RG Proposed Resolution: Change "New and versioned" to "Versioned..." in volume 1. Rick will clarify with SDWG that this was the intended disposition and formally close the ballot comment if not done so previously.

SG: Removed "New and" from the sentence in Volume 1 (Section 4.2.1)

Comments from David Tao

Done: 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.11.20.9.38 (same as in CCDA 1.1) but that the Value Set Source is http://vtsl.vetmed.vt.edu/ (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 http://vtsl.vetmed.vt.edu/ 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

SG: Sean has done a S&D in the value set "source url" field and replaced "http://vtsl.vetmed.vt.edu/" with "https://vsac.nlm.nih.gov" as decided on call. There are still some links to vtsl.vetmed.vt.edu where it points to a specific hierarchy and not just the main SNOMED browser. (e.g.: http://vtsl.vetmed.vt.edu/TerminologyMgt/RF2Browser/ISA.cfm?SCT_ConceptID=308335008 )

Done: 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)

Done - Comment 972: Advance Directives

Doesn't say remove organizer from entries optional template

RG Proposed resolution: Sarah will add the organizer back in.

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

Response: (bam) all fixed

Done - Comment 65: Tobacco Use

2.16.840.1.113883.11.20.9.41 missing DYNAMIC definition

Response: Note sent to Russ (person working on DYNAMIC definitions)

SG: This value set does not have an intensional definition (dynamic valuesets do not have to be intensional). I will see if I can find a description for this value set... (MU)

RG: Proposed resolution: Sarah will add something like "all codes in the SNOMED hierarchy under "tobacco use and exposure".

Closed - Comment: 228: Hospital Consultations Not Done

Response: Sarah Gaunt stated this was intentional - a future SDWG vote marked this comment unrelated.

Rick - please reload spreadsheet to HL7 site with this update

SG: To clarify - the reason this was not done and is unrelated is because "Hospital Consulations Section" is an already published template and thus was not open to be commented on in this ballot.

RG: Correct, this was reopened and marked unrelated. Will post final spreadsheet shortly.

Comments Larry Garber

Done - 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?

Proposed resolution: Larry says Sarah's fix was ok.

Comments from Gaby Jewell

Done - 3.3.1.7 DIR documentationOf

make language clear that the DIR document type may have multiple documentationOf elements, each of which must meet the additional requirements. If this is an issue with the way the IG is written in general, then reword all such statements. there is no way a rational reader expects to be allowed to include multiple documentationOf elements when the requirements state "exactly one". If this requirement means that there may be additional documentationOf elements, do they not need to contain exactly one serviceEvent? The base CDA R2 standard allows exactly one [1..1] serviceEvent elements. It is very confusing to have the same constraint language mean two different things.

8. SHALL contain exactly one [1..1] documentationOf (CONF:8416) such that it a. SHALL contain exactly one [1..1] serviceEvent (CONF:8431).

Keith made a comment on the list serve that only the CCD had a [1..1] constraint on the documentationOf element. the only difference is the 'such that it' language. Again, if this phrase means we can have multiple documentationOf elements, then it also implies that other documentationOf elements are not constrained in any other way. but this contradicts the description of the documentationOf element for the DIR document type:

"Each documentationOf/serviceEvent indicates an imaging procedure that the provider describes and interprets in the content of the DIR."

RG - Proposed Resolution: Will make serviceEvent a branch root to make it clear you can have other documentationOf elements where serviceEvent has a different classCode from ACT.