> 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

Este Template ofrece un método estructurado para recopilar los datos necesarios para analizar el proceso del recorrido del paciente. Incluye los atributos y las actividades esenciales que debe registrar, además de indicaciones prácticas para extraer esta información de su sistema de origen. Utilice este recurso para preparar sus datos para un análisis completo con Process Mining.

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

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

Descargar Template

Atributos del recorrido del paciente

Estos son los campos de datos recomendados para incluir en su Registro de eventos y analizar en profundidad el proceso del recorrido del paciente.

3 Obligatorio 8 Recomendado 8 Opcional

	Nombre	Descripción
	Episodio del paciente PatientEpisodeId	Identificador único de la visita o atención específica del paciente.
Descripción El episodio del paciente funciona como identificador principal del caso y agrupa todos los eventos relacionados con un recorrido de atención específico, para una afección o un periodo de atención determinados. Esto permite integrar las fases de diagnóstico, tratamiento y recuperación, y reunir en un conjunto coherente las interacciones con distintos departamentos. En los sistemas Veradigm (Allscripts), como Sunrise o Paragon, suele corresponder al ID de visita o al número de atención. Por qué es importante Es la clave fundamental para Process Mining, ya que permite reconstruir el recorrido completo del paciente. Dónde obtenerlo Probablemente se encuentra en el encabezado de las tablas de visitas o atenciones (por ejemplo, VISIT_ID, ENCOUNTER_ID). Consulte la documentación de Veradigm (Allscripts). Ejemplos EP-2023-998877VIS-10029384100029384ENC-554433
	Marca de tiempo del evento EventDateTime	Fecha y hora exactas en que se produjo la actividad.
Descripción Registra el momento cronológico de la actividad. Es fundamental para calcular los tiempos de ciclo y las duraciones, y ordenar correctamente la secuencia de eventos. En los datos sanitarios, la precisión al minuto es esencial para analizar con exactitud el flujo de pacientes. Por qué es importante Permite calcular todos los KPI basados en el tiempo, incluidos 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, RESULT_DATE). Ejemplos 2023-10-12T08:30:00Z2023-10-12T14:45:22Z2023-10-15T09:00:00Z
	Nombre de la actividad ActivityName	Evento clínico o administrativo específico que se llevó a cabo.
Descripción Describe el paso realizado en el proceso, como «Paciente registrado», «Medicamento administrado» o «Inicio de la planificación del alta». Este atributo distingue las distintas etapas del recorrido del paciente y es esencial para descubrir procesos y analizar variantes. Por qué es importante Define los nodos del mapa de procesos; sin este atributo no es posible visualizar el flujo del proceso. Dónde obtenerlo Se obtiene de distintas tablas transaccionales: eventos ADT, órdenes, 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	Código ICD-10 o SNOMED que representa la afección principal.
Descripción Motivo codificado de la visita del paciente. Este atributo sirve como filtro para el explorador de variaciones en las vías de tratamiento. Permite 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	Estado o ubicación del paciente al recibir el alta.
Descripción Indica adónde fue el paciente después de su estancia en el hospital (p. ej., «Domicilio», «Centro de enfermería especializada», «Fallecido», «Traslado»). Este dato es importante para analizar el riesgo de reingreso, ya que cada destino conlleva distintos niveles de riesgo. Por qué es importante Aporta contexto al Dashboard «Planificación del alta» y ayuda a explicar las variaciones en la estancia media (ALOS). Dónde obtenerlo Tabla de encabezado de visita/encuentro (p. ej., DISCH_DISP). Consulte la documentación de Veradigm (Allscripts). Ejemplos DomicilioTraslado a un centro de enfermería especializadaDomicilio con atención médica a domicilioSe retiró contra el consejo médico
	Es un reingreso IsReadmission	Indicador que señala si el episodio corresponde a un reingreso dentro de los 30 días.
Descripción Atributo booleano calculado. Devuelve verdadero si el paciente recibió el alta en los 30 días anteriores a la fecha del ingreso actual. Este dato alimenta el «Monitor de la tasa de reingresos evitables». Por qué es importante KPI fundamental para la calidad hospitalaria y el reembolso, especialmente en relación con las regulaciones de CMS. Dónde obtenerlo Se calcula en la capa de ETL/transformación de datos a partir de PatientMRN y las fechas de ingreso y alta. Ejemplos truefalse
	Fecha de alta DischargeDate	Fecha y hora en que se dio de alta al paciente.
Descripción Marca el final del episodio. Se utiliza para cerrar el caso en Process Mining y es esencial para calcular la estancia media (ALOS) y los reingresos. Por qué es importante Define el final del ciclo del proceso y es fundamental para analizar el rendimiento. Dónde obtenerlo Tabla de encabezado de visita/encuentro (p. ej., DISCH_DATE). Consulte la documentación de Veradigm (Allscripts). Ejemplos 2023-10-04T11:00:00Z2023-10-10T09:30:00Z
	Fecha de ingreso AdmissionDate	Fecha y hora en que se ingresó formalmente al paciente.
Descripción 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 media de la estancia (ALOS). Por qué es importante Punto de referencia fundamental para calcular la duración media de la estancia y medir las demoras en los ingresos. Dónde obtenerlo Tabla de encabezados de visitas o atenciones (por ejemplo, ADMIT_DATE). Consulte la documentación de Veradigm (Allscripts). Ejemplos 2023-10-01T10:00:00Z2023-10-05T14:20:00Z
	Nombre del departamento DepartmentName	Unidad o departamento del hospital donde se realizó la actividad.
Descripción Indica el contexto de ubicación, como «Urgencias», «Cardiología» o «Radiología». Es fundamental para el análisis de cuellos de botella en ingresos y traslados, ya que permite ver dónde se producen demoras al trasladar pacientes entre unidades. Por qué es importante Facilita el análisis del uso de los recursos y la identificación de cuellos de botella en los departamentos. Dónde obtenerlo Tablas maestras de ubicaciones o departamentos vinculadas a la transacción. Consulte la documentación de Veradigm (Allscripts). Ejemplos Departamento de urgenciasICUCirugía generalRadiología
	Número de historia clínica del paciente (MRN) PatientMrn	Número de historia clínica que identifica de forma única al paciente en todos sus episodios.
Descripción El número de historia clínica (MRN) o el ID empresarial del paciente. A diferencia del ID del episodio del paciente, este identificador se mantiene igual en las distintas visitas. Es la clave fundamental para vincular episodios separados y calcular las tasas de reingreso. Por qué es importante Esencial para calcular la tasa de reingresos en un plazo de 30 días e identificar a pacientes que regresan. Dónde obtenerlo Índice maestro de pacientes o tablas demográficas (posibles columnas: MRN, PATIENT_ID). Consulte la documentación de Veradigm (Allscripts). Ejemplos MRN-884422P-10022399887766
	Profesional clínico responsable AttendingProvider	Profesional clínico principal responsable del paciente durante el evento.
Descripción Identifica al médico, la enfermera o el especialista que realiza la actividad o es responsable del plan de atención. Analizar este atributo ayuda a comprender el uso de los recursos clínicos y las variaciones en las vías de atención según el profesional médico. Por qué es importante Permite analizar los cuellos de botella relacionados con los recursos y comparar el desempeño del personal clínico. Dónde obtenerlo Tablas transaccionales (por ejemplo, ORDERING_PROVIDER, ATTENDING_PHYSICIAN_ID). Consulte la documentación de Veradigm (Allscripts). Ejemplos Dra. Sarah SmithEnfermero practicante JonesTécnico de radiología A
	Centro de coste CostCenter	Código financiero asociado al departamento o servicio.
Descripción Asocia la actividad clínica con una unidad financiera. Esto ayuda a analizar el «Coste de la actividad» y el rendimiento financiero general de los distintos departamentos. Por qué es importante Relaciona el Process Mining operativo con el impacto financiero. Dónde obtenerlo Tablas de departamentos o de tarifas. 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 ciertas actividades obligatorias (p. ej., «Signos vitales registrados» antes de «Medicamento administrado») se realizaron en el orden correcto. Sirve de apoyo al Dashboard «Cumplimiento del protocolo de atención». Por qué es importante Permite detectar automáticamente los incumplimientos sin revisar manualmente las historias clínicas. Dónde obtenerlo Se calcula en la herramienta de Process Mining o en ETL, según 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 tiene un valor, significa que se programó una cita de seguimiento. Si está vacío o es nulo, no se programó. Por qué es importante Mide directamente el KPI «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 orden OrderId	Identificador de órdenes específicas (análisis, medicamentos, procedimientos).
Descripción Vincula el evento «Orden» con el evento «Resultado» o «Administración». Por ejemplo, relaciona «Prueba diagnóstica solicitada» con «Prueba diagnóstica completada». Este nivel de detalle es necesario para el Dashboard «Tiempo de respuesta de pruebas diagnósticas». Por qué es importante Permite calcular la duración de pasos específicos del proceso (p. ej., el tiempo de respuesta del laboratorio). Dónde obtenerlo Tablas de registro de órdenes (p. ej., ORDER_ID, PLACER_ORDER_NUM). Consulte la documentación de Veradigm (Allscripts). Ejemplos ORD-998877LAB-112233RX-445566
	Nombre del medicamento MedicationName	Nombre del medicamento solicitado o administrado.
Descripción Se utiliza específicamente en el Dashboard «Intervalos entre administraciones de medicamentos». Ayuda a detectar retrasos en la administración de medicamentos concretos (p. ej., antibióticos o analgésicos). Por qué es importante Es fundamental 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	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 los datos, lo que resulta útil para investigar problemas de calidad de los datos. Dónde obtenerlo Se codifica de forma fija durante el proceso ETL o se extrae de las tablas de metadatos del sistema. Ejemplos Veradigm SunriseAllscripts PMVeradigm TouchWorks
	Tiempo de respuesta de pruebas diagnósticas DiagnosticTurnaroundTime	Tiempo transcurrido entre la solicitud de una prueba y la obtención de su resultado.
Descripción Duración calculada entre «Prueba diagnóstica solicitada» y «Diagnóstico confirmado» (o la recepción del resultado). Se utiliza en el Dashboard «Resumen del tiempo de respuesta de pruebas diagnósticas». Por qué es importante Los tiempos de respuesta prolongados aumentan la duración de la estancia; esta métrica permite localizar retrasos en el laboratorio o en radiología. Dónde obtenerlo Cálculo: marca de tiempo del resultado - marca de tiempo de la orden. 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 en el análisis. Este campo permite saber si se están consultando datos en tiempo real o una instantánea de un periodo anterior. Por qué es importante Aporta 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 del proceso 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 y los hitos clave del proceso que debe registrar en su Registro de eventos para descubrir con precisión el 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 registrarse cuando se añade un código de diagnóstico a la lista de problemas o cuando se firma una nota clínica que incluye el diagnóstico.
Por qué es importante La confirmación del diagnóstico es un punto de inflexión fundamental que determina el tratamiento posterior. Permite analizar las variaciones en las vías 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 de la atención o la documentación clínica. Puede inferirse a partir de la marca de tiempo en que se introduce y finaliza un código de diagnóstico principal para la atención. Capturar Utilice la marca de tiempo de creación o actualización del diagnóstico principal correspondiente al episodio del paciente. Tipo de evento inferred
	Evaluación inicial completada	Indica que una enfermera o un médico ha completado la primera evaluación clínica, como el triaje o la evaluación inicial. A menudo se registra cuando se firma y finaliza un formulario o una nota clínica, como una «Evaluación inicial de enfermería», en el sistema de historias clínicas electrónicas.
Por qué es importante Esta actividad es un hito inicial importante. El tiempo entre el registro y esta evaluación permite detectar posibles demoras en la admisión 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 las notas clínicas en los módulos de documentación clínica de Veradigm. Capturar Identifique la marca de tiempo en que el estado de la nota o el formulario de evaluación inicial cambia a «completado» o «firmado». Tipo de evento inferred
	Inicio de la planificación del alta	Indica 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 emisión de una orden de alta o la finalización de una evaluación específica para planificar el alta.
Por qué es importante Esta actividad es el punto de partida para medir la eficiencia del proceso de alta. A menudo, iniciar la planificación con antelación se relaciona con una menor tasa de reingresos. 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. Capturar Identifique la marca de tiempo en que se crea por primera vez una orden o un documento de alta para la atención del paciente. Tipo de evento inferred
	Paciente dado de alta	Marca el final oficial del episodio de hospitalización, cuando se da de alta formalmente al paciente del centro. Es un evento clave y explícito que captura el sistema ADT al actualizar el estado de la atención del paciente a «dado de alta».
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 de atención del paciente incluye la marca de tiempo del alta y el destino. Capturar Utilice la marca de tiempo del alta del registro principal de atención o visita del paciente. Tipo de evento explicit
	Paciente registrado	Marca el inicio oficial del episodio del paciente, cuando se introduce su información en el sistema Veradigm. Este evento suele registrarse de forma explícita cuando una persona completa el flujo de trabajo de registro y se crea un nuevo registro de atención 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 atención de pacientes. Dónde obtenerlo Este evento se registra en el módulo de registro de pacientes o en el módulo ADT (ingreso, alta y traslado). Busque la marca de tiempo de creación del registro de atención o de visita del paciente. Capturar Marca de tiempo de creación del registro en la tabla de atención o registro del paciente. Tipo de evento explicit
	Plan de tratamiento creado	Indica que el equipo clínico ha formalizado el plan de tratamiento del paciente. A menudo se registra cuando se crea y firma en el sistema de historias clínicas electrónicas un documento específico de «Plan de atención» o un conjunto de órdenes iniciales de tratamiento.
Por qué es importante Este hito da inicio a la fase de tratamiento activo. Sirve como referencia para medir el cumplimiento de los protocolos de atención y el tiempo hasta la primera intervenció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 de «Plan de atención» o de la marca de tiempo de creación del primer conjunto importante de órdenes terapéuticas tras el diagnóstico. Capturar Busque la marca de tiempo en que el profesional clínico responsable finaliza o firma el documento de «Plan de atención». Tipo de evento inferred
	Medicamento administrado	Este evento se registra cuando una enfermera u otro profesional clínico documenta la administración de un medicamento al paciente. Se captura en el Registro de administración de medicamentos (MAR) o en el módulo 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 permite detectar demoras en el proceso de entrega de medicamentos. Dónde obtenerlo Se registra explícitamente en el módulo eMAR (Registro electrónico de administración de medicamentos). Cada evento de administración incluye una marca de tiempo, el medicamento y la dosis. Capturar Extraiga de la tabla eMAR las marcas de tiempo de cada evento de administración de medicamentos vinculado a la atención del paciente. Tipo de evento explicit
	Procedimiento realizado	Indica que se ha completado un procedimiento clínico o quirúrgico. Por lo general, se registra cuando un profesional clínico firma la nota del procedimiento o cuando el estado de la orden correspondiente cambia a «completada» en el sistema.
Por qué es importante Los procedimientos son hitos importantes en muchos recorridos de pacientes. Analizar cuándo se realizan ayuda a 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 la nota del procedimiento en el módulo de documentación clínica o de la marca de tiempo de finalización de la orden correspondiente en el módulo de órdenes. Capturar Utilice la marca de tiempo de finalización de la orden del procedimiento o la marca de tiempo de firma de la documentación correspondiente. Tipo de evento inferred
	Prueba diagnóstica completada	Indica que los resultados de una prueba diagnóstica se han finalizado y están disponibles en el registro del paciente. Por lo general, se infiere cuando el estado de la orden original cambia de «activa» o «en curso» a «completada» o «con resultados».
Por qué es importante Esta actividad es un hito clave para medir los tiempos de respuesta de las pruebas diagnósticas. Las demoras entre la solicitud y la finalización pueden prolongar considerablemente el tiempo hasta el diagnóstico. Dónde obtenerlo Se infiere a partir del campo de estado de la orden en el módulo de órdenes o de las marcas de tiempo del módulo de resultados correspondiente, como LIS o RIS. Capturar Identifique la marca de tiempo en que el estado de la orden cambia a un estado final, como «Completada» o «Con resultados». Tipo de evento inferred
	Prueba diagnóstica solicitada	Este evento se produce cuando un profesional clínico solicita una prueba diagnóstica, como un análisis de laboratorio o un estudio de imagen. Se registra explícitamente mediante el sistema de entrada computarizada de órdenes médicas (CPOE) de Veradigm.
Por qué es importante Marca el inicio del subproceso de diagnóstico. Es el punto de partida para medir los tiempos de respuesta de las pruebas diagnósticas y detectar demoras en la solicitud de procedimientos. Dónde obtenerlo Se registra en el módulo de órdenes o en los registros del sistema CPOE. Cada orden incluye una marca de tiempo que indica cuándo se realizó. Capturar Extraiga la marca de tiempo de creación de los registros de órdenes correspondientes a las pruebas diagnósticas pertinentes. Tipo de evento explicit
	Seguimiento programado	Esta actividad representa la programación de una cita de seguimiento para el paciente después del alta. Se captura en el módulo de programación cuando se reserva una cita vinculada a la atención cuyo alta se ha registrado.
Por qué es importante Programar la atención de seguimiento es fundamental para garantizar la continuidad de la atención y reducir 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 para el paciente posterior a la fecha del alta. Capturar Identifique la marca de tiempo de creación de un registro de cita vinculado al paciente en el sistema de programación. Tipo de evento explicit
	Signos vitales registrados	Esta actividad se produce 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 hojas de registro de signos vitales del sistema de historias clínicas electrónicas.
Por qué es importante El registro frecuente de los signos vitales indica que se está realizando un seguimiento activo del paciente. Es posible analizar la frecuencia y el momento de los registros para comprobar el cumplimiento de los protocolos de seguimiento. Dónde obtenerlo Se registra en el repositorio de datos clínicos o en las tablas de hojas de registro donde se almacenan los signos vitales. Cada entrada incluye una marca de tiempo. Capturar Extraiga las marcas de tiempo de los datos de la hoja de registro de signos vitales correspondientes a la atención del paciente. Tipo de evento explicit
	Traslado a otro departamento	Este evento marca el traslado físico del paciente de un departamento o unidad de atención a otro, por ejemplo, de urgencias a una unidad de hospitalización. Se captura en el sistema ADT (ingreso, alta y traslado) de Veradigm.
Por qué es importante Los traslados de pacientes suelen ser puntos donde se producen cuellos de botella y demoras. 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. Capturar Extraiga del sistema ADT los registros de eventos correspondientes a los movimientos de 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 se llama 'EHR_Inbound' o algo similar). Compruebe que este canal procese los tipos de mensajes ADT, SIU, ORM, ORU, RAS y DFT para capturar todas las actividades del recorrido del paciente.
Cree un nuevo canal de transferencia o exportación: Cree un canal de destino llamado 'ProcessMining_Export'. Configure el tipo de salida como 'File Writer'. Este canal recibirá una copia de los mensajes del canal de origen y los convertirá en un archivo plano (CSV) para ProcessMind.
Configure el enrutamiento de mensajes: En las reglas de enrutamiento de AIE, configure una regla de copia o enrutamiento para enviar mensajes desde el canal principal del EHR al nuevo canal 'ProcessMining_Export'. Filtre el enrutamiento para incluir solo los tipos de mensajes necesarios: ADT (registro/traslado), SIU (programación), ORM (Pedidos), ORU (resultados/signos vitales), RAS (medicamentos) y DFT (facturación/procedimientos).
Defina la lógica de transformación: En el 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 los eventos desencadenantes y los códigos de estado correspondientes a los nombres de actividad estándar requeridos (por ejemplo, asignar 'ADT^A01' a 'Paciente registrado').
Asigne los atributos a los campos HL7: Compruebe 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 datos 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 como directorio de salida una ruta de red segura. Defina el formato del nombre de archivo (por ejemplo, EventLog_YYYYMMDD_HH.csv). Configure el modo de archivo como 'Append' para añadir filas continuamente al registro.
Gestione los delimitadores y el escape de caracteres: En el script, asegúrese de limpiar los campos de texto (como el diagnóstico o el nombre del departamento) para eliminar comas y saltos de línea que puedan alterar la estructura del CSV.
Active y pruebe el canal: 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: Establezca un calendario de rotación (por ejemplo, cada día a medianoche) para cerrar el archivo CSV actual y crear uno nuevo. Así, los archivos tendrán un tamaño manejable para cargarlos.
Reproduzca datos históricos (opcional): Si necesita datos históricos, utilice la herramienta 'Message Browser' o 'Log Replay' de AIE para volver a enviar 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 archivos: 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' a ID del caso, 'ActivityName' a Actividad y 'EventDateTime' a Marca de tiempo.

Configuración

Tipo de canal: File Writer / salida del sistema de archivos
Eventos desencadenantes: ADT^A01, ADT^A03, ADT^A04, ADT^A08, SIU^S12, ORM^O01, ORU^R01, RAS^O17, DFT^P03
Codificación del archivo: UTF-8 (importante para los caracteres especiales en 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 que se acumulen mensajes en el motor.

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 tener credenciales válidas para Veradigm (Allscripts) Unity API. Necesitará un Appname (nombre de aplicación) autorizado para su organización, además de un UserID y una Password (o un token) válidos para la autenticación. Compruebe que la cuenta de usuario tenga permisos para acceder a los dominios clínicos (encuentros, Pedidos, resultados, signos vitales y problemas).
Configuración del entorno: Instale Python 3.8 o una versión posterior. Instale las bibliotecas necesarias con pip: pip install requests pandas. Se utilizarán para enviar solicitudes HTTP a Unity API y procesar los datos obtenidos.
Configuración: Abra el script de Python proporcionado. Localice la sección CONFIGURATION al principio. Actualice API_URL para que apunte al endpoint de su entorno de Unity (por ejemplo, unity.veradigm.com o una puerta de enlace interna). Sustituya las credenciales de ejemplo ([YourAppName], [YourUserID], etc.) por sus credenciales reales. Indique las fechas deseadas en START_DATE y END_DATE.
Descripción de la lógica del script: Primero, el script se autentica con la API para obtener un token de seguridad. Después, llama a GetEncounterInfo para recuperar todos los episodios de pacientes del período especificado. Esta lista de encuentros sirve como base para la extracción.
Bucle de extracción de actividades: Para cada EncounterID identificado, el script realiza llamadas adicionales a endpoints específicos. Llama a GetOrders para buscar pruebas diagnósticas y procedimientos, a GetResults para identificar las pruebas completadas, a GetVitals para obtener los registros de signos vitales y a GetPatientProblems para consultar los diagnósticos confirmados. También recorre las notas clínicas para encontrar evaluaciones y planes de tratamiento.
Transformación de datos: Cuando la API devuelve datos JSON sin procesar, el script analiza campos específicos y los asigna al esquema de ProcessMind. Por ejemplo, asigna OrderDateTime a EventDateTime para la actividad 'Prueba diagnóstica solicitada'. El script aplica de forma coherente PatientEpisodeId (ID del encuentro) a todos los registros secundarios.
Gestión de ADT y traslados: La lógica del script consulta el historial de ubicaciones del encuentro (si está disponible mediante llamadas específicas de auditoría o ADT) o deduce 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 para 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 de cada tipo de actividad. Revise los resultados para confirmar que todos los tipos de actividad tengan registros, salvo que se espere lo contrario.
Exportación: El conjunto de datos final se agrupa en un DataFrame de Pandas. El script calcula atributos derivados, como LengthOfStay e IsReadmission, ordenando los datos por paciente y hora. Por último, exporta el registro de eventos depurado a un archivo CSV llamado veradigm_patient_journey_log.csv.
Revisión final: Abra el archivo CSV generado. Compruebe que las fechas estén en formato 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 ID del caso, ActivityName a Actividad y EventDateTime a Marca de tiempo.

Configuración

API_URL: URL base de los servicios de Unity API. Varía según la instalación del cliente (por ejemplo, local o en la nube). Compruebe que el protocolo (https) sea correcto.
Appname: Identificador único de la aplicación registrada en Veradigm/Allscripts. Determina el alcance del acceso a los datos.
Período de fechas: Se recomienda extraer datos de un período de 3 a 6 meses. Los períodos largos pueden agotar el tiempo de espera; si el volumen es elevado, divida la extracción por meses.
Configuración del tiempo de espera: El script usa un tiempo de espera predeterminado de 30 segundos para las llamadas a la API. Auméntelo si el sistema EHR tiene mucha carga.
Procesamiento por lotes: El script procesa cada encuentro por separado. En sistemas de gran volumen, quizá sea necesario modificarlo para obtener datos en bloque (si los endpoints lo permiten) o ejecutar varios hilos en paralelo.
Lógica de asignación: El script asigna 'OrderType' a las actividades. Asegúrese de que los códigos de tipo de pedido específicos de su sistema (por ejemplo, 'Lab', 'Rad') coincidan con la lógica de la función process_orders.

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()

¿Todo listo para comenzar?

Comience hoy a mejorar la experiencia de sus pacientes y la eficiencia operativa. Sus datos pueden revelar información valiosa y ayudarle a impulsar mejoras importantes.

Volver a la guía de mejora

Descargar Template

Optimice hoy los recorridos de los pacientes en Veradigm

Reduzca un 30 % el tiempo de ciclo de atención de los pacientes y mejore los resultados clínicos.

Comience la prueba gratuita

No se requiere tarjeta de crédito. Comience de inmediato.

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 de Allscripts Interface Engine

Pasos

Configuración

Consulta de ejemplo config

Extracción de datos de Veradigm Unity API con Python

Pasos

Configuración

Consulta de ejemplo python

¿Todo listo para comenzar?

Optimice hoy los recorridos de los pacientes en Veradigm