Sharing Laboratory Reports
XD-LAB
Francois Macary, Agfa HealthCare
co-chair Lab Technical Committee
September, 2005
1
What IHE Delivers
Lab TF Integration Profiles
HL7
CDA
Subset of LOINC test codes
Sharing Laboratory Reports (XD-LAB)
Content
V3:
Workflow
Laboratory Scheduled Workflow (LSWF)
Laboratory Information Reconciliation (LIR)
Laboratory Device Automation (LDA)
V2.5
Laboratory Point Of Care Testing (LPOCT)
Laboratory Code Sets Distribution (LCSD)
Laboratory Barcode Labeling (LBL) -> 2007
2
Lab TF Integration Profiles
HL7
Subset of LOINC test codes
CDA
Content
V3:
Workflow
V2.5
Laboratory Scheduled Workflow (LSWF)
Laboratory Information Reconciliation (LIR)
Laboratory Device Automation (LDA)
Laboratory Point Of Care Testing (LPOCT)
Laboratory Code Sets Distribution (LCSD)
Laboratory Barcode Labeling (LBL) -> 2007
Sharing Laboratory
Reports (XD-LAB)
Sharing
Laboratory
Reports
3
Scope
Sharing laboratory reports
 Retrieval of historical lab results by the providers of care, in a patient-centric
manner
Main characteristics of a lab report:
 Presents a set of releasable laboratory results to be shared as “historical





information”.
Usually a final report, shared once the lab order is completed.
Occasionally a partial report may also be shared
Human-readable, viewed by care providers (physicians, nurses,
pharmacists… and even the patient (e.g. through a PHR)
Machine-processable (for decision support, bio-surveillance)
The results must be represented in both formats
4
Use case 1: Hospital lab report [CIS EHRs]
At discharge time, a hospital physician selects the most significant laboratory
reports produced during the patient stay, and issues these reports to an Affinity
Domain shared by a number of healthcare enterprises and primary care providers.
XD*
Hospital
Lab Report
Discharge Source
time
CIS
Lab
Report
Consumer
Lab Reports
Any care setting
or care provider
5
Use case 2: Private lab report [LIS  PHR/EHR]
A private laboratory having signed a final report for a patient, sends this report in
an electronic format to the patient record in the regional or national PHR.
XD*
Report
Signed
Lab Report
Source
LIS
Private laboratory
Lab Report
document
Lab
Report
Consumer
Any care setting
or care provider
6
Use case 3: Lab report published by a GP
A physician reviews the results received from a reference laboratory for his
patient. The doctor, as requested by the patient, shares this laboratory report in
the patient’s personal health record in an electronic format.
XD*
Results
reviewed
Lab Report
Source
Lab Report
document
Ambulatory physician’s office
Lab
Report
Consumer
Any care setting
or care provider
7
Use case 4: Lab report automatically shared
A laboratory, systematically (with some degree of automatism) shares its final
reports with a regional healthcare network.
XD*
Results
completed
Lab Report
Source
LIS
Laboratory
Lab Report
Document
Lab
Report
Consumer
Any care setting
or care provider
8
Use case 5: Hospital’s cumulative report [CIS  PHR]
At discharge time of an inpatient, a hospital physician selects the most significant
lab results, produced by one or more laboratories of the healthcare enterprise
during patient stay, and issues a cumulative report to the national PHR.
XD*
Hospital
Lab Report
Discharge Source
time
CIS
Cumulative
Lab Report
Lab
Report
Consumer
Any care setting
or care provider
9
Dependencies of XD-LAB towards other profiles
Share a CDA
lab report
Content
Creator
XDS
ATNA
CT
or
XDR
Content
Consumer
or XDM
XD-LAB
Document
sharing
infrastructure
Security
infrastructure
10
XD-LAB options
Actor
Options
Domain, Volume,
Section
Content
Consumer
View Option (1)
Document Import Option (1)
Section Import Option (1)
Discrete Data Import Option (1)
PCC TF-2: 3.1.1
PCC TF-2: 3.1.2
PCC TF-2: 3.1.3
PCC TF-2: 3.1.4
Content
Creator
No option
(1) The Content Consumer must support at least one of these options
11
A CDA Release 2 document
<ClinicalDocument>
<structuredBody>
<section>
<section>
<text>
<entry>
The header delivers the context:
patient, encounter, author,
cutodian, documented act…
The body can be structured as a
tree of nested sections
A section may contain a narrative
block for the human reader…
…and a number of entries
containing machine-readable
coded data.
12
XD-LAB constrains CDA R2
Constrains the use of elements of the CDA header
Delivers guidelines for the layout of the structured body
 How to build the tree of sections
 How to organize the narrative block <text> ….. </text>
Mandates the structured & coded data <entry> ….. </entry>
and defines a unique template for it.
 Aligned with HL7 V3 Laboratory result messages
 Compatible with HL7 v2.5 laboratory result messages
13
Key elements in the header
Elements driven by the affinity domain:
clinicalDocument/realmCode
 <realmCode code=“UV”> universal (no national extension)
 <realmCode code=“US”> US extension
clinicalDocument/code
 The kind of document: Either a multi-disciplinary lab report or a single
specialty lab report.
clinicalDocument/languageCode
 The main language used in the document (can be superseded by some
section)
 <languageCode code="en-US" codeSystem=" 2.16.840.1.113883.6.121"/>
14
Key elements in the header
Replacing a lab report by a new version:
<effectiveTime> = The time the current version was produced
<setId> = a common identifier to all versions of this document
<id> = unique id of the current instance
<versionNumber> = integer representing the current version
<relatedDocument typeCode=“RPLC”> (only replacement)
 <parentDocument>
•
<id> = the unique id of the replaced document
15
Key elements in the header
Authoring and stewardship:
The <author> may be a system (e.g. the LIS)
The <custodian> is the organization in charge with stewardship of the
report (replace, deprecate). It is the organization operating the Content
Creator actor (depending on the use case the laboratory, the hospital,
the GP )
16
Key elements in the header
Who and what this report is answering to:
inFulfillmentOf/order = the request received by the laboratory
<participant typeCode=“REF”> = the ordering physician
informationRecipient/intendedRecipient = the list of the other intended
recipents
17
Key elements in the header
The main act: a lab order
documentationOf/serviceEvent = the main act documented by the
report (e.g. the laboratory order)
 <performer> = the laboratory who performed the main part or the totality of
the tests reported in this document.
<legalAuthenticator> = the person who has verified and legally
authenticated the report, and the organization represented by this
person
<authenticator> = the other verifiers of the report (e.g. a biologist who
performed the clinical validation of the results)
18
Key elements in the header
The patient:
<recordTarget> = the patient
componentOf/encompassingEncounter = the encounter during which
the tests documented in this report were produced
19
Same content binding as PCC
Mapping between the metadata of XD* and
the header of the CDA document (here the
lab report), is defined in PCC TF, volume 2,
section 4.1.1
20
The body is structured in two levels of sections
Header
‘Specialty’ section
‘Reported Item’ section
entry
Each section carrying results
is derived from a mandatory
<entry> embedded at the
end of the section.
This entry carries the coded
& structured representation
of these results, to be
imported by the consumer.
18767-4: Blood gas
Arterial blood gas
pO2 (mm Hg)
85
pCO2 (mm Hg)
35
<entry>
18719-5: Chemistry
Electrolytes
Na (mmol/l)
K (mmol/l)
141
4.4
<entry>
21
At the international level, this profile is flexible
regarding the organization of the body
Possibility to use only one level of section, instead of
two.
The profile provides a list of specialties but does not
impose the relationship between specialties and tests
The narrative block (<text>…</text>) may appear
only in a leaf section (which can be a specialty
section without sub-section).
22
General rules of representation of lab
results in the human-readable body
Date/time of the observation (physiologic time = specimen
collection)
Name of the analyte
Value (numeric, textual, coded, graphic, image)
Unit (if relevant)
Reference range (if known and relevant)
Interpretation code (if known and relevant)
Specimen type (if not implied by the test)
Testing method
Zero or more previous results, to facilitate the interpretation (trend)
Verifier, if it does not appear in the header
Subcontractor lab if this test was not performed by the performer
declared in the header
23
4 templates for the leaf sections
Single specimen battery
Individual test
Challenge study (dynamic function test)
microbiology
These templates are flexible: {paragraph, table, paragraph}
The examples shown, are not exclusive.
24
Example:
Specialty
section
Human
readable
<text>
block
Current results
Previous results
25
Embedded graphics or images
<renderMultimedia>
<entry>
<observationMedia>
…
</observationMedia>
</entry>
26
Microbiology: rendering with table germ/antibiotic
27
Microbiology: more traditional rendering
28
The coded & structured data
Each leaf section SHALL contain one <entry>
element at its end, below the <text> block.
The <text> block of the section SHALL be derived
from the content of the <entry>
The <entry> conforms to a unique template defined
in section 9.2 of the supplement.
29
Usable coding systems in the <entry>
HL7 vocabulary domains (e.g. specimen type,
patient gender …)
SNOMED CT
For test codes:
 LOINC subset
 SNOMED CT
 National terminologies (e.g. in Japan)
30
Questions…
Francois.macary@agfa.com
September, 2005
31
What IHE Delivers