CDA+-+Merged+Publication+Considerations

 toc =1. Requirements= The 4/1 column was updated to include an assessment of whether we met this requirement in the ballotted document. Determine form of template, including alphabetical, hierarchical or containment Decide between documents and section grids || (Back to the Top) =2. Recommendations=
 * Note:** An initial set of requirements was proposed by Keith Boone.
 * __**#**__ || __**Requirement**__ || ** . __4/1__ . ** || ** . __7/15__ . ** || __ **Comments** __ ||
 * **1** || In order to adjudicate issues, there must be single "normative" publication format which is the official specification ||= **Achieved** ||=  ||   ||
 * **2** || Formal constraints must be decided upon for the new implementation guide ||= **Achieved** ||=  ||   ||
 * **3** || A standard vocabulary, in terms of value sets, must be applied for the new implementation guide ||= **Achieved** ||=  || By reference or value? ||
 * **4** || A printable format containing all content and containing a table of contents with page numbers must also be available to enable implementers access to a printed format to enable access ||= **Achieved** ||=  ||   ||
 * **5** || Publication formats must be downloadable in their entirety without need for outside web services or network connectivity to enable disconnected access ||= **Achieved** ||=  || Ballot will be downloadable ||
 * **6** || The guide will use readily understandable terms and methods, or when domain specific terms or methods are used, will explain the domain specific content to enable implementers who are not familiar with the domain (e.g., HL7 V3 Modeling) to understand what is being said ||= **Needs Work** ||=  || Conforming examples by April, others by July ||
 * **7** || Only one form of presentation will be normative, others will be informative, to ensure that conflicts between representations can be adjudicated ||= **Achieved** ||=  ||   ||
 * **8** || The new implementation guide (IG) must collapse the numerous CDA IGs upon which C32 and other clinical content specifications are based, to present a single "collapsed" view. ||= **Needs Work** ||=  || How much of CDA must be included? ||
 * **9** || "Schema" validation criteria will identify invalid document exchanges without requiring any specific knowledge of inputs. A document that is not "schema" valid is not a communication conforming to the implementation guide ||= **Did Not Achieve** ||  ||   ||
 * **10** || Automated solutions will be used to generate the multiple representations, to ensure consistency of information in the guide ||= **Partial. Needs Work** ||=  ||   ||
 * **11** || Auxiliary materials, including A) sample files, conformance data, Schematron, B) schema, UML models, et cetera, must be supplied with all delivery formats to further support implementation ||= **A**
 * Partial. Did not Produce Conformance Data and Schematron.** ||= **B** ||  ||
 * **12** || Auxiliary materials will be supplied in standards based formats to support use with off-the-shelf tools. For example, XSD, Schematron, or XMI files. ||= **Needs Work. Only example files were produced.** ||= **X** ||  ||
 * **13** || Tabular data will be made available in either CSV or XML formats to enable easy import into off-the-shelf products ||= **No external table files were produced.** ||= **X** ||  ||
 * **14** || Conformance criteria will generally be organized in the order in which information usually appears in the documents exchanged for ease of access ||= **Achieved** ||=  ||   ||
 * **15** || Conformance rules will provide an explanation of the purpose of the requirement to help implementers understand what the rules are trying to accomplish ||= **Needs Work.** ||= **?** ||  ||
 * **16** || Conformance rules must provide examples of conforming results, and should provide examples of non-conforming content when that will aid implementation ||= **Needs Work. Have conforming examples, but not non-conforming.** ||= **?** || Could move, as is not normative. ||
 * **17** || The guide will provide necessary information in multiple views to enable access via a broad variety of learning styles, as well as examples of conforming content. Refer to Tabular Format Proposal \\
 * Tree views
 * Tabular views
 * Graphical views
 * Summary views
 * UML models of conforming content
 * Conformance statements in English prose || **Did Not Achieve** ||  || For summary view:
 * **18** || A richly linked, searchable multimedia format must be available to enable implementers to quickly locate needed information ||=  ||= **X** || MDHT May do this. ||
 * **19** || XML formats used to convey tabular data must be well documented, preferable standard formats, and should be easy to use with off-the-shelf products (MIF doesn't count) ||=  ||= **X** || No XML Tabular Data in Ballot Package ||
 * **20** || Functional validation criteria will identify specific requirements or capabilities required of document creators and document receivers (what IHE calls the content creator and content consumer actors in its profiles) ||=  ||= **X** || ? Is Functional Criteria part of Ballot? ||
 * **21** || Consider greenCDA template requirements? ||=  ||= **X** ||   ||
 * **22 . ** || Consider form generation template requirements ||=  ||= **X** ||   ||

2.1 Normative Publication
The normative publication will be a PDF document with page numbers, line numbers and table of contents. The publication may be produced from multiple source formats (DITA, Word, et cetera), as needed. The goal is to reach a point where the normative output will come from tools.

This addresses the requirement (1) that there be a normative artifact that is suitable for balloting and adjudication of issues.

It addresses the requirement (4) there be a printable format.

It addresses the requirement (5) that the format be downloadable.

This section identifies the PDF format as being the normative publication (7).

2.2 Constraint representation

 * Conformance terms (SHALL, SHOULD, MAY, NEED NOT, SHOULD NOT, SHALL NOT) will be described at the beginning of the document.
 * Constraints will be described in English prose (similar to what was done for CCD). Shorter notational formats expressing cardinality constraints should be used in tabular representations of the constraints.
 * Each constraint statement will address requirements of a single data element.
 * Constraints will use XPath notation to identify requirements of the XML. Developers are concerned with what is in the XML, and XPath is a familiar way to identify XML elements.
 * XPath expressions will appear in a monospaced font, and will appear as commonly written (e.g., without embedded spaces between nodes).
 * Each set of constraints for a template will define an "anchor point" or context to which the XPath expressions relate to support simple communication of those expressions.
 * The anchor point will be clearly defined in uniquely named variable for each template, and that variable will be used as the context for the XPath expression.
 * Constraints on use of a single code will be simply written to indicate the code, the display name, a human readable name of the coding system, and the OID used to identify that coding system. The use of the terms STATIC or DYNAMIC will not appear.
 * Constrains on use of value sets will be simply written to indicate the required or recommended value set by a human readable name and an identifier.
 * The publication will provide appropriate bookmarks and links to make it easy to navigate from a value set constraint to the value set itself.
 * Similar to existing IGs, but include required portions of CDA. (Will not include ALL of CDA).

2.3 Sample XML

 * One valid sample for each template

2.4 Graphical representation

 * Graphical model fragment
 * greenCDA graphic schema representation

2.5 Summary views
(Back to the Top)
 * Templates: alphabetical, hierarchical, containment;
 * Document vs section grid;
 * Vocabulary (e.g. value sets).

=3. Examples=

Viral hepatitis history observation [TemplateId: 2.16.840.1.113883.10.20.15.3.32; template context: observation]

This clinical statement represents the history of cases of viral hepatitis that the subject of the case report has been diagnosed with other than the one being reported. This template is a simple problem observation template modeled after CCD problem observation and problem status templates to show the history of other viral hepatitis problems.
 * 1) Implies CCD Problem observation Template (TemplateId: 2.16.840.1.113883.10.20.1.28).
 * 2) **SHALL** contain 1..1 **@classCode** = OBS "Observation" (CodeSystem: 2.16.840.1.113883.5.6 HL7ActClass) **STATIC** (CONF: 1189).
 * 3) **SHALL** contain 1..1 **@moodCode** = EVN "Event" (CodeSystem: 2.16.840.1.113883.5.1001 HL7ActMood) **STATIC** (CONF: 1190).
 * 4) **MAY** contain 0..* **id** (CONF: 1191).
 * 5) **SHALL** contain 1..1 **code** = ASSERTION (CodeSystem: 2.16.840.1.113883.5.4 HL7ActCode) **STATIC** (CONF: 1192).
 * 6) **SHALL** contain 1..1 **statusCode** = completed (CodeSystem: 2.16.840.1.113883.5.14 HL7ActStatus) **STATIC** (CONF: 1193).
 * 7) **SHOULD** contain 0..1 **effectiveTime** (CONF: 1194).
 * 8) **SHALL** contain 1..1 **value** (CD), which **SHALL** be selected from ValueSet 2.16.840.1.114222.4.11.3230 Disease Type (Hepatitis) **DYNAMIC** (CONF: 1195).
 * 9) **SHOULD** contain 0..1 **entryRelationship**(CONF: 1196) (specialized branch), which
 * 10) **SHALL** contain 1..1 **@typeCode** = REFR "Refers to" (CodeSystem: 2.16.840.1.113883.5.1002 HL7ActRelationshipType) **STATIC** (CONF: 1197).
 * 11) **SHALL** contain 1..1 **CCD Problem status observation** (templateId: 2.16.840.1.113883.10.20.1.50) (CONF: 1198).

**//Figure: Viral hepatitis history observation example//**

**//Table: Templates Organized By Report//** (Back to the Top)
 * **__Template OID__** || **__Type__** || **__Template Title__** ||
 * **2.16.840.1.113883.10.20.15.1.4** || **Document . ** || **Tularemia PHCR CDA R2 report** ||
 * ... **2.16.840.1.113883.10.20.15.2.2** || **Section** || **PHCR Encounters section** ||
 * .......2.16.840.1.113883.10.20.1.21 || Entry || CCD Encounter activity ||
 * ...........2.16.840.1.113883.10.20.1.45 || Entry || CCD Location participation ||
 * ... **2.16.840.1.113883.10.20.15.2.19** || **Section** || **Tularemia PHCR clinical information section** ||
 * .......2.16.840.1.113883.10.20.15.3.42 || Entry || Patient condition -- alive ||
 * .......2.16.840.1.113883.10.20.15.3.17 || Entry || Patient condition -- deceased ||
 * .......2.16.840.1.113883.10.20.15.3.46 || Entry || Tularemia case observation ||
 * ...........2.16.840.1.113883.10.20.1.50 || Entry || CCD Problem status observation ||
 * ...........2.16.840.1.113883.10.20.15.3.44 || Entry || Location of lesion observation ||
 * ...........2.16.840.1.113883.10.20.15.3.45 || Entry || Tularemia signs and symptoms ||
 * ... **2.16.840.1.113883.10.20.15.2.21** || **Section** || **Tularemia PHCR relevant diagnostic tests and/or laboratory data section** ||
 * .......2.16.840.1.113883.10.20.15.3.5 || Entry || Imaging observation ||
 * .......2.16.840.1.113883.10.20.15.3.51 || Entry || Tularemia result observation ||
 * ...........2.16.840.1.113883.10.20.15.3.2 || Entry || Specimen collection procedure ||
 * ...........2.16.840.1.113883.10.20.15.3.10 || Entry || Susceptibility result ||
 * .......2.16.840.1.113883.10.20.15.3.52 || Entry || Tularemia result organizer ||
 * ...........2.16.840.1.113883.10.20.15.3.2 || Entry || Specimen collection procedure ||
 * ...........2.16.840.1.113883.10.20.15.3.51 || Entry || Tularemia result observation ||
 * ...............2.16.840.1.113883.10.20.15.3.2 || Entry || Specimen collection procedure ||
 * ...............2.16.840.1.113883.10.20.15.3.10 . || Entry || Susceptibility result ||
 * ... **2.16.840.1.113883.10.20.15.2.18** || **Section** || **Tularemia PHCR social history section** ||
 * .......2.16.840.1.113883.10.20.15.3.3 || Entry || Geotemporal history observation ||
 * .......2.16.840.1.113883.10.20.15.3.6 || Entry || Most recent time arrived in USA observation ||
 * .......2.16.840.1.113883.10.20.15.3.7 || Entry || Occupation observation ||
 * .......2.16.840.1.113883.10.20.15.3.8 || Entry || Pregnancy observation ||
 * ...........2.16.840.1.113883.10.20.15.3.1 || Entry || Estimated date of delivery ||
 * .......2.16.840.1.113883.10.20.15.3.9 || Entry || Race observation ||
 * .......2.16.840.1.113883.10.20.15.3.43 || Entry || Tularemia possible exposure location and type ||
 * ... **2.16.840.1.113883.10.20.15.2.20** || **Section** || **Tularemia PHCR treatment information section** ||
 * .......2.16.840.1.113883.10.20.15.3.48 || Entry || Tularemia therapeutic regimen ||
 * ...........2.16.840.1.113883.10.20.15.3.47 || Entry || Tularemia treatment given ||
 * ...........2.16.840.1.113883.10.20.15.3.50 || Entry || Tularemia treatment not given ||

3.2.1 RoseTree (tree)
(Back to the Top)

3.2.2 HL7 V2 Message Workbench (tree)
(Back to the Top)

3.2.3 MDHT UML Table View (tree and table)
(Back to the Top)

3.3.1 HL7 HMD (tabular)
(Back to the Top)

3.3.2 HITSP (tabular)
(Back to the Top)

3.4.1 CCD (graphical)
(Back to the Top)
 * //CDA R2 clinical statement model for problems//**

3.4.2 greenCDA schema (graphical)
(Back to the Top)

3.4.3 MDHT UML Class Diagram (graphical)
Template classes for CCD Problems Section. (Back to the Top)

3.4.4 NHS SMD (graphical)
(Back to the Top)

3.4.5 openEHR (graphical)
(Back to the Top)