Laboratoire danalyse

1
Laboratoire danalyse
2
Laboratory Technical Framework

• Etendue du domaine Laboratoire
• Prescription et réalisation danalyses de
  biologie médicale
• Analyses en laboratoires ou délocalisées sur le
  lieu de soins
• Analyses in vitro, toutes disciplines, y compris
  microbiologie
• Anapath et transfusion sanguine exclues
• Partage de comptes rendus danalyses dans un
  dossier patient communautaire

3
Profils dintégration

• Workflow 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 Specimen Label Workflow (LSL)
• Content Integration Profiles
• Sharing Laboratory Reports (XD-LAB)

HL7 v2.5
POCT1-A
2007
HL7 v3 CDA R2
2006
Pays contributeurs France, Japon, Italie, NL,
Allemagne, UK, US
4
Laboratory Technical Framework

• General scope
• Ordering, placing, scheduling and performing
  clinical laboratory tests within acute care
  settings.
• Bound to in vitro testing
• Microbiology included.
• Pathology and blood banks excluded.
• The first profile LSWF addresses acute care
  settings

5
The major problems to solve

• Reduce over-ordering and over blood-drawing
• By consolidating the lab results in a common
  repository shared by all wards in charge with the
  patient
• By sharing the opened orders
• Bring the accurate lab results to the clinician,
  in time for clinical decision
• Without flooding the ward with paper reports
• Without flooding the lab with phone calls

6
Laboratory Scheduled WorkFlow
3 cas d'utilisation

• Demande externe avec échantillons identifiés
• Les échantillons sont identifiés par un code bar
  sur le tube
• Demande externe, échantillons non identifiés ou à
  collecter dans le laboratoire
• Les échantillons ne sont identifiés dans le
  message de demande
• Demande dans le laboratoire, avec des
  échantillons identifiés par le laboratoire
• Demande créée dans le laboratoire, Order number
  alloué à posteriori

7
IHE Laboratory LSWF
Patient Administration
Rad-1, Rad-12
Rad1, Rad-12 Patient demographics visit
ADT
Clinical validation
Clinical Laboratory
Ward or EHR
Lab-1 Placer order
Order Placer
Order Filler
Lab-2 Filler order
Lab-5 Results
Lab-4 Work order
Technical validation
Lab-3 Results
Order Result Tracker
Automation Manager
8
In case the LIS encompasses both Order Filler
and Automation Manager transactions LAB-4 and
LAB-5 are irrelevant.
9
Order management in LSWF profile

• Deux flux parallèles à synchroniser
• Electronique La demande
• Materiel le ou les échantillons
• Un processus dynamique
• Echantillons ajouté par le demander en cours
  d'étude
• Echantillons rejeté par le filler (endommagé,
  polué...), test en attente d'un nouvel
  échantillon
• Test non demandé ajouté par le filler
  (antibiogramme...)

Order Placer et Order Filler doivent garder la
même vision de la demande (contenu et status)
tout au long de l'analyse
10
Results management in LSWF profile

• Les résultats peuvent être transmis
• Après validation technique (par le technicien de
  laboratoire)
• Après validation clinique (par le biologiste)
• Obligation de maintenir l'Order Result Tracker
  informé de toute modification concernant les
  résultats déjà transmis
• Envoyer les corrections
• Envoyer les validations et les dé-validations
• Envoyer les annulations
• Autres caracteristiques
• Type de Resultats Numerique, codé, textuel,
  graphique (electrophorese)
• Resultats envoyés de manière recapitulative, triés

11
Choice of the standard
See Vol 2 section 1.1

• 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 a while 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
12
HL7 v2.5 profiling conventions
See Vol 2 section 2.2

• 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

13
Example of message static definition
14
Example of segment description
15
Condition predicates for  usage C  fields
See Vol 2 section 3.9
SPM-2 Specimen ID (EIP), conditional.
This field contains a unique identifier for the
specimen, enterprise-wide. Condition predicate
This field shall be populated in OML messages of
transaction LAB-1, in the context of the use case
"Externally placed order with identified
specimens" defined in volume 1. This field is
required in OML messages of LAB-2 transaction. It
may also be used in transaction LAB-3. This field
is required if known (RE) in transactions LAB-4
and LAB-5. Please refer to section 2.3.5.1 for
the details of the data type.
16
Common segments descriptions
See Vol 2 section 3

• MSH Message Header
• MSA Message Acknowledgement
• ERR Error
• NTE Notes and Comments
• PID Patient Identification
• PV1 Patient Visit
• ORC Common Order
• TQ1 Timing Quantity
• Only one TQ1 per order ? One single execution per
  order
• SPM Specimen
• SAC Container Detail
• OBX- Observation/Result

17
HL7 conventions on empty fields
See Vol 2 section 3.9
PID16543210
OBX1NM14996-3LNumol/l
Of course this is forbidden with fields marked
with usage R
18
Vocabulary
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

• a CBC (complete blood count)
• an electrolye (Na, K, Cl)
• a creatinine clearance

19
Watch the 4 examples of section 9
For implementers One of the most helpful parts
of Laboratory Technical Framework.

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

20
1st example Two hematology batteries
21
1st example Two hematology batteries
22
Two hematology batteries One message
23
Acknowledgements with MLLP (1)
See Vol 2 section 2.3

• 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

24
Acknowledgements with MLLP (2)

• A MLLP (Minimal Lower Layer Protocol) network
  connection is unidirectional. Event-triggered
  messages flow in one direction and related
  acknowledgement messages flow in the other
  direction.
• The acknowledgement message to an event-triggered
  message shall be sent immediately to the sender
  on the same MLLP connection that carried the
  event-triggered message.

25
Acknowledgements with MLLP (3)Transactions with
trigger events on both sides (e.g. LAB-1)
Order Placer application
Order Filler application
Accepting module
Initiating module
26
Laboratory Device Automation (LDA)
Demographics
Demographics
ADT
Placer order
Order Filler
Order Placer
Filler order
Results
Work order
Results
Order Result Tracker
Automation Manager
LSWF
27
Scope of LDA

• Workflow between an Automation Manager and its
  set of automated devices.
• Each Work Order is split into a sequence of
  steps, each of which uses a specimen on a device.
  
• Scope limited to devices operated by the lab
  staff.

28
Laboratory Information Reconciliation (LIR)

• Reconcile clinical lab observations produced on
  specimens collected from misidentified or
  unidentified patient. (Same thing as PIR in Radio
  land)
• Reconcile clinical lab observations produced on
  specimens before the orders are created Results
  for unknown orders. (Different from PIR)
• LIR profile depends upon LSWF and LDA profiles
• No added transactions

29
LIR one example of process flow
30
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 provided to the ward staff
• Provision of reagent
• Supervision of quality control
• Clinical validation a posteriori

31
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. E.g. Two drops are enough to test blood
  gas, electrolyte and hematocrit of a new-born
  baby.
• Preserving a high level of quality of the POCT
  process through its supervision by a clinical
  laboratory.

32
Examples of LPOCT

• Portable blood gaz and chemistry analyzer used by
  the nurse in a neonatology ward
• Blood gas analyzer permanently installed in the
  surgery theater
• Glucometer used by the patient in home care
• Workstation on which the nurse manually enters
  the results of pregnancy stick tests.

33
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
34
LPOCT Actors and Transactions
Ward
Clinical laboratory
Lab-30 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
POCDM and Order Filler are assumed to be
provided with up-to-date patient demographic data
(for instance by PAM or PDQ)
35
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 POCRG with an
  intermittent link (no patient identity check)
• Manual entry of unordered observations
• QC results

36
Use case 1 LPOCT LSWF
Order Result Tracker
Order Filler
POCDM
POCRG
Order Placer
LAB-1 New POCT order
Specimen to test for a patient
Order entered
LAB-30 Check patient identity
Test performed,
LAB-31 Produced observations set
LAB-32 Accepted observations set
LAB-1 Order Results received
clinical validation
LAB-1 Order completed
LAB-3 Results validated
37
Selected standard
POCT 1-A, published by CLSI (ex NCCLS)
Based on HL7 early v3 in XML
HL7 v2.5
POCRG
POCDM
Order Filler
38
Laboratory Code Set Distribution

• The goal of this profile is to simplify the
  configuration of the systems involved in the
  Laboratory Scheduled Workflow.
• The Laboratory Code Set Distribution Profile
  offers the means to share the same set of
  test/observation codes between different actors.
• Other information can be also exchanged like
  presentation of results, laboratory codes (in
  which lab a test is performed), units

39
LCSD Actors/Transaction
Grouped with Order Filler, Enterprise Common
Repository
Laboratory Code Set Master
LAB-51 Laboratory Code Set Management
Grouped with Order Placer, Order Result
Tracker, Order Filler,
Laboratory Code Set Consumer
40
LCSD Use Case 1
Laboratory Code Set Consumer
Laboratory Code Set Master
Creates observation, test, battery codes
LAB-51 Laboratory Code Set Management (REP)
Replaces Observation/Test/Battery Code Sets All
Observation, Test and Battery code sets of the
Consumer are replaced by the code sets sent by
the Master. This Use Case is used both for
initialization as well as periodic (weekly,
monthly) update.
41
LCSD - Standard used

• HL7 V2.5 Master Files
• Messages rich enough to transport other
  information than just observation/test/battery
  codes
• presentation of the results
• Units of measure
• Laboratories fulfilling this test

42
LCSD Messages
Code Set Master
Code Set Consumer
MFNM08 Numeric tests
MFKM08 Acknowledgement
MFNM09 Categorical tests
MFKM09 Acknowledgement
MFNM10 Batteries
MFKM10 Acknowledgement
MFNM11 Calculated tests
MFKM11 Acknowledgement
43
XD-LAB Le partage des comptes rendus danalyses
médicales
44
Lune des cibles affichées Le DMP

• Partager dans le DMP les résultats de biologie
  les plus pertinents du parcours de soins
• Faciliter laccès à lhistorique biologique du
  patient par les praticiens, dans le respect du
  secret médical
• Améliorer lefficacité des soins en minimisant
  les analyses redondantes et en éclairant mieux
  les décisions médicales

45
Un compte rendu pour lil du clinicien, capable
dalimenter lhistorique biologique dans son
système informatique

• Un document électronique au format CDA
  (Clinical Document Architecture) tiré du standard
  HL7 V3, basé sur la syntaxe XML

• Formant un tout cohérent, produit par un
  laboratoire pour un patient en réponse à une
  prescription, dans un contexte diagnostic, ou de
  prévention ou de surveillance, signé par un
  biologiste
• Consultable sur un poste muni dun simple
  navigateur web
• Imprimable

• Chaque résultat est intégrable dans le système du
  praticien, pour constituer un historique
  biologique
• Identifiable Nomenclature commune LOINC
• Précis Technique, unités, valeurs de référence,
  interprétation
• laboratoire et biologiste exécutants (SEL ou
  contrat de collaboration)

46
Structure dun compte rendu danalyses CDA
Lentête donne le contexte
Entête ltClinicalDocumentgt

• Catégorie de compte rendu multidisciplinaire ou
  spécialisé
• Patient (identité, identifiant)
• Prescription, prescripteur
• Laboratoire auteur
• Biologiste signataire légal
• Autres biologistes valideurs
• Niveau de complétude (partiel / final)
• Degré de confidentialité
• Langue
• Identifiant du document
• Versioning pour les mises à jour

47
Corps du compte rendu organisé en deux niveaux de
sections
Entête
18767-4 Gaz du sang
Gaz du sang artériel pO2 (mm Hg) 85
pCO2 (mm Hg) 35
ltentrygt (obligatoire)
18719-5 Biochimie sanguine
Ionogramme Na (mmol/l) 141
K (mmol/l) 4.4
ltentrygt (obligatoire)
48
Comparatif XD-LAB / H Médecins
CDA
HPRIM Médecins
49
Rendu dune analyse mono-échantillon
Section spécialité
Bloc lttextgt destiné au lecteur humain
Résultats antérieurs
Résultats courants
50
Spécialité
Bloc lttextgt de la section résultats
51
Analyse avec graphe ou image Electrophorèse
Bloc lttextgt pour le lecteur humain
ltrenderMultimediagt
ltentrygt ltobservationMediagt lt/observationMediagt
lt/entrygt
52
Bactériologie Rendu en tableau germes /
antibiotiques
53
Bactériologie rendu linéaire
54
Sous-ensemble de LOINC
Sélection et traduction réalisées par la SFIL
(Martine Marchand)

• Chemistry .
• Hematology .....
• Toxicology and drug monitoring ..
• Virology and serology ..
• Parasitology and micology .
• Bacteriology
• Immunology and cell mark ..
• Patient and specimen findings ..

• 873 tests
• 284 tests
• 194 tests
• 374 tests
• 158 tests
• 387 tests
• 278 tests
• 30 measures

Restriction de 29 000 codes à 2 600
Autres terminologies utilisables SNOMED CT