Skip to end of metadata
Go to start of metadata



To record your attendance at the SDWG Conference Call, click the sign-in button to the right:


Facilitator:

Austin Kreisler


Date:


Call Details:


 Click for Call Details

Zoom Information

https://us02web.zoom.us/j/465862913?pwd=cUllR1BndVpYNVpyR3dzc3VIUERTZz09

Meeting ID: 465 862 913

Passcode: 310940

Phone Information:

+1 312 626 6799 US (Chicago)
+1 929 436 2866 US (New York)
+1 301 715 8592 US (Germantown)
+1 346 248 7799 US (Houston)
+1 669 900 6833 US (San Jose)
+1 253 215 8782 US (Tacoma)
Find your local number: https://us02web.zoom.us/u/kb1hK2eKvz




Attendees:


 Click here to expand...

Meeting Attendance

To add your name to the attendance, exit Edit mode for this page and then click on the Submit button at the top of the page. Once you have submitted your attendance, the screen will indicate that you have already signed-in. Thank you!

Edit

Name

Name

Affiliation

E-mail

Owned By

Export Records: 0

Agenda:


10:00am EST

  1. Call to order 
    1. Call for Attendance


  2. Business Updates (10 min)
    1. Additions/modifications to the agenda
    2. Approve minutes from 2020-07-02 Agenda and Minutes

    3. HL7
  3. External Updates - ONC and others
  4. Project Updates
  5. Additional Items
    1. Block vote Example Task Force (Brett Marquard ) 
      1. Growth Charts
      2. Counseling Intervention
    2. Review the list of expiring STUs (30 mins)
    3. http://www.hl7.org/Special/committees/tsc/BallotManagement/Reports/ExpiredDSTUs_by_wgid.cfm?wg_id=33
  6. STU Comments

11:00am EST

  1. The Use of OIDs in Attachments - Russell Ott (10 min)
    1.  Attachments
      1. My understanding is that no solutions have been found in Linda’s FHIR work for conveying non-globally-unique identifiers in identifier datatype fields.
      2. The crux of the problem here is that we have established business practices where non-globally-unique “identifiers” (usually just a simple number) are in use, but we don’t have any clean method of including that type of data in CDA datatypes.
      3. There are two stopgap approaches the PIE Workgroup has considered that we’d like to consider:
      1. Utilize nullFlavor and assigningAuthorityName when communicating Attachment Control Numbers:

      e.g., <id nullFlavor="UNK" extension="1234567" assigningAuthorityName="AetnaACN">

      1. Issue a single OID that all payers/providers can use when referring to an Attachment Control Number to at least flag the number as an Attachment Control Number (yes, we know this breaks the concept of root + extension being globally unique):

      e.g., <id root=”1.2.3.4.5.6.7” extension="1234567">

  2. STU Comments - Nick Radov (25min) (Expand C-CDA Templates for Clinical Notes DSTU Release 2.1 - US Realm to find Nick's issues)
    1. STU Comments - HL7 CDA® R2 IG: C-CDA Templates for Clinical Notes DSTU Release 2.1 - US Realm
    2.  Click here to expand...

      STU

      Last Updated

      Commenter

      Issue

       

      2.61 Procedures Section (entries optional) (V2)
      2.61.1 Procedures Section (entries required) (V2)

      I think we have a discrepancy between the narrative text in these sections versus the formal constraints on the contained "Procedure Activity Procedure (V2)" entry template. The sections are only supposed to contain historical procedures which actually altered the patient's state. However the Value Set: ProcedureAct statusCode urn:oid:2.16.840.1.113883.11.20.9.22 includes concept codes for "aborted", "active", and "cancelled". If the procedure is still active then it isn't yet historical. If the procedure was aborted or cancelled then presumably it didn't alter the patient state.

      This is creating confusion among implementers. We have received documents from multiple EHRs containing procedure entries with statusCode/@code="active".

       

      Figure 161: Immunization Activity (V3) Example
      (page 550)

      <code code="33" codeSystem="2.16.840.1.113883.6.59" displayName="Pneumococcal polysaccharide vaccine" codeSystemName="CVX">

      Figure 224: Substance Administered Act Example
      (page 846)

      <code code="43" codeSystem="2.16.840.1.113883.6.59" displayName="Hepatitis B Vaccine" codeSystemName="CVX" />
      1942

       

      Comment Activity
      urn:oid:2.16.840.1.113883.10.20.22.4.64

      5. SHALL contain exactly one [1..1] text (CONF:81-9430).
      a. This text SHALL contain exactly one [1..1] reference (CONF:81-15967).
      i. This reference SHALL contain exactly one [1..1] @value (CONF:81-15968).
      1. This reference/@value SHALL begin with a '#' and SHALL point to its corresponding narrative (using the approach defined in CDA Release 2, section 4.3.5.1) (CONF:81-15969).
      b. This text SHALL contain exactly one [1..1] reference/@value (CONF:81-9431).

      The order of these conformance statement is confusing. It seems like 5.a.i would make more sense under 5.b
      1946

       

      Table 6 found on page 63 in CDAR2_IG_CCDA_CLINNOTES_R1_DSTU2.1_2015AUG_Vol2_2019JUNwith_errata.pdf has the following text:

      Table 6: Language Value Set: Language urn:oid:2.16.840.1.113883.1.11.11526

      A value set of codes defined by Internet RFC 5646. Use 2 character code if one exists. Use 3 character code if a 2 character code does not exist. Including type = region is allowed

      See http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
      Value Set Source: http://www.loc.gov/standards/iso639-2/php/code_list.php

      While the table states Including type = region is allowed - the value set source does not list any valid regions. Also, the two sample provided as follows need to be corrected:

      The Figure 1: US Realm Header (V3) Example shows <languageCode code="en-US" />
      which SHOULD be <languageCode code="en" />

      The Figure 2: recordTarget Example shows <languageCommunication> <languageCode code="eng" />
      which SHOULD be <languageCommunication> <languageCode code="en" /> because Table 6 (Page 63) states to use the 2 digit code if there is one.

      Lastly, this value set is not included in VSAC. Should it be?
      1945

       

      Encounter Diagnosis (V3)
      [act: identifier urn:hl7ii:2.16.840.1.113883.10.20.22.4.80:2015-08-01 (open)]

      This template wraps relevant problems or diagnoses at the close of a visit or that need to be followed after the visit. If the encounter is associated with a Hospital Discharge, the Hospital Discharge Diagnosis must be used. This entry requires at least one Problem Observation entry.

       

      1.1.1 Properties

      ...

      8. SHALL contain exactly one [1..1] confidentialityCode, which SHOULD be selected from ValueSet HL7 BasicConfidentialityKind urn:oid:2.16.840.1.113883.1.11.16926 STATIC (CONF:1198-5259).
      1885

       

      @sueann svabySHALL contain exactly one [1..1] code, which SHOULD be selected from ValueSet Social History Type urn:oid:2.16.840.1.113883.3.88.12.80.60 DYNAMIC (CONF:1198-8558).
      a. If @codeSystem is not LOINC, then this code SHALL contain at least one [1..*] translation, which SHOULD be selected from CodeSystem LOINC (urn:oid:2.16.840.1.113883.6.1) (CONF:1198-32951).
      1873

       

      Encounter Diagnosis (V3)
      [act: identifier urn:hl7ii:2.16.840.1.113883.10.20.22.4.80:2015-08-01 (open)]

      The template is missing a binding for statusCode.

      Figure 144 shows a statusCode of "active". This provides the wrong guidance.
      1859

       

      Please REMOVE/DEPRECATE this commentIn the errata release from June 2019,Figure 162 is wrong and needs to be updated to use the correct Code System OID for CVX 2.16.840.1.113762.1.4.1010.6. It currently shows as 2.16.840.1.113762.12.292
      1860

       

      In the errata release from June 2019,Figure 161 is wrong and needs to be updated to use the correct Code System OID for CVX "2.16.840.1.113883.12.292". It currently shows as 2.16.840.1.113762.6.59

       

      Care Plan (V2)
      [ClinicalDocument: identifier urn:hl7ii:2.16.840.1.113883.10.20.22.1.15:2015-08-01 (open)]

      The CDA Care Plan represents an instance of this dynamic Care Plan at a point in time. The CDA document itself is NOT dynamic.
      Key differentiators between a Care Plan CDA and CCD (another “snapshot in time” document): There are 2 required sections:
      o Health Concerns o Interventions
      There are 2 optional sections:
      o Goals o Outcomes

      • Provides the ability to identify patient and provider priorities with each act • Provides a header participant to indicate occurrences of Care Plan review A care plan document can include entry references from the information in these sections to the information (entries) in other sections.
      Please see Volume 1 of this guide to view a Care Plan Relationship diagram and story board.

       

      Section 1.1.17.4.iv doesn't include ICD-10-PCS as an allowed code system. It has now supplanted ICD-9 in the US realm.
      1802

       

      Smoking Status - Meaningful Use (V2) (urn:hl7ii:2.16.840.1.113883.10.20.22.4.78:2014-06-09)

      . This value SHALL contain exactly one [1..1] @code, which SHALL be selected from ValueSet Smoking Status urn:oid:2.16.840.1.113883.11.20.9.38 DYNAMIC (CONF:1098-14817).

      1800 

      1801

       

      We have trouble adding new Social History Observations when the US Gov't identifies the observation using LOINC. We really should be using LOINC in the code ("the question").

      I recommend creating a Grouping Value Set that combines the original set of concepts using SNOMEDCT (Social History Type (SNOMEDCT)) and then agree to put all new/additional social history observation codes in the Social History Type (LOINC) value set. Use the existing OID for the new Grouping VS and make two new value sets for the parts of the grouping VS.
      1798

       

      On page 392, Section 3.61.1, the last three sentences of the text read as follows:

      "Procedure act is for procedures that alter the physical condition of a patient (e.g., splenectomy). Observation act is for procedures that result in new information about a patient but do not cause physical alteration (e.g., EEG). Act is for all other types of procedures (e.g., dressing change)."

      This is different from the wording on page 390, Section 3.61 Procedures Section (entries optional) (V2). Updated language is in the proposed section below.

       

      Currently the Referral Note (V2) document type doesn't include a Payers section. We should add that as an optional section because sometimes the "Referred From" provider needs to tell the "Referred To" provider which insurance coverage the patient has. And in some cases the provider needs to route a copy of the document to the patient's insurance company so they also need a way to indicate which plan the patient is on (or at least which plan they believe the patient to be on).
      1793

      3.41 Immunization Medication Information (V2) includes SHALL have a manufactureMaterial where this code MAY contain zero or more [0..*] translation, which MAY be selected from ValueSet Vaccine Clinical Drug urn:oid:2.16.840.1.113762.1.4.1010.8 DYNAMIC (CONF:1098-31543).

       

      3.41 Immunization Medication Information (V2) includes SHALL have a manufactureMaterial where this code MAY contain zero or more [0..*] translation, which MAY be selected from ValueSet Vaccine Clinical Drug urn:oid:2.16.840.1.113762.1.4.1010.8 DYNAMIC (CONF:1098-31543).

       

      We have seen real-world implementation defects where planned future encounters appear in the Encounters section rather than the Plan of Treatment section where they should be. I think some developers are just querying their database encounter tables for all encounters for a particular patient and sticking everything in the Encounters section regardless of whether they are past or future. Let's introduce a new conformance rule to ensure each Encounter activity ends before the document header effectiveTime.

       

      In section 3.81 Procedure Activity Procedure (V2) the Procedure.code (CONF:1098-7656) doesn't mention HCPCS as a possible code system. I think that code system should be explicitly listed because it is in common use in the US realm along with CPT-4. There are many procedures which are in HCPCS but not in CPT-4.

      This @code SHOULD be selected from LOINC (CodeSystem: 2.16.840.1.113883.6.1) or SNOMED CT (CodeSystem: 2.16.840.1.113883.6.96), and MAY be selected from CPT-4 (CodeSystem: 2.16.840.1.113883.6.12) or ICD10 PCS (CodeSystem: 2.16.840.1.113883.6.4) or CDT-2 (Code System: 2.16.840.1.113883.6.13) (CONF:1098-19207).

       

      Section 3.23, page 483:

      Table 272: EncounterTypeCode
      Value Set: EncounterTypeCode urn:oid:2.16.840.1.113883.3.88.12.80.32
      This value set includes only the codes of the Current Procedure and Terminology designated for Evaluation and Management (99200 – 99607) (subscription to AMA Required
      Value Set Source: http://www.amacodingonline.com/

       

      <!-- ************************ ENCOUNTERS *********************** -->
      <component>
      <section>
      <!-- *** Encounters section (entries required) (V3) *** -->
      <templateId root="2.16.840.1.113883.10.20.22.2.22.1" extension="2015-08-01"/>
      <templateId root="2.16.840.1.113883.10.20.22.2.22.1"/>

      I think there is a problem with the sample CCD file C-CDA_R2-1_CCD.xml included in this package.

  1. STU Updates - Matt Szczepankiewicz(25min) (expand HL7 CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes Companion Guide, Release 2 STU - US Realm )
    1.  Click here to expand...

      STU

      Last Update

      Commenter

      Comment

      1983   

       

      Order fulfillment conformance statement that are contradictory

       

      Appendix C has a constraint with root, extension and NULL of UNK

       

      The Provenance entry in the Appendix C is inconsistent with the author entry in the C-CDAr2.1 IG in terms of allowable values and it is misleading.

       

      For the UDI information, can we get clarification on whether it is possible to send other information when we do not have the DI information?

       

      Appendix B UDI
      1.1 UDI Organizer 

      Figure 1: Unique Device Identifier (UDI) Organizer Template ID root is incorrect

       

      (Vocab issue)
      Table 9 of the Companion Guide recommends the LOINC codes 11502-2 for Laboratory Narrative notes and 11526-1 for Pathology Narrative notes. However, these codes aren't actually included in the Note Types value set (urn:oid:2.16.840.1.113883.11.20.9.68) as required by the Notes Section and Note Activity templates in Appendix A. Likewise, although no specific LOINC code is recommended for Imaging Narrative notes, the value set doesn't include any codes from the value set recommended for imaging notes in Table 8 (urn:oid:1.3.6.1.4.1.12009.10.2.5).

       

      In Appendix C, I read the Provenance - Author Participation template as saying you can use the same trick as in the standard C-CDA Author Participation template to reference an author already defined elsewhere in the document:

      The assignedAuthor/id may be set equal to (a pointer to) an id on a participant elsewhere in the document (header or entries) or a new author participant can be described here.

      That is, that it's okay to do this:

      <assignedAuthor>
      <id extension="1386639318" root="2.16.840.1.113883.4.6" />
      </assignedAuthor>

      assuming the document actually contains a full entry for the author with that id somewhere else.

      But when an author containing the Provenance - Author Participation templateId does this, it raises a handful of schematron errors that still enforce the SHALL constraint on the representedOrganization (CONF:4440-4 and children):

       

      The following unimplemented constraints use the expression "not(.)" throughout the main Companion Guide schematron file:

      CONF:3250-16902
      CONF:3250-16912
      CONF:3250-16914
      CONF:4435-133
      CONF:3250-16942

      Typically unimplemented constraints use a dummy expression like "not(tested)" that always returns false (since the current element doesn't have a child named "tested"), but in this case, we're asserting that the current node is null, which returns false, makes the assertion fail, and triggers a false positive schematron error.
  2.  Adjourn
    1. Next meeting:  

Notes/Minutes:


10:00am EST

  1. Call to order 
    1. Meeting called to order at 10:05am EST 
    2. Call for Attendance


  2. Business Updates (10 min)
    1. Additions/modifications to the agenda
    2. Approve minutes from 2020-07-02 Agenda and Minutes

      1. Approved by consensus
    3. HL7
  3. External Updates - ONC and others
  4. Project Updates
  5. Additional Items
    1. Block vote Example Task Force (Brett Marquard ) 
      1. Growth Charts
      2. Counseling Intervention
    2. Review the list of expiring STUs (30 mins)
      1. HL7 CDA® R2 Implementation Guide: Personal Advance Care Plan Document, Release 1 - US Realm
        1. Lisa R. Nelson is working on the final comment for STU R2 for this standard.
      2. HL7 FHIR® Profile: C-CDA, Release 1 - US Realm
        1. We need an extension created for this
      3. HL7 CDA® R2 Implementation Guide: Healthcare Associated Infection Reports, Release 3, STU 3 - US Realm
        1. This is in progress
      4. HL7 CDA® R2 Implementation Guide: C-CDA Supplemental Templates for Unique Device Identifier (UDI) for Implantable Medical Devices, Release 1 - US Realm
        1. It is a reference standard in the ONC. Marti Velezisis going to go see where it is referenced. It is referenced in the cert requirements for 2015 Edition. 
        2. In an STU Update, the release number changes.
        3. A small subset of that IG was in the companion guide and that is why we let it lapse.
        4. For the IG outside of the regulation, we can advance it.
        5. The scope is fine
        6. Is there an active project to cover this?
        7. Marti will get the project number for that.
      5. HL7 Version 3 Implementation Guide for CDA Release 2 - Level 3: Emergency Medical Services; Patient Care Report, Release 2 - US Realm
        1. This will lapse 2021-06-15. We believe it is Emergency Care/Patient Care. We need to follow up and see if someone is tracking against it.
        2. CDA Management Group will follow-up.
    3. http://www.hl7.org/Special/committees/tsc/BallotManagement/Reports/ExpiredDSTUs_by_wgid.cfm?wg_id=33
  6. STU Comments

11:00am EST

  1. The Use of OIDs in Attachments - Russell Ott (10 min)
    1.  Attachments
      1. My understanding is that no solutions have been found in Linda’s FHIR work for conveying non-globally-unique identifiers in identifier datatype fields.
      2. The crux of the problem here is that we have established business practices where non-globally-unique “identifiers” (usually just a simple number) are in use, but we don’t have any clean method of including that type of data in CDA datatypes.
      3. There are two stopgap approaches the PIE Workgroup has considered that we’d like to consider:
      1. Utilize nullFlavor and assigningAuthorityName when communicating Attachment Control Numbers:

      e.g., <id nullFlavor="UNK" extension="1234567" assigningAuthorityName="AetnaACN">

      1. Issue a single OID that all payers/providers can use when referring to an Attachment Control Number to at least flag the number as an Attachment Control Number (yes, we know this breaks the concept of root + extension being globally unique):

      e.g., <id root=”1.2.3.4.5.6.7” extension="1234567">

    2. Austin Kreisler remembers something related to this from about 10 years ago.
    3. Lisa R. Nelson had examples for this around masking.
    4. It is required. It won't throw a schema error.
    5. From Russell Ott <id nullFlavor="UNK" extension="1234567" assigningAuthorityName="Aetna"/>

      Russ Ott Email Follow-up

      Hi all,


      Thanks for the discussion today – my understanding of our consensus is that the community (at least representatives on this SDWG call) feels that the nullFlavor approach proposed is probably the better workaround, given where we are today, but that I’ll follow up with Grahame Grieve, Lloyd McKenzie, and Jean Duteau to see if they’re aware of a better solution we could use with CDA, or have strong objections to this approach.


      An additional suggestion from Lisa Nelson might also help provide better context when adopting this approach in the context of Attachment Control Numbers is to include the inFulfillmentOf/order/code attribute to clarify that the “order” relates to generating a claims attachment – example below:



      inFulfillmentOf
            <inFulfillmentOf>
                  <order>
                        <id nullFlavor="UNK" extension="1234567" assigningAuthorityName="Aetna"/>
                        <code code="429111000124101" displayName="Documentation of care summary (procedure)" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT" />
                  </order>
            </inFulfillmentOf>


      I’m also very receptive to a better code  we could use in this context, but this is the best one I could find in my amateur sleuthing of SNOMED.


      • Russ
  2. STU Comments - 1946 - Language ValueSet: Language urn:oid:2.16.840.1.113883.1.11.11526
    1. This may be a technical correction.
    2. FHIR group and C-CDA group have two ValueSet with the same intent with different OIDs
    3. A couple of technical corrections.
    4. Changing an OID to get to a ValueSet with the codes.
    5. TypeMotion
      Motion

      All references to ValueSet Language urn:oid:2.16.840.1.113883.1.11.11526 would be changed to value set CommonLanguages 2.16.840.1.113883.4.642.3.20 (url http://hl7.org/fhir/ValueSet/languages) as represented in FHIR

      By
      Second
      Date

       

      Ref #1946
      For16
      Neg00
      Abs01
      Status

      APPROVED

      Tally16-00-01 
      Discussion

      ActionCorrect and point to the the FHIR terminology.
      TypeMotion
      Motion

      Motion to make sure all the examples are correct

      By
      Second
      Date

       

      Ref #1946
      For16
      Neg00
      Abs01
      Status

      APPROVED

      Tally16-00-01 
      Discussion

      ActionErrata Sheet for the examples
  3. PACP Comment #44 - Open Comment - Lisa R. Nelson
    1. CDAR2_IG_PERSADVCAREPLAN_R1N1_2019SEP_almalgamated_20200416_20200620 reopen comments.xls

    2. TypeMotion
      Motion

      Motion to approve Comment #44 Disposition as stated

      By
      Second
      Date

       

      Ref ##44
      For15
      Neg00
      Abs01
      Status

      APPROVED

      Tally15-00-01 
      Discussion

      No additional discussion

      Action

      Lisa R. Nelsonwill finish up the work on document

  4. STU Comments - Nick Radov (25min) (Expand C-CDA Templates for Clinical Notes DSTU Release 2.1 - US Realm to find Nick's issues)
    1. STU Comments - HL7 CDA® R2 IG: C-CDA Templates for Clinical Notes DSTU Release 2.1 - US Realm
    2.  Click here to expand...

      STU

      Last Updated

      Commenter

      Issue

       

      2.61 Procedures Section (entries optional) (V2)
      2.61.1 Procedures Section (entries required) (V2)

      I think we have a discrepancy between the narrative text in these sections versus the formal constraints on the contained "Procedure Activity Procedure (V2)" entry template. The sections are only supposed to contain historical procedures which actually altered the patient's state. However the Value Set: ProcedureAct statusCode urn:oid:2.16.840.1.113883.11.20.9.22 includes concept codes for "aborted", "active", and "cancelled". If the procedure is still active then it isn't yet historical. If the procedure was aborted or cancelled then presumably it didn't alter the patient state.

      This is creating confusion among implementers. We have received documents from multiple EHRs containing procedure entries with statusCode/@code="active".

       

      Figure 161: Immunization Activity (V3) Example
      (page 550)

      <code code="33" codeSystem="2.16.840.1.113883.6.59" displayName="Pneumococcal polysaccharide vaccine" codeSystemName="CVX">

      Figure 224: Substance Administered Act Example
      (page 846)

      <code code="43" codeSystem="2.16.840.1.113883.6.59" displayName="Hepatitis B Vaccine" codeSystemName="CVX" />
      1942

       

      Comment Activity
      urn:oid:2.16.840.1.113883.10.20.22.4.64

      5. SHALL contain exactly one [1..1] text (CONF:81-9430).
      a. This text SHALL contain exactly one [1..1] reference (CONF:81-15967).
      i. This reference SHALL contain exactly one [1..1] @value (CONF:81-15968).
      1. This reference/@value SHALL begin with a '#' and SHALL point to its corresponding narrative (using the approach defined in CDA Release 2, section 4.3.5.1) (CONF:81-15969).
      b. This text SHALL contain exactly one [1..1] reference/@value (CONF:81-9431).

      The order of these conformance statement is confusing. It seems like 5.a.i would make more sense under 5.b
      1946

       

      Table 6 found on page 63 in CDAR2_IG_CCDA_CLINNOTES_R1_DSTU2.1_2015AUG_Vol2_2019JUNwith_errata.pdf has the following text:

      Table 6: Language Value Set: Language urn:oid:2.16.840.1.113883.1.11.11526

      A value set of codes defined by Internet RFC 5646. Use 2 character code if one exists. Use 3 character code if a 2 character code does not exist. Including type = region is allowed

      See http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
      Value Set Source: http://www.loc.gov/standards/iso639-2/php/code_list.php

      While the table states Including type = region is allowed - the value set source does not list any valid regions. Also, the two sample provided as follows need to be corrected:

      The Figure 1: US Realm Header (V3) Example shows <languageCode code="en-US" />
      which SHOULD be <languageCode code="en" />

      The Figure 2: recordTarget Example shows <languageCommunication> <languageCode code="eng" />
      which SHOULD be <languageCommunication> <languageCode code="en" /> because Table 6 (Page 63) states to use the 2 digit code if there is one.

      Lastly, this value set is not included in VSAC. Should it be?
      1945

       

      Encounter Diagnosis (V3)
      [act: identifier urn:hl7ii:2.16.840.1.113883.10.20.22.4.80:2015-08-01 (open)]

      This template wraps relevant problems or diagnoses at the close of a visit or that need to be followed after the visit. If the encounter is associated with a Hospital Discharge, the Hospital Discharge Diagnosis must be used. This entry requires at least one Problem Observation entry.

       

      1.1.1 Properties

      ...

      8. SHALL contain exactly one [1..1] confidentialityCode, which SHOULD be selected from ValueSet HL7 BasicConfidentialityKind urn:oid:2.16.840.1.113883.1.11.16926 STATIC (CONF:1198-5259).
      1885

       

      @sueann svabySHALL contain exactly one [1..1] code, which SHOULD be selected from ValueSet Social History Type urn:oid:2.16.840.1.113883.3.88.12.80.60 DYNAMIC (CONF:1198-8558).
      a. If @codeSystem is not LOINC, then this code SHALL contain at least one [1..*] translation, which SHOULD be selected from CodeSystem LOINC (urn:oid:2.16.840.1.113883.6.1) (CONF:1198-32951).
      1873

       

      Encounter Diagnosis (V3)
      [act: identifier urn:hl7ii:2.16.840.1.113883.10.20.22.4.80:2015-08-01 (open)]

      The template is missing a binding for statusCode.

      Figure 144 shows a statusCode of "active". This provides the wrong guidance.
      1859

       

      Please REMOVE/DEPRECATE this commentIn the errata release from June 2019,Figure 162 is wrong and needs to be updated to use the correct Code System OID for CVX 2.16.840.1.113762.1.4.1010.6. It currently shows as 2.16.840.1.113762.12.292
      1860

       

      In the errata release from June 2019,Figure 161 is wrong and needs to be updated to use the correct Code System OID for CVX "2.16.840.1.113883.12.292". It currently shows as 2.16.840.1.113762.6.59

       

      Care Plan (V2)
      [ClinicalDocument: identifier urn:hl7ii:2.16.840.1.113883.10.20.22.1.15:2015-08-01 (open)]

      The CDA Care Plan represents an instance of this dynamic Care Plan at a point in time. The CDA document itself is NOT dynamic.
      Key differentiators between a Care Plan CDA and CCD (another “snapshot in time” document): There are 2 required sections:
      o Health Concerns o Interventions
      There are 2 optional sections:
      o Goals o Outcomes

      • Provides the ability to identify patient and provider priorities with each act • Provides a header participant to indicate occurrences of Care Plan review A care plan document can include entry references from the information in these sections to the information (entries) in other sections.
      Please see Volume 1 of this guide to view a Care Plan Relationship diagram and story board.

       

      Section 1.1.17.4.iv doesn't include ICD-10-PCS as an allowed code system. It has now supplanted ICD-9 in the US realm.
      1802

       

      Smoking Status - Meaningful Use (V2) (urn:hl7ii:2.16.840.1.113883.10.20.22.4.78:2014-06-09)

      . This value SHALL contain exactly one [1..1] @code, which SHALL be selected from ValueSet Smoking Status urn:oid:2.16.840.1.113883.11.20.9.38 DYNAMIC (CONF:1098-14817).

      1800 

      1801

       

      We have trouble adding new Social History Observations when the US Gov't identifies the observation using LOINC. We really should be using LOINC in the code ("the question").

      I recommend creating a Grouping Value Set that combines the original set of concepts using SNOMEDCT (Social History Type (SNOMEDCT)) and then agree to put all new/additional social history observation codes in the Social History Type (LOINC) value set. Use the existing OID for the new Grouping VS and make two new value sets for the parts of the grouping VS.
      1798

       

      On page 392, Section 3.61.1, the last three sentences of the text read as follows:

      "Procedure act is for procedures that alter the physical condition of a patient (e.g., splenectomy). Observation act is for procedures that result in new information about a patient but do not cause physical alteration (e.g., EEG). Act is for all other types of procedures (e.g., dressing change)."

      This is different from the wording on page 390, Section 3.61 Procedures Section (entries optional) (V2). Updated language is in the proposed section below.

       

      Currently the Referral Note (V2) document type doesn't include a Payers section. We should add that as an optional section because sometimes the "Referred From" provider needs to tell the "Referred To" provider which insurance coverage the patient has. And in some cases the provider needs to route a copy of the document to the patient's insurance company so they also need a way to indicate which plan the patient is on (or at least which plan they believe the patient to be on).
      1793

      3.41 Immunization Medication Information (V2) includes SHALL have a manufactureMaterial where this code MAY contain zero or more [0..*] translation, which MAY be selected from ValueSet Vaccine Clinical Drug urn:oid:2.16.840.1.113762.1.4.1010.8 DYNAMIC (CONF:1098-31543).

       

      3.41 Immunization Medication Information (V2) includes SHALL have a manufactureMaterial where this code MAY contain zero or more [0..*] translation, which MAY be selected from ValueSet Vaccine Clinical Drug urn:oid:2.16.840.1.113762.1.4.1010.8 DYNAMIC (CONF:1098-31543).

       

      We have seen real-world implementation defects where planned future encounters appear in the Encounters section rather than the Plan of Treatment section where they should be. I think some developers are just querying their database encounter tables for all encounters for a particular patient and sticking everything in the Encounters section regardless of whether they are past or future. Let's introduce a new conformance rule to ensure each Encounter activity ends before the document header effectiveTime.

       

      In section 3.81 Procedure Activity Procedure (V2) the Procedure.code (CONF:1098-7656) doesn't mention HCPCS as a possible code system. I think that code system should be explicitly listed because it is in common use in the US realm along with CPT-4. There are many procedures which are in HCPCS but not in CPT-4.

      This @code SHOULD be selected from LOINC (CodeSystem: 2.16.840.1.113883.6.1) or SNOMED CT (CodeSystem: 2.16.840.1.113883.6.96), and MAY be selected from CPT-4 (CodeSystem: 2.16.840.1.113883.6.12) or ICD10 PCS (CodeSystem: 2.16.840.1.113883.6.4) or CDT-2 (Code System: 2.16.840.1.113883.6.13) (CONF:1098-19207).

       

      Section 3.23, page 483:

      Table 272: EncounterTypeCode
      Value Set: EncounterTypeCode urn:oid:2.16.840.1.113883.3.88.12.80.32
      This value set includes only the codes of the Current Procedure and Terminology designated for Evaluation and Management (99200 – 99607) (subscription to AMA Required
      Value Set Source: http://www.amacodingonline.com/

       

      <!-- ************************ ENCOUNTERS *********************** -->
      <component>
      <section>
      <!-- *** Encounters section (entries required) (V3) *** -->
      <templateId root="2.16.840.1.113883.10.20.22.2.22.1" extension="2015-08-01"/>
      <templateId root="2.16.840.1.113883.10.20.22.2.22.1"/>

      I think there is a problem with the sample CCD file C-CDA_R2-1_CCD.xml included in this package.

  1. STU Updates - Matt Szczepankiewicz(25min) (expand HL7 CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes Companion Guide, Release 2 STU - US Realm )
    1.  Click here to expand...

      STU

      Last Update

      Commenter

      Comment

      1983   

       

      Order fulfillment conformance statement that are contradictory

       

      Appendix C has a constraint with root, extension and NULL of UNK

       

      The Provenance entry in the Appendix C is inconsistent with the author entry in the C-CDAr2.1 IG in terms of allowable values and it is misleading.

       

      For the UDI information, can we get clarification on whether it is possible to send other information when we do not have the DI information?

       

      Appendix B UDI
      1.1 UDI Organizer 

      Figure 1: Unique Device Identifier (UDI) Organizer Template ID root is incorrect

       

      (Vocab issue)
      Table 9 of the Companion Guide recommends the LOINC codes 11502-2 for Laboratory Narrative notes and 11526-1 for Pathology Narrative notes. However, these codes aren't actually included in the Note Types value set (urn:oid:2.16.840.1.113883.11.20.9.68) as required by the Notes Section and Note Activity templates in Appendix A. Likewise, although no specific LOINC code is recommended for Imaging Narrative notes, the value set doesn't include any codes from the value set recommended for imaging notes in Table 8 (urn:oid:1.3.6.1.4.1.12009.10.2.5).

       

      In Appendix C, I read the Provenance - Author Participation template as saying you can use the same trick as in the standard C-CDA Author Participation template to reference an author already defined elsewhere in the document:

      The assignedAuthor/id may be set equal to (a pointer to) an id on a participant elsewhere in the document (header or entries) or a new author participant can be described here.

      That is, that it's okay to do this:

      <assignedAuthor>
      <id extension="1386639318" root="2.16.840.1.113883.4.6" />
      </assignedAuthor>

      assuming the document actually contains a full entry for the author with that id somewhere else.

      But when an author containing the Provenance - Author Participation templateId does this, it raises a handful of schematron errors that still enforce the SHALL constraint on the representedOrganization (CONF:4440-4 and children):

       

      The following unimplemented constraints use the expression "not(.)" throughout the main Companion Guide schematron file:

      CONF:3250-16902
      CONF:3250-16912
      CONF:3250-16914
      CONF:4435-133
      CONF:3250-16942

      Typically unimplemented constraints use a dummy expression like "not(tested)" that always returns false (since the current element doesn't have a child named "tested"), but in this case, we're asserting that the current node is null, which returns false, makes the assertion fail, and triggers a false positive schematron error.
  2.  Adjourn
    1. Next meeting:  
    2. Meeting adjourned at 12:01pm EST by Austin Kreisler

 


*Tip


Copyright © Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher.