Sharing Laboratory Reports XD-LAB

1. Sharing Laboratory ReportsXD-LAB Francois Macary, Agfa HealthCare co-chair Lab Technical Committee

2. HL7 V2.5 Subset of LOINC test codes V3: CDA Lab TF Integration Profiles 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 Workflow Sharing Laboratory Reports (XD-LAB) Content

3. HL7 V2.5 Subset of LOINC test codes V3: CDA Lab TF Integration Profiles 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 Workflow • Sharing Laboratory Reports (XD-LAB) Sharing Laboratory Reports Content

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

5. Discharge time 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 CIS Lab Report Source Lab Report Consumer Lab Reports Any care setting or care provider

6. ReportSigned 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* LIS Lab Report Source Lab Report Consumer Lab Reportdocument Any care setting or care provider Private laboratory

7. 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* Lab Report Source Lab Report Consumer Results reviewed Lab Reportdocument Any care setting or care provider Ambulatory physician’s office

8. 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* LIS Lab Report Source Lab Report Consumer Resultscompleted Lab ReportDocument Any care setting or care provider Laboratory

9. Discharge time 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 CIS Lab Report Source Lab Report Consumer Cumulative Lab Report Any care setting or care provider

10. Dependencies of XD-LAB towards other profiles XD-LAB Share a CDA lab report Content Creator Content Consumer Document sharing infrastructure XDS XDR XDM or or Security infrastructure ATNA CT

11. XD-LAB options (1) The Content Consumer must support at least one of these options

12. A CDA Release 2 document The header delivers the context: patient, encounter, author, cutodian, documented act… <ClinicalDocument> <structuredBody> The body can be structured as a tree of nested sections <section> <section> <text> A section may contain a narrative block for the human reader… …and a number of entries containing machine-readable coded data. <entry>

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

14. 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"/>

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

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

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

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

19. Key elements in the header The patient: • <recordTarget> = the patient • componentOf/encompassingEncounter = the encounter during which the tests documented in this report were produced

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

21. ‘Specialty’ section ‘Reported Item’ section The body is structured in two levels of sections Header 18767-4: Blood gas Arterial blood gas pO2 (mm Hg) 85 pCO2 (mm Hg) 35 entry <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. 18719-5: Chemistry Electrolytes Na (mmol/l) 141 K (mmol/l) 4.4 <entry>

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

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

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

25. Example: Specialty section Human readable <text> block Previous results Current results

26. Embedded graphics or images <renderMultimedia> <entry> <observationMedia> … </observationMedia> </entry>

27. Microbiology: rendering with table germ/antibiotic

28. Microbiology: more traditional rendering

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

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

31. Questions… Francois.macary@agfa.com