Arxius de l'autor: Marc Górriz

Marc Górriz

Sobre Marc Górriz

Enginyer Tècnic en Informàtica de Gestió, treballo al CCI-TCM actualment en la línia d’entorns d’interoperabilitat.

Pàgina web:

Aplicació d’Intel·ligència Artificial en el reconeixement de la Llengua de signes catalana

Leer en castellano
Read It in English

En aquesta entrada s’explica breument la recerca realitzada per estudiar mecanismes per al reconeixement de la llengua de signes a partir d’imatges.

Aquest projecte es va plantejar degut a que des del CCI es vol potenciar la utilització de la intel·ligència artificial per aconseguir beneficis en àmbits relacionats amb la salut. En una societat on cada dia s’aposta més per la integració de les persones amb discapacitat i on la tecnologia cada dia és més present, es considera que cal cercar formes d’aprofitar-la per aquest fi.

En aquest projecte a més d’estudiar les possibilitats en l’àrea del reconeixement de la llengua de signes, es va realitzar una eina per facilitar l’aprenentatge i la millora en l’ús de la llengua de signes catalana (LSC). Aquesta eina permet fer una demostració d’una de les possibles aplicacions que podria tenir aquest algoritme. Addicionalment podria tenir moltes altres aplicacions, com per exemple un traductor per mòbils amb càmera que permetés la comunicació amb persones no familiaritzades amb la LSC.

Un dels punts claus en un sistema de reconeixement d’imatge és el sistema de captura d’aquestes. La tecnologia escollida és el dispositiu Kinect desenvolupat per Microsoft mitjançant el qual es capturen els signes duts a terme per l’usuari. El procés de captura es duu a terme utilitzant la càmera de profunditat que inclou Kinect. A més de capturar la profunditat, gràcies a la càmera d’infrarojos permet una major independència de la il·luminació disponible tant en la captura d’imatges d’entrenament com en la fase d’explotació.

Quan Kinect retorna la imatge de profunditat, imatge on es representa la profunditat amb diferents colors, aquesta es binaritza. Aquest procés consisteix en que si el valor d’un píxel supera el llindar el píxel serà d’un color (blanc o negre) i si no el supera serà de l’altre color. D’aquesta manera es pot separar les mans del fons.

Posteriorment la imatge binaritzada ha de passar un sistema de preselecció que s’encarrega de descartar les lletres que no coincideixin en orientació i nombre de vèrtexs amb la imatge d’entrada.

Després de la preselecció s’inicia l’algoritme d’agrupament Knn sobre les lletres preseleccionades, aquest algoritme utilitza dos paràmetres que són l’àrea de la mà segmentada en quatre porcions i el perímetre de la mà. L’algoritme Knn determina la lletra que ha realitzat l’usuari, comparant el valor dels dos marcadors de la mostra realitzada per l’usuari amb les mostres d’entrenament que té l’aplicació.

A la següent imatge es representa de forma resumida aquest procés.

L’algoritme de clustering Knn consta de dues parts. Prèviament a la fase d’explotació del algoritme es necessari realitzar una fase d’entrenament en la que es defineixen els clústers que corresponen a cadascuna de les lletres.

Per generar aquests clústers es proporciona a l’algoritme un conjunt d’imatges de mostra  etiquetades amb la lletra a que es corresponen. Les mostres d’entrenament són imatges dels signes realitzades per un grup de persones de diferents edats, sexes i races. En base a l’àrea segmentada de la mà i el perímetre d’aquesta es situen les mostres en l’espai formant els diferents clústers.

En la fase d’explotació inicialment es calcula el valor dels marcadors de la mostra a reconèixer per poder situar la nova mostra dins l’espai de mostres d’entrenament.

A continuació es calcula la distància euclidiana de la mostra a reconèixer amb totes les mostres d’entrenament utilitzant els valors dels marcadors dividits entre la seva variança per tal d’igualar el seu pes. Es necessari dividir els marcadors entre la variança per evitar que els de major variabilitat tinguin un pes major a l’algoritme.

Seguidament cal obtenir el conjunt de les K mostres d’entrenament amb major similitud i determinar quina lletra té un major nombre d’ocurrències. La lletra predominant és el resultat del reconeixement. Es a dir s’obté les mostres que estan més properes en l’espai a la imatge que es vol reconèixer, suposant que aquestes pertanyen a la mateixa lletra.

Per últim el procés de Knn es repeteix 25 vegades per signe, a partir de 50 imatges del signe realitzat, agafades no consecutivament per reduir l’efecte de possibles errors de captura. A aquestes 25 imatges es comprova que com a mínim hi hagi una lletra que hagi estat seleccionada pel Knn més cops que el valor definit pel marge d’acceptació, en cas contrari s’informa que el reconeixement ha fallat. El valor òptim del marge d’acceptació s’ha considerat de quinze, mitjançant proves empíriques amb diferents persones utilitzant l’aplicació.

Llegir en català
Read It in English

En esta entrada se explica brevemente la investigación realizada para estudiar mecanismos para el reconocimiento de la lengua de signos a partir de imágenes.

Este proyecto se planteó debido a que desde el CCI se quiere potenciar la utilización de la inteligencia artificial para conseguir beneficios en ámbitos relacionados con la salud. En una sociedad donde cada día se apuesta más por la integración de las personas con discapacidad y donde la tecnología cada día es más presente, se considera que hay que buscar formas de aprovecharla por este fin.

En este proyecto además de estudiar las posibilidades en el área del reconocimiento de la lengua de signos, se realizó una herramienta para facilitar el aprendizaje y la mejora en el uso de la lengua de signos catalana (LSC). Esta herramienta permite hacer una demostración de una de las posibles aplicaciones que podría tener este algoritmo. Adicionalmente podría tener otras muchas aplicaciones, como por ejemplo un traductor para móviles con cámara que permitiera la comunicación con personas no familiarizadas con la LSC.

Uno de los puntos claves en un sistema de reconocimiento de imagen es el sistema de captura de estas. La tecnología escogida es el dispositivo Kinect desarrollado por Microsoft mediante el cual se capturan los signos llevados a cabo por el usuario. El proceso de captura se realiza utilizando la cámara de profundidad que incluye Kinect. Además de capturar la profundidad, gracias a la cámara de infrarrojos permite una mayor independencia de la iluminación disponible tanto en la captura de imágenes de entrenamiento como en la fase de explotación.

Cuando Kinect devuelve la imagen de profundidad, imagen donde se representa la profundidad con diferentes colores, esta se binariza. Este proceso consiste en que si el valor de un píxel supera el umbral definido el píxel será de un color (blanco o negro) y si no lo supera será del otro color. De este modo se puede separar las manos del fondo.

Posteriormente la imagen binarizada tiene que pasar un sistema de preselección que se encarga de descartar las letras que no coincidan en orientación y número de vértices con la imagen de entrada.

Después de la preselección, se inicia el algoritmo de agrupamiento Knn sobre las letras preseleccionadas, este algoritmo utiliza dos parámetros que son el área de la mano segmentada en cuatro porciones y el perímetro de la mano. El algoritmo Knn determina la letra que ha realizado el usuario, comparando el valor de los dos marcadores de la muestra realizada por el usuario con las muestras de entrenamiento que tiene la aplicación.

En la siguiente imagen se representa de forma resumida este proceso.

El algoritmo de clustering Knn consta de dos partes. Previamente a la fase de explotación del algoritmo es necesario realizar una fase de entrenamiento en la que se definen los clústeres que corresponden a cada una de las letras.

Para generar estos clústeres se proporciona al algoritmo un conjunto de imágenes de muestra etiquetadas con la letra a que se corresponden. Las muestras de entrenamiento son imágenes de los signos realizadas por un grupo de personas de diferentes edades, sexos y razas. En base al valor del área segmentada de la mano y el perímetro de esta se sitúan las muestras en el espacio formando los diferentes clústeres.

En la fase de explotación inicialmente se calcula el valor de los marcadores de la muestra a reconocer para poder situar la nueva muestra dentro del espacio de muestras de entrenamiento.

A continuación se calcula la distancia euclídea de la muestra a reconocer con todas las muestras de entrenamiento utilizando los valores de los marcadores divididos entre su varianza para igualar su peso. Es necesario dividir los marcadores entre la varianza para evitar que los de mayor variabilidad tengan un peso mayor en el algoritmo.

Seguidamente hay que obtener el conjunto de las K muestras de entrenamiento con mayor similitud y determinar qué letra tiene un mayor número de ocurrencias. La letra predominante es el resultado del reconocimiento. Es decir se obtiene las muestras que están más cercanas en el espacio a la imagen que se quiere reconocer, suponiendo que estas pertenecen a la misma letra.

Por último el proceso de Knn se repite 25 veces por signo, a partir de 50 imágenes del signo realizado, cogidas no consecutivamente para reducir el efecto de posibles errores de captura. En estas 25 imágenes se comprueba que como mínimo haya una letra que haya sido seleccionada por el Knn más veces que el valor definido por el margen de aceptación, en caso contrario se informa que el reconocimiento ha fallado. El valor óptimo del margen de aceptación se ha considerado de quince, mediante pruebas empíricas con diferentes personas utilizando la aplicación.

This post is only available in Catalan and Spanish:
Llegir en català (Read it in Catalan)
Leer en castellano (Read it in Spanish)

Serveis web a Mirth

Leer en castellano

Un servei web (Web Service en anglès) és una col·lecció de protocols i estàndards que serveix per intercanviar dades entre aplicacions. Diferents aplicacions de programari desenvolupades en llenguatges de programació diferents i executades sobre qualsevol plataforma poden utilitzar els serveis web per l’intercanvi de dades en una xarxa com Internet. Aquesta gran interoperatibilitat s’aconsegueix gràcies a l’adopció d’estàndards oberts.

El protocol usat per la transferència de missatges entre serveis web és SOAP, un protocol de comunicació dissenyat per intercanviar missatges en format XML en una xarxa d’ordinadors, normalment sobre el protocol HTTP.

Mirth disposa d’un web service listener ja definit al qual nomes cal definir-li el port,nom del servei i les interfícies que es volen escoltar, aquest web service permet rebre un paràmetre de tipus cadena de caràcters.

D’aquesta manera no es restringeix el contingut ja que al ser una cadena de caràcters no es valida i pot ser qualsevol tipus de dades. Mirth s’encarregarà de rebre el contingut del literal i parsejarlo al tipus  de dada definit en al origen com pot ser un XML.

Encara que aquest servei web per defecte no és gaire restrictiu i es pot usar en molts casos, és possible que sigui necessari modificar una major quantitat d’aspectes del  servei web més enllà dels mencionats anteriorment per això s’ha definit l’opció dels serveis web personalitzats (customs webservices).

Aquests webservices s’han de definir usant una classe Java que sigui subclasse  de AcceptMessage. Mitjançant anotacions es defineixen les seves propietats i mètodes.

Amb l’anotació @Webservice es defineixen els atributs del webservice, els principals són:

  • WsdlLocation: Defineix la ruta on es troba el wsdl que es publicarà.
  • TargetNamespace: Defineix el namespace del WSDL.
  • ServiceName: El nom del servei.
  • Name: El nom del wsdl:portType.
  • PortName: El valor del wsdl:portName.

A més de definir la configuració del webservice s’han de definir els mètodes del webservice. Els mètodes es defineixen com un mètode Java qualsevol però amb la particularitat que és necessari afegir l’anotació @WebMethod per indicar que és un mètode del webservice.

Un cop s’ha definit aquesta classe cal realitzar un arxiu Jar que contingui la classe i situar-lo a la carpeta custom-libs de Mirth. Seguidament és imprescindible fer referència aquesta classe en el listener tal com es pot veure a la següent imatge.

A més és necessari marcar Custom service i introduir el classpath de la classe que defineix el servei a Service Class Name.

Per últim per definir la resposta del servei s’ha d’afegir un objecte de la classe response al response map.

També serà imperatiu fer referencia a aquest element del response map al respond from de l’origen.

Seguint les directrius i instruccions que s’han presentat en aquesta entrada s’ha de poder crear gairebé qualsevol tipus de web service amb Mirth. Aconseguint així una major versatilitat al realitzar integracions que requereixin d’aquesta mena de serveis.

 

Llegir en català 

Un servicio web (Web Service en inglés) es una colección de protocolos y estándares que sirve para intercambiar datos entre aplicaciones. Diferentes aplicaciones de software desarrolladas en lenguajes de programación diferentes y ejecutadas sobre cualquier plataforma pueden utilizar los servicios web para el intercambio de datos en una red como Internet. Esta interoperatibilidad se consigue gracias a la adopción de estándares abiertos.

El protocolo usado para la transferencia de mensajes entre servicios web es SOAP, un protocolo de comunicación diseñado para intercambiar mensajes en formato XML en una red de ordenadores, normalmente sobre el protocolo HTTP.

Mirth dispone de un web service listener ya definido al cual solo hay que definirle el puerto,nombre del servicio y las interfaces que se quieren escuchar, este web service permite recibir un parámetro de tipo cadena de caracteres.

De este modo no se restringe el contenido puesto que al ser una cadena de caracteres no se valida y puede ser cualquier tipo de datos. Mirth se encargará de recibir el contenido del literal y parsearlo al tipo de dato definido en al origen como puede ser un XML.

Aunque este servicio web por defecto no es muy restrictivo y se puede usar en muchos casos, es posible que sea necesario modificar una mayor cantidad de aspectos de el servicio web más allá de los mencionats anteriormente por eso se ha definido la opción de los servicios web personalizados (customs webservices).

Estos servicios web se tienen que definir usando una clase Java que sea subclase de AcceptMessage. Mediante anotaciones se definen sus propiedades y métodos.

Con la anotación @Webservice se definen los atributos del servicio web, los principales son:

  • WsdlLocation: Define la ruta donde se encuentra el Wsdl que se publicará.
  • TargetNamespace: Define el namespace del Wsdl.
  • ServiceName: El nombre del servicio.
  • Name: El nombre del wsdl:portType.
  • PortName: El valor del wsdl:portName.

Además de definir la configuración del webservice se tienen que definir los métodos del webservice. Los métodos se definen como un método Java cualquiera pero con la particularidad que es necesario añadir la anotación @WebMethod para indicar que es un método del servicio.

Una vez se ha definido esta clase hay que realizar un archivo Jar que contenga la clase y situarlo en la carpeta custom-libs de Mirth. Seguidamente es imprescindible hacer referencia a esta clase en el listener tal como se puede ver a la siguiente imagen.

Además es necesario marcar Custom service e introducir el classpath de la clase que define el servicio en Service Class Name.

Por último para definir la respuesta del servicio se debe añadir un objeto de la clase response al response map.

También será imperativo hacer referencia a este elemento del response map en el respond from del origen.

Siguiendo las directrices e instrucciones que se han presentado en esta entrada se debe poder crear casi cualquier tipo de web service con Mirth. Consiguiendo así una mayor versatilidad al realizar integraciones que requieran de este tipo de servicios.

HAPI (HL7 application programming interface)

Leer en castellano 

HAPI (HL7 application programming interface) és una API de codi obert per al tractament de missatges HL7 2.X amb Java. El projecte no està afiliat a la organització de HL7 però en compleix les especificacions. Va ser iniciat per la University Health Network.

Les principals funcions de HAPI són les següents:

-Extreure la informació dels camps del missatge d’una manera més senzilla, mitjançant un conjunt de  classes que permeten convertir els missatges HL7 en objectes Java que contindran la informació.

//Es recupera  el missatge com un objecte

hapiMsg = p.parse(msg);

//Es realitza un “downcasting” al tipus de missatge

ADT_A01 adtMsg = (ADT_A01)hapiMsg;

//Es recupera un camp del missatge

PN patientName = adtMsg.getPID().getPatientName();

-Crear missatges HL7 a partir d’ objectes Java del tipus del missatge i assignar els valors desitjats als atributs del objecte que es corresponen amb cadascun dels camps del missatge HL7. Els missatges es poden crear tant en ER7 com en XML.

//Es crea un nou missatge ADT_A01

ADT_A01 adt = new ADT_A01();

//Es recupera el segment PID

PID pid = adt.getPID();

//S’omplen tres camps del segment PID

pid.getPatientName(0).getFamilyName().getSurname().setValue("Doe");

pid.getPatientName(0).getGivenName().setValue("John");

pid.getPatientIdentifierList(0).getID().setValue("123456");

-Rebre missatges, permet crear un servidor que rebi un o diversos tipus de missatges HL7.Cadascun dels tipus de missatges poden  tenir assignat un tractament diferent.

-Enviar missatges a servidors receptors de missatges HL7.

-Validar missatges, quan es realitza la conversió del missatge a un objecte Java es possible dur a terme també una validació del format del missatge per verificar que es compleixen les especificacions establertes per HL7. Per a una validació més avançada es pot validar contra perfils de conformitat que són restriccions l’estàndard HL7.Alhora de realitzar la validació es pot programar manualment per que corregeixi certs errors en els missatges.

-Llegir un o més missatges Hl7 emmagatzemats en un fitxer de text.

Mirth Connect, la plataforma d’integració open source, utilitza la llibreria HAPI com a base per tractar tots els missatges HL7 dins la plataforma. Aquesta API permet tractar molt més fàcilment als missatges alhora de construir-los, com per exemple en el cas dels segments de repetició com els OBX, els quals es poden crear com a objectes mitjançant la API, i assignar-los a diferents parts del missatge.

HAPI TestPanel

HAPI TestPanel és una eina amb interfície gràfica que actualment es troba en fase “alpha”. Permet principalment editar, enviar,rebre i validar missatges HL7.

Aquesta eina permet realitzar altres tasques com creació de perfils de Grup que són conjunts d’un o més perfils de conformitat, creació de taules de validació o comparació semàntica de dos missatges HL7 per tal de validar si el seu contingut és el mateix encara que l’estructura sigui diferent, ja que únicament es compara el contingut dels camps. Es pot veure un exemple a la següent imatge.

HAPI ens proporciona doncs l’accés a missatges HL7 a nivell d’objecte, amb la qual podrem crear tot tipus d’aplicacions per generar missatges, parsejar-los, transformar-los i validar-los sota l’estàndard HL7.

Llegir en català 

HAPI (HL7 application programming interface) es una API de código abierto para el tratamiento de mensajes HL7 2.X con Java. El proyecto no está afiliado a la organización de HL7 pero cumple las especificaciones. Fue iniciado por la University Health Network.

Las principales funciones de HAPI son las siguientes:

-Extraer la información de los campos del mensaje de una manera más sencilla, mediante un conjunto de clases que permiten convertir los mensajes HL7 en objetos Java que contendrán la información.

//Se recupera el mensaje como un objeto

hapiMsg = p.parse(msg);

//Se realiza un “downcasting” al tipo de mensaje

ADT_A01 adtMsg = (ADT_A01)hapiMsg;

//Se obtiene un campo del mensaje

PN patientName = adtMsg.getPID().getPatientName();

-Crear mensajes HL7 a partir de objetos Java del tipo del mensaje y asignar los valores deseados a los atributos del objeto que se corresponden con cada uno de los campos del mensaje HL7. Los mensajes se pueden crear tanto en ER7 como en XML.

//Se crea un nuevo mensaje ADT_A01

ADT_A01 adt = new ADT_A01();

//Se recupera el segmento PID

PID pid = adt.getPID();

//Se rellenan 3 campos del segmento PID

pid.getPatientName(0).getFamilyName().getSurname().setValue("Doe");

pid.getPatientName(0).getGivenName().setValue("John");

pid.getPatientIdentifierList(0).getID().setValue("123456");

-Recibir mensajes, permite crear un servidor que reciba uno o varios tipos de mensajes HL7.Cada uno de los tipos de mensajes pueden tener asignado un tratamiento diferente.

-Enviar mensajes a servidores receptores de mensajes HL7.

-Validar mensajes, cuando se realiza la conversión del mensaje a un objeto Java es posible llevar a cabo también una validación del formato del mensaje para verificar que se cumplen las especificaciones establecidas por HL7. Para una validación más avanzada se puede validar contra perfiles de conformidad que son restricciones del estándar HL7.La validación se puede programar manualmente por que corrija ciertos errores en los mensajes.

Leer uno o más mensajes Hl7 almacenados en un fichero de texto.

Mirth Connect, plataforma de integración open source, utiliza la librería HAPI como base para tratar todos los mensajes HL7 dentro de la plataforma. Esta API permite tratar mucho más fácilmente los mensajes en el momento de construirlos, como por ejemplo en el caso de los segmentos de repetición OBX, los cuales se pueden crear como objetos mediante la API, y asignarlos a diferentes partes del mensaje.

HAPI TestPanel

HAPI TestPanel es una herramienta con interfaz gráfica que actualmente se encuentra en fase “alpha”. Permite principalmente editar, enviar,recibir y validar mensajes HL7.

Esta herramienta permite realizar otras tareas como creación de perfiles de Grupo que son conjuntos de uno o más perfiles de conformidad, creación de tablas de validación o comparación semántica de dos mensajes HL7 para validar si su contenido es el mismo aunque la estructura sea diferente, puesto que únicamente se compara el contenido de los campos. Se puede ver un ejemplo a la siguiente imagen.

HAPI nos proporciona pues el acceso a mensajes HL7 a nivel de objeto, con la cual podremos crear todo tipo de aplicaciones para generar mensajes, parsear-los, transformarlos y validarlos bajo el estandard HL7.

IHE i els perfils d’integració

Leer en castellano

Desde el CCI-TCM hem realitzat una sèrie de  documents per tal de definir com implementar diferents aspectes relacionats amb imatge medica com poden ser: La distribució, la presentació o el contingut. Per tal de complir allò que defineix l’ Integrating the Healthcare Enterprise .

Integrating the Healthcare Enterprise , que abreugem com IHE i que podria traduir-se com Integrant les Empreses Sanitàries, és una iniciativa de professionals de la sanitat (incloent col·legis professionals de metges) i empreses proveïdores, que el seu objectiu és millorar la comunicació entre els sistemes d’informació que s’utilitzen en l’atenció al pacient. IHE defineix uns Perfils d’Integració que utilitzen estàndards d’informació mèdica ja preestablerts per a la integració de sistemes, de manera que proporcionen una interoperabilitat efectiva i un flux de treball eficient. IHE també ens permet aconseguir el nivell d’integració exigible en l’era de la història clínica electrònica.

Un Perfil d’Integració IHE descriu una necessitat clínica d’integració de sistemes i la solució per dur-la a terme. Defineix també els components funcionals, als quals anomenarem Actors IHE, i especifica amb el major grau de detall possible les transaccions que cada Actor haurà de dur a terme, basades sempre en estàndards com el de Digital Imaging and Communication in Medicine (DICOM) i Health Level 7 (HL7).

Els Perfils d’Integració IHE permeten gestionar d’una manera eficaç el conjunt integrat de sistemes d’informació necessari per proporcionar una atenció sanitària optima. La seva alternativa seria el desenvolupament d’interfícies fetes a mesura per a cada instal·lació, la qual cosa resulta més costós i requereix el manteniment d’aquestes interfícies durant tota la vida útil del sistema. La integració a través de IHE és menys costosa des del principi i fa que resulti més fàcil la planificació i inici de futures adquisicions, a més de ser més productiva en proporcionar capacitats valuoses. Els Perfils d’Integració defineixen clarament com han d’encaixar totes les peces basant-se en estàndards acceptats globalment.

Gràcies a l’ús de les tecnologies de la informació, IHE aporta valor afegit en diferents processos de negoci com per exemple:

– Ajuda al personal sanitari a l’hora de millorar la qualitat i eficiència de l’atenció sanitària.

-Augmenta la seguretat del pacient al garantir la integritat de la informació mèdica

-Redueix el temps emprat en la solució de problemes tals com la pèrdua de dades i l’aparició d’estudis no corresponents, optimitzant d’aquesta manera l’aprofitament de temps del personal.

-Proporciona al personal sanitari informació ben estructurada sobre el pacient de manera que la presa de decisions mèdiques estigui basada en la millor informació possible.

IHE com s’ha esmentat abans, defineix diferents perfils basats en diferents necessitats d’integració. Aquests perfils es poden trobar  al seu Web Oficial (http://www.ihe.net/Technical_Framework/index.cfm).

Per exemplificar el que és un perfil presentarem els perfils de radiologia que són una part de la totalitat dels perfils que defineix l’IHE.

Els perfils de radiologia estan classificats segons l’àmbit que defineixen:

Flux de treball

[SWF] Scheduled Workflow

Integra la comanda, programació, adquisició d’imatges, emmagatzemament i visualització dels exàmens de radiologia

En aquest perfil participen els següents actors:

Acquisition Modality, Evidence Creator   , Document Consumer, Document Registry, Document Repository,  Image Display, Image Archive, Image Manager, Imaging Document Source i Imaging Document Consumer

[PDI] Portable Data for Imaging

Proporciona l’ intercanvi fiable de les dades de les imatges i dels informes de diagnòstic a partir de la importació sobre Cd’s, impressió, o opcionalment, per poder-lo visualitzar en un navegador.

En aquest  perfil participen els següents actors:

Portable Media Creator,Portable Media Importer,Image Display,Report Reader,Print Composer,Display

Contingut (Content)

[NM] Nuclear Medicine Image

Especifica la quantitat d’imatges de medicina nuclear i pantalles de resultats que es creen, intercanvien,  s’utilitzen i es mostren.

En aquest  perfil participen els següents actors:

Acquisition Modality, Evidence Creator, Image Archive, Image Display.

[MAMMO] Mammography Image

Especifica la quantitat d’imatges de mamografia i d’objectes de prova que es creen,  intercanvien,  s’utilitzen i es mostren.

En aquest  perfil participen els següents actors:

Acquisition Modality, Evidence Creator, Image Archive, Image Display,Print Composer, Print Server.

Presentació (Presentation)

[KIN] Key Image Note

El Perfil Key image Note permet a un usuari marcar una o més imatges com significants en un estudi, afegint una o més notes gestionades conjuntament amb l’estudi.

Els metges poden adjuntar Key Image Notes a les imatges per diferents motius: accés del metge de capçalera, accés a fitxes pedagògiques, consultes amb altres departaments, problemes amb la qualitat de les imatges…

En aquest  perfil participen els següents actors:

Acquisition Modality,Evidence Creator, Image Display,Image Archive,Image Manager.

[CPI] Consistent Presentation of Images

Manté consistentment la intensitat i la transformació d’imatges entre diferents dispositius de còpia (hard i soft).

En aquest perfil participen els següents actors:

– Image Display i Print Composer.

Infraestructura (Infraestructure)

[ARI] Access to Radiology Information

Comparteix imatges, els informes de diagnòstic i informació relacionada, a l’interior d’una única xarxa. Per a poder donar suport per aquest perfil, l’Image Display o el Report reader hauran de poder consultar i recuperar de múltiples Image Manager/Image Archives o Report Repositories respectivament. També hauran de gestionar els duplicats.

Aplicacions dels perfils IHE

Els perfils IHE s’han implementat amb èxit en diferents centres sanitaris repartits per Europa com:

Health Optimum, Veneto, Italy

Medical Centre Leeuwarden, Friesland, the Netherlands

Johannes Gutenberg University Hospital, Mainz Germany

University Hospital Bordeaux Centre, Bordeaux France

Font: Lizana,M & Domingo,M & Rodriguez,D & Gorriz,M  (2012) IHE.Perfil Radiologia .CCI-TCM

Llegir en català

En el CCI-TCM hemos realizado una serie de documentos para definir como implementar diferentes aspectos relacionados con imagen medica como pueden ser: La distribución, la presentación o el contenido. Para cumplir aquello que define el Integrating the Healthcare Enterprise.

Integrating the Healthcare Enterprise, que abreviamos como IHE y que podría traducirse cómo Integrando las Empresas Sanitarias, es una iniciativa de profesionales de la sanidad (incluiendo colegios profesionales de médicos) y empresas proveedoras, que su objetivo es mejorar la comunicación entre los sistemas de información que se utilizan en la atención al paciente. IHE define unos Perfiles de Integración que utilizan estándares de información médica ya preestablecidos para la integración de sistemas, de forma que proporcionan una interoperabilidad efectiva y un flujo de trabajo eficiente. IHE también nos permite conseguir el nivel de integración exigible en la era de la historia clínica electrónica.

Un Perfil de Integración IHE describe una necesidad clínica de integración de sistemas y la solución para llevarla a cabo. Define también los componentes funcionales, a los cuales denominaremos Actores IHE, y especifica con el mayor grado de detalle posible las transacciones que cada Actor tendrá que llevar a cabo, basadas siempre en estándares como el de Digital Imaging and Communication in Medicine (DICOM) y Health Level 7 (HL7).

Los Perfiles de Integración IHE permiten gestionar de una manera eficaz el conjunto integrado de sistemas de información necesario para proporcionar una atención sanitaria optima. Su alternativa sería el desarrollo de interfaces hechas a medida para cada instalación, lo cual resulta más costoso y requiere el mantenimiento de estas interfaces durante toda la vida útil del sistema. La integración a través de IHE es menos costosa desde el principio y hace que resulte más fácil la planificación e inicio de futuras adquisiciones, además de ser más productiva al proporcionar capacidades valiosas. Los Perfiles de Integración definen claramente como tienen que encajar todas las piezas basándose en estándares aceptados globalmente.

Gracias al uso de las tecnologías de la información, IHE aporta valor añadido en diferentes procesos de negocio como por ejemplo:

– Ayuda al personal sanitario a la hora de mejorar la calidad y eficiencia de la atención sanitaria.

-Aumenta la seguridad del paciente al garantizar la integridad de la información médica

-Reduce el tiempo empleado en la solución de problemas tales como la pérdida de datos y la aparición de estudios no correspondientes, optimizando de este modo el aprovechamiento de tiempo del personal.

-Proporciona al personal sanitario información muy estructurada sobre el paciente, de forma que la toma de decisiones médicas esté basada en la mejor información posible.

IHE cómo se ha mencionado antes, define diferentes perfiles basados en diferentes necesidades de integración. Estos perfiles se pueden encontrar en su Web Oficial (http://www.ihe.net/technical_framework/index.cfm).

Para ejemplificar que es un perfil presentaremos los perfiles de radiología que son una parte de la totalidad de los perfiles que define IHE.

Los perfiles de radiología están clasificados según el ámbito que definen:

Flujo de trabajo(Workflow)

[SWF] Scheduled Workflow

Integra el pedido, programación, adquisición de imágenes, almacenamiento y visualización de los exámenes de radiología

En este perfil participan los siguientes actores:

Acquisition Modality, Evidence Creator , Document Consumer, Document Registry, Document Repository, Image Display, Image Archive, Image Manager, Imaging Document Source y Imaging Document Consumer

[PDI] Portable Data for Imaging

Proporciona el intercambio fiable de los datos de las imágenes y de los informes de diagnóstico a partir de la importación sobre Cd’s, impresión, u opcionalmente, para poderlo visualizar en un navegador.

En este perfil participan los siguientes actores:

Portable Media Creator,Portable Media Importer,Image Display,Report Reader,Print Composer y Display

Contenido (Content)

[NM] Nuclear Medicine Image

Especifica la cantidad de imágenes de medicina nuclear y pantallas de resultados que se crean,se intercambian, se utilizan y se muestran.

En este perfil participan los siguientes actores:

Acquisition Modality, Evidence Creator, Image Archive, Image Display

[MAMMO] Mammography Image

Especifica la cantidad de imágenes de mamografía y de objetos de prueba que se crean, se intercambian, se utilizan y se muestran.

En este perfil participan los siguientes actores:

Acquisition Modality, Evidence Creator, Image Archive, Image Display,Print Composer, Print Server.

Presentación (Presentation):

[KIN] Key Image Note

El Perfil Key image Note permite a un usuario marcar una o más imágenes como significantes en un estudio, añadiendo una o más notas gestionadas conjuntamente con el estudio.

Los médicos pueden adjuntar Key Image Notes a las imágenes por diferentes motivos: acceso del médico de cabecera, acceso a fichas pedagógicas, consultas con otros departamentos, problemas con la calidad de las imágenes…

En este perfil participan los siguientes actores:

Acquisition Modality,Evidence Creator, Image Display,Image Archive,Image Manager.

[CPI] Consistent Presentation of Images

Manté consistentment la intensitat i la transformació d’imatges entre diferents dispositius de còpia (hard i soft).

Mantiene consistentemente la intensidad y la transformación de imágenes entre diferentes dispositivos de copia (hard y soft).

En este perfil participan los siguientes actores:

Image Display y Print Composer.

Infraestructura (Infraestructure)

[ARI] Access to Radiology Information

Compartir imágenes, informes de diagnóstico e información relacionada, en el interior de una única red. Para poder dar soporte a este perfil, el Image Display o el Report reader tendrán que poder consultar y recuperar de múltiples Image Manager/Image Archives o Report Repositories respectivamente. También tendrán que gestionar los duplicados.



Aplicaciones de los perfiles IHE

Los perfiles IHE se han implementado con éxito en diferentes centros sanitarios repartidos por Europa cómo por ejemplo:

Health Optimum, Veneto, Italy

Medical Centre Leeuwarden, Friesland, the Netherlands

Johannes Gutenberg University Hospital, Mainz Germany

University Hospital Bordeaux Centre, Bordeaux France

Fuente: Lizana,M & Domingo,M & Rodriguez,D & Gorriz,M  (2012) IHE.Perfil Radiologia. CCI-TCM