Les dispositifs médicaux reliés aux dossiers des patients, … · 2017. 1. 16. · Dispositifs médicaux et dossier patient informatisé – DICOM et HL7 - - Franck DURAND Les dispositifs

Dispositifs médicaux et dossier patient informatisé – DICOM et HL7 -www.acaciafrance.fr - Franck DURAND

Les dispositifs médicaux reliés aux dossiers des patients, différents outils et standards de

communications (DICOM, HL7)

Licence IMB - 2ème étage - bâtiment GIM - IUT de Lorient 18 Janvier 2017 – 14h – 16h

Franck DURAND


DM

S.I.H D.P.I PACS

Médecins

Filtre à la visualisation ? Marquage CE des logiciels médicaux ? Quels formats ? Quels risques ?

HL7 2.x ? DICOM WorkList ? DICOM SOP ? XML ? IHE PAM 2.4 ?


Seuls certains de ces logiciels sont des dispositifs médicaux (DM) ou des dispositifs médicaux de diagnostic in vitro (DM DIV) car ils ont une finalité médicale. Ils doivent, de ce fait, être marqués CE comme tous les DM et DMDIV. Le marquage CE atteste de leur conformité à la réglementation. Ils entrent alors dans le champ de surveillance de l’ANSM. Des repères réglementaires encadrant la mise sur le marché de ces produits en France sont donnés ici aux éditeurs (fabricants) de logiciels et applications en santé. Les logiciels et applications utilisés dans le champ de la santé ne relèvent pas tous du statut de DM ou de DM DIV. La destination est fixée par le fabricant (l’éditeur) de l’application. Elle est décrite dans la notice, l’étiquetage mais également dans le matériel promotionnel. Pour être qualifié de DM ou DM DIV, un logiciel doit être destiné à une utilisation à des fins médicales au sens de la définition du DM ou du DM DIV. Il doit permettre, par exemple, un diagnostic, une aide au diagnostic, un traitement ou une aide au traitement. Il doit également répondre à quelques critères de qualification tels que :le logiciel doit fournir une information médicale nouvelle contribuant par exemple au diagnostic ou au traitement du patient,

Présentation d’un système permettant de sauvegarder, visualiser, interpréter, comparer les examens issus des dispositifs médicaux de: - 15 modalités différentes - 40 fournisseurs - plus de 100 appareils différents

Une seule liaison avec le SIH/DPI Electrocardiographes

Epreuves d’effort Holter ECG / MAPA

Marqueurs d’événements Epreuves Fonctionnelles respiratoires

Moniteurs Défibrillateurs

EEG Etude du sommeil

Réhabilitation cardiaque, etc. …

CardioServer


CardioServer


Multi-Modalités, Multifournisseurs Avec 100 appareils de 40 fournisseurs dans 15

modalités diagnostic vers un système archivage

neutre.

Une application orientée Web Aucune application spéciale n’est nécessaire,

seul un navigateur Web standard est utile.

Lecture simple en temps réel Confirmations en un seul clic pour les E.C.G

normaux avec comparaison intelligente en série

IT Convivial Application logiciel uniquement, intégrée avec la

majorité des SIH et dossiers patients.

Rentabilité des intégrations au SIH Achat d’une interface unique pour l’ensemble

des modalités; consolider de multiples

interfaces lors d’une intégration unique.

Assistance internationale 24/7/365 Assistance logiciel, mise à jour et accès à

distance




Les articulations entre les structures de normalisation, les standards et les différents groupes


Source internet: Infine–Conseil -Bernard Thibault


IHE International est composé de plus de 175 organisations

membres du monde entier engagées à améliorer

l'interopérabilité des systèmes d'information sur les soins de

santé.

Une organisation qui devient membre de IHE International peut

désigner des représentants pour participer aux comités de

domaine et aux comités de déploiement nationaux / régionaux

pertinents à ses intérêts.


IHE est une initiative des professionnels de santé et de l'industrie afin

améliorer la façon dont les systèmes informatiques de santé partagent

l'information.

IHE favorise l'utilisation coordonnée de normes établies telles que DICOM

et HL7 afin de répondre aux besoins cliniques spécifiques.

Les systèmes développés selon les recommandations IHE communiquent

mieux entre eux, ils sont plus faciles à mettre en œuvre et permettent aux

personnels de soins d'utiliser l'information plus efficacement.


IHE rassemble les utilisateurs et les développeurs en relation avec les technologies de l'information de santé (HIT) dans un processus en quatre étapes qui se répète chaque année:

- Les experts cliniques et techniques définissent les cas typique d'utilisation pour le partage

de l'information. - Les experts techniques créent des spécifications détaillées pour la communication entre les systèmes afin de traiter ces cas typiques, de sélectionner et d'optimiser les normes établies. - L'industrie met en œuvre ces spécifications appelées profils IHE dans les systèmes SIH. - IHE test les systèmes des fournisseurs lors d'événements soigneusement planifiés et supervisés appelés Connectathons.

Engager les parties prenantes du S.I.H. dans

un processus éprouvé


Créé en 1985 par l'ACR (American College of Radiology) et la NEMA (National Electric Manufacturers Association) dans le but de standardiser les données transmises entre les différents appareils de radiologie. Ce standard définit un format de fichier mais aussi un protocole de transmission des données (basé sur TCP/IP)

Histoire

HL7 a été fondée en 1987 afin de fournir une norme pour l'échange de données avec les systèmes d'information hospitaliers. Donald W. Simborg, le PDG de Systèmes Simborg a pris l'initiative de créer l'organisation HL7 dans le but de permettre une utilisation plus large de son propre protocole d'échange (connu

sous le nom de protocole de StatLAN, défini à l'origine à l'Université de Californie, San Francisco dans le fin des années 1970)


Digital Imaging and COmmunication in Medicine is a standard for handling, storing, printing, and transmitting information in medical imaging. It includes a file format definition and a network communications protocol. The communication protocol is an application protocol that uses TCP/IP to communicate between systems. DICOM files can be exchanged between two entities that are capable of receiving image and patient data in DICOM format.


DICOM Why ?


DICOM Why ?


Example of Equipment with DICOM Connection


RIS Connection, HL7, DICOM Worklist






DICOM Terminology

•DICOM File Format

•Information Object Definition (IODs)

•Application Entity Title (AE Title)

•Service Class User/Provider (SCU/SCP)

•Unique Identifier (UID)

•Transfer Syntax

•Value Representations (VR)


Application Entity Title (AE Title)

AE is essentially the name of a DICOM device or program used to uniquely identify it (you cannot have two identical Aes in your Pacs network)

Callling AE Title Called AE Title

JOHN


Service Class Provider (SCP) Service Class User (SCU)

Service Class -Service -Object

SOP Pair

DICOM SERVICES CLASS and IOD

« I am Sending a CT Image to you »

A Verb (an action)

A noun (an object)

Service IOD


DICOM SERVICES CLASS


DICOM Storage

•Allows a system to send object data to a remote node

•Object data may be images (e.g. CT images), Waveforms, Mammo CAR, ECG, etc…


Unique IDentifier

UIDs are internal DICOM mechanism to identify Studies, Series, Images, SOP classes, etc. A UID is a string up to 64 characters including digits and “.” example SOP Instance UID 1.2.840.113619.2.65.3.200583648570.2428.1178103577.1 No Leading zeroes in UID components are not allowed.

This string is MUST be UNIQUE around the world. Unique Identifiers (UIDs) provide the capability to uniquely identify a wide variety of items. They guarantee uniqueness across multiple countries, sites, vendors and equipment. Different classes of objects, instance of objects and information entities can be distinguished from one another across the DICOM universe of discourse irrespective of any semantic context.

Each UID is composed of two parts, an <org root> and a <suffix>:

UID = <org root>.<suffix> The <org root> portion of the UID uniquely identifies an organization, (i.e., manufacturer, research organization, NEMA, etc.), and is composed of a number of numeric components as defined by ISO 8824. The <suffix> portion of the UID is also composed of a number of numeric components, and shall be unique within the scope of the <org root>. This implies that the organization identified in the <org root> is responsible for guaranteeing <suffix> uniqueness by providing registration policies. These policies shall guarantee <suffix> uniqueness for all UIDs created by that organization. Unlike the <org root>, which may be common for UIDs in an organization, the <suffix> shall take different unique values between different UIDs that identify different objects.


DICOM file Format

SOP: « Service-Object Pair (SOP) Class » est défini par l’union d’une définition de l’information d’objets (IOD) et un service éléments DICOM (DIMSE). La définition « SOP CLASS » contient les règles et la sémantique qui peut restreindre l’utilisation des services du groupe de service DIMSE ou les attributs de l’IOD. Les exemples d’éléments de services sont: Store, Get, rechercher, déplacer, etc.

Les exemples d’objets sont des images CT, les images IRM, mais comprennent également des listes d’horaire, les files d’attente d’impression, etc.


DICOM file Format


• Clinical data comes in a wide variety of formats. • Ex. Distances measured in millimeters, time in seconds, • patient names are typically written in alphabetic characters, and so on. • The DICOM standard defines 27 basic data types, known as value representations (VRs), • which are designed to encapsulate all possible clinical data types. • Each VR has its own abbreviated two-letter name, a definition of what it represents, a description of what characters are allowed in its data, and a pre-scribed data length.

Value Representation (VR)


Free Form Text VR: SH: Short String LO: Long String ST: Short Text LT: Long Text UT: Unlimited Text Math VR: IS: Integer String DS: Decimal String US: Unsigned Short SS: Signed Short UL: Unsigned Long SL: Signed Long FL: Floating Point Single FD: Floating Point Double

Fixed Format VR: DA: Date TM: Time DT: DateTime PN: Person Name

Other VR: OB: Other Byte OW: Other Word OF: Other Float SQ: Sequence AE: Application Entity AS: Age String AT: Attribute Tag

Other VR CS: Code String UI: Unique Identifier UN: Unknown

Value Representation (VR)


The Data Set A Data Set represents an instance of a real world Information Object. A Data Set is constructed of Data Elements. Data Elements contain the encoded Values of Attributes of that object. Data Elements A Data Element is uniquely identified by a Data Element Tag. The Data Elements in a Data Set shall be ordered by increasing Data Element Tag Number and shall occur at most once in a Data Set.

DICOM Data set


Transfer Syntax

A transfer syntax is the encoding methodology used to send data over network, or to write data to a physical medium.


Transfer Syntax


Information Object Definition


Image Display


Image Display


• HL7 is an ANSI-accredited Standards Development Organization (SDO) operating in the healthcare arena. • It is a non-profit organization made up of volunteers – providers, customers, vendors, government, etc. • HL7 is an cronym for Health Level Seven. Seven represents the highest, or « application level of International Standards Organization (ISO) communication model for Open System Interconnection (OSI) networks.

What is HL7 ?


HL7 focuses on the clinical and administrative data domains. • It defines data exchange standards for these domains called messages or messaging specifications (aka HL7 messages) – Messages are developed by technical committees and special interest groups in the HL7 organization. • HL7 organization defines 2 versions of the messaging standard:

– HL7 v2.x (syntactic only) – HL7 v3.0 (semantic capability added)

What is HL7 ?

Réunion régionale AFIB au CHU de Toulouse Mardi 15 mars 2016 – DICOM et HL7 - Franck DURAND

•HL7 V2.x

•– Defines electronic messages supporting hospital operations

•HL7 V3

•HL7 Clinical Document Architecture (CDA) Realeases 1 and 2

•HL7 Arden Syntax - Representation of medical knowledge •HL7 EHR & PHR Functional Specifications

•Etc…

HL7 Standards


HL7 Version 2 (HL7 V2) •Not « Plug and Play » - It provides 80 % of the interface and a framework to negociate the remaining 20 % on an interface-by-interface basis

•Historically buit in an ad hoc way because no other standar existed at the time

•Generally provides compatibility between 2.x versions

•V2 is what most people think of when people say « HL7 »

•HL7 v2.5 was approved as an ANSI standard in 2003

•HL7 is currently working on version 2.7

The Industry Standard


HL7 v2 Message

• Composed of reusable segments, each identified by a 3-letter mnemonic • All messages must start with header segment MSH which includes sender, receiver, datetime, message identifier, message type, and trigger event • Segments used in a message are determined by message type

OBX|1|NM|10839-9^TROPONIN-I^LN||5|ng/ml| 0-1.3|H||H|F|19980309…


HL7 Basic Transaction Model


HL7 V2 Message

Exemple: MSH|^~&|||Lariboisière PID||||14EE12|THOMAS^Etienne||19920726|M|||13 rue Descartes^Paris^75021 FAC|13AZ12||5 rue du Nord^Paris^75022 PV1||||0103030405^^[email protected]||||54AZE85^Dobian^Michelle DG1|1||GLOBAL|Traitement|20151102 STF||5873AD2|Lafitte^Jacques|||||||^^^[email protected]^^0101010101|Lariboisiere


HL7 V2 Message


Séparateur valeur Usage

Segment <cr> hex 0D Termine le segment. Cette valeur ne peut pas être modifié.

Champs | Sépare deux champs adjacents.

Composant ^ Sépare deux composants d'un même champ

Sous Composant & Sépare deux sous composants d'un même composant

Répétition ~ Sépare plusieurs occurrences du même champ.

Échappement \ Caractère d’échappement

Présentation succincte de HL7 version 2.3

•Les séparateurs

HL7 V2 Message


Quelques segments : MSH : Entête, premier segment dans chaque message. PID : Identification du patient EVN : Événement PV1 : Visite du patient PV2 : Complément d’information du PV1 OBX : Observation AL1 : Allergie MRG : Fusion ORC : Examen demandé (information globale) OBR : Examen demandé (information détaillée) MSA : Accusé de réception

HL7 V2 Message


Quelque type de messages : ACK : Message d’accusé de réception général ADR : Réponse ADT ADT : Message ADT OMS : Message de demande de fourniture en stock ORU : Transmission non sollicitée d’un message d’examen Exemple de message HL7 de type ORU : MSH|^~\&|SRLMED|BPTRU|CIT|PROFIL|200701221630||ORU^R01|IM00001254|T|2.3|||||CA|ASCII|FR<CR> PID|1|MP0245|PP2548||JEAN^JACQUES|LAMERE^DEJEAN|196405060925|F|||rue souvenir, 1052^^^^^CA|||FR|M|||660815 063 69||||LAVAL|||CA|||||<CR> OBR|1|R2578|R264|ECO^ECOGRAPHIE|||200702221530|200702231250|||||||||||||||||A||||||||||||||||||<CR> OBX|1|ST|^Hémodialyse||||||||||||<CR>

Références et slides utilisés dans la présentation: DICOM Structure Basics by Gunjan Patel – Bangalore, Karnatak, India / [email protected] – Medical software Biomédical Engineer DICOM Structure by Shiju P K, Bengaluru Area, India – Senior Technical Specialist HL7 Standards, Nawanan Theera-Ampornpunt, M.D., Ph.D. – Depratment of community Medicine, Faculty of Medicine Ramathibodi Hospital. Certified HL7 CDA Specialist. HL7 Informatique de santé et HL7, Alleknologie


mailto:[email protected]

Réunion régionale AFIB au CHU de Toulouse Mardi 15 mars 2016 – DICOM et HL7 - Franck DURAND

Vos questions ?

Franck DURAND,

Email: [email protected]

Documents

Les dispositifs médicaux reliés aux dossiers des patients, … · 2017. 1. 16. · Dispositifs médicaux et dossier patient informatisé – DICOM et HL7 - - Franck DURAND Les dispositifs