CDA+-+N.A.+Harmonization+Issues

flat =Issues Previously Determined "Resolved" by HITSP= Such guidance would ensure consistency across already-defined documents (CAP119 and 120) and that new specifications from HL7, IHE, others would meet minimal HITSP requirements. Such specification would ensure that entities wishing to exchange a full set of patient records can do so with at least minimal HITSP guidance. It would ensure that entities creating EHR-compatible document management systems construct these systems to accommodate the widest range of clinical information. 2. HITSP should publish a Roadmap describing how the full patient record (the “Health Story”) is to be exchanged. To date, the use-case driven (bottom up) requirements have not provided this comprehensive picture. Such guidance should be consistent with an ontology of document types such that any clinical document can be identified with an ontology according to type. 3. HITSP should provide guidance on implementation of the LOINC document types. Such guidance would include a reference to the full set of HITSP-defined document types and the corresponding LOINC value sets as well as the principles of implementing LOINC as a document ontology. The value is to implementers who can then build document repositories and registries and support queries with “type of” relationships. This is a gap in TN901, CAP119 and CAP120. || Goal of project is a new US Realm CDA Header Template || Robert Dolin || 2.2.1.1.1.3\- Country should use ISO 3166 Country Codes 2.2.1.3.1.5 \-Nursing Diagnoses This list should be specified, or the value set, more rigidly defined. Is the mapping available from IHTSDO, or CAP? 2.2.1.3.1.6\- Diagnoses What specification references this? If none, then it should be removed from C80. 2.2.1.3.1.6.2\- Problem Severity Should include vocabulary, let Allergy stuff that comes later reference Problem severity 2.2.1.3.2.4\- Allergy/Adverse Event Product Where possible, HITSP Value sets should be specific, so we can have a value set for Medication Product, Medication Class, Substance. Then this value set should reference the others, not duplicate them. || 2.2.1.1.1.3 Agreed to use ISO3166 for country code 2.2.1.3.1.5 We need a mapping for Nursing Diagnoses from CCT and OMAHA to SNOMED. This needs to be added to C83 Problem List Section 2.2.1.3.1.6 Diagnosis to be removed from C80 2.2.1.3.1.6.2 Problem Severity should include the Allergy /Severity definition and then reference it in the Allergy section 2.2.1.3.2.4 Allergy Adverse Event Product. this overlaps three other value sets. We should just state this value set contains all values from these 3 other value sets 2.2.1.3.3.12 Medication Vehicle we will use SNOMED for vehicle as it was chosen by industry. 2.2.1.3.4.1 Vaccine Administered discuss with Population tomorrow 2.2.1.3.4.3 Immunization Information Source \--discuss with Population Country Codes - Done Nursing Diagnosis - Not applicable to this workgroup. Mappings are available from CAP. Diagnosis Removed. Problem Severity added. Allergy/Adverse Event Product references other value sets. This one is DONE ||  || Not sure why SNOMED here, and UNI elsewhere. We should be consistent. 2.2.1.3.4.1 Vaccine Administered RxNorm includes Vaccines, should we allow it's use, and try to move away from CVX/MVX? 2.2.1.3.4.3 Immunization Information Source Why is this level of detail necessary for Immunizations but not elsewhere? Is there a way to generalize this for use elsewhere? 2.2.1.3.5.1.1 Laboratory Test Results Needs to Include CSTE identified tests for laboratory results containing reportable/notifiable conditions, or GAP it if that information is not available until next year. Talk to Cecil Lynch. 2.2.1.3.5.1.2 Laboratory Observations Give us the code for the root of the hierarchy. 2.2.1.3.5.3 Laboratory Tests Overlap with 2.2.1.3.5.1.1, one of these should be removed? Value set needs further constraint, since LOINC contains Cardiology, Radiology and other tests as well. Constraint = Method? 2.2.1.3.5.4 Results Normalcy Status Include the table, not just reference, include V3 vocab for this as well (for C37). 2.2.1.3.5.6 Vital Sign Result Type Include value set from original C32 recommendation, see IHE List in PCC TF. 2.2.1.3.7.1 Provider Role Need to include Nursing, other types of provider roles. Need to distinguish administrative vs. clinical role (attending has specific administrative privileges, does not describe clinical role) 2.2.1.3.7.2 Provider Type Check on status of code request, or GAP it. || DVS - Implemented all but what is highlighted below Rejected - Genetic Test being referenced to HL7 (HL7 not done yet so did not reference), changes to Immunization Information Source Deferred - Nursing, Medication Vehicle, Vaccine admission, Lat Tests, Lab Obs, Provider Role, Provider Type, Admin Source, Admin Type, Discharge Disposition, Document Class Provider Setting ||  || See about obtaining this data, does this belong in A&F section. 2.2.1.3.8.2 Admission Type See about obtaining this data, does this belong in A&F section. 2.2.1.3.8.4 Discharge Disposition See about obtaining this data, does this belong in A&F section. 2.2.1.3.9.2 Advance Directive Status Drop this, without definition, it has no value. 2.2.1.3.11.1 Genetic Test Result Identifiers 2.2.1.3.11.2 Genetic Test Result Values Missing reference to HL7 Guide 2.2.1.3.11.7 Single Nucleotide Polymorphisms Some concerns have been raised about this vocab, may want to drop it. 2.2.1.3.12.1 Document Class Investigate note types in AHIC Extension on clinical documents, ensure we have it covered. 2.2.1.3.12.3 Practice Setting Push on NUCC to provide codes. || 2.2.1.1.1.3 Agreed to use ISO3166 for country code 2.2.1.3.1.5 We need a mapping for Nursing Diagnoses from CCT and OMAHA to SNOMED. This needs to be added to C83 Problem List Section 2.2.1.3.1.6 Diagnosis to be removed from C80 2.2.1.3.1.6.2 Problem Severity should include the Allergy /Severity definition and then reference it in the Allergy section 2.2.1.3.2.4 Allergy Adverse Event Product. this overlaps three other value sets. We should just state this value set contains all values from these 3 other value sets 2.2.1.3.3.12 Medication Vehicle we will use SNOMED for vehicle as it was chosen by industry. 2.2.1.3.4.1 Vaccine Administered discuss with Population tomorrow 2.2.1.3.4.3 Immunization Information Source \--discuss with Population Admissions and Encounters stuff (first three) may well belong in Administation and Finance section, not worth debating, could be part of organization of new guide structure. Getting the data requires a license, and HITSP chose not to \-\- Done. Advance Directive Status is done. Genetic Test Result Identifiers and Values … Reference to HL7 IG nice but not necessary for implementation. SNP was deleted. Document Class addressed NUCC no longer relevant, changed to SNOMED w/ NHIN assistance. ||  || The essence of the error is this: HITSP C32 identifies the HL7 Continuity of Care Document (CCD) Implementation Guide as its base standard. HITSP C32 identifies sections of the CCD document, and refers to HITSP C83 for the specification of those sections. HITSP C83 refers to the IHE Patient Care Coordination (PCC) Technical Framework for the definitions of many of the sections defined by the CCD. The IHE Patient Care Coordination Technical Framework definition of individual sections of the CCD is, in some cases, not consistent with the definition of the same section in the CCD base standard. I have not completed an analysis of each of the sections defined in the CCD specification, but these two examples are sufficient to demonstrate the point that the current version of HITSP C32 is internally inconsistent. HITSP standards frequently refer to standards in the “Selected Standards” section of the HITSP construct, without describing precisely what portion of the selected standard applies to the construct, or how. Without such description, the safest thing for an implementer to assume is that the entire standard applies. Implementers would readily make that assumption in the case of HITSP C32 and CCD, given that the title of C32 is “Summary Documents Using HL7 Continuity of Care (CCD) component.” If the intention of the revision of C32 is that only the sections of CCD apply to C32, but not the content of each section, this is both highly misleading and seriously ill-advised. The Results section of the CCD identifies the child element of the “ ” (which is the element that contains the structured portions of each section) as one of Observation, Procedure, or Organizer (used to group a battery of results from the same test). C83 requires conformance to the “Coded Results” section of the IHE PCC Technical Framework. PCC defines the child element of the “ ” as one of Observation, Procedure, or References. Thus, a document that contains, in the Results section, an entry whose top-level element is Organizer is valid CCD, but invalid according to the IHE PCC Technical Framework. The Medications section of the CCD identifies the child element of the “ ” as one of “Substance Administration” or “Supply”. It specifies that the “Substance Administration” activity is used to describe medications that are administered, while the “Supply” activity is used to describe medications that are dispensed (as from a pharmacy). C83 requires conformance to the “Medications” section of the IHE PCC Technical Framework. PCC allows only a “Substance Administration” element as a child of the in the Medications section. PCC defines that a “Substance Administration” element may refer to a “Supply” element (to indicate a medication having been dispensed) using the  construct of CDA, as a related reference to the “Substance Administration” entry. Thus, a document that contains, in the Medications section, a “Supply” element as a direct child of the is valid CCD, but invalid according to the PCC Technical Framework. || **{_}HITSP:_** CMHR was unable to contact commenter for clarfication, needs discussion. These are not issues, but rather design choices in XPHR to AVOID having multiple ways of representing certain information. For example, for medication, supply alone cannot convey dosing instructions (need substanceAdministration for that), and it was expected in IHE and HITSP contexts that posession of supply data would also assume posession of substanceAdministration data, so this additional REQUIREMENT can be met without violating CCD. PLEASE NOTE: PCC requirements are must contain, not must contain as an immediate child. See NIST Validation rules for details. || Richard Franck || Constraints: Current text: C154-\[DE-6.04-1\] Food and substance allergies SHALL be coded as specified in HITSP/C80 Section 2.2.3.3.11 Ingredient Name C154-\[DE-6.04-2\] Suggested changes: C154-\[DE-6.04-1\] Food and non-medicinal allergies SHALL be coded as specified in HITSP/C80 Section 2.2.3.3.11 Ingredient Name C154-\[DE-6.04-2\] Note, C80 section 2.2.3.3.9 Medication Drug Class must allow for more than one NDF-RT classification concept to accurately represent drug class for many medications. For VA/KP Subset for problems, RXNORM, and LOINC Result Codes: Change definition of the vocabulary: The definition will be changed to be consistent with vocabularies selected by Federal regulation on Meaningful use. This change will be completed when that regulation has been published. If the value set identifiers are HITSP identifiers, then we don't need new ones. If they are other than HITSP identifiers, we will need to assign new ones. Update the version to be the expected final publicatioon date for the vocabularies. CMHR - Additional discussion with Rob McClure required to determine how to make the change without it being a major change. VA/KP Problem List Governance is under discussion. Looking for an update. || Cindy Levy clevy@patriottechnologies.net 12/17/2009 10:03:36 Disposition same 8828 and 8840. Terminfo was not selected, so the last part of the comment is not relevant (post-coordination SNOMED CT not prohibited). \-Addressed\- ||  || Constraints: Current text: C154-\[DE-7.04-1\] The problem SHALL be coded as specified in HITSP/C80 Section 2.2.3.1.1 Problem Comment: C80 specification limits problem to VA/KP problem list but for many quality metrics rare diseases must be noted, often for exclusions. Also, if this Data dictionary is to be generally used how will rare problems be handled? Such rare problems, conditions, and diseases either need to be added to the VA/KP problem list or there needs to be different use cases for different subsets of a universal problems, conditions, and diseases list. Finally, use for SNOMED CT expressions (so called post-coordination) must also be directly supported for some complete specifications in accordance with Terminfo as necessary. ||  ||   || For instance: C83 and HL7 CCD give conflicting recommendations for representation of problem status. For instance: There are several CDA templates for "primary diagnosis", including the pattern associated with data element 7.10 "Diagnosis Priority": .. ......  ...... <\!-\- HL7, LOINC, and SNOMED have potentially suitable codes --> ...... ..........  ..............  ..............  .......... ......  ..  ...... <code code="8319008" codeSystem="2.16.840.1.113883.6.96" || Cindy Levy clevy@patriottechnologies.net 12/16/2009.. 20:24:32 Cross Organization coordination (IHE, HL7, HITSP) is required to resolve this... A process will need to be developed. Cindy Levy clevy@patriottechnologies.net 12/16/2009.. 20:24:32 Defer - Process issue to be worked Keith/Bob || Robert Dolin || For instance: C83 and HL7 CCD give conflicting recommendations for representation of problem status. For instance: There are several CDA templates for "primary diagnosis", including the pattern associated with data element 7.10 "Diagnosis Priority": ..  ...... <\!-\- HL7, LOINC, and SNOMED have potentially suitable codes --> ...... ..........  ..............  ..............  .......... ......  ..  ..  ......  || CMHR co-chairs will contact the commenter to discuss || Robert Dolin || Such guidance would ensure consistency across already-defined documents (CAP119 and 120) and that new specifications from HL7, IHE, others would meet minimal HITSP requirements. Such specification would ensure that entities wishing to exchange a full set of patient records can do so with at least minimal HITSP guidance. It would ensure that entities creating EHR-compatible document management systems construct these systems to accommodate the widest range of clinical information. || **(Duplicate of 8843)** || Liora Alschuler || from 2.16.840.1.113883.3.88.11.83.15 to 2.16.840.1.113883.3.88.11.83.15.1). At least it changed in the descriptive text in the top of section 2.2.2.15 and in conformance statement C83-\[DE-15\-CDA-1       \]. It did not change in the example or in the table in the back of HITSP/C83 which lists all the templates. The example in Figure 2-48 should be updated and the template ID should be changed in Section 3.2 Template Identifiers. || Yes, it changed because the template changed. || Andrew McCaffrey || (Back to the Top) =Issues "Not Applicable" to the Consolidation Project= See comment in regards TN 901 CMHR will confer with commenter to create a common understanding. Juggy to provide disposition description and then this PC can be closed. 11/18/09 ||  || 2. Why have we limited the concept of modules to CDA -- aren’t they equally of value for administrative and finance clumps of data? 3. Why have we limited the concept of templates to HL7? 4. On page 13, the sentence “If HITSP has not created an appropriate entry or section, the CDA document MAY contain include those.” Is unclear to me. ||  || Jack Corley || In the example the  contains the C83 templateId 2.16.840.1.113883.3.88.11.83.8.2. This template Id is NOT required by the rules and in fact should not be here because it pulls in the rules of Medication Information (Section 2.2.2.8.10), including the rules for Coded Brand Name Constraints (Section 2.2.2.8.12) that are not applicable in an Immunization context. || Don Van Syckle don@dvsconsult.com 12/22/2009 04:07:51 need further discussion with commenter and CMHR || Andrew McCaffrey || Additionally, the expectation to conform to this guide is that both sender and receiver of the order document must adhere to these coding standards. This would require that all providers, hospitals, laboratories, and other entities adhere to these coding system standards before the HITSP Lab Order Standard is adopted. ||  || Donna Carter || Example: The ANSI data element assigned to PID.8 -- Administrative Sex is ‘001111’ but the C154 document refers to ‘Gender’ as DE-1       .06-1). HL7 2.5.1 Standard Reference HL7 Attribute Table - PID - Patient Identification SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME 8 1 IS O 0001 00111 Administrative Sex C154 Data Dictionary Component Reference 1.06 Gender Gender is used to refer to administrative sex rather than biological sex and therefore should easily be classified into female and male. It is included in the exchange for purposes of linking to insurance information and other patient identification linkages and the value chosen by the patient should reflect the information under which any insurance or financial information will be filed, as well as the same information given to other healthcare providers, institutions or health data exchange networks C154-[DE-1.06-1] Gender SHALL be coded as specified in HITSP/C80 Section 2.2.1.2.1.2 V3 Administrative Gender || Cindy Levy clevy@patriottechnologies.net 12/20/2009 11:42:27 Data Architecture - Data Element Review Required. || Donna Carter || This may be scattered across the various HITSP CDA-oriented constructs (C80, C83, TN901, et al) but would benefit from being described in a single place. ||  || Liora Alschuler || period value='8' unit='h' /> with comment - Based on the rule, shouldn’t the value 'h' be '2' since institutionSpecified = true? ||  || Ed Larsen || 17.03 is attached to the cda:code/cda:originalText... It would therefore be more appropriate to say that the definition is "Free text describing the code of the procedure". The Free text describing the entire procedure would be used under cda:text. See email from Keith below: Boone, Keith W (GE Healthcare) wrote: There are two text parts to each Act in CDA. The first is the narrative text that describes the entire procedure in all detail. The next is the text that just describes the coded procedure. Act.text (or in this case, more specifically, procedure/text) is the full text with all the details associated with the act. The act.code.originalText is just the code for the procedure. See below for an example. The patient had a full hip replacement on July 2, 2008 performed by Dr. Bob at XYZ Hospital ...  ...  ||  || Andrew McCaffrey || If the intent was to change the template ID, then three things need to be changed: the conformance statement, the example and the table in Section 3.2. If the intent was not to change the template ID, then the text at the top of Section 2.2.2.5 should be changed back. ||  || Andrew McCaffrey || 2.2.2.7.4 is misnamed. Because it is putting a constraint on Problem Name which is Data Element 7.03, the statement should be labeled C83-[DE-7.03-1]. ||  || Andrew McCaffrey || The statement in 2.2.2.8.18 should be changed to C154-[DE-8.21-1] because this statement concerns Indication which is date element 8.21 according to table 2-12. ||  || Andrew McCaffrey || All three constraints in section 2.2.2.8.18 (Medication) Indication Constraints are labeled with Data Element 8.20. However, according to table 2-12, DE 8.20 refers to Status of Medication, not Indication. Instead, these conformance statements should be labeled with 8.21 which is the Data Element for Indication. ||  ||   || It should be Section 2.2.3.6.5 in HITSP/C80 which is Vital Sign Result Type. (2.2.3.6.4 is a Result **status**, not a type.) ||  ||   || The cleaner approach is to bind the indication to the order, but also desirable to bind to result. ||  || Lori Fourquet || But according to CDA R2 schema, the Admission Source cannot exist there. A code element is not a valid child of participant. The code element should appear under participantRole. ||  || Andrew McCaffrey || (Back to the Top)
 * __ **Issue ID** __ || __ **Document Reference** __ || __ **Issue Title** __ || __ **Comment/HITSP** __ || __ **Disposition Description** __ || __ **Comment Originator** __ ||
 * 8843 || Multiple Documents || General comments || 1. None of the specifications provide general guidance for exchange of CDA documents within the US Realm. The existing guidelines apply to specific types of documents, however, there remains a gap defining minimal requirements for any document type. TN901 supplies some of the general considerations, however, does not provide a “minimum necessary” for any CDA document. For example, the guidance would define a template for the CDA header to be used in all US-realm documents.
 * 5445 || HITSP/C80 -- Clinical Document and Message Terminology || Multiple Comments || C80 Comments
 * 5445 (con.) || HITSP/C80 -- Clinical Document and Message Terminology || Multiple Comments || 2.2.1.3.3.12 Medication Vehicle
 * 5445 (con.) || HITSP/C80 -- Clinical Document and Message Terminology || Multiple Comments || 2.2.1.3.8.1 Admission Source
 * 7703 || HITSP-C32 - Registration and Medication History || Latest version of C32 is internally inconsistent || **{_}Original:_** A serious error was introduced into C32 with version 2.4, when that Component was restructured with references to document sections, which are defined in HITSP C83. This error results in C32 being internally inconsistent, and in essence, unimplementable.
 * {_}HITSP:_** CMHR was unable to contact commenter for clarfication, needs discussion. || These issues were later addressed. Any specific inconsistencies will be further addressed by this project, but this comment supplies no data to further that effort. || Richard Franck ||
 * 7703 (con.) || HITSP-C32 - Registration and Medication History || Latest version of C32 is internally inconsistent || Two examples:
 * 7867 || HITSP/C154 -- HITSP Data Dictionary -- Section 2.1.2.6 ALLERGY/DRUG SENSITIVITY || ALLERGY/DRUG SENSITIVITY || **{_}Original:_** 6.04 Product Coded
 * {_}HITSP:_** Cindy Levy clevy@patriottechnologies.net 12/17/2009 10:03:36
 * 7868 || HITSP/C80 -- Clinical Document and Message Terminology Component -- Section 2.1.2.7 CONDITION || CONDITION || 7.04 Problem Code
 * 8838 || HITSP/C154 -- HITSP Data Dictionary || data element consistency || All HITSP data elements and CDA templates should be thoroughly reviewed for consistency (internal consistency, consistency across HITSP/IHE/HL7). Conflicting template definitions will pose a significant implementation challenge. HITSP, IHE, and HL7 should develop a uniform process for template development, template formalism, template publishing.
 * 8842 || HITSP/C83 -- CDA Content Modules Component || Template consistency || All HITSP data elements and CDA templates should be thoroughly reviewed for consistency (internal consistency, consistency across HITSP/IHE/HL7). Conflicting template definitions will pose a significant implementation challenge. HITSP, IHE, and HL7 should develop a uniform process for template development, template formalism, template publishing.
 * 9079 || HITSP/TN901 - Clinical Documents || General Guidance on use of CDA || None of the specifications provide general guidance for exchange of CDA documents within the US Realm. The existing guidelines apply to specific types of documents, however, there remains a gap defining minimal requirements for any document type. TN901 supplies some of the general considerations, however, does not provide a “minimum necessary” for any CDA document. For example, the guidance would define a template for the CDA header to be used in all US-realm documents.
 * 11039 || HITSP/C83 -- CDA Content Modules Component -- Section 2.2.2.15 Result and Section 3.2 Template Identifiers || C83 Result Entry Template ID || The template ID for the Result Entry changed from v1.1 to v2.0 (it went
 * __ **Issue ID** __ || __ **Document Reference** __ || __ **Issue Title** __ || __ **Comment/HITSP** __ || __ **Disposition Description** __ || __ **Comment Originator** __ ||
 * 5241 || HITSP/C80 -- Clinical Document and Message Terminology -- Table 2.2.1 Cross reference the Program Team || HL7 vs HITSP OIDs? || **Original:** Why are HITSP value sets identified by HL7 OIDs?
 * HITSP:** KWB -- In some cases, HITSP selects a value set (e.g. as defined by HL7), and in others, it creates it. The latter use HITSP defined OIDs, the former HL7. || We expect HITSP OIDs to be registered in the HL7 Registry when used by HITSP. HITSP does not want to assign an OID to a value set that already has an OID. Note that ANSI is the assigning authority to give HITSP and OID. This will be referred to the IRT for a policy decision. || Ed Larson ||
 * 5639 || HITSP/C83 -- CDA and CCD Content Modules - Section 2.2.2.8 || Generic drug || Looks like there are data elements to specify quantities, repeats, etc. can you also specify when a generic drug || **HITSP:** Emailed author requesting clarification ||  ||
 * 7069 || HITSP/C83 -- CDA and CCD Content Modules - Section 2.2.2.6 || CDA Content Modules - Allergy/Drug Sensitivity || Data element ID 6.02 is unclear and seems to conflict with CCD conformance statement CONF-267        . CCD says to populate observation/value with an AlertTypeCode (e.g. "allergy", "adverse reaction"), whereas C83's C83-[144] says to populate observation/code (and not observation/value) with an Allergy/Adverse Event type code (e.g. "drug allergy"). I believe HITSP may have intended to say that this value belongs in observation/value, not observation/code. The example in Figure 2.2.2.6-1 shows an observation in EVN mood with a code but no value, whereas I would recommend that observation/code here be "ASSERTION", and observation/value be drawn from the referenced value set. || Don Van Syckle don@dvsconsult.com 12/21/2009 15:12:05
 * 7703 || HITSP-C32 - Registration and Medication History || Latest version of C32 is internally inconsistent || I think there is a further philosophical issue at play here as well, which is this: There seems to have been a notion in the creation of the C83 that the IHE PCC Technical Framework represents the “ideal” for describing CDA content profiles, and I think that notion needs to be challenged. The CCD is a clear, concise, and easily implementable specification. The references to the section templates defined by the IHE PCC Framework do not add anything to the C32 specification; in fact, they detract from it by making the overall specification more complicated, and more difficult to trace to its original standards -- and this would be the case even if the issue of conflicting specifications between IHE and CCD did not exist. || **HITSP:** CMHR was unable to contact commenter for clarfication, needs discussion. || Richard Franck ||
 * 8242 || HITSP/TN903 -- Data Architecture Technical Note || Various Comments || 1. The HITSP data architecture is layered (it is not hierarchical, since a data element can be in multiple components and in multiple modules).
 * 8350 || HITSP/C83 -- CDA Content Modules Component -- Section 2.2.2.13 Immunization || Incorrect template ID in Immunization example || In Figure 2-18 there's a misleading template ID reference in the Immunization example.
 * 8801 || Multiple Documents || Difficulty in reading documents || In general, the documents were difficult to review since they have references to several other documents and standards. Unfortunately, it is anticipated that significant information for review and comment may be inadvertently overlooked while trying to manage the documents interactions. ||  || Donna Carter ||
 * 8818 || Multiple Documents || Code and Vocabulary Requirements || There is concern that these documents are folding in significant code and vocabulary changes that are not currently established with the installed base for electronic exchange of laboratory data. For example, the changes requested to support LOINC for order codes, Snomed, UCUM, and OIDs could require significant changes and resource allocation for infrastructure for both the sender and receiver of the order data. This will certainly challenge the adoptability of the guide in advance of the surge for Meaningful Use.
 * 8835 || HITSP/C154 -- HITSP Data Dictionary || Data Element Identifiers || There are already field identifiers assigned by HL7. HITSP is assigning fields identifiers as well, sometimes the field is based on one document and sometimes another and the field prefix changes even within the document. This is overly complex and not necessary. HITSP should adopt HL7 field identifiers. If not, have a consistent process to identify fields so that one does not have to cross walk among multiple documents.
 * 9033 || HITSP/C83 -- CDA Content Modules Component -- Section 2.2.2.18.2 Pedigree || Imbedded image of pedigree || Optimally a pedigree chart would be generated from processible content stored in the CDA document, not a rendered image. Consequently the need for an embedded image is transient and should not be part of the standard. Therefore, if needed, the CDA should reference a location for the image or an external resource that can construct the pedigree from the stored data in a standard format (e.g., GEDCOM XML 6.0 or XGenML). || **HITSP:** Need additional communication from the commenter. ||  ||
 * 9080 || Multiple Documents || Roadmap for full patient record || HITSP should publish a Roadmap describing how the full patient record (the “Health Story”) is to be exchanged. To date, the use-case driven (bottom up) requirements have not provided this comprehensive picture. Such guidance should be consistent with an ontology of document types such that any clinical document can be identified with an ontology according to type.
 * 10032 || HITSP/C154 -- HITSP Data Dictionary -- Section 11.x || Need ‘negation’ data element || For the expresion of negation using HL7 ActMood (Tense 11.03) with Reason (11.02), there is no data element for negation IND = 'True'. It seems there should be another 11.x data element for this ||  || Lori Fourquet ||
 * 10971 || HITSP/C83 -- CDA Content Modules Component -- Section 1.1, 2.2 || Term Component is used in mulitply ways, needs clarifications || The use of the term “Components” here is confusing between HITSP Component and this new definition = Module. In future releases, I would talk about a library of Modules, organized for simplified navigation. ||  || Ed Larsen ||
 * 10973 || HITSP/C83 -- CDA Content Modules Component -- Figure 2-28 || Correct examples in table Figure 2 28 Administration Timing Examples || <period value='12' unit='h' /> with comment - Based on the rule, shouldn’t the value 'h' be '2' since institutionSpecified = true?
 * 11037 || HITSP/C83 -- CDA Content Modules Component -- Section 2.2.2.16 Encounters (Table 2-21). || Slight mismatch between C83 and C154 (minor typo) || There is a slight mismatch between the Data Element identifiers given in C154 (Data Dictionary) and C83. There are two 16.20 elements labeled in C83. The second 16.20 (Facility Name) should be 16.18 per C154. ||  || Andrew McCaffrey ||
 * 11038 || HITSP/C154 -- HITSP Data Dictionary || Definition of 17.03 || The definition of 17.03 is "Free text describing the procedure."
 * 11040 || HITSP/C83 -- CDA Content Modules Component -- Section 2.2.2.5 Insurance Provider; Section 3.2 Template Identifiers || C83 Insurance Provier Template ID || This is similar to my last comment. I think the same issue affects "Insurance Provider" although it's a little more ambiguous. The text at the top of Section 2.2.2.5 gives the (new) template ID as ...83.5.1. But conformance statement C83-[DE-5-CDA-1       ] still uses ...83.5 as does the example in 2-14 and the table in Section 3.2.
 * 11041 || HITSP/C83 -- CDA Content Modules Component -- Section 2.2.2.7.4 Problem Name Constraints || Mislabeled Conformance Statement || I think what is now currently labeled C83-[DE-7.04-1] in Section
 * 11042 || HITSP/C83 -- CDA Content Modules Component -- Appendix 3.1 HITSP Constraints Define In This Document || Erroneous entry in Appendix 3.1 || I believe the first entry in C83 Appendix 3.1 has been included by mistake. My understanding is that the intent was to collect all the conformance statements in one place. However, I think a conformance statement from Section 1.5 Document Conventions.was accidentally pulled in. Section 1.5.2 has an example conformance statement which was supposed to demonstrate the format of labeling to the reader. I don't think it was intended to be acted upon by an implementor. ||  || Andrew McCaffrey ||
 * 11043 || HITSP/C83 -- CDA Content Modules Component Section -- Section 2.2.2.8 Medication || Two conformance statements have the same label || Two different conformance statements have the same label in section 2.2.2.8.17 and 2.2.2.8.18:
 * C154-[DE-8.20-1]: The medication status MAY be recorded using the CCD Medication Status observation using the value set defined in the CCD
 * C154-[DE-8.20-1] The indication SHALL be coded as specified in HITSP/C80 Section 2.2.3.1.1 Problem
 * 11044 || HITSP/C83 -- CDA Content Modules Component -- Section 2.2.2.8 Medications || All labels in Medication Indication constraints are off by one || (This is actually a follow-up to our previous bug report, 11043.)
 * 11045 || HITSP/C83 -- CDA Content Modules Component -- Section 2.2.2.14 Vital Signs || Typo in Vital Signs/Result Type Constraint || Conformance statement C154-[DE-14.03-1] states: "Vital signs SHOULD be coded as specified in HITSP/C80 Section 2.2.3.6.4 Vital Sign Result Type".
 * 10033 || HITSP/C83 -- CDA Content Modules Component -- Results section || To be able to bind indication for orders to order and result || We need to be able to bind indication for order to the order or to the result or to both.
 * 11049 || HITSP/C83 -- CDA Content Modules Component - Section 2.2.2.16 Encounter || Data Element 16.06 Admission Source -- Incorrect CDA Data Location || In Table 2-21, Admission Source is Data Element 16.06. The CDA Data Element is listed as being "cda:participant[@typeCode="ORG"]/cda:code".