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 MEDITECH
Attributs du parcours patient
| Nom | Descriptionn | ||
|---|---|---|---|
| Dernière mise à jour des données LastDataUpdate | Heure de la dernière extraction ou actualisation des données. | ||
| Descriptionn Indique quand l'enregistrement a été traité ou chargé pour la dernière fois dans l'outil de Process Mining. Cela aide à auditer la la réactualisation des données et à garantir que l'analyse reflète l'état le plus actuel du système. Il est distinct de l'horodatage de l'événement, car il reflète le temps du pipeline de données technique plutôt que le temps de l'événement clinique. Pourquoi est-ce important ? : Critique pour la gouvernance des données et pour garantir que l'analyse est effectuée sur des données à jour. Source des 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 patient PatientEpisode | L'identifiant unique pour une période spécifique de soins au patient ou de visite. | ||
| Descriptionn L' Dans les systèmes MEDITECH, cela correspond souvent au numéro de compte ou à l'ID de visite. Cet Pourquoi est-ce important ? : C'est la clé de cas obligatoire requise pour lier des événements disparates en une seule instance de processus. Source des données : Module MEDITECH Admissions ou Inscription ; généralement le champ Numéro de Compte. Exemples V100938475AC29384755E993847211O229384711 | |||
| Horodatage de l'événement EventTimestamp | La date et l'heure spécifiques auxquelles l'activité s'est produite. | ||
| Descriptionn Cet Des Pourquoi est-ce important ? : Requis pour commander les Source des données : Colonnes de date/heure de transaction dans les tables source. Exemples 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:45:00Z | |||
| Nom de l'activité ActivityName | L'action clinique ou administrative spécifique effectuée. | ||
| Descriptionn Cet Une identification correcte des activités est indispensablele pour cartographier le flux de processus. Ces valeurs sont souvent dérivées de codes de transaction, de statuts de commande ou d'interventions documentées au sein du dossier de santé électronique. Pourquoi est-ce important ? : Définit les étapes du processus et est requis pour visualiser la cartographie des processus. Source des données : Dérivé de divers journaux de transactions (OE Orders, NUR Interventions, ADM Events). Exemples Patient enregistréTriage terminéMédicament administréRésultat diagnostique vérifié | |||
| Système source SourceSystem | L'identifiant du système d'où proviennent les `data`. | ||
| Descriptionn Identifie l'instance MEDITECH ou le module spécifique d'où les données d'événements ont été extraites. Dans les environnements multi-hospitaliers, cela aide à distinguer les données provenant de différentes installations ou versions de système. Cet attribut est statique pour une extraction d'un seul système mais critique lors de la fusion de données pour créer une vue unifiée à travers un réseau hospitalier. Pourquoi est-ce important ? : Assure la traçabilité des données dans les environnements multi-systèmes. Source des données : Codé en dur lors de l'extraction ou de la configuration de l'ID système. Exemples MEDITECH_ExpanseMEDITECH_6.1Hospital_A_Main | |||
| Diagnostic principal PrimaryDiagnosis | La principale condition médicale identifiée pour l'`patient episode`. | ||
| Descriptionn Contient le code CIM-10 ou la description de la raison principale de la rencontre. C'est la base de l'analyse des variations des parcours cliniques. En regroupant les cas par diagnostic principal, les gestionnaires cliniques peuvent comparer les parcours de traitement réels avec le parcours clinique idéal pour cette condition spécifique. Pourquoi est-ce important ? : Primordial pour regrouper les cas afin d'analyser les parcours cliniques. Source des données : Module des dossiers médicaux ou d'abstraction. Exemples J18.9 - PneumoniaI21.9 - Infarctus aigu du myocardeS72.0 - Fracture du fémur | |||
| Médecin traitant AttendingProvider | Le clinicien ou prestataire principal responsable de l'activité. | ||
| Descriptionn Enregistre le nom ou l'ID du médecin, de l'infirmier ou du technicien effectuant la tâche ou supervisant les soins. Cet attribut prend en charge le Il permet l'analyse des ressources pour équilibrer les charges de travail et identifier les besoins en formation parmi le personnel clinique. Pourquoi est-ce important ? : Permet l'analyse des performances des ressources et l'équilibrage de la charge de travail. Source des données : Champs Fournisseur ou Utilisateur dans les journaux d'activités. Exemples Dr. SmithInfirmière JonesTech Adams | |||
| Modalité de sortie DischargeDisposition | La destination ou le statut du patient à sa sortie. | ||
| Descriptionn Indique où le patient est allé après l'épisode, par exemple « Domicile », « Établissement de soins infirmiers spécialisés », « Soins à domicile » ou « Décédé ». C'est une indicateur de résultat majeur pour le tableau de bord « Optimisation de la planification de la sortie ». L'analyse de ceci aide à identifier si les retards dans l'obtention de places en soins post-aigus contribuent à des durées de séjour plus longues. Pourquoi est-ce important ? : Métrique de résultat clé pour l'analyse de la durée de séjour et du risque de réadmission. Source des données : Écrans d'abstraction ou d'enregistrement de sortie. Exemples Retour à domicileTransféré vers un hôpital général de court séjourExpiréSortie contre avis médical | |||
| Niveau d'acuité du triage TriageAcuityLevel | Le niveau de gravité attribué à un patient lors du triage. | ||
| Descriptionn Indique l'urgence de l'état du patient, généralement sur une échelle (par ex., 1-5, où 1 est critique). Cet attribut est central à l'« Analyse du flux du service des urgences ». Il permet aux analystes de corréler les temps d'attente avec la gravité du patient, garantissant que les patients les plus critiques sont priorisés efficacement. Pourquoi est-ce important ? : Critique pour l'analyse de la priorisation des urgences et de la conformité à la sécurité. Source des données : Écrans d'évaluation infirmière des urgences ou du triage. Exemples 1 - Resuscitation2 - Emergent3 - Urgent4 - Moins urgent | |||
| Numéro de dossier médical MedicalRecordNumber | Un identifiant unique pour le patient à travers toutes les visites. | ||
| Descriptionn Le numéro de dossier médical (MRN) identifie de manière unique un patient dans l'organisation de soins de santé, distinct de l'ID spécifique à l'épisode. Il permet aux analystes de lier plusieurs épisodes impliquant le même patient au fil du temps. Cet Pourquoi est-ce important ? : Permet l'analyse inter-épisodes et les vues centrées sur le patient. Source des données : Table d'index maître des patients ou d'enregistrement. Exemples MRN-100293MRN-55928388291002 | |||
| Réadmission IsReadmission | Indicateur indiquant si cet épisode est survenu dans les 30 jours suivant un congé précédent. | ||
| Descriptionn Un attribut booléen qui renvoie « vrai » si la date d'enregistrement actuelle du patient se situe dans les 30 jours suivant la date de sortie d'un épisode prélèvement.cédent. Ceci soutient le tableau de bord « Réadmissions et qualité des soins ». L'identification des réadmissions permet aux analystes de remonter à l'épisode prélèvement.cédent pour trouver des lacunes dans la planification des sorties ou les soins de suivi. Pourquoi est-ce important ? : Indicateur de qualité essentiel ayant un impact sur le remboursement et les résultats pour les patients. Source des données : Calculé en comparant le StartTime actuel avec le Case EndTime précédent pour le même MedicalRecordNumber. Exemples truefaux | |||
| Service Hospitalier HospitalDepartment | L'unité ou le service spécifique où l'activité a eu lieu. | ||
| Descriptionn Identifie l'unité fonctionnelle, telle que « Urgences », « Radiologie », « USI » ou « Service Général », responsable de l'activité. Cet attribut est indispensable à le tableau de bord « Débit des ressources départementales ». Il permet la segmentation des métriques de performance par unité, aidant à identifier les points de blocage dans les transferts internes et l'utilisation des ressources. Pourquoi est-ce important ? : Clé pour l'analyse organisationnelle et l'identification des points de blocage dans des unités spécifiques. Source des données : Champs Emplacement ou Département dans les tables de transactions. Exemples Service des urgencesRadiologyUnité de soins intensifsService de chirurgie 3 | |||
| Type de patient PatientType | Catégorisation de la visite patient (par ex., Hospitalisation, Ambulatoire, Urgence). | ||
| Descriptionn Classe la nature de la visite hospitalière. Les valeurs courantes incluent « Hospitalisation », « Ambulatoire », « Urgence » ou « Observation ». Cette classification est clée pour filtrer et comparer les processus, car la norme de soins et la durée prévue diffèrent considérablement selon le type. Ce champ aide dans le tableau de bord « Optimisation de la planification de la sortie » en segmentant les attentes en matière de durée de séjour. Pourquoi est-ce important ? : Segmentation clée pour la comparaison des processus (Hospitalisation vs Ambulatoire). Source des données : Tables d'admission ou de visite (par ex., AdmVisits.Status). Exemples Patient hospitaliséUrgenceChirurgie ambulatoireObservation | |||
| Catégorie de commande OrderCategory | Classification des ordres cliniques (par ex., Laboratoire, Radiologie, Consultation). | ||
| Descriptionn Regroupe les commandes en catégories plus larges telles que « Laboratoire », « Radiologie », « Diététique » ou « Consultation ». Ceci est indispensable pour le tableau de bord « Délai d'exécution des services diagnostiques ». Cela permet la séparation des workflows pour analyser les temps de cycle spécifiques à l'imagerie par rapport aux analyses sanguines, qui ont souvent des points de blocage différents. Pourquoi est-ce important ? : Segmente les Source des données : Champs de catégorie du module de Saisie des Commandes (OE). Exemples LaboratoireRadiologySoins infirmiersPharmacie | |||
| Is Adherence Violation IsAdherenceViolation | Indicateur signalant si le cas a dévié du parcours clinique standard. | ||
| Descriptionn Un indicateur booléen défini sur « vrai » si la séquence d'activités ne correspond pas au modèle de référence défini pour le diagnostic principal du patient. Ceci soutient l'analyse des variations des parcours cliniques. Il permet un filtrage rapide des cas « non conformes » afin d'enquêter sur les raisons pour lesquelles la norme de soins n'a pas été respectée. Pourquoi est-ce important ? : Identifie rapidement les écarts et les variations de processus. Source des données : Calculé par des algorithmes de vérification de conformité. Exemples truefaux | |||
| Montant de la charge ChargeAmount | La valeur financière associée à une activité ou un service spécifique. | ||
| Descriptionn Représente le coût ou la charge enregistrée pour un Lorsqu'il est agrégé, il aide à comprendre l'impact financier des variations de processus, bien que l'objectif principal de la vue demandée soit le flux clinique. Pourquoi est-ce important ? : Ajoute une dimension financière à l'analyse des processus. Source des données : Module de facturation ou BAR (Facturation/Comptes Clients). Exemples 150.001200.5045.00 | |||
| Nom du médicament MedicationName | Le nom du produit pharmaceutique administré. | ||
| Descriptionn Capture le médicament spécifique impliqué dans les événements « Médicament administré ». Ceci est requis pour le tableau de bord « Conformité de l'administration des médicaments ». Il permet au personnel infirmier de vérifier que des médicaments spécifiques à haut risque ou critiques en termes de temps (comme les antibiotiques pour le sepsis) sont administrés dans les fenêtres thérapeutiques appropriées. Pourquoi est-ce important ? : Requis pour l'analyse de la Source des données : Modules Pharmacie (PHA) ou Vérification au chevet (BMV). Exemples AcétaminophèneVancomycineHeparinInsuline | |||
| Source d'admission AdmitSource | D'où le patient est venu (par exemple, Domicile, Transfert, Référence). | ||
| Descriptionn Décrit l'origine de l'admission du patient, telle que « Orientation par un médecin », « Urgences » ou « Transfert d'un autre hôpital ». Cela fournit un contexte sur la manière dont les patients entrent dans le système. C'est utile pour comprendre les schémas d'afflux et leur impact sur l'« Analyse du flux du service des urgences » et la planification des ressources. Pourquoi est-ce important ? : Fournit un contexte sur l'afflux de patients et les canaux de demande. Source des données : Données d'enregistrement des admissions. Exemples Salle d'urgenceOrientation CliniqueTransfert depuis l'USLD | |||
| Temps d'attente au triage TriageWaitTime | Durée entre l'enregistrement et la fin du triage. | ||
| Descriptionn La durée calculée entre l' Surveiller cette durée aide les responsables des urgences à ajuster les effectifs pendant les heures de pointe pour garantir le respect des normes de sécurité des patients. Pourquoi est-ce important ? : Métrique opérationnelle clé pour les services des urgences. Source des données : Différence calculée entre les horodatages d'activités spécifiques. Exemples 15 minutes1 hour 20 minutes | |||
Activités du parcours patient
| Activité | Descriptionn | ||
|---|---|---|---|
| Commande Passée | Enregistre la demande d'un service, d'un médicament ou d'un test diagnostique par un clinicien. C'est l'`event` déclencheur pour les activités cliniques en aval. | ||
| Pourquoi est-ce important ? : Établit une ligne de base pour l'indicateur clé de performance (KPI) « Délai d'exécution des services diagnostiques ». Comparer cela au temps d'exécution identifie les retards dans la prestation de services. Source des données : Module MEDITECH OE (Saisie des Commandes). Capturé depuis la table 'OeOrders' en utilisant le champ Date/Heure de la commande. Capture Comptabilisé lorsque la transaction Saisie Commande est exécutée Type d'événement explicit | |||
| Diagnostic documenté | Le point où un clinicien saisit un diagnostic codé (CIM-10) dans le dossier du patient. Cela déclenche souvent des parcours cliniques spécifiques. | ||
| Pourquoi est-ce important ? : Permet l'analyse des variations des parcours cliniques en catégorisant le cas. Primordial pour regrouper les patients à des fins de comparaison. Source des données : MEDITECH ABS (Abstraction) ou Dossiers Médicaux. Capturé lorsque les codes de diagnostic sont associés au compte. Capture Comptabilisé lorsque la transaction Saisie Diagnostic est exécutée Type d'événement explicit | |||
| Médicament administré | Enregistre l'administration réelle du médicament au patient par le personnel infirmier. Généralement capturé via le scan de code-barres au chevet du patient. | ||
| Pourquoi est-ce important ? : Soutient la 'Conformité à l'administration des médicaments'. Identifie les risques de sécurité et les interruptions de Source des données : MEDITECH PHA (Pharmacie) ou eMAR (Dossier d'Administration Électronique des Médicaments). Le 'AdminDateTime' dans l'historique d'administration. Capture Comptabilisé lorsque la transaction Administration Médicament est exécutée Type d'événement explicit | |||
| Ordre de sortie rédigé | L'`horodatage` lorsque le médecin signe l'ordre autorisant la sortie du patient. Cela marque le début de la phase de 'Planification de la sortie'. | ||
| Pourquoi est-ce important ? : Établit une ligne de base pour le « Délai de planification de la sortie ». L'écart entre ce délai et le départ effectif représente une inefficacité opérationnelle. Source des données : MEDITECH OE (Saisie des Commandes). Filtrer les commandes pour Catégorie = Sortie. Capture Comptabilisé lorsque la transaction Saisie Commande est exécutée Type d'événement explicit | |||
| Patient enregistré | Cet `event` marque la création administrative de l'`patient episode` ou du dossier de visite dans le système. Il capture le point d'entrée initial dans le module MEDITECH ADM (Admissions). | ||
| Pourquoi est-ce important ? : Établit le début du parcours patient et les calculs du temps de cycle. Primordial pour le calcul de la Durée Totale de Séjour. Source des données : Module MEDITECH ADM. Provenant de la table 'Admissions', spécifiquement du champ 'AdmitDateTime' ou de l'horodatage de création du journal de transactions. Capture Comptabilisé lorsque la transaction Nouvelle Visite est exécutée Type d'événement explicit | |||
| Patient sorti | La clôture administrative de la visite. Le patient est physiquement parti et le lit est libéré. | ||
| Pourquoi est-ce important ? : La fin formelle du processus. Utilisé pour calculer la durée de séjour finale et définir la fenêtre de réadmission de 30 jours. Source des données : MEDITECH ADM (Admissions). Le champ 'DischargeDateTime' dans le dossier de visite. Capture Comptabilisé lorsque la transaction Sortie Patient est exécutée Type d'événement explicit | |||
| Patient transféré | Indique le mouvement physique d'un patient d'un lieu (Unité/Chambre/Lit) à un autre. Suit le flux à travers l'hôpital. | ||
| Pourquoi est-ce important ? : Clé pour les 'Goulots d'étranglement des transferts internes'. Des durées de transfert élevées signalent des conflits de ressources ou des retards de manutention. Source des données : MEDITECH ADM (Admissions). Capturé à partir des journaux de transactions 'Location History' ou 'RoomBed'. Capture Comptabilisé lorsque la transaction Transfert Patient est exécutée Type d'événement explicit | |||
| Résultat diagnostique vérifié | Indique qu'un test diagnostique (Laboratoire ou Radiologie) a été effectué et que les résultats ont été validés par un technicien ou un radiologue. Cela clôture efficacement la boucle d'une commande diagnostique. | ||
| Pourquoi est-ce important ? : Le point final pour le 'Délai d'exécution des services diagnostiques'. Primordial pour analyser les Source des données : Modules MEDITECH LAB ou ITS (Imagerie et Services Thérapeutiques). Capturé à partir des changements de statut des résultats vers 'Vérifié' ou 'Validé'. Capture Comptabilisé lorsque le champ de statut passe à Vérifié Type d'événement explicit | |||
| Triage terminé | Indique l'achèvement de l'évaluation infirmière initiale au service des urgences. Cela définit le niveau d'acuité et le score de gravité pour le patient. | ||
| Pourquoi est-ce important ? : Critique pour le tableau de bord « Analyse du flux du service des urgences » afin de mesurer le débit et les temps d'attente. Source des données : Module MEDITECH EDM (Gestion des Urgences). Dérivé des changements de statut dans le suivi EDM ou de l'horodatage du document d'Évaluation du Triage. Capture Comptabilisé lorsque le champ de statut passe à Trié Type d'événement explicit | |||
| Consultation terminée | L'achèvement de l'évaluation du spécialiste. Souvent déduit du dépôt d'un type de document spécifique (par exemple, 'Note de consultation en cardiologie'). | ||
| Pourquoi est-ce important ? : Le point final pour mesurer la réactivité des spécialistes. Primordial pour assurer la progression rapide des soins. Source des données : MEDITECH PCM (Gestion des Commandes du Fournisseur) ou EMR. Déduit des horodatages de création de documents avec des titres spécifiques. Capture Comparer le champ de statut avant et après Type d'événement inferred | |||
| Demande de Consultation Envoyée | Un type d'ordre spécifique demandant l'avis d'un spécialiste. Cela lance le chronomètre sur le tableau de bord « Temps de réponse aux consultations de spécialistes ». | ||
| Pourquoi est-ce important ? : Identifie les points de blocage dans la coordination des soins pluridisciplinaires. Des temps d'attente élevés ici prolongent la durée de séjour. Source des données : MEDITECH OE (Saisie des Commandes). Identifié en filtrant les 'OeOrders' pour Catégorie = Consultation. Capture Comptabilisé lorsque la transaction Saisie Commande 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 spécifique. Cela correspond au concept de 'Plan de traitement développé'. | ||
| Pourquoi est-ce important ? : Mesure la 'vitesse de développement du plan de traitement'. Les retards à ce niveau suggèrent des lacunes dans la prise de décision clinique. Source des données : MEDITECH PCS (Système de Soins aux Patients) ou Gestionnaire de Soins. Horodatage de l'application d'un plan de soins standard au patient. Capture Comptabilisé lorsque la transaction Ajout Plan de Soins est exécutée Type d'événement explicit | |||
| Spécimen prélevé | Marque la collecte physique d'un échantillon biologique pour analyse en laboratoire. Cette activité fait le lien entre la commande et le traitement. | ||
| Pourquoi est-ce important ? : Étape granulaire souvent responsable des retards dans le cycle de diagnostic. Utile pour séparer les retards infirmiers des retards de laboratoire. Source des données : Module MEDITECH LAB. Généralement capturé lorsqu'un phlébotomiste scanne le code-barres ou met à jour le statut du spécimen à 'Collecté'. Capture Comptabilisé lorsque la transaction Collecte Spécimen est exécutée Type d'événement explicit | |||
| Suivi réservé | La planification d'un futur rendez-vous pour le patient. Cette activité soutient la continuité des soins post-sortie. | ||
| Pourquoi est-ce important ? : Soutient l'analyse de la 'Planification des rendez-vous de suivi'. Est corrélé à des taux de réadmission plus faibles. Source des données : MEDITECH SCH (Planification). Déduit en liant un nouveau dossier de rendez-vous créé près de la date de sortie à l'ID du patient. Capture Dériver en comparant le champ Appointment Created Date à Discharge Date Type d'événement inferred | |||
Guides d'extraction
Étapes
Identifier le serveur Data Repository : Localisez l'instance Microsoft SQL Server hébergeant votre MEDITECH Data Repository (DR). Celui-ci est distinct de la base de données transactionnelle M-AT ou basée sur des fichiers. Vous aurez besoin d'identifiants en lecture seule (généralement un compte de service).
Déterminer la version du schéma : Les structures du DR MEDITECH varient légèrement selon les versions Magic, Client/Server (6.x) ou Expanse. La requête ci-dessous utilise les conventions de nommage standards (ex : AdmVisits, OeOrders). Vérifiez ces noms de tables dans l'Explorateur d'objets de SQL Server Management Studio (SSMS).
Définir le périmètre : Identifiez la table principale pour les visites de patients. Elle est généralement nommée AdmVisits, RegAcct ou AbstractData selon votre configuration DR. La requête utilise AdmVisits comme point d'ancrage pour l'épisode patient.
Préparer l'environnement SQL : Ouvrez SSMS et connectez-vous au DR. Ouvrez une nouvelle fenêtre de requête. Assurez-vous d'être positionné sur la bonne base de données (souvent nommée livedb ou similaire).
Configurer les paramètres : Dans le script SQL fourni, remplacez les paramètres fictifs pour les plages de dates (ex : '2023-01-01') et les identifiants d'établissement si votre DR héberge plusieurs sites.
Exécuter l'extraction : Lancez le script T-SQL complet. Il utilise des expressions de table communes (CTE) pour définir la population d'intérêt, puis unifie plusieurs sources de données via UNION ALL pour créer un journal d'événements standardisé.
Gérer les attributs NULL : La requête inclut une logique pour gérer les éventuels NULL dans les horodatages (via COALESCE si nécessaire) et garantit la présence des clés de jointure critiques (SourceID/VisitID).
Vérifier les données de triage et d'urgence : MEDITECH stocke les données ED dans des modules spécifiques. Assurez-vous que les tables EdVisits ou NurInterventions sont alimentées si vous analysez les flux de travail des urgences.
Valider les catégories de commandes : La requête sépare les commandes générales, les consultations et les sorties en fonction des URN ou des mnémoniques de catégorie. Vous devrez peut-être ajuster les clauses WHERE pour correspondre au dictionnaire de mnémoniques propre à votre établissement.
Exporter les données : Une fois les résultats obtenus, faites un clic droit sur la grille de résultats dans SSMS et sélectionnez "Enregistrer les résultats sous CSV". Assurez-vous d'inclure les en-têtes.
Formatage final : 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 l'importation dans ProcessMind.
Configuration
- Accès à la base de données : Nécessite les autorisations
db_datareadersur la base SQL MEDITECH DR. - Période d'extraction : Une fenêtre de 3 à 6 mois pour les patients sortis est recommandée afin de garantir des cycles complets.
- Filtrage par établissement : Si le DR contient des données multi-établissements, filtrez le CTE
BaseVisitsparFacilityIDouSourceSystemID. - Définition de l'épisode : Le script utilise l'identifiant unique
VisitID(souvent appelé numéro de compte ou d'épisode) commeID du cas. - Performance : La requête utilise une ancre CTE pour limiter la plage de recherche. Assurez-vous que des index existent sur
AdmitDateetDischargeDatedans la tableAdmVisitspour une performance optimale. - Latence : Les transferts vers 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');