Votre modèle de données du parcours patient
Votre modèle de données du parcours patient
- Attributs cliniques recommandés
- Jalons essentiels du processus
- Guide d’extraction des données 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 à quel moment l’enregistrement a été traité ou chargé pour la dernière fois dans l’outil de Process Mining. Il contribue à contrôler la fraîcheur des données et à garantir 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 à l’heure technique du pipeline de données et non à l’heure de l’événement clinique. Pourquoi c’est important Essentiel à la gouvernance des données et à la réalisation d’analyses fondées sur des données à jour. Où les obtenir 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 du patient PatientEpisode | Identifiant unique d’une période précise de soins ou d’une visite du patient. | ||
| Description Le Patient Episode sert d’identifiant de cas central pour l’analyse du processus. Il regroupe dans 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 les systèmes MEDITECH, il correspond souvent à l’Account Number ou au Visit ID. Cet attribut est fondamental pour reconstituer le parcours patient, de l’enregistrement à la sortie, calculer la durée du séjour et analyser les parcours cliniques. Pourquoi c’est important Il s’agit de la clé de cas obligatoire permettant de relier des événements distincts à une même instance de processus. Où les obtenir Module MEDITECH Admissions ou Registration, généralement le champ Account Number. Exemples V100938475AC29384755E993847211O229384711 | |||
| Horodatage de l’événement EventTimestamp | Date et heure précises auxquelles l’activité s’est produite. | ||
| Description Cet attribut enregistre le moment exact où une activité a eu lieu. Il sert à ordonner les événements chronologiquement et à calculer les durées entre les étapes du processus. Des horodatages très précis sont nécessaires pour analyser correctement les temps d’attente, comme le délai entre le triage et l’évaluation ou le délai de traitement des résultats diagnostiques. Pourquoi c’est important Nécessaire pour ordonner les événements et calculer les durées de cycle et le débit. Où les obtenir 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 précise réalisée. | ||
| Description Cet attribut correspond au nom de l’événement ou de la tâche qui se déroule dans le parcours patient. Il enregistre les différentes étapes, comme « Patient Registered », « Medication Administered » ou « Discharge Order Written ». L’identification correcte des activités est essentielle pour cartographier le flux du processus. Ces valeurs proviennent souvent des codes de transaction, des statuts de commande ou des interventions documentées dans le dossier médical électronique. Pourquoi c’est important Définit les étapes du processus et est nécessaire pour visualiser la carte du processus. Où les obtenir Dérivé de différents journaux de transactions, notamment OE Orders, NUR Interventions et ADM Events. Exemples Patient enregistréTriage terminéMédicament administréRésultat diagnostique vérifié | |||
| Système source SourceSystem | Identifiant du système à l’origine des données. | ||
| Description Identifie l’instance MEDITECH ou le module précis depuis lequel les données d’événements ont été extraites. Dans les environnements regroupant plusieurs hôpitaux, il permet de distinguer les données provenant de différents établissements ou versions du système. Cet attribut reste statique pour une extraction depuis un système unique, mais il est essentiel lors de la fusion de données visant à créer une vue unifiée d’un réseau hospitalier. Pourquoi c’est important Garantit la traçabilité et la provenance des données dans les environnements multisystèmes. Où les obtenir 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 au moment de sa sortie. | ||
| Description Indique où le patient a été orienté après l’épisode, par exemple « Domicile », « Établissement de soins infirmiers », « Soins à domicile » ou « Décès ». Il s’agit d’un indicateur de résultat important pour le Dashboard « Optimisation de la planification des sorties ». Son analyse permet de déterminer si les retards dans la recherche d’une solution de soins post-aigus contribuent à allonger les durées de séjour. Pourquoi c’est important Indicateur de résultat essentiel pour analyser la durée de séjour et le risque de réadmission. Où les obtenir Écrans d’abstraction ou d’enregistrement des sorties. Exemples Retour à domicileTransfert vers un hôpital général de court séjourDécèsDépart contre avis médical | |||
| Diagnostic principal PrimaryDiagnosis | Pathologie principale identifiée pour l’épisode du patient. | ||
| Description Contient le code ou la description ICD-10 correspondant au motif médical principal de la prise en charge. Il constitue le fondement de l’« Analyse des variantes du parcours clinique ». En regroupant les cas par diagnostic principal, les responsables cliniques peuvent comparer les parcours de traitement réels au parcours clinique de référence correspondant à cette pathologie. Pourquoi c’est important Essentiel pour regrouper les cas et analyser les parcours cliniques. Où les obtenir Dossier médical ou module d’abstraction. Exemples J18.9 - PneumonieI21.9 - Infarctus aigu du myocardeS72.0 - Fracture du fémur | |||
| Niveau de gravité du 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 des flux du service des 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 effectivement traités en priorité. Pourquoi c’est important Essentiel pour analyser la priorisation aux urgences et le respect des exigences de sécurité. Où les obtenir Écrans d’évaluation infirmière des urgences ou du triage. Exemples 1 - Réanimation2 - Urgence vitale3 - 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 de manière unique un patient au sein de l’organisation de santé, indépendamment de l’identifiant propre à chaque épisode. Il permet aux analystes de relier au fil du temps plusieurs épisodes concernant le même patient. Cet attribut est essentiel pour le Dashboard « Réadmissions et qualité des soins » : il permet de détecter les patients qui reviennent à l’hôpital dans les 30 jours suivant leur sortie. Pourquoi c’est important Permet d’analyser plusieurs épisodes et d’obtenir une vue centrée sur le patient. Où les obtenir Index principal des patients ou table d’enregistrement. 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 « Vitesse d’élaboration du plan de traitement » en attribuant les indicateurs de rapidité et d’efficacité à certains membres du personnel ou rôles. Il permet d’analyser les ressources afin d’équilibrer les charges de travail et de repérer les besoins de formation du personnel clinique. Pourquoi c’est important Permet d’analyser la performance des ressources et d’équilibrer les charges de travail. Où les obtenir Champs Provider ou User dans les journaux d’activité. Exemples Dr SmithInfirmier JonesTechnicien Adams | |||
| Réadmission IsReadmission | Indicateur précisant 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 lorsque la date d’enregistrement actuelle du patient se situe dans les 30 jours suivant la date de sortie d’un épisode précédent. Il alimente le Dashboard « Réadmissions et qualité des soins ». L’identification des réadmissions permet aux analystes de revenir à l’épisode précédent afin de repérer d’éventuelles lacunes dans la planification de la sortie ou le suivi des soins. Pourquoi c’est important Indicateur de qualité essentiel, qui influe sur le remboursement et les résultats pour les patients. Où les obtenir 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 dans lequel l’activité a eu lieu. | ||
| Description Identifie l’unité fonctionnelle, par exemple « Urgences », « Radiologie », « USI » ou « Service de médecine générale », responsable de l’activité. Cet attribut est essentiel pour le Dashboard « Débit des ressources par service ». Il permet de segmenter les indicateurs de performance par unité afin de repérer les goulots d’étranglement dans les transferts internes et l’utilisation des ressources. Pourquoi c’est important Essentiel pour l’analyse organisationnelle et l’identification des goulots d’étranglement dans certaines unités. Où les obtenir Champs Location ou Department dans les tables de transactions. Exemples Service des urgencesRadiologieUnité de soins intensifsService de chirurgie 3 | |||
| Type de patient PatientType | Catégorie de la visite du patient, par exemple hospitalisation complète, consultation externe ou urgence. | ||
| Description Classe la nature de la visite à l’hôpital. Les valeurs courantes comprennent « Inpatient », « Outpatient », « Emergency » et « Observation ». Cette classification est fondamentale pour filtrer et comparer les processus, car les standards de soins et les durées attendues varient fortement selon le type de visite. Ce champ contribue au Dashboard « Optimisation de la planification des sorties » en segmentant les durées de séjour attendues. Pourquoi c’est important Segmentation fondamentale pour comparer les processus, notamment entre hospitalisation complète et consultation externe. Où les obtenir Tables Admission ou Visit, par exemple AdmVisits.Status. Exemples Hospitalisation complèteUrgencesChirurgie ambulatoireObservation | |||
| Catégorie de commande OrderCategory | Classification des commandes cliniques, par exemple laboratoire, radiologie ou consultation spécialisée. | ||
| Description Regroupe les prescriptions en catégories générales telles que « Laboratory », « Radiology », « Dietary » ou « Consult ». Cette fonction est essentielle pour le Dashboard « Diagnostic Services Turnaround ». Elle permet de séparer 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 c’est important Segmente les flux de travail de diagnostic et de traitement. Où les obtenir Champs de catégorie du module Order Entry (OE). Exemples LaboratoireRadiologieSoins infirmiersPharmacie | |||
| Montant facturé ChargeAmount | Valeur financière associée à une activité ou à un service précis. | ||
| Description Représente le coût ou le montant facturé pour un événement précis, par exemple un examen ou l’occupation d’une chambre. Bien qu’il soit principalement financier, cet indicateur est lié à l’intensité des ressources mobilisées. Une fois agrégé, il aide à comprendre l’incidence financière des variations de processus, même si la vue demandée porte avant tout sur les flux cliniques. Pourquoi c’est important Ajoute une dimension financière à l’analyse des processus. Où les obtenir Module Billing ou BAR (Billing/Accounts Receivable). Exemples 150.001200.5045.00 | |||
| Nom du médicament MedicationName | Nom du produit pharmaceutique administré. | ||
| Description Enregistre le médicament précis associé aux événements « Médicament administré ». Il est requis pour le Dashboard « Conformité de l’administration des médicaments ». Il permet aux responsables des soins infirmiers de vérifier que certains médicaments à haut risque ou soumis à des contraintes de temps, comme les antibiotiques administrés en cas de sepsis, sont délivrés dans les fenêtres thérapeutiques appropriées. Pourquoi c’est important Requis pour l’analyse de la conformité clinique et de la sécurité des soins. Où les obtenir Modules Pharmacy (PHA) ou Bedside Verification (BMV). Exemples ParacétamolVancomycineHé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 ». Il fournit le contexte dans lequel les patients entrent dans le système. Il aide à comprendre les schémas d’afflux et leur incidence sur l’« Analyse des flux du service des urgences » et la planification des ressources. Pourquoi c’est important Fournit le contexte sur l’afflux de patients et les canaux de demande. Où les obtenir Données d’enregistrement des admissions. Exemples Service des urgencesOrientation par une cliniqueTransfert depuis un établissement de soins infirmiers spécialisés | |||
| Temps d’attente avant le triage TriageWaitTime | Durée entre l’enregistrement et la fin du triage. | ||
| Description Durée calculée entre l’événement « Patient enregistré » et l’événement « Triage terminé ». Elle alimente directement le KPI « Temps moyen de traitement du triage ». Le suivi de cette durée aide les responsables des urgences à adapter les effectifs pendant les périodes de forte affluence et à respecter les exigences de sécurité des patients. Pourquoi c’est important Indicateur opérationnel essentiel pour les services des urgences. Où les obtenir Différence calculée entre les horodatages de certaines activités. Exemples 15 minutes1 heure 20 minutes | |||
| Violation du respect du parcours IsAdherenceViolation | Indicateur précisant si le cas s’est écarté du parcours clinique standard. | ||
| 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 défini pour le diagnostic principal du patient. Il contribue à l’« Analyse des variantes du parcours clinique ». Il permet de filtrer rapidement les cas « non conformes » afin d’examiner les raisons pour lesquelles le standard de soins n’a pas été respecté. Pourquoi c’est important Identifie rapidement les écarts et les variations du processus. Où les obtenir Calculé par des algorithmes de contrôle de conformité. Exemples truefalse | |||
Activités du parcours patient
| Activité | Description | ||
|---|---|---|---|
| Commande passée | Enregistre la demande d’un service, d’un médicament ou d’un examen diagnostique par un clinicien. Il s’agit de l’événement déclencheur des activités cliniques suivantes. | ||
| Pourquoi c’est important Établit la référence du KPI « Diagnostic Services Turnaround ». La comparaison avec l’heure d’exécution permet d’identifier les retards dans la prestation du service. Où les obtenir Module MEDITECH OE (Order Entry). Capturé dans la table « OeOrders » à partir du champ Order Date/Time. Collecte Enregistré lorsque la transaction Order Enter est exécutée Type d’événement explicit | |||
| Diagnostic documenté | Moment où un clinicien saisit un diagnostic codé, selon la classification ICD-10, dans le dossier du patient. Cette étape déclenche souvent des parcours cliniques précis. | ||
| Pourquoi c’est important Permet l’analyse « Clinical Pathway Variant Analysis » en catégorisant le cas. Essentiel pour regrouper les patients à des fins de comparaison. Où les obtenir MEDITECH ABS (Abstracting) ou Medical Records. Capturé lorsque les codes de diagnostic sont associés au compte. Collecte Enregistré lorsque la transaction Diagnosis Enter est exécutée Type d’événement explicit | |||
| Médicament administré | Enregistre l’administration effective du médicament au patient par le personnel infirmier. Elle est généralement capturée au moyen d’un scan de code-barres au chevet du patient. | ||
| Pourquoi c’est important Prend en charge « Medication Administration Compliance ». Identifie les risques de sécurité et les interruptions des flux de travail dans les unités de soins infirmiers. Où les obtenir MEDITECH PHA (Pharmacy) ou eMAR (Electronic Medication Administration Record). Champ « AdminDateTime » de l’historique d’administration. Collecte Enregistré lorsque la transaction Med Admin est exécutée Type d’événement explicit | |||
| Ordre de sortie rédigé | Horodatage de la signature par le médecin de l’ordre autorisant la sortie du patient. Cette étape marque le début de la phase « Discharge Planning ». | ||
| Pourquoi c’est important Établit la référence du « Discharge Planning Lead Time ». L’écart entre cette étape et le départ effectif représente une inefficacité opérationnelle. Où les obtenir MEDITECH OE (Order Entry). Filtrer les commandes avec Category = Discharge. Collecte Enregistré lorsque la transaction Order Enter est exécutée Type d’événement explicit | |||
| Patient enregistré | Cet événement marque la création administrative de l’épisode patient ou du dossier de visite dans le système. Il correspond au premier point d’entrée dans le module MEDITECH ADM (Admissions). | ||
| Pourquoi c’est important Établit le début du parcours patient et des calculs de durée de cycle. Essentiel pour calculer la durée totale du séjour. Où les obtenir Module MEDITECH ADM. Source : table « Admissions », plus précisément le champ « AdmitDateTime » ou l’horodatage de création du journal de transactions. Collecte Enregistré lorsque la transaction New Visit est exécutée Type d’événement explicit | |||
| Patient sorti | Clôture administrative de la visite. Le patient a quitté physiquement l’établissement et le lit est libéré. | ||
| Pourquoi c’est important Fin officielle du processus. Utilisé pour calculer la durée finale du séjour et définir la fenêtre de réadmission à 30 jours. Où les obtenir MEDITECH ADM (Admissions). Champ « DischargeDateTime » du dossier de visite. Collecte Enregistré lorsque la transaction Discharge Patient est exécutée Type d’événement explicit | |||
| Patient transféré | Indique le déplacement physique d’un patient d’un emplacement, unité, chambre ou lit, vers un autre. Suit le parcours du patient dans l’hôpital. | ||
| Pourquoi c’est important Essentiel pour l’analyse des « Internal Transfer Bottlenecks ». Des durées de transfert élevées indiquent une concurrence pour les ressources ou des retards de brancardage. Où les obtenir MEDITECH ADM (Admissions). Capturé dans les journaux « Location History » ou « RoomBed ». Collecte Enregistré lorsque la transaction Transfer Patient est exécutée Type d’événement explicit | |||
| Résultat diagnostique vérifié | Indique qu’un examen diagnostique, de laboratoire ou de radiologie, a été réalisé et validé par un technicien ou un radiologue. Cette étape clôt effectivement le cycle d’une demande diagnostique. | ||
| Pourquoi c’est important Point final du KPI « Diagnostic Services Turnaround ». Essentiel pour analyser les goulots d’étranglement des services auxiliaires. Où les obtenir Modules MEDITECH LAB ou ITS (Imaging and Therapeutic Services). Capturé lors du passage du statut du résultat à Verified ou Signed. Collecte Enregistré 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 d’urgence et le score de gravité du patient. | ||
| Pourquoi c’est important Essentiel pour le Dashboard Emergency Department Flow Analysis, qui mesure le débit et les temps d’attente. Où les obtenir Module MEDITECH EDM (Emergency Department Management). Dérivé des changements de statut dans le tracker EDM ou de l’horodatage du document Triage Assessment. Collecte Enregistré lorsque le champ de statut passe à Triaged Type d’événement explicit | |||
| Consultation terminée | Fin de l’évaluation par le spécialiste. Cette étape est souvent déduite du dépôt d’un type de document précis, par exemple « Cardiology Consult Note ». | ||
| Pourquoi c’est important Point final de la mesure de la réactivité des spécialistes. Essentiel pour garantir la progression rapide de la prise en charge. Où les obtenir MEDITECH PCM (Provider Order Management) ou EMR. Déduit des horodatages de création de documents portant des titres précis. Collecte Comparer le champ de statut avant et après Type d’événement inferred | |||
| Demande de consultation envoyée | Type précis de commande demandant l’avis d’un spécialiste. Cette étape lance le chronomètre du Dashboard « Specialist Consultation Response ». | ||
| Pourquoi c’est important Identifie les goulots d’étranglement dans la coordination des soins pluridisciplinaires. Des temps d’attente élevés à cette étape prolongent la durée du séjour. Où les obtenir MEDITECH OE (Order Entry). Identifié en filtrant « OeOrders » avec Category = Consult. Collecte Enregistré lorsque la transaction Order Enter est exécutée Type d’événement explicit | |||
| Échantillon prélevé | Marque le prélèvement physique d’un échantillon biologique destiné à une analyse de laboratoire. Cette activité fait le lien entre la prescription et le traitement de l’échantillon. | ||
| Pourquoi c’est important Étape détaillée souvent à l’origine de retards dans le cycle diagnostique. Utile pour distinguer les retards infirmiers des retards du laboratoire. Où les obtenir Module MEDITECH LAB. Généralement capturé lorsqu’un phlébotomiste scanne le code-barres ou met à jour le statut de l’échantillon à Collected. Collecte Enregistré lorsque la transaction Collect Specimen est exécutée Type d’événement explicit | |||
| Plan de soins initié | Représente la création ou l’attribution d’un plan de soins infirmiers ou interdisciplinaire précis. Cette étape correspond au concept « Treatment Plan Developed ». | ||
| Pourquoi c’est important Mesure le KPI « Treatment Plan Development Velocity ». Les retards à cette étape peuvent révéler des lacunes dans la prise de décision clinique. Où les obtenir MEDITECH PCS (Patient Care System) ou Care Manager. Horodatage de l’application d’un Plan of Care standard au patient. Collecte Enregistré lorsque la transaction Care Plan Add est exécutée Type d’événement explicit | |||
| Suivi planifié | Planification d’un rendez-vous ultérieur pour le patient. Cette activité contribue à la continuité des soins après la sortie. | ||
| Pourquoi c’est important Contribue à l’analyse « Follow-up Appointment Scheduling ». Corrélé à des taux de réadmission plus faibles. Où les obtenir MEDITECH SCH (Scheduling). Déduit en reliant un nouvel enregistrement Appointment créé à proximité de la date de sortie à l’identifiant du patient. Collecte Déduire en comparant les champs Appointment Created Date et Discharge Date Type d’événement inferred | |||
Guides d’extraction
Étapes
Identifiez le serveur du référentiel de données : localisez l’instance Microsoft SQL Server qui héberge votre MEDITECH Data Repository (DR). Elle est distincte de la base transactionnelle M-AT ou de la base de données fondée sur des 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 : les structures du MEDITECH DR varient légèrement entre Magic, Client/Server (6.x) et Expanse. La requête ci-dessous utilise les conventions de nommage standard, par exemple AdmVisits et OeOrders. Vérifiez ces noms de tables dans l’Explorateur d’objets de SQL Server Management Studio (SSMS) installé localement.
Définissez le périmètre : identifiez la table principale des visites des patients. Elle s’appelle généralement AdmVisits, RegAcct ou AbstractData, selon la configuration de votre DR. La requête utilise AdmVisits comme point d’ancrage de l’épisode patient.
Préparez l’environnement SQL : ouvrez SSMS et connectez-vous au DR. Ouvrez une nouvelle fenêtre de requête. Vérifiez que le contexte correspond à la bonne base de données, souvent nommée livedb ou de manière similaire.
Configurez les paramètres : dans le script SQL fourni, remplacez les espaces réservés correspondant aux plages de dates, par exemple « 2023-01-01 », ainsi qu’aux identifiants des établissements si votre DR héberge plusieurs sites.
Exécutez l’extraction : lancez l’intégralité du script T-SQL. Celui-ci utilise des Common Table Expressions (CTE) pour définir d’abord la population étudiée, puis combiner plusieurs sources de données avec UNION ALL afin de créer un journal d’événements standardisé.
Gérez les attributs NULL : la requête contient une logique de gestion des valeurs NULL dans les horodatages, en utilisant COALESCE lorsque cela est nécessaire, et vérifie la présence des clés de jointure essentielles, SourceID et VisitID.
Vérifiez les données de triage et d’urgence : MEDITECH stocke les données des urgences dans des modules spécifiques. Vérifiez que les tables EdVisits ou NurInterventions sont alimentées si vous analysez les flux de travail des urgences.
Validez les catégories de prescriptions : la requête sépare les prescriptions générales, les consultations et les prescriptions de sortie en fonction des urns ou des mnémoniques de catégorie. Vous devrez peut-être adapter les clauses WHERE aux spécificités du dictionnaire de mnémoniques de votre établissement.
Exportez les données : une fois les résultats affichés, cliquez avec le bouton droit de la souris sur la grille de résultats dans SSMS et sélectionnez Save Results As CSV. Vérifiez que les en-têtes sont inclus.
Effectuez la mise en forme finale : ouvrez le fichier CSV pour vérifier que les formats de date sont conformes à la norme ISO 8601 (YYYY-MM-DD HH:MM:SS) avant de l’importer dans ProcessMind.
Configuration
- Accès à la base de données : nécessite les autorisations db_datareader sur la base SQL du DR MEDITECH.
- Plage de dates : une période d’extraction de 3 à 6 mois de patients sortis est recommandée afin de disposer de cycles terminés.
- Filtrage par établissement : si le DR contient des données provenant de plusieurs établissements, filtrez la CTE BaseVisits selon FacilityID ou SourceSystemID.
- Définition de l’épisode : le script utilise le VisitID unique, souvent appelé Account Number ou Episode Number, comme Case ID.
- Performances : la requête utilise une CTE d’ancrage pour limiter la plage analysée. Vérifiez que des index existent sur AdmitDate et DischargeDate dans la table AdmVisits afin d’obtenir de bonnes performances.
- Latence : les transferts depuis le Data Repository peuvent présenter une latence de 15 minutes à 24 heures selon la configuration du site. Vérifiez l’horodatage LastDataUpdate.
a 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 votre extraction de données afin d’améliorer au maximum l’efficacité de votre établissement.
Optimisez dès maintenant le parcours de vos patients et réduisez les délais
Réduisez de 30 % les temps de cycle et améliorez l’efficacité de votre établissement hospitalier
Aucune carte bancaire requise. Commencez en quelques minutes.