Date post: | 25-Jul-2015 |
Category: |
Documents |
Upload: | oswaldo-canchumani-grillo |
View: | 82 times |
Download: | 0 times |
1
La Historia Clínica Electrónica Interoperable Oswaldo Canchumani Grillo1
1Universidad Peruana Los Andes
Facultad de Ingeniería
Resumen
La mayoría de los establecimientos de salud públicos solo cuentan con sistemas de gestión de
historias clínicas en formato impreso, lo cual obliga a que un paciente tenga una historia en
cada nosocomio donde se atienda, manteniéndose así, una suerte de diversificación de la
información de salud de una persona.
El presente informe presenta una propuesta socio-tecnológica de gestión de la Historia Clínica
Electrónica para el servicio de Consulta Externa que implemente la inter-operabilidad entre los
diversos nosocomios del país, de esta forma, se podrá integrar toda esa información
diversificada en un único documento virtual: la Historia Clínica Electrónica interoperable.
Palabras clave: Historia clínica, inter-operatividad, sistemas distribuidos, Bases de datos
distribuidas.
1. Introducción
El presente informe documenta el entorno
distribuido de la Historia Clínica Electrónica
en el Perú a través de la inter-operatividad
que posibilitará que todo profesional de la
salud pueda acceder a la historia clínica
completa de su paciente. De tal manera,
que al tener acceso a mayor información
del paciente, el profesional podrá dar un
mejor diagnóstico aumentando así la
calidad de la atención médica.
2. Acerca de la empresa
2.1. Industria
Cuidados de la salud del ser humano.
2.2. Organización
Todos los establecimientos de cuidados de
salud de nivel I, II y III pertenecientes al
Ministerio de Salud del Perú (MINSA).
2.3. Redes / Oficinas / Distribución
El área geográfica en que se aplica esta
propuesta es a nivel nacional.
3. Ambiente de TI/SI
3.1. Organización del área de TI
Cada institución de salud del MINSA posee
su propia área de TI. La situación actual del
área de TI es muy variada y depende del
nivel de complejidad del establecimiento, a
saber:
• Establecimientos de complejidad alta.
Corresponde a las Direcciones
Regionales de Salud y a los hospitales
principales. Normalmente el área de TI
comprende un servidor que atiende a
las estaciones del hospital en una
arquitectura de dos (02) capas.
Mayormente atiende pedidos de
sistemas administrativos. Algunos
2
también tienen un servidor web que es
usado sólo para el acceso a Internet.
• Establecimientos de complejidad
media. Corresponde a hospitales
pequeños. Normalmente el área de TI
comprende un servidor que atiende a
las estaciones del hospital. En estos
establecimientos tienden a ser pocas
las estaciones. Mayormente atiende
pedidos de sistemas administrativos
en una arquitectura de dos (02) capas.
Algunos también tienen un servidor
web que es usado sólo para el acceso
a Internet.
• Establecimientos de complejidad baja.
Son las postas médicas. Tienen PC’s
aisladas con sistemas igualmente
independientes.
3.2. Principales sistemas de
información
En general, los establecimientos de
complejidad alta y media tienen sistemas
administrativos:
• Control de medicamentos
• Atención de medicamentos para
pacientes
• Registro de pacientes
• Historia clínica administrativa, es decir,
una base de datos para almacenarla y
emitir información básica y estadística,
mas no es para uso del médico
tratante.
• Facturación
• Planillas
• Contabilidad
Algunos de estos establecimientos, los que
dan servicios de nivel I y II, tienen sistemas
independientes para registrar algunos
resultados médicos:
• Registro de Laboratorio
• Resultados de Servicios de Imagen.
Finalmente, los establecimientos de
complejidad baja, posee pequeños
sistemas administrativos:
• Control de medicamentos y;
• Facturación.
3.3. Estructura de Red
• En los establecimientos de
complejidad alta y media, poseen
sistemas cliente / servidor con
aplicativos basados en base de datos
con SQL.
• En los establecimientos de
complejidad baja, poseen PC’s
independientes con aplicativos
basados en xbase.
3.4. Principales Servidores, Sistemas
Operativos, Bases de Datos. (HW /
SW)
Debido a la variedad de la complejidad, los
establecimientos pueden utilizar equipos TI
muy variados. A continuación, presentamos
los equipos más comunes utilizados en los
establecimientos de salud del MINSA.
3.4.1 Hardware
• Servidor de base de datos. Atiende a
las estaciones cliente en arquitecturas
de dos (02) capas y, en otros casos,
en tres (03) capas
• Servidor WEB. Para ingresar a Internet
y mantener su servidor de correos.
• PC’s actualizadas como estaciones
• Impresoras InkJet y Laser
3.4.2. Software
• El Sistema operativo, es Windows
• El RDBMS, principalmente es SQL
Server de Microsoft
3
• Manejadores de archivos como
Access de Microsoft y archivos planos
.dbf para aplicaciones basadas en
xBase.
3.5. Políticas y Procedimientos base
Las políticas y procedimientos que rigen a
los establecimientos de salud del Perú se
definen a través de la normatividad legal e
institucional del MINSA. Estos instrumentos
que conforman la base legal, se pueden
encontrar en la bibliografía.
4. Sistema distribuido
4.1. Modelo de referencia propuesto
4.1.1. Problema a resolver
Hoy en día los pacientes tienen una
Historia Clínica en cada centro hospitalario
donde se atienden, la cual no es
compartida entre los diversos nosocomios
del país, por lo cual, poseen información
incompleta o duplicada y, cuando están en
formato impreso, son susceptibles de
extraviarse y traspapelarse obligando a
hacer una nueva historia clínica en el
centro hospitalario. Estas deficiencias son
un obstáculo para una atención eficaz y
eficiente causando una limitante directa en
el desempeño de los profesionales de la
salud al no disponer de información
completa, oportuna y de fácil acceso
disminuyendo el nivel de calidad de la
atención al paciente.
Para mejorar el sistema de atención de
pacientes es imprescindible que los
diversos centros hospitalarios compartan la
información clínica de los pacientes
utilizando sistemas distribuidos que hagan
uso de redes de comunicación, por ejemplo
la Web a través de Intranets/Extranets, que
posibiliten el intercambio de información y
la construcción de entornos virtuales de
colaboración en medicina, esto cambiará
radicalmente la manera de cooperar de los
profesionales en el cuidado de la salud.
Esta propuesta tiene como objetivo
proporcionar una vista global e integrada
de la información clínica distribuida en
múltiples sistemas de información
heterogéneos y autónomos.
4.1.2. Propuesta de solución
Esta información clínica compartida, se
refiere a todas las atenciones de salud que
el paciente haya tenido en todos los
nosocomios del país. Estos registros de
atenciones de salud están ubicados en sus
respectivos nosocomios que los crearon
pero serán obtenidos y unificados “al vuelo”
y serán presentados ante los ojos de un
profesional de la salud como si fuera una
historia clínica físicamente real.
A esta historia clínica universal la estamos
denominando Historia Clínica Electrónica
(HCE) y el procedimiento de “unificar al
vuelo” a partir de sistemas informáticos de
salud diferentes se le denomina inter-
operatividad.
4
Desde el punto de vista del usuario, en este
caso el médico tratante, el proceso será
como lo describimos a continuación:
1. En el Consultorio, el médico ingresa al
Visor y digita el DNI del paciente.
2. El Visor solicita al Servidor de BD que
genere los extractos de la HCE.
El Visor solicita a los demás servidores
la HCE del paciente enviando el DNI.
Transmite solo a los Servidores que la
BD Index indique.
El Visor solicita al Servidor de Archivos
que copie los archivos de imagen
correspondientes al directorio temporal.
3. Se ejecuta una rutina ad-hoc que
convierte los datos a un archivo
estándar en formato .txt o .dbf o .xml. A
partir de este archivo, el componente
genera los extractos de la HCE en
formato XML siguiendo el estándar HL7
y deposita en el directorio temporal del
Servidor de Archivos.
Vía SOAP llegan los Extractos de los
otros Servidores y son depositados en
el directorio temporal del Servidor de
Archivos.
Vía SOAP llegan los archivos de
imagen de los otros Servidores y son
depositados en el directorio temporal
del Servidor de Archivos.
4. El Visor combina los extractos en una
HCE única referenciando a las
imágenes correspondientes.
5. El Visor muestra la HCE en pantalla.
6. El médico entrega los formatos de la
HC para que sean ingresados en el
sistemas de HCE
7. El personal de mantenimiento de la
HCE ingresa la información en la bd de
la HCE.
5
Si el paciente es nuevo se envía la
información a todos los centros de
salud inscritos en la red para que se
actualice la bd Index.
4.2. Conceptos básicos de
Cliente/Servidor
4.2.1. Servidores Usados
Actualmente, los establecimientos de salud
trabajan con una arquitectura de
cliente/servidor de dos (02) capas que
atiende a la base de datos y a los clientes.
Comprende un (01) servidor para atender a
clientes y base de datos. Los
establecimiento de mayor complejidad,
pueden poseer, además un servidor WEB
que resuelve, principalmente, las cuentas
de correo electrónico. Esta propuesta,
recomienda añadir un Servidor adicional
para el manejo de la HCE.
En resumen, son tres (03) los servidores a
utilizar:
• Un Servidor de base de datos
• Un Servidor de archivos e imágenes,
opcional
• Un Servidor HCE comprenderá las
siguientes funciones:
o Ejecutar al Visor HCE
o La lógica de agentes de software
que se encargarán de lo siguiente:
� Solicitar a los demás servidores
HCE la información de la HCE
del paciente
� Recibir los extractos de los
demás servidores
� Generar el extracto HCE del
paciente
� Ensamblar la HCE “al vuelo” a
partir de los extractos recibidos
� Ordenar el registro de Pacientes
nuevos en la bd Index de todos
los servidores inscritos en la red
4.2.2. Arquitectura C/S usada
La arquitectura a emplear será
Cliente/Servidor a tres niveles (three tier).
La aplicación se distribuye en los tres
niveles: datos, aplicación e interface de
usuario.
4.2.3. Clasificación usada
El modelo implementa la arquitectura
siguiendo el enfoque de Lógica distribuida.
En el cliente se llevan a cabo la interacción
con el usuario y la parte más trivial de la
lógica de la aplicación. En este caso, se
llevan a cabo controles básicos de rango
de campos, campos obligatorios, etc,
mientras que el grueso de la lógica
permanece en el servidor.
4.2.4. Protocolos usados
Los protocolos utilizados son: HTTPS,
SOAP, TCP/IP y Ethernet. En la figura se
puede observar el caso en que se utilizará
cada uno de los protocolos para la
implementación del sistema distribuido.
6
4.3. Middleware
La capa de middleware incluirá dos (02)
componentes a desarrollar de tipo
intermedio de servicios:
• Generación de extractos en base al
estándar de inter-operatividad HL7. Hl7
es un estándar ANSI para inter-
operatividad de registros sanitarios y
administrativos de la Historia Clínica.
HL7 tiene muchas experiencias
exitosas en otros países (EEUU,
Canadá y Europa) que garantiza la
factibilidad de su implementación en el
Perú. Todos los registros de datos
obtenidos de la base de datos de HC
serán adecuados y ensamblados en
registros planos siguiendo las directivas
de este estándar de inter-operatividad.
• Generación de registros de datos en
xml. El Visor HCE solo trabajará con
archivos en formato xml, por lo cual,
todos los registros planos basados en
HL7 serán guardados en formato xml.
4.4. Objetos
El MINSA mantiene variedad de
arquitecturas de centros de cómputo en los
establecimientos de salud del Perú. Como
se ve en la figura, los establecimientos más
complejos pueden tener más de un servidor
y los menos complejos solo un servidor.
Esta propuesta mantiene la infraestructura
de TI original, ya existente en el
establecimiento de salud como base de
datos, servidores, y estaciones, sin
embargo; hace algunos añadidos. Se
mantiene la infraestructura actual para
evitar los altos costos, en tiempo y dinero,
de implementación de un sistema nuevo a
nivel nacional.
Y, se añaden los nuevos elementos justos
y necesarios para dotar al personal médico
de una Historia Clínica completa. Los
nuevos objetos en la capa Middleware, en
el servidor, serán convocados desde Java
vía la tecnología RMI (Remote Method
Invocation) en un modelo de aplicación
Peer-To-Peer.
Se añaden los siguientes elementos al
entorno TIC de los establecimientos:
7
1. Un Servidor de HCE. Se comporta
como un Servidor-Cliente.
2. Un Firewall
3. Una estación por cada consultorio
externo y laboratorio en el
establecimiento
4. Un sistema Visor HCE.
5. Entorno de red distribuida.
5. Base de datos distribuida usada
La base de datos de HCE a utilizar es la
que existe actualmente en cada
establecimiento de salud y, por medio de
funciones incluidas en el Visor HCE, será
utilizada para que, junto con las demás
bases de datos de los establecimientos de
salud, se crea una Base de Datos
Federada, bajo un modelo es multibase.
8
La Base de Datos Federada se
implementará por medio de agentes que
harán polling entre los servidores externos
para determinar si alguno está solicitando
información de la HCE. Si así fuera, una
organización de agentes extractores
tomarán los datos de la base de datos
local, generará un archivo intermedio con
los datos estandarizados y, a partir de este
archivo estándar, generará los extractos de
información solicitados en un archivo xml.
Como paso final un agente transmitirá este
archivo xml al servidor solicitante.
En el servidor solicitante, el agente que
hace polling, detectará el envío y procederá
a recepcionar el archivo xml grabándolo en
un directorio en el servidor de archivos.
Finalmente, el Visor HCE recibirá la
notificación para mostrar la HCE en la
pantalla del cliente.
6. Desarrollo Web
6.1.1. Características principales del
SHCE
Como ya se dijo, el software a desarrollar,
será el Visor HCE. Este producto será
desarrollado con tecnología Java WEB con
herramientas adecuadas para el manejo de
pantallas en el cliente, acceso a la WEB,
etc.
9
Se usará el aplicativo actual para hacer
mantenimiento a los datos de la HC, por lo
cual se utilizará el DBMS que actualmente
usen en el establecimiento de salud:
MySQL, Postgres, Access, xbase, etc.
El Visor HCE será el nuevo producto a
desarrollar y utilizará archivos en formato
.xml estructurados según el estándar HL7.
Este visor enviará una trama con el DNI del
nuevo paciente y el nodo de la red de inter-
operación en el cual se ha registrado el
paciente a los demás servidores de la red
para que éstos lo registren en su base de
datos Index. Como alternativa se podría
modificar el software actual para que al
ingresar a un paciente nuevo se informe a
los demás servidores inscritos en la red
para que actualicen su base de datos
Index.
6.1.2. Funciones del SHCE
En base a los formatos de la Norma
Técnica NT Nº 022-MINSA /DGSP-V 0.2 se
han identificados las funciones que debe
satisfacer el Visor HCE los mismos que se
muestran en el cuadro siguiente.
Funciones
10
Registro
Registro de los Pacientes nuevos en la bd Index de todos los servidores de la red de inter-operación
Registro de usuarios, roles y controles de seguridad de acceso
Consulta
Lista de Pacientes
Filtros a la Lista de Pacientes
Selección del Paciente
Consulta de datos demográficos del Paciente
Consulta de datos demográficos de Familiares
Consulta de datos del familiar
Consulta de datos socio-económicos de la familia
Consulta de datos de la institución de salud
Consulta de datos de Vivienda de la familia
Consulta de Prescripciones Medicas
Consulta de Ordenes de Farmacia
Consulta de Exámenes solicitados
Gráfico de Signos Vitales para adulto
Gráficos de Signos Vitales para niño
Consulta de Exámenes de Laboratorio efectuados
Consulta de Anamnesis
Consulta de Vacunas
Consulta de Contraindicaciones por reacción a la vacuna
Consulta de factores de salud (drogas, alcohol, tabaco, etc.)
Consulta de interacciones medicamentosas del Paciente
Consulta de alergias del Paciente
Consulta de Problemas
Consulta de Consulta
Consulta de Diagnóstico (CIE10)
Consulta de Valoración Clínica
Consulta de Valoración Mental
Consulta de Valoración Socio-Familiar
Consulta de Notas de Evolución
Consulta de Exámenes Clínicos efectuados
Consulta de procedimientos Clínicos efectuados
Consulta de Examen Ecográfico
Consulta de Examen Hematológico
Consulta de Examen Radiológico
Consulta de Examen REM
Consulta de Examen TAC
Consulta de Examen Clínico General
Consulta de Examen Físico de Abdomen
Consulta de Examen Físico de Cabeza
Consulta de Examen Físico de Cuello
Consulta de Examen Físico Genitourinario
Consulta de Examen Físico de Tórax y Pulmones
Consulta de Examen Neurológico
Consulta del Plan de Trabajo
Consulta de Tratamiento
Consulta de Ordenes: Exámenes, medicamentos, hospitalización, interconsulta, etc.
Consulta de Signos del Paciente
Consulta de Síntomas del Paciente
Consulta de ubicación del Síntoma
11
Citas
Consulta de Cita
Consulta de Notas de Salida
Consulta de Devoluciones al Proveedor
Consulta de Kárdex
Consulta de Medicamentos
Tablas del Sistema
Consulta de Tabla de Ubicación Geográfica
Consulta de Tabla CIE10
Extracto
Extractor de datos demográficos del Paciente
Extractor de datos demográficos de Familiares
Extractor de datos del familiar
Extractor de datos socio-económicos de la familia
Extractor de datos de la institución de salud
Extractor de datos de Vivienda de la familia
Extractor de Prescripciones Medicas
Extractor de Ordenes de Farmacia
Extractor de Solicitud de Examen
Extractor de Exámenes de Laboratorio efectuados
Extractor de Anamnesis
Extractor de Vacunas
Extractor de Contraindicaciones por reacción a la vacuna
Extractor de factores de salud (drogas, alcohol, tabaco, etc.)
Extractor de interacciones medicamentosas del Paciente
Extractor de alergias del Paciente
Extractor de Problemas
Extractor de Consulta
Extractor de Diagnóstico (CIE10)
Extractor de Valoración Clínica
Extractor de Valoración Mental
Extractor de Valoración Socio-Familiar
Extractor de Notas de Evolución
Extractor de Exámenes Clínicos efectuados
Extractor de Procedimientos Clínicos efectuados
Extractor de Examen Ecográfico
Extractor de Examen Hematológico
Extractor de Examen Radiológico
Extractor de Examen REM
Extractor de Examen TAC
Extractor de Examen Clínico General
Extractor de Examen Físico de Abdomen
Extractor de Examen Físico de Cabeza
Extractor de Examen Físico de Cuello
Extractor de Examen Físico Genitourinario
Extractor de Examen Físico de Tórax y Pulmones
Extractor de Examen Neurológico
Extractor del Plan de Trabajo
Extractor de Tratamiento
Extractor de Ordenes: Exámenes, medicamentos, hospitalización, interconsulta, etc.
Extractor de Signos del Paciente
Extractor de Síntomas del Paciente
12
Extractor de ubicación del Síntoma
Obtención de Extractos
6.1.3. Relación de Casos de Uso
identificados
En base a las funciones que debe
satisfacer el sistema se han identificado los
Casos de Uso que se muestran en el
cuadro siguiente.
Casos de Uso
1 Registro de Pacientes nuevos en el Index
2 Extraer Anamnesis
3 Extraer Consulta
4 Extraer Diagnostico
5 Extraer Evolución
6 Extraer Examen efectuado
7 Extraer Familia
8 Extraer Orden de Farmacia
9 Extraer Paciente
10 Extraer Plan de Trabajo
11 Extraer Prescripción Medica
12 Extraer Problema
13 Extraer Procedimiento efectuado
14 Extraer Tratamiento
15 Integrar Extractos
6.2. Ventajas
La historia clínica (de salud) electrónica
tiene diversas ventajas ampliamente
reconocidas sobre las historias
tradicionales basadas en papel, podemos
enumerar las más importantes:
• Acceso a la HCE. Todo el personal
autorizado puede accesar a la
información en la HCE en el momento
que la necesite no sólo localmente sino
también remotamente. Como
consecuencia:
o Ya no habrá repetición de pruebas
diagnósticas
o Ya no se ignorará diagnósticos
anteriores
o En Emergencia se tendrá acceso
inmediato a información valiosa
aunque el paciente se encuentre
imposibilitado de comunicarse con
el médico tratante
• Legibilidad. La información es
generalmente más legible en un
documento impreso que sobre papel
escrito a mano, está mejor organizada
en el sistema informático y mejor
protegida de su deterioro.
• Presentación de la información.
Permite presentar los datos de diversas
formas: cronológicamente, por
problemas, por origen de datos, etc.
• Eficiencia de los profesionales de
salud. Muchas tareas repetitivas
pueden ser automatizadas como las
recetas, la facturación y la confección
de informes de alta a partir de la
información recogida en laboratorios,
cirugía, admisión, etc.
• Investigación médica. Permite
localizar aquellas historias clínicas
relevantes para una determinada
patología, tratamiento, situación social
de los pacientes, etc.
6.3. Desventajas
• Se debe hacer un desembolso inicial
en hardware, software y formación del
personal.
• Se debe hacer una inversión adicional
en la seguridad y confidencialidad de
los datos en la red.
• El personal médico puede presentar
resistencia al uso del computador y del
sistema durante el episodio de
atención al paciente en el consultorio.
• El personal de TI deberá ser
capacitado en conceptos de Historias
13
Clínicas Electrónicas, entornos
distribuidos y bases de datos
distribuidas.
6.4. Controles usados
El Visor HCE será desarrollado en Java
con algunas tecnologías importantes para
asegurar la eficiencia y seguridad del
sistema, como:
• Servlets. Pequeños programas en Java
que se ejecutan de forma persistente
en el servidor, y que, por lo tanto,
tienen una activación muy rápida, y una
forma más simple de hacerlo. Estos
programas procesan una petición y
generan la página de respuesta.
• JSP (Java Server Pages). Pequeños
trozos de código en Java que se
insertan dentro de páginas web. Son
independientes del sistema operativo y
del procesador de la máquina.
7. Observaciones y recomendaciones
Hoy en día los pacientes tienen una Historia
Clínica en cada establecimiento de salud
donde se han atendido. Esta no es
compartida entre los nosocomios, por tanto
usualmente poseen información incompleta o
duplicada o se extravían cuando están en
formato impreso. Todo ello es un obstáculo
para una atención eficaz, eficiente y
económica limitando, además, el desempeño
de los profesionales de la salud al no disponer
de información oportuna y de fácil acceso.
Para mejorar el sistema de atención de
pacientes es imprescindible que los diversos
centros hospitalarios compartan la
información clínica de los pacientes utilizando
sistemas distribuidos que hagan uso de redes
de comunicación que posibiliten el
intercambio de información y la construcción
de entornos virtuales de colaboración en
medicina. Esta disponibilidad de los registros
de la Historia Clínica será una mejora
sustancial en el proceso de atención al
paciente. La ausencia de información puede
conducir a la repetición de pruebas
diagnósticas, ignorar diagnósticos
anteriores, o que en Emergencia no se
tenga disponible información muy valiosa.
Todo esto redunda en tener que asumir
riesgos evitables, mayores gastos para las
instituciones financiadoras y molestias para
los usuarios.
Resolver este problema requiere centralizar
todas las Historias Clínicas, de todos los
pacientes en el Perú, desarrollar un
software estándar, implementarlo en todos
los establecimientos del país y capacitar a
todo el personal a nivel nacional. Esto es
muy costoso en términos de tiempo, dinero,
recursos y curva de aprendizaje.
La alternativa, pasa por buscar una
solución que requiere de un poco de
innovación; se trata de un entorno no
centralizado, utilizando la infraestructura
actual del país, desarrollando un software
complementario, implementarlo en todos
los establecimientos del país gradualmente
y capacitar solo a los médicos (y no a todo
el personal) reduciendo la curva de
aprendizaje.
Es decir, se trata de implementar una base
de datos distribuida utilizando estándares
ya reconocidos y con experiencias previas
en otros países. Así, será mucho más
14
viable la implementación de una Historia
Clínica Electrónica en el Perú.
8. Bibliografía
• Ley N° 26842 – Ley General de Salud
• Ley N° 27269 – Ley de Firmas y
Certificados Digitales
• Ley N° 27657 – Ley del Ministerio de
Salud
• Ley N° 27806 – Ley de Transparencia y
Acceso a la Información Pública
• NT Nº 022-MINSA /DGSP-V 0.2 –
Norma Técnica de Salud para la
Gestión de la Historia Clínica
• Decreto Supremo N° 024 2005-SA, que
aprobó las Identificaciones Estándar de
Datos en Salud
• Resolución Ministerial N° 729-2003
SA/DM, que aprobó el Documento
Técnico: “La Salud Integral:
Compromiso de Todos – El Modelo de
Atención Integral de Salud”.
• Resolución Ministerial N° 751-
2004/MINSA, que aprobó la NT N° 018-
MINSA/DGSP – V.01: Norma Técnica
del Sistema de Referencia y
Contrarreferencia de los
Establecimientos del Ministerio de
Salud”.
• Resolución Ministerial N° 769-
2004/MINSA, que aprobó la NT N° 021-
MINSA/DGSP – V.01: “Norma Técnica
Categorías de Establecimientos del
Sector Salud”.