Post on 31-Dec-2015
transcript
Established Profile
Laboratory Scheduled WorkFlowEstablished Profile
Laboratory Scheduled WorkFlow
Charles ParisotCharles ParisotGE HealthcareGE Healthcare
IHE IT Technical Committee Co-chairIHE IT Technical Committee Co-chair
François MacaryFrançois MacaryAGFA Healthcare ITAGFA Healthcare IT
IHE Laboratory Committee Co-chairIHE Laboratory Committee Co-chair
The IHE Laboratory CommitteeThe IHE Laboratory Committee
Contributing countries– France
– Japan
– Germany
– Italy
– The Netherlands
– UK
– US (CLSI - ex NCCLS)
• Development started in 2003
• First profile published in November 2003
• 10 systems validated in 2004
• 12 systems validated in 2005
• Four new profiles currently published for public comment
Cochairs: Francois Macary - Agfa Healthcare IT
Yoshimitsu Takagi - Hitachi
IHE Lab today and to-morrow
• Five profiles:– Laboratory Scheduled Workflow (LSWF)– Laboratory Point Of Care Testing (LPOCT)– Laboratory Device Automation (LDA)– Laboratory Code Set Distribution (LCSD)– Laboratory Information Reconciliation (LIR)
• Future plans– Incorporate analyzer images in the result workflow– Cross-enterprise sharing of lab reports, using CDA-R2– Specimen labels workflow
• Ordering, placing, scheduling and performing clinical laboratory tests both for Hospital and Ambulatory.
• Microbiology included. Anatomic pathology and blood bank excluded
Volume 1
Scope of LSWF profile
• Integrate the clinical laboratory in the healthcare
enterprise
• Workflow: Ordering, placing, scheduling, performing
clinical laboratory tests, and delivering the results.
• In vitro testing: All specialties working on specimen, not
on the patient itself.
• Bound to clinical biology (anatomic pathology excluded)
LSWF: Three major use cases
• Externally placed order with identified specimens– The ordering provider collects the specimens and uniquely identifies them
(in the message placing the order as well as on the container with a barcode label)
• Externally placed order with specimens unidentified or to be collected by the laboratory– The specimens are unidentified within the message placing the order
• Filler order with specimens identified by the laboratory– The order is created in the laboratory, and afterwards a number is
assigned to it in the placer application.
Patient Administration
Clinical laboratoryWard or EHR
Lab-1: Placer order
Lab-2: Filler order
Rad1, Rad-12
Patient demographics & visit
Lab-5: Results
Rad-1, Rad-12
Lab-3: Results
Lab-4: Work order
Order Result Tracker
ADT
Automation Manager
Order Placer Order Filler
IHE Laboratory: LSWF
Clinicalvalidation
Technicalvalidation
Actors Transactions Optionality
ADT Patient demographics [RAD-1, RAD-12] R
Order Placer Patient demographics [RAD-1, RAD-12] R
Placer Order management [LAB-1] R
Filler Order Management [LAB-2] R
Order Filler Patient demographics [RAD-1, RAD-12] R
Placer Order management [LAB-1] R
Filler Order Management [LAB-2] R
Order result management [LAB-3] R
Work Order management [LAB-4] R*
Test results management [LAB-5] R*
Automation Manager
Work order management [LAB-4] R
Test result management [LAB-5] R
Order Result Tracker
Patient demographics [RAD-1, RAD-12] R
Order result management [LAB-3] R
* In case the LIS encompasses both Order Filler and Automation Manager transactions LAB-4 and LAB-5 are irrelevant.
Order management in LSWF profile
• Two parallel flows to keep synchronized– Electronic: The order
– Material: The specimen(s) required to perform the order
• A dynamic process– Specimen added by the placer to a running time study
– Specimen rejected by the filler (damaged or spoiled), tests held in wait for a new specimen
– Unordered test added by the filler (e.g. antibiogram in microbiology)
Order Placer and Order Filler must keep the same vision of the order (content and status) all along the process
Results management in LSWF profile
• Results can be transmitted at various steps– After technical validation (by the lab technician)
– After clinical validation (by the clinical expert)
• Requirement to keep Order Result Tracker informed with all changes occurred to results previously sent – Send corrections
– Send validation or un-validation
– Send cancellation
• Other characteristics– Result type: Numeric, coded, textual, graphical (electrophoresis)
– Results are sent in recapitulative mode, appropriately sorted
Laboratory Technical Framework Volume 2
Choice of the standard
• Need for an international standard, fully implementable with guides and tools ready for use– Excluded HL7 v3
• Supporting specimen and container management– Excluded v2.3.1 and v2.4
• Choice of HL7 v2.5, released just before IHE Lab TF (end 2003)
HL7 v2.5 Transactions LAB-1, LAB-2, LAB-3, LAB-4, LAB-5
HL7 v2.3.1 Transactions RAD-1, RAD-12
Vertical bar encoding shall be supported. XML encoding may be supported
See Vol 2 section 1.1
HL7 v2.5 profiling conventions
• Static definition: Usage of segments and fields– R: Required– RE: Required but may be empty– O: Optional = Usage not defined yet– C: Conditional (condition predicate in the textual description)– X: Not supported. Must not be sent.
• For a better readability:– Segments with usage X do not appear in message tables– Fields with usage O do not appear in segment tables
• Cardinalities of segments, segment groups and fields:– Min and max between square brackets: [0..*]– * stands for “no upper limit”
See Vol 2 section 2.2
Example of message static definition
Specimen Segment group
Example of segment description
Vocabulary & tracking orders
– a CBC (complete blood count)
– an electrolyte (Na, K, Cl)
– a creatinine clearance
Order Placer allocates an Identifier to each ordered battery
Order Filler allocates an Identifier to each accepted battery
The physician places a lab request. The Order Placer allocates the unique Id “123” to this request consisting of:
Laboratory request 123
Placer Order Number(ordered battery)
12345
12346
12347
ordered battery 12347
Filler Order Number
(accepted battery)
F101
F102
F103
accepted battery F103
Watch the 4 examples of section 9
• Each example is using the same layout:
– Storyboard
– List of human actors and organizations
– Ids and numbers
– List of interactions
– Interaction diagram
– Messages with key information highlighted.
For implementers: One of the most helpful parts of Laboratory Technical Framework.
1st example: Two hematology batteries
1st example: Two hematology batteries
Two hematology batteries: One message
Acknowledgements with MLLP (1)
• An OML message shall be acknowledged by one single ORL message.
• An OUL message shall be acknowledged by one single ACK message.
• These acknowledgements are application-level acknowledgements (i.e. not transport acknowledgements) and must be generated by the receiving application after it has processed the message semantic content, according to its own business rules.
• Intermediate message brokers do not have this capacity and therefore shall not be used to generate the contents of application acknowledgements.
• The receiving application shall automatically generate the application-level acknowledgement messages without waiting for human approval of the contents of the message that was received
See Vol 2 section 2.3
Thank you for your attention…