Difference between revisions of "Consolidated CDA July 2012 Errata"
Line 34: | Line 34: | ||
*SHALL contain exactly one [1..1] code="11323-3" Health status with @xsi:type="CE" (CodeSystem: LOINC 2.16.840.1.113883.6.1 STATIC) (CONF:9073). | *SHALL contain exactly one [1..1] code="11323-3" Health status with @xsi:type="CE" (CodeSystem: LOINC 2.16.840.1.113883.6.1 STATIC) (CONF:9073). | ||
These were data entry errors. There was no intent to require @xsi:type to be present and constrain it to anything other than the default datatype for applicable code element. | These were data entry errors. There was no intent to require @xsi:type to be present and constrain it to anything other than the default datatype for applicable code element. | ||
+ | |||
+ | 7.Inconsistent use of serviceEvent/performer/@typeCode. There are several single value bindings for typeCode throughout consolidation. The general header constraints require "PRF" (Participation physical performer, see conf 14840), but other document type specific header constraints require other codes like "PPRF" (Primary Performer, see conf 8495). SDWG agreed to remove the single value binding from CONF 14840 in the general header constraints, allowing all document types to use whatever codes are appropriate. (reviewed and approved on the Nov 1, 2012 SDWG call). | ||
==Errata to be reviewed by SDWG== | ==Errata to be reviewed by SDWG== |
Revision as of 13:29, 2 November 2012
Return to SDWG page. (Items on this list must first have been approved for inclusion through a SDWG vote).
Approved Errata
1. Published IG states "HL7 Data Types Release 1 requires the codeSystem attribute unless the underlying data type is Coded Simple or CS, in which case it is prohibited. The displayName and the codeSystemName are optional, but recommended, in all cases".
- Because displayName and codeSystemName are prohibited in CS data type, the recommendation only applies where the data type is NOT CS (e.g. CE or CD).
2. Section 1.8.1, Table "Constraints format example", shows that template constraints are presented in various formats in order to meet different user needs. We have found a handful of discrepancies between the constraints enumerated in the tables and the corresponding constraints enumerated in the list of constraints following each table. We have identified the source of discrepancies, which will resolve this issue in future publications. For now, we declare that the constraints enumerated in the list are the source of truth, and take precedence over the constraints enumerated in the table. We will include this declaration in future implementation guides. Specific discrepancies identified include:
- Table "Comment Activity Constraints Overview" incorrectly lists and links to CONF 9430 and 9431, which do not exist.
- Table "Family History Organizer Constraints Overview" incorrectly lists and links to CONF 8610, 8611, 8613, 8614, and 8615, which do not exist.
- Table "Referenced Frames Observation Constraints Overview" incorrectly lists and links to CONF 15923, which does not exist.
3. Table "Template Ids Alphabetically by Template Type"
- Lists an Implants Section template, which does not exist (see Procedure Implants Section instead).
- Lists a Surgery Description Section template, which does not exist (see Procedure Description Section instead).
4.The implementation is full of constraints like the following: (reviewed and approved on the Sept 20, 2012 SDWG call)
- SHALL contain exactly one [1..1] statusCode="completed" Completed (CodeSystem: ActStatus 2.16.840.1.113883.5.14 STATIC) (CONF:7321).
Which imply that statusCode should directly contain the string "completed" (i.e. <statusCode>completed</statusCode>) when what is wanted is statusCode/@code="completed" (i.e. <statusCode code="completed"/>) )
5.The medications section contains the following constraint: (reviewed and approved on the Sept 20, 2012 SDWG call)
- SHALL contain exactly one [1..1] title="Medications" (CONF:7793).
other sections do not constrain their titles to a fixed string. This is an error and the correct conformance statement should be this:
- SHALL contain exactly one [1..1] title (CONF:7793).
6.There are many constraints on code elements (observation/code, etc.) requiring @xsi:type to be present when that was not the intent. For example: (reviewed and approved on the Sept 20, 2012 SDWG call)
- SHALL contain exactly one [1..1] code="11323-3" Health status with @xsi:type="CE" (CodeSystem: LOINC 2.16.840.1.113883.6.1 STATIC) (CONF:9073).
These were data entry errors. There was no intent to require @xsi:type to be present and constrain it to anything other than the default datatype for applicable code element.
7.Inconsistent use of serviceEvent/performer/@typeCode. There are several single value bindings for typeCode throughout consolidation. The general header constraints require "PRF" (Participation physical performer, see conf 14840), but other document type specific header constraints require other codes like "PPRF" (Primary Performer, see conf 8495). SDWG agreed to remove the single value binding from CONF 14840 in the general header constraints, allowing all document types to use whatever codes are appropriate. (reviewed and approved on the Nov 1, 2012 SDWG call).
Errata to be reviewed by SDWG
1. Smoking Status Observation templateId and value set OIDs are incorrect.
- Update template from 2.16.840.1.113883.10.22.4.78 to 2.16.840.1.113883.10.20.22.4.78
- Update value set reference in CONF:14817 to Smoking Status 2.16.840.1.113883.11.20.9.38 STATIC 2012-07-01