1 / 54

Laboratoire d’analyse

Laboratoire d’analyse. Laboratory Technical Framework. Etendue du domaine Laboratoire : Prescription et réalisation d’analyses de biologie médicale Analyses en laboratoires ou délocalisées sur le lieu de soins Analyses in vitro, toutes disciplines, y compris microbiologie

jalena
Télécharger la présentation

Laboratoire d’analyse

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Laboratoire d’analyse

  2. Laboratory Technical Framework • Etendue du domaine Laboratoire : • Prescription et réalisation d’analyses 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 d’analyses dans un dossier patient communautaire

  3. Profils d’inté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 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 3 cas d'utilisation

  7. IHE Laboratory: LSWF Patient Administration Rad-1, Rad-12 Rad1, Rad-12 Patient demographics & visit ADT Clinical validation Ward or EHR Clinical Laboratory Lab-1: Placer order Order Placer Order Filler Lab-2: Filler order Lab-4: Work order Lab-5: Results Technical validation Lab-3: Results Order Result Tracker Automation Manager

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

  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 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) See Vol 2 section 1.1 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 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

  13. Example of message static definition Specimen Segment group

  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 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 See Vol 2 section 3

  17. HL7 conventions on empty fields If the value of a field is not present, the receiver shall not change corresponding data in its database. If the sender defines the field value to be the explicit NULL value (i.e. two double quotes ""), it shall cause removal of any values for that field in the receiver's database. This convention is fully applied by the Laboratory Technical Framework. See Vol 2 section 3.9 PID|1||6543210 OBX|1|NM|14996-3^^LN||””|umol/l Of course this is forbidden with fields marked with usage R

  18. Vocabulary Placer Order Number (ordered battery) Filler Order Number (accepted battery) F101 12345 F102 12346 F103 12347 Laboratory request 123 ordered battery 12347 accepted battery F103 The physician places a lab request. The Order Placer allocates the unique Id “123” to this request consisting of: Order Placer allocates an Identifier to each ordered battery Order Filler allocates an Identifier to each accepted battery • a CBC (complete blood count) • an electrolye (Na, K, Cl) • a creatinine clearance

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

  20. 1st example: Two hematology batteries

  21. 1st example: Two hematology batteries

  22. Two hematology batteries: One message

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

  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. Results validated Order Filler Application Order Result Tracker Application ACK ACK Message OUL Message OUL <SB> message <EB><CR> MLLP Initiating module MLLP Accepting module <SB> acknowledgement <EB><CR>

  25. Acknowledgements with MLLP (3)Transactions with trigger events on both sides (e.g. LAB-1) New placer order Order Status change ORL^OK OML^NW OML^NW ORL^OK OML^SC ORL^OK OML^NW OML^SC ORL^OK ORL^OK OML^SC Initiating module Accepting module ORL^OK Order Placer application Order Filler application Initiating module Accepting module

  26. Laboratory Device Automation (LDA) Work Order Steps Pre/post processor Analyzer LDA Demographics Demographics ADT Placer order Order Placer Order Filler Filler order Work order Results 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 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 Scope:

  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 Placer Order Filler POCDM POCRG 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 Master Laboratory Code Set Consumer 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 MFN^M08: Numeric tests MFK^M08: Acknowledgement MFN^M09: Categorical tests MFK^M09: Acknowledgement MFN^M10: Batteries MFK^M10: Acknowledgement MFN^M11: Calculated tests MFK^M11: Acknowledgement

  43. XD-LAB : Le partage des comptes rendus d’analyses médicales

  44. L’une des cibles affichées : Le DMP • Partager dans le DMP les résultats de biologie les plus pertinents du parcours de soins • Faciliter l’accès à l’historique biologique du patient par les praticiens, dans le respect du secret médical • Améliorer l’efficacité des soins en minimisant les analyses redondantes et en éclairant mieux les décisions médicales

  45. Un compte rendu pour l’œil du clinicien, capable d’alimenter l’historique 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 d’un 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 d’un compte rendu d’analyses CDA : Corps <structuredBody> <section> <text> Pour l’œil du soignant <entry>  machine <section> <text> <entry>  machine L’entête donne le contexte Entête <ClinicalDocument> • 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 Chapitre et sous-chapitre Résultats d’analyses Chaque section de résultats contient une entrée obligatoire structurant et codant les résultats, pour les rendre intégrables dans le système du récepteur, afin de consolider un historique biologique Entête 18767-4: Gaz du sang Gaz du sang artériel pO2 (mm Hg) 85 pCO2 (mm Hg) 35 <entry> (obligatoire) 18719-5: Biochimie sanguine Ionogramme Na (mmol/l) 141 K (mmol/l) 4.4 <entry> (obligatoire)

  48. Comparatif XD-LAB / H’ Médecins      Données structurées restreintes : Code test ne précise pas la nomenclature utilisée. Format texte brut, requérant un viewer spécifique Corps inorganisé et monolithique : Des lignes de texte, sans aucune mise en forme Un format spécifique aux résultats de laboratoire. Entête sommaire (médecin, patient, référence demande)      Richesse de mise en forme du corps. Sections différenciés par labo exécutant, biologiste valideur, … CDA : Un standard unique pour tous les documents médicaux Données structurées complètes : Test, nomenclature, résultat, unité, méthode, intervalle de référence, de 0 à n antériorités, commentaires, valideur, exécutant, anormalité … Format XML, affichable et imprimable par un simple navigateur web Entête du compte rendu fournit un contexte précis et détaillé CDA HPRIM Médecins

  49. Rendu d’une analyse mono-échantillon Section spécialité Bloc <text> destiné au lecteur humain Résultats antérieurs Résultats courants

  50. Spécialité Bloc <text> de la section résultats

More Related