Vers des dossiers patients «interopérables»Enjeux et solutions
C.Daniel
INSERM, UMR_S 872, Eq. 20, Université Paris Descartes, France
AP-HP, Paris, ASIP Santé
http://fr.creativecommons.org/contrats.htm
Plan
2
ContexteSystèmes d’Information de Santé développés en
silo, non partagés ,non “intéropérables”Interopérabilité sémantique
Qu’est ce que c’estPourquoi faire?Comment ?
Rolés des organismes de standardisation, d’IHE, de l’ASIP Santé
Un example : production du réferentiel “CR d’anatomie pathologique”
5 règles d’or de la production de réferentiels d’interopérabilité sémantique
Interopérabilité sémantique & medecine translationnelle
ContexteSystèmes d’Information de Santé
3
Gestion de données de santé multimodales (textes, signaux, images, etc.)
Coordination des
soinsRecherche biologiqueRecherche clinique,
épidémiologique ou de veille sanitaire
Un patient , combien de dossiers?
Contexte: Informatique clinique
Systèmes d’Information gérant les données de santé individuelles relatives à des patients ou des tissus (échantillons biologiques) Dossier Patient Informatisé, système de gestion de
plateaux techniques, SIH, Dossier Patient de réseau de soins, Dossier Médical Personnel, etc
ClinicienInformaticien
biomédicalInformatique
clinique
4
Biologiste
ClinicienInformaticien
biomédicalInformatique
clinique
Bio-informatique
Contexte: Bio-informatique
Systèmes d’Information gérant des données relatives à des gènes, molécules, cellules et tissusGénomique, protéomique, etc
5
Contexte: Informatique de la recherche clinique et épidémiologique
6
Système d’Information gérant des données de santé individuelles anonymisées relatives à des patients & données agrégées relatives à des populations Biologist
e
Clinicien
Investigateur/épidémiologist
eChercheur en
santé publique
Informaticien biomédical
Informatique clinique
Informatique de la recherche
clinique, épidémiologique et santé publique
Bio-informatique
Contexte: des Systèmes d’Information de Santé développés en “silo”
7
Méthodes et outils COMMUNS de gestion des données, d’informations et de connaissances exploitées par les professionnels de santé …Traitement des données et des signauxIntégration de données hétérogènes distribuéesRecherche d’information dans des bases de
données et d’imagesFouille de données et de texteetc
… MAIS développement « EN SILO » de Systèmes d’Information non « intéropérables »
Biologiste
Clinicien
Investigateur/épidémiologist
e Chercheur en santé
publique
Informaticien biomédical
Continuum de la médecine translationnelle (d’après Sarkar 2010)
“Bench”(molécules & cellules, tissus)
“Community”(populations)
“Policy”(populations)
Informatique clinique
Informatique de la recherche
clinique, épidémiologique et santé publique
INNOVATION
VALIDATION ADOPTION
Verrou 1“Du génotype vers le
phénotype”
Verrou 2
Verrou 3
Bio-informatique
8
“Bedside”(patients )“Bedside”(prélèvements, patients (données cliniques, biologiques et d’imagerie))
Interopérabilité sémantique Qu’est ce que c’est?
9
Interopérabilité des Systèmes d’information de Santé
10
Capacité de ces systèmes à offrir aux acteurs de santé (professionnels de santé, patients, citoyens, autorités sanitaires, structures de recherche ou de formation, etc) des solutions d’échange ou de partage de données de santé
3 niveaux d’interopérabilité
11
Absence d’interopérabilité
Interopérabilité technique et syntaxiqueAccès à des données de santé dématérialisées,
interprétables par l’humain e.g un compte rendu d’hospitalisation textuel
« Semantic Interoperability for Better Health and Safer Healthcare. Research and Deployment RoadMap for Europe - Semantic Health Report » de janvier
2009
Une information compréhensible pour l’être humain…
Hépatotoxicité du
Doliprane
Stent actif sur l’IVA
Peflacine pour une infection urinaire à
E.coli résistant aux quinolonesPeflacine
E.Coli – Quinolones - R
Inférences rapides permettant l’interprétation
d’informations multi-sources, multi-format
Hépatite cholestatique : oui
Blb augmentéeALAT augmentées
…et aussi pour la machine
Hépatite cholestatique : oui
Atteinte hépatique: Hépatite cholestatique
1000 11 0001
1000001
0110 10001
101001
Formats hétérogènes
(« model of use »)
Structure de données +
Vocabulaire(terminologie de référence
e.g CIM-10, SNOMED, LOINC, ADICAP, etc)
Référentiel d’interopérabilité
sémantique(« model of meaning »)
Cette patiente a
une hépatite
cholestatique
1000 1
1 0001
1000001
0110 10001
101001
3 niveaux d’interopérabilité
14
Interopérabilité sémantiqueAccès à des données de santé dématérialisées
codées en utilisant un système de codage interprétable par la machine e.g diagnostics codés en CIM-10, actes codés en CCAM,
résultats de biologie codés en LOINC, diagnostics anatomo-pathologiques codés en ADICAP, etc)
« Semantic Interoperability for Better Health and Safer Healthcare. Research and Deployment RoadMap for Europe - Semantic Health Report » de janvier
2009
Codage de l’information médicale
15
Codage de l’information médicale
2975493
2962703
2975493
2975493
6943503
7963493
2975493
16
Tabac ? oui/non
Fumeur / Non fumeur ?
Nombre de cigarette / jour ?
Codage de l’information médicaleEtape 1: Standardisation des variables
Variable 1
Variable 2
Variable 3
Variable 4
Variable 5
Variable 6
Variable 7
Variable 8
17
Variable 1
Variable 2
Variable 3
Variable 4
Variable 5
Variable 6
Variable 7
Variable 8
Vous sentez vous fatigué ? Souvent / parfois / rarement /jamais
Vous sentez vous fatigué ? Souvent / jamais
Codage de l’information médicaleEtape 1: Standardisation des variables
18
PAS couché (mmHg)?(min/max)
Pression artérielle systolique en position couchée au repos (mmHg) ? (min/max)
Variable 1
Variable 2
Variable 3
Variable 4
Variable 5
Variable 6
Variable 7
Variable 8
19
Codage de l’information médicaleEtape 1: Standardisation des variables
« Automatique »Simple
Athérome M-52100 atherome
Grammaire compositionnelle permettant le codage d’expressions complexeAthérome de l’artère rénale
M-52100|atherome| |localisé à|T-46600 artère rénale
Ovariectomie droite au laser83152002|oophorectomy|260686004|method|=25820006|laser excision – action|363704007|procedure site|=20837000|structure of right
ovary|
20
Codage de l’information médicaleEtape 2: Codage des variables et des données
(e.g SNOMED
Automatique + manuelAbréviation, termes locaux
AVC o D3-89550 accident cérébrovasculaire
Connaissance implicite, expressions elliptiquesAldostérone couché
F-B2970 aldostérone (substance)A-18160 couche (dispositif)
Dosage de l’aldostérone, position en décubituso P3-71300 dosage de l’aldostérone (procédure)o F-10450 position en décubitus (signe)
Information temporelleAccident coronarien père (avant 55 ans)Diagnostic DFM porté <2ans avant inclusion
2121
Codage de l’information médicale Etape 2: Codage des variables et des données
Bibliothèque de variables standardisées codées
22
Projet SHARE : Shared Health And Clinical Research Electronic Library“SHARE is a global,
accessible, electronic library, which through advanced technology, enables precise and standardized data element definitions that can be used within applications and across studies to improve biomedical research and its link with healthcare”.
Bibliothèque de variables standardiséesHEGP (Recherche clinique/Soin) Terminologies à
alignerNb. Termes RC alignés
Taux (%)
IT-RC/IT-S(n=3.739/8.587)
648 17.3%
Arcadia/Visite(n=236/367)
26 15.7% -> 11.0%
Arcadia/Visite (SNOMED)
71 30.0% -> 13.1%
23
Taux de réutilisation potentielle de données cliniques: 13.1%
Bibliothèque de variables standardisées HEGP (Recherche clinique/Soin)
date4%
time1%
Codelist36%
binary18%
numeric21%
text20%
Variables « Soin »
Variables « Recherche clinique »
date7%
time1%
Codelist16%
binary30%
numeric22%
text24%
24
Interopérabilité sémantique Pourquoi faire?
25
Interopérabilité sémantiqueBénéfices attendusPermet l’extraction et l’utilisation de
l’information clinique non seulement par des humains
Mais aussi par des machines (Systèmes d’information de Santé) offrant des fonctionnalités avancées pour la coordination des soins, la recherche et formation
Grâce à l’intégration de données et de connaissances
26
Coordination des soinsCapture de données (guidée par une ontologie)
FRACTURE SURGERY FRACTURE SURGERY
Structured Data Entry
File Edit Help
TibiaTibia FibulaFibula AnkleAnkle More...More...
RadiusRadius UlnaUlna WristWrist More...More...HumerusHumerus
FemurFemur
LeftLeft RightRight
More...More...Gt Gt TrochTroch
ShaftShaft NeckNeck
FemurFemur
LeftLeft
NeckNeck
ReductionReduction FixationFixation
OpenOpen ClosedClosedOpenOpen
FixationFixation
Réduction d’une fracture du col du fémur gauche27
Ce patient présente de nouveaux résultats
biologiques en rapport avec sa
pathologie hépatique
Coordination des soinsRecherche d’information (vues, navigation)Vues construites à partir de l’interprétation de
données cliniques structurées codées
Hépatite
Hépatite cholestatique
Hépatitecytolytique
Cholestaseet ictère
Maladies Hépatobiliaires
Augmentation des ALAT
Tests fonctionnels hépatiques
Bilirubine augmentée
test_diagnostique_de
Hépatite cholestatique : oui Blb augmentéeALAT augmentées28
Coordination des soinsAide à la décision, évaluation des pratiquesCoupler les données cliniques aux règles en se
basant sur l’interprétation de données cliniques structurées codées
29
E.g Rappels, alarmes, suggestions diagnostiques ou thérapeutiques, détection des interactions, détection de pratiques inappropriées
Epidémiologie, veille sanitaire
Tableaux de bords construits à partir de l’interprétation (agrégation) de données cliniques structurées codées
Escherichia
Escherichia coli
Entérobactéries
Oflocet
Quinolones
Peflacine
test_de_susceptibilitéKlebsiella
Klebsie pneumoniaella
La résistance des
entérobactéries aux
fluoroquinolones augmente en Ile de France
…
30
Fluoroquinolones
Epidémiologie, veille sanitaire
Détection du signal (pharmacovigilance) à partir de l’interprétation (agrégation) de données cliniques structurées codées
Hépatite
Hépatite cholestatiqu
e
Hépatitecytolytique
Cholestase
et ictère
Maladies Hépatobiliaires
Augmentation des ALAT
Tests fonctionnels hépatiques
Bilirubine augmentée
test_diagnostique_de
Hépatite cholestatique : ouiBlb augmentée
ALAT augmentées
3 cas d’hépatotoxic
ité liés au Doliprane ?
Atteinte hépatique: Hépatite cytolytique
Interopérabilité sémantique Comment?
32
Standards pour l’interopérabilité des SISHealth Level 7 (HL7)
33
Organisme de développement de standards (ANSI) créé en 1987
Standards d’échange ou partage de données informatisées administratives et cliniques (spécifications messages, documents)
500 organisations membres, 1500 inscrits, 15 affiliés internationauxFrance depuis 2004
http://wwww.hl7.org
HL7 Version 3
34
Modèle de données de réferenceRIM : Reference Information Model
Modèle objet représenté en Unified Modeling Langage (UML)Types de données rigoureusement définis
Couplage avec des domaines de vocabulaires contrôlés prédéfinis
Modèles de données spécifiquesOrganisés en 30 domaines d’intérêt (Universal
Domains) Ex : laboratoire, médicament, prescription, résultats, etc
Conçus en utilisant une méthode formelle de développement de standards (HDF : HL7 Development Framework)Messages
e.g prescription médicamenteuse, résultat biologique, etcDocument clinique : HL7 Clinical Document architecture
(CDA)34
ISO
ISO
ISO
35
RIM HL7: Diagramme de classes
35
• 110 classes • 532 attributs• 167 Relations
• 30 relations Is-a• 2 relations d’agrégation
• 43 types de données (Data types)• Couplage à des vocabulaires contrôlés
ISO
Types de données HL7
36
Booléen
String
Physical
Quantity
Real
Integer
Concept Descript
or
<code ='8480-6 ' displayName=‘Intravascular systolic' codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/>
ISO
HL7 v3 Architetcure de document clinqiueHL7 Clinical Document Architecture (CDA)
Patient
Destinataire
Signataire légalValideur
Auteur
Participant
Opérateur de saisie
Entête
Corps structuré
Corps non
structuré
Observation
ROIMoyen d’observation
Prescription médicamenteuse
Procédure
Episode de soin
Observation
Organiseur
Acte
37
ISO
Document clinique
ClinicalDocument : en-tête CDA• identification, type, gestion du document• patient et rencontre (venue en étabt.)• participants (prescripteur, signataire, etc) structuredBody : corps structuré• section
• section de second niveau text [ … ] entry
observations images & graphes …
• section text [ … ]
entry …
fournit l’essentiel des métadonnées pour l’indexation du document
38
HL7 CDA niveau 3
HL7 CDA : structureEx: Pression artérielle systoliqueVariable
élément <observation> utilisant le modèle Vital Signs Observation template.
<observation classCode='OBS' moodCode='EVN'>
<templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.13'/> <code code='8480-6 ' displayName=‘Intravascular systolic pressure' codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/> <effectiveTime value=' '/><value xsi:type='PQ' value=' ' unit=' mm[Hg] '/>
</observation> “Organiseur” “Signes vitaux”
Element <organizer><organizer classCode='CLUSTER' moodCode='EVN'>
<templateId root='2.16.840.1.113883.10.20.1.32'/> <code code='46680005' displayName='Vital signs' codeSystem='2.16.840.1.113883.6.96' codeSystemName=‘SNOMED CT />
<!-- one or more vital signs observations --> <observation classCode='OBS' moodCode='EVN'> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.13.2'/></observation>
</organizer>3939
HL7 CDA : vocabulaire Ex: Variables du groupe «Signes vitaux»
40
Code de l‘observation (LOINC)
Designation de l‘observation
Type de donnée de la valeur de l’observation
Unité
9279-1 RESPIRATION RATE
Numérique
/min8867-4 HEART BEAT 2710-2 OXYGEN SATURATION %
8480-6INTRAVASCULAR
SYSTOLIC PRESSUREmm[Hg]
8462-4INTRAVASCULAR
DIASTOLIC PRESSURE8310-5 BODY TEMPERATURE Cel or [degF] 8302-2 BODY HEIGHT
m, cm,[in_us] or [in_uk]
8306-3 BODY HEIGHT^LYING
8287-5CIRCUMFRENCE.OCCIPIT
AL-FRONTAL (TAPE MEASURE)
3141-9 BODY WEIGHTkg, g, [lb_av] or
[oz_av]
Standards pour l’interopérabilité des SIS
41
http://www.hl7.org/v3ballot/html/welcome/environment/index.htm
30 domaines
Standards pour l’interopérabilité des SIS CEN TC 251
42
Organisme de développement de standards Standard de communication entre DPI (EHR)Solution de partage de dossiers ou d’éléments de
dossierEntre systèmes hétérogènes au sein d’un réseau
EN13606 (EHRcom) en 2006Modèle de données de référenceModèle de données spécifiques (archétypes)
Modèles de messages
“Standardiser les standards”
43
HL7
CEN TC 251
Standards - Mode d’emploi ?Rôle de l’initiative “Integrating the Healthcare Enterprise” (IHE)
44
Y-a-t-il un chef d’orchestre ?IHE (Integrating the Healthcare Entreprise)
Promotion de l’utilisation de standards existant IT (Internet, ISO, etc)Domaine de la santé (HL7, DICOM)
Existe-t-il une partition ?Technical framework IHE – Profils d’intégrationForum de discussion et de spécification
Utilisateurs et développeursY-a-t-il des répétitions ?
ConnectathonsEnvironnement de test de la connectivité des produits
Editeurs testent la connectivité de leurs produits sous la surveillance d’observateurs neutres
45
Integrating the Healthcare Enterprise (IHE)Connectathons
46
Integrating the Healthcare Enterprise (IHE)
Integrating the Healthcare Enterprise (IHE)
47
Standards - Mode d’emploi ?Rôle de l’ASIP Santé
48
En France, l’ASIP Santé (Agence des Systèmes d’Information Partagés de Santé) est en charge du cadre d’interopérabilité des SI de santéDéfinir, promouvoir et homologuer des référentiels
contribuant à l’interopérabilité, à la sécurité et à l’usage des systèmes d’information de santé et de la télésanté.
IHE CDA
Standards internationaux dédiés à la santé
DICOM
CDA
Standards internationaux généralistes (de l’internet)
SoaphttpxmlSAML…
SNOMED
LOINC
CIM-10
assemblés et contraints dans des
profils IHE
49
ASIP SantéCadre d’interopérabilité
IHE CDA
Interopérabilité sémantique Comment?
Un exemple : le référentiel “Compte rendu structuré d’anatomie pathologique”
50
Contexte : Démarches nationales de standardisation des variables…
51
CR anatomie pathologiquePays-Bas, Allemagne, Australasie
CR anatomie pathologique de cancérologieCAP (College of American Pathologists)
67 checklists et protocoles (Octobre 2009)France - SFP (Société Française de Pathologie) –
INCa (Institut du Cancer) Items minimaux CR tumeur primitive - 20 localisations
Australasie6 modèles
Royaume-Uni
Contexte : Démarches nationales de standardisation des variables…
11 avril 202352
Contexte : … et de production de guides d’implémentation
53
Standards internationaux généralistesXML
CAP electronic Cancer Checklist
Standards internationaux d’informatique de santéCEN archétypes
AustralieHL7 CDA
Pays-Bas, Allemagne
Objectif: Référentiel “Compte rendu structuré d’anatomie pathologique”
54
Modèles HL7 CDA de CR anatomie pathologique pour l’échange ou partage dans un contexte de coordination des soins
Périmètre22 modèles de CR
Modèle génériqueTout type de pathologie (inflammatoire, vasculaire,
traumatique, métabolique ou tumorale) Modèles générique de CR de cancer20 modèles de CR de cancer spécifiques d’organe (85%
des cancers incidents) Variables anatomo-pathologiques “traditionnelles”
Microscopie optique (y compris immunohistochimie, hybridation in situ, etc)
Méthode de production du référentielProfil de contenu IHE
55
Production du référentiel international (profil de contenu IHE « Anatomic Pathology Structured Report ») Initiative conjointe IHE-HL7 anatomic pathology
(ADICAP, ASIP Santé, CAP, NAACCR, CDC) Production de l’extension nationale (référentiel
ASIP Santé « CR d’Anatomie Pathologique (CR-ACP) »)
CR d’anatomie pathologique (HL7 CDA)Corps structuré
<text>
AP <entry>
Human-readable part
Machine-readable part
specimen information <organizer> A specimen
problem <organizer> A problem observed
1..1
0..*
1..1
0..*
0..*
AP ancillary technique <observation>0..*
clinical laboratory <observation>0..*
One to six AP sections
specimen collection <procedure>1..1
0..*
Procedure, target site, specimen type, …
has as sub-observation
AP <observation>
1..6
<structuredBody>1..1 Body of the report
<ClinicalDocument> Header of the APSR, delivers contextualinformation.
non-AP <section>
AP <section>
0..*56
57
[0..*] <value> (zero to many response)•coded (code, coding system, version, display name)
[0..*] <qualifier> (post coordinated expression)• numeric (integer or real, unit)•textual
Variables anatomo-pathologiques (n=80)e.g “procédure de collecte du prélèvement”, “taille de la tumeur”, “type histologique”
Jeux de valeurs (“Value Sets”) des variables codées (Coded Descriptor)
Procédure de collecte du prélèvement (CR cancer du sein) Système de codage: PathLex – OID:
1.3.6.1.4.1.19376.1.8.2.1Jeu de valeurs OID: 1.3.6.1.4.1.19376.1.8.5.2
Exceptions admises: Inconnu, demandé mais inconnu, autre
displayNameBreast excision without wire-guided localizationBreast excision with wire-guided localizationTotal mastectomy (including nipple and skin)
58
CR d’anatomie pathologiques standardisés, interprétables par l’Homme et la machine - HL7 CDA
Ce que voit la
machine
59
Ce que voit le clinicien…
60
Ce que voit la machine…<ClinicalDocument xmlns='urn:hl7-org:v3'>
<typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/>
<!-- conformance to a generic APSR content module -->
<templateId root='1.3.6.1.4.1.19376.1.8.1.1.1'/>
<!-- conformance to a cancer APSR content module -->
<templateId root='1.3.6.1.4.1.19376.1.8.1.1.2'/>
<!-- conformance to a breast cancer content module -->
<templateId root='1.3.6.1.4.1.19376.1.8.1.1.2.1'/>
...remainder of the header not shown ...
<component>
<structuredBody>
<component>
<section>
<templateId root='1.3.6.1.4.1.19376.1.8.1.2.1'/>
<code code='22636-5' displayName=’Pathology report relevant history'
codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/>
<title>Relevant information provided by the ordering physician</title>
<text>
Tissue submitted: left breast biopsy and apical axillary tissue
</text>
<entry> ... </entry>
<component>
<section>
<templateId root='1.3.6.1.4.1.19376.1.8.1.2.1'/>
61
Kussaibi H, Macary F, Kennedy M, Booker D, Brodsky V, Schrader T, Garcia-Rojo M, Daniel C. CDA Implementation Guide for Structured Anatomic Pathology Reports Methodology and Tools. Medinfo. 2010
Solution d’échange et partage de CR d’anatomie pathologique multimédia au niveau international pour la coordination des soins
Utilisation secondaire dans un contexte d’assurance qualité, d’épidémiologie (registres du cancer) et de recherche clinique
Interopérabilité sémantique Comment?
Les 5 règles d’or de la production de référentiels d’interopérabilité sémantique
62
Le respect des standards internationaux (Format & modèles métier)
SAVE AS CDA
L’interopérabilité sémantique ce n’est pas magique!
Pas d’interopérabilité sémantique clinique en dehors de modèles CDA de référence encodant des modèles métier partagés, consensuels et validés
63
Un contexte (objectif et périmètre) bien défini
Grande variabilité des modèles métier de documents de santé en fonction du contexte d’utilisation (soin, recherche), des experts, du temps, etc
Importance de la validation du modèle métier (consensus d’experts, demande institutionnelle/réglementaire, etc) avant toute production de guide d’implémentation
L’interopérabilité sémantique c’est spécifique!
64
Des ressources d’expertise métier et technique
TA : 160/95
L’interopérabilité sémantique c’est pharaonique!
65
Des ressources d’expertise métier et technique
OrganiseurVital sign section
<organizer classCode=‘cluster' moodCode='EVN'> <templateId root='2.16.840.1.113883.10.20.1.32'/> <code code='46680005' displayName='Vital signs' codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED CT'/> <!-- one or more vital signs observations --> <observation classCode='OBS' moodCode='EVN'> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.13.2'/></observation> </organizer>
<observation> elements are using the Vital Signs Observation template.
<observation classCode='OBS' moodCode='EVN'> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.13'/> <code code='8480-6 ' displayName=‘Intravascular systolic pressure' codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/> <effectiveTime value=' '/><value xsi:type='PQ' value=' ' unit=' mm[Hg] '/> </observation>
<observation classCode='OBS' moodCode='EVN'> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.13'/> <code code='8480-6 ' displayName=‘Intravascular diastolic pressure' codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/> <effectiveTime value=' '/><value xsi:type='PQ' value=' ' unit=' mm[Hg] '/> </observation>
1…n Observation
66
Un niveau de structuration adapté
Le choix d’un niveau 3 de structuration permettent une interopérabilité sémantique doit être pesé.
La structuration minimale des documents de santé (CDA niveau 1) permet le partage de documents au sein du DMP interprétables par des humains
L’interopérabilité sémantique ce n’est pas automatique!
67
Des conditions d’opérationnalisation
Serveur de formulaire
Intégration de référentiels d’interopérabilité sémantique dans les SIIntégration aux modèles/terminologies locales
Produire des formulaires utilisablesGérer les versions
L’interopérabilité sémantique c’est parfois pratique….
…souvent technique
68
Des conditions d’opérationnalisationMaintenir les référentiels
Jan Fev Mar Avr Mai Jun Jui Aou Sep Oct Nov Dec
SNOMEDCCAMCIM 10
MeS
HLOINC
CR-ACP
69
ASIP Santé - “Info-structure” Plateforme collaborative de production et de distribution de référentiels d’interopérabilité sémantique
Services génériques classiquesCommunication (liste de diffusion, notification,
agendas partagés, etc)Accès et de partage de documents et fichiers
ayant des formats usuels (word, pdf, excel, etc)édition partagée, la gestion de version, etc
70
Services et outils spécifiques issus de la rechercheOutils d’ingénierie des modèles: éditeur
collaboratif de “templates” CDA (MIF)Open Medical Development Framework (OMDF)
(D.Ouagne)Outils d’ingénierie ontologique : éditeurs de
terminologies (OWL, SKOS) et de jeux de valeurs, services de terminologieITM (P-Y Vandenbusche)
71
ASIP Santé - “Info-structure” Plateforme collaborative de production et de distribution de référentiels d’interopérabilité sémantique
6ème règle : Des conditions d’adoption
72
“May all of your problems being technical”!
Nécessaire démarche de standardisation et de structuration des données cliniques selon des principes définis au sein de référentiels
Questions légitimes d’ordre économique, éthique, déontologique
L’interopérabilité sémantique c’est aussi économique,
politique, déontologique, etc !
Interopérabilité sémantique & médecine translationnelle
Recherche clinique & épidémiologique
73
Intégration systèmes d’information cliniques/de la recherche“De l’incantation à l’action”
74
Enquête en ligne auprès des 50 membres du “Clinical Research Forum” sur l’utilisation des SI cliniques en recherche (2005/2007)19 réponses (37%)L’importance des SIC pour la recherche
biomédicale est reconnue mais pas d’intégration opérationnelle
Les institutions ne sont pas en capacité de construire et maintenir les solutions répondant aux besoins exprimés DiLaura R, Turisco F, McGrew C, Reel S, Glaser J, Crowley WF Jr. Use of informatics and information technologies in the clinical research enterprise within US academic medical centers: progress and challenges from 2005 to 2007. J Investig Med. 2008 Jun;56(5):770-9.
“De l’incantation à l’action” Centres de recherche translationnelle
75
Plateformes d’informatique translationnelleFirst Summit on Clinical Research Informatics
(CRI) (AMIA) 2010“The need for effective information management
is critical to the addressing the many challenges facing clinical research, and there has been a corresponding and rapid evolution of the biomedical informatics methods and tools specifically designed to address clinical research information management requirements.”Butte AJ. Translational bioinformatics: coming of age. J Am Med Inform Assoc 2008;
15:709-14. Friedman CP. A "fundamental theorem" of biomedical informatics. J Am Med Inform Assoc 2009; 16:169-70. Hersh W. A stimulus to define informatics and health information technology. BMC Medical Informatics and Decision Making 2009, 9:24.Kahn MG, Kaplan D, Sokol RJ, DiLaura RP. Configuration challenges: implementing translational research policies in electronic medical records. Acad Med 2007: 82:661-9.
Enjeux de la recherche clinique
0
10
20
30
40
50
60
'90 '91 '92 '93 '94 '95 '96 '97 '98 '99 '00 '01 '02 '03
Appro
ved N
CEs
0
5
10
15
20
25
30
35
R&
D E
xpendit
ure
($Bn)
NCEs R&D Expenditure
76 NCE : New Chemical Entities
Augmenter les capacités de
développement initial
Phase I
Phase II
Phase III
rejection
rejection
rejection
Augmenter le nombre de nouveaux
médicaments approuvés
Accélérer la mise sur le
marchéLimiter le
coût
Eviter les échecs tardifs
Ian Ferrier, PhD
Enjeux de la recherche clinique
77
Intégrer les Systèmes d’Information cliniques/de recherche clinique
Analyser la faisabilité d’un essai cliniqueFaciliter la participation des patients
Seulement 7% des patients éligibles étaient recrutésLe patients ne sont pas recrutés à temps dans 86%
des essais cliniquesLes femmes, les minorités, les enfants sont sous
représentésFaciliter la collecte des données
DPI contiennent 30% to 50% des données collectées lors des essais cliniques
Améliorer le signalement d’évènements indésirables d’origine médicamenteuse
78
Kahn, Michael G. MD, PhD; Kaplan, David MD. Implementing Translational Research Policies in Electronic Medical Records. Academic Medicine. 82(7):661-669, July 2007.
Draft version 0.1, March 3, 2006;The eClinical Forum and PhaRMA EDC. The Future Vision of Electronic Health Records as eSource for Clinical Research
“Standardiser les standards”
79
HL7
CDISC
CDISC (Clinical Data Interchange Standards Consortium)
80
Organisation internationale créée en 1997 liée à l’ISO TC 215accord avec HL7 depuis
2001Standards de données de
la recherche clinique régulée par les agences règlementaires pour l’acquisition,
l’échange, l’archivage, la soumission de données électroniques
www.cdisc.org
80
CDISC ODM (Operational data Model)
81
Structure standard d’acquisition, d’échange et d’archivage de données de recherche clinique au sein de bases de données opérationnelles
Quatre niveaux principaux : étude, méta données, données administratives, et données à archiver
SubjectData
StudyEventData
FormData
ItemGroupData
ItemData
StudyEventDef
FormDef
ItemGroupDef
ItemDef
CodeListDef
Meta données
Données
1:N
N:M
MeasurementUnit
RangeCheck
Protocol
AuditRecordAuditRecord
AuditRecordAuditRecord
AuditRecordAuditRecord
AuditRecordAuditRecord
AuditRecordAuditRecord
eCRF généré automatiquement à partir du fichier CDISC ODM
82
Groupe d‘itemsItemsFormulaires
Visites=Events
CDISC ODM : structureEx: Pression artérielle systolique
Item definition including CDASH normalized data structures<ItemDef DataType="integer" Length="3" Name="PA systolique" OID="ID.PA_SYSTOLIQUE"> <Question>
<TranslatedText xml:lang="fr">Pression Artérielle Systolique</TranslatedText>
</Question> <MeasurementUnitRef MeasurementUnitOID="MU.MMHG" /> <Alias Context="CDASH" Name=“VS.VSORRES (where
VS.VSTEST=systolic blood pressure)" /> </ItemDef>
Item group definition & item references<ItemGroupDef Name="Bilan commun" OID="IG.BILAN_COMMUN" Repeating="No"> <Description>
<TranslatedText xml:lang="fr">Bilan commun </TranslatedText> </Description> <ItemRef ItemOID="ID.POIDS" Mandatory="Yes" /> <ItemRef ItemOID="ID.TAILLE" Mandatory="Yes" /> <ItemRef ItemOID="ID.PA_SYSTOLIQUE" Mandatory="Yes" /> </ItemGroupDef>
8383
CDISC ODM – VocabulaireClinical Data Acquisition Standards Harmonization (CDASH)Conçu pour standardiser les variables dans un
certain nombre de domaines transversaux aux étudesCDASH Domain
Variable Name Definition
Demography BRTHYR/BRTHMO Year/Month of subject’s birthSEX
Medical History
MHTERM Medical condition or event. CMTRT Drug nameCMSTDTC Date when the medication was first taken.
Substance UseSUTRT The type of substance (e.g., TOBACCO, ALCOHOL, CAFFEINE, etc. Or CIGARETTES, CIGARS, COFFEE, etc.).
VSORRES Result of the vital signs measurement as originally received or collected.
VSORRESU Original units in which the data were collected. Lab Test Results
LBDTC Date of sample collection. LBORRES Result of the measurement or findingLBORRESU Units in which the data were collectedLBTEST Test or examination used to obtain the measurement or
finding. ECG Test Results
LBDTC Date of sample collection. EGORRES Result of the measurement or finding aEGTEST Test or examination used to obtain the measurement or
finding.
84
“Standardiser les standards”
85
HL7 RCRIMBRIDG model
IHE QRPH Quality,
Research, and Public Health
HL7
CDISC
“Standardiser les standards”N
ivea
u d
’Ab
stra
ctio
n
RIM
Modèles spécifiques
ODM
HL7(UML)
CDISC
Modèles spécifiquesHL7 CDA
86
“Standardiser les standards”
87
SHARE : bibliothèque de variables SI cliniques/de recheche clinique
Niv
eau
d’A
bst
ract
ion
RIM
Modèles spécifiques recherche clinique
HL7(UML)
CDISC
Modèles spécifiquesHL7 CDA
BRIDG
ODM
Réutilisation des données cliniquesApproche “Source unique” (RE-USE - A.Elfadly)
Recherche clinique (CDISC)
CRO n°1
Soin (HL7)
Hopital n°1
Template source
Document Repository
Template Consumer
Document Source
(1) Recherche de template
(meta données)CDISC ODM file
(3) Echange/partage de document
(meta données + données)CDISC ODM
(2)
El Fadly N, Lucas N, Lastic P-Y, Verplancke P, Daniel C.The REUSE project: EHR as single datasource for biomedical research. Medinfo. 2010.
88
Synchronisation des variables (recherche clinique/soin) lors de l’intégration du formulaire
Processus de synchronisation (DxSync) (cadre d’intéropérabilité sémantique)
89
Capture de donnéesRéutilisation des données du DPI
90
Le pré-remplissage du formulaire repose sur les mécanismes internes du DPI
Visite
“Poids actuel” : 78 kg
90
Capture de donnéesRéutilisation des données du DPI
91
Arcadia
“Dernier poids connu” : 78 kg
Daniel - Le Bozec C, Steichen O, Dart T, Jaulent M-C. The role of local terminologies in electronic health records. The HEGP experience. Stud Health Technol Inform. 2007;129:780-4.
Export des données vers la base de données de recherche clinique
La validation des données est réalisée au sein de la base de données de recherche clinique92
Recherche clinique (CDISC)
CRO n°1
Soin (HL7)
Hospital n°1
CDMS
Perspective: de RE-USE à EHR4CR(call IMI 2009)
EHR
Hospital n°2
EHR
Hoppital n°X
EHR
RE-USEPreuve de concept
“1 hopital - 1 promotteur”
CRO n°X
93
CDMS
93
… plateforme utilisable et extensible
EHR4CR
L’interopérabilité sémantique pour la médecine translationnelle
Epidémiologie, veille sanitaire
94
Agrégation de données cliniques DebugIT (R.Choquet, D.Ouagne, A.Assele, N.Douali)
95
DebugIT (Detecting and Eliminating Bacteria UsinG Information Technology)(FP7-ICT-2007-1- « Patient Safety »)Plateforme Européenne d’informatique
translationnelle dédiée aux maladies infectieusesIntégrer des données hétérogènes distribuées au sein de
Systèmes d’Information CliniquesSurveillance de l’antibiorésistance, fouille de
données, alertes, aide à l’antibiothérapie
Schober D, Boeker M, Daniel C, Bullenkamp J. The DebugIT Core Ontology: semantic integration of antibiotics resistance patterns. Medinfo. 2010. Schulz S, Schober D, Daniel C, Jaulent MC. Bridging the semantics gap between terminologies, ontologies, and information models. Medinfo. 2010. Choquet R, Qouiyd S, Ouagne D, Pasche E, Daniel C, Boussaid O, Jaulent MC. The Information Quality Triangle: a methodology to assess Clinical Information quality. Medinfo. 2010. Ouagne D, Nadah N, Schober D, Choquet R, Teodoro D, Colaert D, Schulz S, Jaulent MC, Daniel C. Ensuring HL7-based information model requirements within an ontology framework. Medinfo. 2010.
Utiliser les ontologies et les technologies du Web sémantique pour intégrer des données de santé
96
SPARQL (SPARQL Protocol and RDF Query Language), une technologie du Web sémantique permettant d’interroger des bases de données dont les données sont vues comme des triplets RDF (Resource
Description Framework) e.g “Quel était le pourcentage d’isolats d’E.Coli
resistants au TMP/SMX en 2008”?
Utiliser les ontologies pour intégrer des données de santé
Ontologies de
domaine
Ontologie d’objets d’information HL7CDR
97
Pourcentage d’isolats d’E.Coli
resistants aux fluoroquinolones en 2008 ?
OflocetPeflacine
Fluoroquinolones
Ingénierie des modèles OMDF (D.Ougane)
Niv
eau
d’A
bst
ract
ion
RIM
Méta modèle
Ontologies spécifiques d’objets d’information
Ontologie du RIM
HL7(UML)
Ontologies(OWL)
Modèles spécifiques (e.g
laboratoire, prescription médicamenteuse)
98
Résultats : Antibioresistance d’E.coli / fluoroquinolones (2008)
99
Conclusion
100
L’intéropérabilité sémantique en santé est un enjeuDes solutions existent qui ont déjà apporté des résultats
Cap de Bonne Espérance, Medinfo 2010
Merci pour votre attention !
PathLex
Terminologie d’interface multilingue dans le domaine de l’anatomie pathologique
“Une étoile filante dans la galaxie SNOMED”
PathLex -> SNOMED CT
Grammaire compositionnelle permettant le codage d’expressions complexeE.g : 83152002|oophorectomy|260686004|
method|=25820006|laser excision – action|,363704007|procedure site|=20837000|structure of right ovary|
PathLex : Uniformisation des jeux de valeurs (LexWiki)
UV
US FR
SP IT
OID NameCDASH Alias Name Codelist Domain CDASH Core SDTM
Common_1_2010-03-10 Sponsor SPONSOR Common Optional -
Description: A unique identifier for a study sponsor. An individual, company, institution, or organization that takes responsibility for the initiation and management of a clinical trial, although may or may not be the main funding organization. If there is also a secondary sponsor, this entity would be considered the primary sponsor. A corporation or agency whose employees conduct the investigation is considered a sponsor and the employees are considered investigators.
Question: Sponsor
Completion instructions: Not applicable
Info. for Sponsors: This is typically pre-printed. May be used as an identifier in external data warehouses (e.g. Janus) and in electronic medical records or other partnerships for sharing data.
Not an SDTM variable.
Common_2_2010-03-10 Protocol/Study STUDYID Common Highly Recommended STUDYID
Description: Unique identifier for a study.
Question: Protocol/Study
Completion instructions: Not applicable.
Info. for Sponsors: This is typically pre-printed/pre-populated.
Common_4_2010-03-10 Subject SUBJID Common Highly Recommended SUBJID
Description: Subject identifier for the study.
Question: Subject
Completion instructions: Record the identifier for the subject.
Info. for Sponsors: Paper: This is typically recorded in the header of each CRF page.EDC: The subject identifiers may be provided to the site using a pre-populated list in the system.
CDASH > Présentation
OID NameCDASH Alias Name Codelist Domain CDASH Core SDTM
Common_1_2010-03-10 Sponsor SPONSOR Common Optional -
Description: A unique identifier for a study sponsor. An individual, company, institution, or organization that takes responsibility for the initiation and management of a clinical trial, although may or may not be the main funding organization. If there is also a secondary sponsor, this entity would be considered the primary sponsor. A corporation or agency whose employees conduct the investigation is considered a sponsor and the employees are considered investigators.
Question: Sponsor
Completion instructions: Not applicable
Info. for Sponsors: This is typically pre-printed. May be used as an identifier in external data warehouses (e.g. Janus) and in electronic medical records or other partnerships for sharing data.
Not an SDTM variable.
Common_2_2010-03-10 Protocol/Study STUDYID Common Highly Recommended STUDYID
Description: Unique identifier for a study.
Question: Protocol/Study
Completion instructions: Not applicable.
Info. for Sponsors: This is typically pre-printed/pre-populated.
Common_4_2010-03-10 Subject SUBJID Common Highly Recommended SUBJID
Description: Subject identifier for the study.
Question: Subject
Completion instructions: Record the identifier for the subject.
Info. for Sponsors: Paper: This is typically recorded in the header of each CRF page.EDC: The subject identifiers may be provided to the site using a pre-populated list in the system.
ODM ItemDef
CDASH > Présentation
OID NameCDASH Alias Name Codelist Domain CDASH Core SDTM
Common_1_2010-03-10 Sponsor SPONSOR Common Optional -
Description: A unique identifier for a study sponsor. An individual, company, institution, or organization that takes responsibility for the initiation and management of a clinical trial, although may or may not be the main funding organization. If there is also a secondary sponsor, this entity would be considered the primary sponsor. A corporation or agency whose employees conduct the investigation is considered a sponsor and the employees are considered investigators.
Question: Sponsor
Completion instructions: Not applicable
Info. for Sponsors: This is typically pre-printed. May be used as an identifier in external data warehouses (e.g. Janus) and in electronic medical records or other partnerships for sharing data.
Not an SDTM variable.
Common_2_2010-03-10 Protocol/Study STUDYID Common Highly Recommended STUDYID
Description: Unique identifier for a study.
Question: Protocol/Study
Completion instructions: Not applicable.
Info. for Sponsors: This is typically pre-printed/pre-populated.
Common_4_2010-03-10 Subject SUBJID Common Highly Recommended SUBJID
Description: Subject identifier for the study.
Question: Subject
Completion instructions: Record the identifier for the subject.
Info. for Sponsors: Paper: This is typically recorded in the header of each CRF page.EDC: The subject identifiers may be provided to the site using a pre-populated list in the system.
CRF / e-CRF
CDASH > PrésentationODM ItemDef
<ItemDef DataType="partialDate" Name="Birthday" OID="ID.BIRTHYEAR"><Description>
<TranslatedText xml:lang="fr">Annee de naissance
</TranslatedText></Description><Question>
<TranslatedText xml:lang="fr">Annee de naissance
</TranslatedText></Question><Alias Context="CDASH" Name="BRTHYR" />
</ItemDef>
CDISC > CDASH dans le fichier ODM
<ItemDef DataType="partialDate" Name="Birthday" OID="ID.BIRTHYEAR"><Description>
<TranslatedText xml:lang="fr">Annee de naissance
</TranslatedText></Description><Question>
<TranslatedText xml:lang="fr">Annee de naissance
</TranslatedText></Question><Alias Context="CDASH" Name="BRTHYR" />
</ItemDef>
CDISC > CDASH dans le fichier ODM
<ItemDef DataType="partialDate" Name="Birthday" OID="ID.BIRTHYEAR"><Description>
<TranslatedText xml:lang="fr">Annee de naissance
</TranslatedText></Description><Question>
<TranslatedText xml:lang="fr">Annee de naissance
</TranslatedText></Question><Alias Context="CDASH" Name="BRTHYR" />
</ItemDef>
Identifiant de la variable dans le fichier ODM
Ne doit pas obligatoirement provenir de CDASH (préfixe ID. par exemple)
CDISC > CDASH dans le fichier ODM
OID NameCDASH Alias Name Codelist Domain CDASH Core SDTM
Common_1_2010-03-10 Sponsor SPONSOR Common Optional -
Description: A unique identifier for a study sponsor. An individual, company, institution, or organization that takes responsibility for the initiation and management of a clinical trial, although may or may not be the main funding organization. If there is also a secondary sponsor, this entity would be considered the primary sponsor. A corporation or agency whose employees conduct the investigation is considered a sponsor and the employees are considered investigators.
Question: Sponsor
Completion instructions: Not applicable
Info. for Sponsors: This is typically pre-printed. May be used as an identifier in external data warehouses (e.g. Janus) and in electronic medical records or other partnerships for sharing data.
Not an SDTM variable.
Common_2_2010-03-10 Protocol/Study STUDYID Common Highly Recommended STUDYID
Description: Unique identifier for a study.
Question: Protocol/Study
Completion instructions: Not applicable.
Info. for Sponsors: This is typically pre-printed/pre-populated.
Common_4_2010-03-10 Subject SUBJID Common Highly Recommended SUBJID
Description: Subject identifier for the study.
Question: Subject
Completion instructions: Record the identifier for the subject.
Info. for Sponsors: Paper: This is typically recorded in the header of each CRF page.EDC: The subject identifiers may be provided to the site using a pre-populated list in the system.
Niveau de recommandation de la variable dans le CRF
CDASH > Présentation
OID NameCDASH Alias Name Codelist Domain CDASH Core SDTM
Common_1_2010-03-10 Sponsor SPONSOR Common Optional -
Description: A unique identifier for a study sponsor. An individual, company, institution, or organization that takes responsibility for the initiation and management of a clinical trial, although may or may not be the main funding organization. If there is also a secondary sponsor, this entity would be considered the primary sponsor. A corporation or agency whose employees conduct the investigation is considered a sponsor and the employees are considered investigators.
Question: Sponsor
Completion instructions: Not applicable
Info. for Sponsors: This is typically pre-printed. May be used as an identifier in external data warehouses (e.g. Janus) and in electronic medical records or other partnerships for sharing data.
Not an SDTM variable.
Common_2_2010-03-10 Protocol/Study STUDYID Common Highly Recommended STUDYID
Description: Unique identifier for a study.
Question: Protocol/Study
Completion instructions: Not applicable.
Info. for Sponsors: This is typically pre-printed/pre-populated.
Common_4_2010-03-10 Subject SUBJID Common Highly Recommended SUBJID
Description: Subject identifier for the study.
Question: Subject
Completion instructions: Record the identifier for the subject.
Info. for Sponsors: Paper: This is typically recorded in the header of each CRF page.EDC: The subject identifiers may be provided to the site using a pre-populated list in the system.
CDASH > Présentation
OID NameCDASH Alias Name Codelist Domain CDASH Core SDTM
Common_1_2010-03-10 Sponsor SPONSOR Common Optional -
Description: A unique identifier for a study sponsor. An individual, company, institution, or organization that takes responsibility for the initiation and management of a clinical trial, although may or may not be the main funding organization. If there is also a secondary sponsor, this entity would be considered the primary sponsor. A corporation or agency whose employees conduct the investigation is considered a sponsor and the employees are considered investigators.
Question: Sponsor
Completion instructions: Not applicable
Info. for Sponsors: This is typically pre-printed. May be used as an identifier in external data warehouses (e.g. Janus) and in electronic medical records or other partnerships for sharing data.
Not an SDTM variable.
Common_2_2010-03-10 Protocol/Study STUDYID Common Highly Recommended STUDYID
Description: Unique identifier for a study.
Question: Protocol/Study
Completion instructions: Not applicable.
Info. for Sponsors: This is typically pre-printed/pre-populated.
Common_4_2010-03-10 Subject SUBJID Common Highly Recommended SUBJID
Description: Subject identifier for the study.
Question: Subject
Completion instructions: Record the identifier for the subject.
Info. for Sponsors: Paper: This is typically recorded in the header of each CRF page.EDC: The subject identifiers may be provided to the site using a pre-populated list in the system.
Common (Common)Adverse Events (AE)Concomitant Medication (CM)Demographics (DM)Medical History (MH)Vital Signs (VS)Substance Use (SU)ECG (EG)Lab (LB)Subject Characteristic (SC)Inclusion and Exclusion Criteria (IE)Disposition (DS)Drug Accountability (DA)Exposure (EX)Protocol Deviations (DV)Physical Examination (PE)
Domaines CDASH
CDASH > Présentation
CDASH > hiérarchisation
Dans dernière version en développement :
MHOCCUR : Medical history occured
HBP.MHOCCUR : High blood pressure (Y/N)
APPENDECTOMY.MHOCCUR : Appendectomy (Y/N)
SUNCF : Substance usage
TOBACCO.CIGARETTES.SUNCF : Usage (Never/Current/Former)
TOBACCO.CIGARS.SUNCF : Usage (Never/Current/Former)Précision de la variable par un préfixe, quelques cas prévus
Probablement à entendre avec d’autres vocabulaires contrôlés
Collaboration
HL7 établit des collaboration avec les organismes de standardisation internationaux d’informatique de santé et de recherche clinique (ISO, CEN, OMG, CDISC)Eviter les efforts redondants
CDISC (Clinical Data Interchange Standards Consortium)Collaboration depuis 2002Comité technique RCRIMDéveloppement du modèle BRIDG modèle de
domaine “Protocol-driven research and associated regulatory artifacts”
Réutilisation des données cliniquesApproche 1 : Extraction de donnéesIHE “Retrieve Form for Data Capture (RFD)” - Content profile “Clinical Research data Capture”
115
Serveur de formulaires
Affichage de
formulaires
Rechercher et pré-remplir un
formulaire
CDMSEHR
Réutilisation des données cliniquesApproche 1 : Extraction de donnéesPré-remplissage du formulaire de recherche clinique à partir des données cliniques
Une fois rempli le formulaire de recherche clinique est stocké sous forme de document (pdf) dans le Dossier Patient Informatisé.
Content profile “Clinical Research data Capture” Règles d’alignementHL7 CDA r2 <-> CDASH
Clinical Research Data Capture Data Elements
CDISC CDASH Domains HL7 CCD Reference
Demography CCD Header Information
Medical History Active Problems, Past Medical History, and Procedures and Interventions
Concommitant Medication Current Medications
Substance Use Social History
Vital Signs Vital Signs
Physical Exam Physical Exam
Adverse Events Allergies
Lab Test Results Coded Results
ECG Test Results Coded Results
117
118
BRIDG (Biomedical Research Integrated Domain Group)
HL7 s’intéresse aux modèles statiques et dynamiques en relation avec les processusLe protocole de spécification des messages ou documents
HL7 exige une correspondance avec les activités des acteurs et les « interactions » définies entre ces acteurs
Les modèles doivent avoir une sémantique communeCDISC s’intéresse (actuellement) aux modèles
statiques Spécification des messages échangés entre les
applicationsObjectifs de BRIDG
Un modèle formel comportant des modèles statiques et dynamiques
Une sémantique commune
Source: Douglas B. Fridsma, Julie Evans, Charles N. Mead
119
Historique de BRIDG
Début 2004, CDISC Modèle d'analyse de domaine pour garantir
l'harmonisation des standards de recherche clinique avec les standards HL7 de soin
Fin 2004, NCI’s «Cancer Biomedical Informatics Grid (caBIG ™) Représentation structurée des protocoles pour les
systèmes de gestion des essais cliniques en cancérologieEn 2005, HL7 «Regulated Clinical Research
Information Management (RCRIM TC)Adoption du modèle BRIDG afin de produire un modèle
d’analyse de domaine En 2007, FDA
BRIDG intégré à plusieurs projets du plan d’action à 5 ans
Source: Douglas B. Fridsma, Julie Evans, Charles N. Mead
BRIDGSeparating Analysis from Design/Implementation
ODM
RIM / DMIM
Modèle de l’espace de problème(HL7 Development Framework)
RMIM / HMD / XSD
Niv
eau
d
’Ab
stra
ctio
n
121
Documentation du modèle BRIDG
Différents niveaux d’abstraction et d’explicitation dans de multiple sous-domaines
Explicitaion au sein d’un seul modèle basé sur le RIM (‘Analysis Model’)
Modèle du domaine compréhensible par les experts
Aligné sans ambiguité au RIM HL7
class BRIDG Sub-Domain Packages Diagram
Adv erse Event Sub-Domain
+ AdverseEvent
+ AdverseEventActionTaken
+ AdverseEventOutcomeAssessment
+ AdverseEventOutcomeResult
+ CausalAssessment
+ EvaluatedActivityRelationship
+ EvaluatedResultRelationship
+ PerformedProductInvestigation
+ PerformedProductInvestigationResult
+ PerformedProductProblemDiscovery
+ ProductActionTakenRelationship
+ SafetyReport
Common Sub-Domain
+ Activity
+ AdministrativeMemberCRA
+ AdministrativeMemberPI
+ Animal
+ AssociatedBiologicEntity
+ Biologic
+ BiologicEntity
+ BiologicEntityGroup
+ BiologicEntityIdentifier
+ BiologicEntityPart
+ CooperativeGroup
+ CooperativeGroupMember
+ Cosmetic
+ Device
+ Distributor
+ Document
+ DocumentAuthor
+ DocumentIdentifier
+ DocumentReceiver
+ DocumentRelationship
+ DocumentWorkflowStatus
+ Drug
+ ExperimentalUnit
+ FoodProduct
+ HealthcareFacility
+ HealthcareProvider
+ HealthcareProviderGroup
+ HealthcareProviderGroupMember
+ Manufacturer
+ ManufacturingSite
+ Material
+ Organization
+ OrganizationalContact
+ OrganizationPart
+ OversightCommittee
+ Package
+ Performer
+ Person
+ Place
+ Product
+ ProductGroup
+ ProductPart
+ QualifiedPerson
+ Report
+ ResearchOrganization
+ ResearchStaf f
+ ResourceProvider
+ StudyRegistry
+ StudySubject
+ StudySubjectIdentifier
+ Subject
+ TreatingSite
Protocol Representation Sub-Domain
+ DefinedSubjectActivityGroup
+ Arm
+ DefinedActivity
+ DefinedAdministrativeActivity
+ DefinedCompositionRelationship
+ DefinedContingentOnRelationship
+ DefinedCriterionGroup
+ DefinedCriterionGroupCompositionRelationship
+ DefinedCriterionGroupOptionRelationship
+ DefinedEligibilityCriterion
+ DefinedExclusionCriterion
+ DefinedExperimentalUnitAllocation
+ DefinedImaging
+ DefinedInclusionCriterion
+ DefinedObservation
+ DefinedObservationResult
+ DefinedOptionRelationship
+ DefinedProcedure
+ DefinedRepeatActivityUntilRule
+ DefinedSpecimenCollection
+ DefinedSpecimenStorage
+ DefinedStratificationCriterion
+ DefinedStratificationCriterionPermissibleResult
+ DefinedStudyAdministrativeActivity
+ DefinedStudyAgentTransfer
+ DefinedStudySubjectMilestone
+ DefinedSubstanceAdministration
+ Epoch
+ ExpandedAccessStudy
+ Funding
+ GovernmentFunding
+ InterventionalStudy
+ MaterialResource
+ ObservationalStudy
+ PlannedActivity
+ PlannedCompositionRelationship
+ PlannedContingentOnRelationship
+ PlannedCriterionGroup
+ PlannedCriterionGroupCompositionRelationship
+ PlannedCriterionGroupOptionRelationship
+ PlannedOptionRelationship
+ PlannedRandomizationBookAllocation
+ PlannedRepeatActivityUntilRule
+ RandomizationBookEntry
+ ReferenceToStudyResults
+ RegistrationCenter
+ Resource
+ Service
+ StratumGroup
+ Study
+ StudyActivity
+ StudyAgent
+ StudyColleague
+ StudyInvestigator
+ StudyLegalSponsor
+ StudyObjective
+ StudyOutcomeMeasure
+ StudyOversightAuthority
+ StudyProtocolDocument
+ StudyReference
+ StudyResource
Regulatory Sub-Domain
+ OversightAuthority
+ RegulatoryApplication
+ RegulatoryApplicationSponsor
+ RegulatoryAssessment
+ RegulatoryAuthority
+ ReviewableUnit
+ Submission
+ SubmissionUnit
Study Conduct Sub-Domain
+ AssessedResultRelationship
+ Assessor
+ BiologicSpecimen
+ CollectingLaboratory
+ ConcomitantAgent
+ Laboratory
+ PerformedActivity
+ PerformedAdministrativeActivity
+ PerformedClinicalInterpretation
+ PerformedClinicalResult
+ PerformedDiagnosis
+ PerformedEligibilityCriterion
+ PerformedExclusionCriterion
+ PerformedHistopathology
+ PerformedImaging
+ PerformedInclusionCriterion
+ PerformedLesionDescription
+ PerformedMedicalHistoryResult
+ PerformedObservation
+ PerformedObservationResult
+ PerformedProcedure
+ PerformedProtocolDeviation
+ PerformedSpecimenCollection
+ PerformedStudyAdministrativeActivity
+ PerformedStudyAgentTransfer
+ PerformedStudySubjectMilestone
+ PerformedSubstanceAdministration
+ PerformingLaboratory
+ ReferenceResult
+ ScheduledActivity
+ StudyOverallStatus
+ StudyRecruitmentStatus
+ StudyResearchCoordinator
+ StudySite
+ StudySiteContact
+ StudySiteInvestigator
+ StudySiteOversightStatus
+ StudySiteResearchCoordinator
Name:Package:Version:Author:
BRIDG Sub-Domain Packages DiagramBRIDG Domain Analysis Model3.0BRIDG SCC
Adverse EventRegulatoryCommonProtocol RepresentationStudy Conduct
BRIDG 3.0 Sub domains
AdverseEvent sub domain
Type: public Class {leaf}Extends: PerformedObservationResult.
Package: Adverse Event Sub-DomainAny unfavorable and unintended sign,
symptom, disease, or other medical occurrence with a temporal association with the use of a medical product, procedure or other therapy, or in conjunction with a research study, regardless of causal relationship.
For example, death, back pain, headache, pulmonary embolism, heart attack.
AdverseEvent AttributesAttribute Type Notes
gradeCode public :CD
A coded value specifying the level of injury suffered by the subject for whom the event is reported. For example, the gradeCode could be 3 if the CTCAE coding system is being used.
Map:AE = 'AdverseEvent.gradeOrSeverity'Map:CTOM = 'AdverseEvent.ctcGradeCode'Map:CTOM = 'AdverseEvent.ctcGradeCodeSystem'Map:SDTM IG = 'AE.AETOXGR'
severityCode public :CD
A coded value specifying the intensity of the event.For example, moderate could be used to describe acne.
Map:AE = 'AdverseEvent.gradeOrSeverity'Map:SDTM IG = 'AE.AESEV'
seriousnessCode public :CD
A coded value specifying the degree or extent of the consequence suffered by the subject. For example, resulted in death, required hospitalization, was life threatening.
Map:AE = 'AdverseEvent.seriousnessCode'Map:CTOM = 'AdverseEvent.seriousReasonCode'Map:SDTM IG = 'AE.AESER'Map:SDTM IG = 'AE.AESHOSP'
AdverseEvent Attributes (suite)
Attribute Type Notes
categoryCode public :CD
A coded value specifying a classification of the adverse event.For example, bleeding, hypoglycemia.NOTE: Theoretically speaking, the category should be derivable from the subcategory, however if there may only be a category and not a subcategory, then both attributes must be present in the model.
Map:SDTM IG = 'AE.AECAT'
subcategoryCode
public :CD
A coded value specifying a subdivision within a larger category of an adverse event.For example, neurologic.NOTE: Theoretically speaking, the category should be derivable from the subcategory, however if there may only be a category and not a subcategory, then both attributes must be present in the model.
Map:SDTM IG = 'AE.AESCAT'
occurrencePatternCode
public :CD
A coded value specifying the time recurrence by which an adverse event occurs. For example, intermittent.
Map:AE = 'AdverseEvent.patternCode'Map:CTOM = 'AdverseEvent.conditionPatternCode'Map:SDTM IG = 'AE.AEPATT'
AdverseEvent Attributes
PerformedObservation
Type: public Class {leaf}Extends: PerformedActivity.
The completed action of observing, monitoring, measuring or otherwise qualitatively or quantitatively gathering data or information about one or more aspects of a subject's, study subject's or experimental unit's physiologic or psychologic state.
For example, lab test, taking vital signs, physical exam, etc.
PerformedObservation Attributes
Attribute Type Notes
methodCode public :DSET<CD>
A coded value specifying the technique used to perform the observation.For example, blood pressure measurement method could be arterial puncture or sphygmomanometry.For example, global introspection, algorithm, bayesian to assess AE causality.For example for a clinical result assay method, values could include: Estrogen Receptor Assay, Progesterone Receptor Assay, p53 Assay, etc.
Map:AE = 'PerformedProductInvestigation.evaluationMethodCode'Map:AE = 'CausalAssessment.methodCode'Map:CTOM = 'ClinicalResult.meansVitalStatusObtainedCode'Map:CTOM = 'ClinicalResult.assayMethodCode'Map:CTOM = 'ClinicalResult.labTechniqueCode'Map:CTOM = 'LesionDescription.methodCode'
bodyPositionCode
public :CD
A coded value specifying the 3-dimensional spatial orientation of a subject during a particular observation.For example, supine, trendelenburg, standing, etc.
AE:Exclude = 'True'Map:CTOM = 'ClinicalResult.bodyPositionCode'Map:PSC = 'VS.VSPOS'Map:SDTM IG = 'EG.EGPOS'
targetAnatomicSiteCode
public :CD
A coded value specifying the anatomic location that is the focus of the observation.For example, gastrointestinal, cardiovascular. NOTE: The target site of the result may be different than the target site of the activity (PerformedObservation) that generated it. For example, a chest x-ray (observation) has the target site of chest while the result might show an infiltration in the left lower lobe of the lung (target site of result), or a dermatological exam may check the skin across the whole body (target site of observation) while the result might identify a rash on the right leg (target site of result).
Map:AE = 'AdverseEvent.bodyLocation'Map:CTOM = 'Diagnosis.primaryAnatomicSiteCodeSystem'Map:CTOM = 'Imaging.anatomicSiteCodeSystem'Map:CTOM = 'Imaging.anatomicSiteCode'Map:CTOM = 'Diagnosis.primaryAnatomicSiteCode'
PerformedObservation Attributes (suite)
Attribute TypeNotes
targetAnatomicSiteLateralityCode
public :CD
A coded value specifying the side of the body (or a paired organ) that is a target site for a procedure. For example, Bilateral, Left, Right.
Map:AE = 'AdverseEvent.bodyLocation'Map:CTOM = 'Diagnosis.primaryAnatomicSiteLateralityCode'
focalDuration public :PQ.TIME
The quantity of time in which the observation result is held to be true.For example, 2 months is the evaluation interval for a question such as "Have you smoked in the last 2 months?".NOTE: The focalDuration can be derived using the focalDateRange.
AE:Exclude = 'True'Map:CTOM = 'DiseaseResponse.progressionPeriodUnitOfMeasureCode'Map:CTOM = 'DiseaseResponse.progressionPeriod'Map:SDTM IG = 'QS.QSEVLINT'
focalDateRange public :IVL<TS.DATETIME>
The time period in which the observation result is held to be true.NOTE: The focalDateRange can be derived from DefinedObservation.focalDateRange alone (i.e., directly from simple date ranges like 1990-1999) or from evaluating the expression in DefinedObservation.focalDateRange (which references a date that is now known).
AE:Exclude = 'True'Map:CTOM = 'DiseaseResponse.progressionDate'Map:CTOM = 'Diagnosis.confirmationDate'
Représentation OWL de BRIDG
Domaine d’intérêt
Conceptualisation visuelle
(DAM UML )
Representation ontologique
(OWL-DL)
Form
alis
atio
n
Est décrit par
Fourni des information
pour
Une définition OWL-DL est préferable à un ensemble de classes UMLUn diagramme UML est préferable à une centaine de recommandations dans un documen word
ConclusionBRIDG, un des piliers de l'interopérabilité Modèle UML de données global pour tous les
domaines d'intérêtBase de types de données rigoureusement définisMéthodologie pour interagir avec des domaines de
vocabulaires contrôlés prédéfinisMéthode formelle de développement de
standardsMéthode de conception orientée objet Outils de dérivation et test de conformité
131