El documento describe los objetivos y stakeholders clave del Registro Nacional de Historias Clínicas Electrónicas (RENHICE) en Perú. Identifica a los ministerios de salud y otras instituciones gubernamentales, financiadores, proveedores de atención médica e individuos como partes interesadas importantes en el proceso. También resume los estándares y requisitos técnicos necesarios para implementar con éxito el RENHICE y lograr la interoperabilidad de datos de salud electrónicos entre las partes.
SISTEMA DE CLORACIÓN - PARA SISTEMA DE AGUA POTABLE VIVIENDA.pptx
RENHICE objetivos involucrados requisitos
1. GOBIERNO EN TECNOLOGIAS DE LA INFORMACION Y SALUD, NOVIEMBRE 2016 1
Despabilando las Buenas Intenciones del
RENHICE
Jorge Chaup´ın, Member, CIP 146661
Resumen—El prop´osito del art´ıculo es dar las pautas para alcanzar con prestancia los objetivos del RENHICE,
identificando a los involucrados, los insumos necesarios de este proceso, y brindar alcances que ayuden a los
encargados de liderar este desafio.
Index Terms—Gesti´on, RENHICE, HCE, HRE, Protecci´on de Datos, Estandar de Identificaci´on, Autenticaci´on y
Certificaci´on, CDA, HL7.
!
INTRODUCCI ´ON
EN la actualidad en el Per´u, se cuenta con el
marco jur´ıdico necesario para llevar a cabo
grandes desafios en el sector Salud, alineando
la tecnolog´ıa al negocio y soportando el ne-
gocio en la tecnolog´ıa. En este marco jur´ıdico
tenemos:
Ley N.o 30024, Ley que Crea el Registro
Nacional de Historias Cl´ınicas Electr´oni-
cas, del 22 de mayo del 2013; y su regla-
mento aprobado por Decreto Supremo N.o
039-2015-SA, del 17 de diciembre del 2015.
Ley N.o 29733, Ley de Protecci´on de Datos
Personales, del 3 de julio del 2011; y su
reglamento aprobado por Decreto Supre-
mo N.o 003-2013-JUS, del 22 de marzo del
2013.
Ley N.o 27269, Ley de Firmas y Certifica-
dos Digitales, del 26 de mayo del 2000; y
su reglamento aprobado por Decreto Su-
premo N.o 052-2008-PCM, del 21 de junio
del 2001.
y Otros...
Y encontramos los desafios planteados en
los objetivos del RENHICE, los cuales son en
forma resumida:
• Project Manager Senior – PMP Member Id: 2615384,
Enterpise Architect – ISACA Member Number: 809376, MPA
(Maestr´ıa en Gesti´on P´ublica) finalizado,
Skype: giorgio.chaupin, E-mail: jlgz3n@gmail.com,
https://pe.linkedin.com/in/jorgechaupin
Datos de contacto, actualizados a Octubre 26, 2016.
Organizar y mantener el registro de histo-
rias cl´ınicas electr´onicas
Estandarizar los datos y la informaci´on
cl´ınica de historias cl´ınicas electr´onicas,
asi como las caracter´ısticas funcionales de
los sistemas de informaci´on de historias
cl´ınicas electr´onicas
Asegurar la disponibilidad de la infor-
maci´on cl´ınica contenida en las historias
cl´ınicas para el paciente o su representante
legal y para los profesionales de salud
autorizados
Asegurar la continuidad de la atenci´on de
salud al paciente en los establecimientos
de salud y los servicios m´edicos de apoyo
Brindar informaci´on al Sistema Nacional
de Salud para el dise˜no y aplicaci´on de
pol´ıticas p´ublicas que permitan el ejercicio
efectivo del derecho a la salud de las
personas.
Ante lo expuesto, es necesario apoyarnos
en un l´ıder comprometido y un gerente de
proyecto que se soporte en un equipo inter-
disciplinario, el que tendr´a a cargo concretizar
estas buenas intenciones; es indispensable la
experiencia y conocimiento del negocio unido
a la tecnolog´ıa; sin paradigmas del “Donde
esta funcionando, para copiarnos”, “Que otro
se arriesque...”, es dif´ıcil creer en que podemos
ser los primeros en lograr sue˜nos como los
planteados en la Ley, pero no imposible.
Octubre 27, 2016
2. GOBIERNO EN TECNOLOGIAS DE LA INFORMACION Y SALUD, NOVIEMBRE 2016 2
OBJETIVOS
Pautar los pasos para viabilizar las buenas
intenciones del RENHICE.
Identificar a los involucrados para viabili-
zar las buenas intenciones del RENHICE.
Analizar los requerimientos necesarios pa-
ra viabilizar las buenas intenciones plas-
madas en los art´ıculos del RENHICE.
STAKEHOLDERS
Ministerio de Salud - MINSA
Es el ente rector del sector, el cual lidera a
trav´es de la Oficina General de Tecnolog´ıas de
la Informaci´on; la concretizaci´on del RENHI-
CE.
Instituto Nacional de Salud - INS
Es el ente que propone pol´ıticas y
normas, promueve, desarrolla y difunde
la investigaci´on cient´ıfica-tecnol´ogica. Ademas
brinda servicios de salud en los campos
de salud p´ublica, control de enfermedades
transmisibles y no transmisibles para contribuir
a mejorar la calidad de vida de la poblaci´on.
Para estos fines el INS requiere datos y poder
identificar patrones y sobre todo explotar
informaci´on para la toma de desiciones, por lo
cual es un cliente importante del RENHICE.
Superintendencia Nacional de Salud - SUSA-
LUD
Es la instituci´on encargada de proteger y
velar los derechos en salud de cada peruano
orientando y empoderando al ciudadano, si-
tuandolo en el centro del sistema de salud na-
cional. Sus acciones se fundamentan en cuatro
l´ıneas:
1. La promoci´on y protecci´on de los dere-
chos en salud
2. La prevenci´on
3. Restituci´on del derecho
4. Investigaci´on y desarrollo
Por lo cual, registra, autoriza, supervisa y
regula a las Instituciones Administradoras de
Fondos de Aseguramiento en Salud (IAFAS),
as´ı como supervisar a las Instituciones Pres-
tadoras de Servicios de Salud (IPRESS) en el
´ambito de su competencia.
Financiadores de los Servicios de Salud
Son las Instituciones Administradoras de
Fondos de Aseguramiento en Salud (IAFAS).
Se tipifican de la siguiente manera:
IAFAS P´ublicas (SIS, ESSALUD)
IAFAS EPS (Entidades Prestadoras de Sa-
lud)
IAFAS Prepagas
IAFAS Autoseguros
IAFAS Compa˜nias de Seguros
IAFAS AFOCAT (Asociaciones de Fondos
Regionales o Provinciales contra Acciden-
tes de Tr´ansito)
Todas las IAFAS, son clientes importantes del
RENHICE.
Instituciones Prestadoras de Servicios de
Salud - IPRESS
Son aquellos establecimientos de salud
y servicios m´edicos de apoyo, p´ublicos,
privados o mixtos que realizan atenci´on de
salud con fines de prevenci´on, promoci´on,
diagn´ostico, tratamiento y/o rehabilitaci´on;
as´ı como aquellos servicios complementarios o
auxiliares de la atenci´on m´edica.
Estas entidades son las responsables de la
inscripci´on de todos los bancos de datos
personales que pudiera administrar, as´ı como
los datos relativos que sean necesarios para
el ejercicio de los derechos de cada paciente.
Adicionalmente, estas entidades son las que
informan a los pacientes de manera previa a la
recoleccion de sus datos, durante la admision,
la finalidad para la que sus datos personales
ser´an tratados; qui´enes son o pueden ser sus
destinatarios, la existencia del banco de datos
en que se almacenar´an, as´ı como la identidad
y domicilio de su titular.
Toda IPRESS son proveedores del RENHICE.
Profesionales de la Salud
Son profesionales identificados y acreditados
por sus respectivos Colegios Profesionales los
cuales les permiten el ejercicio profesional. Es-
tos actores son vitales en el proceso de cambio
3. GOBIERNO EN TECNOLOGIAS DE LA INFORMACION Y SALUD, NOVIEMBRE 2016 3
del soporte fisico de los registros de atencion
al soporte electronico, mediante el uso de su
certificado digital que deber´a ser entregado por
su respectivo colegio profesional.
Toda los profesionales de la Salud son provee-
dores de informaci´on, son los garantizadores
de la calidad del dato para el RENHICE.
Pacientes
Son los actores principales del proceso de
cambio, y de atenci´on de salud. Son ellos los
propietarios de los datos a resguardar´an e
intercambiaran en el RENHICE.
Todos los pacientes son proveedores de
datos para el RENHICE.
Colegios Profesionales de la Salud
Son instituciones aut´onomas con
personalidad derecho p´ublico encargados
promover y proteger el ejercicio legal de
las profesiones a trav´es de la colegiatura y
habilitaci´on, velando por el cumplimiento de
las normas ´eticas y deontol´ogicas de cada
profesi´on.
En la actualidad, los colegios profesionales
otorgan un carnet y un sello permitiendo a
sus miembros la identificacion y la firma de
sus actuados. Adicionalmente los colegios
profesionales cuentan con el documento
denominado Constancias de Habilidad el cual
sirve para probar el ejercicio legal.
Los colegios profesionales tienen la necesidad
ante esta coyuntura poder brindar a sus
miembros los certificados digitales y la entrega
de constancias de habilidad electronicas.
Direcci´on General de Protecci´on de Datos
Personales
Es la Autoridad Nacional de Protecci´on de
Datos Personales , entidad adscrita al Minis-
terio de Justicia, la cual ejerce las funciones
administrativas, orientadoras, normativas, re-
solutivas, fiscalizadoras y sancionadoras; con el
fin de garantizar el derecho fundamental a la
protecci´on de los datos personales.
ADMINISTRACI ´ON Y ORGANIZACI ´ON DEL
RENHICE
Estandares de Identificaci´on del Dato de Sa-
lud
El Decreto Supremo N.o 024-2005-SA, del 2
de enero del 2006. Se aprob´o la identificaci´on
estandar de datos en salud, en suma son ocho
(8) estandares.
1. Identificaci´on del Procedimiento M´edi-
co: CPT (Current Procedure Terminology).
Cabe mencionar que el uso CDT (Current
Dental Terminology) no esta mencionado.
2. Identificaci´on del Producto Farmaceuti-
co: ATC (Anat´omico, Terap´eutico, Qu´ımi-
co) y DCI (Denominaci´on Com´un Inter-
nacional). Esta identificacion sirve para la
prescripci´on, m´as no para el seguimiento
de los medicamentos dispensados por lo
cual el uso del EAN-13 es necesario.
3. Identificaci´on del Usuario de Salud
(paciente): DNI (Documento Nacional de
Identificacion), Pasaporte y carnet de ex-
tranjeria. En este dato habr´ıa que modifi-
carlo apoy´andonos en el ISO 3166-1, para
usar el codigo OACI, el cual es usado en
los pasaportes e incluso en nuestro DNI
(PER + DNI).
4. Identificaci´on del Establecimiento de
Salud: RUC y C´odigo RENAES.
5. Identificaci´on de la UPS. Un dato con
poco sentido sentido y con muchos pro-
blemas de soporte actual por parte delos
sistemas de informaci´on del estado. Estos
datos se pueden obtener para una mejor
estadistica del tipo de atenci´on y especia-
lidad del profesional.
6. Identificaci´on del Episodio M´edico; Un
correlativo por a˜no, es la identificaci´on de
una atenci´on de salud. Este identificador
habr´ıa que replantearlo para un mejor uso
partiendo quiz´as desde la especialidad
de salud, etc. Garantizar una codificaci´on
simple y usable por los sistemas de infor-
maci´on, que sea irrepetible y ´unico.
7. Identificaci´on del Personal de Salud:
DNI, pasaporte o carnet de extranjeria. En
este caso, es necesario asignar como dato
principal el c´odigo de colegiatura.
8. Identificaci´on del Financiador de Salud:
4. GOBIERNO EN TECNOLOGIAS DE LA INFORMACION Y SALUD, NOVIEMBRE 2016 4
RUC. Tambi´en es necesario identificar al
Financiador por su c´odigo IAFA.
El valor la informaci´on; se fundamenta
en la calidad del valor del dato por
lo cual estandarizar la mayoria de los
datos que intervienen en una atenci´on
de salud es necesario. Asumir estandares
internacionales u homologarlos tales como:
DICOM (Digital Imaging and Communication
in Medicine), CIF (discapacidades), c´odigo de
vacunas, identificaci´on ´unica de las recetas,
identificacion ´unica de los informes de
procedimientos (laboratorios, im´agenes, etc),
entre otros.
Un caso que actualmente es un dolor de
cabeza para las clinicas privadas es la homolo-
gaci´on SEGUS - CPT/CDT; inexistente debido
a concepciones y fines diferentes.
Clinical Data Architecture - CDA
El CDA debe ser alineado al HL7 v3 (siendo
por el momento la version actual); este HL7
CDA es la base del intercambio de datos entre
sistemas de historias clinicas. Por lo cual su
esquematizaci´on y publicaci´on es prioritaria.
Estos archivos XML deben contar con su res-
pectiva firma electr´onica al momento de ser
enviadas para el intercambio de datos.
Infraestructura Tecnologica y Comunicacio-
nes
Segun la Ley, indica que se usara
la infraestructura de la Plataforma de
Interoperabilidad del Estado - PIDE; lo
cual nos ayuda a centrarnos en el software y
la tecnologia de interfaces.
En el Reglamento del RENHICE, establece
un involucrado mas Registro Nacional de
Identificacion y Estado Civil - RENIEC. El cual
desde mi punto de vista personal entorpece y
no suma en el logro de las buenas intenciones
del RENHICE.
La Tecnologia del eDNI, no cuenta con
soporte a Near Field Communication (NFC),
lo cual permitiria una interfaz mas simple
usando dispositivos moviles. Sin necesidad de
un Lector de e-DNI. Su uso solo tiene soporte
al Sistema Operativo Windows en su version
7.0; lo cual descarta los sistemas operativos
mas pupulares en los dispositivos moviles:
Android y iOS.
Los servicios habilitados para el uso de
eDNI solo utiliza el browser Internet Explorer
en su version 8.0 y superiores. Siendo este
browser (navegador); el menos popular, es
decir el menos usado. Adicionalmente, la
escasa o poca integracion del eDNI, con los
sistemas de informacion de manera directa
y transparente. Las actuales iniciativas que
hacen uso del DNI tienen un modulo de firma
desasociado de las aplicaciones.
Por otro lado las empresas dedicadas a
la certificaci´on digital (negocio al cual
se dedican), cuentan con SDKs(Suite
Development Suite) para los lenguajes
de programacion mas populares que
permiten la integraci´on con los sistemas
de informacion. Nos permiten el uso de
cualquier Sistema Operativo y diferentes
dispositivos criptograficos: Token de negocio,
Token USB, Tarjeta Criptogr´afica, Mini lector
USB, Hardware Security Module - HSM, etc.
Proceso de Acreditaci´on del Software de
Historia Clinica Electronica
Este proceso en la brevedad posible debe
mapeado y normado; para incorporarlo en el
Tramite unico de Procesos Adminsitrativos -
TUPA del MINSA, como uno sus los servicios.
IMPLEMENTACI ´ON DEL RENHICE
Arquitectura del Software
La arquitectura del software que soporte el
registro unico y centralizados de los atencio-
nes clinicas electronicas, debe contar con las
caracteristicas de: independencia tecnologica,
escalabilidad y seguridad. Para esto podemos
apoyarnos en frameworks como ITIL, COBIT e
ISOS de calidad en la parte de Gestion.
5. GOBIERNO EN TECNOLOGIAS DE LA INFORMACION Y SALUD, NOVIEMBRE 2016 5
Big Data e Inteligencia de Negocios
Adicional al software de RENHICE, se
debera contar con un infraestructura para la
explotacion de informaci´on, salvaguardando
los datos de filiaci´on de las atenciones clinicas
electronicas.
El Big Data nos permitira encontrar patrones,
lo cual nos apoyara en la seleccion de mejores
estrategias, y visionar los escenarios futuros.
La inteligencia de Negocios, mediante
sus datamarts, nos brindaran informaci´on
explotada y mediante uso de m´etodos de
extrapolaci´on poder soportar la toma de
decisiones.
CONFIDENCIALIDAD, AUTENTICACI ´ON Y
CERTIFICACI ´ON DEL RENHICE
Confidencialidad de Datos Personales
Informaci´on en un registro de salud se
divide en los datos de filiaci´on, y los datos
cl´ınicos. Lo que se requiere salvaguardar son
los datos de filiaci´on para que la identificaci´on
sea s´olo y exclusivo con el permiso del
paciente.
El tratamiento de datos personales debe
realizarse con pleno respeto de los derechos
fundamentales de sus titulares y de los
derechos que esta Ley les confiere. Igual regla
rige para su utilizaci´on por terceros.
En casos relacionados este derecho no
requerir´a a la salud y sea necesario, en
circunstancia de riesgo, para la prevenci´on,
diagn´ostico y tratamiento m´edico o quir´urgico
del titular, siempre que dicho tratamiento sea
realizado en establecimientos de salud y por
profesionales de la salud y medien razones
de inter´es p´ublico previstas por ley o cuando
deban tratarse por razones de salud p´ublica,
se podr´a acceder a dichos datos personales.
Autenticaci´on y Certificaci´on del Personal
de Salud
Cuando nos referimos al t´ermino
“autenticar”; hay que tener en mente la
gesti´on, control de accesos a un sistema de
informaci´on, negando el ingreso de personas
no autorizadas; por lo tanto autenticar es la
capacidad de demostrar que un usuario es
realmente qui´en dicha persona dice ser. Por
lo cual debemos tener en cuenta la ISO 27K
y los factores de autenticaci´on, la cual nos
da pautas para el aseguramiento y control de
este proceso. En un primer factor o nivel de
control de accesos tenemos el uso de cuentas
de usuario y contrase˜nas (dato est´atico), en
un segundo nivel; adicional al primer factor
debemos contar con un dato din´amico ya sea
con el uso de un SMS, tarjeta de coordenadas,
token, etc; en un tercer factor se plantea el uso
de reconocimiento biom´etrico: huella digital,
iris, facial, patrones de voz o escritura, ADN.
Por otro lado tenemos el t´ermino de
“certificaci´on”; en el caso de los profesionales
de salud. El ´unico ente que puede indicar si un
individuo es m´edico, enfermero, odont´ologo,
etc. es su respectivo colegio as´ı como constatar
su habilidad para el ejercicio profesional. Para
el uso de la tecnolog´ıa de firmas digitales cada
profesional deber´a contar con su certificado
digital que lo identifique ante la autoridad
como tal.
Autenticaci´on y Certificaci´on del Paciente
En la secci´on anterior, se di´o alcances claros
de lo que ser´ıa autenticar y certificar. En el
caso de los pacientes, su autenticaci´on es
necesaria para poder acceder a su informaci´on
en los repositorios del RENHICE y poder
hacer efectivo sus derechos ARCO. El paciente
requerir´a uno de los factores de autenticaci´on
expuestos.
Los derechos ARCO permiten que las personas
puedan controlar su informaci´on personal y
exigir que sus datos personales sean tratados
adecuadamente.
Acceso: Toda persona tiene derecho a ob-
tener la informaci´on que sobre s´ı mismo
sea objeto de tratamiento en bancos de da-
tos de administraci´on p´ublica o privada.
Rectificaci´on (Actualizaci´on, Inclusi´on): Es
el derecho del titular de datos personales
6. GOBIERNO EN TECNOLOGIAS DE LA INFORMACION Y SALUD, NOVIEMBRE 2016 6
que se modifiquen los datos que resulten
ser parcial o totalmente inexactos, incom-
pletos, err´oneos o falsos.
Cancelaci´on (Supresi´on): El titular de los
datos personales podr´a solicitar la supre-
si´on o cancelaci´on de sus datos personales
de un banco de datos personales cuando
´estos hayan dejado de ser necesarios o
pertinentes para la finalidad para la cual
hayan sido recopilados.
Oposici´on: Toda persona tiene la posibili-
dad de oponerse, por un motivo leg´ıtimo y
fundado, referido a una situaci´on personal
concreta, a figurar en un banco de datos
o al tratamiento de sus datos personales,
siempre que por una ley no se disponga
lo contrario.
El acceso a estos derechos ARCO, se
aterrizan en una plataforma informatica por
parte de cada IPRESS, en la cual cada paciente
podra ejercer sus derechos. En el caso que los
sistemas de historias cl´ınicas electr´onicas de
las IPRESS esten ya incorporadas al RENHICE,
ser´a obligatoriedad del MINSA, habilitar una
instancia para ejercer lso derechos ARCO por
parte de cada paciente.
Sobre la certificaci´on de pacientes, no cabe
duda que esta condici´on de una persona en
paciente s´olo la podr´ıa establecer las IPRESS
(establecimientos de salud), quienes son los
que acogen a las personas para ser atendidas.
Estas deber´ıan ser las que entreguen en su
proceso de atenci´on en la fase de admisi´on los
certificados digitales para poder ser usados
en cualquier establecimiento, para la firma
de consentimientos informados y acceso a su
repositorio de historias cl´ınicas electr´onicas.
CONCLUSIONES
Se identific´o a los involucrados para viabi-
lizar las buenas intenciones del RENHICE,
adem´as de brindar informaci´on sobre su
participaci´on.
Se analiz´o que los requerimientos necesa-
rios para viabilizar las buenas intenciones
del RENHICE deben ser acompa˜nados por
el involucramiento del m´as alto nivel de
toma de desiciones de las instituciones
interesadas.
REFERENCIAS
[1] Ley N.o 30024, Ley que Crea el Registro Nacional de Historias
Cl´ınicas Electr´onicas, del 22 de mayo del 2013.
[2] Decreto Supremo N.o 039-2015-SA, Reglamento de la Ley del
Registro Nacional de Historias Cl´ınicas Electr´onicas, del 17 de
diciembre del 2015.
[3] Ley N.o 29733, Ley de Protecci´on de Datos Personales, del 3
de julio del 2011.
[4] Decreto Supremo N.o 003-2013-JUS, Reglamento de la Ley de
Protecci´on de Datos Personales, del22 de marzo del 2013.
[5] Ley N.o 27269, Ley de Firmas y Certificados Digitales, del 26
de mayo del 2000.
[6] Decreto Supremo N.o 052-2008-PCM, Reglamento de la Ley
de Firmas y Certificados Digitales, del 21 de junio del 2001.
[7] Decreto Supremo N.o 024-2005-SA, Identificacion estandar de
Datos en Salud, del 2 de enero del 2006.
[8] Something You Know, Have, or Are,
https://www.cs.cornell.edu/courses/cs513/2005fa/nnlauthpeople.html.
[9] Multi-factor authentication, https://en.wikipedia.org/wiki/Multi-
factor authentication.
[10] RENIEC - DNI Electronico,
http://portales.reniec.gob.pe/web/dni/aplicaciones, Octubre
- 2006.
[11] RENIEC, Manual de Usuario del Refirma 1.10, 1ra ed., 24
Enero 2013.
[12] El DNI electr´onico ha muerto: ¡larga vida al DNI 3.0!,
http://www.elconfidencial.com/tecnologia/2013-10-02/el-dni-
electronico-ha-muerto-larga-vida-al-dni-3-0 35442, 02 de
octubre del 2013.