PCC Public Comment Drafts

Volume 2

HIMSS and RSNA
Integrating the Healthcare Enterprise

IHE Patient Care Coordination

Technical Framework
Volume 2

Revision 2.0
2006-2007

Comment

Preface to Volume 2

Intended Audience

The intended audience of this document is:

• Technical staff of vendors planning to participate in the IHE initiative
• IT departments of healthcare institutions
• Experts involved in standards development
• Anyone interested in the technical aspects of integrating healthcare information systems

Related Information for the Reader

The reader of volume 2 should read or be familiar with the following documents:

• Volume 1 of the Cross-Enterprise Document Sharing (XDS) Integration Profile documented in the ITI Infrastructure Technical Framework
  (See http://www.ihe.net/Technical_Framework/index.cfm ).
• Volume 1 of the Notification of Document Availability (NAV) Integration Profile documented in the ITI Infrastructure Technical Framework
  (See http://www.ihe.net/Technical_Framework/index.cfm ).
• Volume 1 of the Audit Trail and Node Authentication (ATNA) Integration Profile documented in the ITI Infrastructure Technical Framework
  (See http://www.ihe.net/Technical_Framework/index.cfm ).
• HL7 Clinical Document Architecture Release 2: Section 1, CDA Overview.
• Care Record Summary – Implementation Guide for CDA Release 2 (US Realm): Section 1
• Presentations from IHE Workshop: Effective Integration of the Enterprise and the Health System - June 28–29, 2005: http://www.ihe.net/Participation/workshop_2005.cfm, June 2005:
• for a RHIO-3.ppt Leveraging IHE to Build RHIO Interoperability
• Cross-Enterprise Document Sharing (XDS)
• Notification of Document Availability (NAV)
• Educ.ppt Patient Care Coordination
• Use Cases for Medical Summaries
• Ovrw.ppt Patient Care Coordination - Overview of Profiles

How this Document is Organized

Section 1 is the preface, describing the intended audience, related resources, and organizations and conventions used within this document.

Section 2 provides an overview of the concepts of IHE actors and transactions used in IHE to define the functional components of a distributed healthcare environment.

Section 3 defines transactions in detail, specifying the roles for each actor, the standards employed, the information exchanged, and in some cases, implementation options for the transaction.

Section 4 defines a set of payload bindings with transactions.

Section 5 defines the content modules that may be used in transactions.

Conventions Used in this Volume

This document has adopted the following conventions for representing the framework concepts and specifying how the standards upon which the IHE Technical Framework is based should be applied.

The Generic IHE Transaction Model

Transaction descriptions are provided in section 4. In each transaction description, the actors, the roles they play, and the transactions between them are presented as use cases.

The generic IHE transaction description includes the following components:

• Scope: a brief description of the transaction.
• Use case roles: textual definitions of the actors and their roles, with a simple diagram relating them, e.g.:

Use Case Role Diagram

• Referenced Standards: the standards (stating the specific parts, chapters or sections thereof) to be used for the transaction.
• Interaction Diagram: a graphical depiction of the actors and transactions, with related processing within an actor shown as a rectangle and time progressing downward, similar to:

Interaction Diagram

The interaction diagrams used in the IHE Technical Framework are modeled after those described in Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide, ISBN 0-201-57168-4. Simple acknowledgment messages are omitted from the diagrams for brevity.

• Message definitions: descriptions of each message involved in the transaction, the events that trigger the message, its semantics, and the actions that the message triggers in the receiver.

Copyright Permissions

Health Level Seven, Inc., has granted permission to the IHE to reproduce tables from the HL7 standard. The HL7 tables in this document are copyrighted by Health Level Seven, Inc. All rights reserved.

Material drawn from these documents is credited where used.

How to Contact Us

IHE Sponsors welcome comments on this document and the IHE initiative. They should be directed to the discussion server at http://forums.rsna.org or to:

Didi Davis
Director of Integrating the Healthcare Enterprise
230 East Ohio St., Suite 500
Chicago, IL 60611
Email: ihe@himss.org

Introduction

This document, the IHE Patient Care Coordination Technical Framework (PCC TF), defines specific implementations of established standards. These are intended to achieve integration goals that promote appropriate exchange of medical information to coordinate the optimal patient care among care providers in different care settings. It is expanded annually, after a period of public review, and maintained regularly through the identification and correction of errata. The latest version of the document is always available via the Internet at http://www.ihe.net/Technical_Framework/index.cfm , where the technical framework volumes specific to the various healthcare domains addressed by IHE may be found.

The IHE Patient Care Coordination Technical Framework identifies a subset of the functional components of the healthcare enterprises and health information networks, called IHE actors, and specifies their interactions in terms of a set of coordinated, standards-based transactions.

The other domains within the IHE initiative also produce Technical Frameworks within their respective areas that together form the IHE Technical Framework. Currently, the following IHE Technical Framework(s) are available:

• IHE IT Infrastructure Technical Framework
• IHE Cardiology Technical Framework
• IHE Laboratory Technical framework
• IHE Radiology Technical Framework
• IHE Patient Care Coordination Technical Framework

Where applicable, references are made to other technical frameworks. For the conventions on referencing other frameworks, see the preface of this volume.

Relationship to Standards

The IHE Technical Framework identifies functional components of a distributed healthcare environment (referred to as IHE actors), solely from the point of view of their interactions in the healthcare enterprise. At its current level of development, it defines a coordinated set of transactions based on standards (such as HL7, IETF, ASTM, DICOM, ISO, OASIS, etc.) in order to accomplish a particular use case. As the scope of the IHE initiative expands, transactions based on other standards may be included as required.

Each transaction may have as its payload one or more forms of content, as well as specific metadata describing that content within the transaction. The specification of the payload and metadata about it are the components of a Content Integration Profile. The payload is specified in a Content Module, and the impacts of any particular payload on a transaction are described within a content binding. The payloads of each transaction are also based on standards (such as HL7, IETF, ASTM, DICOM, ISO, OASIS, etc.), again, in order to meet the needs of a specific use case.

In some cases, IHE recommends selection of specific options supported by these standards. However, IHE does not introduce technical choices that contradict conformance to these standards. If errors in or extensions to existing standards are identified, IHE's policy is to report them to the appropriate standards bodies for resolution within their conformance and standards evolution strategy.

IHE is therefore an implementation framework, not a standard. Conformance claims for products must still be made in direct reference to specific standards. In addition, vendors who have implemented IHE integration capabilities in their products may publish IHE Integration Statements to communicate their products' capabilities. Vendors publishing IHE Integration Statements accept full responsibility for their content. By comparing the IHE Integration Statements from different products, a user familiar with the IHE concepts of actors and integration profiles can determine the level of integration between them. See PCC TF-1: Appendix C for the format of IHE Integration Statements.

Relationship to Product Implementations

The IHE actors and transactions described in the IHE Technical Framework are abstractions of the real-world healthcare information system environment. While some of the transactions are traditionally performed by specific product categories (e.g. HIS, Clinical Data Repository, Electronic Health record systems, Radiology Information Systems, Clinical Information Systems or Cardiology Information Systems), the IHE Technical Framework intentionally avoids associating functions or actors with such product categories. For each actor, the IHE Technical Framework defines only those functions associated with integrating information systems. The IHE definition of an actor should therefore not be taken as the complete definition of any product that might implement it, nor should the framework itself be taken to comprehensively describe the architecture of a healthcare information system.

The reason for defining actors and transactions is to provide a basis for defining the interactions among functional components of the healthcare information system environment. In situations where a single physical product implements multiple functions, only the interfaces between the product and external functions in the environment are considered to be significant by the IHE initiative. Therefore, the IHE initiative takes no position as to the relative merits of an integrated environment based on a single, all-encompassing information system versus one based on multiple systems that together achieve the same end.

Relation of this Volume to the Technical Framework

The IHE Technical Framework is based on actors that interact through transactions using some form of content.

Actors are information systems or components of information systems that produce, manage, or act on information associated with operational activities in the enterprise.

Transactions are interactions between actors that transfer the required information through standards-based messages.

The implementation of the transactions described in this PCC TF-2 support the specification of Integration Profiles defined in PCC TF-1. The role and implementation of these transactions require the understanding of the Integration profile they support.

There is often a very clear distinction between the transactions in a messaging framework used to package and transmit information, and the information content actually transmitted in those messages. This is especially true when the messaging framework begins to move towards mainstream computing infrastructures being adopted by the healthcare industry.

In these cases, the same transactions may be used to support a wide variety of use cases in healthcare, and so more and more the content and use of the message also needs to be profiled, sometimes separately from the transaction itself. Towards this end IHE has developed the concept of a Content Integration Profile.

Content Integration Profiles specify how the payload of a transaction fits into a specific use of that transaction. A content integration profile has three main parts. The first part describes the use case. The second part is binding to a specific IHE transaction, which describes how the content affects the transaction. The third part is a Content Module, which describes the payload of the transaction. A content module is specified so as to be independent of the transaction in which it appears.

Content Modules

The Patient Care Coordination Technical Framework organizes content modules categorically by the base standard. At present, the PCC Technical Framework uses only one base standard, CDA Release 2.0, but this is expected to change over time. Underneath each standard, the content modules are organized using a very coarse hierarchy inherent to the standard. So for CDA Release 2.0 the modules are organized by document, section, entry, and header elements.

Each content module can be viewed as the definition of a "class" in software design terms, and has associated with it a name. Like "class" definitions in software design, a content module is a "contract", and the PCC Technical Framework defines that contract in terms of constraints that must be obeyed by instances of that content module. Each content module has a name, also known as its template identifier. The template identifiers are used to identify the contract agreed to by the content module. The PCC Technical Committee is responsible for assigning the template identifiers to each content module.

Like classes, content modules may inherit features of other content modules of the same type (Document, Section or Entry) by defining the parent content module that they inherit from. They may not inherit features from a different type. Although information in the CDA Header is in a different location that information in a CDA Entry, these two content modules are considered to be of the same type, and so may inherit from each other when necessary.

The PCC Technical Framework uses the convention that a content module cannot have more than one parent (although it may have several ancestors). This is similar to the constraint in the Java™ programming language, where classes can derive from only one parent. This convention is not due to any specific technical limitation of the technical framework, but does make it easier for software developers to implement content modules.

Each content module has a list of data elements that are required (R), required if known (R2), and optional (O). The presentation of this information varies with the type of content module, and is described in more detail below. Additional data elements may be provided by the sender that are not defined by a specific content module, but the receiver is not required to interpret them.

Required data elements must always be sent. Data elements that are required may under exceptional circumstances have an unknown value (e.g., the name of an unconscious patient). In these cases the sending application is required to indicate the reason that the data is not available.

Data elements that are marked required if known (R2) must be sent when the sending application has that data available. The sending application must be able to demonstrate that it can send all required if known elements, unless it does not in fact gather that data. When the information is not available, the sending application may indicate the reason that the data is not available.

Data elements that are marked optional (O) may be sent at the choice of the sending application. Since a content module may include data elements not specified by the profile, some might ask why these are specified in a content module. The reason for specifying the optional data elements is to ensure that both sender and receiver use the appropriate semantic interpretation of these elements. Thus, an optional element need not be sent, but when it is sent, the content module defines the meaning of that data element, and a receiver can always be assured of what that data element represents when it is present. Senders should not send an optional data element with an unknown value. If the value is not known, simply do not send the data element.

Other data elements may be included in an instance of a content module over what is defined by the PCC Technical Framework. Receivers are not required to process these elements, and if they do not understand them, must ignore them. Thus, it is not an error to include more than is asked for, but it is an error to reject a content module because it contains more than is defined by the framework. This allows value to be added to the content modules delivered in this framework, through extensions to it that are not defined or profiled by IHE. It further allows content modules to be defined later by IHE that are refinements or improvements over previous content modules.

For example, there is a Referral Summary content module defined in this framework. In later years an ED Referral content module can be created that inherits the constraints of the Referral Summary content module, with a few more use case specific constraints added. Systems that do not understand the ED Referral content module but do understand the Referral Summary content module will be able to interoperate with systems that send instances of documents that conform to the ED Referral content module. This interoperability, albeit at a reduced level of functionality, is by virtue of the fact that ED Referrals are simply a refinement of the Referral Summary.

In order to retain this capability, there are a few rules about how the PCC Technical Committee creates constraints. Constraints that apply to any content module will always apply to any content modules that inherit from it. Thus, the "contracts" are always valid down the inheritance hierarchy. Secondly, data elements of a content module will rarely be deprecated. This will usually occur only in the cases where they have been deprecated by the base standard. While any specific content module has a limited scope and set of use cases, deprecating the data element prevents any future content module from taking advantage of what has already been defined when a particular data element has been deprecated simply because it was not necessary in the original use case.

Document Content Module Constraints

Each document content module will define the appropriate codes used to classify the document, and will also describe the specific data elements that are included. The code used to classify it is specified using an external vocabulary, typically LOINC in the case of CDA Release 2.0 documents. The set of data elements that make up the document are defined, including the whether these data elements must, should or may be included in the document. Each data element is typically a section within the document, but may also describe information that is contained elsewhere within of the document (e.g., in the header). Each data element is mapped into a content module via a template identifier, and the document content module will further indicate whether these are data elements are required, required if known or optional.

Thus, a document content module shall contain as constraints:

• The template identifier of the parent content module when there is one.
• The LOINC code or codes that shall be used to classify the document.
• A possibly empty set of required, required if known, and optional section content modules, and their template identifiers.
• A possibly empty set of required, required if known, and optional header content modules, and their template identifiers.
• Other constraints as necessary.

The template identifier for the document will be provided in the narrative, as will the legal LOINC document type codes and if present, any parent template identifier.

The remaining constraints are presented in two tables. The first table identifies the relevant data elements as determined during the technical analysis, and maps these data elements to one or more standards. The second table actually provides the constraints, wherein each data element identified in the first table is repeated, along with whether it is required, required if known, or optional. Following this column is a reference to the specification for the content module that encodes that data element, and the template identifier assigned to it. The simple example below completes the content specification described above. A simplified example is shown below.

== Development Only == The PCC Wiki Content is used only for development of IHE PCC Content. The Normative content of the PCC Technical Framework and the current supplements can be found at http://www.ihe.net/Technical_Framework/index.cfm#PCC Sample Document Specification SampleDocumentOID Sample Document has one required section, and one entry that is required if known Specification Data Element Name Opt Template ID Sample Section Comment on section R SampleSectionOID Sample Entry Comment on entry R2 SampleEntryOID Conformance CDA Release 2.0 documents that conform to the requirements of this content module shall indicate their conformance by the inclusion of the appropriate <templateId> elements in the header of the document. This is shown in the sample document below. Sample Sample Document Document <ClinicalDocument xmlns='urn:hl7-org:v3'> <typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/> <templateId root='SampleDocumentOID'/> <id root=' ' extension=' '/> <code code=' ' displayName=' ' codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/> <title>Sample Document</title> <effectiveTime value='20260407012005'/> <confidentialityCode code='N' displayName='Normal' codeSystem='2.16.840.1.113883.5.25' codeSystemName='Confidentiality' /> <languageCode code='en-US'/>  : <component><structuredBody>  <component> <section> <templateId root='SampleSectionOID'/> <!-- Required Sample Section Section content --> </section> </component>     </structuredBody></component> </ClinicalDocument> Schematron <pattern name='Template_SampleDocumentOID'> <rule context='*[cda:templateId/@root="SampleDocumentOID"]'> <!-- Verify that the template id is used on the appropriate type of object --> <assert test='../cda:ClinicalDocument'> Error: The Sample Document can only be used on Clinical Documents. </assert>  <!-- Verify the document type code --> <assert test='cda:code[@code = "{{{LOINC}}}"]'> Error: The document type code of a Sample Document must be {{{LOINC}}} </assert> <assert test='cda:code[@codeSystem = "2.16.840.1.113883.6.1"]'> Error: The document type code must come from the LOINC code system (2.16.840.1.113883.6.1). </assert>  <assert test='.//cda:templateId[@root = "SampleSectionOID"]'>  <!-- Verify that all required data elements are present --> Error: The Sample Document Document must contain a(n) Sample Section Section. See http://wiki.ihe.net/index.php?title=SampleDocumentOID  </assert>  <assert test='.//cda:templateId[@root = "SampleEntryOID"]'>  <!-- Alert on any missing required if known elements --> Warning: The Sample Document Document should contain a(n) Sample Entry Entry. See http://wiki.ihe.net/index.php?title=SampleDocumentOID  </assert>  </rule> </pattern> }}

Section Content Module Constraints

Section content modules will define the content of a section of a clinical document. Sections will usually contain narrative text, and so this definition will often describe the information present in the narrative, although sections may be wholly comprised of subsections.

Sections may contain various subsections, and these may be required, required if known or optional. Sections may also contain various entries, and again, these may be required, required if known, or optional. A section may not contain just entries; it must have at least some narrative text or subsections to be considered to be valid content.

Again, sections can inherit features from other section content modules. Once again, sections are classified using an external vocabulary (again typically this would be LOINC), and so the list of possible section codes is also specified. Sections that inherit from other sections will not specify a LOINC code unless it is to restrict the type of section to smaller set of LOINC codes specified by one of its ancestors.

Thus, a section content module will contain as constraints:

• The template identifier of the parent content module when there is one.
• The LOINC code or codes that shall be used to classify the section.
• A possibly empty set of required, required if known, and optional section content modules, and their template identifiers for the subsections of this section.
• A possibly empty set of required, required if known, and optional entry content modules, and their template identifiers.
• Other constraints as necessary.

These constraints are presented in this document using a table for each section content module, as shown below.

Sample Section Content Module

== Development Only == The PCC Wiki Content is used only for development of IHE PCC Content. The Normative content of the PCC Technical Framework and the current supplements can be found at https://www.ihe.net/resources/technical_frameworks/#pcc Sample Section Template ID SampleSectionOID Parent Template foo (SampleParentOID) General Description Desription of this section LOINC Codes Opt Description XXXXX-X R SECTION NAME Entries Opt Description OID R Sample Entry Subsections Opt Description OID R Sample Subsection Parent Template The parent of this template is foo. Sample Sample Section <component> <section> <templateId root='SampleParentOID'/> <templateId root='SampleSectionOID'/> <id root=' ' extension=' '/> <code code=' ' displayName=' ' codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/> <text> Text as described above </text> <entry> Required and optional entries as described above </entry> <component> Required and optional subsections as described above </component>     </section> </component> Uses See Templates using the Sample Section

Entry and Header Content Modules Constraints

Entry and Header content modules are the lowest level of content for which content modules are defined. These content modules are associated with classes from the HL7 Reference Information Model (RIM). These "RIM" content modules will constrain a single RIM class. Entry content modules typically constrain an "Act" class or one of its subtypes, while header content modules will normally constrain "Participation", "Role" or "Entity" classes, but may also constrain an "Act" class.

Entry and Header content modules will describe the required, required if known, and optional XML elements and attributes that are present in the CDA Release 2.0 instance. Header and Entry content modules may also be built up using other Header and Entry content modules.

An entry or header content module may also specify constraints on the vocabularies used for codes found in the entry, or data types for the values found in the entry.

Thus, an entry or header content module will contain as constraints:

• The template identifier of the parent content module when there is one.
• A description of the XML elements and attributes used in the entry, along with explanations of their meaning.
• An indication of those XML elements or attributes that are required, required if known, or optional.
• Vocabulary domains to use when coding the entry.
• Data types used to specify the value of the entry.
• Other constraints as necessary.

An example is shown below:

==== Sample Entry ==== Some text describing the entry. <observation classCode='OBS' moodCode='EVN'> <templateId root='foo'/> </observation> <observation classCode='OBS' moodCode='EVN'> Some details about the observation element <templateId root='foo'/> Some details about the template id element

IHE Transactions

This section defines each IHE transaction in detail, specifying the standards used, and the information transferred.

IHE Patient Care Coordination Bindings

This section describes how the payload used in a transaction of an IHE profile is related to and/or constrains the data elements sent or received in those transactions. This section is where any specific dependencies between the content and transaction are defined.

A content integration profile can define multiple bindings. Each binding should identify the transactions and content to which it applies.

The source for all required and optional attributes have been defined in the bindings below. Three tables describe the three main XDS object types: XDSDocumentEntry, XDSSubmissionSet, and XDSFolder. XDSSubmissionSet and XDSDocumentEntry are required. Use of XDSFolder is optional. These concepts are universal to XDS, XDR and XDM.

The columns of the following tables are:

• <XXX> attribute – name of an XDS attribute, followed by any discussion of the binding detail.
• Optional? - Indicates the required status of the XDS attribute, and is one of R, R2, or O (optional). This column is filled with the values specified in the XDS Profile as a convenience.
• Source Type – Will contain one of the following values:

Source Type	Description
SA	Source document Attribute – value is copied directly from source document. The Source/Value column identifies where in the source document this attribute comes from. Specify the location in XPath when possible.
SAT	Source document Attribute with Transformation – value is copied from source document and transformed. The Source/Value column identifies where in the source document this attribute comes from. Specify the location in XPath when possible. Extended Discussion column must not be empty and the transform must be defined in the extended discussion
FM	Fixed (constant) by Mapping - for all source documents. Source/Value column contains the value to be used in all documents.
FAD	Fixed by Affinity Domain – value configured into Affinity Domain, all documents will use this value.
CAD	Coded in Affinity Domain – a list of acceptable codes are to be configured into Affinity Domain. The value for this attribute shall be taken from this list.
CADT	Coded in Affinity Domain with Transform - a list of acceptable codes are to be configured into Affinity Domain. The value for this attribute shall be taken from this list.
n/a	Not Applicable – may be used with an optionality R2 or O attribute to indicate it is not to be used.
DS	Document Source – value comes from the Document Source actor. Use Source/Value column or Extended Discussion to give details.
O	Other – Extended Discussion must be 'yes' and details given in an Extended Discussion.

• Source/Value – This column indicates the source or the value used.

The following tables are intended to be summaries of the mapping and transforms. The accompanying sections labeled 'Extended Discussion' are to contain the details as necessary.

Medical Document Binding to XDS, XDM and XDR

This binding defines a transformation that generates metadata for the XDSDocumentEntry element of appropriate transactions from the XDS, XDM and XDR profiles given a medical document and information from other sources. The medical document refers to the document being stored in a repository that will be referenced in the registry. The other sources of information include the configuration of the Document Source actor, the Affinity Domain, the site or facility, local agreements, other documents in the registry/repository, and this Content Profile.

In many cases, the CDA document is created for the purposes of sharing within an affinity domain. In these cases the context of the CDA and the context of the affinity domain are the same, in which case the following mappings shall apply.

In other cases, the CDA document may have been created for internal use, and are subsequentyly being shared. In these cases the context of the CDA document would not neccessarily coincide with that of the affinity domain, and the mappings below would not necessarily apply.

Please note the specifics given in the table below.

XDSDocumentEntry Metadata

XDSDocumentEntry Attribute	Optional?	Source Type	Source/ Value
availabilityStatus	R	DS
authorInstitution	R2	SAT	$inst <= /ClinicalDocument/author /assignedAuthor /representedOrganization The authorInstitution can be formated using the following XPath expression, where $inst in the expression below represents the representedOrganization. concat($inst/name)
authorPerson	R2	SAT	$person <= /ClinicalDocument/author The author can be formatted using the following XPath expression, where $person in the expression below represents the author. concat( $person/id/@extension,"^", $person/assignedPerson/name/family,"^", $person/assignedPerson/name/given[1],"^", $person/assignedPerson/name/given[2],"^", $person/assignedPerson/name/suffix,"^", $person/assignedPerson/name/prefix,"^", "^^^&", $person/id/@root,"&ISO")
authorRole	R2	SAT	This metadata element should be based on a mapping of the participation function defined in the CDA document to the set of author roles configured for the affinity domain. If the context of the CDA coincides with that of the affinity domain, then the following x-path may be appropriate: /ClincicalDocument/author/ participationFunction
authorSpecialty	R2	SAT	This metadata element should be based on a mapping of the code associated with the assignedAuthor to detailed defined classification system for healthcare providers such configured in the affinitity domain. Possible classifications include those found in SNOMED-CT, or the HIPAA Healthcare Provider Taxonomy. If the context of the CDA coincides with that of the affinity domain, then the following x-path may be appropriate: /ClinicalDocument/author/ assignedAuthor/code
classCode	R	CADT	Derived from a mapping of /ClinicalDocument/code/@code to an Affinity Domain specified coded value to use and coding system. Affinity Domains are encouraged to use the appropriate value for Type of Service, based on the LOINC Type of Service (see Page 53 of the LOINC User's Manual). Must be consistent with /ClinicalDocument/code/@code
classCodeDisplayName	R	CADT	DisplayName of the classCode derived. Derived from a mapping of /ClinicalDocument/code/@code to the appropriate Display Name based on the Type of Service. Must be Consitent with /ClinicalDocument/code/@code
confidentialityCode	R	CADT	Derived from a mapping of /ClinicalDocument/confidentialityCode/@code to an Affinity Domain specified coded value and coding system. When using the BPPC profile, the confidentialyCode may also be obtained from the <authorization> element. /ClinicalDocument/ confidentialityCode/@code -AND/OR- /ClinicalDocument/authorization/ consent[ templateId/@root= '1.3.6.1.4.1.19376.1.5.3.1.2.5' ] /code/@code
comments	O	DS
creationTime	R	SAT	/ClinicalDocument/effectiveTime Times specified in clinical documents may be specified with a precision in fractional sections, and may contain a time zone offset. In the XDS Metadata, it can be precise to the second, and is always given in UTC, so the timezone offset if present must be added to the current time to obtain the UTC time.
entryUUID	R	DS
eventCodeList	O	CADT	These values express a collection of keywords that may be relevant to the consumer of the documents in the registry. They may come from anywhere in the CDA document, according to its purpose.
eventCodeDisplayNameList	R (if event Code is valued)	CADT	These are the display names for the collection of keywords described above.
formatCode	R	FM	The format code for each PCC Document content profile is provided within the document specifications.
healthcareFacilityTypeCode	R	CAD	A fixed value assigned to the Document Source and configured form a set of Affinity Domain defined values. Must be concistent with /clinicalDocument/code
healthcareFacility TypeCodeDisplay Name	R	CAD	Must be concistent with /clinicalDocument/code
intendedRecipient (for XDR, XDM)	O	SAT	$person <= /ClinicalDocument/intendedRecipient and/or $inst <= /ClinicalDocument/intendedRecipient/receivedOrganization The intendedRecipient can be formated using the following XPath expression, where $inst in the expression below represents the receivedOrganization and where $person in the expression below represents the intendedRecipient. concat( $person/id/@extension,"^", $person/informationRecipient/name/family,"^", $person/informationRecipient/name/given[1],"^", $person/informationRecipient/name/given[2],"^", $person/informationRecipient/name/suffix,"^", $person/informationRecipient/name/prefix,"^", "^^^&", $person/id/@root,"&ISO", "|" $inst/name) "^^^^^&", $inst/id/@root, "&ISO", "^^^^", $inst/id/@extension) -->
languageCode	R	SA	/ClinicalDocument/languageCode
legalAuthenticator	O	SAT	$person <= /ClinicalDocument/ legalAuthenticator The legalAuthenticator can be formatted using the following XPath expression, where $person in the expression below represents the legalAuthenticator. concat( $person/id/@extension,"^", $person/assignedPerson/name/family,"^", $person/assignedPerson/name/given[1],"^", $person/assignedPerson/name/given[2],"^", $person/assignedPerson/name/suffix,"^", $person/assignedPerson/name/prefix,"^", "^^^&", $person/id/@root,"&ISO")
mimeType	R	FM	text/xml
parentDocumentRelationship	R (when applicable)	DS	Local document versions need not always be published, and so no exact mapping can be determined from the content of the CDA document. The parentDocumentRelationship may be determined in some configurations from the relatedDocument element present in the CDA dsocument. If the context of the CDA coincides with that of the affinity domain, then the following x-path may be appropriate: /ClinicalDocument/relatedDocument/@typeCode
parentDocumentId	R (when parent Document Relationship is present)	DS	Local document versions need not always be published, and so no exact mapping can be determined from the content of the CDA document. The parentDocumentId may be determined in some configurations from the relatedDocument element present in the CDA dsocument. If the context of the CDA coincides with that of the affinity domain, then the following x-path may be appropriate: $docID <= /ClinicalDocument/ relatedDocument/parentDocument/id The parentDocumentId can be formatted using the following XPath expression, where $docID in the expression below represents the identifier. concat($docID/@root,"^", $docID/@extension)
patientId	R	DS	The XDS Affinity Domain patient ID can be mapped from the patientRole/id element using transactions from the ITI PIX or PDQ profiles. See sourcePatientId below. If the context of the CDA coincides with that of the affinity domain, then the following x-path may be appropriate: $patID <= /ClinicalDocument/recordTarget/ patientRole/id
practiceSettingCode	R	CAD	This elements should be based on a coarse classification system for the class of specialty practice. Recommend the use of the classification system for Practice Setting, such as that described by the Subject Matter Domain in LOINC.
practiceSettingCodeDisplayName	R	CAD	This element shall contain the display names associated with the codes described above.
serviceStartTime	R2	SAT	/ClinicalDocument/documentationOf/ serviceEvent/effectiveTime/low/ @value Times specified in clinical documents may be specified with a precision in fractional sections, and may contain a time zone offset. In the XDS Metadata, it can be precise to the second, and is always given in UTC, so the timezone offset if present must be added to the current time to obtain the UTC time.
serviceStopTime	R2	SAT	/ClinicalDocument/documentationOf/ serviceEvent/effectiveTime/high/ @value Times specified in clinical documents may be specified with a precision in fractional sections, and may contain a time zone offset. In the XDS Metadata, it can be precise to the second, and is always given in UTC, so the timezone offset if present must be added to the current time to obtain the UTC time.
sourcePatientId	R	SAT	$patID <= /ClinicalDocument/recordTarget/ patientRole/id The patientId can be formatted using the following XPath expression, where $patID in the expression below represents the appropriate identifier. concat($patID/@extension,"^^^&", $patID/@root, "&ISO")
sourcePatientInfo	R	SAT	/ClinicalDocument/recordTarget/ patientRole The sourcePatientInfo metadata element can be assembled from various components of the patientRole element in the clinical document.
title	O	SA	/ClinicalDocument/title
typeCode	R	CADT	/ClinicalDocument/code/@code The typeCode should be mapped from the ClinicalDocument/code element to a set of document type codes configured in the affinity domain. One suggested coding system to use for typeCode is LOINC, in which case the mapping step can be omitted.
typeCodeDisplay Name	R	CADT	/ClinicalDocument/code/@displayName
uniqueId	R	SAT	$docID <= /ClinicalDocument/id The uniqueId can be formatted using the following XPath expression, where $docID in the expression below represents the identifier. concat($docID/@root,"^", $docID/@extension)

XDSSubmissionSet Metadata

The submission set metadata is as defined for XDS, and is not necessarily affected by the content of the clinical document. Metadata values in an XDSSubmissionSet with names identical to those in the XDSDocumentEntry may be inherited from XDSDocumentEntry metadata, but this is left to affinity domain policy and/or application configuration.

Use of XDS Submission Set

This content format uses the XDS Submission Set to create a package of information to send from one provider to another. All documents referenced by the Medical Summary in this Package must be in the submission set.

Use of XDS Folders

No specific requirements identified.

Configuration

IHE Content Profiles using this binding require that Content Creators and Content Consumers be configurable with institution and other specific attributes or parameters. Implementers should be aware of these requirements to make such attributes easily configurable. There shall be a mechanism for the publishing and distribution of style sheets used to view clinical documents.

Extensions from other Domains

Scanned Documents (XDS-SD)

XDS-SD is a CDA R2 document and thus conforms to the XDS Metadata requirements in the PCC-TF, volume 2, Section 5 unless otherwise specified below.

XDSDocumentEntry

XDS-SD leverages the XDS DocumentEntry Metadata requirements in the PCC-TF, volume 2, Section 5.1.1.1.1 and in PCC_TF-2/Bindings unless otherwise specified below

XDSDocumentEntry.formatCode

The XDSDocumentEntry.formatCode shall be urn:ihe:iti:xds-sd:pdf:2008 when the document is scanned pdf and urn:ihe:iti:xds-sd:text:2008 when the document is scanned text. The formatCode codeSystem shall be 1.3.6.1.4.1.19376.1.2.3.

XDSDocumentEntry.uniqueId

This value shall be the ClinicalDocument/id in the HL7 CDA R2 header. The root attribute is required, and the extension attribute is optional. In accordance with the XDS.a profile, total length is limited to 128 characters; for XDS.b the limit is 256 characters. Additionally see PCC-TF, volume 2, Section 5.1.1.1.1 or PCC_TF-2/Bindings for further content specification.

Relating instances of XDS-SD documents

In general, most instances of XDS-SD will not have parent documents. It is possible, however, in some specific use cases that instances of XDS-SD documents are related. For example, for a particular document it may be the case that both the PDF scanned content and somewhat equivalent plaintext need to be wrapped and submitted. Each document would correspond to separate XDSDocumentEntries linked via an XFRM Association that indicates one document is a transform of the other. These can be submitted in a single submission set, or in separate ones. Other specific examples may exist and this profile does not preclude the notion of a parent document for these cases.

XDSSubmissionSet

No additional constraints. Particular to this profile, a legitimate use of submission sets would be to maintain a logical grouping of multiple XDS-SD documents. We encourage such usage. For more information, see PCC-TF-2 Section 5.1.1.1.2 or PCC_TF-2/Bindings.

XDSFolder

No additional requirements. For more information, see PCC-TF-2 Section 5.1.1.1.3 or PCC_TF-2/Bindings.

Laboratory Reports (XD-LAB)

XD-Lab is a CDA R2 document and thus conforms to the XDS Metadata requirements in the PCC-TF, volume 2, Section 5 unless otherwise specified below.

XDSDocumentEntry

XD-Lab leverages the XDS DocumentEntry Metadata requirements in the PCC-TF, volume 2, Section 5.1.1.1.1 and in PCC_TF-2/Bindings unless otherwise specified below

XDSDocumentEntry.eventCodeList

XD-Lab documents further constrain the the XDSDocumentEntry.eventCodeList to the following.

XDSDocumentEntry

Attribute	Optional?	Source Type	Source/ Value
eventCodeList	R2	SAT	ClinicalDocument / component / structuredBody / component / section / entry / act / entryRelationship / organizer (templateId="1.3.6.1.4.1.19376.1.3.1.1")/ component / observation(templateId="1.3.6.1.4.1.19376.1.3.1.1.1")/code AND ClinicalDocument / component / structuredBody / component / section / entry / act / subject / code If the document has Reportable Condition, then this code shall be among those listed in the eventCodeList. Additionally, if the document contains information about a Non-Human Subject, then the code that indicates what this subject is shall be among those listed in the eventCodeList. Thus, this attribute has been enhanced from the XDS profile from O to R2.

XDSDocumentEntry.formatCode

The XDSDocumentEntry.formatCode shall be urn:ihe:lab:xd-lab:2008 The formatCode codeSystem shall be 1.3.6.1.4.1.19376.1.2.3.

XDSSubmissionSet

No additional constraints. For more information, see PCC-TF-2 Section 5.1.1.1.2 or PCC_TF-2/Bindings.

XDSFolder

No additional requirements. For more information, see PCC-TF-2 Section 5.1.1.1.3 or PCC_TF-2/Bindings.

Namespaces and Vocabularies

This section lists the namespaces and identifiers defined or referenced by the IHE PCC Technical Framework, and the vocabularies defined or referenced herein.

The following vocabularies are referenced in this document. An extensive list of registered vocabularies can be found at http://www.hl7.org/oid/.

Vocabularies Used

codeSystem	codeSystemName	Description
1.3.6.1.4.1.19376.1.5.3.1	IHE PCC Template Identifiers	This is the root OID for all IHE PCC Templates. A list of PCC templates can be found below in CDA Release 2.0 Content Modules.
1.3.6.1.4.1.19376.1.5.3.2	IHEActCode	See IHEActCode Vocabulary below
1.3.6.1.4.1.19376.1.5.3.3	IHE PCC RoleCode	See IHERoleCode Vocabulary below
1.3.6.1.4.1.19376.1.5.3.4		Namespace OID used for IHE Extensions to CDA Release 2.0
2.16.840.1.113883.10.20.1	CCD Root OID	Root OID used for by ASTM/HL7 Continuity of Care Document
2.16.840.1.113883.5.112	RouteOfAdministration	See the HL7 RouteOfAdministration Vocabulary
2.16.840.1.113883.5.1063	SeverityObservation	See the HL7 SeverityObservation Vocabulary
2.16.840.1.113883.5.7	ActPriority	See the HL7 ActPriority Vocabulary
2.16.840.1.113883.6.1	LOINC	Logical Observation Identifier Names and Codes
2.16.840.1.113883.6.96	SNOMED-CT	SNOMED Controlled Terminology
2.16.840.1.113883.6.103	ICD-9CM (diagnosis codes)	International Classification of Diseases, Clinical Modifiers, Version 9
2.16.840.1.113883.6.104	ICD-9CM (procedure codes)	International Classification of Diseases, Clinical Modifiers, Version 9
2.16.840.1.113883.6.26	MEDCIN	A classification system from MEDICOMP Systems.
2.16.840.1.113883.6.88	RxNorm	RxNorm
2.16.840.1.113883.6.63	FDDC	First DataBank Drug Codes
2.16.840.1.113883.6.12	C4	Current Procedure Terminology 4 (CPT-4) codes.
2.16.840.1.113883.6.257	Minimum Data Set for Long Term Care	The root OID for Minimum Data Set Answer Lists
1.2.840.10008.2.16.4	DCM	DICOM Controlled Terminology; PS 3.16 Content Mapping Resource, Annex D
2.16.840.1.113883.6.24	MDC	ISO/IEEE 11073 Medical Device Nomenclature
2.16.840.1.113883.3.26.1.5	NDF-RT	National Drug File Reference Terminology (NCI version)
2.16.840.1.113883.11.19465	nuccProviderCodes	National Uniform Codes Council Healthcare Provider Terminology
2.16.840.1.113883.6.255.1336	X12DE1336	Insurance Type Code (ASC X12 Data Element 1336)
2.16.840.1.113883.6.256	RadLex	RadLex (Radiological Society of North America)
1.3.6.1.4.1.19376.1.5.3.1.3.43	PCC.ODH	Vocabulary OID used in ODH IG

The IHE FormatCode vocabulary is now managed in an Implementation Guide published using FHIR.

• formal canonical URI https://profiles.ihe.net/fhir/ihe.formatcode.fhir/ValueSet-formatcode.html
• formal publication URL https://profiles.ihe.net/fhir/ihe.formatcode.fhir/
• FormatCode gitHub repository for source of the Implementation Guide can be used to register issues, or create pull requests for modifications. Formal governance is managed by ITI Technical Committee.

This FormatCode vocabulary represents:

• Code System 1.3.6.1.4.1.19376.1.2.3
• Value Set 1.3.6.1.4.1.19376.1.2.7.1

IHEActCode Vocabulary

CCD		ASTM/HL7 Continuity of Care Document
CCR		ASTM CCR Implementation Guide

The IHEActCode vocabulary is a small vocabulary of clinical acts that are not presently supported by the HL7 ActCode vocabulary. The root namespace (OID) for this vocabulary is 1.3.6.1.4.1.19376.1.5.3.2. These vocabulary terms are based on the vocabulary and concepts used in the CCR and CCD standards listed above.

Code	Description
COMMENT	This is the act of commenting on another act.
PINSTRUCT	This is the act of providing instructions to a patient regarding the use of medication.
FINSTRUCT	This is the act of providing instructions to the supplier regarding the fulfillment of the medication order.
IMMUNIZ	The act of immunization of a patient using a particular substance or class of substances identified using a specified vocabulary. Use of this vocabulary term requires the use of either the SUBSTANCE or SUBSTCLASS qualifier described below, along with an identified substance or class of substances.
DRUG	The act of treating a patient with a particular substance or class of substances identified using a specified vocabulary. Use of this vocabulary term requires the use of either the SUBSTANCE or SUBSTCLASS qualifier described below, along with an identified substance or class of substances.
INTOL	An observation that a patient is somehow intollerant of (e.g., allergic to) a particular substance or class of substances using a specified vocabulary. Use of this vocabulary term requires the use of either the SUBSTANCE or SUBSTCLASS qualifier described below, along with an identified substance or class of substances.
SUBSTANCE	A qualifier that identifies the substance used to treat a patient in an immunization or drug treatment act. The substance is expected to be identified using a vocabulary such as RxNORM, SNOMED CT or other similar vocabulary and should be specific enough to identify the ingredients of the substance used.
SUBSTCLASS	A qualifier that identifies the class of substance used to treat a patient in an immunization or drug treatment act. The class of substances is expected to be identified using a vocabulary such as NDF-RT, SNOMED CT or other similar vocabulary, and should be broad enough to classify substances by mechanism of action (e.g., Beta Blocker), intended effect (Dieuretic, antibiotic) or ...

For Public Comment

What else needs to appear above for SUBSTCLASS?

IHERoleCode Vocabulary

The IHERoleCode vocabulary is a small vocabulary of role codes that are not presently supported by the HL7 Role Code vocabulary. The root namespace (OID) for this vocabulary is 1.3.6.1.4.1.19376.1.5.3.3.

IHERoleCode Vocabulary

Code	Description
EMPLOYER	The employer of a person.
SCHOOL	The school in which a person is enrolled.
AFFILIATED	An organization with which a person is affiliated (e.g., a volunteer organization).
PHARMACY	The pharmacy a person uses.

Conventions

Various tables used in this section will further constrain the content. Within this volume, the follow conventions are used.

R

A "Required" data element is one that shall always be provided. If there is information available, the data element must be present. If there is no information available, or it cannot be transmitted, the data element must contain a value indicating the reason for omission of the data. (See PCC TF-2: 5.3.4.2 for a list of appropriate statements).

R2

A "Required if data present" data element is one that shall be provided when a value exists. If the information cannot be transmitted, the data element shall contain a value indicating the reason for omission of the data. If no such information is available to the creator or if such information is not available in a well identified manner (e.g. buried in a free form narrative that contains additional information relevant to other sections) or if the creator requires that information be absent, the R2 section shall be entirely absent. (See section PCC TF-2: 5.3.4.2 for a list of appropriate statements).

O

An optional data element is one that may be provided, irrespective of whether the information is available or not. If the implementation elects to support this optional section, then its support shall meet the requirement set forth for the "Required if data present" or R2.

C

A conditional data element is one that is required, required if known or optional depending upon other conditions. These will have further notes explaining when the data element is required, et cetera.

Note:

The definitions of R, R2, and O differ slightly from other IHE profiles. This is due in part to the fact that local regulations and policies may in fact prohibit the transmission of certain information, and that a human decision to transmit the information may be required in many cases.

Folder Content Modules

This section contains modules that describe the content requirements of XDS Folders. At present, the IHE PCC Technical Framework has not defined any Folder Modules.

CDA Release 2.0 Content Modules

This section contains content modules based upon the HL7 CDA Release 2.0 Standard, and related standards and/or implementation guides.

Development Only

The PCC Wiki Content is used only for development of IHE PCC Content. The Normative content of the PCC Technical Framework and the current supplements can be found at http://www.ihe.net/Technical_Framework/index.cfm#PCC

Medical Documents Specification 1.3.6.1.4.1.19376.1.5.3.1.1.1

This section defines the base set of constraints used by almost all medical document profiles described the PCC Technical Framework.

Standards

CDAR2	HL7 CDA Release 2.0
CDTHP	CDA for Common Document Types History and Physical Notes (DSTU)
XMLXSL	Associating Style Sheets with XML documents

Conformance

CDA Release 2.0 documents that conform to the requirements of this content module shall indicate their conformance by the inclusion of the appropriate <templateId> elements in the header of the document. This is shown in the sample document below.

Sample Medical Documents Document

<ClinicalDocument xmlns='urn:hl7-org:v3'> <typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.1'/> <id root=' ' extension=' '/> <code code=' ' displayName=' ' codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/> <title>Medical Documents</title> <effectiveTime value='20260407012005'/> <confidentialityCode code='N' displayName='Normal' codeSystem='2.16.840.1.113883.5.25' codeSystemName='Confidentiality' /> <languageCode code='en-US'/>  : <component><structuredBody>     </structuredBody></component> </ClinicalDocument>

 

   <!-- Verify the document type code -->
   <assert test='cda:code[@code = "{{{LOINC}}}"]'>
     Error: The document type code of a Medical Documents must be {{{LOINC}}}
   </assert>
   <assert test='cda:code[@codeSystem = "2.16.840.1.113883.6.1"]'>
     Error: The document type code must come from the LOINC code 
     system (2.16.840.1.113883.6.1).
   </assert>

Specification

The constraints for encoding of the CDA Header (Level 1) can be found in the CDA for Common Document Types History and Physical Implementation Guide, in the section 2. CDA Header -- General Constraints.

• IHE Medical Documents shall follow all constraints found in that section with the exception of the constraint on realmcode found in CONF-HP-15:.
• IHE Medical Documents which are implemented for the US Realm shall follow ALL constraints found in that section, and shall use both the IHE Medical Document templateId (1.3.6.1.4.1.19376.1.5.3.1.1.1) and the HL7 General Header Constraints templateId (2.16.840.1.113883.10.20.3).}}

Realm	Constraints	Template IDs Required
Universal	CONF-HP-1 through CONF-HP-14 CONF-HP-16 through CONF-HP-52	1.3.6.1.4.1.19376.1.5.3.1.1.1
US	CONF-HP-1 through CONF-HP-52	1.3.6.1.4.1.19376.1.5.3.1.1.1 2.16.840.1.113883.10.20.3

Style Sheets

Document sources should provide an XML style sheet to render the content of the Medical Summary document. The output of this style sheet shall be an XHTML Basic (see http://www.w3.org/TR/xhtml-basic/) document that renders the clinical content of a Medical Summary Document as closely as possible as the sending provider viewed the completed document. When a style sheet is provided, at least one processing instruction shall be included in the document that including a link to the URL for the XML style sheet. To ensure that the style sheet is available to all receivers, more than one stylesheet link may be included.

When a stylesheet is used within an XDS Affinity domain, the link to it shall be provided using an HTTPS or HTTP URL.

<?xml-stylesheet href='https://foobar:8080/mystylesheet.xsl' type='text/xsl'?>

When using XDM or XDR to exchange documents, the stylesheet shall also be exchanged on the media. The link to the stylesheet shall be recorded as a relative URL.

<?xml-stylesheet href='../../stylesheets/mystylesheet.xsl' type='text/xsl'?>

Style sheets should not rely on graphic or other media resources. If graphics other media resources are used, these shall be accessible in the same way as the stylesheet. The Content Creator need not be the provider of the resources (stylesheet or graphcs).

When a Content Creator provides a style sheet, Content Consumers must provide a mechanism to render the document with that style sheet. Content Consumers may view the document with their own style sheet.

To record the stylesheet within a CDA Document that might be used in both an XDS and XDM environment, more than one stylesheet processing instruction is required. In this case, all style sheet processing instructions included must include the alternate='yes' attribute.

<?xml-stylesheet href='https://foobar:8080/mystylesheet.xsl' type='text/xsl' alternate='yes'?>
<?xml-stylesheet href='../../stylesheets/mystylesheet.xsl' type='text/xsl' alternate='yes'?>

A Content Consumer that is attempting to render a document using the document supplied stylesheet may use the first style sheet processing instruction for which it is able to obtain the style sheet content, and shall not report any errors if it is able to find at least one stylesheet to render with.

Distinctions of None

Information that is sent must clearly identify distinctions between

None

It is known with complete confidence that there are none. Used in the context of problem and medication lists, this indicates that the sender knows that there is no relevant information that can be sent.

None Known

None are known at this time, but it is not known with complete confidence than none exist. Used in the context of allergy lists, where essentially, it is impossible to prove the negative that no allergies exist, it is only possible to assert that none have been found to date.

None Known Did Ask

None are known at this time, and it is not known with complete confidence than none exist, but the information was requested. Also used in the context of allergy lists, where essentially, it is impossible to prove the negative that no allergies exist, it is only possible to assert that none have been found to date.

Unknown

The information is not known, or is otherwise unavailable.

In the context of CDA, sections that are required to be present but have no information should use one of the above phrases where appropriate.

An appropriate machine readable entry shall be present for problems, medications and allergies to indicate the reason that no information. Codes for recording unknown or no information are provided in the section on the Problem, Allergy and Medications Entry.

Development Only

The PCC Wiki Content is used only for development of IHE PCC Content. The Normative content of the PCC Technical Framework and the current supplements can be found at http://www.ihe.net/Technical_Framework/index.cfm#PCC

Medical Summary Specification 1.3.6.1.4.1.19376.1.5.3.1.1.2

A medical summary contains a snapshot of the patient's medical information, including at the very least, a list of the patients problems, medications and allergies. A Medical Summary is an abstract template that is expected to be further refined by additional document templates.

Parent Template

This document is an instance of the Medical Document template.

Standards

CDAR2

HL7 CDA Release 2.0

Specification

Data Element Name	Opt	Template ID
Problem Concern Entry	R	1.3.6.1.4.1.19376.1.5.3.1.4.5.2
Allergy Concern Entry	R	1.3.6.1.4.1.19376.1.5.3.1.4.5.3
Medications	R	1.3.6.1.4.1.19376.1.5.3.1.4.7

Conformance

CDA Release 2.0 documents that conform to the requirements of this content module shall indicate their conformance by the inclusion of the appropriate <templateId> elements in the header of the document. This is shown in the sample document below. A CDA Document may conform to more than one template. This content module inherits from the Medical Document content module, and so must conform to the requirements of that template as well, thus all <templateId> elements shown in the example below shall be included.

Sample Medical Summary Document

<ClinicalDocument xmlns='urn:hl7-org:v3'> <typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.1'/>  <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.2'/> <id root=' ' extension=' '/> <code code=' ' displayName=' ' codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/> <title>Medical Summary</title> <effectiveTime value='20260407012005'/> <confidentialityCode code='N' displayName='Normal' codeSystem='2.16.840.1.113883.5.25' codeSystemName='Confidentiality' /> <languageCode code='en-US'/>  : <component><structuredBody>     </structuredBody></component> </ClinicalDocument>

Schematron

<pattern name='Template_1.3.6.1.4.1.19376.1.5.3.1.1.2'>
 <rule context='*[cda:templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.1.2"]'>
   <!-- Verify that the template id is used on the appropriate type of object -->
   <assert test='../cda:ClinicalDocument'>
     Error: The Medical Summary can only be used on Clinical Documents.
   </assert> 
   <!-- Verify that the parent templateId is also present. -->
   <assert test='cda:templateId[@root="1.3.6.1.4.1.19376.1.5.3.1.1.1"]'>
     Error: The parent template identifier for Medical Summary is not present.
   </assert> 
   <!-- Verify the document type code -->
   <assert test='cda:code[@code = "{{{LOINC}}}"]'>
     Error: The document type code of a Medical Summary must be {{{LOINC}}}
   </assert>
   <assert test='cda:code[@codeSystem = "2.16.840.1.113883.6.1"]'>
     Error: The document type code must come from the LOINC code 
     system (2.16.840.1.113883.6.1).
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.4.5.2"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Medical Summary Document must contain a(n) Problem Concern Entry Entry.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.2
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.4.5.3"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Medical Summary Document must contain a(n) Allergy Concern Entry Entry.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.2
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.4.7"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Medical Summary Document must contain a(n) Medications Entry.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.2
   </assert> 
 </rule>
</pattern>

Document Specification

A medical summary is a type of medical document, and incorporates the constraints defined for Medical Documents, and requires the recording of Problems, Allergies and Medications.

Development Only

The PCC Wiki Content is used only for development of IHE PCC Content. The Normative content of the PCC Technical Framework and the current supplements can be found at http://www.ihe.net/Technical_Framework/index.cfm#PCC

Referral Summary Specification 1.3.6.1.4.1.19376.1.5.3.1.1.3

The use case is described fully in PCC_TF-1 for the Ambulatory Specialist Referral. Briefly, it involves a "collaborative" transfer of care for the referral of a patient from a primary care provider (PCP) to a specialist. The important document data elements identified by physicians and nurses for this use case are listed in the table below under the column "Data Elements". These were then mapped to the categories given HL7 Care Record Summary Implementation Guide, and HL7 CDA Release 2.0. These mappings are provided in the next two columns.

A referral summary is a type of Medical Summary, and incorporates the constraints defined for a Medical Summary(1.3.6.1.4.1.19376.1.5.3.1.1.2) above. This section defines additional constraints for Medical Summary Content used in a Referral summary. These tables present the Categories, as defined in Section 3 of CRS. In no case are these IHE requirements less strict than those defined by CRS.

Format Code

The XDSDocumentEntry format code for this content is urn:ihe:pcc:xds-ms:2007

Parent Template

This document is an instance of the Medical Summary template.

Standards

CDAR2	HL7 CDA Release 2.0
CRS	HL7 Care Record Summary
CCD	ASTM/HL7 Continuity of Care Document

Data Element Index

Data Elements	HL7 Care Record Summary	CDA Release 2.0
Reason for Referral	Reason for Referral	REASON FOR REFERRAL
History Present Illness	History of Present Illness	HISTORY OF PRESENT ILLNESS
Active Problems	Conditions	PROBLEM LIST
Current Meds	Medications	HISTORY OF MEDICATION USE
Allergies	Allergies and Adverse Reactions	HISTORY OF ALLERGIES
History of Past Illness	Conditions	HISTORY OF PAST ILLNESS
List of Surgeries	Past Surgical History	HISTORY OF PRIOR SURGERIES
Immunizations	Immunizations	HISTORY OF IMMUNIZATIONS
Family History	Family History	HISTORY OF FAMILY ILLNESS
Social History	Social History	SOCIAL HISTORY
Pertinent Review of Systems	Review of Systems	REVIEW OF SYSTEMS
Vital Signs	Physical Exam	VITAL SIGNS
Physical Exam	Physical Exam	GENERAL STATUS, PHYSICAL FINDINGS
Relevant Diagnostic Surgical Procedures / Clinical Reports (including links)	Studies and Reports	RELEVANT DIAGNOSTIC TESTS AND/OR LABORATORY DATA
Relevant Diagnostic Test and Reports (Lab, Imaging, EKG's, etc.) including links.	Studies and Reports	RELEVANT DIAGNOSTIC TESTS AND/OR LABORATORY DATA
Plan of Care (new meds labs, or x-rays ordered)	Care Plan	TREATMENT PLAN
Advance Directives	Advance Directives	ADVANCE DIRECTIVES
Patient Administrative Identifiers	Header	patientRole/id
Pertinent Insurance Information	Participant	participant[@classCode='HLD']
Data needed for state and local referral forms, if different than above	Optional Sections	section

Specification

Data Element Name	Opt	Template ID
Reason for Referral	R	1.3.6.1.4.1.19376.1.5.3.1.3.1
History Present Illness	R	1.3.6.1.4.1.19376.1.5.3.1.3.4
Active Problems	R	1.3.6.1.4.1.19376.1.5.3.1.3.6
Current Meds	R	1.3.6.1.4.1.19376.1.5.3.1.3.19
Allergies	R	1.3.6.1.4.1.19376.1.5.3.1.3.13
History of Past Illness	R2	1.3.6.1.4.1.19376.1.5.3.1.3.8
List of Surgeries	R2	1.3.6.1.4.1.19376.1.5.3.1.3.11
Immunizations	R2	1.3.6.1.4.1.19376.1.5.3.1.3.23
Family History	R2	1.3.6.1.4.1.19376.1.5.3.1.3.14
Social History	R2	1.3.6.1.4.1.19376.1.5.3.1.3.16
Pertinent Review of Systems	O	1.3.6.1.4.1.19376.1.5.3.1.3.18
Vital Signs	R2	1.3.6.1.4.1.19376.1.5.3.1.3.25
Physical Exam	R2	1.3.6.1.4.1.19376.1.5.3.1.3.24
Relevant Diagnostic Surgical Procedures / Clinical Reports and Relevant Diagnostic Test and Reports (Lab, Imaging, EKG's, etc.) including links.	R2	1.3.6.1.4.1.19376.1.5.3.1.3.27
Plan of Care (new meds, labs, or x-rays ordered)	R2	1.3.6.1.4.1.19376.1.5.3.1.3.31
Advance Directives	R2	1.3.6.1.4.1.19376.1.5.3.1.3.34
Patient Administrative Identifiers Handled by the Medical Documents Content Profile by reference to constraints in HL7 CRS.	R
Pertinent Insurance Information Refer to Appropriate Payers Section -- TBD	R2
Data needed for state and local referral forms, if different than above These are handed by including additional sections within the summary.	R2

Conformance

CDA Release 2.0 documents that conform to the requirements of this content module shall indicate their conformance by the inclusion of the appropriate <templateId> elements in the header of the document. This is shown in the sample document below. A CDA Document may conform to more than one template. This content module inherits from the Medical Summary content module, and so must conform to the requirements of that template as well, thus all <templateId> elements shown in the example below shall be included.

Sample Referral Summary Document

<ClinicalDocument xmlns='urn:hl7-org:v3'> <typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.2'/>  <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.3'/> <id root=' ' extension=' '/> <code code=' ' displayName=' ' codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/> <title>Referral Summary</title> <effectiveTime value='20260407012005'/> <confidentialityCode code='N' displayName='Normal' codeSystem='2.16.840.1.113883.5.25' codeSystemName='Confidentiality' /> <languageCode code='en-US'/>  : <component><structuredBody>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.1'/> <!-- Required Reason for Referral Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.4'/> <!-- Required History Present Illness Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.6'/> <!-- Required Active Problems Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.19'/> <!-- Required Current Meds Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.13'/> <!-- Required Allergies Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.8'/> <!-- Required if known History of Past Illness Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.11'/> <!-- Required if known List of Surgeries Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.23'/> <!-- Required if known Immunizations Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.14'/> <!-- Required if known Family History Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.16'/> <!-- Required if known Social History Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.18'/> <!-- Optional Pertinent Review of Systems Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.25'/> <!-- Required if known Vital Signs Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.24'/> <!-- Required if known Physical Exam Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.27'/> <!-- Required if known Relevant Diagnostic Surgical Procedures / Clinical Reports and Relevant Diagnostic Test and Reports Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.31'/> <!-- Required if known Plan of Care (new meds, labs, or x-rays ordered) Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.34'/> <!-- Required if known Advance Directives Section content --> </section> </component>     </structuredBody></component> </ClinicalDocument>

Schematron

<pattern name='Template_1.3.6.1.4.1.19376.1.5.3.1.1.3'>
 <rule context='*[cda:templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.1.3"]'>
   <!-- Verify that the template id is used on the appropriate type of object -->
   <assert test='../cda:ClinicalDocument'>
     Error: The Referral Summary can only be used on Clinical Documents.
   </assert> 
   <!-- Verify that the parent templateId is also present. -->
   <assert test='cda:templateId[@root="1.3.6.1.4.1.19376.1.5.3.1.1.2"]'>
     Error: The parent template identifier for Referral Summary is not present.
   </assert> 
   <!-- Verify the document type code -->
   <assert test='cda:code[@code = "{{{LOINC}}}"]'>
     Error: The document type code of a Referral Summary must be {{{LOINC}}}
   </assert>
   <assert test='cda:code[@codeSystem = "2.16.840.1.113883.6.1"]'>
     Error: The document type code must come from the LOINC code 
     system (2.16.840.1.113883.6.1).
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.1"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Referral Summary Document must contain a(n) Reason for Referral Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.3
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.4"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Referral Summary Document must contain a(n) History Present Illness Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.3
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.6"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Referral Summary Document must contain a(n) Active Problems Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.3
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.19"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Referral Summary Document must contain a(n) Current Meds Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.3
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.13"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Referral Summary Document must contain a(n) Allergies Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.3
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.8"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  Referral Summary Document should contain a(n) History of Past Illness Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.3
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.11"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  Referral Summary Document should contain a(n) List of Surgeries Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.3
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.23"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  Referral Summary Document should contain a(n) Immunizations Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.3
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.14"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  Referral Summary Document should contain a(n) Family History Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.3
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.16"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  Referral Summary Document should contain a(n) Social History Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.3
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.18"]'> 
     <!-- Note any missing optional elements -->
     Note: This Referral Summary Document does not contain a(n) Pertinent Review of Systems Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.3
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.25"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  Referral Summary Document should contain a(n) Vital Signs Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.3
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.24"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  Referral Summary Document should contain a(n) Physical Exam Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.3
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.27"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  Referral Summary Document should contain a(n) Relevant Diagnostic Surgical Procedures / Clinical Reports and Relevant Diagnostic Test and Reports Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.3 
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.31"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  Referral Summary Document should contain a(n) Plan of Care (new meds, labs, or x-rays ordered) Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.3
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.34"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  Referral Summary Document should contain a(n) Advance Directives Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.3
   </assert> 
   <assert test='.//cda:templateId[@root = ""]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Referral Summary Document must contain a(n) Patient Administrative Identifiers Entry.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.3 
   </assert> 
   <assert test='.//cda:templateId[@root = ""]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  Referral Summary Document should contain a(n) Pertinent Insurance Information Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.3 
   </assert> 
   <assert test='.//cda:templateId[@root = ""]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  Referral Summary Document should contain a(n) Data needed for state and local referral forms, if different than above Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.3 
   </assert> 
 </rule>
</pattern>

Development Only

The PCC Wiki Content is used only for development of IHE PCC Content. The Normative content of the PCC Technical Framework and the current supplements can be found at http://www.ihe.net/Technical_Framework/index.cfm#PCC

Discharge Summary Specification 1.3.6.1.4.1.19376.1.5.3.1.1.4

This use case is described fully in the XDS-MS profile found in PCC TF-1. Briefly, it involves an episodic transfer of care in the form of a patient discharge from a hospital to home. The important data elements identified by physicians and nurses for this use case are listed in the table below under the column "Data Elements". These are mapped to the categories given HL7 Care Record Summary Implementation Guide, and HL7 CDA Release 2.0 in the next two columns.

A discharge summary is a type of medical summary, and incorporates the constraints defined for Medical Summaries.

This section defines additional constraints for Medical Summary Content used in a Discharge Summary. These tables present the data elements described above, along with their optionality, and references to the section and template where these sections or header data elements are further defined.

In no case are these IHE requirements less strict than those defined by the HL7 Care Record Summary.

Format Code

The XDSDocumentEntry format code for this content is urn:ihe:pcc:xds-ms:2007

Parent Template

This document is an instance of the Medical Summary template.

Standards

CDAR2	HL7 CDA Release 2.0
CRS	HL7 Care Record Summary
CCD	ASTM/HL7 Continuity of Care Document

Data Element Index

Data Elements	HL7 Care Record Summary	CDA Release 2.0
Date of Admission	Header	encompassingEncounter/effectiveTime
Date of Discharge	Header	encompassingEncounter/effectiveTime
Participating Providers and Roles	Header	documentationOf/serviceEvent/performer
Discharge Disposition (who, how, where)	Care Plan	DISCHARGE DISPOSITION
Admitting Diagnosis	Conditions	HOSPITAL ADMISSION DX
History of Present Illness	History of Present Illness	HISTORY OF PRESENT ILLNESS
Hospital Course	Hospital Course	HOSPITAL COURSE
Discharge Diagnosis (including active and resolved problems)	Conditions	HOSPITAL DISCHARGE DX
Selected Medicine Administered during Hospitalization	Medications	HISTORY OF MEDICATION USE
Discharge Medications	Medications	HOSPITAL DISCHARGE MEDICATIONS
Allergies and adverse reactions	Allergies and Adverse Reactions	HISTORY OF ALLERGIES
Discharge Diet	Optionally found in Care Plan	DISCHARGE DIET
Review of Systems	Review of Systems	REVIEW OF SYSTEMS
Vital Signs (most recent, high/low/average)	Physical Exam	VITAL SIGNS
Functional Status	Functional Status	HISTORY OF FUNCTIONAL STATUS
Relevant Procedures and Reports (including links)	Studies and Reports	HOSPITAL DISCHARGE STUDIES
Relevant Diagnostic Tests and Reports (including links)	Studies and Reports	HOSPITAL DISCHARGE STUDIES
Plan of Care	Care Plan	TREATMENT PLAN
Administrative Identifiers	Header	patient/id
Pertinent Insurance Information	Header	participant[@classCode='HLD']

Specification

Data Element Name	Opt	Template ID
Active Problems	R	1.3.6.1.4.1.19376.1.5.3.1.3.6
Resolved Problems	R	1.3.6.1.4.1.19376.1.5.3.1.3.8
Discharge Diagnosis	R	1.3.6.1.4.1.19376.1.5.3.1.3.7
Admitting Diagnosis	R	1.3.6.1.4.1.19376.1.5.3.1.3.3
Selected Meds Administered	R2	1.3.6.1.4.1.19376.1.5.3.1.3.21
Discharge Meds	R	1.3.6.1.4.1.19376.1.5.3.1.3.22
Admission Medications	R2	1.3.6.1.4.1.19376.1.5.3.1.3.20
Allergies	R	1.3.6.1.4.1.19376.1.5.3.1.3.13
Hospital Course	R	1.3.6.1.4.1.19376.1.5.3.1.3.5
Advance Directives	O	1.3.6.1.4.1.19376.1.5.3.1.3.34
History of Present Illness	R2	1.3.6.1.4.1.19376.1.5.3.1.3.4
Functional Status	O	1.3.6.1.4.1.19376.1.5.3.1.3.17
Review of Systems	O	1.3.6.1.4.1.19376.1.5.3.1.3.18
Physical Examination	O	1.3.6.1.4.1.19376.1.5.3.1.3.24
Vital Signs	O	1.3.6.1.4.1.19376.1.5.3.1.3.25
Discharge Procedures Tests, Reports	O	1.3.6.1.4.1.19376.1.5.3.1.3.29
Plan of Care	R	1.3.6.1.4.1.19376.1.5.3.1.3.31
Discharge Diet	O	1.3.6.1.4.1.19376.1.5.3.1.3.33

Conformance

CDA Release 2.0 documents that conform to the requirements of this content module shall indicate their conformance by the inclusion of the appropriate <templateId> elements in the header of the document. This is shown in the sample document below. A CDA Document may conform to more than one template. This content module inherits from the Medical Summary content module, and so must conform to the requirements of that template as well, thus all <templateId> elements shown in the example below shall be included.

Sample Discharge Summary Document

<ClinicalDocument xmlns='urn:hl7-org:v3'> <typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.2'/>  <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.4'/> <id root=' ' extension=' '/> <code code=' ' displayName=' ' codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/> <title>Discharge Summary</title> <effectiveTime value='20260407012005'/> <confidentialityCode code='N' displayName='Normal' codeSystem='2.16.840.1.113883.5.25' codeSystemName='Confidentiality' /> <languageCode code='en-US'/>  : <component><structuredBody>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.6'/> <!-- Required Active Problems Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.8'/> <!-- Required Resolved Problems Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.7'/> <!-- Required Discharge Diagnosis Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.3'/> <!-- Required Admitting Diagnosis Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.21'/> <!-- Required if known Selected Meds Administered Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.22'/> <!-- Required Discharge Meds Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.20'/> <!-- Required if known Admission Medications Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.13'/> <!-- Required Allergies Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.5'/> <!-- Required Hospital Course Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.34'/> <!-- Optional Advance Directives Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.4'/> <!-- Required if known History of Present Illness Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.17'/> <!-- Optional Functional Status Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.18'/> <!-- Optional Review of Systems Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.24'/> <!-- Optional Physical Examination Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.25'/> <!-- Optional Vital Signs Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.29'/> <!-- Optional Discharge Procedures Tests, Reports Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.31'/> <!-- Required Plan of Care Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.33'/> <!-- Optional Discharge Diet Section content --> </section> </component>     </structuredBody></component> </ClinicalDocument>

Schematron

<pattern name='Template_1.3.6.1.4.1.19376.1.5.3.1.1.4'>
 <rule context='*[cda:templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.1.4"]'>
   <!-- Verify that the template id is used on the appropriate type of object -->
   <assert test='../cda:ClinicalDocument'>
     Error: The Discharge Summary can only be used on Clinical Documents.
   </assert> 
   <!-- Verify that the parent templateId is also present. -->
   <assert test='cda:templateId[@root="1.3.6.1.4.1.19376.1.5.3.1.1.2"]'>
     Error: The parent template identifier for Discharge Summary is not present.
   </assert> 
   <!-- Verify the document type code -->
   <assert test='cda:code[@code = "{{{LOINC}}}"]'>
     Error: The document type code of a Discharge Summary must be {{{LOINC}}}
   </assert>
   <assert test='cda:code[@codeSystem = "2.16.840.1.113883.6.1"]'>
     Error: The document type code must come from the LOINC code 
     system (2.16.840.1.113883.6.1).
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.6"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Discharge Summary Document must contain a(n) Active Problems Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.4
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.8"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Discharge Summary Document must contain a(n) Resolved Problems Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.4
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.7"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Discharge Summary Document must contain a(n) Discharge Diagnosis Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.4
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.3"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Discharge Summary Document must contain a(n) Admitting Diagnosis Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.4
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.21"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  Discharge Summary Document should contain a(n) Selected Meds Administered Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.4
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.22"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Discharge Summary Document must contain a(n) Discharge Meds Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.4
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.20"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  Discharge Summary Document should contain a(n) Admission Medications Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.4
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.13"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Discharge Summary Document must contain a(n) Allergies Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.4
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.5"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Discharge Summary Document must contain a(n) Hospital Course Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.4
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.34"]'> 
     <!-- Note any missing optional elements -->
     Note: This Discharge Summary Document does not contain a(n) Advance Directives Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.4
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.4"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  Discharge Summary Document should contain a(n) History of Present Illness Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.4
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.17"]'> 
     <!-- Note any missing optional elements -->
     Note: This Discharge Summary Document does not contain a(n) Functional Status Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.4
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.18"]'> 
     <!-- Note any missing optional elements -->
     Note: This Discharge Summary Document does not contain a(n) Review of Systems Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.4
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.24"]'> 
     <!-- Note any missing optional elements -->
     Note: This Discharge Summary Document does not contain a(n) Physical Examination Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.4
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.25"]'> 
     <!-- Note any missing optional elements -->
     Note: This Discharge Summary Document does not contain a(n) Vital Signs Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.4
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.29"]'> 
     <!-- Note any missing optional elements -->
     Note: This Discharge Summary Document does not contain a(n) Discharge Procedures Tests, Reports Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.4
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.31"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Discharge Summary Document must contain a(n) Plan of Care Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.4
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.33"]'> 
     <!-- Note any missing optional elements -->
     Note: This Discharge Summary Document does not contain a(n) Discharge Diet Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.4
   </assert> 
 </rule>
</pattern>

Development Only

The PCC Wiki Content is used only for development of IHE PCC Content. The Normative content of the PCC Technical Framework and the current supplements can be found at http://www.ihe.net/Technical_Framework/index.cfm#PCC

PHR Extract Specification 1.3.6.1.4.1.19376.1.5.3.1.1.5

The PHR Extract module describes the document content that summarizes information contained within a Personal Health Record. While a PHR can contain a great deal more information (including clinical documents, lab reported, images, trend data, monitoring data) et cetera, this content module only deals with the format of the summary information from the PHR.

An PHR Extract Module is a type of medical summary, and incorporates the constraints defined for Medical Summaries. While mappings have been provided to various standards, this content module conforms to the ASTM/HL7 Continuity of Care Document as well as this guide.

The following table describes the data elements that may be present in a PHR Extract. The first column of this table is drawn from the Common Data Elements in the PHR found in Appendix B of the AHIMA Report: The Role of the Personal Health Record in the EHR. Indented items in this column of the table provide more detail for the item they appear underneath.

These data elements were then mapped to the ASTM CCR, HL7 CDA, CRS and CCD and the implicit data elements referenced by the HL7 PHR Conformance Criteria.

A further requirement of transfers of information between PHR and EHR systems is that authorship of the information stored within the PHR shall be tracable through the various import/export cycles. PHR Manager Actors must be secure nodes, which requires logging of any updates to or accesses of PHR information. The DSG profile should be used to ensure that information coming into, or exiting these systems is verifiably authored.

Format Code

The XDSDocumentEntry format code for this content is urn:ihe:pcc:xphr:2007

Parent Template

This document is an instance of the Medical Summary template.

LOINC Code

The LOINC code for this document is 34133-9 Summary of Episode Note

Standards

AHIMA-PHR	AHIMA PHR Common Data Elements
CDAR2	HL7 CDA Release 2.0
CRS	HL7 Care Record Summary
CCD	ASTM/HL7 Continuity of Care Document
HL7-PHR	HL7 PHR Functional Model (Draft)
LOINC	Logical Observation Identifier Names and Codes

Data Element Index

AHIMA Common Data Elements	ASTM Continuity of Care Record	HL7 Clincial Document Architecture, Care Record Summary or Continuity of Care Document	HL7 PHR Conformance Criteria
Personal Information	Patient	patientRole	Demographic Information
Name	Patient	patient/name	Demographic Information
Address	Patient	patientRole/addr	Contact Information
Contact Information	Patient	patientRole/telecom	Contact Information
Personal Identification Information	Patient	patientRole/id	Demographic Information
Gender	Patient	patient/administrativeGenderCode	Demographic Information
Date of Birth	Patient	patient/birthTime	Demographic Information
Marital Status	Patient	patient/maritalStatusCode
Race	Patient	patient/raceCode
Ethnicity	Patient	patient/ethnicGroupCode	Demographic Information
(Religious Affiliation[1])	Patient	patient/religiousAffiliationCode	Spiritual Affiliation / Considerations
Languages Spoken	Patient	patient/languageCommunication
Employer and School Contacts	Social History
Hazardous Working Conditions	Social History	HISTORY OF OCCUPATIONAL EXPOSURE
Emergency Contacts	Support
Healthcare Providers	Practitioners	serviceEvent/performer	Healthcare Providers
Insurance Providers	Insurance	Health Insurance or Pharmacy Insurance
Pharamacy		performer
Legal Documents and Medical Directives	Advance Directives	ADVANCE DIRECTIVES	Advance Directive
General Medical Information Height, Weight	Vital Signs	VITAL SIGNS
Blood Type	Results	RELEVANT DIAGNOSTIC TESTS AND/OR LABORATORY DATA
Last Physical or Checkup	Encounters	HISTORY OF OUTPATIENT VISITS	Clinical Encounters and Procedures List
Allergies and Drug Sensitivies	Alerts	HISTORY OF ALLERGIES	Allergy and Reaction List
Conditions	Problems	HISTORY OF PAST ILLNESS - or - PROBLEM LIST	Problem List
Surgeries	Procedures	HISTORY OF SURGICAL PROCEDURES	Clinical Encounters and Procedures List
Medications – Prescription and Non-Prescription	Medications	HISTORY OF MEDICATION USE	Medication List
Immunizations	Immunizations	HISTORY OF IMMUNIZATIONS	Immunizations List
Doctor Visits	Encounters	HISTORY OF OUTPATIENT VISITS	Clinical Encounters and Procedures List
Hospitalizations	Encounters	HISTORY OF HOSPITALIZATIONS	Clinical Encounters and Procedures List
Other Healthcare Visits	Encounters	HISTORY OF OUTPATIENT VISITS	Clinical Encounters and Procedures List
Clinical Tests	Results	RELEVANT DIAGNOSTIC TESTS AND/OR LABORATORY DATA	Laboratory and Test Results
Pregnancies		HISTORY OF PREGNANCIES
Medical Devices	Medical Devices	HISTORY OF MEDICAL DEVICE USE
Family Member History	Family History	HISTORY OF FAMILY MEMBER DISEASES	Family History
Foreign Travel		HISTORY OF TRAVEL
Therapy	Plan of Care	TREATMENT PLAN	Care Plans, Goals and Disease Management
Vital Signs	Vital signs	VITAL SIGNS
(Functional Status[2])	Functional Status	FUNCTIONAL STATUS

Specification

Data Element Name	Opt	Template ID
Personal Information   Name Address Contact Information Personal Identification Gender Date of Birth Thes components are required of all Medical Documents	R	1.3.6.1.4.1.19376.1.5.3.1.1.1
Personal Information   Marital Status This commponent is optional in Medical Documents, but required if known in this specification.	R2	1.3.6.1.4.1.19376.1.5.3.1.1.1
Personal Information   Race Ethnicity Religious Affiliation [2] These components are optional in Medical Documents	O	1.3.6.1.4.1.19376.1.5.3.1.1.1
Languages Spoken	R2	1.3.6.1.4.1.19376.1.5.3.1.2.1
Employer and School Contacts	O	1.3.6.1.4.1.19376.1.5.3.1.2.2
Hazardous Working Conditions	O	1.3.6.1.4.1.19376.1.5.3.1.1.5.3.1
Patient Contacts	R2	1.3.6.1.4.1.19376.1.5.3.1.2.4
Healthcare Providers	R	1.3.6.1.4.1.19376.1.5.3.1.2.3
Insurance Providers	R2	1.3.6.1.4.1.19376.1.5.3.1.1.5.3.7
Pharamacy	R2	1.3.6.1.4.1.19376.1.5.3.1.2.3
Legal Documents and Medical Directives	R2	1.3.6.1.4.1.19376.1.5.3.1.3.34
Allergies and Drug Sensitivities	R	1.3.6.1.4.1.19376.1.5.3.1.3.13
Conditions	R	1.3.6.1.4.1.19376.1.5.3.1.3.8
Conditions (cont)	R	1.3.6.1.4.1.19376.1.5.3.1.3.6
Surgeries	R2	1.3.6.1.4.1.19376.1.5.3.1.3.12
Medications – Prescription and Non-Prescription	R	1.3.6.1.4.1.19376.1.5.3.1.3.19
Immunizations	R2	1.3.6.1.4.1.19376.1.5.3.1.3.23
Doctor Visits / Last Physical or Checkup	O	1.3.6.1.4.1.19376.1.5.3.1.1.5.3.3
Hospitalizations	O	1.3.6.1.4.1.19376.1.5.3.1.1.5.3.3
Other Healthcare Visits	O	1.3.6.1.4.1.19376.1.5.3.1.1.5.3.3
Clinical Tests / Blood Type	O	1.3.6.1.4.1.19376.1.5.3.1.3.28
Pregnancies	O	1.3.6.1.4.1.19376.1.5.3.1.1.5.3.4
Medical Devices	R2	1.3.6.1.4.1.19376.1.5.3.1.1.5.3.5
Family Member History	O	1.3.6.1.4.1.19376.1.5.3.1.3.15
Foreign Travel	O	1.3.6.1.4.1.19376.1.5.3.1.1.5.3.6
Plan of Care	O	1.3.6.1.4.1.19376.1.5.3.1.3.31
Coded Vital signs	O	1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2
Functional Status	O	1.3.6.1.4.1.19376.1.5.3.1.3.17

Conformance

CDA Release 2.0 documents that conform to the requirements of this content module shall indicate their conformance by the inclusion of the appropriate <templateId> elements in the header of the document. This is shown in the sample document below. A CDA Document may conform to more than one template. This content module inherits from the Medical Summary content module, and so must conform to the requirements of that template as well, thus all <templateId> elements shown in the example below shall be included.

Sample PHR Extract Document

<ClinicalDocument xmlns='urn:hl7-org:v3'> <typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.2'/>  <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.5'/> <id root=' ' extension=' '/> <code code='34133-9' displayName='Summary of Episode Note' codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/> <title>PHR Extract</title> <effectiveTime value='20260407012005'/> <confidentialityCode code='N' displayName='Normal' codeSystem='2.16.840.1.113883.5.25' codeSystemName='Confidentiality' /> <languageCode code='en-US'/>  : <component><structuredBody>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.5.3.1'/> <!-- Optional Hazardous Working Conditions Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.34'/> <!-- Required if known Legal Documents and Medical Directives Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.13'/> <!-- Required Allergies and Drug Sensitivities Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.8'/> <!-- Required Conditions Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.6'/> <!-- Required Conditions (cont) Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.12'/> <!-- Required if known Surgeries Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.19'/> <!-- Required Medications – Prescription and Non-Prescription Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.23'/> <!-- Required if known Immunizations Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.5.3.3'/> <!-- Optional Doctor Visits / Last Physical or Checkup Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.5.3.3'/> <!-- Optional Hospitalizations Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.5.3.3'/> <!-- Optional Other Healthcare Visits Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.28'/> <!-- Optional Clinical Tests / Blood Type Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.5.3.4'/> <!-- Optional Pregnancies Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.5.3.5'/> <!-- Required if known Medical Devices Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.15'/> <!-- Optional Family Member History Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.5.3.6'/> <!-- Optional Foreign Travel Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.31'/> <!-- Optional Plan of Care Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2'/> <!-- Optional Coded Vital signs Section content --> </section> </component>  <component> <section> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.17'/> <!-- Optional Functional Status Section content --> </section> </component>     </structuredBody></component> </ClinicalDocument>

Schematron

<pattern name='Template_1.3.6.1.4.1.19376.1.5.3.1.1.5'>
 <rule context='*[cda:templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.1.5"]'>
   <!-- Verify that the template id is used on the appropriate type of object -->
   <assert test='../cda:ClinicalDocument'>
     Error: The PHR Extract can only be used on Clinical Documents.
   </assert> 
   <!-- Verify that the parent templateId is also present. -->
   <assert test='cda:templateId[@root="1.3.6.1.4.1.19376.1.5.3.1.1.2"]'>
     Error: The parent template identifier for PHR Extract is not present.
   </assert> 
   <!-- Verify the document type code -->
   <assert test='cda:code[@code = "34133-9"]'>
     Error: The document type code of a PHR Extract must be 34133-9
   </assert>
   <assert test='cda:code[@codeSystem = "2.16.840.1.113883.6.1"]'>
     Error: The document type code must come from the LOINC code 
     system (2.16.840.1.113883.6.1).
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.1.1"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The PHR Extract Document must contain a(n) Personal Information Entry.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5 
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.1.1"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  PHR Extract Document should contain a(n) Personal Information Entry.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5 
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.1.1"]'> 
     <!-- Note any missing optional elements -->
     Note: This PHR Extract Document does not contain a(n) Personal Information Entry.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5 
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.2.1"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  PHR Extract Document should contain a(n) Languages Spoken Entry.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.2.2"]'> 
     <!-- Note any missing optional elements -->
     Note: This PHR Extract Document does not contain a(n) Employer and School Contacts Entry.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.1.5.3.1"]'> 
     <!-- Note any missing optional elements -->
     Note: This PHR Extract Document does not contain a(n) Hazardous Working Conditions Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.2.4"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  PHR Extract Document should contain a(n) Patient Contacts Entry.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.2.3"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The PHR Extract Document must contain a(n) Healthcare Providers Entry.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.1.5.3.7"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  PHR Extract Document should contain a(n) Insurance Providers Entry.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.2.3"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  PHR Extract Document should contain a(n) Pharamacy Entry.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.34"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  PHR Extract Document should contain a(n) Legal Documents and Medical Directives Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.13"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The PHR Extract Document must contain a(n) Allergies and Drug Sensitivities Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.8"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The PHR Extract Document must contain a(n) Conditions Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.6"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The PHR Extract Document must contain a(n) Conditions (cont) Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.12"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  PHR Extract Document should contain a(n) Surgeries Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.19"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The PHR Extract Document must contain a(n) Medications – Prescription and Non-Prescription Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.23"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  PHR Extract Document should contain a(n) Immunizations Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.1.5.3.3"]'> 
     <!-- Note any missing optional elements -->
     Note: This PHR Extract Document does not contain a(n) Doctor Visits / Last Physical or Checkup Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.1.5.3.3"]'> 
     <!-- Note any missing optional elements -->
     Note: This PHR Extract Document does not contain a(n) Hospitalizations Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.1.5.3.3"]'> 
     <!-- Note any missing optional elements -->
     Note: This PHR Extract Document does not contain a(n) Other Healthcare Visits Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.28"]'> 
     <!-- Note any missing optional elements -->
     Note: This PHR Extract Document does not contain a(n) Clinical Tests / Blood Type Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.1.5.3.4"]'> 
     <!-- Note any missing optional elements -->
     Note: This PHR Extract Document does not contain a(n) Pregnancies Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.1.5.3.5"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  PHR Extract Document should contain a(n) Medical Devices Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.15"]'> 
     <!-- Note any missing optional elements -->
     Note: This PHR Extract Document does not contain a(n) Family Member History Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.1.5.3.6"]'> 
     <!-- Note any missing optional elements -->
     Note: This PHR Extract Document does not contain a(n) Foreign Travel Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.31"]'> 
     <!-- Note any missing optional elements -->
     Note: This PHR Extract Document does not contain a(n) Plan of Care Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2"]'> 
     <!-- Note any missing optional elements -->
     Note: This PHR Extract Document does not contain a(n) Coded Vital signs Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.17"]'> 
     <!-- Note any missing optional elements -->
     Note: This PHR Extract Document does not contain a(n) Functional Status Section.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.5
   </assert> 
 </rule>
</pattern>

Additional Constraints

The assignedAuthoring device shall be populated with information about the EHR and/or PHR which assisted in creation of the document.

All sections and entries within the document shall contain an <id> element.

Development Only

The PCC Wiki Content is used only for development of IHE PCC Content. The Normative content of the PCC Technical Framework and the current supplements can be found at http://www.ihe.net/Technical_Framework/index.cfm#PCC

PHR Update Specification 1.3.6.1.4.1.19376.1.5.3.1.1.6

The PHR Update Content Module is similar to the PHR Extract content module, except that it has a number of different constraints. First of all, it is not required to contain all of the information that the PHR Extract content module does. The reason for this is because the purpose of this module is to reflect the changes that should be made to a PHR based on a previously existing PHR Extract content module. So, while it makes use of the same data element index, almost all of the data elements are optional. The purpose of this module is to make it easier for an EHR to create content that can be used to update a PHR.

Format Code

The XDSDocumentEntry format code for this content is urn:ihe:pcc:xphr:2007

Conformance

CDA Release 2.0 documents that conform to the requirements of this content module shall indicate their conformance by the inclusion of the appropriate <templateId> elements in the header of the document. This is shown in the sample document below.

Sample PHR Update Document

<ClinicalDocument xmlns='urn:hl7-org:v3'> <typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.6'/> <id root=' ' extension=' '/> <code code=' ' displayName=' ' codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/> <title>PHR Update</title> <effectiveTime value='20260407012005'/> <confidentialityCode code='N' displayName='Normal' codeSystem='2.16.840.1.113883.5.25' codeSystemName='Confidentiality' /> <languageCode code='en-US'/>  : <component><structuredBody>     </structuredBody></component> </ClinicalDocument>

 

   <!-- Verify the document type code -->
   <assert test='cda:code[@code = "{{{LOINC}}}"]'>
     Error: The document type code of a PHR Update must be {{{LOINC}}}
   </assert>
   <assert test='cda:code[@codeSystem = "2.16.840.1.113883.6.1"]'>
     Error: The document type code must come from the LOINC code 
     system (2.16.840.1.113883.6.1).
   </assert>

Requirements

The requirements of this module are that it support recording updates to the original PHR Extract. The PHR Extract is made up of a header, and several sections, each of which may contain one or more entries. Suggestions to add, remove or update a section or entry are described in more detail below.

Adding a New Section or Appending to an Existing Section

A PHR Reviewer Actor may suggest additional material for an existing or new section by simply adding that section to the PHR Update document.

Replacing a Section

A PHR Reviewer Actor may suggest a revision to a section in the PHR Extract by replacing that section. To replace a section, the PHR Reviewer Actor creates a section in the PHR Update document that is of the same type as the section to be replaced in the PHR Extract document, and adds a <ppc:replacementOf> element to that section to indicate the section that it replaces.

The replacementOf element is an extension to the CDA Release 2.0 standard, and is further described below in Appendix C Extensions to CDA Release 2.0.

Adding an Entry

A PHR Reviewer Actor may suggest a new entry be added to a section by simply including that entry in a like section in the PHR Update document.

Replacing or Removing an Entry

The PHR Review Actor can replace an existing entry by adding an entry of the same type with new or modified information, and including in that entry a <reference> element that has an <externalAct> element. The <id> element of the <externalAct> shall be that of the act that is being replaced

Removing an Entry

The PHR Reviewer Actor can suggest that an entry be removed by replacing it with an act who <statusCode> element has been set to nullified.

Constraints

The LOINC document type code is the same as for the PHR Extract content module. The PHR Update Content module must record the PHR Extract which it is updating

Development Only

The PCC Wiki Content is used only for development of IHE PCC Content. The Normative content of the PCC Technical Framework and the current supplements can be found at http://www.ihe.net/Technical_Framework/index.cfm#PCC

Consent to Share Information Specification 1.3.6.1.4.1.19376.1.5.3.1.1.7

Consents to share information are documents that contain both a human and machine readable description of how a patient has chosen to share their information.

Format Code

The XDSDocumentEntry format code for this content is urn:ihe:pcc:bppc:2007

Parent Template

This document is an instance of the Medical Document template.

Standards

CDAR2	HL7 CDA Release 2.0
XDS-SD	Scanned Documents

Specification

Data Element Name	Opt	Template ID
Consent Service Event At least one, and possibly more than one, consent can be provided within the document.	R	1.3.6.1.4.1.19376.1.5.3.1.2.6
Authorization Consents may also be protected under a sharing policity.	O	1.3.6.1.4.1.19376.1.5.3.1.2.5

Conformance

CDA Release 2.0 documents that conform to the requirements of this content module shall indicate their conformance by the inclusion of the appropriate <templateId> elements in the header of the document. This is shown in the sample document below. A CDA Document may conform to more than one template. This content module inherits from the Medical Document content module, and so must conform to the requirements of that template as well, thus all <templateId> elements shown in the example below shall be included.

Sample Consent to Share Information Document

<ClinicalDocument xmlns='urn:hl7-org:v3'> <typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.1'/>  <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.7'/> <id root=' ' extension=' '/> <code code=' ' displayName=' ' codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/> <title>Consent to Share Information</title> <effectiveTime value='20260407012005'/> <confidentialityCode code='N' displayName='Normal' codeSystem='2.16.840.1.113883.5.25' codeSystemName='Confidentiality' /> <languageCode code='en-US'/>  : <component><structuredBody>     </structuredBody></component> </ClinicalDocument>

Schematron

<pattern name='Template_1.3.6.1.4.1.19376.1.5.3.1.1.7'>
 <rule context='*[cda:templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.1.7"]'>
   <!-- Verify that the template id is used on the appropriate type of object -->
   <assert test='../cda:ClinicalDocument'>
     Error: The Consent to Share Information can only be used on Clinical Documents.
   </assert> 
   <!-- Verify that the parent templateId is also present. -->
   <assert test='cda:templateId[@root="1.3.6.1.4.1.19376.1.5.3.1.1.1"]'>
     Error: The parent template identifier for Consent to Share Information is not present.
   </assert> 
   <!-- Verify the document type code -->
   <assert test='cda:code[@code = "{{{LOINC}}}"]'>
     Error: The document type code of a Consent to Share Information must be {{{LOINC}}}
   </assert>
   <assert test='cda:code[@codeSystem = "2.16.840.1.113883.6.1"]'>
     Error: The document type code must come from the LOINC code 
     system (2.16.840.1.113883.6.1).
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.2.6"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Consent to Share Information Document must contain a(n) Consent Service Event Entry.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.7 
   </assert> 
   <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.2.5"]'> 
     <!-- Note any missing optional elements -->
     Note: This Consent to Share Information Document does not contain a(n) Authorization Entry.
     See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.7 
   </assert> 
 </rule>
</pattern>

Constraints

A consent shall contain a text description of what the patient consented to, a list of codes indicating the policy(s) agreed to, a time range indicating the effective time of the consent, and shall contain a signature signifying the patient agreement to those policy(s) stated in the text description. Finally, consents may be attested to using an electronic digital signature, conforming to the ITI Digital Signature Profile.

The text description and signature may appear as a scanned image. When the consent contains a scanned image, it shall also conform to the constraints of the ITI Scanned Document profile.

A consent shall have one or more <serviceEvent> elements in the header identifying the policies authorized by the document (see Section 4.2.3.4 of CDAR2). Each <serviceEvent> element indicates informed consent to one and only one XDS Affinity Domain policy. More than one policy may be agreed to within a given consent document.

Consent documents should be attested to by either the patient and/or legal guardian, or a third party assigned by the XDS Affinity Domain or its member organizations. The attestation, if present, should be performed using the ITI Digital Signature profile. The signer may be the patient, or a third party.