P L A T A F O R M A R C I M - I H C 3

Texto completo

(1)

PLATAFO RMA RCIM - IHC3

PUBLICACIÓ DE LA I MA TGE M ÈDICA A

LA HIST ÒRIA CLÍNI CA COMPART IDA

DE CATAL UNYA

VERSIÓ 1.1

17 de març del 2.011 PIMed - Pla per la Digitalització de la Imatge Mèdica de Catalunya Departament de Salut - Generalitat de Catalunya

(2)

2

1 ÍNDEX DE CONTINGUTS

2 Històric del document ... 3

3 Introducció ... 4

4 Components del Repositori Central d'Imatge Mèdica ... 5

4.1 Backup d'imatge (Bi) ... 5

4.2 Índex d'imatge mèdica (iHC3) ... 5

4.3 Plataformes avançades (PAi) ... 5

4.4 Connectivitat amb el Repositori Central d'Imatge Mèdica ... 5

5 Sistemes que intervenen en la publicació ... 7

5.1 PACS ... 7 5.2 RIS/HIS ... 7 5.3 BACKUP IMATGES ... 7 5.4 iHC3 ... 7 5.5 HCCC ... 7 5.6 Visor d'HCCC ... 8 5.7 Visor d’Imatge ... 8 6 Funcionament ... 9

6.1 Copiar imatges al Backup ... 10

6.2 Registrar estudi a iHC3 ... 10

6.3 Publicar estudi a HCCC ... 11

6.4 Consultar estudi des d'HCCC ... 13

7 Transaccions ... 14

7.1 Còpia de fitxers ... 14

7.2 Registre d'estudis ... 14

7.2.1 IAN ... 15

7.2.2 Servei Web ... 16

7.3 Missatgeria d'integració amb HCCC ... 20

8 Casos d’us ... 21

8.1 Esquemes ... 22

8.1.1 Publicar un estudi a HCCC ... 23

8.1.2 Modificar (afegir o treure) imatges a un estudi registrat o publicat ... 24

8.1.3 Esborrar estudi publicat a HCCC ... 25

(3)

2 HISTÒRIC DEL DOCUMENT

Data Punt de

menú Raó del canvi Autor

24/01/2011 Tots Creació Tomàs Salas

(4)

4

3 INTRODUCCIÓ

L'objectiu últim del Pla per la Digitalització de la Imatge Mèdica a Catalunya és que, un cop digitalitzada, aquesta imatge es pugui compartir a través de la Història Clínica compartida de Catalunya (HC3).

L'AIAQS del Departament de Salut ha desplegat una infraestructura centralitzada d’arxiu d’imatge mèdica, el Repositori Central d'Imatge Mèdica (RCIM), que permet als centres disposar d’una còpia segura de les seves imatges mèdiques i compartir-les amb la resta de centres a través de la Història Clínica compartida de Catalunya.

Aquest document descriu els components que formen el RCIM, els serveis que proporciona, i les funcionalitats que els Sistemes d’Informació (HIS, RIS i PACS) dels centres han d’implementar tal que es pugui accedit a les seves imatges a través d’HCCC.

El següent esquema és una representació gràfica dels components de RCIM i dels serveis que proporciona.

(5)

4 COMPONENTS DEL REPOSITORI CENTRAL D'IMATGE MÈDICA

4.1 BACKUP D'IMATGE (BI)

És un sistema d'emmagatzemament NAS que actua com a extensió del sistema de fitxers del PACS de cada centre permetent-los disposar d'una còpia segura de les seves imatges. Aquest sistema està configurat en alta disponibilitat (24x7x365), i és accesible de forma online pel PACS del centre.

Cada centre disposarà de l'espai en disc que necessiti per les imatges generades des de la data de la posada en marxa (per l’històric caldrà tractar-ho cas a cas). La única condició per accedir-hi és el compromís de compartir aquestes imatges amb la resta de centres a través de la Història Clínica Compartida de Catalunya.

4.2 ÍNDEX D'IMATGE MÈDICA (IHC3)

Registra la informació necessària per classificar i accedir a les imatges. Inclou les interfícies necessàries (serveis web o IAN de DICOM) per actualitzar-lo i mantenir-lo sincronitzat amb els PACS dels centres.

4.3 PLATAFORMES AVANÇADES (PAI)

La infrastructura de RCIM es podrà aprofitar en el futur per posar en funcionament plataformes avançades d'imatge, com poden ser xarxes de professionals, serveis de telemedicina i teleassistència, o eines centralitzades de suport al diagnòstic (CAD).

4.4 CONNECTIVITAT AMB EL REPOSITORI CENTRAL D'IMATGE MEDICA

La infraestructura física de RCIM està dissenyada per treballlar en format multi-site. La situació actual, distribuida en varis CPDs, es resumeix a la següent taula:

Servei Ubicació Característiques

Magatzems

d'imatges Orange - L'Hospitalet de Ll. (Polígon Pedrosa) 64 TB nets Magatzems

d'imatges Departament de Salut - Pavelló Olímpia 64 TB nets Magatzems

d'imatges CTTI - L'Hospitalet de Ll. (Polígon Pedrosa) 300 TB nets iHC3 Departament de Salut - Pavelló

(6)

6

La connexió amb RCIM per tal d'actualitzar informació es realitza en tots els casos a través de l'Anella TICSALUT. L'ample de banda entre l'Anella TICSALUT i els CPDs RCIM és de al menys 1 Gbps. Per consultar aquesta informació es pot accedir, opcionalment, a través d'internet.

Les comunicacions amb RCIM es fan de forma segura per tal de garantir l'autenticitat, integritat i confidencialitat de les dades.

Per sol·licitar l’accés a RCIM per part d’un centre que proveeixi imatge mèdica, cal que es donin les següents condicions:

1. Haver signat amb el Departament de Salut el Conveni per Història Clínica Compartida. 2. Compromís per part del centre de publicar les imatges a Història Clínica Compartida. 3. Disposar d’accés a l’anella TicSalut (antic Nus Sanitari).

(7)

5 SISTEMES QUE INTERVENEN EN LA PUBLICACIÓ

5.1 PACS

Els PACS dels centres mantenen la sincronització entre les imatges arxivades localment i la còpia emmagatzemada al backup que s'utilitza per consultar a través de la Història Clínica Compartida de Catalunya. Per tal de mantenir aquesta sincronització els PACS dels centres han d'implementar les següents 2 transaccions:

 Còpia segura de les imatges al sistema de backup.

 Registre de les imatges a iHC3. Mitjançant la crida a un WebService o el servei IAN de DICOM, s’envia la informació dels estudis copiats, així com de la seva estructura i localització a RCIM (path).

5.2 RIS/HIS

El RIS/HIS del centre manté la sincronització entre els estudis disponibles a través de l'estació clínica local i els que es poden consultar a través de la Història Clínica Compartida de Catalunya. Per tal de mantenir aquesta sincronització, entre RIS/HIS i HCCC, el centre ha d'implementar la missatgeria d'integració amb Història Clínica Compartida de Catalunya.

5.3 BACKUP IMATGES

És un sistema d'emmagatzemament NAS que actua com a extensió del sistema de fitxers dels PACS dels centres i els hi permet disposar d'una còpia segura de les seves imatges. D’aquesta manera, si el sistema principal d’arxiu del centre falla, es pot continuar donant servei automàticament des d’aquest arxiu amb la pèrdua de rendiment derivada de l’amplada de banda entre el centre i l’RCIM.

El sistema garanteix que les imatges copiades no es poden modificar i que l'accés a les mateixes per la resta de centres només es pot realitzar a través de la Història Clínica Compartida a Catalunya.

Cada centre disposarà de l'espai en disc que necessiti, i la única condició per accedir-hi és el compromís de compartir aquestes imatges amb la resta de centres a través de la Història Clínica Compartida de Catalunya.

Actualment no es realitza còpia de seguretat d'aquest sistema i, per tant, els centres han de disposar al menys d'una còpia de les imatges als seus CPDs.

5.4 IHC3

iHC3 és el sistema índex d'imatges. Gestiona el contingut dels estudis, la seva localització al backup, i l'equivalència entre l'identificador original de l'estudi (identificador al PACS del centre), i l'identificador del mateix a Història Clínica Compartida a Catalunya.

Tanmateix proporciona les interfícies necessàries per tal d'actualitzar (serveis web i DICOM-IAN) i consultar aquesta informació (visor i serveis web).

(8)

8

Història Clínica Compartida de Catalunya és el sistema que permet compartir la informació clínica dels ciutadans entre les diferents Entitats Proveïdores de Salut. HCCC manté l'índex de documents disponibles per ser consultats, i proporciona les interfícies necessàries (visor i serveis web) per tal d'actualitzar i consultar aquesta informació.

Els centres tenen l'opció d'enviar al repositori d'HCCC una còpia dels documents que volen compartir, o proporcionar un enllaç al seu arxiu local de documents.

5.6 VISOR D'HCCC

El visor d'HCCC és la interfície d'usuari que permet als professionals consultar la informació clínica dels seus pacients generada per altres Entitas Proveïdores.

En el cas de la imatge mèdica, aquest visor permet consultar quins estudis d'imatge existeixen per un pacient determinat, i mostrar el seu contingut mitjançant el SW de visualització d'imatge mèdica d'HCCC (RAIM java).

5.7 VISOR D’IMATGE

El RAIM Java, de la UDIAT Centre Diagnòstic, és el programari de visualització d'imatge mèdica que fa servir la HCCC. És un programari dissenyat per distribuir la imatge a metges no especialistes en diagnòstic per la imatge, que permet la seva visualització i manipulació en format DICOM, però que no incorpora les eines de diagnòstic avançades dels programaris que fan servir els especialistes.

Tecnològicament, RAIM java és un applet java que es descarrega en la màquina de l'usuari, accedeix a les imatges emmagatzemades al sistema de backup del RCIM, i les mostra al professional.

La qualitat de les imatges descarregades està en funció de la qualitat de les línies de comunicacions de les que disposa el centre des del que es fa la consulta. Si aquestes proporcionen un ample de banda suficient, la imatge es descarrega sense pèrdua d'informació, si no és així la imatge es comprimeix per tal de permetre que es pugui visualitzar en un temps raonable.

(9)

6 FUNCIONAMENT

El procés de compartició de les imatges a la HCCC consta de 3 parts ben diferenciades:

1. Còpia (COPY) de les imatges als servidors Bi. Ho fa el PACS. Les imatges encara no estan visibles a HCCC.

2. Registre (REG) de les imatges copiades al servidor iHC3. Ho fa el PACS. Les imatges encara no estan publicades a HCCC. Existeix també el missatge de cancel.lar un registre si encara no ha estat publicat (REG(0)).

3. Publicació (ADC) de les imatges registrades a la HCCC. Ho fa el RIS/HIS. Fins que no es fa aquest pas, les imatges no estaran publicades a HCCC. D’aquesta manera se li dóna la responsbilitat al RIS/HIS del centre del moment exacte de la visibilitat de les imatges fora del centre. El centre pot escollir el moment de la publicació en funció dels processos interns: immediatament, un cop es signi l’informe, depenent del tipus d’informe i la urgència, ... Existeix també el missatge de cancel.lar una publicació (DCD)

El Sistema PACS és l’encarregat de copiar i registrar les imatges, mentre que el sistema HIS/RIS és l’encarregat de la publicació.

El sistema PACS és qui ha de garantir, de la mateixa manera que ho fa als sistemes de cada centre, quines imatges pertanyen a un estudi concret (agafant l’AccessionNumber o el StudyInstanceUID com a identificador clau). El sistema RIS/HIS és qui ha de garantir la pertinença d’un estudi a un ciutadà (CIP). Aquest aspecte és clau en la comprensió del funcionament d’aquesta plataforma, sobretot en els processos de reconciliació d’estudis.

A la plataforma iHC3, la parella AccessionNumber i Centre (AN+C) és l’identificador únic d’estudi. D’aquesta manera, es pot treballar amb els mateixos AN que els centres tenen als seus PACS. Un estudi a iHC3 (AN+C) té 3 estats possibles:

1. No existeix: O bé la parella AN+C no existeix o bé ha estat eliminada ja sigui des del PACS (REG(0)) o desde HCCC (DCD).

2. Registrat: La parella AN+C existeix però no està publicada mitjançant la missatgeria REG. 3. Publicat: La parella AN+C existeix i està publicada mitjançant la misatgeria ACD.

El següent diagrama mostra el fluxe d’estats:

REG (0)

REG REG

REG ACD

DCD

(10)

10 Els processos es detallen en els següents capítols:

6.1 COPIAR IMATGES AL BACKUP

PACS HIS/RIS BACK

UP iHC3 HCCC Visor HCCC

1 El PACS del centre copia les imatges al backup

1.1 Estableix una connexió segura amb el sistema de backup i copia les imatges a un recurs compartit de xarxa amb accés restringit per usuari i

password

1.2 El sistema de backup autentica al PACS del centre i autoritza l'escriptura al recurs compartit

6.2 REGISTRAR ESTUDI A IHC3

PACS HIS/RIS BACK

UP iHC3 HCCC Visor HCCC

2 El PACS del centre registre a iHC3 les imatges que prèviament ha copiat al backup 2.1a El PACS del centre

consumeix un WebService que li permet informar a iHC3 dels estudis copiats al backup (identificador d'estudi, sèries, imatges, etc.) i de la seva

localització 2.1b El PACS del centre ,

mitjançant el servei IAN de DICOM informa a iHC3 dels estudis copiats al backup (identificador d'estudi, sèries, imatges, etc.) i de la seva localització 2.2 iHC3 valida el missatge rebut del centre i actualitza la informació de l'estudi a la seva base de dades.

(11)

Si l'estudi havia estat prèviament registrat, la informació anterior s'anul·la i es substitueix per la última rebuda. Això permet afegir o treure imatges d'un estudi, incloent deixar com registrat un estudi sense cap imatge.

6.3 PUBLICAR ESTUDI A HCCC

PACS HIS/RIS BACK

UP iHC3 HCCC Visor HCCC 3 El HIS del centre publica a HCCC els estudis prèviament copiats al backup i registrats a iHC3 3.1 El HIS/RIS del centre consumeix

(12)

12

un WebService que li permet informar a HCCC dels estudis disponibles per ser compartits a través d'aquest sistema.

3.2 HCCC valida el

missatge rebut pel centre i assigna a l'estudi

l'identificador que s'utilitzarà per consultar-lo a través del seu visor

3.3 HCCC envia a iHC3

la parella identificador de l'estudi del centre i identificador de l'estudi a HCCC

3.4 iHC3 comprova que

l'estudi està registrat i actualitza la seva BD amb l'equivalència entre identificadors de l'estudi (identificador al PACS del centre i identificador d'HCCC).

(13)

6.4 CONSULTAR ESTUDI DES D'HCCC

PACS HIS/RIS BACKUP iHC3 HCCC Visor HCCC

4 El visor d'HCCC sol·licita la visualització d'un estudi 4.1 Petició a HCCC 4.2 Petició a iHC3 4.3 Retorna JNLP a HCCC 4.4 Retorna JNLP al visor HCCC

4.5 Carrega RAIM java

4.6 Demana l’estudi per https

directament a iHC3 4.7 Valida Petició

4.8 Retorna informació amb ubicació de les imatges

4.9 Demana les imatges per

https directament als Bi 4.10 Valida la petició 4.11 Retorna la imatge 4.12 Visualitza la imatge

(14)

14

7 TRANSACCIONS

7.1 CÒPIA DE FITXERS

El model de Backup de Imatge Mèdica es basa en la còpia de les imatges a un recurs compartit (NAS) a través d'IPSEC, un protocol segur sobre IP (Internet Protocol) aplicat sobre la capa 3 del model OSI. L'autenticació es realitza mitjançant certificació digital d’aplicació (PACS) i de servidor (Backup d'Imatges, Bi).

L'espai de disc del que els centres disposen al backup està configurat com un recurs compartit de xarxa, al que s'hi accedeix mitjançant usuari i password, de tal manera que el PACS pot desar imatges a la carpeta de backup com si es trobés en el seu propi sistema de fitxers local.

Aquest model és independent de proveïdor PACS i permet l’accés instantani a la imatge en cas de fallida del sistema local de fitxers.

Els servidors de backup estan muntats sobre servidors Microsoft Windows, i publiquen els seus sistemes de fitxers a través del protocol NETBios sobre TCP/IP (NetBT). En cas de PACS que treballin sobre altres sistemes operatius que no operin amb NetBT de forma nativa, caldrà implantar aquest protocol (per exemple, en el cas de UNIX, s’implantarà un servei SAMBA per accedir-hi).

S'han de tenir en compte les següents restriccions quan l'enviament de les imatges al Backup i la seva gestió posterior:

1. Les imatges s’enviaran al RCIM en format DICOM preferentment amb compressió lossless 2. Les imatges s’enviaran preferentment anonimitzades

3. Les imatges enviades al backup no es podran esborrar o modificar, ni tampoc no es podrà modificar la seva capçalera DICOM.

4. Es poden afegir imatges addicionals a un estudi ja existent al RCIM 5. El PACS de cada centre tindrà accés només a les seves imatges

6. Els centres podran accedir a la resta de les imatges només a través de la plataforma d'Història Compartida de Catalunya (HCCC) i, per tant, amb les garanties de seguretat i confidencialitat de les dades que aquesta plataforma ofereix.

7.2 REGISTRE D'ESTUDIS

Registrar un estudi consisteix en comunicar a RCIM quines imatges s'han copiat i la seva localització. Per tal d'implementar aquest missatgeria, els Centres disposen de 2 possibilitats:

 Implementar el servei IAN de DICOM

 Implementar un Web Service que rep un string d'entrada amb la informació de l'estudi a registrar.

La connexió es realitza mitjançant el protocol https i es fan servir Certificats Digitals d'Aplicació y de Servidor en els dos extrems de la comunicació.

Aquesta interfície permet:

(15)

 Modificar l'estructura d'un estudi a l'índex (afegir o treure sèries i imatges)

 Esborrar un estudi de l'índex (esborrat lògic, l'estudi amb tota la seva informació continuarà estant a l'índex però no serà accesible)

Un resum de la informació bàsica que es comunica és el següent:

 Identificador de l'estudi al PACS local, habitualment l'ACCESSION NUMBER

 Codi de centre a la plataforma Història Clínica Compartida de Catalunya (HCCC), per tal d’assegurar la no coincidència d'identificadors d'estudi entre centres, RCIM fa servir la combinació Codi de Centre + Accession Number.

 Estructura de l'estudi, s'ha de proporcionar tota la informació DICOM per tal d'agrupar les imatges en el seu estudi (UIDs d'estudi, sèrie i instàncies, SOP class de cada sèrie)

 Ubicació de les imatges (path a RCIM)

Existeixen 2 mecanismes per tal de registrar un estudi a RCIM.

7.2.1 IAN

El sistema índex de documents permet registrar tant la disponibilitat d’un nou estudi, com la no disponibilitat d’un estudi registrat amb anterioritat.

En els 2 casos, el PACS del centre, actuant com a SCU, crearà una instància de la SOP Class Instance Availability Notification (SOP Class UID "1.2.840.10008.5.1.4.33").

El sistema d’índex d’Història Cínica compartida necessita conèixer la ubicació dels fitxers copiats a l’arxiu d’imatge. Per comunicar aquesta informació s'utilitzaran els següents tags:

Attribute

Name Tag Attribute Description

>>Retrieve

Location UID (0040,E011) Unique identifier of the system where the Composite Object(s) may be retrieved on the network. >>Retrieve URI (0040,E010) Retrieval access path to the referenced SOP instance(s). Includes fully specified scheme, authority, path, and query in accordance with RFC 2396

La disponibilitat de l’estudi s’informarà en el tag Instance Availability, amb les restriccions que es defineixen a la taula següent.

Attribute Name Tag Restriccions

>>Instance

Availability (0008,0056)   “ONLINE”, alta d’un nou estudi “UNAVAILABLE”, baixa d’un estudi registrat anteriorment

Aquesta instància s’enviarà a iHC3, que disposarà dels components de SW necessaris per actuar com a SCP, processar-la i efectuar el registre de l’estudi al sistema d’índex d'imatges de RCOM (iHC3).

(16)

16

La informació necessària per tal d'implementar aquest servei es troba a la documentació de l'estàndard DICOM, i especificament a:

DICOM 2009 PS 3.4: Instance Availability Notification Service Class DICOM Correction Item, CP-1029, de 21 de juny de 2010, text definiu

7.2.2 SERVEI WEB

Alternativament, existeix un sistema de registre d’estudis mitjançant serveis web. A la següent taula es mostren els paràmetres d’entrada i sortida del mateix.

NOM Registry (xmlIn: String)

ACCIÓ Registrar a l’índex d’IHC3 un estudi emmagatzemat al sistema d’imatge. DESCRIPCIÓ

TÈCNICA Aquesta operació és un Web Service que rep un string que conté un xml amb els paràmetres d’entrada i retorna un string amb un xml amb la resposta del resultat de la crida. Permet:

 Afegir a l'índex nous estudis amb les seves imatges

 Afegir o treure imatges associades a un estudi prèviament registrat

 Eliminar un estudi que ha estat registrat però encara no publicat (enviant zero imatges) PRE

CONDICIONS Totes les imatges referenciades han d’haver estat copiades a disc prèviament. iHC3 comprobarà que els fitxers existeixen al disc, però no que siguin objectes DICOM. POST

CONDICIONS L’estudi està indexat a la BD del sistema d’iHC3 amb les imatges del xml (entenent que si s’envien zero imatges, s’està donant de baixa l’estudi) ENTRADA General:

<?xml version="1.1" encoding="utf-8"?>

<REGISTRY xmlns="http://server.com/" VERSION="1.1">

<STUDY STUDYDATETIME="Data de l’estudi" IDCENTER="Identificador del centre per HCCC" AE_TITLE="XXX" IDSTUDYCENTER="AccessionNumber"

STUDYINSTANCEUID="XXX">

<SERIE SERIESDATETIME="XXX" SERIESINSTANCEUID="XXX" MODALITY="XXX" > <INSTANCE SOPCLASSUID="XXX" NUMBEROFFRAMES="XXX"

INSTANCEDATETIME="XXX" PATHHD="XXX" SOPINSTANCEUID="XXX" /> …

<INSTANCE SOPCLASSUID="XXX" NUMBEROFFRAMES="XXX"

INSTANCEDATETIME="XXX" PATHHD="XXX" SOPINSTANCEUID="XXX" /> </SERIE>

<SERIE SERIESDATETIME="XXX" SERIESINSTANCEUID="XXX" MODALITY="XXX" > … </SERIE> </STUDY> </REGISTRY> Esborrar estudi: <?xml version="1.1" encoding="utf-8"?>

< REGISTRY xmlns="http://server.com/" VERSION="1.1">

<STUDY IDCENTER="Identificador del centre per HCCC" AE_TITLE="XXX" IDSTUDYCENTER="Identificador de l’estudi al centre (id local)"

STUDYINSTANCEUID="XXX"> </STUDY>

</REGISTRY>

Exemple general:

<?xml version="1.1" encoding="utf-8"?>

< REGISTRY xmlns="http://udiat.com/" VERSION=”1.1”><STUDY STUDYDATETIME="17/03/2011 13:31:35" IDCENTER="H17001484"

(17)

AE_TITLE="AET_H17001484" IDSTUDYCENTER="3030003601774000" STUDYINSTANCEUID="1.2.826.0.1.3680043.2.403.87.1110317132624460.1.12355200761 4"><SERIE SERIESDATETIME="17/03/2011 13:31:42" SERIESINSTANCEUID="1.3.46.670589.30.1.3.1.1625114806.1300365403833.1" MODALITY="CR"><INSTANCE SOPCLASSUID="1.2.840.10008.5.1.4.1.1.104.2" NUMBEROFFRAMES="1" INSTANCEDATETIME="17/03/2011 13:31:46" PATHHD="\\10.10.10.10\Folder001\20110317.6\20110215.133157.321.66390.MODAL0 01" SOPINSTANCEUID="1.3.46.670589.30.1.3.1.16321321.775843.3"/></SERIE></STUDY></ REGISTRY >

Exemple esborrar estudi:

<?xml version="1.1" encoding="utf-8"?>

< REGISTRY xmlns="http://udiat.com/" VERSION=”1.1”><STUDY IDCENTER="H17001484" AE_TITLE="AET_H17001484" IDSTUDYCENTER="3030003601774000"

STUDYINSTANCEUID="1.2.826.0.1.3680043.2.403.87.1110317132624460.1.12355200761 4"></STUDY></ REGISTRY >

SORTIDA <Result xmlns="http://server.com/"> <Status>[OK/ERROR]</Status> <Details>

<Event Type="[Error/Warning/Info]" Code="[000-->999]" Name="[Títol]" Cause="[Descripció de l’event]" Action="[Recomanacions]"/>

<Event Type.../> ...

<RequestKeyValues [Llistat camps clau de la petició] ProcessKey=”[Id del procés que ha tractat la petició]” />

</Details> </Result> Exemple:

<?xml version="1.0" encoding="utf-8"?><Result

xmlns=""><Status>OK</Status><Details><Event Type="Info" Code="0" Name="Procés finalitzat" Cause="El procés s'ha executat correctament." /></Details><RequestKey ProcessKey="BFRb823907adef344a081382e696c76e0b5" /></Result>

Els principals resultats d’aquest registre són:  Si AN=0 o el Centre és erroni -> ERROR

 Si AN+C no existeix -> l’estudi es crea i passa a registrat.

 Si AN+C està registrat o publicat -> Es canvien totes les imatges antigues per les noves  Si és REG (0) i l’estudi està registrat però no publicat -> l’estudi passa a no existent

 Si és REG (0) i l’estudi està publicat -> ERROR (si està publicat, només es pot donar de baixa via HCCC).

(18)

18 Si Hi ha més imatges? No No Inserim la sèrie IdSerie Es crea un estudi nou No idStudy Actualitzem Containers Existeix la serie? Sinó la Inserim. idSerie Inserim l’instància Esborrem l’estudi (delete=1, idhc3=””) Idstudyhccc

Tractem les imatges del XML

Existeix study (AN + Center)

Es crea un estudi nou heretant isdtudyhc3 IdStudy Existeix path? Si Si No V alidem center + PACS Alta No Validem XML Error Delete Si Esborrem l’estudi (delete=1) Missatge d’Error Resposta XML L’estudi està publish? No Si

(19)

El llistat d’errors que pot donar aquesta missatgeria és el que es mostra a la següent taula:

CODI NAME CAUSE ACTION

100 Error genèric del

sistema d'arxius Error genèric del sistema d'arxius.

101 No existeix fitxer No s'ha pogut trobar el fitxer. Revisar que el fitxer existeix al directori. 102 No existeix el directori No s'ha localitzat el directori indicat. Revisar la ruta proporcionada.

104 No s'ha trobat l'arxiu La instància s'ha esborrat de l'índex, però l'arxiu DCM no s'ha trobat.

200 Error genèric XML No s'ha pogut carregar o llegir l'XML. Comprovar que el fitxer té el format correcte.

201 Validació XML S'ha detectat que el format del XML

reportat no és correcte. Comprovar mitjançant la plantilla XSD el format del XML. 202 Validació XML S'ha detectat que el format del XML

reportat no és correcte. Comprovar mitjançant la plantilla XSD el format del XML. 203 Validació XML Problema recuperant les dades d'un

atribut. Comprovar que els atributs de l'element estiguin correctament introduïts. 204 Validació XML El format de la data no és correcte. Revisar el format de la data.

207 Validació XML El namespace del XML d'entrada no és

correcte o no te cap valor. Comprovar que l’atribut xmlns existeix i té el valor correcte. 208 Validació XML L'atribut INSTANCEDATETIME de

l'element STUDY està buit. Inserir l’atribut. 209 Validació XML L'atribut IDCENTER de l'element STUDY

està buit. Inserir l’atribut. 210 Validació XML L'atribut AE_TITLE de l'element STUDY

està buit. Inserir l’atribut. 211 Validació XML L'atribut IDSTUDYCENTER de l'element

STUDY està buit. Inserir l’atribut. 212 Validació XML L'atribut STUDYINSTANCEUID de

l'element STUDY està buit. Inserir l’atribut. 213 Validació XML L'atribut SERIESDATETIME d'un element

SERIE està buit. Inserir l’atribut. 214 Validació XML L'atribut SOPINSTANCEUID d'un element

INSTANCE està buit. Inserir l’atribut. 215 Validació XML L'atribut SERIESINSTANCEUID d'un

element SERIE està buit. Inserir l’atribut. 216 Validació XML L'atribut INSTANCEDATETIME d'un

element INSTANCE està buit. Inserir l’atribut. 218 Validació XML L'atribut PATHHD d'un element

INSTANCE està buit. Inserir l’atribut. 226 Validació XML L'atribut IDCENTER de l'element STUDY

no està declarat. Assignar el valor corresponent a l'atribut IDCENTER. 300 Error genèric en

comprovació de dades Error genèric en comprovació de dades. 301 Invàlid IdCenter L'IdCenter i/o AE_TITLE reportat no es

troba donat d'alta a l'aplicació. Revisar els IdCenter i AE_TITLE informats als estudis. 302 Invàlid IdSOPClass L'IdSOPClass reportat no es troba donat

d'alta a l'aplicació. Revisar els IdSOPClass informats a les instàncies. 303 Invàlid IdCompression L'IdCompression reportat no es troba

donat d'alta a l'aplicació. Revisar els IdCompressions informats a les instàncies. 304 Invàlid PATHHD L'atribut PATHHD de l'element instance

reportat no es troba donat d'alta a l'aplicació.

Revisar els PATHHD informats a les instàncies.

305 Invalid Path relatiu El path relatiu del container passat al XML

no existeix. Revisar que l'atribut RelativePath dins de l'element Instance sigui correcte. 400 Error genèric de la

Plataforma Error genèric de la Plataforma. Contactar amb l'administrador d’iHC3. 405 Valors incorrectes El valor d'algun dels atributs no és vàlid. Modificar la petició validant-la amb la

plantilla XSD.

500 Error de Seguretat S'ha produït un error de seguretat. Verificar els permisos disposats. 501 Error de permisos No s'ha pogut accedir per no disposar de

permisos. Revisar els permisos de connexió de l'usuari. 502 Path no accessible No s'ha pogut accedir a la imatge. Revisar els permisos d'usuari per

(20)

20

carpeta contenidora. 503 Server busy El servidor no disponible

sobrecàrrega temporal o per manteniment.

Tornar a enviar el missatge al cap d’uns minuts.

505 No s'ha trobat l'arxiu

de claus No s'ha trobat l'arxiu de claus. Revisar el nom de l'arxiu especificat. 701 Càlcul SR Error en generar el SR de la instància. Revisar els paràmetres de la imatge. 702 Càlcul KIN Error en generar el KIN de la instància. Revisar els paràmetres de la imatge. Altre Altre Error intern Contactar amb l'administrador d’iHC3.

7.3 MISSATGERIA D'INTEGRACIÓ AMB HCCC

La missatgeria d'integració actualitza l'índex de documents d'HCCC amb la informació de l'estudi i, si és necessari, ho associa amb un o més d'un informes existents en aquest índex. Aquesta missatgeria, mitjançant serveis web, permet:

 Publicar un estudi

 Anul·lar la publicació realitzada d'un estudi

 Relacionar estudis amb informes, aquesta relació pot ser n a m, i permet per tant qualsevol combinació informes – estudis que es pugui donar en la pràctica clínica

Tota la informació necessària per implementar la connexió amb HCCC es pot trobar als següents documents:

 Història Clínica Compartida a Catalunya. Guia d'implementació d'Imatge Digital

 Història Clínica Compartida a Catalunya. Requisits per la integració i publicació de dades en la plataforma HCCC per les Institucions Assistencials: Document Tècnic

(21)

8 CASOS D’US

La següent taula mostra els casos d’us més habituals, fent èmfasi en els casos on s’han d’arreglar estudis:

Cas d’ús Trigger Esqu

ema Successió d’events Descripció

Publicació d’un

estudi El HIS/RIS/PACS decideixen que un estudi és publicable

1 Copy REG ACD

L’estudi queda registrat a la HCCC i es pot visualitzar des del seu visor.

Esborrar un estudi registrat però no publicat

Quan el PACS vol esborrar

un estudi no publicat REG (0) Esborra l’estudi del registre de iHC3. Esborrar un

estudi ja publicat

El HIS, decideix eliminar (temporalment o definitiva) un estudi.

3 DCD Esborra l’estudi dels indexos de HCCC i de iHC3.

Afegir imatges a un estudi publicat o registrat

Quan el PACS rep imatges adicionals a un estudi ja registrat o publicat 2 Copy REG S’afegeixen imatges a un AN de iHC3.

No cal tornar a publicar l’estudi. No cal que el PACS notifiqui res al HIS/RIS.

Treure imatges a un estudi publicat o registrat

Quan el PACS rep ordre d’eliminar alguna imatge d’un estudi ja registrat o publicat

2 REG Es treuen imatges a un AN de iHC3.

No cal tornar a publicar l’estudi. No cal que el PACS notifiqui res al HIS/RIS.

Conciliació d’estudis entre HIS/RIS/PACS

Quan es produeix una conciliació d’estudis entre el HIS/RIS/PACS 3 i 1 Per cada estudi: DCD REG ACD

Quan alguns estudis canvien d’AN, caldrà cancel.lar tots els estudis afectats, fer el REG per cada un (no cal tornar a copiar-los) i publicar-los tots altra vegada.

Cal que el PACS i el HIS/RIS estiguin molt ben sincronitzats per assegurar estrictament aquest ordre.

Split d’un estudi

publicat Quan el PACS rep l’ordre de dividir un estudi en dos estudis (siguin o no del mateix pacient) DCD (estudi) REG (Estudi1) REG (Estudi2) ACD (Estudi1) ACD (Estudi2)

Quan s’han barrejat imatges de dos estudis diferents en un de sol.

Canvi

demogràfics El HIS registra un canvi de demogràfics del pacient Res Res No cal fer res a iHC3, perquè l’iHC3 no té ni CIP ni dades demogràfiques de pacient (li passa sempre la HCCC). L’acció només s’haurà de fer a HCCC. Fusió de

pacients El HIS registra una fusió de pacients Res Res No cal fer res a iHC3, perquè l’iHC3 no té ni CIP ni dades demogràfiques de pacient (li passa sempre la HCCC). L’acció només s’haurà de fer a HCCC.

(22)

22

Divisió d’una Història Clínica

El HIS divideix una Història Clínica en dues

Res Res Si no canvia l’AN dels estudis* (és l’habitual), no cal fer res a iHC3 perquè l’iHC3 no té ni CIP ni dades demogràfiques de pacient (li passa sempre la HCCC). L’acció només s’haurà de fer a HCCC.

* Si canvia l’AN, caldrà fer un DCD, REG i ACD.

Copy: Còpia de les imatges als Bi

REG: Registry (missatge del PACs al iHC3). REG (0) indica el REG amb zero imatges ACD: AddClinicalDocument (missatge del HIS a la HCCC)

DCD: DeleteClinicalDocument (missatge del HIS a la HCCC)

Per assegurar la integritat de les dades, cal que el PACS i el HIS/RIS estiguin molt ben sincronitzats i seguir estrictament l’odre de la missatgeria proposada.

Per veure com funciona exactament la obertura d’un estudi i quins actors intervenen, afegim també l’esquema 7, Obertura d’un estudi publicat en HCCC, amb RaïmJava no instal·lat.

A continuació es presenta la missatgeria existent en cada cas. El que no s’inclou és la missatgeria existent entre PACS i HIS, donat que pot diferir en cada cas.

(23)

Pàgina 23

8.1.1 PUBLICAR UN ESTUDI A HCCC

PACS HIS / RIS Servidor Backup (Bi) iHC3 HCCC

Pot ser que el propi PACS sigui el que arrenqui el procés, al tenir un nou estudi

Comprova que existeix

HCCC assigna id HC3 al document HCCC passa el id HC3 del

document i el accession number a iHC3 per que registri la relació

AddClinicalDocument

Es destaquen els tres punts principals de la interacció de l’entitat proveidora amb el sistema:

BACKUP REGISTRE

Estudi publicable (accession number, centre)

En aquest punt, el HIS pot esperar per asegurar:

 que l’estudi ja no rep més imatges

 les directives del centre sobre temps d’espera de publicació

*

Aquestes tasques es repeteixen per cada nova sèrie d’imatges a registrar, indicant totes les imatges en cada registre. Només es farà backup d’aquells arxius dels que no s’ha fet backup abans.

REGISTRE

: mètode Registry (accession number, centre, arxius)

BACKUP

(còpia dels fitxers NOUS al servidor) Registrar

Estudi

(24)

Pàgina 24

8.1.2 MODIFICAR (AFEGIR O TREURE) IMATGES A UN ESTUDI REGISTRAT O PUBLICAT

En cas que, un cop estigui registrat per part del PACS al iHC3, el PACS rebi noves imatges en un estudi, o be es modifiqui per l’estudi per eliminar imatges, ha de tornar a registrar-ho sense que això afecti a la publicació per part de la plataforma de publicació, fent la còpia de les imatges noves si n’hi ha, i tornant a demanar el seu registre. En l’exemple mostrem el cas d’us en que arriben noves imatges i s’han d’eliminar algunes.

PACS HIS / RIS Servidor Backup (Bi) iHC3

Nova imatge per estudi

Comprova que existeix

*

Aquestes tasques es repeteixen per cada nova sèrie d’imatges a registrar. Si cal treure imatges, simplement no s’inclouen en el XML. Només es farà backup d’aquells arxius dels que no s’ha fet backup abans.

REGISTRE

: mètode Registry (accession number, centre, arxius)

BACKUP

(còpia dels fitxers NOUS al servidor)

En aquest moment, al PACS li arriben modificacions, noves imatges per afegir a l’estudi i imatges per treure

No importa si el la plataforma de publicacio ja ha publicat, si publicarà després, o si publica mentre es produeix aquesta operació, la plataforma de publicació no intervé per res.

(25)

8.1.3 ESBORRAR ESTUDI PUBLICAT A HCCC

HIS / RIS HCCC

DeleteClinicalDocument (id HC3 de l’estudi)

iHC3

HCCC dóna de baixa lógica l’estudi, marcant-lo com esborrat, i demana a iHC3 que sincronitzi també aquest fet.

Mètode deleteClinicalDocument (id HC3 de l’estudi)

iHC3 fa la baixa lógica de l’estudi, marcant-lo com esborrat.

(26)

Pàgina 26

8.1.4 APERTURA D’UN ESTUDI PUBLICAT A HCCC.

Aquest circuit es mostra només a nivell informatiu, donat que l’entitat, apart d’assegurar que l’estació de treball disposa de la darrera versió de la màquina virtual de java, no te cap altre responsabilitat.

Estació de treball (navegador /

visor HCCC) HCCC iHC3 Servidor Backup (Bi)

Clic Imatge

Obrir imatge

.jnlp

iHC3 retorna un arxiu jnlp per obrir la imatge.

.jnlp

OpenClinicalDocument

Es descarrega i s’instal·la en l’estació de treball el RaimJava. El jnlp porta la información de com fer-ho.

Descarregar RaimJava

RaimJava demana a iHC3 les dades de l’estudi, Params.

RaimJava mostra les imatges a mida que arriben al visor.

LocalitzarEstudi Params

Per cada imatge, RaimJava la demana al ImageGate del servidor de Backup corresponent. Obté imatge Arxiu DCM

*

RaimJava en estació de treball

RaimJava s’inicia asíncronament

rutes

ImageGate valida, “crema” la petició perque valgui un sol cop, i retorna les rutes

Figure

Actualización...

Referencias

Actualización...

Related subjects :