Votre modèle de données pour le parcours patient
Votre modèle de données pour le parcours patient
- Attributs cliniques recommandés
- Jalons essentiels du processus
- Recommandations pour l’extraction depuis MEDITECH
Attributs du parcours patient
| Nom | Description | ||
|---|---|---|---|
| Dernière mise à jour des données LastDataUpdate | Horodatage de la dernière extraction ou actualisation des données. | ||
| Description Indique la dernière date de traitement de l’enregistrement ou de son chargement dans l’outil de Process Mining. Cet attribut permet de vérifier la fraîcheur des données et de s’assurer que l’analyse reflète l’état le plus récent du système. Il se distingue de l’horodatage de l’événement, car il correspond au moment du traitement technique des données et non à celui de l’événement clinique. Pourquoi est-ce important ? Essentiel à la gouvernance des données et à la réalisation d’analyses à partir de données à jour. Où trouver ces données Date système au moment de l’exécution de l’ETL. Exemples 2023-11-01T00:00:00Z2023-11-02T12:00:00Z | |||
| Épisode de soins PatientEpisode | Identifiant unique d’une période de soins ou d’une visite donnée. | ||
| Description L’épisode de soins sert d’identifiant central pour l’analyse du processus. Il regroupe en un même parcours cohérent tous les événements cliniques, administratifs et financiers liés à un séjour hospitalier ou à une visite ambulatoire. Dans MEDITECH, il correspond souvent au numéro de compte ou à l’identifiant de visite. Cet attribut est essentiel pour reconstituer le parcours du patient, de son enregistrement à sa sortie, calculer la durée de séjour et analyser les parcours cliniques. Pourquoi est-ce important ? Il s’agit de la clé de cas obligatoire qui permet de relier des événements distincts au sein d’une même instance de processus. Où trouver ces données Module Admissions ou Registration de MEDITECH, généralement le champ Account Number. Exemples V100938475AC29384755E993847211O229384711 | |||
| Horodatage de l’événement EventTimestamp | Date et heure précises auxquelles l’activité a eu lieu. | ||
| Description Cet attribut consigne le moment exact où une activité s’est déroulée. Il sert à ordonner les événements chronologiquement et à calculer les durées entre les étapes du processus. Des horodatages précis sont nécessaires pour analyser correctement les temps d’attente, par exemple entre le triage et l’évaluation, ou le délai de traitement des résultats diagnostiques. Pourquoi est-ce important ? Nécessaire pour ordonner les événements et calculer les temps de cycle et le débit. Où trouver ces données Colonnes de date et d’heure des transactions dans les tables sources. Exemples 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:45:00Z | |||
| Nom de l’activité ActivityName | Action clinique ou administrative réalisée. | ||
| Description Cet attribut désigne le nom de l’événement ou de la tâche qui intervient dans le parcours du patient. Il décrit les différentes étapes, comme « Patient enregistré », « Médicament administré » ou « Prescription de sortie rédigée ». L’identification correcte des activités est indispensable pour cartographier le flux du processus. Ces valeurs proviennent souvent des codes de transaction, des statuts de prescription ou des interventions consignées dans le dossier médical électronique. Pourquoi est-ce important ? Définit les étapes du processus et est nécessaire pour visualiser la cartographie du processus. Où trouver ces données Dérivé de différents journaux de transactions (prescriptions OE, interventions NUR, événements ADM). Exemples Patient enregistréTriage terminéMédicament administréRésultat diagnostique vérifié | |||
| Système source SourceSystem | Identifiant du système d’origine des données. | ||
| Description Identifie l’instance MEDITECH ou le module précis dont les données d’événement ont été extraites. Dans les environnements regroupant plusieurs hôpitaux, cet attribut permet de distinguer les données provenant de différents établissements ou de différentes versions du système. Cet attribut reste fixe lors d’une extraction depuis un système unique, mais il est essentiel pour fusionner des données et obtenir une vue unifiée du réseau hospitalier. Pourquoi est-ce important ? Assure la traçabilité et le suivi de l’origine des données dans les environnements multisystèmes. Où trouver ces données Renseigné en dur lors de l’extraction ou de la configuration de l’identifiant système. Exemples MEDITECH_ExpanseMEDITECH_6.1Hospital_A_Main | |||
| Destination à la sortie DischargeDisposition | Destination ou statut du patient à sa sortie. | ||
| Description Indique où le patient est allé après l’épisode, par exemple à son domicile, dans un établissement de soins infirmiers qualifiés ou dans un service de soins à domicile, ou s’il est décédé. Il s’agit d’un indicateur de résultat important pour le Dashboard « Optimisation de la planification de la sortie ». Son analyse permet de déterminer si les retards dans l’organisation des soins post-aigus prolongent la durée du séjour. Pourquoi est-ce important ? Indicateur de résultat important pour analyser la durée du séjour et le risque de réadmission. Où trouver ces données Écrans de synthèse de sortie ou d’inscription. Exemples Sortie au domicileTransfert vers un hôpital général de court séjourDécèsSortie contre avis médical | |||
| Diagnostic principal PrimaryDiagnosis | Principale affection médicale identifiée pour l’épisode du patient. | ||
| Description Contient le code CIM-10 ou la description du motif principal de la consultation. Cet attribut est au cœur de l’« Analyse des variantes du parcours clinique ». En regroupant les cas par diagnostic principal, les responsables cliniques peuvent comparer les parcours de soins réellement suivis au parcours clinique de référence pour l’affection concernée. Pourquoi est-ce important ? Essentiel pour regrouper les cas et analyser les parcours cliniques. Où trouver ces données Module Medical Records ou Abstracting. Exemples J18.9 - PneumonieI21.9 - Infarctus aigu du myocardeS72.0 - Fracture du fémur | |||
| Niveau de gravité au triage TriageAcuityLevel | Niveau de gravité attribué au patient lors du triage. | ||
| Description Indique le degré d’urgence de l’état du patient, généralement sur une échelle (par exemple de 1 à 5, où 1 correspond à un état critique). Cet attribut est au cœur de l’« Analyse du parcours aux urgences ». Il permet aux analystes de mettre en relation les temps d’attente et la gravité de l’état des patients, afin de vérifier que les cas les plus critiques sont bien traités en priorité. Pourquoi est-ce important ? Essentiel à l’analyse des priorités aux urgences et au respect des exigences de sécurité. Où trouver ces données Écrans d’évaluation infirmière des urgences ou du triage. Exemples 1 - Réanimation2 - Urgence absolue3 - Urgent4 - Moins urgent | |||
| Numéro de dossier médical MedicalRecordNumber | Identifiant unique du patient pour l’ensemble de ses visites. | ||
| Description Le numéro de dossier médical (MRN) identifie chaque patient de manière unique au sein de l’établissement de santé. Il est distinct de l’identifiant propre à chaque épisode et permet aux analystes de relier plusieurs épisodes concernant un même patient au fil du temps. Cet attribut est essentiel au Dashboard « Réadmissions et qualité des soins » : il permet de repérer les patients réadmis dans les 30 jours suivant leur sortie de l’hôpital. Pourquoi est-ce important ? Permet d’analyser plusieurs épisodes et d’obtenir une vue centrée sur le patient. Où trouver ces données Index principal des patients ou table d’inscription. Exemples MRN-100293MRN-55928388291002 | |||
| Professionnel de santé responsable AttendingProvider | Clinicien ou professionnel de santé principalement responsable de l’activité. | ||
| Description Enregistre le nom ou l’identifiant du médecin, de l’infirmier ou du technicien qui réalise la tâche ou supervise les soins. Cet attribut alimente le Dashboard « Délai d’élaboration du plan de traitement » en associant les indicateurs de rapidité et d’efficacité à des membres du personnel ou à des rôles précis. Il permet d’analyser les ressources afin de mieux répartir la charge de travail et de repérer les besoins de formation du personnel clinique. Pourquoi est-ce important ? Permet d’analyser la performance des ressources et de répartir la charge de travail. Où trouver ces données Champs Provider ou User des journaux d’activité. Exemples Dr SmithInf. JonesTech. Adams | |||
| Réadmission IsReadmission | Indicateur signalant si cet épisode a eu lieu dans les 30 jours suivant une sortie précédente. | ||
| Description Attribut booléen qui renvoie la valeur true si la date d’inscription actuelle du patient se situe dans les 30 jours suivant la date de sortie d’un épisode précédent. Cet attribut alimente le Dashboard « Réadmissions et qualité des soins ». Le repérage des réadmissions permet aux analystes de revenir à l’épisode précédent pour identifier les lacunes dans la planification de la sortie ou le suivi des soins. Pourquoi est-ce important ? Indicateur de qualité essentiel, qui influe sur le remboursement et les résultats pour les patients. Où trouver ces données Calculé en comparant StartTime actuel et Case EndTime précédent pour le même MedicalRecordNumber. Exemples truefalse | |||
| Service hospitalier HospitalDepartment | Unité ou service précis où l’activité a eu lieu. | ||
| Description Identifie l’unité fonctionnelle responsable de l’activité, par exemple les urgences, la radiologie, les soins intensifs ou une unité d’hospitalisation générale. Cet attribut est essentiel au Dashboard « Débit des ressources par service ». Il permet de ventiler les indicateurs de performance par unité afin de repérer les goulots d’étranglement lors des transferts internes et dans l’utilisation des ressources. Pourquoi est-ce important ? Essentiel à l’analyse de l’organisation et au repérage des goulots d’étranglement dans certaines unités. Où trouver ces données Champs Location ou Department des tables de transactions. Exemples Service des urgencesRadiologieUnité de soins intensifsUnité de chirurgie 3 | |||
| Type de patient PatientType | Catégorie de la visite du patient, par exemple hospitalisation, consultation externe ou urgence. | ||
| Description Classe la nature de la visite à l’hôpital. Les valeurs courantes sont « Inpatient », « Outpatient », « Emergency » et « Observation ». Cette classification est fondamentale pour filtrer et comparer les processus, car les soins attendus et leur durée varient considérablement selon le type de visite. Ce champ permet de ventiler les durées de séjour attendues dans le Dashboard « Optimisation de la planification de la sortie ». Pourquoi est-ce important ? Segmentation fondamentale pour comparer les processus (hospitalisation ou consultation externe). Où trouver ces données Tables Admission ou Visit, par exemple AdmVisits.Status. Exemples HospitalisationUrgencesChirurgie ambulatoireObservation | |||
| Catégorie de commande OrderCategory | Classification des commandes cliniques, par exemple laboratoire, radiologie ou consultation. | ||
| Description Regroupe les commandes en grandes catégories, comme « Laboratoire », « Radiologie », « Diététique » ou « Consultation ». Cet attribut est essentiel au Dashboard « Délais des services diagnostiques ». Il permet de distinguer les flux de travail afin d’analyser les temps de cycle propres à l’imagerie et aux analyses sanguines, qui présentent souvent des goulots d’étranglement différents. Pourquoi est-ce important ? Segmente les flux de travail diagnostiques et thérapeutiques. Où trouver ces données Champs de catégorie du module Order Entry (OE). Exemples LaboratoireRadiologieSoins infirmiersPharmacie | |||
| Écart de conformité IsAdherenceViolation | Indicateur signalant si le cas s’est écarté du parcours clinique de référence. | ||
| Description Indicateur booléen défini sur true lorsque la séquence des activités ne correspond pas au modèle de référence établi pour le diagnostic principal du patient. Cet attribut alimente l’« Analyse des variantes du parcours clinique ». Il permet de filtrer rapidement les cas « non conformes » afin de déterminer pourquoi le protocole de soins standard n’a pas été suivi. Pourquoi est-ce important ? Repère rapidement les écarts et les variations du processus. Où trouver ces données Calculé par des algorithmes de vérification de la conformité. Exemples truefalse | |||
| Montant facturé ChargeAmount | Valeur financière associée à une activité ou à un service précis. | ||
| Description Correspond au coût ou au montant facturé pour un événement précis, comme un examen ou l’occupation d’une chambre. Bien qu’il soit principalement financier, cet attribut renseigne sur l’intensité des ressources mobilisées. Une fois agrégé, il permet d’évaluer l’incidence financière des variations du processus, même si la vue demandée porte avant tout sur le parcours clinique. Pourquoi est-ce important ? Ajoute une dimension financière à l’analyse du processus. Où trouver ces données Module Billing ou BAR (Billing/Accounts Receivable). Exemples 150.001200.5045.00 | |||
| Nom du médicament MedicationName | Nom du médicament administré. | ||
| Description Indique le médicament associé aux événements « Médicament administré ». Cet attribut est nécessaire au Dashboard « Conformité de l’administration des médicaments ». Il permet aux responsables des soins infirmiers de vérifier que les médicaments à haut risque ou à administrer à une heure précise, comme les antibiotiques contre le sepsis, sont administrés dans les délais thérapeutiques appropriés. Pourquoi est-ce important ? Nécessaire à l’analyse de la conformité clinique et de la sécurité. Où trouver ces données Modules Pharmacy (PHA) ou Bedside Verification (BMV). Exemples AcétaminophèneVancomycineHéparineInsuline | |||
| Origine de l’admission AdmitSource | Origine du patient, par exemple domicile, transfert ou orientation. | ||
| Description Décrit l’origine de l’admission du patient, par exemple « Orientation par un médecin », « Service des urgences » ou « Transfert depuis un autre hôpital ». Cet attribut précise comment les patients entrent dans le système. Il aide à comprendre les flux d’admission et leur incidence sur l’« Analyse du parcours aux urgences » et la planification des ressources. Pourquoi est-ce important ? Précise les flux d’admission des patients et les canaux de demande. Où trouver ces données Données d’inscription des admissions. Exemples Service des urgencesOrientation par une cliniqueTransfert depuis un établissement de soins infirmiers qualifiés | |||
| Temps d’attente au triage TriageWaitTime | Durée entre l’inscription et la fin du triage. | ||
| Description Durée calculée entre l’événement « Patient inscrit » et l’événement « Triage terminé ». Elle alimente directement l’indicateur clé de performance « Durée moyenne du triage ». Le suivi de cette durée aide les responsables des urgences à ajuster les effectifs pendant les périodes de forte affluence et à respecter les normes de sécurité des patients. Pourquoi est-ce important ? Indicateur opérationnel important pour les services d’urgence. Où trouver ces données Différence calculée entre les horodatages d’activités précises. Exemples 15 minutes1 heure 20 minutes | |||
Activités du parcours patient
| Activité | Description | ||
|---|---|---|---|
| Diagnostic consigné | Moment où un clinicien saisit un diagnostic codé (ICD-10) dans le dossier du patient. Cette saisie déclenche souvent des parcours cliniques spécifiques. | ||
| Pourquoi est-ce important ? Permet l’analyse des variantes de parcours cliniques en catégorisant le cas. Indispensable pour regrouper les patients à des fins de comparaison. Où trouver ces données Module ABS (Abstracting) ou Medical Records de MEDITECH. Données enregistrées lorsque les codes de diagnostic sont associés au compte. Données à recueillir Consigné lors de l’exécution de la transaction Diagnosis Enter Type d’événement explicit | |||
| Médicament administré | Consigne l’administration effective d’un médicament au patient par le personnel infirmier. L’événement est généralement enregistré par lecture du code-barres au chevet du patient. | ||
| Pourquoi est-ce important ? Contribue au suivi de la conformité à l’administration des médicaments. Permet de repérer les risques pour la sécurité et les interruptions des flux de travail dans les unités de soins infirmiers. Où trouver ces données Module PHA (Pharmacy) ou eMAR (Electronic Medication Administration Record) de MEDITECH. Champ « AdminDateTime » de l’historique d’administration. Données à recueillir Consigné lors de l’exécution de la transaction Med Admin Type d’événement explicit | |||
| Patient enregistré | Cet événement correspond à la création administrative du dossier de l’épisode de soins ou de la visite dans le système. Il marque le premier point d’entrée dans le module ADM (Admissions) de MEDITECH. | ||
| Pourquoi est-ce important ? Définit le début du parcours du patient et sert au calcul du temps de cycle. Indispensable au calcul de la durée totale de séjour. Où trouver ces données Module ADM de MEDITECH. Source : table « Admissions », en particulier le champ « AdmitDateTime » ou l’horodatage de création du journal de transactions. Données à recueillir Consigné lors de l’exécution de la transaction New Visit Type d’événement explicit | |||
| Patient sorti | Clôture administrative de la visite. Le patient a quitté l’établissement et le lit est libéré. | ||
| Pourquoi est-ce important ? Fin officielle du processus. Sert à calculer la durée finale du séjour et à définir la période de réadmission de 30 jours. Où trouver ces données Module ADM (Admissions) de MEDITECH. Champ « DischargeDateTime » du dossier de visite. Données à recueillir Consigné lors de l’exécution de la transaction Discharge Patient Type d’événement explicit | |||
| Patient transféré | Indique le déplacement physique d’un patient d’un lieu à un autre (unité, chambre ou lit). Permet de suivre son parcours dans l’hôpital. | ||
| Pourquoi est-ce important ? Indispensable pour repérer les goulots d’étranglement des transferts internes. Des transferts longs signalent une concurrence pour les ressources ou des retards de brancardage. Où trouver ces données Module ADM (Admissions) de MEDITECH. Données extraites de l’historique des emplacements ou des journaux de transactions « RoomBed ». Données à recueillir Consigné lors de l’exécution de la transaction Transfer Patient Type d’événement explicit | |||
| Prescription de sortie rédigée | Horodatage de la signature par le médecin de la prescription autorisant la sortie du patient. Il marque le début de la phase de préparation de la sortie. | ||
| Pourquoi est-ce important ? Définit la référence du délai de préparation de la sortie. L’écart entre cette étape et le départ effectif révèle les inefficacités opérationnelles. Où trouver ces données Module OE (Order Entry) de MEDITECH. Filtrer les prescriptions sur Category = Discharge. Données à recueillir Consigné lors de l’exécution de la transaction Order Enter Type d’événement explicit | |||
| Prescription saisie | Consigne la demande d’un service, d’un médicament ou d’un examen diagnostique par un clinicien. Cet événement déclenche les activités cliniques suivantes. | ||
| Pourquoi est-ce important ? Définit la référence de l’indicateur « Délai de prise en charge des examens diagnostiques ». La comparaison avec l’heure de réalisation permet de repérer les retards de prise en charge. Où trouver ces données Module OE (Order Entry) de MEDITECH. Données extraites de la table « OeOrders », à partir du champ Order Date/Time. Données à recueillir Consigné lors de l’exécution de la transaction Order Enter Type d’événement explicit | |||
| Résultat diagnostique vérifié | Indique qu’un examen diagnostique, en laboratoire ou en radiologie, a été réalisé et que ses résultats ont été validés par un technicien ou un radiologue. Cette étape clôt le cycle de la prescription diagnostique. | ||
| Pourquoi est-ce important ? Point final de l’indicateur « Délai de prise en charge des examens diagnostiques ». Indispensable à l’analyse des goulots d’étranglement dans les services annexes. Où trouver ces données Modules LAB ou ITS (Imaging and Therapeutic Services) de MEDITECH. Données extraites des changements de statut des résultats, lorsque ceux-ci passent à Verified ou Signed. Données à recueillir Consigné lorsque le champ de statut passe à Verified Type d’événement explicit | |||
| Triage terminé | Indique la fin de l’évaluation infirmière initiale aux urgences. Cette étape détermine le niveau de gravité et le score de sévérité du patient. | ||
| Pourquoi est-ce important ? Indispensable au Dashboard d’analyse des flux aux urgences pour mesurer le débit et les temps d’attente. Où trouver ces données Module EDM (Emergency Department Management) de MEDITECH. Déduit des changements de statut dans le suivi EDM ou de l’horodatage du document d’évaluation du triage. Données à recueillir Consigné lorsque le champ de statut passe à Triaged Type d’événement explicit | |||
| Consultation terminée | Fin de l’évaluation par le spécialiste. Elle est souvent déduite de l’enregistrement d’un document spécifique, par exemple « Cardiology Consult Note ». | ||
| Pourquoi est-ce important ? Point final de la mesure du délai de réponse du spécialiste. Indispensable pour assurer la continuité de la prise en charge dans les meilleurs délais. Où trouver ces données Module PCM (Provider Order Management) ou EMR de MEDITECH. Événement déduit des horodatages de création de documents portant des titres spécifiques. Données à recueillir Comparer le champ de statut avant et après Type d’événement inferred | |||
| Demande de consultation envoyée | Type de prescription demandant l’avis d’un spécialiste. Elle lance le décompte du délai dans le Dashboard de réponse aux consultations spécialisées. | ||
| Pourquoi est-ce important ? Permet de repérer les goulots d’étranglement dans la coordination des soins pluridisciplinaires. Un temps d’attente élevé à cette étape prolonge la durée de séjour. Où trouver ces données Module OE (Order Entry) de MEDITECH. Événement repéré en filtrant la table « OeOrders » sur Category = Consult. Données à recueillir Consigné lors de l’exécution de la transaction Order Enter Type d’événement explicit | |||
| Échantillon prélevé | Marque le prélèvement physique d’un échantillon biologique destiné à une analyse en laboratoire. Cette activité fait le lien entre la prescription et le traitement de l’échantillon. | ||
| Pourquoi est-ce important ? Cette étape détaillée est souvent à l’origine de retards dans le parcours diagnostique. Elle aide à distinguer les retards liés aux soins infirmiers de ceux du laboratoire. Où trouver ces données Module LAB de MEDITECH. L’événement est généralement enregistré lorsqu’un préleveur scanne le code-barres ou met à jour le statut de l’échantillon en Collected. Données à recueillir Consigné lors de l’exécution de la transaction Collect Specimen Type d’événement explicit | |||
| Plan de soins lancé | Correspond à la création ou à l’attribution d’un plan de soins infirmiers ou pluridisciplinaire spécifique. Cette étape correspond au concept « Plan de traitement élaboré ». | ||
| Pourquoi est-ce important ? Mesure la vitesse d’élaboration du plan de traitement. Un retard à cette étape peut révéler des lacunes dans la prise de décision clinique. Où trouver ces données Module PCS (Patient Care System) ou Care Manager de MEDITECH. Horodatage de l’application d’un plan de soins standard au patient. Données à recueillir Consigné lors de l’exécution de la transaction Care Plan Add Type d’événement explicit | |||
| Rendez-vous de suivi programmé | Programmation d’un prochain rendez-vous pour le patient. Cette activité contribue à la continuité des soins après la sortie. | ||
| Pourquoi est-ce important ? Contribue à l’analyse de la programmation des rendez-vous de suivi. Est associé à un taux de réadmission plus faible. Où trouver ces données Module SCH (Scheduling) de MEDITECH. Événement déduit de l’association d’un nouveau rendez-vous créé près de la date de sortie avec l’identifiant du patient. Données à recueillir Déduire en comparant les champs Appointment Created Date et Discharge Date Type d’événement inferred | |||
Guides d’extraction
Étapes
Repérez le serveur du référentiel de données : identifiez l’instance Microsoft SQL Server qui héberge votre MEDITECH Data Repository (DR). Il s’agit d’un système distinct de la base transactionnelle M-AT ou de la base de données sur fichiers. Vous aurez besoin d’identifiants en lecture seule, généralement ceux d’un compte de service.
Déterminez la version du schéma : la structure du DR varie légèrement entre Magic, Client/Server (6.x) et Expanse. La requête ci-dessous utilise les conventions de nommage courantes (par exemple, AdmVisits, OeOrders). Vérifiez les noms de ces tables dans l’Explorateur d’objets de SQL Server Management Studio (SSMS) de votre environnement.
Définissez le périmètre : repérez la table principale des visites des patients. Selon la configuration de votre DR, elle s’appelle généralement AdmVisits, RegAcct ou AbstractData. La requête utilise AdmVisits comme table de référence pour l’épisode patient.
Préparez l’environnement SQL : ouvrez SSMS et connectez-vous au DR. Ouvrez une nouvelle fenêtre de requête et vérifiez que la base de données sélectionnée est la bonne, souvent livedb ou un nom similaire.
Configurez les paramètres : dans le script SQL fourni, remplacez les valeurs de dates (par exemple, « 2023-01-01 ») et les identifiants d’établissement si votre DR héberge plusieurs sites.
Lancez l’extraction : exécutez l’intégralité du script T-SQL. Il utilise des expressions de table communes (CTE) pour définir d’abord la population étudiée, puis regroupe plusieurs sources de données avec UNION ALL afin de créer un journal d’événements normalisé.
Gérez les attributs NULL : la requête prévoit le traitement des valeurs NULL dans les horodatages (avec COALESCE, le cas échéant) et vérifie la présence des clés de jointure essentielles (SourceID/VisitID).
Vérifiez les données de triage et des urgences : MEDITECH stocke les données des urgences dans des modules spécifiques. Si vous analysez les flux de travail des urgences, vérifiez que les tables EdVisits ou NurInterventions sont renseignées.
Validez les catégories de commandes : la requête distingue les commandes générales, les consultations et les demandes de sortie selon les urns ou les mnémoniques de catégorie. Vous devrez peut-être adapter les clauses WHERE au dictionnaire de mnémoniques de votre établissement.
Exportez les données : une fois les résultats affichés, faites un clic droit sur la grille de résultats dans SSMS et choisissez Save Results As CSV. Vérifiez que les en-têtes sont inclus.
Vérifiez le format final : ouvrez le fichier CSV et vérifiez que les dates respectent le format ISO 8601 (YYYY-MM-DD HH:MM:SS) avant de l’importer dans ProcessMind.
Configuration
- Accès à la base de données : le compte doit disposer des autorisations db_datareader sur la base SQL du MEDITECH DR.
- Période : il est recommandé d’extraire les données des patients sortis au cours des 3 à 6 derniers mois afin d’obtenir des cycles complets.
- Filtrage par établissement : si le DR contient des données de plusieurs établissements, filtrez la CTE BaseVisits selon FacilityID ou SourceSystemID.
- Définition de l’épisode : le script utilise l’identifiant unique VisitID, souvent appelé Account Number ou Episode Number, comme ID de cas.
- Performances : la requête utilise une CTE de référence pour limiter la plage analysée. Pour de bonnes performances, vérifiez la présence d’index sur AdmitDate et DischargeDate dans la table AdmVisits.
- Latence : selon la configuration du site, le transfert des données du référentiel peut prendre de 15 minutes à 24 heures. Vérifiez l’horodatage LastDataUpdate.
Exemple de requête sql
/* MEDITECH Data Repository T-SQL Extraction for ProcessMind */
/* Process: Patient Journey */
/* Dialect: T-SQL */
WITH BaseVisits AS (
/* Define the population: Discharged patients within a date range */
SELECT
V.VisitID,
V.PatientID,
V.AccountNumber AS MedicalRecordNumber,
V.AdmitDateTime,
V.DischargeDateTime,
V.FacilityID,
V.PatientType,
V.AttendingProviderID,
V.DischargeDisposition,
NULLIF(DATEDIFF(MINUTE, V.AdmitDateTime, V.DischargeDateTime), 0) / 1440.0 AS LengthOfStay,
/* Flag readmissions logic would go here, simplified as 0 for base script */
0 AS IsReadmission
FROM
[YourDatabaseName].[dbo].[AdmVisits] V
WHERE
V.DischargeDateTime >= '2023-01-01'
AND V.DischargeDateTime < '2023-04-01'
AND V.Status = 'DIS' /* Discharged Status */
),
PatientDiagnoses AS (
/* Helper CTE for Primary Diagnosis to avoid duplicates in joins */
SELECT
D.VisitID,
MAX(D.ICDCode) AS PrimaryDiagnosis
FROM
[YourDatabaseName].[dbo].[AbsDiagnoses] D
WHERE
D.Rank = 1 /* Primary Diagnosis Rank */
GROUP BY
D.VisitID
),
TriageData AS (
/* Helper CTE for Triage Acuity */
SELECT
T.VisitID,
MAX(T.AcuityLevel) AS TriageAcuityLevel
FROM
[YourDatabaseName].[dbo].[EdTriage] T
GROUP BY
T.VisitID
)
/* 1. Patient Registered */
SELECT
V.VisitID AS PatientEpisode,
'Patient Registered' AS ActivityName,
V.AdmitDateTime AS EventTimestamp,
'MEDITECH_ADM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
V.FacilityID AS HospitalDepartment,
V.AttendingProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
BaseVisits V
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
V.AdmitDateTime IS NOT NULL
UNION ALL
/* 2. Triage Completed */
SELECT
V.VisitID AS PatientEpisode,
'Triage Completed' AS ActivityName,
ED.TriageDateTime AS EventTimestamp,
'MEDITECH_ED' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
'Emergency Department' AS HospitalDepartment,
ED.TriageNurseID AS AttendingProvider,
V.PatientType,
ED.AcuityLevel AS TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[EdTriage] ED
INNER JOIN BaseVisits V ON ED.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
WHERE
ED.TriageDateTime IS NOT NULL
UNION ALL
/* 3. Order Placed (General) */
SELECT
V.VisitID AS PatientEpisode,
'Order Placed' AS ActivityName,
O.OrderDateTime AS EventTimestamp,
'MEDITECH_OE' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
O.Department AS HospitalDepartment,
O.OrderingProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[OeOrders] O
INNER JOIN BaseVisits V ON O.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
O.Category NOT IN ('CONSULT', 'DISCHARGE') /* Exclude specific types handled elsewhere */
UNION ALL
/* 4. Specimen Collected */
SELECT
V.VisitID AS PatientEpisode,
'Specimen Collected' AS ActivityName,
L.CollectionDateTime AS EventTimestamp,
'MEDITECH_LAB' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
'Laboratory' AS HospitalDepartment,
L.CollectedBy AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[LabSpecimens] L
INNER JOIN BaseVisits V ON L.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
L.CollectionDateTime IS NOT NULL
UNION ALL
/* 5. Diagnostic Result Verified */
SELECT
V.VisitID AS PatientEpisode,
'Diagnostic Result Verified' AS ActivityName,
R.VerifiedDateTime AS EventTimestamp,
'MEDITECH_LAB' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
'Laboratory' AS HospitalDepartment,
R.VerifiedBy AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[LabResults] R
INNER JOIN BaseVisits V ON R.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
R.VerifiedDateTime IS NOT NULL
UNION ALL
/* 6. Diagnosis Documented */
SELECT
V.VisitID AS PatientEpisode,
'Diagnosis Documented' AS ActivityName,
DX.EntryDateTime AS EventTimestamp,
'MEDITECH_ABS' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
V.FacilityID AS HospitalDepartment,
DX.ProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[AbsDiagnoses] DX
INNER JOIN BaseVisits V ON DX.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
DX.EntryDateTime IS NOT NULL
UNION ALL
/* 7. Care Plan Initiated */
SELECT
V.VisitID AS PatientEpisode,
'Care Plan Initiated' AS ActivityName,
N.CreateDateTime AS EventTimestamp,
'MEDITECH_NUR' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
N.NurseUnit AS HospitalDepartment,
N.NurseID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[NurPlan] N
INNER JOIN BaseVisits V ON N.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
N.CreateDateTime IS NOT NULL
UNION ALL
/* 8. Medication Administered */
SELECT
V.VisitID AS PatientEpisode,
'Medication Administered' AS ActivityName,
M.AdminDateTime AS EventTimestamp,
'MEDITECH_PHA' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
M.AdminLocation AS HospitalDepartment,
M.AdministeredBy AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[PhaMedAdmin] M
INNER JOIN BaseVisits V ON M.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
M.Status = 'ADMINISTERED'
UNION ALL
/* 9. Consult Request Sent */
SELECT
V.VisitID AS PatientEpisode,
'Consult Request Sent' AS ActivityName,
O.OrderDateTime AS EventTimestamp,
'MEDITECH_OE' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
O.Department AS HospitalDepartment,
O.OrderingProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[OeOrders] O
INNER JOIN BaseVisits V ON O.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
O.Category = 'CONSULT'
UNION ALL
/* 10. Consultation Completed */
SELECT
V.VisitID AS PatientEpisode,
'Consultation Completed' AS ActivityName,
O.CompletedDateTime AS EventTimestamp,
'MEDITECH_OE' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
O.Department AS HospitalDepartment,
O.OrderingProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[OeOrders] O
INNER JOIN BaseVisits V ON O.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
O.Category = 'CONSULT'
AND O.Status = 'COMPLETED'
AND O.CompletedDateTime IS NOT NULL
UNION ALL
/* 11. Patient Transferred */
SELECT
V.VisitID AS PatientEpisode,
'Patient Transferred' AS ActivityName,
TX.TransferDateTime AS EventTimestamp,
'MEDITECH_ADM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
TX.ToLocation AS HospitalDepartment,
NULL AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[AdmRoomTx] TX
INNER JOIN BaseVisits V ON TX.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
TX.TransferDateTime IS NOT NULL
UNION ALL
/* 12. Discharge Order Written */
SELECT
V.VisitID AS PatientEpisode,
'Discharge Order Written' AS ActivityName,
O.OrderDateTime AS EventTimestamp,
'MEDITECH_OE' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
O.Department AS HospitalDepartment,
O.OrderingProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[OeOrders] O
INNER JOIN BaseVisits V ON O.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
O.Category = 'DISCHARGE'
OR O.Mnemonic LIKE '%DISCHARGE%'
UNION ALL
/* 13. Patient Discharged */
SELECT
V.VisitID AS PatientEpisode,
'Patient Discharged' AS ActivityName,
V.DischargeDateTime AS EventTimestamp,
'MEDITECH_ADM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
V.FacilityID AS HospitalDepartment,
V.AttendingProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
BaseVisits V
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
V.DischargeDateTime IS NOT NULL
UNION ALL
/* 14. Follow-up Booked */
SELECT
V.VisitID AS PatientEpisode,
'Follow-up Booked' AS ActivityName,
S.BookDateTime AS EventTimestamp,
'MEDITECH_SCH' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
S.ApptDepartment AS HospitalDepartment,
S.ProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[SchAppt] S
INNER JOIN BaseVisits V ON S.PatientID = V.PatientID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
S.BookDateTime > V.AdmitDateTime
AND S.BookDateTime <= DATEADD(day, 30, V.DischargeDateTime) /* Logic to link appt to episode */
AND S.Status NOT IN ('CANCELLED', 'NOSHOW'); Prêt à commencer ?
Commencez dès aujourd’hui à transformer vos opérations cliniques en appliquant ce modèle à vos données MEDITECH. Notre équipe peut vous aider à affiner l’extraction des données afin d’améliorer l’efficacité de votre établissement.
Optimisez le parcours de vos patients et réduisez les retards dès maintenant
Réduisez les temps de cycle de 30 % et améliorez l’efficacité de votre établissement
Aucune carte bancaire requise. Commencez en quelques minutes.