Template

Show index

Template Sharing Laboratory Reports (XD-LAB) Content Module 2016‑07‑05

Id1.3.6.1.4.1.19376.1.3.3
ref
XDLAB-
Effective Date2016‑07‑05
Statusactive ActiveVersion Label2017
NameIHEXDLABDisplay NameSharing Laboratory Reports (XD-LAB) Content Module
Description
en-US

Sharing Laboratory Reports (XD-LAB) Content Module

This Content Integration Profile describes a laboratory report as an electronic document to be published towards a document sharing resource such as an Electronic Health Record (EHR) or Personal Health Record (PHR) shared by a community of care providers, using one of the document sharing profiles defined in ITI-TF.

Such an electronic document contains the set of releasable results produced by a clinical laboratory or by a public health laboratory in fulfillment of an Order or an Order Group for a patient. The report is shared in a human-readable format. In addition, this electronic laboratory report SHALL contain test results in a machine-readable format, to facilitate the integration of these observations in the database of a consumer system.

The human rendering of the laboratory report defined in this Integration Profile is compatible with laboratory regulations in numerous countries, including CLIA in the USA, GBEA in France.

The laboratory report described in this profile, with its set of test results in a machine-readable format, MAY also be used to share historical results with appropriate content anonymization and patient identification pseudonymization to create shared distributed repositories of laboratory information.

ContextPathname /
ClassificationCDA Document Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 0 transactions and 0 templates, Uses 14 templates
Uses as NameVersion
1.3.6.1.4.1.19376.1.3.3.1.1Includeactive Human Patient (2017)DYNAMIC
1.3.6.1.4.1.19376.1.3.3.1.2Includeactive Non-Human Subject (2017)DYNAMIC
1.3.6.1.4.1.19376.1.3.3.1.3Includeactive Human Patient with Non-Human Subject (2017)DYNAMIC
1.3.6.1.4.1.19376.1.3.3.1.4Includeactive XD-LAB Information Recipient (2017)DYNAMIC
1.3.6.1.4.1.19376.1.3.3.1.5Containmentactive Laboratory Results Validator (2017)DYNAMIC
1.3.6.1.4.1.19376.1.3.3.1.6Includeactive Ordering Provider (2017)DYNAMIC
1.3.6.1.4.1.19376.1.3.3.2.1Containmentactive Laboratory Specialty Section (2017)DYNAMIC
1.3.6.1.4.1.19376.1.3.10.2.2Includeactive XD-LAB Author (2017)DYNAMIC
1.3.6.1.4.1.19376.1.3.10.2.3Includeactive XD-LAB Custodian (2017)DYNAMIC
1.3.6.1.4.1.19376.1.3.10.2.4Includeactive XD-LAB LegalAuthenticator (2017)DYNAMIC
1.3.6.1.4.1.19376.1.3.10.9.14Includeactive XD-LAB InFulfillmentOf Order (2017)DYNAMIC
1.3.6.1.4.1.19376.1.3.10.9.15Includeactive XD-LAB DocumentationOf (2017)DYNAMIC
1.3.6.1.4.1.19376.1.3.10.9.16Includeactive XD-LAB RelatedDocument (2017)DYNAMIC
1.3.6.1.4.1.19376.1.3.10.9.20Includeactive XD-LAB ComponentOf (2017)DYNAMIC
RelationshipSpecialization: template 2.16.840.1.113883.10.12.2 CDA ClinicalDocument (with StructuredBody) (2005‑09‑07)
ref
ad1bbr-
ItemDTCardConfDescriptionLabel
hl7:ClinicalDocument
IHEXDLAB
hl7:realmCode
CS1 … 1Ren-US

This element SHALL be present and is valued from the RealmOfUse [2.16.840.1.113883.1.11.11050] subset, within the VocabularyDomainQualifier value set. In the international context of this profile used as it is without any further extension, the realm code SHALL be <realmCode code="UV"/> (universal).

Whenever a national extension has been defined and is used, the realm code SHALL identify this national extension.

IHEXDLAB
 Example
Example for a French extension
<realmCode code="FR"/>
hl7:typeId
II1 … 1Men-US

This element is a technology-neutral explicit reference to the standard CDA R2. It SHALL be present and valued as follows:
ClinicalDocument/typeId@root = "2.16.840.1.113883.1.3" (which is the OID for HL7 Registered models);
ClinicalDocument.typeId@extension = "POCD_HD000040" (which is the unique identifier for the CDA, Release Two Hierarchical Description).

IHEXDLAB
@root
uid1 … 1F2.16.840.1.113883.1.3
@extension
st1 … 1FPOCD_HD000040
hl7:templateId
II1 … 1Men-US

This element is identifying the set of constraints applied to the CDA R2 standard by this IHE specification of a laboratory report. The following templateId SHALL be present and valued as follows to indicate compliance with the XD-LAB specification.

IHEXDLAB
@root
uid1 … 1F1.3.6.1.4.1.19376.1.3.3
hl7:id
II1 … 1Men-US

ClinicalDocument/Id SHALL be present. It represents the unique instance identifier of the clinical document. The combination of the root and extension attributes SHALL provide a globally unique identifier, in accordance with CDA R2, without further constraints.

IHEXDLAB
 Example
Example using the extension attribute
<id root="1.3.6.1.4.1.19376.1.3.4" extension="abc2"/>
 Example
Example without the extension attribute
<!-- In this case the OID populated in the root attribute is the unique instance identifier itself
(The OID in this example is constructed from the OID dedicated to all examples in IHE LAB TF: 1.3.6.1.4.1.19376.1.3.4)-->
<id root="1.3.6.1.4.1.19376.1.3.4.1232669"/>
hl7:code
CE1 … 1Men-US

ClinicalDocument/code SHALL be present. The laboratory report can be either a multi-disciplinary report or a single discipline report.

Multi-disciplinary Laboratory Report:
The LOINC code identifying the type of document as a (potentially) multidisciplinary laboratory report (presenting results from many specialties) is:
<code codeSystem="2.16.840.1.113883.6.1" codeSystemName=”LOINC” code="11502-2" displayName="LABORATORY REPORT.TOTAL"/>

Single Discipline Laboratory Report:
Use the appropriate LOINC code as listed in Value-Set “Laboratory Specialties”.

IHEXDLAB
 CONF
The value of @code shall be drawn from value set 1.3.6.1.4.1.19376.1.3.11.6 (DYNAMIC)
or
The value of @code shall be drawn from value set 1.3.6.1.4.1.19376.1.3.11.1 (DYNAMIC)
hl7:title
ST0 … 1en-US

The Laboratory Specialty Section <title> MAY be present. It is the local translation of the code@displayName.

IHEXDLAB
hl7:effectiveTime
TS1 … 1Ren-US

ClinicalDocument/effectiveTime SHALL be present. It contains the creation date & time of the laboratory report as an electronic document. In case this is a new revision replacing a previous version (identified in parentDocument), this is the date & time of the new revision.

IHEXDLAB
 Example<effectiveTime value="20080624131933.0000-0500"/>
hl7:confidentialityCode
CE1 … 1Ren-US

ClinicalDocument/confidentialityCode SHALL be present in accordance with the HL7 CDA R2 standard.

IHEXDLAB
hl7:languageCode
CS1 … 1Ren-US

ClinicalDocument/languageCode SHALL be present in accordance with the HL7 CDA R2 standard.

IHEXDLAB
 Example
Example of a report authored in American English
<languageCode code="en-US"/>
 Example
Example of a report authored in French
<languageCode code="fr-FR"/>
hl7:setId
II1 … 1Men-US

ClinicalDocument/setId SHALL be present to enable further updates of the clinical document. It is an identifier that is common across all revisions of this laboratory report.

IHEXDLAB
 Example<setId root="1.3.6.1.4.1.19376.1.3.4" extension="abc2"/>
hl7:versionNumber
INT0 … 1en-US

ClinicalDocument/versionNumber MAY be present. As requested by the CDA standard, it is an integer value used as versioning.

IHEXDLAB
Choice1 … *
en-US

ClinicalDocument/recordTarget SHALL be present and SHALL conform to the Human Patient, Non-Human Subject or Human Patient with Non-Human Subject templates defined below. There are three varieties of laboratory reports:

  • Human (patient): The document reports laboratory observations produced on specimens collected exclusively from the patient.
  • Non-Human Subject: The document reports laboratory observations produced on specimens collected from a non-human material (e.g., water, milk, etc.) or living subject (e.g., animal).
  • Human (patient) paired with Non-Human Subject: The document reports laboratory observations produced on a non-human specimen with a relationship to a human patient (e.g., peanut butter eaten by a patient, a ferret that bit a patient).

These three varieties are represented by three templates applied to recordTarget element:

Elements to choose from:
Included0 … * from 1.3.6.1.4.1.19376.1.3.3.1.1 Human Patient (DYNAMIC)
en-US

Human (patient): The document reports laboratory observations produced on specimens collected exclusively from the patient.

All persons (including the patient) and organizations mentioned in the document SHALL provide elements name, addr and telecom.

hl7:recordTarget
0 … *RHumadotsrget
hl7:patientRole
1 … 1RHumadotsrget
hl7:id
II1 … *RHumadotsrget
hl7:addr
AD1 … *en-US All persons (including the patient) and organizations mentioned in the document SHALL provide elements name, addr and telecom.Humadotsrget
hl7:telecom
TEL1 … *en-US All persons (including the patient) and organizations mentioned in the document SHALL provide elements name, addr and telecom.Humadotsrget
hl7:patient
1 … 1Humadotsrget
hl7:id
II0 … 1Humadotsrget
hl7:name
PN1 … *Humadotsrget
hl7:administrativeGenderCode
CE1 … 1RHumadotsrget
hl7:birthTime
TS1 … 1RHumadotsrget
Included0 … * from 1.3.6.1.4.1.19376.1.3.3.1.2 Non-Human Subject (DYNAMIC)
en-US

Non-Human Subject: The document reports laboratory observations produced on specimens collected from a non-human material (e.g., water, milk, etc.) or living subject (e.g., animal).

hl7:recordTarget
0 … *RNonhdotsrget
@typeCode
cs0 … 1FRCT
@contextControlCode
cs0 … 1FOP
hl7:templateId
II1 … 1MNonhdotsrget
@root
uid1 … 1F1.3.6.1.4.1.19376.1.3.3.1.2
hl7:patientRole
1 … 1RNonhdotsrget
@classCode
cs0 … 1FPAT
hl7:id
II1 … *RNonhdotsrget
hl7:patient
1 … 1Nonhdotsrget
@classCode
cs0 … 1FPSN
@determinerCode
cs0 … 1FINSTANCE
@nullFlavor
cs1 … 1FOTH
Included0 … * from 1.3.6.1.4.1.19376.1.3.3.1.3 Human Patient with Non-Human Subject (DYNAMIC)
en-US

Human (patient) paired with Non-Human Subject: The document reports laboratory observations produced on a non-human specimen with a relationship to a human patient (e.g., peanut butter eaten by a patient, a ferret that bit a patient).

hl7:recordTarget
0 … *RHumadotsrget
hl7:templateId
II1 … 1MHumadotsrget
@root
uid1 … 1F1.3.6.1.4.1.19376.1.3.3.1.3
hl7:patientRole
1 … 1RHumadotsrget
hl7:id
II1 … *RHumadotsrget
hl7:addr
AD1 … *Humadotsrget
hl7:telecom
TEL1 … *Humadotsrget
hl7:patient
1 … 1Humadotsrget
hl7:id
II0 … 1Humadotsrget
hl7:name
PN1 … *Humadotsrget
hl7:administrativeGenderCode
CE1 … 1RHumadotsrget
hl7:birthTime
TS1 … 1RHumadotsrget
Included1 … *R from 1.3.6.1.4.1.19376.1.3.10.2.2 XD-LAB Author (DYNAMIC)
en-US

At least one ClinicalDocument/author SHALL be present with a time in accordance with the HL7 CDA R2 standard and further constrained by this specification to require the presence of name, addr and telecom. The author/time element carries the date&time the laboratory report was produced. The laboratory report can be authored by a software system or by a person or by both.

hl7:author
1 … *RIHEHdotsthor
hl7:time
TS1 … 1Ren-US

The author/time element carries the date&time the laboratory report was produced.

IHEHdotsthor
hl7:assignedAuthor
1 … 1RIHEHdotsthor
hl7:addr
AD1 … *Ren-US

All persons (including the patient) and organizations mentioned in the document SHALL provide elements name, addr and telecom.

IHEHdotsthor
hl7:telecom
TEL1 … *Ren-US

All persons (including the patient) and organizations mentioned in the document SHALL provide elements name, addr and telecom.

IHEHdotsthor
Choice0 … 1Elements to choose from:
hl7:assignedPerson
en-US

All persons (including the patient) and organizations mentioned in the document SHALL provide elements name, addr and telecom.


Contains 1.3.6.1.4.1.19376.1.3.10.9.18 PlayingEntity or person with Name (DYNAMIC)
IHEHdotsthor
hl7:assignedAuthoringDevice
en-US

ClinicalDocument/author SHALL be present in accordance with the HL7 CDA R2 standard


Contains 1.3.6.1.4.1.19376.1.3.10.9.19 Laboratory Device (DYNAMIC)
IHEHdotsthor
hl7:representedOrganization
0 … 1en-US

All persons (including the patient) and organizations mentioned in the document SHALL provide elements name, addr and telecom.


Contains 1.3.6.1.4.1.19376.1.3.10.9.13 Organization with Name, Addr, Telecom (DYNAMIC)
IHEHdotsthor
Included1 … 1R from 1.3.6.1.4.1.19376.1.3.10.2.3 XD-LAB Custodian (DYNAMIC)
en-US

ClinicalDocument/custodian SHALL be present with an id in accordance with the HL7 CDA R2 standard and further constrained by this specification to require the presence of name, addr and telecom. It represents the organization that is in charge of maintaining the laboratory report.

hl7:custodian
1 … 1RIHEHdotsdian
hl7:assignedCustodian
1 … 1RIHEHdotsdian
hl7:representedCustodianOrganization
1 … 1RIHEHdotsdian
hl7:id
II1 … *Men-US

ClinicalDocument/custodian SHALL be present with an id in accordance with the HL7 CDA R2 standard.

IHEHdotsdian
hl7:name
ON1 … 1Ren-US

All persons (including the patient) and organizations mentioned in the document SHALL provide elements name, addr and telecom.

IHEHdotsdian
hl7:telecom
TEL1 … 1Ren-US

All persons (including the patient) and organizations mentioned in the document SHALL provide elements name, addr and telecom.

IHEHdotsdian
hl7:addr
AD1 … 1Ren-US

All persons (including the patient) and organizations mentioned in the document SHALL provide elements name, addr and telecom.

IHEHdotsdian
Included0 … * from 1.3.6.1.4.1.19376.1.3.3.1.4 XD-LAB Information Recipient (DYNAMIC)
en-US

ClinicalDocument/informationRecipient MAY be present. When present, it SHALL be in accordance with the HL7 CDA R2 standard and further constrained by this specification to require the presence of name (on the informationRecipient and/or receivedOrganization), addr and telecom. Additionally, it SHALL have the following:

  • <templateId root="1.3.6.1.4.1.19376.1.3.3.1.4"/> - The templateId element identifies this participant as an intended recipient. The templateId SHALL have root="1.3.6.1.4.1.19376.1.3.3.1.4".

The informationRecipient/intendedRecipient element can be multiple. It introduces an intended recipient of the laboratory report, other than the Ordering Provider (described as a referrer participant). These elements carry the list of the originally intended recipients of the laboratory report, i.e., those who were known at the time the report was created and published for sharing.

hl7:informationRecipient
0 … *Infodotsient
hl7:templateId
II1 … 1MInfodotsient
@root
uid1 … 1F1.3.6.1.4.1.19376.1.3.3.1.4
hl7:intendedRecipient
1 … 1RInfodotsient
hl7:id
II0 … *RInfodotsient
hl7:addr
AD1 … *Infodotsient
hl7:telecom
TEL1 … *Infodotsient
hl7:informationRecipient
0 … 1Contains 1.3.6.1.4.1.19376.1.3.10.9.18 PlayingEntity or person with Name (DYNAMIC)Infodotsient
hl7:receivedOrganization
0 … 1Contains 1.3.6.1.4.1.19376.1.3.10.9.13 Organization with Name, Addr, Telecom (DYNAMIC)Infodotsient
Included0 … 1 from 1.3.6.1.4.1.19376.1.3.10.2.4 XD-LAB LegalAuthenticator (DYNAMIC)
en-US

The ClinicalDocument/legalAuthenticator MAY be present. When present, it SHALL be in accordance with the HL7 CDA R2 standard and further constrained by this specification to require the presence of name, addr and telecom. This element carries the person who has legally authenticated the report, and the organization represented by this person. The sub-element time carries the date&time this legal authentication took place. The sub-element signatureCode carries the “signed” (S) status

If this entity happens also to be one of the validators of the laboratory results in the report, it SHALL also be documented as a validator.

hl7:legalAuthenticator
0 … 1IHEHdotsator
hl7:time
TS1 … 1Ren-US

The sub-element time carries the date&time this legal authentication took place.

IHEHdotsator
hl7:signatureCode
CS1 … 1Ren-US

The sub-element signatureCode carries the “signed” (S) status

IHEHdotsator
@code
CONF0 … 1FS
hl7:assignedEntity
1 … 1Ren-US

All persons (including the patient) and organizations mentioned in the document SHALL provide elements name, addr and telecom.

IHEHdotsator
hl7:addr
AD1 … *Ren-US

Constrained by this specification to require the presence of name, addr and telecom.

IHEHdotsator
hl7:telecom
TEL1 … *Ren-US

Constrained by this specification to require the presence of name, addr and telecom.

IHEHdotsator
hl7:assignedPerson
0 … 1en-US

All persons (including the patient) and organizations mentioned in the document SHALL provide elements name, addr and telecom.


Contains 1.3.6.1.4.1.19376.1.3.10.9.18 PlayingEntity or person with Name (DYNAMIC)
IHEHdotsator
hl7:representedOrganization
0 … 1en-US

All persons (including the patient) and organizations mentioned in the document SHALL provide elements name, addr and telecom.


Contains 1.3.6.1.4.1.19376.1.3.10.9.13 Organization with Name, Addr, Telecom (DYNAMIC)
IHEHdotsator
hl7:authenticator
0 … *en-US

The ClinicalDocument/authenticator element MAY be present. When present it represents the clinical expert who performed the clinical validation (see the entries “validator” and “clinical expert” in the glossary in LAB TF-1:1.11) of the report or of a subset of its results, also called the validator.

This element SHALL be in accordance with the HL7 CDA R2 standard and further constrained by this specification to require the presence of name, addr and telecom.

There MAY be more than one validator of the report. All the validators SHALL appear in the report header as authenticator elements AND, in the case of multiple validators, each individual validator SHALL be associated with the particular sections of the report he or she validated. In this case, the validator of a section SHALL also appear in the entry this section is derived from.

This module is consistent with the CDA standard regarding participant and requires in addition the name, addr and telecom for all participants.


Contains 1.3.6.1.4.1.19376.1.3.3.1.5 Laboratory Results Validator (DYNAMIC)
IHEXDLAB
Included0 … * from 1.3.6.1.4.1.19376.1.3.3.1.6 Ordering Provider (DYNAMIC)
en-US

ClinicalDocument/participant(s) MAY be present. When present, this element SHALL be in accordance with the HL7 CDA R2 standard with a time element and further constrained by this specification to require the presence of name, addr and telecom. In particular, when the ordering provider of the order (or group of orders) fulfilled by this laboratory report is present in the CDA, it SHALL be documented as a participant with the attribute typeCode valued “REF” (referrer). Additionally, the ordering provider SHALL have the following:

  • <templateId root="1.3.6.1.4.1.19376.1.3.3.1.6"/> - The templateId element identifies this participant as an ordering physician. The templateId SHALL have root="1.3.6.1.4.1.19376.1.3.3.1.6".
hl7:participant
0 … *en-US Referral Ordering PhysicianOrdedotsider
@typeCode
cs1 … 1FREF
hl7:templateId
II1 … 1Ordedotsider
@root
uid1 … 1F1.3.6.1.4.1.19376.1.3.3.1.6
hl7:time
IVL_TS1 … 1Ren-US This element represents the date and time the order was placed. Time MAY be present.Ordedotsider
hl7:associatedEntity
1 … 1Ordedotsider
hl7:addr
AD1 … *Ren-US The address of this person (referral ordering physician) SHALL be present.Ordedotsider
hl7:telecom
TEL1 … *Ren-US The telecom of this person (referral ordering physician) SHALL be present.Ordedotsider
 Schematron assertrolered error 
 testnot(hl7:assignedPerson) or hl7:assignedPerson/hl7:name 
 MessageThe <name> sub-element SHALL be present when <assignedPerson> present. 
hl7:associatedPerson
0 … 1ROrdedotsider
hl7:scopingOrganization
0 … 1Ordedotsider
Included0 … * from 1.3.6.1.4.1.19376.1.3.10.9.14 XD-LAB InFulfillmentOf Order (DYNAMIC)
en-US

The inFulfillmentOf/order element MAY be present. It represents the Placer Order or the Placer Group that was fulfilled, the id of which is carried by inFulfillmentOf/order/id.

hl7:inFulfillmentOf
0 … *IHEIdotserId
hl7:order
1 … 1RIHEIdotserId
hl7:id
II1 … *Ren-US

It represents the Placer Order or the Placer Group that was fulfilled, the id of which is carried by inFulfillmentOf/order/id.

IHEIdotserId
Included0 … * from 1.3.6.1.4.1.19376.1.3.10.9.15 XD-LAB DocumentationOf (DYNAMIC)
en-US

ClinicalDocument/documentationOf(s) MAY be present.

hl7:documentationOf
0 … *IHEDdotsrmer
hl7:serviceEvent
1 … 1RIHEDdotsrmer
hl7:effectiveTime
IVL_TS0 … 1en-US

Use of sub element documentationOf/serviceEvent/effectiveTime to document the time boundaries of events in the document is appropriate.

IHEDdotsrmer
lab:statusCode
CS0 … 1en-US

This Laboratory Report Content Module can express both final and non-final reports. To distinguish between the two, the statusCode element has been added to the documentationOf/serviceEvent element. A non-final report is a report documenting a serviceEvent, which is in the status "active". This sub-element serviceEvent/statusCode is optional. When it is not present the serviceEvent is assumed to be in the status "completed".

IHEDdotsrmer
 CONF
The value of @code shall be drawn from value set 1.3.6.1.4.1.19376.1.3.11.4 (DYNAMIC)
hl7:performer
0 … *en-US

Laboratory Performer template in the CDA header


Contains 1.3.6.1.4.1.19376.1.3.3.1.7 Laboratory Performer (DYNAMIC)
IHEDdotsrmer
Included0 … * from 1.3.6.1.4.1.19376.1.3.10.9.16 XD-LAB RelatedDocument (DYNAMIC)
en-US

This element SHALL be present in case of an update replacement of a previous report. In this case relatedDocument@typeCode attribute SHALL be valued "RPLC", the new report replacing the parent one.

hl7:relatedDocument
0 … *IHERdotsment
@typeCode
cs1 … 1FRPLC
 en-US

relatedDocument@typeCode attribute SHALL be valued "RPLC".

hl7:parentDocument
1 … 1RIHERdotsment
hl7:id
II1 … 1Ren-US

SHALL be equal to ClinicalDocument/ id of the replaced document.

IHERdotsment
hl7:setId
II1 … 1Ren-US

SHALL have the same value in the new report as in the replaced report.

IHERdotsment
hl7:versionNumber
INT1 … 1en-US

SHALL have the same value as in the replaced report (when provided there)

IHERdotsment
Included0 … 1 from 1.3.6.1.4.1.19376.1.3.10.9.20 XD-LAB ComponentOf (DYNAMIC)
en-US

The ClinicalDocument/componentOf/encompassingEncounter element MAY be present. It describes the encounter during which the reported lab observations were ordered. When present the encounter SHALL:

  • be identified with an id element: encompassingEncounter/id
  • The encounter SHALL have an effective time that represents the time interval (possibly still running, e.g., an inpatient current stay) of the encounter or a point in time at which the encounter took place (e.g., an outpatient consultation): encompassingEncounter/ effectiveTime

The encounter MAY provide any number of encounter participants (encompassingEncounter/encounterParticipant/assignedEntity). When present, encounter participants SHALL be in accordance with the HL7 CDA R2 standard with a time and further constrained by this specification to require the presence of name, addr and telecom. Additionally, the encounter participant SHALL have a typeCode with one the values selected from the x_EncounterParticipant domain: The encounter MAY precise the patient location during this encounter. This is the healthcare facility in which the patient was located when the reported lab test observations were ordered: encompassingEncounter/location/healthCareFacility. This healthcare facility can be represented as a physical place (e.g., room, floor, building, office) or as an organization (e.g., service, department, team) or both: healthCareFacility/location, healthCareFacility/serviceProviderOrganization.

hl7:componentOf
0 … 1XDLAdotsntOf
hl7:encompassingEncounter
1 … 1RXDLAdotsntOf
hl7:id
II1 … *MXDLAdotsntOf
hl7:effectiveTime
IVL_TS1 … 1MXDLAdotsntOf
hl7:encounterParticipant
0 … *XDLAdotsntOf
@typeCode
cs1 … 1R
hl7:time
IVL_TS1 … 1RXDLAdotsntOf
hl7:assignedEntity
1 … 1RXDLAdotsntOf
hl7:addr
AD1 … *RXDLAdotsntOf
hl7:telecom
TEL1 … *RXDLAdotsntOf
hl7:assignedPerson
0 … 1RXDLAdotsntOf
hl7:representedOrganization
0 … 1RXDLAdotsntOf
 Schematron assertrolered error 
 testnot(hl7:assignedPerson) or hl7:assignedPerson/hl7:name 
 Messagethe <name> sub-element of <assignedPerson> SHALL be present. 
hl7:component
1 … 1RIHEXDLAB
hl7:structuredBody
1 … 1RIHEXDLAB
hl7:component
1 … *Ren-US

Content Modules for CDA Sections (Level 2)

A laboratory report SHALL have a structuredBody. This body is organized as a tree of up to two levels of sections, delivering the human-readable content of the report: Top level sections represent laboratory specialties. A top level section SHALL contain either one text block carrying all the text results produced for this specialty along with a single Laboratory Data Processing Entry or a set of Laboratory Report Item Sections. In the first case the specialty section happens to also be a leaf section. In the latter case, each (second level) leaf section contained in the (top level) specialty section represents a Report Item: i.e., a battery, a specimen study (especially in microbiology), or an individual test. In addition, any leaf section SHALL contain a single Laboratory Data Processing Entry containing the observations of that section in a machine-readable format.


Contains 1.3.6.1.4.1.19376.1.3.3.2.1 Laboratory Specialty Section (DYNAMIC)
IHEXDLAB
 Schematron assertrolered error 
 test//hl7:templateId[@root='1.3.6.1.4.1.19376.1.3.1.6'] 
 MessageLab report SHALL contain Laboratory Observation