Difference between revisions of "PCC Document Content Profiles"
Line 35: | Line 35: | ||
=Structure of a PCC Content Module Document= | =Structure of a PCC Content Module Document= | ||
+ | |||
+ | =Relationship Between PCC Content Module Documents= | ||
=Struture of Section Content Module= | =Struture of Section Content Module= | ||
=Structure of Entry Content Module= | =Structure of Entry Content Module= |
Latest revision as of 17:36, 28 July 2009
Introduction
This page is a workspace to create material that describes how a human (person, analyst) would interpret a PCC Document Content Profile for purposes of developing software or a system for reading or writing such a document.
In this material, one tool we will use is an analogy between Document Content Modules and classes in Object Oriented programming. The reader does not need to be an OO expert, but at least familiar with the concepts and terms.
ITI and Laboratory Disclaimer
This material only applies to documents defined by IHE PCC. IHE ITI and IHE Laboratory have defined content modules based on CDA R2 using a different model.
Relationship to Existing Standards
Document Content Module is a CDA Release 2.0 Document
Each PCC Document Content Module is a CDA Release 2.0 Document. That means each Document Content Module
- inherits all constraints and requirements defined by HL7 CDA R2
- does not relax any constraints or requirements defined by HL7 CDA R2
- may impose further definitions and requirements
Relationship to HL7 CCD
Overview of Content Modules
The final documents use HL7 CDA concepts as building blocks. Each building block is considered a content module on its own. Content modules are defined at different levels of granularity:
- document
- section
- entry
- header
Each PCC Document Content Module is defined by requirements using these building blocks.
Each content module has a name which is its template identifier. Template identifiers are most often OIDs defined by PCC, but can be defined by other organizations if the content module is taken from another standard.
Each content module has a definition that list requirements for the module. Like classes, content modules may inherit features and requirements of other content modules of the same type. This is accomplished in content module by defining a parent content module by referencing the template identifier of that parent.
- Content modules are not required to have a parent module.
- Content mdules may have only a single parent.
- Content modules may have more than one ancestor (but may not violate the one parent constraint).