• No se han encontrado resultados

Guía de Implementación. Mensajería HL7 V3.3

N/A
N/A
Protected

Academic year: 2022

Share "Guía de Implementación. Mensajería HL7 V3.3"

Copied!
44
0
0

Texto completo

(1)

Guía de Implementación Mensajería HL7

V3.3

Mensajes para Cuenta Médica FONASA Proceso Ambulatorio y Hospitalización Intercambio de Datos Validación Beneficiario-

Prestador

(2)

Página 2 de 44

V ERSIONES

Fecha Asunto Responsable Ver.

16-01-2018 Guía de

Implementación de mensajería para Cierre de Encuentro Médico

❖ César Galindo (CENS)

❖ Ignacio Pineda (Salud + Desarrollo)

❖ Jorge Cristi (Salud + Desarrollo)

❖ Carlos Núñez (FONASA)

❖ Jorge Mansilla (CENS)

3.3

(3)

Página 3 de 44

C ONTROL DE C AMBIOS

1) Cambios en la redacción en general.

2) Cambio en la obligatoriedad de los siguientes campos:

• MSH.3

• MSH.4

• MSH.5

• MSH.6

• EVN.1

• PV1.18

Quedando todos con la opción de obligatorios.

3) Cambio en longitud de los siguientes campos:

• PID.3 Long 199

• PID.6 Long 194

• PV1.18 Long 4

• PV1.20 Long 20

• PR1.3 Long 1

• IN1.1 Long 30

• IN1.2 Long 199

• IN1.3 Long 15

4) En el campo PV1-18, se agrega el código "00" para la opción "Sin marca de gratuidad".

5) Se agrega campo EVN 5.

(4)

Página 4 de 44

Índice General

Versiones... 2

Control de Cambios... 3

1 Introducción ... 7

1.1 Estándares internacionales ... 8

1.2 Visión Global ... 9

1.2.1 Descripción del proceso de Atención Ambulatoria y PAD ... 9

1.2.2 Descripción del proceso de Atención Hospitalaria ... 10

2 Glosario ... 12

3 Convenciones y Organización de la Guía ... 15

3.1 Modelo Genérico de Transacción ... 15

3.2 Convención respecto al uso de caracteres ... 16

4 Definición del Mensaje de Validación de Beneficiario y Prestador ... 17

4.1 Alcance ... 17

4.2 Versión del Estándar ... 17

4.3 Roles en el Caso de Uso ... 17

4.4 Diagrama de Interacciones ... 19

4.5 Eventos gatilladores ... 19

4.5.1 Notificación de Solicitud de Atención de Beneficiario ... 20

4.5.2 Notificación de Validación de Prestador, Beneficiario y Apertura de Cuenta 20 4.5.3 Respuesta ACK ... 21

4.6 Estructura de los Segmentos ... 21

4.6.1 MSH – Segmento de cabecera del mensaje ... 21

4.6.2 EVN – Segmento del tipo de evento ... 25

4.6.3 PID – Segmento identificador de paciente ... 26

4.6.4 PV1 - Segmento origen del paciente ... 27

4.6.5 PR1- Segmento de Prestaciones ... 29

4.6.6 IN1 – Segmento de Seguro ... 30

4.6.7 MSA – Segmento de cabecera ... 31

5 Ejemplos... 33

5.1 Ambulatorio ... 33

5.2 Hospitalario ... 34

(5)

Página 5 de 44

6 ANEXOS ... 36

6.1 Nomenclatura: ... 36

6.1.1 Criterio para definir obligatoriedad en los segmentos, campos y sub- campos: 36 6.1.2 Nomenclatura empleada en la especificación de los mensajes: ... 36

6.2 Tipos de Datos (DT) ... 37

6.2.1 Tipos de Datos ... 37

6.2.2 Datos Compuestos: ... 37

6.2.3 Segmentos ... 38

6.3 Tabla HL7 0003 ... 38

Índice Imágenes Imagen 1: Diagrama Genérico de Transacciones ... 15

Imagen 2: Diagrama de Secuencia Genérico ... 16

Imagen 3 Diagrama de secuencia para mensajería Validación ... 19

Índice Tablas Tabla 1 "Valores de delimitadores" ... 16

Tabla 2 Transición para la validación Beneficiario - Prestador... 17

Tabla 3 Estructura segmento ADT 01 ... 20

Tabla 4 Estructura segmento BAR P01 ... 20

Tabla 5 Elementos descritos en el segmento MSH ... 21

Tabla 6 Descripción caracteres delimitadores ... 22

Tabla 7 Establecimiento que envía ... 22

Tabla 8 "Tabla 0301 – Tipo universal ID” ... 22

Tabla 9 "Tabla 0361 - Establecimiento" ... 23

Tabla 10 Establecimiento que recibe ... 23

Tabla 11 "Tabla 0301 – Tipo universal ID” ... 23

Tabla 12 "Tabla 0361 - Establecimiento" ... 23

Tabla 13 "Tabla 0076 – Tipo de Mensaje" ... 24

Tabla 14 "Tabla 0003 – Tipo de Evento" ... 24

Tabla 15 "Tabla 0354 – Estructura de los mensajes" ... 24

(6)

Página 6 de 44

Tabla 16 “Tabla HL7 – ID de la Versión” ... 25

Tabla 17 "Tabla EVN – Elementos descritos en el segmento EVN" ... 25

Tabla 18 “Subconjunto de tabla 0003 de HL7” ... 25

Tabla 19 "Tabla PID – Elementos descritos en el segmento PID" ... 26

Tabla 20 Tipo documento según tabla 0203 de HL7 ... 26

Tabla 21 "Tabla PV1 – Elementos descritos en el segmento PV1" ... 28

Tabla 22 "Tabla 0004 – Tipo de encuentro" ... 28

Tabla 23 "Marca de Gratuidad" ... 29

Tabla 24 "Tabla 0064 – Tipo de paciente"... 29

Tabla 25 "Tabla PR1 – Elementos descritos en el segmento PR1 " ... 29

Tabla 26 "Tabla 0004 – Tipo de encuentro" ... 30

Tabla 27 "Tabla IN1 – Elementos descritos en el segmento IN1. " ... 30

Tabla 28 "Tabla 0072 – Leyes previsionales" DEIS: Decreto ex. 643/2016 .... 31

Tabla 29 DEIS: Decreto ex. 643/2016 ... 31

Tabla 30 "Tabla MSA – Elementos descritos en el segmento MSA. " ... 31

Tabla 31 "Tabla 0008 – Acknowledge Code" ... 32

Tabla 32 Explicación datos requeridos y opcionales ... 36

Tabla 33 Nomenclatura empleada en la especificación de los mensajes ... 37

Tabla 34 Tipos de datos ... 37

Tabla 35 Tipos de datos compuestos ... 38

(7)

Página 7 de 44

1 I NTRODUCCIÓN

El proyecto de cuenta médica interoperable tiene como objetivo final que la información sanitaria y financiera necesaria para asegurar la continuidad del negocio entre prestadores y FONASA sea comunicada de manera interoperable y estandarizada, lo que finalmente se traducirá en un beneficio directo para los beneficiarios. El conocimiento que será posible generar permitirá caracterizar el uso de recursos, complementar y justificar la incorporación de nuevas prestaciones al arancel, así como también hacer más eficientes los procesos de comunicación entre el seguro y los prestadores.

Esta guía de implementación es resultado de una de las cuatro mesas de trabajo formadas para el cumplimiento de la Fase de Diseño. Los puntos de interoperabilidad, así como los datos asociados a cada punto fueron identificados y definidos por los participantes en cada mesa y consolidados en este documento.

La mensajería a utilizar en el piloto de cuenta médica interoperable necesaria para cumplir el objetivo planteado se delimitó basándose en los datos identificados anteriormente, razón por la cual es fundamental contar con un documento que explique y estandarice definiciones de la información a intercambiar.

Los participantes de las mesas de trabajo fueron los siguientes:

• Fondo Nacional de Salud

• Servicio de Salud Araucanía Sur

• Servicio de Salud Talcahuano

• Servicio de Salud Maule

• Clínica Indisa

(8)

Página 8 de 44

• Clínica Dávila

• Megasalud

• Centro Nacional en Sistemas de Información en Salud (CENS)

• Subcomité de Salud – Comité de Industrias Inteligentes (CORFO)

1.1 E

STÁNDARES INTERNACIONALES

La mensajería HL7 define el formato, estructura y contenido de la transmisión de información durante determinados procesos dentro de las Instituciones de Salud. La homologación de estos estándares en los distintos países permite generar normas específicas para cada proceso con la facilidad de adaptación para cada uno de los distintos contextos que los países presentan.

El desarrollo de estas normas presenta libertad durante la estructuración de la arquitectura de cada uno de los mensajes, esto debido a que la estándar entrega libre elección sobre los datos contenidos para cada uno de los segmentos asociados a un determinado evento, generando el inconveniente de que se pueden generar diferencias en cada interpretación dada al estándar, aun cuando lo que se busca es la interoperabilidad entre los Sistemas Informáticos en Salud.

Esto se soluciona sumando toda la información y datos contenidos en cada estándar junto con toda la información que cada país o institución requiere. Todo lo anterior queda definido, redactado y es accesible para quienes deben implementar estos estándares en las guías de implementación, las cuales describen en forma detallada toda la información necesaria para la aplicación de estos estándares junto con la estructura de cada mensaje que es homologado.

Todo lo anterior converge en la generación de Guías de Implementación de los

estándares para que los sistemas puedan transmitir, almacenar y confirmar el

(9)

Página 9 de 44

envío de información bajo estándares definidos, que permiten generar interoperabilidad y disminuyen en gran cantidad los posibles errores durante la interacción entre los distintos sistemas, afianzando Instituciones que trabajan en función de la innovación tecnológica, requieren de una gran gestión de sus recursos y operan con sistemas de apoyo en la toma de decisiones.

1.2 V

ISIÓN

G

LOBAL

1.2.1 D

ESCRIPCIÓN DEL PROCESO DE

A

TENCIÓN

A

MBULATORIA Y

PAD

Los beneficiarios de FONASA, dependiendo de su tramo de beneficio, pueden acceder a la compra de un bono modalidad libre elección para ser atendidos de manera ambulatoria ya sea en la red privada de atención o en la red pública de atención.

El proceso de inicia con el envío por parte del prestador, de la información relacionada con las prestaciones a realizar, con el fin de recibir una valorización inicial de la cuenta médica por parte de FONASA utilizando un servicio interno (OIPA). Luego de esto, el beneficiario puede aceptar o rechazar la valoración.

Luego que la valorización sea aceptada por el beneficiario, se inicia el proceso de identificación y validación previsional del beneficiario.

Para efectos prácticos, el paciente podrá conocer el valor de la prestación, la

bonificación por FONASA, el monto cubierto por posibles seguros

complementarios y el valor final a pagar. Si hay una compra efectiva del bono,

el paciente recibirá las prestaciones en el plazo establecido por el prestador,

entendiendo que puede recibir prestaciones que en un comienzo no se

valorizaron, dependiendo de la evolución clínica y del criterio del profesional de

(10)

Página 10 de 44

salud. Una vez que se cierre el encuentro médico, el prestador deberá enviar a FONASA los datos solicitados en este punto, incluyendo información financiera y sanitaria, necesarias para el cierre de la cuenta médica.

Hospitalizaciones programadas PAD: Son atenciones de salud que ocurren cuando el paciente previamente tiene una programación de hospitalización dada por un profesional médico y se encuentra dentro de los programas PAD. Para estos efectos el proceso será el mismo que el explicado anteriormente para el proceso ambulatorio.

1.2.2 D

ESCRIPCIÓN DEL PROCESO DE

A

TENCIÓN

H

OSPITALARIA

El proceso de atención hospitalario tiene distintos puntos de inicio o puertas de entrada, dependiendo del área de consulta del paciente, ya que existe la posibilidad de que el beneficiario sea admitido desde el Servicio de Urgencia o que la hospitalización sea programada.

Servicio de Urgencia: El proceso se inicia al momento que el paciente ingrese

al Servicio de Urgencia y requiera atención de salud. Si el paciente se encuentra

en riesgo vital, sigue un proceso paralelo que no se encuentra dentro del alcance

de este proyecto (Ley de Urgencia). Si no existe riesgo vital, el paciente deberá

ser identificado y validado por el prestador. Para este fin, deberá enviar

información a FONASA quien consultará bases internas y confirmará si la

validación fue exitosa o no.

(11)

Página 11 de 44

De ser exitosa el prestador procederá a ofrecer atención médica al paciente, siendo decisión del médico tratante la decisión de alta clínica u orden de hospitalización. Hospitalizaciones programadas son atenciones de salud que ocurren cuando el paciente previamente tiene una programación de hospitalización dada por un profesional médico.

El proceso se inicia con la identificación y validación por parte del prestador, proceso realizado igual que en el escenario anterior. Una vez que la validación es correcta, se procede a la valorización y compra del bono para la atención.

Luego de la alta clínica y administrativa del paciente, el prestador deberá enviar a FONASA los datos asociados a ese encuentro médico necesarios para realizar trazabilidad financiera y clínica de la atención del paciente.

Hospitalizaciones no programadas: La identificación y validación del

beneficiario, se realiza de igual manera que en los escenarios anteriores. La

valorización y cierre de cuenta médica para fines sanitarios y financieros se

realiza posterior al alta administrativa del paciente.

(12)

Página 12 de 44

2 G LOSARIO

ACK: Abreviatura de Acknowledge (recibido). Es un aviso de recepción de un mensaje. En el contexto de la interoperabilidad empleando el estándar HL7 este aviso puede limitarse a la recepción del mensaje a nivel de aplicación en cuyo caso se denomina ACK en modo original o informar tanto del reconocimiento a nivel de aplicación como a nivel de aceptación del mensaje en cuyo caso se denomina ACK en modo mejorado (enhanced mode). Este aviso se envía también en forma de mensaje electrónico.

Campo: Corresponden a los componentes de construcción del mensaje, se encuentran definiendo la semántica de los segmentos, por lo que conforman los datos o conjuntos de datos.

Estándar: Norma técnico-legal elaborada por fabricantes, administraciones, usuarios y consumidores, que contienen las especificaciones técnicas asociadas a una tecnología, son producto de experiencia, desarrollo y resultados de implementación.

Estandarización: Redacción y aprobación de normas que determinan una serie de garantías dependiendo del campo de aplicación.

Evento: Situación que requiere de un efector y un afectado dentro de un proceso clínico. Pueden estar orientados a pacientes, equipamiento, instalaciones, emergencias, etc.

Homologación: Equiparación o igualación de las especificaciones, normas,

documentos, características, que permiten ordenar el funcionamiento de una

entidad.

(13)

Página 13 de 44

HL7: Health Level Seven, por sus siglas en inglés, son un conjunto de estándares que facilitan el intercambio de información clínica. Utiliza modelado dado por UML y lenguaje XML.

IHE: Integrating the Healthcare Enterprise, es una iniciativa de empresas y profesionales en Salud con el objetivo de optimizar, mejorar y clarificar la comunicación entre los sistemas informáticos en Salud.

Interoperabilidad: Habilidad de dos o más sistemas para intercambiar información y utilizar entre estos mismos la información.

Mensaje: Modo en que se intercambia la información entre sistemas informáticos. Su sintaxis está dada por el estándar de mensajería HL7, en el cual se detalla el lenguaje, la estructura, la codificación, etc.

PAD: Corresponde al Programa de Pago Asociado a Diagnóstico (PAD), también llamado “Cuenta Conocida”, es un conjunto de prestaciones previamente estandarizadas, que permiten resolver en forma integral un diagnóstico o problema de salud determinado.

Proceso: Conjunto de eventos coordinados y ordenados, que suceden bajo ciertas circunstancias, a partir de una entrada para generar una salida.

RIM: Abreviatura de Reference Information Model (Modelo de Referencia de Información). Es un modelo de clases que sirve como referencia para comprender la información resultante del registro de los eventos de salud como un todo, con el fin de mejorar la interoperabilidad semántica.

Rol: Es una de las clases principales del RIM. Es una competencia de la Entidad

que se desempeña en un Acto.

(14)

Página 14 de 44

Segmento: Corresponde a cada una de las líneas de un mensaje, cada segmento posee su propio sentido semántico por lo que contienen información específica.

SIDRA: Sistema de Información de las redes Asistenciales. Iniciativa impulsada

por el Ministerio de Salud, que tiene como objetivo informatizar los procesos

clínicos – administrativos de los Prestadores públicos en Chile.

(15)

Página 15 de 44

3 C ONVENCIONES Y O RGANIZACIÓN DE LA G UÍA

Esta Guía Muestra la estructura de implementación del set de mensajes relacionados con la Validación de Beneficiario entre Prestador y FONASA. Para este fin de definirá la estructura del mensaje y la composición de los campos y sub-campos que definen el intercambio de datos para este fin. Existen algunas convenciones y convenciones que se deben conocer para poder conocer el mensaje que se describe.

3.1 M

ODELO

G

ENÉRICO DE

T

RANSACCIÓN

Cada descripción de transacción, actores, los roles que juegan y las transacciones entre ellos se presentan como un caso de uso

• Alcance: Descripción de las transacciones

• Roles: Definición de los actores y sus roles

Imagen 1: Diagrama Genérico de Transacciones

• Estándar de Referencia: Especificación del estándar usado en las transacciones

• Diagrama de Secuencia: Descripción grafica de las interacciones

(16)

Página 16 de 44 Imagen 2: Diagrama de Secuencia Genérico

3.2 C

ONVENCIÓN RESPECTO AL USO DE CARACTERES

Para estas guías se usará el juego de caracteres UTF-8.

Carácter Descripción Valor Hexa ASCII

<cr> Retorno de carro 0D 13

| Separador de campo 7C 124

^ Separador de componente 5E 94

~ Carácter de repetición 7E 126

\ Carácter de escape 5C 92

& Separador de subcomponente 26 38

. Separador decimal 2E 46

Tabla 1 "Valores de delimitadores"

Por efecto del uso del codificador de caracteres UTF-8, se recomienda no utilizar tildes.

(17)

Página 17 de 44

4 D EFINICIÓN DEL M ENSAJE DE V ALIDACIÓN DE B ENEFICIARIO Y

P RESTADOR

4.1 A

LCANCE

Este mensaje es obligatorio para cualquier tipo de atención.

Esta transacción está definida para la validación tanto del Beneficiario como del Prestador a modo que FONASA pueda verificar que ambos se encuentren en sus registros.

Situación inicial

El beneficiario llega a recibir la prestación

Acciones 1.

El Beneficiario se presenta en el establecimiento de salud

2.

El prestador registra los datos iniciales de la prestación

3.

El Prestador envía datos a FONASA

4.

FONASA registra datos

5.

FONASA valida al prestador y al beneficiario en sus registros

6.

FONASA otorga ID encuentro FONASA

Resultados

Como resultado de este proceso pueden existir dos escenarios posibles:

1) Se produce validación de beneficiario exitosa por parte de FONASA y se entrega tramo de beneficiario y ID encuentro FONASA

2) La validación no es exitosa y FONASA rechaza la solicitud de ID encuentro FONASA por parte del prestador

Tabla 2 Transición para la validación Beneficiario - Prestador

4.2 V

ERSIÓN DEL

E

STÁNDAR

Para el desarrollo de los mensajes de Validación para el proceso de Atención Ambulatoria y Hospitalizado, se trabajó con el estándar sobre mensajería HL7 versión 2.5.1 y más específicamente su capítulo 2 y 3 los cuales definen los mensajes asociados a pacientes para los eventos que se gatillan.

4.3 R

OLES EN EL

C

ASO DE

U

SO

A partir del proceso de Atención Ambulatoria y de Hospitalización, y según lo

definido por la red asistencial, se pueden definir dos actores que interactuarán

en el intercambio de datos de este mensaje.

(18)

Página 18 de 44 Imagen 1: Roles en el Caso de Uso para Mensaje de Validación

Prestadores (Específicamente el Front de Prestadores): Los Prestadores de Salud son personas naturales o jurídicas, tales como, consultorios, consultas, centros médicos, hospitales, o clínicas, que otorgan atenciones de salud a las personas beneficiarias. Se denomina Front de prestadores a la unidad, dentro del organismo, encargada de realizar el envío de datos a FONASA.

FONASA (Específicamente End Point de FONASA): El Fondo Nacional de

Salud (FONASA) es el organismo público que administra los fondos estatales

destinados a salud en Chile, para dar cobertura a sus beneficiarios. Se denomina

End Point de FONASA a la unidad, dentro del organismo, encargada de realizar

el envío de datos a FONASA.

(19)

Página 19 de 44

4.4 D

IAGRAMA DE

I

NTERACCIONES

Imagen 3 Diagrama de secuencia para mensajería Validación

Temporalidad de mensajes:

1. Mensaje ADT_A01 con información de identificación de prestador y del paciente.

2. Mensaje ACK de acuse de recibo desde FONASA al Prestador.

3. Mensaje BAR_P01 desde FONASA enviando el tramo del beneficiario y el ID encuentro FONASA.

4. Mensaje ACK de acuse de recibo desde FONASA al Prestador.

4.5 E

VENTOS GATILLADORES

Estos mensajes se gatillarán al momento de que el paciente se presenta en

admisión del prestador y antes de recibir atención médica, salvo en caso donde

aplique Ley de Urgencia, donde el paciente con riesgo vital es atendido

inmediatamente, sin validación previa necesaria. A modo de aclaración, el

proceso de Ley de Urgencia no está dentro del alcance de este proyecto, por lo

que no será tratado en estas guías.

(20)

Página 20 de 44

4.5.1 N

OTIFICACIÓN DE

S

OLICITUD DE

A

TENCIÓN DE

B

ENEFICIARIO

Este evento se produce al tributar por parte del prestador, los datos relacionados con el beneficiario. El evento asociado será ADT A01 para una admisión en tiempo y su estructura de define a continuación:

ADT A01 ADT Message

MSH Cabecera

EVN Tipo de evento PID Identificación del paciente PV1 Origen del paciente PR1 Prestación tipo de encuentro

IN1 Aseguramiento

Tabla 3 Estructura segmento ADT 01

Estructura MSH

EVN PID PV1 PR1 IN1

4.5.2 N

OTIFICACIÓN DE

V

ALIDACIÓN DE

P

RESTADOR

, B

ENEFICIARIO Y

A

PERTURA DE

C

UENTA

Este evento se produce al informar FONASA al Prestador que tanto éste como el beneficiario están en sus registros, por medio de la apertura de la cuenta entregando un ID encuentro FONASA. El evento asociado es BAR P01 y su estructura se define a continuación:

BAR P01 BAR Message

MSH Cabecera

EVN Tipo de evento PID Identificación del paciente PV1 Origen del paciente PR1 Prestación tipo de encuentro

IN1 Aseguramiento

Tabla 4 Estructura segmento BAR P01

(21)

Página 21 de 44

Estructura MSH

EVN PID PV1 PR1 IN1 4.5.3 R

ESPUESTA

ACK

Para los dos mensajes, la estructura del mensaje ACK es la misma Estructura

MSH MSA

4.6 E

STRUCTURA DE LOS

S

EGMENTOS

4.6.1 MSH S

EGMENTO DE CABECERA DEL MENSAJE Sec Long DT R/O RP

(#) Tabla

Asoc. Nombre del elemento Obs

1 1 ST R Separador de Campo

2 4 ST R Codificación de

caracteres

3 227

HD

R 1 Aplicación que envía

4 227

HD

R 1 0301

0361 Establecimiento que envía

5 227

HD

R 1 Aplicación que recibe

6 227

HD

R 1 0301

0361 Establecimiento que recibe

7 26 TS R Fecha y hora del mensaje

9 15 MSG R 0076

0003 0354

Tipo de Mensaje

10 20 ST R ID de Control del

mensaje

11 3 PT R ID de Procesamiento Valor por defecto

“P”

12 60 VID R ID de Versión

Tabla 5 Elementos descritos en el segmento MSH

(22)

Página 22 de 44

Descripción de las secuencias

MSH-1 Separador de campo <|>

MSH-2 Codificación de los caracteres

<^~\&>

Carácter Descripción

^ Separador de componente

& Separador de subcomponente

~ Carácter de repetición

\ Carácter de escape

Tabla 6 Descripción caracteres delimitadores

MSH-3 Aplicación que envía

<Nombre Aplicación Origen>

MSH-4 Establecimiento que envía

<Cod_Establecimiento_Origen^NroRUT^Tipo_universal_ID>

Cod_Establecimiento_Origen

Prestador público Código DEIS

FONASA 0

Prestador privado

RUT Sucursal o RUT Jurídico en caso de ser sucursal única.

NroRUT

Prestador Publico

RUT Jurídico

FONASA

61.603.000-0

Prestador Privado

RUT Jurídico

Tabla 7 Establecimiento que envía

El valor de FONASA 0 como Cod_Establecimiento_Origen es predefinido, al igual que el RUT FONASA 61.603.000-0

Código Glosa

RUT Tipo de documento de identificación DEIS Código de establecimiento

Tabla 8 "Tabla 0301 – Tipo universal ID”

Código Glosa

(23)

Página 23 de 44 Tabla 9 "Tabla 0361 - Establecimiento"

OBS: La Tabla 9 "Tabla 0361 - Establecimiento", será disponibilizada a través del Maestro de Prestadores. Por el momento completar con RUT jurídico institucional.

MSH-5 Aplicación que recibe <Nombre Aplicación Destino>

MSH-6 Establecimiento que recibe

<Cod_Establecimiento_Origen^NroRUT^Tipo_universal_ID>

Cod_Establecimiento_Destino

Prestador público Código DEIS

FONASA 0

Prestador privado

RUT Sucursal o RUT Jurídico en caso de ser sucursal única.

NroRUT

Prestador Publico

RUT Jurídico

FONASA

61.603.000-0

Prestador Privado

RUT Jurídico

Tabla 10 Establecimiento que recibe

El valor de FONASA 0 como Cod_Establecimiento_Origen es predefinido, al igual que el RUT FONASA 61.603.000-0

Código Glosa

RUT Tipo de documento de identificación DEIS Código de establecimiento

Tabla 11 "Tabla 0301 – Tipo universal ID”

Código Glosa

Tabla 12 "Tabla 0361 - Establecimiento"

OBS: La Tabla 9 "Tabla 0361 - Establecimiento", será disponibilizada a través del Maestro de Prestadores. Por el momento completar con RUT jurídico institucional.

MSH-7 Fecha y hora del mensaje

<Fecha (YYYYMMDDhhmmss±ZZZZ) >

Corresponde a la fecha y hora de creación del mensaje.

Representa: Año (4 dígitos), mes (2 dígitos), día (2 dígitos), hora (dos dígitos), minutos (2 dígitos), segundos (2 dígitos), huso horario (signo y dos dígitos de hora más dos dígitos de minutos).

Según ISO 8601.

(24)

Página 24 de 44

MSH-9 Tipo de mensaje

<ID (Tabla 0076)>^<Valor (Tabla 0003)>^<Valor (Tabla 0354)>

ID Responsable

ACK Mensaje de confirmación de recibo ADT Mensaje ADT

BAR Mensaje de cuentas

Tabla 13 "Tabla 0076 – Tipo de Mensaje"

Valor Descripción

A01 Notificación de admisión/visita A11 Rechazo de admonición P01 Apertura de cuenta P06 Notificación cierre cuenta P10 Notificación de cuentas P12 Envío de diagnostico

Tabla 14 "Tabla 0003 – Tipo de Evento"

Valor Eventos

ADT_A01 A01, A04, A08, A13 ADT_A09 A09, A10, A11 BAR_P01 P01

BAR_P06 P06 BAR_P10 P10 BAR_P12 P12

Tabla 15 "Tabla 0354 – Estructura de los mensajes"

MSH-10 ID de control de mensaje <Número de Control>

Este es un número único que identifica al mensaje, es generado por el sistema informático local según sus reglas. El Software emisor entrega un número que se utiliza para identificar en forma univoca el mensaje. El software receptor replica este número en el MSA de la respuesta ACK.

MSH-11 ID de procesamiento

<P>

Valor predeterminado por el estándar MSH-12 ID de versión

<ID de la versión>

(25)

Página 25 de 44 ID de la versión Descripción Comentarios

2.5.1 Versión 2.5.1 Enero 2007 Tabla 16 “Tabla HL7 – ID de la Versión”

4.6.2 EVN S

EGMENTO DEL TIPO DE EVENTO

Sec Long DT R/O RP

(#)

Tabla Asoc

Nombre del elemento

Obs

1 3 ID R 0003 Tipo de

Evento

Según tipo de mensaje a utilizar.

2 26 TS R Hora y Fecha del evento

5 194 XCN O Código Error

FONASA

Código de error que serán utilizados para indicar errores globales. Caídas de servicios, etc. Valido para Mensaje BAR_P01 desde FONASA al Prestador

Tabla 17 "Tabla EVN – Elementos descritos en el segmento EVN"

EVN-1 Tipo de Evento

<Código> (Para tabla completa ver anexo 6.3 de esta guía.)

Mensaje Código Tipo de Evento ADT A01 Admisión, Notificación.

BAR

P01 Apertura de Cuenta P06 Cierre de Cuenta

P10 Información del paciente P12 Codificación de Diagnostico Tabla 18 “Subconjunto de tabla 0003 de HL7”

EVN-2 Hora y fecha del evento

<Fecha (YYYYMMDDhhmmss±ZZZZ)>

Corresponde a fecha y hora de la creación del mensaje.

Representa: Año (4 dígitos), mes (2 dígitos), día (2 dígitos), hora (dos dígitos), minutos (2 dígitos), segundos (2 dígitos), huso horario (signo y dos dígitos de hora más dos dígitos de minutos).

Según ISO 8601.

EVN-5 Código error FONASA

<Código error FONASA>^<Glosa Código error FONASA>

(26)

Página 26 de 44

4.6.3 PID S

EGMENTO IDENTIFICADOR DE PACIENTE Sec Long DT R/O RP

(#)

Tabla Asoc

Nombre del elemento

Obs 3 199 CX R SI 0203 Número de

identificación del beneficiario

Corresponde al ID de documentación del paciente, establecimiento quien asigno el ID, Tipo de documento presentado por el paciente y país emisor del documento (valor predeterminado 152&Chile&ISO3166-1)

5 250 XPN R Primer apellido y nombres del beneficiario

Agregar todos los nombres del paciente. En caso de que no tenga segundo nombre agregar solo Primer nombre

6 194 XPN O Segundo apellido

Por seguridad, agregar siempre este dato. En caso de que no exista segundo apellido dejar en blanco Tabla 19 "Tabla PID – Elementos descritos en el segmento PID"

PID-3 Número de identificación del beneficiario

<id_number>^<verificador>^<>^<AA_Asignación>^<TipoDocumento>^<>^<>^<

>^<CodPaísEmisorDocumento&País&ISOxxxx>

Código Tipo de documento CZ Tarjeta de ciudadanía NI Carnet de Identidad PPN Pasaporte

WP Visa de Trabajo

Tabla 20 Tipo documento según tabla 0203 de HL7

Descripción de los componentes:

• id_number: Corresponde al RUN del paciente sin digito verificador.

• verificador: Digito verificador del RUN

• AA_Asignación: Entidad que emite el RUN. Temporalmente el valor predeterminado será string “RegistroCivil”. En la medida que se obtengan las definiciones por OID, se usaran estos codificadores

• TipoDocumento: Documento presentado por el paciente. Basado en Tabla HL7 0203

• CodPaísEmisorDocumento&País&NormaCodificacionPais:

(27)

Página 27 de 44

o CodPaísEmisorDocumento: Código de país

o Pais: Glosa País

o NormaCodificacionPais: Norma utilizada para codificación de país.

Ejemplo para Cédula de Identidad emitida en Chile, nro 123456789-0 123456789^0^^RegistroCivil^NI^^^^152&Chile&ISO3166-1

PID-5 Primer apellido y nombres del beneficiario

<primer apellido>^<primer nombre>^<segundo nombre>

PID-6 Segundo Apellido

<segundo apellido>

4.6.4 PV1 - S

EGMENTO ORIGEN DEL PACIENTE Sec Long DT R/O RP

(#)

Tabla Asoc

Nombre del elemento

Observación

2 1 IS R 0004 Tipo del encuentro

Tipo de encuentro entre el paciente y el prestador

5 199 CX O Id del encuentro

propio

Numero creado por los prestadores previo al envío del primer mensaje a FONASA. Podrá ser número de ficha clínica u otro.

7 15 XCN O

RUN médico tratante y/o equipo

RUN del profesional médico que atenderá al paciente. Solo requerido para el proceso ambulatorio y en consultas médicas. Si el paciente viene por examen de laboratorio o imagenología dejar en blanco.

8 15 XCN O

RUN Médico que refiere

hospitalización

Sera solo obligatorio para procesos hospitalizados. En ambulatorio dejar en blanco.

18 4 IS R Marca de

Gratuidad

Valido solo en respuesta de FONASA al Prestador. En caso de que el paciente no posea una marca de gratuidad, este campo ira vacío.

19 199 CX R ID

Encuentro FONASA

Este dato solo va en mensaje de respuesta de FONASA hacia los prestadores (solo necesario para BAR P01). En el primer mensaje de los prestadores hacia FONASA dejar en blanco.

(28)

Página 28 de 44

20 20 FC R 0064 Tramo

Beneficiario

Este dato solo va en mensaje de respuesta de FONASA hacia los prestadores (solo necesario para BAR P01). En el primer mensaje de los prestadores hacia FONASA dejar en blanco. Solamente se puede seleccionar una opción. Según Decreto ex. 643 del código de Salud

Tabla 21 "Tabla PV1 – Elementos descritos en el segmento PV1"

PV1-2 Tipo del Encuentro <Valor>

Valor Descripción Comentarios 1 Hospitalizado

2 Urgencia 3 Ambulatorio

Tabla 22 "Tabla 0004 – Tipo de encuentro"

PV1-5 Id del Encuentro Propio <Valor>

PV1-7 RUN médico tratante y/o equipo

<RUN_Médico_Tratante>

En el proceso ambulatorio, solamente aplica para consultas médicas y procedimientos ambulatorios. No así para exámenes de laboratorio o imágenes. En ese caso dejar este campo en blanco

En el proceso hospitalario y emergencia, no aplica.

PV1-8 RUN médico que refiere hospitalización

<RUN_Médico_Hospitalización>

Esto aplica para procesos hospitalario, RUN de médico que indica hospitalización. No aplica para proceso ambulatorio.

PV1-18 Marca de Gratuidad

<Código>

Código Descripción 00 SIN MARCA GRATUIDAD

01 PRAIS

02 ANTUCO

(29)

Página 29 de 44

03 DIRIGENTE VECINAL 04 PRI LONCO

Tabla 23 "Marca de Gratuidad"

PV1-19 ID Encuentro FONASA

<ID Encuentro>

PV1-20 Tramo Beneficiario

<Valor>

Valor Descripción Comentarios A Tramo A de FONASA

B Tramo B de FONASA C Tramo C de FONASA D Tramo D de FONASA X No es un afiliado valido

Tabla 24 "Tabla 0064 – Tipo de paciente"

4.6.5 PR1- S

EGMENTO DE

P

RESTACIONES Sec Long DT R/O RP

(#)

Tabla Asoc

Nombre del elemento

Obs

1 4 SI R Numero de Transacción.

Este es un valor incremental, el cual identifica la transacción.

Para la primera ocurrencia del segmento, la secuencia debería ser 01, para la segunda 02, etc.

3 1 CE R 0004 Tipo de encuentro Tipo de encuentro entre el paciente y el prestador

5 26 IS R Fecha y Hora del Procedimiento.

Fecha y hora de solicitud de prestación por el paciente. Esta fecha es válida para el proceso ambulatorio y hospitalizaciones

programadas. Para

hospitalizaciones no programadas, la fecha y hora será la misma que la presentación en admisión.

Tabla 25 "Tabla PR1 – Elementos descritos en el segmento PR1 "

PR1-1 Número de Transacción

<valor>

(30)

Página 30 de 44

Este es un valor incremental, el cual identifica la transacción. Para la primera ocurrencia del segmento, la secuencia debería ser 01, para la segunda 02, etc.

PR1-3 Código de tipo de encuentro <Valor>

Valor Descripción Comentarios 1 Hospitalizado

2 Urgencia 3 Ambulatorio

Tabla 26 "Tabla 0004 – Tipo de encuentro"

PR1-5 Fecha y Hora del Encuentro <Fecha (YYYYMMDDhhmmss±ZZZZ) >

Representa: Año (4 dígitos), mes (2 dígitos), día (2 dígitos), hora (dos dígitos), minutos (2 dígitos), segundos (2 dígitos), huso horario (signo y dos dígitos de hora más dos dígitos de minutos).

Según ISO 8601.

4.6.6 IN1 S

EGMENTO DE

S

EGURO

Sec. Long DT R/O RP (#)

Tabla Asoc

Nombre del elemento

Obs

1 30 SI R Contador IN1 Valor predeterminado será 1.

2 199 CE R 0072 Leyes previsionales

Según decreto ex. 643 del código de salud. Es responsabilidad del prestador si la atención está cubierta por alguna de estas leyes.

3 15 CX R Tabla 29

DEIS:

Decreto ex.

643/2016

Previsión Previsión a la que el paciente dice pertenecer. Validación a posteriori en mensajería desde FONASA.

Tabla 27 "Tabla IN1 – Elementos descritos en el segmento IN1. "

IN1-1 Contador de Segmento <Valor predeterminado 1>

IN1-2 Leyes previsionales <Código>

Nombre Leyes Previsionales

01 Ley 18.490 Accidentes de Transporte

(31)

Página 31 de 44 02 Ley 16.744 Accidentes del Trabajo y Enfermedades Profesionales

03 Ley 16.744 Accidente Escolar 04 Ley 19.650/99 De Urgencia 05 Ley 19.966 PRAIS

06 Ley 19.966 Régimen General de Garantías en Salud GES

96 Ninguna

97 No Recuerda

Tabla 28 "Tabla 0072 – Leyes previsionales" DEIS: Decreto ex. 643/2016

IN1-3 Previsión

<Código>

Descripción Obs 01 FONASA

02 ISAPRE 03 CAPREDENA 04 DIPRECA 05 SISA 96 NINGUNA 99 DESCONOCIDO

Tabla 29 DEIS: Decreto ex. 643/2016

4.6.7 MSA S

EGMENTO DE CABECERA Sec. Long DT R/O RP

(#)

Tabla Asoc

Item# Nombre del elemento

Obs

1 Variable ID R 0008 00018 Código ACK 2 199 ST R Código ID

mensaje

Deberá ser el mismo código que aquel puesto en la cabecera del mensaje (MSH-10 ID Control de mensaje).

Tabla 30 "Tabla MSA – Elementos descritos en el segmento MSA. "

MSA-1 Código ACK <Código>

Descripción Comentarios

AA Modo original: Aplicación Aceptar - Modo mejorado:

Reconocimiento de la aplicación: Aceptar

Usar este si mensaje es recibido sin daño AE Modo original: Error de aplicación - Modo mejorado:

Reconocimiento de la aplicación: Error

AR Modo original: Rechazo de la aplicación - Modo mejorado:

Reconocimiento de la aplicación: Rechazar

(32)

Página 32 de 44 CA Modo mejorado: Aceptar

confirmación: Confirmar Aceptar

CE Modo mejorado: Aceptar confirmación: Confirmar error

CR Modo mejorado: Aceptar confirmación: Cometer rechazo

Tabla 31 "Tabla 0008 – Acknowledge Code"

MSA-2 Código ID mensaje

<Código Control ID>

(33)

Página 33 de 44

5 E JEMPLOS

5.1 A

MBULATORIO

Rigoberto Ignacio Pérez González, ID de identificación 13.453.567-K, nacionalidad chilena, presenta Carnet de Identidad emitido en Chile como documento identificatorio, emitido por el Registro Civil de Chile. Se presenta el día 23 de noviembre del 2017 a las 16:45 para ser atendido por un doctor con RUN 9.904.867-5 y se le asocia una ficha clínica en el establecimiento con el número 346482 y se registra en el sistema de registro administrativo de la Clínica Sonrisa, RUT Prestador Jurídico 56.867.986-0, RUT de sucursal 54.481.325-4. El tipo de atención es ambulatoria. La atención del paciente no cae dentro de algún tipo de ley previsional y el paciente refiere pertenecer a FONASA.

Los datos son enviados por el prestador a FONASA. Con este proceso, FONASA identifica al beneficiario en su base de datos, identificando a Don Rigoberto Pérez González como beneficiario de FONASA tramo B, sin marca de gratuidad.

FONASA le otorga el código 342RT como ID de encuentro de FONASA para la atención médica.

PRESTADOR ENVÍA:

ADT A01 Tributación Datos de Paciente

MSH|^~\&|SW_RegistroAdministrativoClinicaSonrisa|544813254^568679860^RUT|S W_FONASA|0^616030000^RUT|20171123164500-

0400||ADT^A01^ADT_A01|000001|P|2.5.1 EVN|A01|20171123164500-0400

PID|||13453567^K^^AA_RegistroCivil^NI^^^^152&Chile&ISO3166- 1||Perez^Rigoberto^Ignacio|Gonzalez

PV1||3|||346482||99048675

PR1|01||3||20171123164500-0400

IN1|1|96|01

(34)

Página 34 de 44

ACK ADT A01

MSH|^~\&|SW_FONASA|0^616030000^RUT|SW_RegistroAdministrativoClinicaSonrisa

|544813254^568679860^RUT|20171123164500-0400||ACK|000001|P|2.5.1 MSA|AA|000001

FONASA CREA EL REGISTRO DE ATENCIÓN

BAR P01: Apertura de Cuenta

MSH|^~\&|SW_FONASA|0^616030000^RUT|SW_RegistroAdministrativoClinicaSonrisa

|544813254^568679860^RUT|20171123164500- 0400||BAR^P01^BAR_P01|00004|P|2.5.1 EVN|P01|20171123164500-0400

PID|||13453567^K^^AA_RegistroCivil^NI^^^^152&Chile&ISO3166- 1||Perez^Rigoberto^Ignacio|Gonzalez

PV1||3|||346482||99048675|||||||||||00|342RT|B PR1|01||3||20171123164500-0400

IN1|1|96|01 ACK BAR P01

MSH|^~\&|SW_RegistroAdministrativoClinicaSonrisa|544813254^568679860^RUT|S W_FONASA|0^616030000^RUT|20171123164500-0400||ACK|00004|P|2.5.1

MSA|AA|00004

5.2 H

OSPITALARIO

La paciente Clara Pérez Gómez se presenta en admisión del Servicio Quirúrgico de la Clínica Mejor derivada por un cuadro de dolor abdominal agudo. Presenta su Carnet de Identidad emitido por el Registro Civil en Chile en admisión, RUN 14.563.928-3. La Clínica es una institución privada, RUT jurídico 88.745.453-3, RUT sucursal 98.345.765-8. El ingreso al Servicio de Cirugía se realiza el día 12 de enero del 2017 a las 09:12 y se le asigna el número 12323 como ficha clínica.

La atención no cae dentro de alguna ley provisional y la paciente refiere

pertenecer a FONASA. El medico 8.987.345-6 fue quien deriva a la paciente para

su hospitalización, para resolución quirúrgica.

(35)

Página 35 de 44

El prestador envía los datos a FONASA para la realización de la validación y verificación del beneficiario. FONASA verifica que la paciente es beneficiaria del seguro, tramo C sin marca de gratuidad y se le otorga el ID FONASA 234R4.

PRESTADOR ENVÍA:

ADT A01 Tributación Datos de Paciente

MSH|^~\&|SW_RegistroAdministrativoClinicaMejor|983457658^887454533^RUT|SW_

FONASA|0^616030000^RUT|20170112091200- 0400||ADT^A01^ADT_A01|XYZ1|P|2.5.1 EVN|A01|20170112091200-0400

PID|||14563928^3^^AA_RegistroCivil^NI^^^^152&Chile&ISO3166- 1||Perez^Clara|Gomez

PV1||1|||12323||89873456

PR1|01||1||20170112091200-0400 IN1|1|96|01

ACK ADT A01

MSH|^~\&|SW_FONASA|0^616030000^RUT|SW_RegistroAdministrativoClinicaMejor|

983457658^887454533^RUT|20170112091200-0400||ACK|XYZ1|P|2.5.1 MSA|AA|XYZ1

FONASA CREA EL REGISTRO DE ATENCIÓN

BAR P01: Apertura de Cuenta

MSH|^~\&|SW_FONASA|0^616030000^RUT|SW_RegistroAdministrativoClinicaMejor|

983457658^887454533^RUT|20170112091200- 0400||BAR^P01^BAR_P01|FON02|P|2.5.1 EVN|P01|20170112091200-0400

PID|||14563928^3^^AA_RegistroCivil^NI^^^^152&Chile&ISO3166- 1||Perez^Clara|Gomez

PV1||1|||12323|||89873456||||||||||00|234R4|C PR1|01||1||20170112091200-0400

IN1|1|96|01 ACK BAR P01

MSH|^~\&|SW_RegistroAdministrativoClinicaMejor|983457658^887454533^RUT|SW_

FONASA|0^616003000^RUT|20170112091200-0400||ACK|FON02|P|2.5.1

MSA|AA|FON02

(36)

Página 36 de 44

6 ANEXOS

6.1 N

OMENCLATURA

:

6.1.1 C

RITERIO PARA DEFINIR OBLIGATORIEDAD EN LOS SEGMENTOS

,

CAMPOS Y SUB

-

CAMPOS

:

En la presente guía la definición del estándar HL7 International debe ser respetada, razón por la cual los campos obligatorios por cada segmento de mensaje seleccionado deben ser mantenidos. Este criterio será mantenido en todos los mensajes seleccionados. A parte de éstos, del CMD aparecerán elementos Requeridos adicionales o nuevos campos requeridos para la realidad de los eventos a implementar. Finalmente se puedan estipular los campos Optativos. Una vez concluido esto se determinarán las necesidades de sub- campos por cada campo determinado.

Valor Explicación

R Elemento es requerido en la semántica del segmento O Elemento es opcional en la semántica del segmento

Tabla 32 Explicación datos requeridos y opcionales

En el caso de la columna que define repetitividad (RPT/#), si contiene el carácter

“Y”, entonces el elemento puede repetirse infinitamente.

En la columna “Tabla Asoc” se define si existe una tabla asociada al elemento junto con el número que la identifica.

6.1.2 N

OMENCLATURA EMPLEADA EN LA ESPECIFICACIÓN DE LOS MENSAJES

:

En el caso de los mensajes la estructura abstracta definida presenta los

siguientes

(37)

Página 37 de 44 Valor Explicación

SEG Segmento es obligatorio

[SEG] Segmento puede o no aparecer una única vez.

{SEG} Segmento obligatorio que puede repetirse [{SEG}] Segmento puede o no aparecer repetidas veces.

Tabla 33 Nomenclatura empleada en la especificación de los mensajes

6.2 T

IPOS DE

D

ATOS

(DT)

6.2.1 T

IPOS DE

D

ATOS

En la siguiente tabla se definen los datos básicos empleados en esta guía de implementación HL7 para Atención Ambulatoria y Hospitalizada.

Sigla Explicación Longitud

DT Fecha 8

CE Elemento codificado 483

TS Sello de Tiempo 26

CX ID compuesto ampliado con dígito de verificación 1913

ID Identificador Variable

IS Identificador definido por una tabla. 20 XPN Nombre extendido de la persona 1103

ST Cadena de caracteres. 199

XAD Dirección extendida 631

XCN Número de identificación compuesto y nombre extendido 3002

MSG Tipo de mensaje 15

FC Categoría financiera 20

VID Identificador de versión 5

NM Numérico Variable

Tabla 34 Tipos de datos

6.2.2 D

ATOS

C

OMPUESTOS

:

En la siguiente tabla se definen los datos básicos empleados en esta guía de implementación HL7 para Atención Ambulatoria.

Sigla Explicación DTM Fecha/Hora ST Variable Glosa

(38)

Página 38 de 44 FN Apellido

ID Valores codificados para tablas HL7 HD Designador jerárquico

SAD Dirección

Tabla 35 Tipos de datos compuestos

6.2.3 S

EGMENTOS

Los segmentos que se trabajaran al dar estructura al mensaje en la presente Guía de Implementación son los siguientes:

MSH: Es el segmento cabecera, en el cual se incluyen datos relativos a la mensajería.

EVN: Segmento en el cual se incluyen datos relativos al evento propiamente tal.

PID: Segmento que incluye información relativa al paciente.

PV1: Segmento que incluye información sobre el origen del paciente.

MSA: Segmento que contiene información enviada mientras se reconoce otro mensaje.

PR1: Segmento que hace referencia a los procedimientos que pueden ser realizados a un paciente.

IN1: Segmento que contiene información referente al aseguramiento del paciente.

6.3 T

ABLA

HL7 0003

Value Description

A01 ADT/ACK - Admit/visit notification A02 ADT/ACK - Transfer a patient A03 ADT/ACK - Discharge/end visit A04 ADT/ACK - Register a patient A05 ADT/ACK - Pre-admit a patient

A06 ADT/ACK - Change an outpatient to an inpatient A07 ADT/ACK - Change an inpatient to an outpatient A08 ADT/ACK - Update patient information

A09 ADT/ACK - Patient departing - tracking A10 ADT/ACK - Patient arriving - tracking A11 ADT/ACK - Cancel admit/visit notification

(39)

Página 39 de 44 A12 ADT/ACK - Cancel transfer

A13 ADT/ACK - Cancel discharge/end visit A14 ADT/ACK - Pending admit

A15 ADT/ACK - Pending transfer A16 ADT/ACK - Pending discharge A17 ADT/ACK - Swap patients

A18 ADT/ACK - Merge patient information (for backward compatibility only) A19 QRY/ADR - Patient query

A20 ADT/ACK - Bed status update

A21 ADT/ACK - Patient goes on a “leave of absence”

A22 ADT/ACK - Patient returns from a “leave of absence”

A23 ADT/ACK - Delete a patient record A24 ADT/ACK - Link patient information A25 ADT/ACK - Cancel pending discharge A26 ADT/ACK - Cancel pending transfer A27 ADT/ACK - Cancel pending admit A28 ADT/ACK - Add person information A29 ADT/ACK - Delete person information

A30 ADT/ACK - Merge person information (for backward compatibility only) A31 ADT/ACK - Update person information

A32 ADT/ACK - Cancel patient arriving - tracking A33 ADT/ACK - Cancel patient departing - tracking

A34 ADT/ACK - Merge patient information - patient ID only (for backward compatibility only) A35 ADT/ACK - Merge patient information - account number only (for backward compatibility only)

A36 ADT/ACK - Merge patient information - patient ID and account number (for backward compatibility only) A37 ADT/ACK - Unlink patient information

A38 ADT/ACK - Cancel pre-admit

A39 ADT/ACK - Merge person - patient ID (for backward compatibility only) A40 ADT/ACK - Merge patient - patient identifier list

A41 ADT/ACK - Merge account - patient account number A42 ADT/ACK - Merge visit - visit number

A43 ADT/ACK - Move patient information - patient identifier list A44 ADT/ACK - Move account information - patient account number A45 ADT/ACK - Move visit information - visit number

A46 ADT/ACK - Change patient ID (for backward compatibility only) A47 ADT/ACK - Change patient identifier list

A48 ADT/ACK - Change alternate patient ID (for backward compatibility only) A49 ADT/ACK - Change patient account number

A50 ADT/ACK - Change visit number A51 ADT/ACK - Change alternate visit ID

A52 ADT/ACK - Cancel leave of absence for a patient

A53 ADT/ACK - Cancel patient returns from a leave of absence A54 ADT/ACK - Change attending doctor

A55 ADT/ACK - Cancel change attending doctor A60 ADT/ACK - Update allergy information A61 ADT/ACK - Change consulting doctor A62 ADT/ACK - Cancel change consulting doctor B01 PMU/ACK - Add personnel record

B02 PMU/ACK - Update personnel record B03 PMU/ACK - Delete personnel re cord B04 PMU/ACK - Active practicing person B05 PMU/ACK - Deactivate practicing person

(40)

Página 40 de 44 B06 PMU/ACK - Terminate practicing person

B07 PMU/ACK - Grant Certificate/Permission B08 PMU/ACK - Revoke Certificate/Permission C01 CRM - Register a patient on a clinical trial

C02 CRM - Cancel a patient registration on clinical trial (for clerical mistakes only) C03 CRM - Correct/update registration information

C04 CRM - Patient has gone off a clinical trial C05 CRM - Patient enters phase of clinical trial

C06 CRM - Cancel patient entering a phase (clerical mistake) C07 CRM - Correct/update phase information

C08 CRM - Patient has gone off phase of clinical trial

C09 CSU - Automated time intervals for reporting, like monthly C10 CSU - Patient completes the clinical trial

C11 CSU - Patient completes a phase of the clinical trial

C12 CSU - Update/correction of patient order/result information CNQ Cancel Query

I01 RQI/RPI - Request for insurance information

I02 RQI/RPL - Request/receipt of patient selection display list I03 RQI/RPR - Request/receipt of patient selection list

I04 RQD/RPI - Request for patient demographic data I05 RQC/RCI - Request for patient clinical information I06 RQC/RCL - Request/receipt of clinical data listing I07 PIN/ACK - Unsolicited insurance information

I08 RQA/RPA - Request for treatment authorization information I09 RQA/RPA - Request for modification to an authorization I10 RQA/RPA - Request for resubmission of an authorization I11 RQA/RPA - Request for cancellation of an authorization I12 REF/RRI - Patient referral

I13 REF/RRI - Modify patient referral I14 REF/RRI - Cancel patient referral

I15 REF/RRI - Request patient referral status J01 QCN/ACK - Cancel query/acknowledge message J02 QSX/ACK - Cancel subscription/acknowledge message K11 RSP - Segment pattern response in response to QBP^Q11 K13 RTB - Tabular response in response to QBP^Q13

K15 RDY - Display response in response to QBP^Q15 K21 RSP - Get person demographics response K22 RSP - Find candidates response

K23 RSP - Get corresponding identifiers response K24 RSP - Allocate identifiers response

K25 RSP - Personnel Information by Segment Response K31 RSP - Dispense History

M01 MFN/MFK - Master file not otherwise specified ( for backward compatibility only ) M02 MFN/MFK - Master file - staff practitioner

M03 MFN/MFK - Master file - test/observation ( for backward compatibility only ) M04 MFN/MFK - Master files charge description

M05 MFN/MFK - Patient location master file

M06 MFN/MFK - Clinical study with phases and schedules master file

M07 MFN/MFK - Clinical study without phases but with schedules master file M08 MFN/MFK - Test/observation (numeric) master file

M09 MFN/MFK - Test/observation (categorical) master file M10 MFN/MFK - Test /observation batteries master file M11 MFN/MFK - Test/calculated observations master file M12 MFN/MFK - Master file notification message

M13 MFN/MFK - Master file notification - general

(41)

Página 41 de 44 M14 MFN/MFK - Master file notification - site defined

M15 MFN/MFK - Inventory item master file notification N01 NMQ/NMR - Application management query message

N02 NMD/ACK - Application management data message (unsolicited) O01 ORM - Order message (also RDE, RDS, RGV, RAS)

O02 ORR - Order response (also RRE, RRD, RRG, RRA) O03 OMD - Diet order

O04 ORD - Diet order acknowledgment O05 OMS - Stock requisition order

O06 ORS - Stock requisition acknowledgment O07 OMN - Non-stock requisition order

O08 ORN - Non-stock requisition acknowledgment O09 OMP - Pharmacy/treatment order

O10 ORP - Pharmacy/treatment order acknowledgment O11 RDE - Pharmacy/treatment encoded order

O12 RRE - Pharmacy/treatment encoded order acknowledgment O13 RDS - Pharmacy/treatment dispense

O14 RRD - Pharmacy/treatment dispense acknowledgment O15 RGV - Pharmacy/treatment give

O16 RRG - Pharmacy/treatment give acknowledgment O17 RAS - Pharmacy/treatment administration

O18 RRA - Pharmacy/treatment administration acknowledgment O19 OMG - General clinical order

O20 ORG/ORL - General clinical order response O21 OML - Laboratory order

O22 ORL - General laboratory order response message to any OML O23 OMI - Imaging order

O24 ORI - Imaging order response message to any OMI O25 RDE - Pharmacy/treatment refill authorization request

O26 RRE - Pharmacy/Treatment Refill Authorization Acknowledgement O27 OMB - Blood product order

O28 ORB - Blood product order acknowledgment O29 BPS - Blood product dispense status

O30 BRP - Blood product dispense status acknowledgment O31 BTS - Blood product transfusion/disposition

O32 BRT - Blood product transfusion/disposition acknowledgment

O33 OML - Laboratory order for multiple orders related to a single specimen O34 ORL - Laboratory order response message to a multiple order related to single specimen OML

O35 OML - Laboratory order for multiple orders related to a single container of a specimen O36 ORL - Laboratory order response message to a single container of a specimen OML

P01 BAR/ACK - Add patient accounts P02 BAR/ACK - Purge patient accounts

P03 DFT/ACK - Post detail financial transaction P04 QRY/DSP - Generate bill and A/R statements P05 BAR/ACK - Update account

P06 BAR/ACK - End account

P07 PEX - Unsolicited initial individual product experience report P08 PEX - Unsolicited update individual product experience report P09 SUR - Summary product experience report

P10 BAR/ACK -Transmit Ambulatory Payment Classification(APC) P11 DFT/ACK - Post Detail Financial Transactions - New

P12 BAR/ACK - Update Diagnosis/Procedure PC1 PPR - PC/ problem add

PC2 PPR - PC/ problem update

(42)

Página 42 de 44 PC3 PPR - PC/ problem delete

PC4 QRY - PC/ problem query PC5 PRR - PC/ problem response PC6 PGL - PC/ goal add

PC7 PGL - PC/ goal update PC8 PGL - PC/ goal delete PC9 QRY - PC/ goal query PCA PPV - PC/ goal response

PCB PPP - PC/ pathway (problem-oriented) add PCC PPP - PC/ pathway (problem-oriented) update PCD PPP - PC/ pathway (problem-oriented) delete PCE QRY - PC/ pathway (problem-oriented) query

PCF PTR - PC/ pathway (problem-oriented) query response PCG PPG - PC/ pathway (goal-oriented) add

PCH PPG - PC/ pathway (goal-oriented) update PCJ PPG - PC/ pathway (goal-oriented) delete PCK QRY - PC/ pathway (goal-oriented) query

PCL PPT - PC/ pathway (goal-oriented) query response Q01 QRY/DSR - Query sent for immediate response Q02 QRY/QCK - Query sent for deferred response Q03 DSR/ACK - Deferred response to a query Q04 EQQ - Embedded query language query

Q05 UDM/ACK - Unsolicited display update message Q06 OSQ/OSR - Query for order status

Q07 VQQ - Virtual table query Q08 SPQ - Stored procedure request Q09 RQQ - event replay query

Q11 QBP - Query by parameter requesting an RSP segment pattern response Q13 QBP - Query by parameter requesting an RTB - tabular response Q15 QBP - Query by parameter requesting an RDY display response Q16 QSB - Create subscription

Q17 QVR - Query for previous events Q21 QBP - Get person demographics Q22 QBP - Find candidates

Q23 QBP - Get corresponding identifiers Q24 QBP - Allocate identifiers

Q25 QBP - Personnel Information by Segment Query Q26 ROR - Pharmacy/treatment order response

Q27 RAR - Pharmacy/treatment administration information Q28 RDR - Pharmacy/treatment dispense information Q29 RER - Pharmacy/treatment encoded order information Q30 RGR - Pharmacy/treatment dose information

Q31 QBP - Dispense History

R01 ORU/ACK - Unsolicited transmission of an observation message R02 QRY - Query for results of observation

R03 QRY/DSR Display-oriented results, query/unsol. update (for backward compatibility only) (Replaced by Q05) R04 ORF - Response to query; transmission of requested observation

ROR ROR - Pharmacy prescription order query response R07 EDR - Enhanced Display Response

R08 TBR - Tabular Data Response R09 ERP - Event Replay Response

R21 OUL - Unsolicited laboratory observation

R22 OUL - Unsolicited Specimen Oriented Observation Message

R23 OUL - Unsolicited Specimen Container Oriented Observation Message

Referencias

Documento similar

&#34;No porque las dos, que vinieron de Valencia, no merecieran ese favor, pues eran entrambas de tan grande espíritu […] La razón porque no vió Coronas para ellas, sería

Asegurar una calidad mínima en los datos es una de las tareas más difíciles de conseguir para los organismos públicos cuyo objetivo es publicar datos lo más rápidamente posible

Por PEDRO A. EUROPEIZACIÓN DEL DERECHO PRIVADO. Re- laciones entre el Derecho privado y el ordenamiento comunitario. Ca- racterización del Derecho privado comunitario. A) Mecanismos

En el capítulo de desventajas o posibles inconvenientes que ofrece la forma del Organismo autónomo figura la rigidez de su régimen jurídico, absorbentemente de Derecho público por

b) El Tribunal Constitucional se encuadra dentro de una organiza- ción jurídico constitucional que asume la supremacía de los dere- chos fundamentales y que reconoce la separación

Primeros ecos de la Revolución griega en España: Alberto Lista y el filohelenismo liberal conservador español 369 Dimitris Miguel Morfakidis Motos.. Palabras de clausura

Volviendo a la jurisprudencia del Tribunal de Justicia, conviene recor- dar que, con el tiempo, este órgano se vio en la necesidad de determinar si los actos de los Estados