PCC Document Content Profiles

From IHE Wiki
Revision as of 17:26, 28 July 2009 by Smoore (talk | contribs) (New page: __TOC__ =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 s...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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

Building Blocks

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).