> Mejora continua de procesos > Recorrido del paciente > Veradigm (Allscripts) > Template de datos

Su Template de datos del recorrido del paciente

Veradigm (Allscripts)

Atributos del recorrido del paciente (19) Actividades del recorrido del paciente (13) Guías de extracción (2)

Su Template de datos del recorrido del paciente

Esta plantilla ofrece un enfoque estructurado para recopilar los datos necesarios para analizar el proceso del recorrido del paciente. Describe los atributos y las actividades esenciales que debe registrar, junto con recomendaciones prácticas para extraer esta información de su sistema de origen. Utilice este recurso para preparar sus datos para un Process Mining completo.

Atributos recomendados para recopilar un análisis completo
Actividades clave que debe registrar para descubrir el proceso con precisión
Recomendaciones prácticas para extraer datos de su sistema

¿Es nuevo en los registros de eventos? Aprenda a crear un registro de eventos de Process Mining.

Descargar Template

Atributos del recorrido del paciente

Estos son los campos de datos recomendados que debe incluir en su registro de eventos para realizar un análisis completo del proceso de recorrido del paciente.

3 Obligatorio 8 Recomendado 8 Opcional

	Nombre	Descripción
	Episodio del paciente PatientEpisodeId	Identificador único de la visita o el encuentro específico del paciente.
Descripción El episodio del paciente actúa como identificador principal del caso y agrupa todos los eventos relacionados con el recorrido sanitario específico de un paciente para una determinada afección o periodo de atención. Esto permite obtener una visión integrada de las fases de diagnóstico, tratamiento y recuperación, conectando las interacciones de distintos departamentos en un conjunto coherente. En los sistemas Veradigm (Allscripts), como Sunrise o Paragon, normalmente corresponde al identificador de visita o al número de encuentro. Por qué es importante Es la clave fundamental para Process Mining, ya que permite reconstruir el recorrido completo del paciente de principio a fin. Dónde obtenerlo Probablemente se encuentra en la cabecera de las tablas de visitas o encuentros, por ejemplo, VISIT_ID o ENCOUNTER_ID. Consulte la documentación de Veradigm (Allscripts). Ejemplos EP-2023-998877VIS-10029384100029384ENC-554433
	Marca de tiempo del evento EventDateTime	La fecha y hora exactas en las que ocurrió la actividad.
Descripción Registra el momento cronológico de la actividad. Es fundamental para calcular tiempos de ciclo y duraciones, así como para ordenar correctamente la secuencia de eventos. En los datos sanitarios, la precisión hasta el minuto es esencial para analizar con exactitud el flujo de pacientes. Por qué es importante Permite calcular todos los KPI basados en el tiempo, incluido el tiempo medio del ciclo del recorrido del paciente y los tiempos de espera. Dónde obtenerlo Marcas de tiempo de las transacciones en las tablas de origen, por ejemplo, ADT_DATE, ORDER_DATE y RESULT_DATE. Ejemplos 2023-10-12T08:30:00Z2023-10-12T14:45:22Z2023-10-15T09:00:00Z
	Nombre de la actividad ActivityName	El evento clínico o administrativo específico que se realizó.
Descripción Describe el paso realizado en el proceso, como «Patient Registered», «Medication Administered» o «Discharge Planning Initiated». Este atributo diferencia las distintas etapas del recorrido del paciente y es esencial para el descubrimiento de procesos y el análisis de variantes. Por qué es importante Define los nodos del mapa de procesos; sin él, no es posible visualizar ningún flujo de proceso. Dónde obtenerlo Se obtiene de diversas tablas transaccionales: eventos ADT, solicitudes, resultados y tablas de documentación clínica. Ejemplos Paciente registradoPrueba diagnóstica solicitadaMedicamento administradoPaciente dado de alta
	Código del diagnóstico principal PrimaryDiagnosisCode	El código ICD-10 o SNOMED que representa la afección principal.
Descripción El motivo codificado de la visita del paciente. Este atributo sirve como filtro para el «Treatment Pathway Variation Explorer». Permite a los analistas comparar cómo distintas afecciones, como la neumonía y la insuficiencia cardíaca, avanzan por el sistema. Por qué es importante Es necesario para segmentar los procesos por afección clínica y comprobar el cumplimiento de los protocolos. Dónde obtenerlo Tablas de diagnósticos o listas de problemas, normalmente con columnas ICD-10. Consulte la documentación de Veradigm (Allscripts). Ejemplos I50.9J18.9E11.9
	Destino al alta DischargeDisposition	El estado o la ubicación del paciente al recibir el alta.
Descripción Indica adónde fue el paciente después de la estancia hospitalaria, por ejemplo, «Home», «Skilled Nursing Facility», «Expired» o «Transfer». Es importante para analizar los riesgos de reingreso, ya que cada destino implica un perfil de riesgo diferente. Por qué es importante Aporta contexto al Dashboard de planificación del alta y ayuda a explicar las variaciones del ALOS. Dónde obtenerlo Tabla de cabecera de visitas o encuentros, por ejemplo, DISCH_DISP. Consulte la documentación de Veradigm (Allscripts). Ejemplos DomicilioTrasladado a un centro de enfermería especializadaDomicilio con atención médica domiciliariaAbandonó el centro contra recomendación médica
	Es una readmisión IsReadmission	Indicador que señala si este episodio corresponde a una readmisión en un plazo de 30 días.
Descripción Atributo booleano calculado. Devuelve true si el paciente tuvo un alta previa dentro de los 30 días anteriores a la fecha de admisión actual. Este dato alimenta el «Monitor de la tasa de readmisiones evitables». Por qué es importante KPI fundamental para la calidad hospitalaria y el reembolso, especialmente en relación con las normativas de CMS. Dónde obtenerlo Se calcula en la capa de ETL o transformación de datos mediante PatientMRN y las fechas de admisión y alta. Ejemplos truefalse
	Fecha de alta DischargeDate	La fecha y hora en las que el paciente recibió el alta.
Descripción La marca de tiempo que señala el final del episodio. Se utiliza para cerrar el caso en Process Mining y es esencial para calcular el ALOS y los reingresos. Por qué es importante Define el final del ciclo del proceso y es fundamental para analizar el flujo de pacientes. Dónde obtenerlo Tabla de cabecera de visitas o encuentros, por ejemplo, DISCH_DATE. Consulte la documentación de Veradigm (Allscripts). Ejemplos 2023-10-04T11:00:00Z2023-10-10T09:30:00Z
	Fecha de ingreso AdmissionDate	La fecha y hora en las que el paciente ingresó formalmente.
Descripción La marca de tiempo que señala el inicio de la estancia hospitalaria. Se utiliza junto con la fecha de alta para calcular la duración de la estancia (ALOS). Por qué es importante Punto de referencia fundamental para calcular el ALOS y medir los retrasos en los ingresos. Dónde obtenerlo Tabla de cabecera de visitas o encuentros, por ejemplo, ADMIT_DATE. Consulte la documentación de Veradigm (Allscripts). Ejemplos 2023-10-01T10:00:00Z2023-10-05T14:20:00Z
	MRN del paciente PatientMrn	Medical Record Number que identifica de forma única al paciente en los distintos episodios.
Descripción El Medical Record Number (MRN) o Enterprise Patient ID. A diferencia del identificador del episodio del paciente, este ID permanece constante para el paciente en las distintas visitas. Es la clave fundamental para vincular episodios separados y calcular las tasas de reingreso. Por qué es importante Esencial para la «tasa de reingreso en 30 días» y para identificar a pacientes recurrentes. Dónde obtenerlo Índice maestro de pacientes o tablas demográficas, probablemente con las columnas MRN y PATIENT_ID. Consulte la documentación de Veradigm (Allscripts). Ejemplos MRN-884422P-10022399887766
	Nombre del departamento DepartmentName	La unidad hospitalaria o el departamento donde tuvo lugar la actividad.
Descripción Indica el contexto de ubicación, como «Emergency Room», «Cardiology» o «Radiology». Es fundamental para el análisis de cuellos de botella de ingresos y traslados, ya que permite ver dónde se quedan bloqueados los pacientes al desplazarse entre unidades. Por qué es importante Facilita el análisis del uso de recursos y la identificación de cuellos de botella departamentales. Dónde obtenerlo Tablas maestras de ubicaciones o departamentos vinculadas a la transacción. Consulte la documentación de Veradigm (Allscripts). Ejemplos Servicio de urgenciasICUCirugía generalRadiología
	Profesional responsable AttendingProvider	El profesional clínico principal responsable del paciente durante el evento.
Descripción Identifica al médico, enfermero o especialista que realiza la actividad o es responsable del plan asistencial. Analizar este atributo ayuda a comprender el uso de recursos clínicos y las variaciones de las rutas asistenciales según el profesional médico. Por qué es importante Permite analizar los cuellos de botella de los recursos y comparar el rendimiento del personal clínico. Dónde obtenerlo Tablas de transacciones, por ejemplo, ORDERing_PROVIDER y ATTENDING_PHYSICIAN_ID. Consulte la documentación de Veradigm (Allscripts). Ejemplos Dra. Sarah SmithEnfermero practicante JonesTécnico de radiología A
	Centro de costos CostCenter	Código financiero asociado al departamento o servicio.
Descripción Relaciona la actividad clínica con una unidad financiera. Esto ayuda a analizar el «Costo de la actividad» o el desempeño financiero genérico de los distintos departamentos. Por qué es importante Conecta el Process Mining operativo con el impacto financiero. Dónde obtenerlo Tablas maestras de departamentos o cargos. Consulte la documentación de Veradigm (Allscripts). Ejemplos CC-1020CC-Rad-01Emergency-001
	Cumple el protocolo IsProtocolCompliant	Indicador que señala si el caso siguió la ruta de atención estándar.
Descripción Atributo calculado que comprueba si determinadas actividades obligatorias, por ejemplo, «Signos vitales registrados» antes de «Medicamento administrado», ocurrieron en el orden correcto. Es compatible con el «Dashboard de adherencia al protocolo de atención». Por qué es importante Automatiza la detección del incumplimiento sin necesidad de revisar manualmente las historias clínicas. Dónde obtenerlo Se calcula en la herramienta de Process Mining o mediante ETL a partir de la secuencia de actividades. Ejemplos truefalse
	Fecha de la cita de seguimiento FollowUpAppointmentDate	Fecha de la cita de seguimiento programada.
Descripción Se utiliza para calcular la «Tasa de citas de seguimiento programadas». Si este campo contiene un valor, indica que se programó una cita de seguimiento. Si es nulo o está vacío, no se programó. Por qué es importante Mide directamente el KPI de «Cumplimiento de la atención de seguimiento». Dónde obtenerlo Sistema de programación o tabla de citas futuras vinculada al paciente. Consulte la documentación de Veradigm (Allscripts). Ejemplos 2023-11-15T14:00:00Znull
	ID de la solicitud OrderId	Identificador de solicitudes específicas, como análisis, medicamentos y procedimientos.
Descripción Vincula el evento «Order» con el evento «Result» o «Administration». Por ejemplo, conecta «Diagnostic Test Ordered» con «Diagnostic Test Completed». Este nivel de detalle es necesario para el Dashboard de tiempo de respuesta diagnóstica. Por qué es importante Permite calcular la duración de pasos específicos del proceso, como el tiempo de respuesta del laboratorio. Dónde obtenerlo Tablas de entrada de solicitudes, por ejemplo, ORDER_ID y PLACER_ORDER_NUM. Consulte la documentación de Veradigm (Allscripts). Ejemplos ORD-998877LAB-112233RX-445566
	Nombre del medicamento MedicationName	El nombre del medicamento solicitado o administrado.
Descripción Se utiliza específicamente para el Dashboard de intervalos en la administración de medicamentos. Ayuda a identificar si determinados medicamentos, como antibióticos o analgésicos, sufren retrasos en su administración. Por qué es importante Esencial para analizar la seguridad clínica y optimizar los procesos de farmacia. Dónde obtenerlo Registro de administración de medicamentos (MAR) u órdenes de farmacia. Consulte la documentación de Veradigm (Allscripts). Ejemplos AmoxicilinaHeparinaSulfato de morfina
	Sistema de origen SourceSystem	El nombre del sistema del que proceden los datos.
Descripción Identifica la instancia de software que proporciona los datos, como «Veradigm Sunrise» o «Veradigm TouchWorks». Es especialmente importante en entornos con varios hospitales o al combinar datos de centros de atención aguda y ambulatoria. Por qué es importante Proporciona trazabilidad y linaje de datos, lo que resulta útil para depurar problemas de calidad de los datos. Dónde obtenerlo Se codifica durante el proceso ETL o se extrae de las tablas de metadatos del sistema. Ejemplos Veradigm SunriseAllscripts PMVeradigm TouchWorks
	Tiempo de respuesta del diagnóstico DiagnosticTurnaroundTime	Duración entre la solicitud de una prueba y la recepción de su resultado.
Descripción Duración calculada entre «Prueba diagnóstica solicitada» y «Diagnóstico confirmado» o recepción del resultado. Se utiliza en la «Vista general del tiempo de respuesta del diagnóstico». Por qué es importante Los tiempos de respuesta elevados prolongan la estancia hospitalaria; esta métrica identifica los retrasos en el laboratorio y radiología. Dónde obtenerlo Calculado como: Timestamp(Resultado) - Timestamp(Solicitud). Ejemplos 2 horas45 minutos1,5 días
	Última actualización de los datos LastDataUpdate	Marca de tiempo de la última extracción o actualización del registro.
Descripción Indica la actualidad de los datos utilizados para el análisis. Este campo ayuda a los usuarios a saber si consultan datos en tiempo real o una instantánea de un periodo anterior. Por qué es importante Garantiza la transparencia sobre la latencia de los datos y facilita las estrategias de carga incremental. Dónde obtenerlo Marca de tiempo generada por el sistema durante la ejecución de ETL o de extracción. Ejemplos 2023-11-01T23:59:59Z2023-11-02T06:00:00Z

Obligatorio Recomendado Opcional

Actividades del recorrido del paciente

Estos son los pasos clave y los hitos del proceso que debe capturar en su registro de eventos para descubrir con precisión el proceso de recorrido del paciente.

6 Recomendado 7 Opcional

	Actividad	Descripción
	Diagnóstico confirmado	Esta actividad indica que un profesional clínico ha registrado oficialmente un diagnóstico en la historia clínica del paciente. Puede capturarse cuando se añade un código de diagnóstico a la lista de problemas o cuando se firma una nota clínica que contiene el diagnóstico.
Por qué es importante La confirmación del diagnóstico es un punto de inflexión crucial que determina la ruta de tratamiento posterior. Permite analizar las variaciones de las rutas de tratamiento según los distintos diagnósticos. Dónde obtenerlo Se encuentra en la lista de problemas del paciente, los registros de diagnósticos del encuentro o la documentación clínica. Puede inferirse a partir de la marca de tiempo en la que se introduce y finaliza el código de diagnóstico principal del encuentro. Recopilar Utilice la marca de tiempo de creación o actualización de la entrada del diagnóstico principal correspondiente al episodio específico del paciente. Tipo de evento inferred
	Evaluación inicial completada	Representa la finalización de la primera evaluación clínica realizada por un enfermero o médico, como el triaje o la admisión inicial. A menudo se captura cuando un formulario o una nota clínica específica, como «Nursing Initial Assessment», se firma y finaliza en el EHR.
Por qué es importante Esta actividad es un hito inicial clave. El tiempo transcurrido entre el registro y esta evaluación permite detectar posibles retrasos en la admisión del paciente y la atención inicial. Dónde obtenerlo Se infiere a partir de la marca de tiempo de finalización o firma de los formularios de evaluación inicial o de las notas clínicas en los módulos de documentación clínica de Veradigm. Recopilar Identifique la marca de tiempo en la que el estado de la nota o el formulario de evaluación inicial cambia a «completed» o «signed». Tipo de evento inferred
	Inicio de la planificación del alta	Representa el inicio formal del proceso de planificación del alta de un paciente. Puede inferirse a partir de la creación de un documento de planificación del alta, la introducción de una orden de alta o la finalización de una evaluación específica de planificación del alta.
Por qué es importante Esta actividad es el punto de partida para medir la eficiencia del proceso de alta. El inicio temprano de la planificación suele asociarse con menores tasas de reingreso. Dónde obtenerlo Se infiere a partir de la marca de tiempo de creación de una nota de planificación del alta, un conjunto de órdenes de alta o un formulario de evaluación específico en Veradigm. Recopilar Identifique la marca de tiempo en la que se crea por primera vez una orden o un documento específico del alta para el encuentro del paciente. Tipo de evento inferred
	Paciente dado de alta	Marca el final oficial del episodio de hospitalización, cuando el paciente recibe formalmente el alta del centro. Es un evento explícito y clave que captura el sistema ADT, al actualizar el estado del encuentro del paciente a «discharged».
Por qué es importante Es la actividad final principal de la mayoría de los recorridos de pacientes. Resulta fundamental para calcular la duración media de la estancia (ALOS) y el tiempo total del ciclo del proceso. Dónde obtenerlo Se registra explícitamente en el módulo ADT. El registro del encuentro del paciente incluye una marca de tiempo del alta y el destino al alta. Recopilar Utilice la marca de tiempo del alta del registro principal del encuentro o de la visita del paciente. Tipo de evento explicit
	Paciente registrado	Marca el inicio oficial del episodio del paciente, cuando su información se introduce en el sistema Veradigm. Este evento suele capturarse explícitamente cuando un usuario completa el Workflow de registro y crea un nuevo registro de encuentro del paciente con un identificador único y una marca de tiempo.
Por qué es importante Es la actividad inicial principal del recorrido del paciente. Resulta esencial para calcular el tiempo total del ciclo del proceso, la duración de la estancia y las tasas de flujo de pacientes. Dónde obtenerlo Este evento se registra en el módulo de registro de pacientes o ADT (Admission, Discharge, Transfer). Busque la marca de tiempo de creación del registro del encuentro o de la visita del paciente. Recopilar Marca de tiempo de la tabla de encuentros o registros de registro del paciente, correspondiente a la creación del registro. Tipo de evento explicit
	Plan de tratamiento creado	Representa la formalización del plan de tratamiento del paciente por parte del equipo clínico. A menudo se captura cuando se crea y firma en el EHR un documento específico de «Plan of Care» o un conjunto inicial de órdenes de tratamiento.
Por qué es importante Este hito inicia la fase activa del tratamiento. Sirve como referencia para medir el cumplimiento de los protocolos asistenciales y el tiempo hasta la primera acción terapéutica, como la administración de un medicamento. Dónde obtenerlo Se infiere a partir de la marca de tiempo de firma de un formulario «Plan of Care» o de la marca de tiempo de creación del primer conjunto importante de órdenes terapéuticas posterior al diagnóstico. Recopilar Busque la marca de tiempo en la que el documento «Plan of Care» se finaliza o lo firma el profesional clínico responsable. Tipo de evento inferred
	Medicamento administrado	Este evento se registra cuando un enfermero o profesional clínico documenta la administración de un medicamento al paciente. Se captura en el módulo Medication Administration Record (MAR) o eMAR, que registra la hora exacta de administración.
Por qué es importante El seguimiento de la administración de medicamentos es fundamental para analizar la puntualidad y el cumplimiento del tratamiento. El intervalo entre la solicitud y la administración ayuda a identificar retrasos en el proceso de suministro de medicamentos. Dónde obtenerlo Se registra explícitamente en el módulo eMAR (electronic Medication Administration Record). Cada evento de administración incluye una marca de tiempo, el medicamento y la dosis específicos. Recopilar Extraiga las marcas de tiempo de la tabla eMAR para cada evento de administración de medicamentos vinculado al encuentro del paciente. Tipo de evento explicit
	Procedimiento realizado	Representa la finalización de un procedimiento clínico o quirúrgico. Normalmente se captura cuando un profesional clínico firma la nota del procedimiento o cuando el estado de la orden del procedimiento se actualiza a «completed» en el sistema.
Por qué es importante Los procedimientos son hitos importantes en muchos recorridos de pacientes. Analizar su momento permite comprender el uso de los recursos y la eficiencia de la programación. Dónde obtenerlo Se infiere a partir de la marca de tiempo de firma de una nota del procedimiento en el módulo de documentación clínica o de la marca de tiempo de finalización en el módulo de solicitudes correspondiente a dicho procedimiento. Recopilar Utilice la marca de tiempo de finalización de la solicitud del procedimiento o la marca de tiempo de firma de la documentación relacionada. Tipo de evento inferred
	Prueba diagnóstica completada	Representa el momento en que los resultados de una prueba diagnóstica se finalizan y quedan disponibles en el registro del paciente. Normalmente se infiere a partir de un cambio de estado de la solicitud original, de «active» o «in-progress» a «completed» o «resulted».
Por qué es importante Esta actividad es un hito fundamental para medir los tiempos de respuesta diagnóstica. Los retrasos entre la solicitud y la finalización pueden afectar significativamente al tiempo hasta el diagnóstico. Dónde obtenerlo Se infiere a partir del campo de estado de la solicitud en el módulo de solicitudes o de las marcas de tiempo del módulo de resultados correspondiente, como LIS o RIS. Recopilar Identifique la marca de tiempo en la que el estado de la solicitud cambia a un estado final como «Completed» o «Resulted». Tipo de evento inferred
	Prueba diagnóstica solicitada	Este evento ocurre cuando un profesional clínico solicita una prueba diagnóstica, como un análisis de laboratorio o una prueba de imagen. Se captura explícitamente mediante el sistema Computerized Physician Order Entry (CPOE) de Veradigm.
Por qué es importante Marca el inicio del subproceso diagnóstico. Es el punto de partida para medir los tiempos de respuesta diagnóstica e identificar retrasos en la solicitud de pruebas. Dónde obtenerlo Se registra en el módulo de solicitudes o en los registros del sistema CPOE. Cada solicitud incluye una marca de tiempo que indica cuándo se realizó. Recopilar Extraiga la marca de tiempo de creación de los registros de solicitudes correspondientes a las pruebas diagnósticas relevantes. Tipo de evento explicit
	Seguimiento programado	Esta actividad representa la programación de una cita de seguimiento para el paciente después del alta. El evento se captura en el módulo de programación cuando se reserva una cita vinculada al encuentro dado de alta.
Por qué es importante Garantizar la programación de la atención de seguimiento es fundamental para la continuidad asistencial y la reducción de los reingresos. Esta actividad ayuda a medir el cumplimiento de los protocolos posteriores al alta. Dónde obtenerlo Se registra en el módulo de programación de citas. Busque la marca de tiempo de creación de una nueva cita del paciente posterior a la fecha del alta. Recopilar Identifique la marca de tiempo de creación de un registro de cita en el sistema de programación vinculado al paciente. Tipo de evento explicit
	Signos vitales registrados	Esta actividad ocurre cada vez que se registran los signos vitales del paciente, como la frecuencia cardíaca, la presión arterial y la temperatura. Es un evento explícito que se captura en la documentación clínica o en la sección de hoja de flujo específica de signos vitales del EHR.
Por qué es importante El registro frecuente de los signos vitales indica una supervisión activa del paciente. La frecuencia y el momento de los registros pueden analizarse para garantizar el cumplimiento de los protocolos de monitorización. Dónde obtenerlo Se registra en el repositorio de datos clínicos o en las tablas de hojas de flujo donde se almacenan los signos vitales. Cada entrada incluye una marca de tiempo. Recopilar Extraiga las marcas de tiempo de los datos de la hoja de flujo de signos vitales correspondientes al encuentro del paciente. Tipo de evento explicit
	Traslado a otro departamento	Este evento marca el traslado físico de un paciente de un departamento o unidad asistencial a otro, por ejemplo, de urgencias a una planta de hospitalización. Se captura mediante el sistema ADT (Admission, Discharge, Transfer) de Veradigm.
Por qué es importante Los traslados de pacientes suelen ser puntos donde aparecen cuellos de botella y retrasos. Analizar su duración y frecuencia ayuda a optimizar el flujo de pacientes y la asignación de recursos entre departamentos. Dónde obtenerlo Se registra explícitamente en el módulo ADT. Cada evento de traslado incluye el paciente, las ubicaciones de origen y destino y una marca de tiempo. Recopilar Extraiga los registros de eventos del sistema ADT correspondientes a los movimientos de los pacientes. Tipo de evento explicit

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Veradigm (Allscripts)

Pasos

Identifique el canal de interfaz de destino: Inicie sesión en la consola de administración de Allscripts Interface Engine (AIE). Localice el canal de interfaz principal que procesa los mensajes entrantes del EHR, normalmente denominado «EHR_Inbound» o similar. Asegúrese de que este canal gestione los tipos de mensaje ADT, SIU, ORM, ORU, RAS y DFT para capturar todo el alcance de las actividades del recorrido del paciente.
Cree un nuevo canal de transferencia o exportación: Cree un nuevo canal de destino denominado «ProcessMining_Export». Establezca el tipo de salida como «File Writer». Este canal recibirá una copia de los mensajes del canal de origen y los transformará en un archivo plano en formato CSV para ProcessMind.
Configure el enrutamiento de mensajes: En las reglas de enrutamiento de AIE, configure una regla de copia o enrutamiento para enviar los mensajes del canal principal del EHR al nuevo canal «ProcessMining_Export». Filtre el enrutamiento para incluir únicamente los tipos de mensaje necesarios: ADT (registro o traslado), SIU (programación), ORM (órdenes), ORU (resultados o signos vitales), RAS (medicamentos) y DFT (facturación o procedimientos).
Defina la lógica de transformación: Dentro del canal «ProcessMining_Export», abra el editor de transformación o scripts. Debe implementar un script de análisis, consulte la sección «query» más abajo, que lea los segmentos HL7 sin procesar y asigne eventos Trigger y códigos de estado específicos a los nombres de actividad estándar requeridos, por ejemplo, asignar «ADT^A01» a «Paciente registrado».
Asigne los atributos a los campos HL7: Asegúrese de que el script extraiga «PatientEpisodeId» del segmento PV1-19 (número de visita) y «PatientMrn» de PID-3. Asigne «EventDateTime» a MSH-7 o EVN-2. Extraiga detalles clínicos como «DepartmentName» de PV1-3 y «AttendingProvider» de PV1-7.
Configure los parámetros del archivo de salida: Configure los ajustes de File Writer. Establezca el directorio de salida en una ruta de red segura. Defina la convención de nombres de archivo, por ejemplo, EventLog_YYYYMMDD_HH.csv. Establezca el modo de archivo como «Append» para añadir filas continuamente al Registro de eventos.
Gestione los delimitadores y el escape de caracteres: En el script, asegúrese de que los campos de texto, como Diagnosis o Department Name, se limpien para eliminar comas o saltos de línea y evitar que se rompa la estructura CSV.
Active y pruebe: Inicie el canal «ProcessMining_Export». Genere un evento de prueba en el entorno de pruebas de Veradigm, por ejemplo, registre a un paciente de prueba. Compruebe que aparezca una nueva fila en el archivo CSV con el nombre de actividad y la marca de tiempo correctos.
Configure la rotación de registros: Configure un calendario de rotación, por ejemplo, diariamente a medianoche, para cerrar el archivo CSV actual e iniciar uno nuevo. Así los archivos tendrán un tamaño manejable para su carga.
Reproducción de datos históricos (opcional): Si necesita datos históricos, utilice la herramienta «Message Browser» o «Log Replay» de AIE para reenviar los registros HL7 archivados de los últimos 3 a 6 meses a través del canal «ProcessMining_Export». Supervise el rendimiento del sistema para evitar retrasos.
Recupere y dé formato a los datos: Acceda al directorio de salida, recupere los archivos CSV generados y compruebe que los encabezados coincidan con los requisitos. Combine los archivos diarios si es necesario.
Cargue los datos en ProcessMind: Importe el conjunto de datos final en ProcessMind y asigne «PatientEpisodeId» como Case ID, «ActivityName» como Activity y «EventDateTime» como Timestamp.

Configuración

Tipo de canal: File Writer / salida del sistema de archivos
Eventos Trigger: ADT^A01, ADT^A03, ADT^A04, ADT^A08, SIU^S12, ORM^O01, ORU^R01, RAS^O17, DFT^P03
Codificación del archivo: UTF-8, fundamental para los caracteres especiales de nombres y diagnósticos
Delimitador: Coma (,) o barra vertical (|)
Formato de fecha: Se recomienda ISO 8601 (YYYY-MM-DDTHH:MM:SS) para convertir las marcas de tiempo HL7
Rotación de registros: Diaria o cuando el tamaño del archivo supere los 100 MB
Modo de escritura: Append, no sobrescribir
Rendimiento: Asegúrese de que el script de transformación sea ligero para evitar colas o acumulación de mensajes en el motor.

a Consulta de ejemplo config

// AIE Transformation Script (Pseudo-code for Config)
// Objective: Parse HL7 message and append line to CSV
// Output Columns: PatientEpisodeId, ActivityName, EventDateTime, PatientMrn, AttendingProvider, DepartmentName, PrimaryDiagnosisCode

// 1. Initialize Variables
var msgType = HL7.GetField("MSH-9-1") + "^" + HL7.GetField("MSH-9-2");
var visitNumber = HL7.GetField("PV1-19");
var mrn = HL7.GetField("PID-3");
var eventTime = HL7.GetField("MSH-7"); // Or EVN-2
var provider = HL7.GetField("PV1-7");
var dept = HL7.GetField("PV1-3");
var diagnosis = HL7.GetField("DG1-3"); // For Diagnosis events
var orderStatus = HL7.GetField("ORC-5");
var resultStatus = HL7.GetField("OBR-25");
var activityName = "";

// 2. Map Message Types to Activities
// Registration & Admission
if (msgType == "ADT^A04" || msgType == "ADT^A01") {
    activityName = "Patient Registered";
}
else if (msgType == "ADT^A02") {
    activityName = "Transfer to Department";
}
else if (msgType == "ADT^A03") {
    activityName = "Patient Discharged";
}
// Scheduling
else if (msgType == "SIU^S12") {
    activityName = "Follow-up Scheduled";
}
// Orders (Diagnostics, Care Plans, Discharge Planning)
else if (msgType == "ORM^O01") {
    var orderControl = HL7.GetField("ORC-1");
    var orderType = HL7.GetField("OBR-4"); // Check for specific service codes
    
    if (orderControl == "NW") { // New Order
        if (orderType.Contains("LAB") || orderType.Contains("RAD")) {
            activityName = "Diagnostic Test Ordered";
        }
        else if (orderType.Contains("DISCHARGE")) {
            activityName = "Discharge Planning Initiated";
        }
        else if (orderType.Contains("CARE_PLAN")) {
            activityName = "Treatment Plan Created";
        }
    }
}
// Results & Vitals
else if (msgType == "ORU^R01") {
    // Check if it is Vitals or Lab Result based on OBX codes or sending app
    var observationId = HL7.GetField("OBX-3"); 
    if (observationId.Contains("VITALS")) {
        activityName = "Vitals Recorded";
    } else {
        if (resultStatus == "F" || resultStatus == "C") {
            activityName = "Diagnostic Test Completed";
        }
    }
    
    // Initial Assessment Check (often a specific doc type in ORU or MDM)
    if (observationId.Contains("INITIAL_ASSESS")) {
        activityName = "Initial Assessment Completed";
    }
}
// Medication Administration (RAS)
else if (msgType == "RAS^O17") {
    activityName = "Medication Administered";
}
// Billing/Procedures (DFT)
else if (msgType == "DFT^P03") {
    activityName = "Procedure Performed";
}
// Diagnosis Updates (Often in ADT or DFT, logic depends on config)
else if (msgType == "ADT^A08" && diagnosis != "") {
    // Check if diagnosis segment is new/updated
    activityName = "Diagnosis Confirmed";
}

// 3. Write to File if Activity Identified
if (activityName != "" && visitNumber != "") {
    // Format Date to ISO
    var formattedDate = FormatDate(eventTime, "yyyy-MM-dd HH:mm:ss");
    
    // Construct CSV Line
    var csvLine = visitNumber + "," + 
                  activityName + "," + 
                  formattedDate + "," + 
                  mrn + "," + 
                  provider + "," + 
                  dept + "," + 
                  diagnosis;
                  
    File.WriteLine("[Configured_Output_Path]\\PatientJourneyLog.csv", csvLine);
}

Pasos

Requisitos previos y acceso: Asegúrese de disponer de credenciales válidas para la API Unity de Veradigm (Allscripts). Necesitará un Appname (nombre de aplicación) autorizado para su organización, además de un UserID y una Password válidos, o un token, para la autenticación. Compruebe que la cuenta de usuario tenga permisos para acceder a los dominios clínicos, incluidos Encounters, Orders, Results, Vitals y Problems.
Configuración del entorno: Instale Python 3.8 o una versión posterior. Instale las bibliotecas necesarias mediante pip: pip install requests pandas. Se utilizarán para realizar solicitudes HTTP a la API Unity y manipular los datos resultantes.
Configuración: Abra el script de Python proporcionado. Localice la sección CONFIGURATION al principio. Actualice API_URL para que apunte al endpoint específico de su entorno Unity, por ejemplo, unity.veradigm.com o una puerta de enlace interna. Sustituya las credenciales de ejemplo ([YourAppName], [YourUserID], etc.) por sus credenciales reales. Establezca START_DATE y END_DATE según el periodo de análisis que desea utilizar.
Descripción general de la lógica del script: El script comienza autenticándose en la API para obtener un token de seguridad. Después llama a GetEncounterInfo para recuperar todos los episodios de pacientes dentro del intervalo de fechas especificado. Esta lista de encuentros sirve como iterador central de la extracción.
Bucle de extracción de actividades: Para cada EncounterID identificado, el script realiza llamadas secundarias a endpoints especializados. Llama a GetOrders para encontrar pruebas diagnósticas y procedimientos. Llama a GetResults para identificar las pruebas completadas. Llama a GetVitals para obtener los registros de signos vitales. Llama a GetPatientProblems para obtener los diagnósticos confirmados. También recorre las notas clínicas para encontrar evaluaciones y planes de tratamiento.
Transformación de datos: A medida que la API devuelve datos JSON sin procesar, el script analiza campos específicos para asignarlos al esquema de ProcessMind. Por ejemplo, OrderDateTime se asigna a EventDateTime para la actividad «Prueba diagnóstica solicitada». El script garantiza que PatientEpisodeId (ID del encuentro) se aplique de forma coherente a todos los registros secundarios.
Gestión de ADT y traslados: La lógica del script comprueba el historial de ubicaciones del encuentro, si está disponible mediante llamadas específicas de auditoría o ADT, o infiere los traslados a partir de los cambios de departamento en la documentación clínica para generar eventos de «Traslado al departamento».
Lógica de seguimiento: Después de procesar el encuentro, el script consulta GetSchedule para el mismo PatientID y busca fechas de citas posteriores a DischargeDate con el fin de generar la actividad «Seguimiento programado».
Validación: El script incluye un paso de validación local que muestra en la consola el número de filas por tipo de actividad. Revise este resultado para asegurarse de que ningún tipo de actividad tenga cero registros, salvo que sea lo esperado.
Exportación: El conjunto de datos final se agrega en un DataFrame de Pandas. El script calcula atributos derivados como LengthOfStay e IsReadmission ordenando los datos por paciente y hora. Finalmente, exporta el Registro de eventos limpio a un archivo CSV denominado veradigm_patient_journey_log.csv.
Revisión final: Abra el archivo CSV generado. Compruebe que los formatos de fecha sean ISO 8601 (YYYY-MM-DD HH:MM:SS) y que los campos de texto, como ActivityName, no contengan caracteres delimitadores.
Carga: Importe el archivo CSV en ProcessMind. Asigne PatientEpisodeId a Case ID, ActivityName a Activity y EventDateTime a Timestamp.

Configuración

API_URL: URL base de los servicios de la API Unity. Varía según la instalación del cliente, por ejemplo, local o en la nube. Asegúrese de que el protocolo https sea correcto.
Appname: Identificador único de la aplicación registrada en Veradigm/Allscripts. Controla el alcance del acceso a los datos.
Intervalo de fechas: Se recomienda extraer datos de un periodo de 3 a 6 meses. Los intervalos amplios pueden agotar el tiempo de espera; si el volumen es elevado, considere dividir la extracción por meses.
Configuración del tiempo de espera: El script utiliza un tiempo de espera predeterminado de 30 segundos para las llamadas a la API. Auméntelo si el sistema EHR soporta una carga elevada.
Procesamiento por lotes: El script itera por encuentro. En sistemas de gran volumen, puede ser necesario modificarlo para obtener datos en bloque, si los endpoints lo permiten, o ejecutar hilos en paralelo.
Lógica de asignación: El script asigna OrderType a las actividades. Asegúrese de que los códigos específicos de tipo de orden de su sistema, por ejemplo, «Lab» o «Rad», coincidan con la lógica de la función process_orders.

a Consulta de ejemplo python

import requests
import pandas as pd
import json
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># === CONFIGURATION ===
API_URL = class="hl-string">"https://unity.veradigm.com/[YourEnvironment]/unity/unityservice.svc/json"
APP_NAME = class="hl-string">"[YourAppName]"
USER_ID = class="hl-string">"[YourUserID]"
PASSWORD = class="hl-string">"[YourPassword]"
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-01-31"
OUTPUT_FILE = class="hl-string">"veradigm_patient_journey_log.csv"

class=class="hl-string">"hl-comment"># Global Session Token
TOKEN = None

def get_security_token():
    class="hl-string">"""Authenticate and retrieve security token."""
    payload = {
        class="hl-string">"Action": class="hl-string">"GetToken",
        class="hl-string">"Appname": APP_NAME,
        class="hl-string">"Username": USER_ID,
        class="hl-string">"Password": PASSWORD
    }
    try:
        response = requests.post(API_URL, json=payload)
        response.raise_for_status()
        data = response.json()
        class=class="hl-string">"hl-comment"># Depending on Unity version, token might be in body or header. Assuming body here.
        return data[0][class="hl-string">'Token'] if isinstance(data, list) else data.get(class="hl-string">'Token')
    except Exception as e:
        print(fclass="hl-string">"Authentication failed: {e}")
        return None

def make_unity_request(action, params):
    class="hl-string">"""Wrapper for Unity API calls."""
    payload = {
        class="hl-string">"Action": action,
        class="hl-string">"Appname": APP_NAME,
        class="hl-string">"Token": TOKEN
    }
    payload.update(params)
    
    try:
        response = requests.post(API_URL, json=payload, timeout=30)
        response.raise_for_status()
        class=class="hl-string">"hl-comment"># Unity often returns a list of dictionaries
        return response.json()
    except Exception as e:
        print(fclass="hl-string">"API Call Error ({action}): {e}")
        return []

def extract_patient_journey():
    global TOKEN
    TOKEN = get_security_token()
    if not TOKEN:
        return

    print(class="hl-string">"Token acquired. Starting extraction...")
    
    event_log = []

    class=class="hl-string">"hl-comment"># 1. Get Encounters within Date Range
    class=class="hl-string">"hl-comment"># Using GetEncounterInfo or similar search action
    encounters = make_unity_request(class="hl-string">"GetEncounterInfo", {
        class="hl-string">"StartEncounterDate": START_DATE,
        class="hl-string">"EndEncounterDate": END_DATE
    })

    print(fclass="hl-string">"Found {len(encounters)} encounters. Processing details...")

    for enc in encounters:
        try:
            class=class="hl-string">"hl-comment"># Basic Encounter Data
            episode_id = str(enc.get(class="hl-string">'EncounterID'))
            patient_id = enc.get(class="hl-string">'PatientID')
            mrn = enc.get(class="hl-string">'MRN', class="hl-string">'')
            admit_time = enc.get(class="hl-string">'EncounterDate') class=class="hl-string">"hl-comment"># ISO string expected
            discharge_time = enc.get(class="hl-string">'DischargeDate')
            dept_name = enc.get(class="hl-string">'Department', class="hl-string">'General')
            attending = enc.get(class="hl-string">'ProviderName', class="hl-string">'Unknown')
            
            class=class="hl-string">"hl-comment"># --- Activity: Patient Registered ---
            if admit_time:
                event_log.append({
                    class="hl-string">"PatientEpisodeId": episode_id,
                    class="hl-string">"ActivityName": class="hl-string">"Patient Registered",
                    class="hl-string">"EventDateTime": admit_time,
                    class="hl-string">"PatientMrn": mrn,
                    class="hl-string">"AttendingProvider": attending,
                    class="hl-string">"DepartmentName": dept_name,
                    class="hl-string">"AdmissionDate": admit_time,
                    class="hl-string">"DischargeDate": discharge_time
                })

            class=class="hl-string">"hl-comment"># --- Activity: Patient Discharged ---
            if discharge_time:
                 event_log.append({
                    class="hl-string">"PatientEpisodeId": episode_id,
                    class="hl-string">"ActivityName": class="hl-string">"Patient Discharged",
                    class="hl-string">"EventDateTime": discharge_time,
                    class="hl-string">"PatientMrn": mrn,
                    class="hl-string">"AttendingProvider": attending,
                    class="hl-string">"DepartmentName": dept_name,
                    class="hl-string">"AdmissionDate": admit_time,
                    class="hl-string">"DischargeDate": discharge_time
                })

            class=class="hl-string">"hl-comment"># 2. Get Orders (Labs, Procedures, Consults)
            orders = make_unity_request(class="hl-string">"GetOrders", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for order in orders:
                order_time = order.get(class="hl-string">'OrderDate')
                order_type = order.get(class="hl-string">'OrderType', class="hl-string">'').lower()
                order_name = order.get(class="hl-string">'OrderName', class="hl-string">'Unknown Order')
                
                class=class="hl-string">"hl-comment"># --- Activity: Diagnostic Test Ordered ---
                if class="hl-string">'lab' in order_type or class="hl-string">'imaging' in order_type or class="hl-string">'radiology' in order_type:
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Diagnostic Test Ordered",
                        class="hl-string">"EventDateTime": order_time,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_OrderName": order_name
                    })

                class=class="hl-string">"hl-comment"># --- Activity: Procedure Performed ---
                class=class="hl-string">"hl-comment"># Often procedures are orders with status completed or specific types
                if class="hl-string">'procedure' in order_type and order.get(class="hl-string">'Status') == class="hl-string">'Completed':
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Procedure Performed",
                        class="hl-string">"EventDateTime": order.get(class="hl-string">'CompletionDate', order_time),
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_ProcedureName": order_name
                    })
                    
                class=class="hl-string">"hl-comment"># --- Activity: Discharge Planning Initiated ---
                if class="hl-string">'discharge' in order_name.lower():
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Discharge Planning Initiated",
                        class="hl-string">"EventDateTime": order_time,
                        class="hl-string">"PatientMrn": mrn
                    })

            class=class="hl-string">"hl-comment"># 3. Get Results (Lab completion)
            results = make_unity_request(class="hl-string">"GetResults", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for res in results:
                result_time = res.get(class="hl-string">'ResultDate')
                if result_time:
                    class=class="hl-string">"hl-comment"># --- Activity: Diagnostic Test Completed ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Diagnostic Test Completed",
                        class="hl-string">"EventDateTime": result_time,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_ResultName": res.get(class="hl-string">'TestName', class="hl-string">'Unknown Test')
                    })

            class=class="hl-string">"hl-comment"># 4. Get Problems (Diagnosis)
            problems = make_unity_request(class="hl-string">"GetPatientProblems", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for prob in problems:
                onset_date = prob.get(class="hl-string">'OnsetDate') or prob.get(class="hl-string">'DateEntered')
                if onset_date:
                     class=class="hl-string">"hl-comment"># --- Activity: Diagnosis Confirmed ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Diagnosis Confirmed",
                        class="hl-string">"EventDateTime": onset_date,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"PrimaryDiagnosisCode": prob.get(class="hl-string">'ICD10', class="hl-string">''),
                        class="hl-string">"Attribute_DiagnosisName": prob.get(class="hl-string">'ProblemDescription', class="hl-string">'')
                    })

            class=class="hl-string">"hl-comment"># 5. Get Vitals
            vitals = make_unity_request(class="hl-string">"GetVitals", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for vit in vitals:
                taken_time = vit.get(class="hl-string">'DateTaken')
                if taken_time:
                    class=class="hl-string">"hl-comment"># --- Activity: Vitals Recorded ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Vitals Recorded",
                        class="hl-string">"EventDateTime": taken_time,
                        class="hl-string">"PatientMrn": mrn
                    })

            class=class="hl-string">"hl-comment"># 6. Get Clinical Notes (Assessments, Plans)
            class=class="hl-string">"hl-comment"># Sometimes accessed via GetNoteInfo or GetChart
            notes = make_unity_request(class="hl-string">"GetNoteInfo", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for note in notes:
                note_date = note.get(class="hl-string">'NoteDate')
                note_title = note.get(class="hl-string">'DocumentType', class="hl-string">'').lower()
                
                class=class="hl-string">"hl-comment"># --- Activity: Initial Assessment Completed ---
                if class="hl-string">'initial' in note_title or class="hl-string">'assessment' in note_title:
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Initial Assessment Completed",
                        class="hl-string">"EventDateTime": note_date,
                        class="hl-string">"PatientMrn": mrn
                    })
                
                class=class="hl-string">"hl-comment"># --- Activity: Treatment Plan Created ---
                if class="hl-string">'plan' in note_title or class="hl-string">'care' in note_title:
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Treatment Plan Created",
                        class="hl-string">"EventDateTime": note_date,
                        class="hl-string">"PatientMrn": mrn
                    })

            class=class="hl-string">"hl-comment"># 7. Med Administration (GetMedicationAdministration or inferred from Med History)
            meds = make_unity_request(class="hl-string">"GetMedicationAdministration", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for med in meds:
                admin_time = med.get(class="hl-string">'AdministrationDate')
                if admin_time:
                    class=class="hl-string">"hl-comment"># --- Activity: Medication Administered ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Medication Administered",
                        class="hl-string">"EventDateTime": admin_time,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_MedicationName": med.get(class="hl-string">'MedicationName', class="hl-string">'')
                    })

            class=class="hl-string">"hl-comment"># 8. Transfer Events (Infer from ADT or Audit log)
            class=class="hl-string">"hl-comment"># Simulating transfer extraction via AuditLog for Location changes
            audit_logs = make_unity_request(class="hl-string">"GetAuditLog", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for log in audit_logs:
                if class="hl-string">"Transfer" in log.get(class="hl-string">'EventName', class="hl-string">'') or class="hl-string">"Location Change" in log.get(class="hl-string">'EventName', class="hl-string">''):
                     class=class="hl-string">"hl-comment"># --- Activity: Transfer to Department ---
                     event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Transfer to Department",
                        class="hl-string">"EventDateTime": log.get(class="hl-string">'EventDate'),
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"DepartmentName": log.get(class="hl-string">'NewValue', class="hl-string">'Unknown Dept')
                     })

            class=class="hl-string">"hl-comment"># 9. Follow-up Scheduled
            if discharge_time:
                future_appts = make_unity_request(class="hl-string">"GetSchedule", {class="hl-string">"PatientID": patient_id, class="hl-string">"StartDate": discharge_time})
                for appt in future_appts:
                    class=class="hl-string">"hl-comment"># --- Activity: Follow-up Scheduled ---
                    class=class="hl-string">"hl-comment"># Note: We want the time the appt was BOOKED, but Unity usually gives ApptDate.
                    class=class="hl-string">"hl-comment"># We will use the creation date of the appt if available, otherwise ApptDate as proxy
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Follow-up Scheduled",
                        class="hl-string">"EventDateTime": appt.get(class="hl-string">'DateBooked', appt.get(class="hl-string">'ApptDate')), 
                        class="hl-string">"PatientMrn": mrn
                    })

        except Exception as e:
            print(fclass="hl-string">"Error processing encounter {enc.get('EncounterID')}: {e}")
            continue

    class=class="hl-string">"hl-comment"># Post-Processing: Create DataFrame
    df = pd.DataFrame(event_log)
    
    class=class="hl-string">"hl-comment"># Helper: Convert strings to datetime
    df[class="hl-string">'EventDateTime'] = pd.to_datetime(df[class="hl-string">'EventDateTime'], errors=class="hl-string">'coerce')
    df = df.dropna(subset=[class="hl-string">'EventDateTime', class="hl-string">'PatientEpisodeId'])
    
    class=class="hl-string">"hl-comment"># Calculate LOS and Readmission
    df[class="hl-string">'AdmissionDate'] = pd.to_datetime(df[class="hl-string">'AdmissionDate'], errors=class="hl-string">'coerce')
    df[class="hl-string">'DischargeDate'] = pd.to_datetime(df[class="hl-string">'DischargeDate'], errors=class="hl-string">'coerce')
    
    class=class="hl-string">"hl-comment"># LOS
    df[class="hl-string">'LengthOfStay'] = (df[class="hl-string">'DischargeDate'] - df[class="hl-string">'AdmissionDate']).dt.days

    class=class="hl-string">"hl-comment"># IsReadmission (Simplified: check if patient had previous discharge within 30 days)
    class=class="hl-string">"hl-comment"># Requires sorting by patient and admission time first
    class=class="hl-string">"hl-comment"># This is complex in a flat event log context, simplified here as placeholder logic
    df[class="hl-string">'IsReadmission'] = False 

    print(fclass="hl-string">"Extraction complete. Rows: {len(df)}")
    df.to_csv(OUTPUT_FILE, index=False)
    print(fclass="hl-string">"Data saved to {OUTPUT_FILE}")

if __name__ == class="hl-string">"__main__":
    extract_patient_journey()

¿Listo para comenzar?

Comience hoy mismo su camino hacia la optimización de la experiencia del paciente y la eficiencia operativa. Sus datos contienen la clave para descubrir información valiosa e impulsar mejoras significativas.

Volver a la guía de mejora Descargar Template

Optimice hoy los recorridos de pacientes en Veradigm

Consiga ciclos de atención de pacientes un 30 % más rápidos y mejores resultados clínicos.

Iniciar la prueba gratuita

No necesita tarjeta de crédito. Comience al instante.

Su Template de datos del recorrido del paciente

Su Template de datos del recorrido del paciente

Atributos del recorrido del paciente

Actividades del recorrido del paciente

Guías de extracción

Exportación del Registro de eventos del motor de interfaces de Allscripts

Pasos

Configuración

a Consulta de ejemplo config

Extracción de la API Unity de Veradigm mediante Python

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Optimice hoy los recorridos de pacientes en Veradigm

Su Template de datos del recorrido del paciente

Su Template de datos del recorrido del paciente

Atributos del recorrido del paciente

Actividades del recorrido del paciente

Guías de extracción

Exportación del Registro de eventos del motor de interfaces de Allscripts

Pasos

Configuración

a Consulta de ejemplo config

Extracción de la API Unity de Veradigm mediante Python

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Optimice hoy los recorridos de pacientes en Veradigm

Valoramos su privacidad