IHE Laboratory

1. IHE Laboratory Cochairs: Francois Macary - Agfa HealthCare Nobuyuki Chiba - A&T Corporation

2. Agenda • Background (who? what? How?) • Lab TF 2.0: Profiles available for this 2008 connectathon • Ongoing work for next year and later

3. Background: Who? What? How?

4. Forces of IHE LAB • Contributing countries • France, Japan, Italy, NL, Germany, UK, US, Belgium • Sponsors • France: GMSIH, SFIL • Japan: JAHIS, IHE-J • US: RSNA • Technical & planning committee • Cooperative work by email, and wiki • 2 ftf meetings / year (June, December)

5. General scope of LAB TF  2008 Ordering and performing clinical laboratory tests within acute care settings • Tests on in vitro specimens • Collected from human patients • Tests performed in lab as well as on the point of care • Microbiology included • Anatomic pathology excluded (another domain in IHE) Sharing laboratory reports within a wide community of care providers • Report for one patient • Published in a document sharing infrastructure • Electronic document (human readable & importable in DB)

6. LAB TF 2.0: Profiles for 2008 CAT

7. Organization of LAB TF rel 2.0 • Volume 1: use cases, profiles, actors, dependencies • Volume 2: Description of message-based transactions • Volume 3: Document-based transaction (lab report) • Volume 4: Common subset of LOINC test codes

8. Lab TF Rel 2.O HL7 V2.5 Laboratory Testing Workflow - LTW Laboratory Device Automation - LDA Laboratory Point Of Care Testing - LPOCT Laboratory Code Sets Distribution - LCSD Laboratory Barcode Labeling - LBL Workflow Intra hospital Subset of LOINC test codes V3: CDA R2 Sharing Laboratory Reports - XD-LAB Content Community

9. ATNA CT PAM PDQ Workflow profiles dependencies Security Patient admin. Care unit Laboratory Order mgmt Automation LTW LCSD LPOCT LBL LDA

10. ATNA Sharing Laboratory Reports XD-LAB CT XDS XDR XDM Content profile dependencies Security Document Sharing infrastructure Laboratory Or Ambulatory EHR Or Hospital EMR

11. Work Order Steps Query & download modes Tests results Pre/post processor Analyzer LDA Laboratory Testing Workflow (LTW) & Laboratory Device Automation (LDA) Placer order Order Filler Order Placer Filler order Work order Results Results Automation Manager Order Result Tracker LTW

12. Units of work in LTW & LDA LTW LDA Order Placer Order Filler Automation Manager Lab Device Laboratory Request = Order Group (ORC-4) Placer Order (OBR-2) Filler Order (OBR-3) Work Order (OBR-2) Work Order Step (OBR-2)

13. Laboratory Point Of Care Testing Scope: • In vitro tests performed on point of care or patient bedside • specimen collected, tested at once and eliminated • No pre or post-processing • Results used immediately by the care provider • Supervision by a clinical laboratory of the hospital • Training the ward staff • Provides reagent & supervises QC • Clinical validation a posteriori

14. Benefits of LPOCT • Results obtained at once  increases the efficiency of clinical decisions • Minimizes the blood quantity drawn from the patient, because of the immediate use of the specimen. • Preserving a high level of quality of the POCT process through its supervision by a clinical laboratory.

15. Five major use cases • Observations to match with an existing order, real-time patient identity checking • Unordered observations, real-time patient identity checking • Unordered observations on a POC device with an intermittent link (no patient identity check) • Manual entry of unordered observations • QC results

16. The Actors of LPOCT Point Of Care Result Generator (POCRG) Produces the results from a specimen by testing on a specimen, or calculation or manual entry Point Of Care Data Manager (POCDM) Administers a set of POCRG, controls their process. Collects the patient and QC results. Forwards the patient results to the Order Filler Order Filler Recipient of POCT results. Stores the results within orders. Performs a posteriori clinical validation Point of care results Point of care patient results

17. PAM PDQ LPOCT: Actors and Transactions Ward Clinical laboratory Lab-30 (optional): Initiate testing on a specimen Point Of Care Result Generator Point Of Care Data Manager Lab-31: Performed observation set (patient or QC results) Lab-32: Accepted observation set (patient results) Order Filler

18. One single option: Patient identity checking • Transaction LAB-30 enables the operator to get a real time checking on the patient identity: • When initiating the test on the point of care device, the patient ID is scanned or keyed in. The device, then sends the patient ID, device ID, operator ID to the POCDM, which checks the patient identity and sends back the patient name, displayed on the device.

19. Selected standard: POCT1-A Point of care device Observation Reviewer POCT1-A Component Observation Recipient Point Of Care Result Generator Point Of Care Data Manager IHE Actor Order Filler

20. Correspondence IHE/POCT1-A • IHE is neutral towards the « Device Access Point » (DAP) interface. • IHE is an implementation guide of: • The Device Message Layer (DML) interface, based on a proto-v3 HL7 XML message format • The Observation Reporting Interface (ORI), which is a pure subset of HL7 v2.5 (ORU message structures) • Added value : The « patient identiy checking » option.

21. Sharing Laboratory Reports: XD-LAB

22. Purpose • Sharing laboratory reports • Access to lab results in a patient-centric manner • Retrieval of historical lab results by providers of care • To improve coordination of care • A content profile. A lab report: • Presents a set of releasable laboratory results to be shared as “historical information”. • Is human-readable, shared between care providers of various specialties and the patient (e.g. through a PHR) • Contains machine importable coded data(decision support, bio-surveillance)

23. Value Proposition • Use case 1: Hospital lab report • Use case 2: Private lab report • Use case 3: Lab report shared by physician • Use case 4: Lab report automatically shared • Use case 5: Hospital’s cumulative report

24. Structure of a CDA lab report Header • A laboratory report has its results sorted by “specialty” sections. • Within a specialty section, the results may be organized by “reported item” sections(battery, specimen study, individual test). • The relationship between reported item and specialty is not constrained: Left up to the Document Source Actor. • Each leaf section of the body is derived from a level 3 <entry> 18767-4: Blood gas B O D Y Arterial blood gas pO2 (mm Hg) 85 pCO2 (mm Hg) 35 Mandatory <entry> 18719-5: Chemistry Electrolytes Na (mmol/l) 141 K (mmol/l) 4.4 Mandatory <entry> Glucose (g/L) 0.5 Mandatory <entry>

25. Rendering of a single specimen battery (2) text block of the leaf section <renderMultimedia> <entry> <observationMedia> … </observationMedia> </entry>

26. A possible rendering for microbiology

27. Ongoing work in LAB domain

28. Preparing LAB TF 2.1 Final Text  July 2008 • Refine microbiology messaging • Specimen attributes (collection site, method, location…) • Dynamic tree of micro results (aligned with HL7 implementation guide of Lab to EHR results message) • Add the public health lab report use case to XD-LAB • Extend the scope to non-human specimen related to a human patient • Extend the number of CDA content modules (templates), • Minor corrections and clarifications (CPs)

29. Preparation of supplements • Lab to lab workflow • Linking images to lab results Sub-order Requester Subcontractor Results Next face to face meeting: New York, June 23-25

30. Francois.macary@agfa.com Questions?