Despabilando las Buenas Intenciones del RENHICE

6

Click here to load reader

Transcript of Despabilando las Buenas Intenciones del RENHICE

Page 1: Despabilando las Buenas Intenciones del RENHICE

GOBIERNO EN TECNOLOGIAS DE LA INFORMACION Y SALUD, NOVIEMBRE 2016 1

Despabilando las Buenas Intenciones delRENHICE

Jorge Chaupın, Member, CIP 146661

Resumen—El proposito 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 losencargados de liderar este desafio.

Index Terms—Gestion, RENHICE, HCE, HRE, Proteccion de Datos, Estandar de Identificacion, Autenticacion yCertificacion, CDA, HL7.

F

INTRODUCCION

EN la actualidad en el Peru, se cuenta con elmarco jurıdico necesario para llevar a cabo

grandes desafios en el sector Salud, alineandola tecnologıa al negocio y soportando el ne-gocio en la tecnologıa. En este marco jurıdicotenemos:

Ley N.o 30024, Ley que Crea el RegistroNacional de Historias Clınicas Electroni-cas, del 22 de mayo del 2013; y su regla-mento aprobado por Decreto Supremo N.o039-2015-SA, del 17 de diciembre del 2015.Ley N.o 29733, Ley de Proteccion de DatosPersonales, del 3 de julio del 2011; y sureglamento aprobado por Decreto Supre-mo N.o 003-2013-JUS, del 22 de marzo del2013.Ley N.o 27269, Ley de Firmas y Certifica-dos Digitales, del 26 de mayo del 2000; ysu reglamento aprobado por Decreto Su-premo N.o 052-2008-PCM, del 21 de juniodel 2001.y Otros...

Y encontramos los desafios planteados enlos objetivos del RENHICE, los cuales son enforma resumida:

• Project Manager Senior – PMP Member Id: 2615384,Enterpise Architect – ISACA Member Number: 809376, MPA(Maestrıa en Gestion Publica) finalizado,Skype: giorgio.chaupin, E-mail: [email protected],https://pe.linkedin.com/in/jorgechaupin

Datos de contacto, actualizados a Octubre 26, 2016.

Organizar y mantener el registro de histo-rias clınicas electronicasEstandarizar los datos y la informacionclınica de historias clınicas electronicas,asi como las caracterısticas funcionales delos sistemas de informacion de historiasclınicas electronicasAsegurar la disponibilidad de la infor-macion clınica contenida en las historiasclınicas para el paciente o su representantelegal y para los profesionales de saludautorizadosAsegurar la continuidad de la atencion desalud al paciente en los establecimientosde salud y los servicios medicos de apoyoBrindar informacion al Sistema Nacionalde Salud para el diseno y aplicacion depolıticas publicas que permitan el ejercicioefectivo del derecho a la salud de laspersonas.

Ante lo expuesto, es necesario apoyarnosen un lıder comprometido y un gerente deproyecto que se soporte en un equipo inter-disciplinario, el que tendra a cargo concretizarestas buenas intenciones; es indispensable laexperiencia y conocimiento del negocio unidoa la tecnologıa; sin paradigmas del “Dondeesta funcionando, para copiarnos”, “Que otrose arriesque...”, es difıcil creer en que podemosser los primeros en lograr suenos como losplanteados en la Ley, pero no imposible.

Octubre 27, 2016

Page 2: Despabilando las Buenas Intenciones del RENHICE

GOBIERNO EN TECNOLOGIAS DE LA INFORMACION Y SALUD, NOVIEMBRE 2016 2

OBJETIVOSPautar 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.

STAKEHOLDERSMinisterio de Salud - MINSA

Es el ente rector del sector, el cual lidera atraves de la Oficina General de Tecnologıas dela Informacion; la concretizacion del RENHI-CE.

Instituto Nacional de Salud - INSEs el ente que propone polıticas y

normas, promueve, desarrolla y difundela investigacion cientıfica-tecnologica. Ademasbrinda servicios de salud en los camposde salud publica, control de enfermedadestransmisibles y no transmisibles para contribuira mejorar la calidad de vida de la poblacion.

Para estos fines el INS requiere datos y poderidentificar patrones y sobre todo explotarinformacion para la toma de desiciones, por locual es un cliente importante del RENHICE.

Superintendencia Nacional de Salud - SUSA-LUD

Es la institucion encargada de proteger yvelar los derechos en salud de cada peruanoorientando y empoderando al ciudadano, si-tuandolo en el centro del sistema de salud na-cional. Sus acciones se fundamentan en cuatrolıneas:

1. La promocion y proteccion de los dere-chos en salud

2. La prevencion3. Restitucion del derecho4. Investigacion y desarrolloPor lo cual, registra, autoriza, supervisa y

regula a las Instituciones Administradoras deFondos de Aseguramiento en Salud (IAFAS),ası como supervisar a las Instituciones Pres-tadoras de Servicios de Salud (IPRESS) en elambito de su competencia.

Financiadores de los Servicios de SaludSon las Instituciones Administradoras de

Fondos de Aseguramiento en Salud (IAFAS).Se tipifican de la siguiente manera:

IAFAS Publicas (SIS, ESSALUD)IAFAS EPS (Entidades Prestadoras de Sa-lud)IAFAS PrepagasIAFAS AutosegurosIAFAS Companias de SegurosIAFAS AFOCAT (Asociaciones de FondosRegionales o Provinciales contra Acciden-tes de Transito)

Todas las IAFAS, son clientes importantes delRENHICE.

Instituciones Prestadoras de Servicios deSalud - IPRESS

Son aquellos establecimientos de saludy servicios medicos de apoyo, publicos,privados o mixtos que realizan atencion desalud con fines de prevencion, promocion,diagnostico, tratamiento y/o rehabilitacion;ası como aquellos servicios complementarios oauxiliares de la atencion medica.

Estas entidades son las responsables de lainscripcion de todos los bancos de datospersonales que pudiera administrar, ası comolos datos relativos que sean necesarios parael ejercicio de los derechos de cada paciente.Adicionalmente, estas entidades son las queinforman a los pacientes de manera previa a larecoleccion de sus datos, durante la admision,la finalidad para la que sus datos personalesseran tratados; quienes son o pueden ser susdestinatarios, la existencia del banco de datosen que se almacenaran, ası como la identidady domicilio de su titular.

Toda IPRESS son proveedores del RENHICE.

Profesionales de la SaludSon profesionales identificados y acreditados

por sus respectivos Colegios Profesionales loscuales les permiten el ejercicio profesional. Es-tos actores son vitales en el proceso de cambio

Page 3: Despabilando las Buenas Intenciones del RENHICE

GOBIERNO EN TECNOLOGIAS DE LA INFORMACION Y SALUD, NOVIEMBRE 2016 3

del soporte fisico de los registros de atencional soporte electronico, mediante el uso de sucertificado digital que debera ser entregado porsu respectivo colegio profesional.Toda los profesionales de la Salud son provee-dores de informacion, son los garantizadoresde la calidad del dato para el RENHICE.

PacientesSon los actores principales del proceso de

cambio, y de atencion de salud. Son ellos lospropietarios de los datos a resguardaran eintercambiaran en el RENHICE.

Todos los pacientes son proveedores dedatos para el RENHICE.

Colegios Profesionales de la SaludSon instituciones autonomas con

personalidad derecho publico encargadospromover y proteger el ejercicio legal delas profesiones a traves de la colegiatura yhabilitacion, velando por el cumplimiento delas normas eticas y deontologicas de cadaprofesion.

En la actualidad, los colegios profesionalesotorgan un carnet y un sello permitiendo asus miembros la identificacion y la firma desus actuados. Adicionalmente los colegiosprofesionales cuentan con el documentodenominado Constancias de Habilidad el cualsirve para probar el ejercicio legal.

Los colegios profesionales tienen la necesidadante esta coyuntura poder brindar a susmiembros los certificados digitales y la entregade constancias de habilidad electronicas.

Direccion General de Proteccion de DatosPersonales

Es la Autoridad Nacional de Proteccion deDatos Personales , entidad adscrita al Minis-terio de Justicia, la cual ejerce las funcionesadministrativas, orientadoras, normativas, re-solutivas, fiscalizadoras y sancionadoras; con elfin de garantizar el derecho fundamental a laproteccion de los datos personales.

ADMINISTRACION Y ORGANIZACION DELRENHICEEstandares de Identificacion del Dato de Sa-lud

El Decreto Supremo N.o 024-2005-SA, del 2de enero del 2006. Se aprobo la identificacionestandar de datos en salud, en suma son ocho(8) estandares.

1. Identificacion del Procedimiento Medi-co: CPT (Current Procedure Terminology).Cabe mencionar que el uso CDT (CurrentDental Terminology) no esta mencionado.2. Identificacion del Producto Farmaceuti-co: ATC (Anatomico, Terapeutico, Quımi-co) y DCI (Denominacion Comun Inter-nacional). Esta identificacion sirve para laprescripcion, mas no para el seguimientode los medicamentos dispensados por locual el uso del EAN-13 es necesario.3. Identificacion del Usuario de Salud(paciente): DNI (Documento Nacional deIdentificacion), Pasaporte y carnet de ex-tranjeria. En este dato habrıa que modifi-carlo apoyandonos en el ISO 3166-1, parausar el codigo OACI, el cual es usado enlos pasaportes e incluso en nuestro DNI(PER + DNI).4. Identificacion del Establecimiento deSalud: RUC y Codigo RENAES.5. Identificacion de la UPS. Un dato conpoco sentido sentido y con muchos pro-blemas de soporte actual por parte delossistemas de informacion del estado. Estosdatos se pueden obtener para una mejorestadistica del tipo de atencion y especia-lidad del profesional.6. Identificacion del Episodio Medico; Uncorrelativo por ano, es la identificacion deuna atencion de salud. Este identificadorhabrıa que replantearlo para un mejor usopartiendo quizas desde la especialidadde salud, etc. Garantizar una codificacionsimple y usable por los sistemas de infor-macion, que sea irrepetible y unico.7. Identificacion del Personal de Salud:DNI, pasaporte o carnet de extranjeria. Eneste caso, es necesario asignar como datoprincipal el codigo de colegiatura.8. Identificacion del Financiador de Salud:

Page 4: Despabilando las Buenas Intenciones del RENHICE

GOBIERNO EN TECNOLOGIAS DE LA INFORMACION Y SALUD, NOVIEMBRE 2016 4

RUC. Tambien es necesario identificar alFinanciador por su codigo IAFA.

El valor la informacion; se fundamentaen la calidad del valor del dato porlo cual estandarizar la mayoria de losdatos que intervienen en una atencionde salud es necesario. Asumir estandaresinternacionales u homologarlos tales como:DICOM (Digital Imaging and Communicationin Medicine), CIF (discapacidades), codigo devacunas, identificacion unica de las recetas,identificacion unica de los informes deprocedimientos (laboratorios, imagenes, etc),entre otros.

Un caso que actualmente es un dolor decabeza para las clinicas privadas es la homolo-gacion SEGUS - CPT/CDT; inexistente debidoa concepciones y fines diferentes.

Clinical Data Architecture - CDAEl CDA debe ser alineado al HL7 v3 (siendo

por el momento la version actual); este HL7CDA es la base del intercambio de datos entresistemas de historias clinicas. Por lo cual suesquematizacion y publicacion es prioritaria.Estos archivos XML deben contar con su res-pectiva firma electronica al momento de serenviadas para el intercambio de datos.

Infraestructura Tecnologica y Comunicacio-nes

Segun la Ley, indica que se usarala infraestructura de la Plataforma deInteroperabilidad del Estado - PIDE; locual nos ayuda a centrarnos en el software yla tecnologia de interfaces.

En el Reglamento del RENHICE, estableceun involucrado mas Registro Nacional deIdentificacion y Estado Civil - RENIEC. El cualdesde mi punto de vista personal entorpece yno suma en el logro de las buenas intencionesdel RENHICE.

La Tecnologia del eDNI, no cuenta consoporte a Near Field Communication (NFC),lo cual permitiria una interfaz mas simple

usando dispositivos moviles. Sin necesidad deun Lector de e-DNI. Su uso solo tiene soporteal Sistema Operativo Windows en su version7.0; lo cual descarta los sistemas operativosmas pupulares en los dispositivos moviles:Android y iOS.

Los servicios habilitados para el uso deeDNI solo utiliza el browser Internet Exploreren su version 8.0 y superiores. Siendo estebrowser (navegador); el menos popular, esdecir el menos usado. Adicionalmente, laescasa o poca integracion del eDNI, con lossistemas de informacion de manera directay transparente. Las actuales iniciativas quehacen uso del DNI tienen un modulo de firmadesasociado de las aplicaciones.

Por otro lado las empresas dedicadas ala certificacion digital (negocio al cualse dedican), cuentan con SDKs(SuiteDevelopment Suite) para los lenguajesde programacion mas populares quepermiten la integracion con los sistemasde informacion. Nos permiten el uso decualquier Sistema Operativo y diferentesdispositivos criptograficos: Token de negocio,Token USB, Tarjeta Criptografica, Mini lectorUSB, Hardware Security Module - HSM, etc.

Proceso de Acreditacion del Software deHistoria Clinica Electronica

Este proceso en la brevedad posible debemapeado y normado; para incorporarlo en elTramite unico de Procesos Adminsitrativos -TUPA del MINSA, como uno sus los servicios.

IMPLEMENTACION DEL RENHICE

Arquitectura del Software

La arquitectura del software que soporte elregistro unico y centralizados de los atencio-nes clinicas electronicas, debe contar con lascaracteristicas de: independencia tecnologica,escalabilidad y seguridad. Para esto podemosapoyarnos en frameworks como ITIL, COBIT eISOS de calidad en la parte de Gestion.

Page 5: Despabilando las Buenas Intenciones del RENHICE

GOBIERNO EN TECNOLOGIAS DE LA INFORMACION Y SALUD, NOVIEMBRE 2016 5

Big Data e Inteligencia de NegociosAdicional al software de RENHICE, se

debera contar con un infraestructura para laexplotacion de informacion, salvaguardandolos datos de filiacion de las atenciones clinicaselectronicas.

El Big Data nos permitira encontrar patrones,lo cual nos apoyara en la seleccion de mejoresestrategias, y visionar los escenarios futuros.

La inteligencia de Negocios, mediantesus datamarts, nos brindaran informacionexplotada y mediante uso de metodos deextrapolacion poder soportar la toma dedecisiones.

CONFIDENCIALIDAD, AUTENTICACION YCERTIFICACION DEL RENHICEConfidencialidad de Datos Personales

Informacion en un registro de salud sedivide en los datos de filiacion, y los datosclınicos. Lo que se requiere salvaguardar sonlos datos de filiacion para que la identificacionsea solo y exclusivo con el permiso delpaciente.El tratamiento de datos personales deberealizarse con pleno respeto de los derechosfundamentales de sus titulares y de losderechos que esta Ley les confiere. Igual reglarige para su utilizacion por terceros.

En casos relacionados este derecho norequerira a la salud y sea necesario, encircunstancia de riesgo, para la prevencion,diagnostico y tratamiento medico o quirurgicodel titular, siempre que dicho tratamiento searealizado en establecimientos de salud y porprofesionales de la salud y medien razonesde interes publico previstas por ley o cuandodeban tratarse por razones de salud publica,se podra acceder a dichos datos personales.

Autenticacion y Certificacion del Personalde Salud

Cuando nos referimos al termino“autenticar”; hay que tener en mente lagestion, control de accesos a un sistema de

informacion, negando el ingreso de personasno autorizadas; por lo tanto autenticar es lacapacidad de demostrar que un usuario esrealmente quien dicha persona dice ser. Porlo cual debemos tener en cuenta la ISO 27Ky los factores de autenticacion, la cual nosda pautas para el aseguramiento y control deeste proceso. En un primer factor o nivel decontrol de accesos tenemos el uso de cuentasde usuario y contrasenas (dato estatico), enun segundo nivel; adicional al primer factordebemos contar con un dato dinamico ya seacon el uso de un SMS, tarjeta de coordenadas,token, etc; en un tercer factor se plantea el usode reconocimiento biometrico: huella digital,iris, facial, patrones de voz o escritura, ADN.

Por otro lado tenemos el termino de“certificacion”; en el caso de los profesionalesde salud. El unico ente que puede indicar si unindividuo es medico, enfermero, odontologo,etc. es su respectivo colegio ası como constatarsu habilidad para el ejercicio profesional. Parael uso de la tecnologıa de firmas digitales cadaprofesional debera contar con su certificadodigital que lo identifique ante la autoridadcomo tal.

Autenticacion y Certificacion del PacienteEn la seccion anterior, se dio alcances claros

de lo que serıa autenticar y certificar. En elcaso de los pacientes, su autenticacion esnecesaria para poder acceder a su informacionen los repositorios del RENHICE y poderhacer efectivo sus derechos ARCO. El pacienterequerira uno de los factores de autenticacionexpuestos.

Los derechos ARCO permiten que las personaspuedan controlar su informacion personal yexigir que sus datos personales sean tratadosadecuadamente.

Acceso: Toda persona tiene derecho a ob-tener la informacion que sobre sı mismosea objeto de tratamiento en bancos de da-tos de administracion publica o privada.Rectificacion (Actualizacion, Inclusion): Esel derecho del titular de datos personales

Page 6: Despabilando las Buenas Intenciones del RENHICE

GOBIERNO EN TECNOLOGIAS DE LA INFORMACION Y SALUD, NOVIEMBRE 2016 6

que se modifiquen los datos que resultenser parcial o totalmente inexactos, incom-pletos, erroneos o falsos.Cancelacion (Supresion): El titular de losdatos personales podra solicitar la supre-sion o cancelacion de sus datos personalesde un banco de datos personales cuandoestos hayan dejado de ser necesarios opertinentes para la finalidad para la cualhayan sido recopilados.Oposicion: Toda persona tiene la posibili-dad de oponerse, por un motivo legıtimo yfundado, referido a una situacion personalconcreta, a figurar en un banco de datoso al tratamiento de sus datos personales,siempre que por una ley no se dispongalo contrario.

El acceso a estos derechos ARCO, seaterrizan en una plataforma informatica porparte de cada IPRESS, en la cual cada pacientepodra ejercer sus derechos. En el caso que lossistemas de historias clınicas electronicas delas IPRESS esten ya incorporadas al RENHICE,sera obligatoriedad del MINSA, habilitar unainstancia para ejercer lso derechos ARCO porparte de cada paciente.

Sobre la certificacion de pacientes, no cabeduda que esta condicion de una persona enpaciente solo la podrıa establecer las IPRESS(establecimientos de salud), quienes son losque acogen a las personas para ser atendidas.Estas deberıan ser las que entreguen en suproceso de atencion en la fase de admision loscertificados digitales para poder ser usadosen cualquier establecimiento, para la firmade consentimientos informados y acceso a surepositorio de historias clınicas electronicas.

CONCLUSIONES

Se identifico a los involucrados para viabi-lizar las buenas intenciones del RENHICE,ademas de brindar informacion sobre suparticipacion.Se analizo que los requerimientos necesa-rios para viabilizar las buenas intencionesdel RENHICE deben ser acompanados porel involucramiento del mas alto nivel de

toma de desiciones de las institucionesinteresadas.

REFERENCIAS

[1] Ley N.o 30024, Ley que Crea el Registro Nacional de HistoriasClınicas Electronicas, del 22 de mayo del 2013.

[2] Decreto Supremo N.o 039-2015-SA, Reglamento de la Ley delRegistro Nacional de Historias Clınicas Electronicas, del 17 dediciembre del 2015.

[3] Ley N.o 29733, Ley de Proteccion de Datos Personales, del 3de julio del 2011.

[4] Decreto Supremo N.o 003-2013-JUS, Reglamento de la Ley deProteccion de Datos Personales, del22 de marzo del 2013.

[5] Ley N.o 27269, Ley de Firmas y Certificados Digitales, del 26de mayo del 2000.

[6] Decreto Supremo N.o 052-2008-PCM, Reglamento de la Leyde Firmas y Certificados Digitales, del 21 de junio del 2001.

[7] Decreto Supremo N.o 024-2005-SA, Identificacion estandar deDatos 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., 24Enero 2013.

[12] El DNI electronico 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 deoctubre del 2013.