This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "CDA Implementation Guide Quality Criteria"

From HL7Wiki
Jump to navigation Jump to search
Line 36: Line 36:
 
** A stand alone complete sample file is present
 
** A stand alone complete sample file is present
  
* Extensions [suggested addition:LRN]
+
* Extensions [suggested addition:Lisa Nelson]
 
** A table summarizes all extensions
 
** A table summarizes all extensions
 
** Modified Schema including all extensions
 
** Modified Schema including all extensions
 +
 +
* Validation Guidance [suggested addition:Lisa Nelson, Virinder Batra]
 +
** A table listing the available validation mechanisms
 +
** Guidance on how to handle situations where a document instance validates under one mechanism, but generates errors under a different recommended validation mechanism.

Revision as of 00:19, 24 October 2012

Return to SDWG page.


Project Scope Statement (approved by SDWG, pending TSC approval): http://wiki.hl7.org/index.php?title=File:HL7_Project_Scope_Statement_v2012_Quality_Criteria_for_CDA_IGs.06Sept2012.docx


NOTE: This is a draft starter set of CDA Implementation Guide Quality Criteria. HL7 Structured Documents WG is putting together a Project Scope Statement to flesh these out in more detail. For now, think of this page more as a scratch pad where anyone can list their suggestions.


Suggested CDA Implementation Guide Quality Criteria

  • Title page
    • Title is specified
    • Realm is specified
    • Ballot type (e.g. DSTU vs. ??) is specified
    • Date is specified
    • HL7 logo is present
  • Templates
    • Each template has a narrative description
    • Constraints are ordered per the CDA schema
  • Version? Usage? Edition?
    • Guide specifies both normative and inferred or inherited constraints, but clearly differentiates between them with visual cues
    • or,
    • Guide is published both in a concise version for normative purposes, including only constraints unique to the guide, and in a verbose version for developers, making all constraints explicit, whether unique to the guide or inherited
  • Value sets
    • Are linked to templates using normative binding syntax
    • Each value set is referenced via a value set OID
    • Each code in a value set has a specified code system OID
    • SNOMED CT value sets adhere to TermInfo conformance rules
  • Examples
    • Inline examples are present for all templates
    • A stand alone complete sample file is present
  • Extensions [suggested addition:Lisa Nelson]
    • A table summarizes all extensions
    • Modified Schema including all extensions
  • Validation Guidance [suggested addition:Lisa Nelson, Virinder Batra]
    • A table listing the available validation mechanisms
    • Guidance on how to handle situations where a document instance validates under one mechanism, but generates errors under a different recommended validation mechanism.