CDA+-+Initial+Publication+Requirements

Click here to return to the Merged Publication Considerations.
The table below includes the publication requirements that we agreed to on our 2/9 call. The requirements have been allocated to the April 1 ballot deadline, or the July 15 publishing deadline based on my (Keith's) assessment of what is needed for ballot and final publication of the implementation guide. These are not hard and fast decisions. They have been started to spark discussion. Some of these requirements may be delegated to other workgroups.

On our next call, I'd like to do two things:
 * 1) Confirm the allocation and/or delegation of these requirements to the release schedule
 * 2) Discuss what decisions must be made to fulfill each requirement, and what the alternatives are. For example, in the first case, we should establish what the normative form is. Please come to this meeting with suggestions for how to meet each requirement, and an idea of what resource committments must be available to accomplish it by the deadlines.


 * __** # **__ || __** Requirement **__ || **.** __** 4/1 **__ **.** || **.** __** 7/15 **__ **.** || __** Comments **__ ||
 * **1** || In order to adjudicate issues, there must be single "normative" publication format which is the official specification ||= **X** ||=  ||   ||
 * **2** || A richly linked, searchable multimedia format must be available to enable implementers to quickly locate needed information ||=  ||= **X** ||   ||
 * **3** || 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 ||= **X** ||=  ||   ||
 * **4** || 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** ||= **B** ||  ||
 * **5** || Auxiliary materials will be supplied in standards based formats to support use with off-the-shelf tools. For example, XSD, Schematron, or XMI files. ||= **X** ||= **X** ||  ||
 * **6** || Tabular data will be made available in either CSV or XML formats to enable easy import into off-the-shelf products ||= **X** ||= **X** ||  ||
 * **7** || 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 ||
 * **8** || Publication formats must be downloadable in their entirety without need for outside web services or network connectivity to enable disconnected access ||= **X** ||=  || Ballot will be downloadable ||
 * **9** || The Implementation Guide must have testable conformance criteria to ensure conformance. NOTE: Testable does not imply that ALL tests can be automated ||= **X** ||=  || Defer to Validation ||
 * **10** || Conformance criteria must be expressed in a computable form, and made available as data/models to enable other systems to use the information in innovative ways ||= **X** ||=  || Defer to Validation ||
 * **11** || Conformance criteria will be divided into two sets, schema validation, and functional validation to support input validation and functional testing as separate capabilities ||= **X** ||=  || Defer to Validation ||
 * **12** || "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 ||= **X** ||=  ||   ||
 * **13** || 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? ||
 * **14** || Conformance criteria will generally be organized in the order in which information usually appears in the documents exchanged for ease of access ||= **X** ||=  ||   ||
 * **15** || Conformance rules will provide an explanation of the purpose of the requirement to help implementers understand what the rules are trying to accomplish ||= **X** ||= **?** ||  ||
 * **16** || Conformance rules must provide examples of conforming results, and should provide examples of non-conforming content when that will aid implementation ||= **X** ||= **?** || Could move, as is not normative. ||
 * **17** || 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 ||= **X** ||=  || Conforming examples by April, others by July ||
 * **18** || The guide will provide necessary information in multiple forms: UML models of conforming content, conformance statements in English prose, and where possible, in tabular form to enable access via a broad variety of learning styles, as well as examples of conforming content ||=  ||= **X** ||   ||
 * **19** || Only one form of presentation will be normative, others will be informative, to ensure that conflicts between representations can be adjudicated ||= **X** ||=  ||   ||
 * **20** || Automated solutions will be used to generate the multiple representations, to ensure consistency of information in the guide ||= **X** ||=  ||   ||