Difference between revisions of "Query for Existing Data"

From IHE Wiki
Jump to navigation Jump to search
Line 255: Line 255:
  
 
=Volume II=
 
=Volume II=
−
{{:PCC-1}}
+
{{Title Page|
 +
Domain=Patient Care Coordination|
 +
Volume=Query for Existing Data (QED)<br/>Volume 2|
 +
Revision=2.0|
 +
Year=2006-2007|
 +
Status=Comment}}
  
−
{{:PCC-2}}
+
{{:PCC TF-2/Header}}
  
−
{{:PCC-3}}
+
{{:CDA Release 2.0 Content Modules}}
  
−
{{:PCC-4}}
+
{{:PCC TF-2/Trailer}}
−
 
 
−
{{:PCC-5}}
 
  
 
{{:Sending HL7 Version 3 Messages}}
 
{{:Sending HL7 Version 3 Messages}}
 +
</noinclude>

Revision as of 21:04, 14 June 2007

Introduction

This is a draft of the Query for Existing Data Profile (QED) supplement to the Patient Care Coordination Technical Framework. This draft is a work in progress, not the official supplement or profile.


For Public Comment Appendix D of Volume II and Appendix O of the ITI Technical Framework Volume II overlap in content. If you are reviewing this profile, we would like your feedback on the content of this appendix and of the ITI Appendix O. That appendix can be found in the PIX/PDQ Version 3 Profile Supplement


For Public Comment The WSDLs provided in Appendix E of this Profile Supplement are intended to conform to Appendix V of Volume II of the ITI Technical Framework. If you are reading this profile, you should also read that appendix. Please comment on any discrepancies that you may find.


Profile Abstract

The Query for Existing Data Profile (QED) supports dynamic queries for Clinical Data. A wide variety of systems often need access to dynamic clinical information stored and maintained in an EMR system or other clinical data repository. This profile makes the information widely available to other systems within and across enterprises to support provision of better clinical care. The information made available by this profile can be used to support clinical care, quality reporting, financial transactions, public health reporting, clinical trials, drug interaction checking, and patient qualification for various protocols.

Glossary

Clinical Data Repository
A Clinical Data Repository (CDR) is a database of clinical information on patients, often optimized for access by individual patients.

Volume I

Add the following bullet to the list of profiles
  • Query for Existing Data - This profile (QED) supports dynamic queries for Clinical Data. A wide variety of systems often need access to dynamic clinical information stored and maintained in an EMR system or other clinical data repository. This profile makes the information widely available to other systems within and across enterprises to support provision of better clinical care. The information made available by this profile can be used to support clinical care, quality reporting, financial transactions, public health reporting, clinical trials, drug interaction checking, and patient qualification for various protocols.

Dependencies

Add the following row(s) to the list of dependencies
Integration Profile Dependency Dependency Type Purpose
Query for Existing Data Audit Trail and Node Authentication Each actor in this profile shall be grouped with the ATNA Secure Node or Secure Application actor. Required to manage audit trail of exported PHI, node authentication, and transport encryption.
Query for Existing Data Consistent Time Each actor in this profile shall be grouped with the Time Client Actor Required to manage and resolve conflicts in multiple updates.

Query for Existing Data Profile (QED)

The Query for Existing Data Profile (QED) supports dynamic queries for clinical data. A wide variety of systems often need access to dynamic clinical information stored and maintained in an EMR system or other clinical data repository. This profile makes the information widely available to other systems within and across enterprises to support provision of better clinical care. The information made available by this profile can be used to support clinical care, quality reporting, financial transactions, public health reporting, clinical trials, drug interaction checking, and patient qualification for various protocols.

Classification of Information

The QED profile classifies information into six different categories for the purpose of determining where it might be found.

Common Observations
These are a collection of simple measurements or reported values that can be determined using simple measuring devices (e.g., Height, Weight), or which can be reported by the patient (date of last menstrual period). These measurements do NOT include anything that might be recorded as a problem, allergy, risk, or which requires interpretation, clinical decision making, or diagnostic quality equipment or procedures for performing the measurement.
Diagnostic Results
These are a collection of observations made or performed using laboratory testing equipment, imaging procedures, vision examinations, et cetera.
Problems and Allergies
These are a collection of diagnoses, clinical findings, allergies, or other risk factors that are recorded for the patient. The information may be obtained from patient reports, or through clinical decision making. It includes such information as would be found in social and family history sections of clinical reports. This classfication can be further subdivided into three groups.
Conditions
This is a collection of disease conditions for the patient.
Intolerances
This is a collection of the patient's allergies and other intolerances.
Risk Factors
This is a collection of the patients significant risk factors, as might be established based on a review of family history, social history, occupational exposures, et cetera. By themselves, they may not be indicitave of a disease condition, but could contribute to one.
Medications
This is a collection of the medications that a patient is or has been taking for treatment of one or more conditions.
Immunizations
This is a collection of immunizations that have been given, or which are planned to be given to the patient.
Professional Services
This is a collection of procedures and/or encounters which the patient has participated in, or is expected to participate in.

Each of these major classifications of information can often be found in distinct repositories of information. For example, patient vital signs, problems and allergies may be recorded in simple EHR sytem; diagnostic results in a laboratory or radiology information system; medications in a pharmacy information system, immunizations in an immunization registry, and professional services in a practice management system.

Actors/Transaction

There are six actors in this profile, the Clinical Data Consumer, and five different repositories of clinical data, including vitals, problems and allergies, diagnostic results, medications, and immunizations.

Query for Existing Data Actor Diagram


For Public Comment The Vital Signs Data Repository should probably become the Common Observations Data Repository, because it should be able to contain more than just vital signs measurements.


The table below lists the transactions for each actor directly involved in the Query for Existing Data Profile. In order to claim support of this Integration Profile, an implementation must perform the required transactions (labeled 'R'). Transactions labeled 'O' are optional. A complete list of options defined by this Integration Profile and that implementations may choose to support is listed below under Options.

Actor Name Optionality Transaction
Query for Existing Data Actors and Transactions
Clinical Data Consumer Query Vital Signs O1 PCC-1
Query Problems and Allergies O1 PCC-2
Query Diagnostic Data O1 PCC-3
Query Medications O1 PCC-4
Query Immunizations O1 PCC-5
Vital Signs Data Repository Query Vital Signs R PCC-1
Problems and Allergies Repository Query Problems and Allergies R PCC-2
Diagnostic Data Repository Query Diagnosic Data R PCC-3
Medications Repository Query Medications R PCC-4
Immunizations Repository Query Immunizations R PCC-5

Note 1: The Actor shall support at least one of these transactions.

Options

Actor Option
Query for Existing Data Options
Vital Signs Data Repository None Defined
Problems and Allergies Data Repository
Diagnostic Data Repository
Medications Data Repository
Immunizations Data Repository
Clinical Data Consumer Vital Signs Option (1)
Problems and Allergies Option (1)
Diagnostic Data Option (1)
Medications Option (1)
Immunizations Option (1)

(1) At least one of these options shall be supported by a Clinical Data Consumer Actor

Vital Signs Option

A Clinical Data Consumer that implements the Vital Signs Option implements the Query Vital Signs transaction.

Problems and Allergies Option

A Clinical Data Consumer that implements the Problems and Allergies Option implements the Query Problems and Allergies transaction.

Diagnostic Data Option

A Clinical Data Consumer that implements the Diagnostic Data Option implements the Query Diagnostic Data transaction.

Medications Option

A Clinical Data Consumer that implements the Medications Option implements the Query Medications transaction.

Immunizations Option

A Clinical Data Consumer that implements the Immunizations Option implements the Query Immunizations transaction.

Grouping

Clinical Data Repositories

Any of the repository actors of this profile can be grouped with other repository actors. For example, an EMR might implement all of the repository actors of this profile, while a pharmacy system might implement only the Immunizations and Medications Repository actors.

When actors are grouped in this fashion, it is expected that they will provide appropriate join fields to show relationships between different records. For example, when a EMR groups together the Medication Data Repository and Problems and Allergies Data Repository, and recieves a request for Medications, it should also return the Problems, and internal references to those problems that are the reason for prescribing the medication.

Audit Trail and Node Authentication and Consistent Time

All actors of this profile shall be grouped with either the Secure Node or the Secure Application actor, to ensure the security of the information being exchanged. These actors shall also implement Time Client to ensure that consistent time is maintained across systems.

TBD -- what specifically are the logging requirements under this profile

  • Login/Logout
  • Actor Start/Stop
  • Query
  • Import (if the reciever imports the queried data)
  • Export

Retrieve Form for Data Capture

A Clinical Data Consumer actor may be grouped with an Form Filler or Form Manager actor to appropriately populate forms with recently gathered clinical data.

Cross Enterprise Document Sharing

A Repository actor may be grouped with a Cross Enterprise Document Repository actor. Data gathered from clinical documents submitted to the Document Repository can be a source of information returned by the Repository actor. Information returned by the Repository shall include references to all documents used in generating the results.

Content Integration Profiles

A Content Creator may be grouped with a Clinical Data Consumer to obtain some or all of the information necessary to create a Medical Summary based on information found in a Repository.

A Content Creator may be grouped with a Data Repository. When grouped with a Data Repository, the Data Repository Actor shall respond to queries containing the relevant vocabulary codes used by the Content Creator.


For Public Comment The assumption is that if a system can create content using a particular code, then it should also be able to respond to queries using that same code.


Patient Identity Cross Referencing and Patient Demographics Query

A clinical data consumer may be grouped with a Patient Identifier Cross-reference Consumer or a Patient Demographics Consumer actor to resolve patient identifiers prior to submitting queries to a Repository.

Within an enterprise, the need to cross-reference patient identifiers may not be necessary. However, once enterprise boundaries are crossed, these identifiers will need to be resolved. In that case either PIX or PDQ shall be used.

Process Flow

Query for Existing Data Process Flow

Clinical Trials

A patient participating in a clinical trial arrives for a trial-related visit to a physician office. The physician completes a report in his/her EMR gathering information relevant to the trial. Upon completion of the visit, a research assistant gathers the data relevant to the trial and submits it to the clinical trial information system. Among the data needed to gather are the patient's current medications.

The research assistant logs into the clinical trial information system, and enters data about the patient visit pertinent to the trial. The clinical trial information system performs a query of the EMR using [PCC-4] where the patient data is stored, and obtains the list of the patient's current medications.

Claims

A claims administrator begins a claim for treatment of a patient who is pregnant. They log into their practice management system to begin processing the claim. Since this claim is for services provided during pregnancy, a patient measurement is needed to complete the claim. The practice management / billing system queries the EMR for the date of last menstruation for the patient using [PCC-1], and completes the claim.

Drug Safety

Medication is about to be administered at a modality. Prior to administration, the modality queries the EMR for current problems and allergies and medications using PCC-3 and PCC-4 to enable display of this information to the operator, or to send to a decision support system to determine if this medication is OK to administer.

A CPOE system needs to generate a medication order for a patient for a medication whose dosage is based on weight. Prior to generating the order, the system will query the EMR for the most recent weight measurements of the patient to determine the correct dose using [PCC-1]. The system also request information about the patient's current problems and allergies using [PCC-3], and medications using [PCC-4] to perform drug interaction checking before completing the order.

Public Health, Biosurveillance, and Disease Registries

During a routine pediatric visit, an EMR queries an immunization registry for the immunization history for the patient using [PCC-5]. Upon review of the information, it appears that on a recent visit, the patient was scheduled for immunization, but the immunization was not given due to a current fever. The fever ius not longer present, so the immunization is given to the patient.

Upon completion of the visit, a reporting application is notified. The reporting application queries the EMR visit data to see if any immunizations were given during the just completed visit using [PCC-5]. If an immunization was given during the visit, the reporting application collects the appropriate data and submits it to an immunization registry.

Identifying Qualifying Patients

Decision support systems can query the EMR to obtain specific data elements for a patient, and use that information to determine if the patient qualifies for a clinical trial, or if the visit is one that requires additional reporting.

Upon completion of a visit, the EMR activates a decision support system. The decision support system queries the EMR for patient diagnoses using PCC-3. Upon determining that the patient has been diagnosed with Diabetes, the decision support system notifies the EMR that it needs to activate protocols for diabetic care. This use case could be continued as described in the section below.

Quality Reports and Disease Management

Upon completion of a visit, certain quality measures need to be gathered in order to produce an aggregate measure. A quality system can query the EMR to determine for each patient the values that need to be measured.

A diabetic patient completes a routine visit. The EMR queries a Lab Result Repository using PCC-2 to determine if a recent HgA1C result is available from the last six months using [PCC-2]. Upon failing to find one the EMR system notifies the physician that an updated HgA1C test is required.

Disease Management

A physician wants to monitor a patient's blood sugar levels and body mass index. She requests a graph of the patient's blood sugar lab results (lab) and BMI (vital signs) for the past 9 months from a desktop application. The desktop application queries the EMR for the selected vital signs for the indicated time period using PCC-1, and graphs the data appropriately.

Actor Definitions

Clinical Data Consumer
A clinical data consumer makes use of clinical patient data.
Vital Signs Data Repository
A Vital Signs Data Repository maintains patient vital signs data.
Problems and Allergies Repository
A Problems and Allergies Repository maintains patient problem and allergy data.
Diagnostic Data Repository
A Diagnostic Data Repository Repository maintains results from diagnostic tests (e.g., Lab, Imaging, or other test results).
Medications Data Repository
A Medications Data Repository maintains patient medication data.
Immunizations Data Repository
An Immunizations Data Repository maintains patient immunization data.

Transaction Definitions

Query Vital Signs
Request information about recent patient measurements, usually used to obtain vital signs measurements. The query may request all measurements, or those taken for a specific encounter, or date range, or may be for a specific set of measurements.
Query Problems and Allergies
Request information about problems or allergies known for a patient, usually to determine the patients current problems and allergies. The query may request information about all problems, all allergies, or may request information on a specific problem or allergy entry, entered during a specific encounter or date range.
Query Diagnostic Data
Request information about diagnostic results known for a patient. The query may request information about all diagnostic results, or may request information on a specific diagnostic result entry, or one entered for a specific encounter or date range.
Query Medications
Request information about medications given to, or being taken by a patient. The query may request information about all medications or may request information on a specific kind of medication or immunization, or one entered for a specific encounter or date range.
Query Immunizations
Request information about immunizations given to a patient. The query may request information about all immunizations, all immunizations or may request information on a specific kind of medication or immunization, or one entered for a specific encounter or date range.

Volume II

HIMSS and RSNA
Integrating the Healthcare Enterprise

IHEBandW.png

IHE Patient Care Coordination

Technical Framework
Query for Existing Data (QED)
Volume 2

Revision 2.0
2006-2007

Comment


HIMSS and RSNA
Integrating the Healthcare Enterprise

IHEBandW.png

IHE Patient Care Coordination

Technical Framework
Volume II

Revision 3.0
2008-2009

Public Comment


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.

Basic Patient Privacy Consents (BPPC)

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)

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

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.

HL7 Version 3.0 Content Modules

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

CDA Document Content Modules

CDA Header Content Modules

CDA Section Content Modules

This list defines the sections that may appear in a medical document. It is intended to be a comprehensive list of all document sections that are used by any content profile defined in the Patient Care Coordination Technical Framework. All sections shall have a narrative component that may be freely formatted into normal text, lists, tables, or other appropriate human-readable presentations. Additional subsections or entry content modules may be required.





Impressions


CDA and HL7 Version 3 Entry Content Modules

Appendix A - Examples Using PCC Content Profiles

Example documents conforming to each profile can be found on the IHE wiki at the following URLs.

Profile and Content URL
XDS-MS  
 Referral Summary XDSMS Example1
 Discharge Summary XDSMS Example1
XPHR  
 XPHR Content XPHR Example1
 XPHR Update XPHR Example2
(EDR) ED Referral EDR Example
(APS) Antepartum Summary APS Example
(EDES)  
 Triage Note EDES Example1
 ED Nursing Note EDES Example2
 Composite Triage and Nursing Note EDES Example3
 ED Physician Note EDES Example4
(FSA) Functional Status Section FSA Example

Appendix B - Validating CDA Documents using the Framework

Many of the constraints specified by the content modules defined in the PCC Technical Framework can be validated automatically by software. Automated validation is a very desirable capability, as it makes it easier for implementers to test the correctness of their implementations. With regard to validation of the content module, the PCC Technical Framework narrative is the authoritative specification, not any automated software tool. Having said that, it is still very easy to create a validation framework for the IHE PCC Technical Framework using a XML validation tool such as Schematron. Since each content module has a name (the template identifier), any XML instance that reports itself to be of that "class" can be validated by creating assertions that must be true for each constraint indicated for the content module. In the XML representation, the <templateId> element is a child of the element that is claiming conformance to the template named. Thus the general pattern of a Schematron that validates a specific template is shown below: 

<schema xmlns="http://www.ascc.net/xml/schematron" xmlns:cda="urn:hl7-org:v3">
  <ns prefix="cda" uri="urn:hl7-org:v3" />
  <pattern name='ReferralSummary'>
    <rule context='*[cda:templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.1.3]"'>
      <!-- one or more assertions made by the content module -->
    </rule>
  </pattern>
</schema>

Validating Documents

For document content modules, the pattern can be extended to support common document content module constraints as shown below: 

<schema xmlns="http://www.ascc.net/xml/schematron" xmlns:cda="urn:hl7-org:v3">
  <ns prefix="cda" uri="urn:hl7-org:v3" />
  <pattern name='ReferralSummary'>
    <rule context='*[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='../ClinicalDocument'>
        Error: The referral content module can only be used on Clinical Documents.
      </assert>
      <!-- Verify that the parent templateId is also present. -->
      <assert test='templateId[@root="1.3.6.1.4.1.19376.1.5.3.1.1.2"]'>
        Error: The parent template identifier for medical summary is not present.
      </assert>
      <!-- Verify the document type code -->
      <assert test='code[@code = "34133-9"]'>
        Error: The document type code of a referral summary must be
        34133-9 SUMMARIZATION OF EPISODE NOTE.
      </assert>
      <assert test='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>
      <!-- Verify that all required data elements are present -->
      <assert test='.//templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
        Error: A referral summary must contain a reason for referral.
      </assert>
      <!-- Alert on any missing required if known elements -->
      <assert test='.//templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.8"]'>
        Warning: A referral summary should contain a list of history of past illnesses.
      </assert>
      <!-- Note any missing optional elements -->
      <assert test='.//templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.18"]'>
        Note: This referral summary does not contain the pertinent review of systems.
      </assert>
    </rule>
  </pattern>
</schema>

Validating Sections

The same pattern can be also applied to sections with just a few minor alterations. 

<schema xmlns="http://www.ascc.net/xml/schematron" xmlns:cda="urn:hl7-org:v3">
  <ns prefix="cda" uri="urn:hl7-org:v3" />
  <pattern name='ReasonForReferralUncoded'>
    <rule context='*[templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
      <!-- Verify that the template id is used on the appropriate type of object -->
      <assert test='section'>
        Error: The coded reason for referral module can only be used on a section.
      </assert>
      <assert test='false'>
        Manual: Manually verify that this section contains narrative providing the
        reason for referral.
      </assert>
      <!-- Verify that the parent templateId is also present. -->
      <assert test='templateId[@root="1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
        Error: The parent template identifier for the reason for referral 
        module is not present.
      </assert>
      <!-- Verify the section type code -->
      <assert test='code[@code = "42349-1"]'>
        Error: The section type code of the reason for referral section must be 42349-1
        REASON FOR REFERRAL.
      </assert>
      <assert test='code[@codeSystem = "2.16.840.1.113883.6.1"]'>
        Error: The section type code must come from the LOINC code 
        system (2.16.840.1.113883.6.1).
      </assert>
  </pattern>
  <pattern name='ReasonForReferralCoded'>
    <rule context='*[templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.3.2"]'>
      <!-- The parent template will have already verified the type of object -->
      <!-- Verify that the parent templateId is also present. -->
      <assert test='templateId[@root="1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
        Error: The parent template identifier for the reason for referral 
        module is not present.
      </assert>
      <!-- Don't bother with the section type code, as the parent template caught it -->
      <!-- Verify that all required data elements are present -->
      <assert test='.//templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.4.13"]'>
        Error: A coded reason for referral section must contain an simple observation.
      </assert>
      <!-- Alert on any missing required if known elements -->
      <!-- Note any missing optional elements -->
    </rule>
  </pattern>
</schema>

A similar pattern can also be followed for Entry and Header content modules, and these are left as an exercise for the reader.

Phases of Validation and Types of Errors

Note that each message in the Schematrons shown above start with a simple text string that indicates whether the message indicates one of the following conditions:

  • An error, e.g., the failure to transmit a required element,
  • A warning, e.g., the failure to transmit a required if known element,
  • A note, e.g., the failure to transmit an optional element.
  • A manual test, e.g., a reminder to manually verify some piece of content.

Schematron supports the capability to group sets of rules into phases by the pattern name, and to specify which phases of validation should be run during processing. To take advantage of this capability, one simply breaks each <pattern> element above up into separate patterns depending upon whether the assertion indicates an error, warning, note or manual test, and then associate each pattern with a different phase. This is shown in the figure below. 

<schema xmlns="http://www.ascc.net/xml/schematron" xmlns:cda="urn:hl7-org:v3">
  <ns prefix="cda" uri="urn:hl7-org:v3" />
  <phase id="errors">
    <active pattern="ReasonForReferralUncoded_Errors"/>
    <active pattern="ReasonForReferralCoded_Errors"/>
  </phase>
  <phase id="manual">
    <active pattern="ReasonForReferralUncoded_Manual"/>
  </phase>
  <pattern name='ReasonForReferralUncoded_Errors'>
    <rule context='*[templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
      <assert test='section'>
        Error: The coded reason for referral module can only be used on a section.
      </assert>
      <assert test='code[@code = "42349-1"]'>
        Error: The section type code of the reason for referral section must be 42349-1
        REASON FOR REFERRAL.
      </assert>
      <assert test='code[@codeSystem = "2.16.840.1.113883.6.1"]'>
        Error: The section type code must come from the LOINC code 
        system (2.16.840.1.113883.6.1).
      </assert>
    </rule>
  </pattern>
  <pattern name='ReasonForReferralUncoded_Manual'>
    <rule context='*[templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
      <assert test='false'>
        Manual: Manually verify that this section contains narrative providing the
        reason for referral.
      </assert>
  </pattern>
  <pattern name='ReasonForReferralCoded_Errors'>
    <rule context='*[templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.3.2"]'>
      <assert test='templateId[@root="1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
        Error: The parent template identifier for the reason for referral not present.
      </assert>
      <assert test='.//templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.4.13"]'>
        Error: A coded reason for referral section must contain an simple observation.
      </assert>
    </rule>
  </pattern>
</schema>

Using these simple "templates" for template validation one can simply create a collection of Schematron patterns that can be used to validate the content modules in the PCC Technical Framework. Such Schematrons are expected to be made available as part of the MESA test tools that are provided to IHE Connectathon participants, and which will also be made available to the general public after connectathon.

Appendix C - Extensions to CDA Release 2.0

This section describes extensions to CDA Release 2.0 that are used by the IHE Patient Care Coordination Technical Framework.

IHE PCC Extensions

All Extensions to CDA Release 2.0 created by the IHE PCC Technical Committee are in the namespace urn:ihe:pcc:hl7v3.

The approach used to create extension elements created for the PCC Technical Framework is the same as was used for the HL7 Care Record Summary (see Appendix E) and the ASTM/HL7 Continuity of Care Document (see secion 7.2).

replacementOf

The <replacementOf> extension element is applied to a section appearing in a PHR Update Document to indicate that that section's content should replace that of a previously existing section. The identifier of the previously existing section is given so that the PHR Manager receiving the Update content will know which section to replace. The model for this extension is shown below.

Model for replacementOf

Use of this extension is shown below. The <replacementOf> element appears after all other elements within the <section> element. The <id> element appearing in the <externalDocumentSection> element shall provide the identifier of the section being replaced in the parent document.

Example use of the replacementOf extension 
<section>
 <id root=' ' extension=' '/>
 
 <title>Name of the Section</title>
 <text>Text of the section</text>
 <entry></entry>
 <component></component>
 <pcc:replacementOf xmlns:pcc='urn:ihe:pcc:hl7v3'>
   <pcc:externalDocumentSection>
     <pcc:id root='58FCBE50-D4F2-4bda-BC1C-2105B284BBE3'/>
   <pcc:externalDocumentSection/>
 </pcc:replacementOf>
</section>

Extensions Defined Elsewhere used by IHE PCC

Entity Identifiers

There is often a need to record an identifer for an entity so that it can be subsequently referenced. This extension provides a mechnism to store that identifier. The element appears after any <realm>, <typeId> or <templateId> elements, but before all others in the entity where it is used: 

<playingEntity classCode='ENT' determinerCode='INSTANCE'>
 <sdtc:id root='1.3.6.4.1.4.1.2835.2' extension='EntityID'/>
   :
   .
</playingEntity>

Patient Identifier

There is a need to record the identifer by which a patient is known to another healthcare provider. This extension provides a role link between the assigned, related or associated entity, and the patient role.

Use of this extension to record the identifier under which the patient is known to a provider is shown below.

Example use of the Patient Identifier Extension 
<assignedEntity>
 <id extension='1' root='1.3.6.4.1.4.1.2835.1'/>
 
 <addr>
   <streetAddressLine>21 North Ave</streetAddressLine>
   <city>Burlington</city>
   <state>MA</state>
   <postalCode>01803</postalCode>
   <country>USA</country>
 </addr>
 <telecom value='tel:(999)555-1212' use='WP'/>
 <assignedPerson>
   <name>
     <prefix>Dr.</prefix><given>Bernard</given><family>Wiseman</family><suffix>Sr.</suffix>
   </name>
 </assignedPerson>
 <sdtc:patient xmlns:sdtc='urn:hl7-org:sdtc' >
   <sdtc:id root='1.3.6.4.1.4.1.2835.2' extension='PatientMRN'/>
 </sdtc:patient>
</assignedEntity>

The <patient> element records the link between the related, assigned or associated entity and the patient. The <id> element provides the identifier for the patient. The root attribute of the <id> should be the namespace used for patient identifiers by the entity. The extension attribute of the <id> element shall be the patient's medical record number or other identifier used by the entity to identify the patient.

Appendix D - Sending HL7 Version 3 Messages

For Public Comment This appendix and Appendix O of the ITI Technical Framework overlap in content. If you are reviewing this profile, we would like your feedback on the content of this appendix and of the ITI Appendix. Appendix O of the ITI Technical Framework can be found in the PIX/PDQ Version 3 Profile


HL7 Version 3 messages are sent in XML. Each message has information related to:

  1. Messaging Infrastructure
  2. Control Act
  3. Domain Content

The first two components are described in greater detail below. Domain content is decribed in further detail within the IHE Profiles.

Message Infrastructure

This section of the message conveys information about the message itself, including:

  • The message identity
  • Creation time of the message
  • The message type
  • Processing controls on the message
  • Identity of the sending and recieving systems
  • The control act which is being conveyed in the message

An example message illustrating the message infrastructure elements is shown below. 

<HL7Interaction xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <id root=' ' extension=' '/>
 <creationTime value=' '/>
 <interactionId extension='HL7Interaction' root='2.16.840.1.113883'/>
 <processingCode code='D|P|T'/>
 <processingModeCode code='A|T|I|R'/>
 <acceptAckCode code='AL|ER|NE'/>
 <receiver typeCode="RCV">
   <device determinerCode="INSTANCE">
     <id/>
     <name/>
     <desc/>
     <existenceTime><low value=' '/></existenceTime>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </receiver>
 <sender typeCode="SND">
   <device determinerCode="INSTANCE">
     <id/>
     <name/>
     <desc/>
     <existenceTime><low value=' '/></existenceTime>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </sender>
 <controlActProcess>
  See Control Act Process below
 </controlActProcess>
</HL7Interaction>

<HL7Interaction xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> =

The HL7 Interaction being sent will control the name of the root element in the message. The namespace of this message shall be urn:hl7-org:v3, and the ITSVersion attribute shall be "XML_1.0".

<id root=' ' extension=' '/>

Each message shall be uniquely identified. The root attribute is required, the extension attribute may be used if the root attribute is insufficient to uniquely identify the message instance.

<creationTime value=' '/>

The creationTime indicates when the message was created, and shall be sent with a timestamp that is precise to at least 1/100th of a second.

<interactionId extension='HL7Interaction' root='2.16.840.1.113883'/>

The identifer for the interaction shall be sent. The extension value shall be valued with the HL7 Interaction identifier specified within the standard. The root attribute shall be set to the value 2.16.840.1.113883 to identify this as an HL7 interaction.

<processingCode code='D|P|T'/>

The processingCode element identifiers whether this message is being sent for debugging, production or training respectively. It shall be present and have one of the values D, P or T, as shown above.

<processingModeCode code='A|T|I|R'/>

The processingModeCode distinguishes the type of processing being performed, using the values A, T, I or R for Archive, current processing, Initial load, or Restore from archive respectively. This element shall be present and have one of the values shown above.

<acceptAckCode code='AL|ER|NE'/>

The acceptAckCode indicates whether the reciever wants to recieve an acknowledgement Always (AL), only on errors (ER), or never (NE). Unless reliable message transport has been established through some other mechanism, any message that would result in the potential alteration of clinical data shall be sent with the acceptAckCode set to AL, and any message that performs queries or is otherwise non-destructive should be set the value to 'ER' or 'AL'.

<receiver typeCode="RCV">
<sender typeCode='SND'/>

The reciever and sender elements shall be used to identify the systems responsible for recieving and sending the messages.

<id/>

The id element is required and identifies the sender or reciever of the message.

<name/>

The name element may be sent to provide a human readable name for the sender or reciever.

<existenceTime><low value=' '/></existenceTime>

The existenceTime element may be set by the sender on the sender element, or by the reciever on the reciever element to indicate the time at which the sending or recieving process was last started. The sender should not set this value for the reviever, and visa-versa.

<telecom value=' ' />

The telecommunications address for the sender and/or reciever may be sent. This address is the URL at which the sender or reciever is originating or recieving messages. The URL shall be the URL of the appropriate web service end-point.

<manufacturerModelName/>

The manufacturer model name may be set by the sender or reciever to indicate a human readable description of the manufacturer model name of the sending or recieving device. Once again, the senders and recievers should only set these values for themselves.

<softwareName/>

The software name may be set by the sender or reciever to indicate a human readable description of the software being used to send or recieve the message. Once again, the senders and recievers should only set these values for themselves.

Control Act Process

This section of the message identifies the action and provides information the business actors related to the transaction. This includes:

  • The author or performer of the act
  • The information recipients to who the information will be conveyed
  • The domain content related to the act
 <controlActProcess moodCode="RQO|EVN">
   <id root=' ' extension=' '/>
   <code code='QUPC_TE043100UV'/>
   <effectiveTime value=' '/>
   <languageCode code=' '/>
   <authorOrPerformer typeCode=' '></authorOrPerformer>
   <informationRecipient typeCode=' '></informationRecipient>
   <!-- Performing a Query -->
   <queryByParameter>
     <statusCode code='new'/>
     <initialQuantity value=' '/>
     <initialQuantityCode code=' ' codeSystem='2.16.840.1.113883'>
     <parameterList>
       :
       Domain Content
     </parameterList>
   </queryByParameter>
   <!-- Returning Results -->
   <subject>
      :
      Domain Content
   </subject>
   <!-- Any response to a query (returning results, acknowledging a cancelation, or returning an error -->
   <queryAck>
     <queryId root=' ' extension=' '/>
     <statusCode code=' '/>
     <queryResponseCode code=' '/>
     <resultTotalQuantity value=' '/>
     <resultCurrentQuantity value=' '/>
     <resultRemainingQuantity value=' '/>
   </queryAck>
   <!-- Requesting more results or cancelling a query -->
   <queryContinuation>
     <queryId root=' ' extension=' '/>
     <statusCode code='waitContinuedQueryResponse|aborted'/>
     <startResultNumber value=' '/>
     <continuationQuantity value=' '/>
   </queryContinuation>
   </queryContinuation>
 </controlActProcess>

<controlActProcess moodCode="RQO|EVN">

The controlActProcess element is where information about the business act being performed is recorded. The moodCode is set to "RQO" by the sender to indicate a request to perform an action. The reciever will often return a new controlActProcess element in moodCode "EVN" to indicate that the act has been performed.

<id root=' ' extension=' '/>

Each control act may have a unique identifier, recorded in the id element. The root attribute must be present. The extension attribute may be present to further distinguish the identifier.

<code code='QUPC_TE043100UV'/>

The trigger event which caused the act to be transmitted shall be recorded in the code element.

<effectiveTime value=' '/>

The date and time of the trigger event shall be recorded in the effectiveTime of the control act. This is timestamp is distinct from the time of message transmission in the transmission wrapper.

<languageCode code=' '/>

The primary language used within the message content is identified in the languageCode element. This element shall be present.

<authorOrPerformer typeCode=' '></authorOrPerformer>

This element may be present to identify the business actors responsible for the message transmission.

<informationRecipient typeCode=' '></informationRecipient>

This element may be present to identify the business actors expected to recieve the result of the message.

Performing a Query

<queryByParameter>

For HL7 Version 3 messages that perform a query, the query is specified in the <queryByParameter> element.

<statusCode code='new'/>

When passing the parameter list, the <statusCode> element shall be recorded as above to indicate that this is a new query.

<initialQuantity value=' '/>

The <initialQuantity> element may be present to specify the initial number of data elements to be returned. The responder must send no more than the specified number of data elements in the response, but may send fewer than requested.

<initialQuantityCode code=' ' codeSystem='2.16.840.1.113883'>

The <initialQuantityCode> element indicates hoow responses are counted. This element must be specified when the <initialQuantity> element is present. It indicates the HL7 structures to count when determining the total number of data elements to return. The code is the identifier of the HL7 artifact to count (i.e., the R-MIM or C-MET identifier). Each query should indicate what structures are counted within the detail of the transaction. The rationale for counting based on HL7 structures is that each query is expected to return one or more "rows", and each row is expected to coorespond to an HL7 structure that is being returned.

<parameterList>

The <parameterList> data element shall be provided. This data element contains a domain specific set of parameters. These parameters will be described in the transaction detail.

Returning Results

<subject>
 Domain Content
</subject>

For typical HL7 version 3 messages, the domain content is accessible through the subject element, as is the domain content that is generated in response to a query.

<queryAck>

The queryAck element is transmitted in any message that is a response to a query, query continuation or query cancellation message.

<queryId root=' ' extension=' '/>

The queryId element shall be transmitted in a queryAck element. It shall contain an identifier that may be used in subsquent messages to obtain more results, or to cancel the query.

<statusCode code=' '/>

The statusCode element in the queryAck element indicates the status of the query. It may contain the value 'deliveredResponse' or 'aborted'. If the value is 'aborted', no additional messages should be sent to the data repository for the specified query.

<queryResponseCode code=' '/>

The queryResponseCode element indicates at a high level the results of performing the query. It may have the value 'OK' to indicate that the query was performed and has results. It may have the value 'NF' to indicate that the query was performed, but no results were located. Finally, it may have the value 'QE' to indicate that an error was detected in the incoming query message.

<resultTotalQuantity value=' '/>

The resultTotalQuantity element should be present, and if so, enumerates the number of results found. It shall be present once the last result has been located by the data repository. This element gives the count of the total number of results located by the query. When present, the resultRemainingQuantity element shall also be present.

<resultCurrentQuantity value=' '/>

The resultCurrentQuantity element shall be present, and shall enumerate number of results returned in the current response.

<resultRemainingQuantity value=' '/>

This resultRemainingQuantity element may be present, and shall be present if resultTotalQuantity is present. It shall enumerate the number of results that follow the results currently returned.

Continuation or Cancellation of a Query

<queryContinuation>

The queryContinuation element shall be sent in messages that are used to obtain more query results or cancel a current query.

<queryId root=' ' extension=' '/>

The identifier of the query to continue or cancel shall be reported in the queryId element.

<statusCode code='waitContinuedQueryResponse|aborted'/>

The statusCode element shall be sent, and indicates whether this is a continuation or cancellation of the query. If the query is to be continued, the code attribute shall be set to waitContinuedQueryResponse. If the query is to be canceled, it shall be set to aborted.

<startResultNumber value=' '/>

The startResultNumber element may be sent to indicate the query result to start returning from. If this element is sent, it shall be honored by the data repository. If this element is omitted, results will be sent that follow the last set of results sent. Results are numbered from 1, so setting this value to 1 will start with the first result returned. Setting this value to a number less than 1 will result in undefined application behavior.

<continuationQuantity value=' '/>

The continuationQuantity element shall be sent on cancelation requests, and shall have a value of 0. For continuation requests, this element may be sent to indicate the number of results that should be returned. The data repository may send fewer results than requested, but shall send no more than this value.

Retrieved from "http://wiki.ihe.net/index.php?title=Query_for_Existing_Data&oldid=7744"