CDA+-+Resolved+Header+Issues


 * **Issue ID** || **Document Reference** || **Issue Title** || **Comment** || **Disposition Description** ||
 * **8089** || HITSP/C80 -- Clinical Document and Message Terminology Component || HITSP Select Standard now Obsolete - FIPS

INCITS 38-2009, FIP 5-2 website should reference the new standard. Keith, to send link. Now replaced by INCITS 38:2009 available at ||
 * Originator:** Cindy Levy || This HITSP component includes Federal Information Processing Standards (FIPS) Publication 5-2: Codes for the Identification of the States, the District of Columbia, and Outlying Areas of the United States, and Associated Areas. The FIPS Publication, however, has been withdrawn per Federal Register/Vol 73 No. 170 published on 2 September 2008. || Update using appropriate vocabulary when it is formally published. It was not published at the time the document was written.
 * **11047** || HITSP/C83 -- CDA Content Modules Component || National Provider ID listed as R2, but CDA R2 forces id element to R

In Section 2.2.2.4 Healthcare Provider, Data Element 4.10 is National Provider ID. Its Requirement is listed as R2 and the CDA Data Location is cda:assignedEntity/cda:id. There is an "additional specification" (2.2.2.4.4) which forces the root element of this id to be set to 2.16.840.1.113883.4.6 (NPI) and the extension must be set to the NPI value. So, our understanding is that if an implementor has an NPI for the patient, they would use it here. If they did not have the NPI, they would leave the element out. However, in the CDA R2 schema, the cardinality of an id element under assignedEntity is 1...*. This means that the implementor is forced to put an id element here, even if they do not have an NPI. However, once the id element is present, presumably the rules in 2.2.2.4.4 are active. If they do not have an NPI, it is not clear what they should do about the root and element. One solution to this ambiguity would be to change the CDA Data Element for 4.10. Instead of making the id element R2, instead make cda:id\[@extension and @root\] attributes R2 in a similar way that was done for 4.04 in the same table (and other places in HITSP/C83 where the Data Element was moved from cda:code to cda:code/@code or cda:value to cda:value/@code). A larger discussion may involve moving R2 requirements from element level to the attribute level. Alternatively, some language could be added to clarify the use of nullFlavors in R2 elements (i.e. "Additional Specification" requirements to only be enforced when a nullFlavor does not exist, or something along those lines). || R2 is defined as a SHOULD so NPI is no longer required || NullFlavor is allowed. ||  || //**Response from NIST:**// //The NIST tooling was designed to match the specification itself. So if the specification says something that isn't appropriate, then the tooling will match then until such time as the specification changes.// //In the specific case of gender, Table 2-5 of HITSP/C83 v2.0 (page 27) puts the "R" requirement at the attribute level ]]_(cda:administrativeGenderCode/@code). This makes the code attribute required. The code attribute is then further constrained by section 2.2.2.1.4 (which forces the HL7 gender vocabulary). I don't see any language that would allow the tool to get around these requirements.// //Further, see Section 1.4.3 (pg 10) of HITSP/C83 v2.0. Here it discusses the two instances in HITSP/C83 where adherence to a specific vocabulary is required. One of these instances is Gender. This whole section further demonstrates that the specification was written to only allow for the HL7 vocabulary here. More specifically: "1.06 Gender, it was felt that adherence to a vocabulary containing only 3 elements for a commonly understood construct could be met by all producers using the HITSP supplied vocabulary."// //If a way to supply "unknown" gender as opposed to an "undifferentiated" gender is required, then the specification will have to be changed to make that happen. If/when that happens we will update the tool.// ||  || CONF-HP.-32: A patient/birthTime element SHALL be present. The patient/birthTime element SHALL be precise at least to the year, and SHOULD be precise at least to the day, and MAY omit time zone. If unknown, it SHALL be represented using a flavor of null. ||  ||
 * Originator:** Andrew McCaffrey || (Although this comment is about one data element, it perhaps is part of a larger discussion that would affect other "required" R2 elements.)
 * **V.A.-1** || HITSP/C83 || 1.03-Person Address: Which Address is Required || Clarify how the "Required" constraint is to be satisfied - is is satisfied when any one of the home, work, or vacation addresses are provided or must t he home address be provided? || Add clarification to IG: Any address is acceptable. Intent is address that supports delivery of care ||  ||
 * **V.A.-2** || HITSP/C83 || 1.04-Person Phone/Email/URL: What Elements are Required || Clarify how the "Required" constraint is to be satisfied - is is satisfied when any one of the phone/email/url elements are provided and/or any type of phone: home, work, vacation || Add clarification to IG: If any are present this requirement is statisfied. Just an e-mail or phone number would satisfy this requirement.
 * **V.A.-3** || HITSP/C83 || 1.05-Person Name: What Elements are Required || Clarify how the "Required" constraint is to be satisfied - What are the minimum components for a name ?, Which name type is required (legal, alias, or any)? || Add clarification to IG: The name element must be present. ||
 * **V.A.-4** || HITSP/C83 || 1.06-Gender: Unable to specify "Unknown" || 1.06-Gender is a Required data element for the C32. The required terminology is the HL7 Adminstrative Gender Code. The values are M=Male, F-Female and U=Undifferentiated. However, the VA Gender values are M=Male, F=Female, and U=Unknown. When the VA VistA value is U=Unknown, a code translation cannot performed because there is no equivalent in the HL7 Administrative Gender code set. In this case, the VA data will be provided by setting the administrativeGenderCode to nullFlavor =”UNK”. But this causes the NIST Validation Tool to generate an error. A method to specify "Unknown" for Gender is needed. || Introductory material: Need to be very clear that nullFlavor is allowed in a SHALL.
 * **V.A.-5** || HITSP/C83 || 1.07-Person Date of Birth: Can It Be Imprecise? || Clarify how precise birthTime needs to be. This may be inherent in the cda:birthTime designation, but it is legwork that the implementor has to research. Can the document explain whether only a year or only month+year can be provided. For many VA patients, the birth date is not completely precise with MM+DD+YYYY. || Per H&P and to be inclued in the new US-Realm Header:
 * **V.A.-6** || HITSP/C83 || Need Visibility to Modules Like Custodian, LegalAuthenticator, etc || Implementation Guide should provide viability to and definition of CCD modules that are required but not represented in the C32 spec. || All CDA base requirements will be reiterated in the consolidated IG. Health Story guides referencing CCD/C32 modules will include full detail. ||