Disseny i implementació d’una eina per particularitzar...

Projecte final de carrera Enginyeria Tècnica en Informàtica de Gestió

Disseny i implementació

d’una eina per particularitzar ontologies

d’actors

Sergio Martínez Lluís Ester Morales Grau

Directors de projecte Montserrat Batet Sanromà (URV) Aïda Valls Mateu (URV) Karina Gibert Oliveras (UPC) Escola Tècnica Superior d’Enginyeria (ETSE) Universitat Rovira i Virgili (URV) Curs 2007-2008

Disseny i implementació d’una eina per particularitzar ontologies d’actors

2

Índex de continguts 1 Introducció sobre el projecte .................................................................................. 5

1.1 Motivació i objectius del projecte .................................................................... 6 1.2 Planificació i divisió de les tasques a realitzar ............................................... 7 1.3 Estructura del document ................................................................................. 7

2 Home Care i projecte K4CARE............................................................................... 9 2.1 Què és Home Care? ......................................................................................... 9 2.2 Introducció i objectius del projecte K4CARE............................................... 10 2.3 Introducció al model K4CARE ..................................................................... 11 2.4 Model K4CARE ............................................................................................. 12

2.4.1 Home Care Nuclear Structure (HCNS)............................................... 13 2.4.2 Home Care Accessory Service – Rehabilitation (HCAS-R)................. 19

2.5 Implementació de K4CARE .......................................................................... 22 2.5.1 Plataforma del K4CARE ....................................................................... 23 2.5.2 Capa de Coneixement (Knowledge Layer) ........................................... 24 2.5.3 Data Abstraction Layer ........................................................................ 25

3 Ontologies .............................................................................................................. 26 3.1 Què són les ontologies? ................................................................................. 26 3.2 Classificació de les ontologies ....................................................................... 26 3.3 Components de les ontologies ....................................................................... 27 3.4 Llenguatge OWL i Jena per accedir al OWL ............................................... 27 3.5 Eina Protégé .................................................................................................. 28

4 L’ontologia de Perfils d’Actors (APO).................................................................. 30 4.1 Definició de la APO ....................................................................................... 30 4.2 Perfil dels continguts de la APO .................................................................. 30

5 Particularització de la APO (Tailoring) ............................................................... 33 5.1 El manegament de fitxers OWL .................................................................... 33 5.2 Tailoring de Care Units ................................................................................. 34

5.2.1 Creació de la SubAPO ........................................................................... 36 5.2.2 Modificacions fetes sobre el codi previ ................................................. 37 5.2.3 Pseudocodi en alt nivell del Tailoring of Care Units ........................... 37

5.3 Tailoring d’Entitats ....................................................................................... 39 5.3.1 Creació de la SubAPO ........................................................................... 42 5.3.2 Pseudocodi en alt nivell de Automatic Tailoring of Actor ................... 42

5.4 Personalització............................................................................................... 44 5.4.1 Personalització de Documents .............................................................. 45 5.4.2 Personalització d’Accions ..................................................................... 46 5.4.3 Validació ............................................................................................... 48

6 ATAPO (Automatic Tailoring of the APO) .......................................................... 49 6.1 Descripció de l’eina ATAPO ......................................................................... 49 6.2 Funcionalitats de l’eina ATAPO .................................................................. 50

6.2.1 Creació de les SubAPOs ........................................................................ 50 6.2.2 Visualització de les SubAPOs................................................................ 51 6.2.3 Personalització de documents ............................................................... 52 6.2.4 Personalització d’accions ...................................................................... 53 6.2.5 Validació de les SubAPOs ..................................................................... 54

6.3 Manual d’usuari per a l’eina ATAPO .......................................................... 57 7 Joc de proves .......................................................................................................... 65 8 Conclusions i valoració ........................................................................................ 71


3

9 Treball futur........................................................................................................... 73 10 Referències ......................................................................................................... 74 11 Annexos.............................................................................................................. 75

Índex de figures Figura 1. Arquitectura del model K4CARE per HC ..................................................... 13 Figura 2. Actors de HCNS ............................................................................................ 14 Figura 3. Actors de HCAS-R ........................................................................................ 20 Figura 4. Estructura del model K4CARE...................................................................... 23 Figura 5. Plataforma K4CARE ..................................................................................... 24 Figura 6. Pantalla principal de Protégé.......................................................................... 29 Figura 7. Arquitectura de la APO.................................................................................. 32 Figura 8. Protégé - APO ................................................................................................ 35 Figura 9. Protégé – Nurse_APO.................................................................................... 36 Figura 10. Estructura de la SubAPO de l’actor Family Doctor..................................... 41 Figura 11. Protégé – SubAPO de Nurse........................................................................ 41 Figura 12. ATAPO – Validació d’usuaris ..................................................................... 49 Figura 13. ATAPO – Creació de SubAPOs .................................................................. 51 Figura 14. ATAPO – Visualitzador de SubAPOs ......................................................... 52 Figura 15. ATAPO – Personalització de documents..................................................... 53 Figura 16. ATAPO - Personalització d’accions ............................................................ 54 Figura 17. ATAPO – Validació de SubAPOs ............................................................... 55 Figura 18. ATAPO – Validació de SubAPOs ............................................................... 55 Figura 19. ATAPO – Validació d’usuaris ..................................................................... 57 Figura 20. ATAPO - Creació de SubAPOs................................................................... 57 Figura 21. ATAPO – Selecció d’Actor/Care Unit......................................................... 58 Figura 22. ATAPO – Procés de creació ........................................................................ 59 Figura 23. ATAPO – Visualitzador de SubAPOs ......................................................... 59 Figura 24. ATAPO – Visualitzador de propietats/restriccions...................................... 60 Figura 25. ATAPO – Personalització d’accions............................................................ 60 Figura 26. ATAPO – Personalització de documents..................................................... 61 Figura 27. ATAPO – Validació de SubAPOs ............................................................... 62 Figura 28. ATAPO – Validació de SubAPOs (documents) .......................................... 63 Figura 29. ATAPO – Validació de SubAPOs (accions) ............................................... 64 Figura 30. ATAPO – Mostra de SubAPOs ................................................................... 65 Figura 31. Protégé – SubAPO de la Nurse .................................................................... 66 Figura 32. ATAPO – Edició de Documents.................................................................. 66 Figura 33. Protégé – Propietats de la Nurse .................................................................. 67 Figura 34. ATAPO – Inversa de la propietat................................................................. 68 Figura 35. ATAPO – Validació de SubAPOs ............................................................... 68 Figura 36. ATAPO – Validació de documents.............................................................. 69 Figura 37. Protégé – Documents de la Nurse................................................................ 69 Figura 38. Protégé – Propietats dels Documents........................................................... 70


4

Índex de taules Taula 1. Agrupació d’accions de HCNS ........................................................................ 16 Taula 2. Llista d’accions del pacient de HCNS ............................................................. 17 Taula 3. Serveis de HCNS .............................................................................................. 18 Taula 4. Access Services en Rehabilitació .................................................................... 21 Taula 5. Patient Care Rehabilitative Services ............................................................... 22 Taula 6. Propietat i propietat inversa segons el tipus de document. ............................. 46 Taula 7. Propietat i propietat inversa segons el tipus d’acció. ..................................... 47


5

1 Introducció sobre el projecte

K4CARE [1] és un projecte finançat per la Comissió Europea destinada al

desenvolupament d’una plataforma web intel·ligent per a proporcionar e-services a professionals mèdics, pacients i ciutadans que formen part de Home Care (HC) de pacients ancians que viuen a casa.

Aquests serveis pretenen millorar les funcionalitats de la nova societat de la UE per dirigir i respondre a les necessitats del gran volum de població sènior, els quals requereixen una assistència mèdica personalitzada.

A eHealth és cada vegada més necessari el desenvolupament d’aplicacions teleinformàtiques per a ajudar a la plantilla que treballa en l’assistència mèdica (metges, infermeres, pacients, familiars i ciutadans en general). La cura de pacients amb malalties cròniques i pacients discapacitats comporta tractaments de llarga durada i sota una supervisió continuada per part dels experts. A més a més, els assistents mèdics i els pacients accepten que estar als hospitals i residències pot ser innecessari i contraproduent. Des d’un punt de vista global, aquests pacients poden arribar a saturar la xarxa mèdica i incrementar els costos relacionats amb la salut.

El debat sobre la crisi del finançament d’assistència mèdica està obert i és un tema únicament polític per als països de la UE.

El projecte K4CARE integra un conjunt d’informació, tècniques, experiències i

experteses dels centres especialitzats i professionals dels països de la UE, i els incorpora en una plataforma web intel·ligent per a proveir als professionals, pacients i ciutadans en general de e-services.

Una de les tasques més importants en la creació del sistema K4CARE és la definició del model de dades que representarà el coneixement de la plataforma K4CARE. Aquestes dades es representen utilitzant un Actor Profile Ontology (APO), un patient-Case Profile Ontology (CPO) i els Formal Intervention Plans (FIPs).

L’objectiu principal de la APO[2][3] és emmagatzemar informació sobre els actors que formen part del model de K4CARE, els serveis corresponents i com es realitzen. La CPO emmagatzema informació sobre els símptomes, malalties, medicació, procediments quirúrgics, etc. Els FIPs [4]contenen informació sobre com s’ha de dur a terme el HC utilitzant una pràctica basada en pautes d’evidència.

En aquest projecte, l’esforç recau en la creació de SubAPOs a partir de la APO

inicial, que emmagatzemaran la informació únicament necessària per la entitat de la qual s’hagi d’obtenir l’ontologia. Per a obtenir la informació necessària, el PFC s’objectiva en la creació d’una eina anomenada ATAPO, la funció de la qual és el Tailoring de la APO.

Aquesta incorpora funcionalitats bàsiques de la particularització del model i fa que la seva utilització sigui més familiar, ja que el personal usuari que futurament utilitzarà aquesta tècnica és personal no informàtic.

La necessitat de Tailoring, definit com el procés d’obtenir una vista particular de

la APO, es deu a la necessitat de personalitzar els actors. D’aquesta manera, cada actor podrà veure la seva pròpia informació a la que li està permès accedir i també modificar.

Degut al marge legal que la sanitat acompanya, aquesta personalització ha de ser verificada o validada per personal a càrrec de la plantilla mèdica. És per aquest motiu que ATAPO incorpora una funció tan important com és la validació de SubAPOs.


6

1.1 Motivació i objectius del projecte

L’objectiu principal ha estat implementar la creació de SubAPOs a partir de la

APO en el cas particular dintre del projecte K4CARE. Dintre d’aquest objectiu la primera tasca ha estat la comprovació de la possibilitat de crear aquesta vista particular de l’ontologia general. Degut a la possible creació, s’ha continuat amb el següent procés i objectius:

Una SubAPO és una vista particular per una Entitat o Care Unit que contingui els

documents, accions, serveis i procediments als quals tingui accés la Entitat o Care Unit concreta, segregant aquests de la APO general.

Aquest objectiu principal requereix de prerequisits per a la seva obtenció. El principal prerequisit és estudiar i comprendre l’estructura de les ontologies en general i de la APO del projecte K4CARE.

Una vegada assolit l’objectiu principal de creació de SubAPOs per Entitats i Care

Unit, sorgeixen nous objectius: permetre personalitzacions de les SubAPOs per actor, és a dir, la vista particular que un Actor obté de la APO general ha de poder ser personalitzat, afegint o eliminant elements que un Actor concret necessiti afegir o eliminar en relació amb el seu treball i tasques real dins l’assistència mèdica.

L’altre objectiu que apareix en la personalització és la necessitat de revisar

validacions sobre les personalitzacions ja que, per exemple, els documents que un actor desitgi afegir a la seva SubAPO estan legalment emparats sota lleis de privadesa mèdica. Aquest fet fa que sigui necessari un sistema d’acceptacions per part del cap de la unitat corresponent.

Tots aquests punts requereixen el disseny i implementació d’una eina que

incorpori aquestes funcionalitats per facilitar l’ús als usuaris. En resum, els principals objectius del PFC han estat els següents:

- Estudiar l’estructura de les ontologies i en particular la APO del model K4CARE.

- Estudiar les possibilitats i implementar la creació de SubAPOs per actor i

comprendre la creació de SubAPOs per Care Unit.

- Estudiar les possibilitats i implementar la personalització de SubAPOs per actor.

- Estudiar les possibilitats i implementar la validació de personalitzacions.

- Estudiar les possibilitats i implementar una eina gràfica per a l’usuari que integri totes aquestes funcionalitats.

- Preparar i redactar documentació referida a tots aquests punts per la seva

publicació dins el projecte K4CARE.


7

1.2 Planificació i divisió de les tasques a realitzar

Degut a la composició de dos estudiants en aquest PFC, el treball ha hagut de ser

repartit, tot i que bona part s’ha realitzat conjuntament i en treball en equip. Aquelles parts realitzades conjuntament són:

- Estudi de l’estructura de les ontologies i de la APO del model K4CARE. - Creació de SubAPOs per Actor. Definició del procés de Tailoring per a les

entitats existents a la APO. - Documentació i publicacions per al projecte K4CARE.

Tasques fetes individualment:

- La personalització de SubAPOs és realitzada per Sergio Martínez Lluís. - La validació de personalitzacions és realitzada per Ester Morales Grau.

1.3 Estructura del document

Els continguts d’aquest document estan estructurats de la següent manera: 2. Descripció dels termes generals necessaris per a desenvolupar el projecte, com són el terme Home Care i el projecte K4CARE. Aquest PFC forma part d’aquest últim projecte i per tant és molt important el seu coneixement. Aquest projecte inclou un model detallat que descriu els actors, serveis, documents, accions i procediments que prenen part al Home Care. 3. Aquesta secció està dedicada a l’explicació del concepte Ontologia, els tipus d’ontologies i els elements de les ontologies. Per a desenvolupar aquest treball, s’ha hagut d’extreure la informació de Actor Profile Ontology, i per tant, els continguts de les ontologies són necessaris. També s’inclou una introducció al llenguatge OWL amb el que s’implementen les ontologies. 4. En aquest punt es fa una definició detallada de l’ontologia utilitzada per a fer el Tailoring de SubAPOs, la APO (Actor Profile Ontology). Se’n inclou la seva arquitectura juntament amb els elements de què està composta. 5. Aquest capítol tracta la particularització de la APO, és a dir, de l’anomenat procés de Tailoring. Inclou una explicació sobre com una SubAPO d’una Care Unit o una SubAPO d’un Actor són generats a partir de la APO. Els passos realitzats per a crear-la es detallen i també un algoritme en pseudocodi. Seguidament s’exposa la personalització de SubAPOs, concretament les d’Actor. 6. Conté tot allò relacionat amb l’eina creada al projecte: ATAPO, juntament amb totes les funcionalitats que aquesta incorpora: creació de SubAPOs tant per Actor com per Care Unit, mostrar SubAPOs creades anteriorment, personalització de SubAPOs, i finalment, validació de SubAPOs que han sigut personalitzades. A més a més, inclou un capítol amb un manual d’usuari per a l’eina ATAPO.


8

7. Joc de proves de l’eina ATAPO amb els possibles processos a realitzar, tot testant totes les funcionalitats que aquesta incorpora. Per finalitzar, els capítols 8 i 9 contenen les conclusions, valoració i treball futur. El capítol 10 conté les referències bibliogràfiques i enllaços relacionats amb el projecte i l’11 conté una llista dels annexos que s’adjunten en un altre document.


9

2 Home Care i projecte K4CARE

2.1 Què és Home Care?

Home Care, també conegut com atenció sanitària a domicili, és la provisió d’atenció mèdica a l’habitatge del pacient que ho necessita per part dels professionals mèdics o per la família i amics (anomenats també caregivers, primary caregiver, o voluntary caregivers que donen unes atencions sanitàries informals).

L’atenció mèdica domiciliària està destinada a aquells pacients amb malalties

mentals o físiques que tornen de l’hospital o residències especials i que han estat assistits professionalment amb la necessitat de recursos formals per a la salut i suport social. Principalment, aquells pacients qui són dependents i necessiten serveis intensius i sofisticats. Normalment no hi ha límits d’edat per a fer ús de l’atenció sanitària a domicili, tot i que tendeix a ser més utilitzat amb l’augment de l’edat. Algunes definicions només consideren que l’atenció mèdica domiciliària és la provisió d’assistència a persones amb edat per sobre dels 16 anys a casa seva, llavors a vegades es considera l’edat.

Home Care té tres funcions principals:

- Substituir serveis més costosos com els hospitals. - Substituir les cures per facilitats a llarg termini. - Proporcionar funcions que permetin al pacient continuar a casa seva sense

moure’s a una nova residència normalment més costosa.

Hi ha dos fluxos d’entrada al Home Care: - Serveis professionals, incloent infermeria, treballadors socials, terapeutes i

serveis de suport per a l’habitatge. - Una gran extensió de programes i serveis addicionals, incloent programes de dia

per adults (hospitals geriàtrics de dia), programes d’alimentació, equipament mèdic i consultoria.

Home Care es centra en l’assessorament del client, la família i l’entorn en general.

S’encarrega de coordinar el suport social i els serveis que els clients necessiten, vivint a la comunitat i els assegura la provisió d’una atenció continuada conforme a les seves necessitats canviants.

A [5] es presenten les principals motivacions del Home Care. La idea d’evitar la

mobilitat dels pacients no és nova. El Home Care ja ha estat practicat en diferents graus a alguns països d’Europa en l’últim segle, essencialment per organitzacions voluntàries.

L’augment del Home Care a Europa no és una decisió voluntària, ja que hi ha vàries raons que el fan necessari. La principal motivació del Home Care és millorar la qualitat de vida del pacient, creient que la infermeria a casa ajuda al pacient a conservar la seva dignitat i vida social. L’estat d’ànim del pacient no només augmenta degut al seu augment de salut psicològica, sinó que també augmenta pel seu estat físic. El temps de recuperació disminueix.

Una altra motivació pel Home Care és la de reduir la despesa econòmica que l’atenció mèdica als pacients implica per a les institucions. L’augment de persones de la


10

tercera edat amb malalties cròniques fa que s’allargui el temps d’atenció mèdica als pacients.

2.2 Introducció i objectius del projecte K4CARE

El projecte Europeu K4CARE (Knowledge – Based HomeCare eServices for an

Ageing Europe) es basa en un model de Home Care (HC), on s’hi engloben els serveis d’assistència que es donen a un pacient que necessita assistència a casa. Es considera que el pacient típic de Home Care (HCP) és un pacient adult, malalt i amb poca mobilitat, incapacitats físiques i cognitives, pèrdues funcionals per múltiples invalideses i necessitat de dependència.

El tractament del HCP és complex degut al nombre creixent de pacients en aquestes circumstàncies, i també perquè es necessiten un gran nombre de recursos per a garantir una assistència a llarg termini.

L’objectiu principal de K4CARE és aplicar un model efectiu adreçat als països europeus i en el context de les recomanacions de la Unió Europea. Aquest model que cal aplicar és referit com el model de K4CARE. L’objectiu té una implicació social directa d’ajuda a la gent parcialment, temporalment o totalment dependent perquè visqui en el seu entorn el màxim de temps possible, i fer una diferenciació clara amb l’ús de la institucionalització. Des del punt de vista mèdic i administratiu, es vol definir un model que sigui una referència Europea per al tractament de HCPs d’una forma efectiva i eficient.

El model de K4CARE [1] es basa en la definició d’uns actors (metges, assistents

socials, infermeres, professionals de la rehabilitació, HCPs, familiars, assistents informals (informal care givers), ciutadans, organismes socials, etc.), els seus papers i la seva interacció.

La interacció entre metges professionals, informàtics i centres tecnològics són bàsics per a definir aquest model, on s’hi identifiquen alguns aspectes crítics i es resolen els serveis d’atenció sanitària del model del K4CARE.

Un altre component important d’aquest projecte és el disseny d’una plataforma informàtica basada en les telecomunicacions que suporti el model mèdic d’assistència domiciliària J4CARE. Aquesta plataforma ha de permetre que els diferents tipus d’usuaris puguin proporcionar els serveis mèdics definits en el model, en qualsevol lloc i en qualsevol moment, amb accés a les dades mèdiques del pacient. Aquesta plataforma també ajudarà a tasques administratives de coordinació dels equips mèdics que interactuen en la cura d’un pacient.

Els principals objectius del projecte K4CARE es divideixen en Objectius

Generals, Objectius Científics i Objectius Tecnològics: Objectius Generals:

O1. Generar un nou Model Sanitari (model de K4CARE)per donar assistència sanitària als HCPs a Europa. O2. Proposar una plataforma basada en el coneixement (plataforma del K4CARE) que implementi el model anterior. Aquesta plataforma contindrà totes les tecnologies desenvolupades al projecte.


11

O3. La plataforma es provarà primer a les societats d’est i oest de la UE per detectar les principals diferències i aconseguir un model homogeni. O4. Alguns països començaran a usar aquest model per demostrar que aquest coneixement entre els diferents països de la Unió Europea, no només és possible sinó que també beneficial i necessari per aconseguir un servei de HC standard Europeu suportat amb les últimes tecnologies.

Objectius Científics: O5. Integrar diferents tipus de dades (per exemple: text, valors numèrics, elements multimèdia) i documents provinents de diferents fonts (per exemple: serveis hospitalaris, laboratoris, consultoris, especialistes, familiars i pacients a casa). O6. Integrar informació provinent de diferents països membres de la UE. O7. Definir una Actor Profile Ontology (APO) per a representar els perfils que interactuen al model de K4CARE. O8. Definir patient-Case Profile Ontologies (CPO) per a representar símptomes, malalties, síndromes, etc. O9. Definir Formal Intervention Plans (FIP) per als tractaments de les malalties i síndromes.

Objectius Tecnològics:

O10. Personalitzar l’accés a la plataforma del K4CARE. Adaptar les APOs als requeriments dels usuaris, ja que no tots els pacients necessiten l’assistència sanitària de la mateixa forma. Els mètodes de personalització desenvolupats s’aplicaran a les ontologies de care-givers per donar a veure que no tots els professionals interactuen al sistema de la mateixa manera. O11. Personalitzar l’assistència de ciutadans sèniors. Les CPOs no són vàlides fins el moment en que es personalitzar el HCP que el fa diferent dels altres tractaments. O12. Els FIPs s’obtindran a partir de noves tècniques d’aprenentatge. S’obtenen a partir de l’estudi dels pacients anteriors emmagatzemats al sistema. O13. Dissenyar i implementar agents intel·ligents que permetin adaptar i editar les ontologies i introduir nous FIPs. Combinar aquests agents amb un sistema multi-agent amb e-services als caregivers, pacients i ciutadans. O14. Desenvolupar una aplicació integrada a la plataforma del K4CARE per a localitzar pacients topogràficament.

2.3 Introducció al model K4CARE

Tal com s’ha dit, s’ha definit un model mèdic de HC anomenat model K4CARE [1] que dóna una descripció concreta del model que es necessita. Aquest model ha estat elaborat per un conjunt d’experts mèdics. La proposta inclou la manera de dur a terme l’assistència mèdica als pacients malalts, incapacitats o crònics en una societat tecnològica en la UE. Per a la definició d’aquest standard ha estat necessari un esforç considerable per part de la plantilla mèdica, ja que s’havia de formalitzar el comportament d’un sistema de HomeCare de la forma més precisa i estructurada


12

possible. La proposta dels experts estableix quins són els actors que prenen part al sistema i quines són les tasques en les que prenen part.

El document de definició del model K4CARE ha estat el punt de partida per a la

formalització del coneixement mèdic en un sistema informàtic. Aquest coneixement s’ha representat mitjançant una estructura de coneixement anomenada ontologia.

Aquest document contenia especificacions mèdiques que precisaven una

formalització a nivell d’enginyeria, ja que hi havia certa informació necessària en el model formal i que no hi constava.

En l’Enginyeria del Coneixement, la formalització de dominis complexes és una tasca difícil, principalment per l’existència de coneixement implícit, que rarament s’expressa en la primera especificació de l’expert. L’Enginyeria del Coneixement ajuda a refinar i validar formalment el model mèdic en termes de correcció des d’un punt de vista lògic. En aquest pas, és necessària una forta interacció entre els experts i els enginyers del coneixement. Es van identificar redundàncies no trivials, inconsistències i una certa falta d’informació per a completar l’especificació.

Així doncs, l’ontologia es va organitzar i construir conjuntament amb els experts

mèdics del projecte . Aquesta ontologia s’anomena APO: Actor Profile Ontology [2]. La seva arquitectura interna va ser dissenyada per a ser prou flexible per a suportar addicions de Care Units.

Actualment, s’està implementant un primer prototipus de la plataforma del

K4CARE i alguns tests estan en funcionament. La APO fa un paper crucial en l’arquitectura global del sistema, ja que defineix les tasques que un actor pot realitzar dins l’estructura organitzativa del sistema sanitari domiciliari. A més a més, la APO defineix els permisos, les interaccions entre les diferents persones que prenen part a l’assistència del pacient.

2.4 Model K4CARE

Als països europeus, i a les diferents àrees dels mateixos països, HC s’estructura de formes diferents, depenent de les lleis locals de cada lloc. Els diferents prototipus reflecteixen variades aproximacions al HC, particularment referides als serveis que s’ofereixen, els recursos humans i les dependències. El model K4CARE proposa un paradigma fàcil i adoptable en qualsevol dels països de la UE, d’adoptar un model eficient de HC.

El model proposa que els serveis de K4CARE siguin distribuïts per equips locals i integrats amb els serveis socials, amb altres organitzacions eventuals d’atenció mèdica o de suport social. El seu objectiu és proveir els pacients de les necessitats sanitàries i el suport social per a ser tractat a casa.

Degut a que l’objectiu del model es proposa com un estàndard europeu, el projecte

K4CARE recomana una estructura modular que pot ser adaptada a diferents oportunitats i necessitats locals. L’èxit d’aquest model està directament relacionat amb els nivells d’eficàcia, eficiència i millor pràctica dels serveis de cures que el model suporta.


13

Figura 1. Arquitectura del model K4CARE per HC Tal i com mostra la Figura 1, el model es basa en una estructura nuclear (HCNS)

que comprèn el nombre mínim d’elements necessaris per a proporcionar un servei HC bàsic. Els HCNS poden variar amb un nombre opcional de serveis accessoris (HCAS) que poden ser afegits modularrment a l’estructura nuclear. Aquests serveis serveixen per a cures especialitzades, necessitats especials, oportunitats, mètodes, etc.

La diferència entre un HCNS i els complementaris HCASs s’ha d’interpretar com una manera d’introducció a la flexibilitat i l’adaptació del model de K4CARE i també com un intent de donar suggeriments a estàndards per a ser utilitzats amb la projecció i la realització de nous serveis en diferents contextos.

Aquest punt dóna una descripció detallada tant del HCNS com dels HCASs, anomenats Rehabilitation Unit (Unitat de Rehabilitació).

En detall, cadascuna de les estructures dels HCs (per exemple HCNS i HCAS) consisteix dels mateixos components: actors, documents, serveis, procediments i accions. Els Actors són totes les figures humanes incloses a l’estructura del HC.

Quan s’afegeixen nous HCASs al model, nous actors, accions, serveis, procediments i informacions entren a formar part de l’extensió del model. D’aquesta manera, el model és compatible amb la situació actual dels països europeus on les lleis internacionals, nacionals i locals defineixen diferents sistemes de HC per als diferents països.

2.4.1 Home Care Nuclear Structure (HCNS)

El Home Care Nuclear Structure del model de HC de K4CARE comprèn els elements mínims per a dur a terme un servei bàsic de HC. Aquests elements són els actors involucrats al HC amb les seves accions, els serveis existents, els procediments i la informació per a proporcionar aquests serveis.


14

2.4.1.1 Actors Hi ha diferents actors que interactuen en el health care: pacients, parents, metges,

assistents socials, infermeres, professionals de la rehabilitació, care givers informals, ciutadans, organismes socials, etc. Al HCNS aquests individus són membres de tres grups d’actors de HC que aquesta secció descriu. Aquests grups són el pacient; els stable members (membres estables) de HCNS (el family doctor, el physician in charge of HC, la head nurse, la nurse, el social worker, cadascun d’ells presents al HCNS); i els additional care givers. El family doctor, el physician in charge of HC, la head nurse i el social worker formen una estructura temporal – la Evaluation Unit – necessària per assessorar les necessitats i els problemes del pacient. La Figura 2 mostra el pacient al centre del HCNS del model de K4CARE, i el resta de grups organitzats al voltant és un símbol d’un model de HC per a un pacient.

Figura 2. Actors de HCNS

Pacient (HCP) El típic pacient és de la tercera edat, amb condicions i malalties de mobilitat, cognitives i/o físiques, pèrdues funcionals amb discapacitats i dependents.

Stable Members

Family Doctor (FD) El Metge de Família és l’encarregat del pacient. FD diagnostica i tracta les malalties, desordres psicològics i lesions dels pacients. Dóna un contacte primari i atenció mèdica continuada i dirigeix de la salut dels pacients. Physician in Charge of the HC (PC)


15

El Metge Encarregat del HC és un supervisor de la Evaluation Unit i el responsable mèdic del servei de HC. En alguns països o àrees, aquesta tasca li correspon al FD. Head Nurse (HN) La Cap de les Infermeres principalment coordina el treball de les infermeres per a dur a terme el pla d’intervenció. Social Worker (SW) El Treballador Social identifica i avalua les necessitats socials, dirigeix la implicació social del pla d’intervenció i posa en funcionament els serveis socials, és l’instructor de la xarxa de care givers del pacient. Nurse (Nu) La Infermera s’encarrega de les tasques terapèutiques. La Nu treballa a casa del pacient en funció de l’accés especulat. Dóna l’atenció mèdica d’infermeria necessàries i es pot també especialitzar en cures especials. En aquests casos pot formar part de HCAS.

Evaluation Unit (EU)

La Unitat d’Avaluació està composta pel FD, PC, HN i SW (Figura 2). La EU es un equip de professionals en HC que assessoren els problemes, defineixen un pla d’intervenció individual (IIP), identifiquen els procediments adequats, avaluen els resultats i verifiquen l’èxit del IIP. La EU selecciona un professional per a cobrir el paper de Case Management (CM), que serà aquell qui s’encarregui del IIP (normalment la HN). La EU és un equip temporal i només actua durant la primera assignació del pacient (HCP) i per a les reavaluacions.

Additional Care Giver (ACG)

Altres grups de professionals i actors no professionals solen formar part del HC. La seva presència és gairebé omnipresent, fins al punt que poden arribar a formar part de l’estructura del HC (per exemple: Stable Members). En principi, els Specialist Physicians no estan directament dintre del servei de HC; els Social Sanitary Operators treballen normalment per municipis locals; els Continuous Care Provider pot ser, en casos diferents, un familiar o una tercera persona la qual obté un salari; el Informal Care Giver pot ser part de l’organització de ciutadans o bé un simple veí. Aquests grups de Additional Care Givers no tenen una posició exacta dintre del context de la xarxa del HC, però el seu paper resulta, en molts casos, essencial per a l’atenció continuada del HCP. Al model de K4CARE, s’anomenen “addicionals” ja que són actors que treballen per a completar les competències i les intervencions dels HCNS. La seva presència individual en un HCNS particular és opcional.

a) Specialist Physician (SP). El metge especialitzat és un doctor especialitzat en una branca de medicina. Un especialista en medicina clínica diagnostica i tracta malalties i desordres i actua com un consultor per als altres metges. Els especialistes en cirurgia s’encarreguen i revisen els procediments quirúrgics. El SP pot donar una gran gamma de serveis d’especialització; en aquests casos el


16

SP pot formar part d’un HCAS. Al HCNS, els especialistes més habituals són els geriàtrics, cardiòlegs, cirurgians, neuròlegs i uròlegs.

b) Social Operator (SO). L’Operador Social normalment treballa per municipis locals, o el contracta una companyia privada. El SO representa una branca operativa per a donar suport a necessitats socials del HCP directament a casa.

c) Continuous Care Provider (CCP). L’Assistent Continuat és l’actor que està a càrrec de l’assistència continuada del HCP, normalment les 24 hores del dia. El CCP pot ser, en casos diferents, un familiar o una tercera persona amb un salari.

d) Informal Care Giver (ICG). L’Assistent Informal és una persona que proveeix al HCP de suport rellevant, sense ser un professional o familiar. ICG pot formar part dels ciutadans de l’organització, comunitats religioses, o simplement un veí. L’acció de l’ICG està principalment relacionada amb la preservació de les relacions socials entre el HCP i el seu entorn.

2.4.1.2 Accions i Responsabilitats professionals En aquesta secció s’enumeren les accions generals que cadascun dels actors

realitza al model de K4CARE dintre dels serveis de HCNS. S’ha definit una llista amb totes les accions que es necessiten per realitzar l’assistència bàsica domiciliària (HCNS). Aquestes accions s’agrupen segons la seva tipologia tal com es descriu a la Figura 3:

Taula 1. Agrupació d’accions de HCNS


17

Aquestes accions també es poden estructurar des del punt de vista de l’actor que realitza l’acció, tal com es veu a la Taula 1. A l’Annex 1 s’hi descriuen les llistes d’accions de cada actor per separat.

Taula 2. Llista d’accions del pacient de HCNS

2.4.1.3 Serveis

Les accions no es poden realitzar de forma aïllada, sinó que formen part d’un servei mèdic més complex. Aquests serveis s’han definit dins el model K4CARE [1]. El HCNS ofereix un conjunt de Serveis per a l’atenció mèdica de HC. Aquests serveis es classifiquen en Access services (serveis d’accés), Patient Care services (serveis d’atenció mèdica del pacient) i Information services (serveis d’informació). Els Access services veuen els actors de HCNS com elements del model de K4CARE i s’encarreguen de tasques com donar d’alta al pacient al model de HC o de la seva admissió. Els Patient Care services són els serveis més complexes del model de HC considerant tots els models d’atenció sanitària possibles per als pacients de HCNS. Finalment, els Information services cobreixen les necessitats d’informació dels actors de HCNS requerits al model de K4CARE. A la Taula 2 es mostren les llistes de classificació dels serveis de HCNS.


18

Taula 3. Serveis de HCNS

A l’Annex 2 es defineixen els serveis de HCNS en detall. 2.4.1.4 Documents L’estructura de HCNS defineix un conjunt d’unitats d’informació que cal

emmagatzemar per a que pugin ser consultats posteriorment. Aquest documents poden contenir resultats de proves o de diagnòstics, que formaran part del historial mèdic del pacient, o bé ser documents administratius com autoritzacions de serveis, planificació de tasques, llistes d’espera o bé altres documents mèdics de consulta, com guies de medicaments.

A l’Annex 3 s’expliquen tots els tipus de documents en detall. 2.4.1.5 Procediments Al model de K4CARE, un procediment representa la manera en que les accions

són realitzades i combinades entre els actors per a realitzar un servei. El primer grup de serveis abans descrit, indica com els actors i els grups de treball es creen, formen i destrueixen al model de K4CARE. El segon grup de serveis exposa com els actors interactuen per tal de proporcionar una atenció sanitària eficient. El tercer grup comprèn aquells serveis necessaris per a proporcionar informació.


19

Els procediments donen una especificació més detallada de com s’ha de realitzar cadascun dels serveis. Els procediments permeten estructurar seqüencialment les accions. Això es representa mitjançant diagrames de flux, que ens indiquen els prerequisits entre les accions, els restriccions en quant a actors involucrats, i els documents necessàries a cada pas. Això s’ha representat formalment usant el llenguatge SDA* [6].

A l’Annex 4 es descriuen els procediments per cada tipus de servei.

2.4.2 Home Care Accessory Service – Rehabilitation (HCAS-R)

Una vegada definit el model nuclear de K4CARE, nous grups addicionals de serveis poden ser definits i afegits al model, tal com s’ha presentat abans. Actualment un servei addicional ja està totalment definit: la Rehabilitació.

La rehabilitació és generalment necessària per aquells pacients qui pateixen les

conseqüències d’uns determinats síndromes, molt importants al model de K4CARE (per exemple síndromes d’immobilitat i capacitat cognitiva perjudicada). Hi ha varis tipus d’intervenció. La teràpia física es centra en el moviment físic. La teràpia de la parla es concentra en problemes de comunicació. La teràpia ocupacional ajuda als pacients en els problemes diaris de viure a casa o bé del treball. La teràpia cognitiva treballa sobre les incapacitats cognitives del pacient.

La activació dels HCAS-R és activada en cas de que la Unitat d’Avaluació (EU)

ho demani (el FD o el PC) en el moment de la reavaluació. Des de que les activitats de les dues estructures (HCNS i HCAS-R) han de ser integrades, es proposa que els actors (HN i RCS, respectivament), qui maneguen els dos plans d’intervenció, puguin ser representats pel mateix individual. El HCAS-R depèn de HCNS per aquells serveis ja proporcionats per l’última estructura.


20

2.4.2.1 Actors La Figura 4 mostra una classificació dels actors per HCAS-R:

Figura 3. Actors de HCAS-R Patient to rehabilitate (HCP) El HCP és la típica persona que pateix de conseqüències degut a condicions que

disminueixen les capacitats físiques o d’altres habilitats funcionals, com el síndrome de la mobilitat. Un pacient de rehabilitació pot no tenir algunes capacitats cognitives, i ser tractat per a no perdre més d’aquestes capacitats o en general les habilitats.

Physician in Charge of the Rehabilitation Service (PCR) El PCR és un SP, normalment un Psiquiàtric (un SP especialitzat en medicina

física i rehabilitació) o Geriatria. Rehabilitation Service Coordinator (RSC) El RSC coordina el treball dels Therapists, programa i coordina les diferents fases

del tractament. La HN també pot fer el paper del RSC per aconseguir una integració millor entre els diferents serveis.

Therapists (Th) Els Therapists s’encarreguen de proporcionar un tractament de rehabilitació,

treballant a casa del pacient. Aquest treballa per aconseguir i mantenir les habilitats del HCP. Es divideixen en:

a) Physical Therapist (PT): ajuda als pacients a guanyar les seves funcions com la mobilitat, decrementar el dolor o limitar les seves discapacitats.


21

b) Occupational Therapist (OT): treballa per aconseguir que les activitats instrumentals o del dia a dia siguin més fàcils de realitzar (per exemple: menjar, vestir-se o banyar-se), activitats productives o de temps lliure.

c) Speech and Language Therapist (SLT): assessora i tracta la parla, el llenguatge i els problemes de comunicació per a permetre als HCP comunicar-se de la millor manera.

d) Psychologist (Ps): és un psicòleg clínic, normalment neuro-psicòleg, que està al càrrec de la rehabilitació cognitiva. Tracta desordres de comportament, emocionals i cognitius.

2.4.2.2 Accions i Responsabilitats professionals A l’Annex 5 s’exposen les accions i responsabilitats per HCAS-R en detall.

2.4.2.3 Serveis HCAS-R proposa un conjunt de serveis d’accés individuals (veure Taula 3) per a

dur a terme la rehabilitació d’un pacient particular, admetre i donar d’alta els actors introduïts a la secció anterior i editar informació professional i del pacient. Els Accessory Service de HCAS-R també s’encarreguen dels serveis que hi ha a la Taula 4.

Taula 4. Access Services en Rehabilitació


22

Taula 5. Patient Care Rehabilitative Services

Els serveis individuals que es troben a la Taula 3 tenen descripcions similars a les de HCNS. Per aquest motiu no s’expliquen en el projecte. Els serveis del l’assistència mèdica del pacient de rehabilitació de la Taula 4 s’expliquen a l’Annex 6.

2.4.2.4 Documents

A l’Annex 7 s’exposen les responsabilitats d’escriure i/o llegir Documents

necessaris per a realitzar la rehabilitació del pacient. 2.4.2.5 Procediments Al model de K4CARE, un procediment representa la forma en que les accions

s’apliquen als/pels actors amb l’objectiu de dur a terme un servei. Els procediments per a la rehabilitació s’expliquen a l’Annex 8.

2.5 Implementació de K4CARE

El disseny de K4CARE està compost de tres capes (figura 5): la primera proporciona una interfície web als usuaris i conté tota la funcionalitat del sistema, s’anomena plataforma K4CARE i es divideix en tres components: el Servlet, l’Agent Gateway i el Sistema Multi-Agent (MAS)[7]. La segona és una capa intermèdia anomenada Data Abstraction Layer, que té el paper de facilitat l’accés a les dades d’una forma transparent i a alt nivell. Finalment, trobem una capa anomenada Knowledge Layer, que emmagatzema el tot el coneixement que necessita el sistema per donar l’assistència sanitària professional. A continuació es donen més detalls de cadascuna d’aquestes capes.


23

Figura 4. Estructura del model K4CARE

2.5.1 Plataforma del K4CARE

El MAS s’encarrega de la funcionalitat del sistema al projecte K4CARE. El MAS al K4CARE està compost per diferents tipus d’agents d’assistència sanitària, els agents que representen la plantilla (per exemple: family doctors, nurses, etc.), i els agents que representen els pacients del sistema. A més a més, hi ha un grup d’un altre tipus d’agents (per exemple: agents que executen Plans d’Intervenció Individuals i Plans d’Intervenció Formals).

El model de K4CARE defineix una sèrie de serveis per atendre als pacients. El

principal objectiu dels MAS és connectar la Interfície Web amb els agents de l’assistència sanitària i oferir aquests serveis. Els agents fan la funció d’executar les funcionalitats descrites a [1], que comporta l’execució de tractaments a llarg termini, Plans d’Intervenció Individuals i l’execució de Procediments.

La connexió entre la Interfície d’Usuari (World Wide Web) i els agents al sistema

(HealthCare agents) es fa a través d’un conjunt de agents Gateway. L’accés al sistema MAS de K4CARE es realitza a través d’un web browser. El servidor s’implementa utilitzant servlets. El punt d’entrada per al servlet al MAS serà un agent anomenat Gateway Agent, la funció del qual serà traduir objectes provinents del servlet cap a missatges FIPA que van cap a MAS.


24

Figura 5. Plataforma K4CARE

2.5.2 Capa de Coneixement (Knowledge Layer) La capa inferior conté tot el coneixement formal utilitzat a K4CARE. Aquest està

representat usant diferents llenguatges i es pot emmagatzemar en llocs diferents segons les seves necessitats. El coneixement es distribueix en les següents fonts d’informació:

Electronic Health Record (EHR) i una base de dades relacional:

emmagatzema dades administratives sobre els actors implicats al K4CARE i informació relativa al pacient, que vol dir, el seu historial clínic, etc.

Actor Profile Ontologies (APO): formalització del coneixement relacionat amb tots els agents que interactuen en l’atenció sanitària als pacients crònics. La APO emmagatzema les permissions, els procediments, serveis i documents relacionats a cada actor. Aquest coneixement formal serà utilitzat per a personalitzar l’assistència de tots els agents que treballen amb la plataforma: els professionals de l’assistència sanitària, els pacients i els ciutadans en general.


25

Case Profile Ontologies (CPO): formalitza el coneixement de les malalties d’aquests pacients. La CPO conté la descripció de cadascuna d’aquestes malalties que els pacients pateixen.

Formal Intervention Plans (FIP): formalitza els processos de tractament de cada malaltia.

Procedures: són un conjunt d’accions combinades amb el fi de realitzar un servei.

2.5.3 Data Abstraction Layer

En el model de K4CARE els agents han de poder utilitzar dades procedents de moltes fonts de coneixement. La Data Abstraction Layer (DAL). és una capa intermèdia intel·ligent que sap implícitament on es troba el coneixement que els agents necessiten, i que és capaç de dirigir els requeriments de comunicació cap a les fonts d’informació adequades. Aquesta capa permet que els agents del Sistema Multi-Agent accedeixin de forma transparent al coneixement a través de consultes d’alt nivell. A la Figura 6 es pot veure aquesta capa intermèdia que facilita l’accés a les dades. La DAL està composta per diverses Application Programming Interfaces (APIs) i un nou element anomenat Data Access Interface. Els elements de la Data Abstraction Layer són els següents:

La EHR API proporciona la informació continguda al EHR i dades

administratives (per al log-in), que s’emmagatzemen conjuntament en una base de dades relacional. El resultat de la EHR API es posa al objecte K4CareStorage de Java.

La SDA API dóna accés a la informació representada al SDA, per exemple els Plans d’Intervenció Formals que defineixen normes per a tractar als pacients que pateixen de malalties particulars, Plans d’Intervenció Individuals que són FIPs adaptats a les particularitats d’un pacient o procediments que s’executen per dur a terme un servei.

La Actor Profile Ontology API i la Case Profile Ontology API es creen per realitzar consultes del coneixement contingut a les ontologies APO i CPO. Aquestes APIs, que retornen dades a través d’un objecte K4CareOntology, permeten les consultes a un coneixement específic contingut a la APO o al CPO, com els serveis que un actor pot iniciar o els tipus de documents continguts al EHR. La APO API i la CPO API accedeixen a aquestes ontologies a través de l’OWL Wrapper, dissenyat i implementat dintre del projecte K4CARE.

La part més important de la DAL és l’accés a la Data Access Interface (DA). Aquest element treballa amb diferents fonts de coneixements i tradueix les dades a objectes Java, necessaris pel sistema multi-agent. La interfície DA té un paper actiu, està a càrrec dels permisos d’accés a les diferents fonts de coneixement; combina informació de diferents fonts per a donar una resposta única a les peticions d’alt nivell, etc.


26

3 Ontologies

3.1 Què són les ontologies?

La terminologia ontologia en informàtica fa referència a el intent de formular un

exhaustiu i rigorós esquema conceptual dintre d’un domini donat, amb la finalitat de facilitar la comunicació i compartició d’informació entre diferents sistemes.

El sinònim més usual d’ontologia és conceptualització (sistema de categories que

donen una visualització del món). Una ontologia constitueix una especificació formal, explícita d’una conceptualització compartida. En aquesta definició [9] convertida ja en estàndard, conceptualització es refereix a un model abstracte d’un fenomen del món del que se’n identifiquen els conceptes més rellevants; explícita fa referència a la necessitat d’especificar de forma conscient els diferents conceptes que formen una ontologia; formal indica que l’especificació ha de ser representada per mitjà d’un llenguatge de representació formalitzat; finalment, compartida reflexa que una ontologia ha de contenir coneixement acceptat (pel grup de persones que l’utilitzaran).

Quan parlem d’ontologies com a “sistemes de representació del coneixement” cal

especificar a quin tipus de sistemes ens referim. En realitat, les ontologies s’estan aplicant a qualsevol tipus d’aplicacions informàtiques en les quals és necessari definir concretament el conjunt d’entitats rellevants en el camp d’aplicació determinat i les interaccions entre aquestes.

3.2 Classificació de les ontologies

En funció de l’expressivitat o del subjecte i del tipus d’estructura de la

conceptualització existeixen varis tipus d’ontologies [10]:

Ontologia d’alt nivell: descriuen conceptes molt generals com espai, temps, matèria, objecte, event, acció, etc., els quals són independents d’un problema o domini en particular.

Ontologia de domini: descriuen el vocabulari relacionat amb un domini genèric

mitjançant l’especialització dels termes introduïts a l’ontologia d’alt nivell. Ontologia de mètodes: donen definicions dels conceptes rellevants i de les relacions

aplicades per a especificar un procés i per aconseguir una tasca en particular. Ontologia de tasques: descriuen el vocabulari relacionat a una tasca o activitat

genèrica (com la medicina o els automòbils), mitjançant l’especialització dels termes introduïts a l’ontologia d’alt nivell.

Ontologia de tasca-domini: descriuen, respectivament, el vocabulari relacionat amb

un domini genèric (com la medicina o els automòbils) o una tasca o activitat genèrica (diagnòstic o venta), mitjançant l’especialització dels termes introduïts a l’ontologia d’alt nivell.


27

Ontologia d’aplicacions: descriuen conceptes que depenen tant d’un domini com

d’una tasca en particular, els quals solen ser especialitzacions d’ambdues ontologies. Normalment, aquests conceptes corresponen als rols duts a terme per entitats del domini mentre realitzen una certa activitat. Contenen coneixement essencial per a modelar una aplicació particular sota consideració.

3.3 Components de les ontologies

Hi ha moltes representacions dels formalismes utilitzats en les Ontologies, però hi

ha tres components comuns que comparteixen tots els formalismes [11].

Classes: representen entitats que formen part de l’ontologia. Per exemple, al domini dels viatges, els conceptes són: llocs (ciutats, pobles, etc.), estances (hotels, càmpings, etc.) i mitjans de transport (avions, trens, cotxes, etc.). En ontologies les classes estan organitzades de forma jeràrquica de manera que mecanismes d’herència puguin ser aplicats.

Relacions: representen un tipus d’associació entre els elements del domini.

Normalment, les ontologies contenen relacions binàries. El primer argument és conegut com el domini de la relació, i el segon argument és el rang. Les relacions binàries també s’utilitzen per a definir atributs. Aquests es diferencien de les relacions ja que el rang és un datatype, com un String, numèric, etc, mentre que el rang de les relacions és un concepte.

Instàncies: són utilitzades per a representar elements concrets o individus en una

ontologia. Aquests elements són membres d’alguna de les classes de l’ontologia.

3.4 Llenguatge OWL i Jena per accedir al OWL

L’OWL1 està dissenyat per a ser utilitzat en aplicacions que necessitin processar el contingut de la informació enlloc de, únicament, representar informació per als humans [12]. OWL té tres subllenguatges, amb un nivell d’expressivitat creixent: OWL Lite, OWL DL i OWL Full.

OWL pot ser utilitzat per a representar explícitament el significat de termes en

vocabularis i les relacions entre aquests. Aquesta representació de termes i les seves interrelacions s’anomena ontologia.

El Llenguatge d’Ontologia Web (OWL) té com a objectiu facilitar un model de

marcat (codificar un document que, juntament amb el text, incorpora etiquetes o marques que contenen informació addicional sobre l’estructura del text o la seva presentació) construït sobre RDF (és un model de dades per a objectes (“recursos”) i relacions entre ells, proporcionant una semàntica simple) i codificat en XML (proporciona una sintaxis superficial per a documents estructurats, però no imposa restriccions semàntiques en el significat dels documents).

1 OWL: http://www.w3.org/tr/owl-features/.

http://www.w3.org/tr/owl-features/


28

OWL és utilitzat quan la informació continguda als documents necessita ser processada per aplicacions, contràriament a situacions on el contingut ha de ser presentat als humans. OWL pot ser utilitzat explícitament per a representar el significat en termes de vocabularis i les relacions entre aquests termes. Aquesta representació de termes i les seves interrelacions s’anomena Ontologia. OWL té altres facilitats per a expressar semàntiques com XML, RDF i RDF-S. OWL és una revisió del llenguatge d’ontologia web DAML+OIL, que incorpora temes de disseny d’aplicacions.

La Semantic Web és una visió de futur de la Web, on la informació es dóna amb

significat explícit, facilitant-ho a les màquines per a processar automàticament i integrar la informació de la Web.

El llenguatge OWL s’ha dissenyat per a completar la necessitat d’un Web Ontology Language.

XML facilita una superfície sintàctica per a documents estructurats, però no

imposa restriccions semàntiques en el significat d’aquests documents. XML Schema és un llenguatge per a restringir l’estructura de documents XML i

estendre l’XML amb tipus de dades. RDF és un datamodel per a objectes i relacions entre ells, dóna una semàntica

simple per aquest datamodel, i aquests datamodel poden ser representats en sintaxis XML.

RDF Schema és vocabulari per a descriure propietats i classes de recursos RDF, amb semàntica per a generalitzar jerarquies de les classes i propietats.

OWL afegeix més vocabulari per a descriure propietats i classes: entre altres, relacions entre classes, cardinalitat, igualtat, és més ric en tipus de propietats, característiques de propietats i classes enumerades.

Jena és un Java framework per a la creació d’aplicacions de Semantic Web. Proporciona un entorn de programació per a RDF, RDFS i OWL, SPARQL i inclou una màquina basada en regles.

Jena Framework inclou: Una API RDF Llegir i escriure en RDF/XML, N3 i N-Triples Una API OWL In-memory i emmagatzematge persistent SPARQL query engine

3.5 Eina Protégé

Protégé [13] és una eina utilitzada per al desenvolupament d’ontologies i sistemes basats en el coneixement creada a la Universitat d’Stanford. Aquest està desenvolupat en JAVA.

Les aplicacions fetes amb Protégé són aplicades en resolució de problemes i presa de decisions en dominis particulars. L’eina empra una interfície d’usuari que facilita la creació d’una estructura de frames amb classes, slots i instàncies d’una manera integrada.


29

Les ontologies del K4CARE (com la APO) han estat implementades en aquesta eina. Protégé permet crear ontologies OWL utilitzant una interfície gràfica. Es pot trobar més informació sobre el Protégé a la seva pàgina web (http://protege.stanford.edu/), i en el K4CARE s’usa la versió 3.1 (http://protege.stanford.edu/download/old-releases/3.1/full).

Per al PFC, el Protégé ha estat molt útil per a comparar la creació de SubAPOs

amb la APO general. El Protégé reflexa l’estructura amb totes les seves classes, propietats, restriccions, etc. d’una ontologia. Per aquest motiu ha estat present durant tota la feina realitzada. A més a més, l’eina creada en aquest projecte és un semblant al Protégé en quan a vista d’ontologies i particularització, tot i que molt més senzilla per a facilitar-ne el seu ús als futurs usuaris.

La APO està continguda en un fitxer anomenat APO.owl. Per omplir aquesta

ontologia usant Protégé, cal seguir els següents passos: 1. Obrir Protégé 2. Clicar a Create new Project... 3. Seleccionar Create From Existing Sources i també tenir seleccionat OWL

Files (.owl or .rdf) i finalment clicar al botó Next >. 4. Modificar OWL file name or URL clicant al botó . 5. Ara cal escollir el fitxer APO.owl. 6. Clicar al botó Finish.

Una vegada s’ha obert el fitxer amb el programa, es podrà veure la pantalla de la

Figura 7. Clicant a les diferents pestanyes (OWL Classes, Properties, Individuals, Forms), es pot anar veient l’estructura de l’ontologia amb les seves classes, propietats i restriccions.

Figura 6. Pantalla principal de Protégé

http://protege.stanford.edu/

http://protege.stanford.edu/download/old-releases/3.1/full


30

4 L’ontologia de Perfils d’Actors (APO)

4.1 Definició de la APO

Una de les tasques importants del sistema de K4CARE ha estat la definició del model de dades que representarà el coneixement mèdic que la plataforma del K4CARE ha de manegar.

Tal com ja s’ha dit, la definició de la APO comença amb l’especificació prèvia del model de K4CARE. Posteriorment es van usar tècniques d’enginyeria del coneixement per refinar el model i fer-ne una formalització que pugui ser utilitzada pel sistema informàtic. Durant aquest procés es va detectar la informació que hauria de ser afegida, i detectar com poder definir el model de forma que la seva estructura sigui fàcil de mantenir, de reduir els errors i d’ampliar. La definició de la APO es va fer amb la col·laboració d’experts mèdics, els quals van revisar la APO tot analitzant el model [1]

Després d’aquest procés la APO conté el coneixement referit als serveis bàsics

identificats prèviament al model mèdic. L’ontologia APO s’ha codificat en el llengutage OWL, utilitzant l’eina Protégé.

El paper de la APO en el K4CARE és molt important, ja que és l’element que

permet definir de forma dinàmica el comportament del sistema i els serveis a proveir per cada usuari, segons del quin tipus d’actor es tracti. A més a més, la APO permet la integració i la coordinació de diferents actors per assegurar una correcta Home Care assistència, ja que defineix els rols i les interaccions entre els actors a nivell de serveis mèdics. També té un paper important en la protecció de la privadesa de les dades, que és un tema molt important quan es tracta d’historials mèdics, que són dades privades molt sensibles. Això es fa a través de la definició dels permisos de lectura i escriptura de cada document, els quals restringeixen l’accés a les dades a persones no autoritzades.

4.2 Perfil dels continguts de la APO

Els principals conceptes de la APO es descriuen seguidament. Les relacions entre aquests conceptes es representen a la Figura 8.

Entitat: es refereix a totes les persones o grups de persones involucrats al

Home Care. Entitat es divideix en dues classes principals: Group, per a equips de treball amb responsabilitats d’atenció sanitària a domicili; Actor, per a participants individuals (pacient, infermera, doctor de família, etc.). Les Entitats emmagatzemen informació sobre els Serveis que poden iniciar i les Accions que poder realitzar. També tenen un conjunt de drets sobre els Documents que poden llegir i escriure.

Servei: es defineix com una activitat del Home Care que engloba el treball

realitzat per un o més actors d’una forma coordinada. Estan classificats en Access Services, Patient Care Services i Information Services. La


31

propietat serviceInitiatedBy (servei iniciat per) informa sobre les entitats que poden activar el servei, mentre que hasProcedure indica una o més alternatives de modificar el servei mitjançant procediments. Finalment, hasDocument (té document) lliga documents que poden ser necessitats per a realitzar el servei.

Acció: representa els passos simples que cal fer per a realitzar un servei.

L’ontologia en distingeix varis subtipus, com l’acció social, cas de direcció, acció d’infermeria, etc. Les accions tenen un objecte (propietat hasObject) que indica l’actor a qui s’aplica el servei (normalment un pacient), i un subjecte (propietat hasSubject) que és l’entitat que realitza l’acció. Les accions poden treballar sobre alguns documents (propietat usesDocument).

Procediment: és la representació de la forma en que un Servei es realitza

en termes d’accions i la resta de serveis. Emmagatzema informació sobre el servei al qual es refereix (propietat isProcedureOf), els passos del procediment (propietat hasStep) o accions i serveis que prenen part a la provisió del servei i l’algoritme SDA, que defineix com el procediment ha de ser aplicat, que és el fluxe d’accions (propietat hasSDAFile). Les diferents unitats de cura poden tenir diferents SDAs per al mateix procediment, per aquesta raó l’ontologia inclou també el concepte SDA.

Document: conté els resultats d’una acció realitzada al pacient. Els

documents estan al Electronic Health Record. Poden ser utilitzats en diversos procediments (propietat isDocumentOf), i poden ser utilitzats per diferents actors amb diferents drets (propietats isWrittenBy, isWrittenSometimesBy, isReadBy, isReadSometimesBy).

Cada classe fulla de la jerarquia dels conceptes Entitat, Servei,

Procediment i SDA hereten de la jerarquia de Care Unit Element. Això permet indicar a quina care unit es refereixen. Per cada nova HCAS que s’afegeix per a estendre les capacitats del model K4CARE, la APO ha de contenir una nova subclasse de CareUnitElement amb el nom de la nova HCAS (per exemple: rehabilitació, oncologia).


32

Figura 7. Arquitectura de la APO

La APO emmagatzema el coneixement sobre quins actors estan involucrats en un

Home Care d’assistència, incloent els seus rols, funcionalitats i permissions. L’ontologia representa els elements mínims necessaris per a donar un HC bàsic, tenint en compte el model proposat al projecte K4CARE. Aquest model fa referència a les estructures més comunes i bàsiques d’un Home Care en el sistema europeu, anomenat HCNS (Home Care Nuclear Services). El model permet la definició de HC Accessory Services (HCAS) que hereten de HCNS i que són serveis especialitzats provinents de serveis d’Oncologia o Unitats de Rehabilitació.

Com s’explica a [14], la construcció d’ontologies des de zero és un procés

complicat. Per aquesta raó, es va dissenyar i implementar l’eina ISA (Intelligent Service Adder) [15]. Aquesta eina facilita la definició i la codificació de nous HCAS que són afegits a una Actor Profile Ontology d’una forma guiada, per evitar inconsistències i redundàncies. Amb aquesta eina és possible afegir serveis addicionals a la APO, obtenint una estructura global que representi el model de Home Care i que és suportat pel sistema K4CARE.


33

5 Particularització de la APO (Tailoring)

La Particularització o Tailoring es necessita per adaptar el comportament del sistema en situacions particulars. Hi ha un punt de la descripció d’objectius del projecte K4CARE [16] que diu: “Personalitzar l’accés a la plataforma K4CARE. Adaptar les APOs als requeriments dels usuaris per a permetre l’accés al EHR o l’assistència del model K4CARE. Els mètodes de personalització seran aplicats als care-givers d’ontologies per a representar el factor de que no tots els professionals interactuen en l’atenció sanitària de la mateixa manera. Les ontologies particulars i les interfícies de les tecnologies, juntament amb aspectes d’utilitat i seguretat, passaran a ser un aspecte important en l’acceptació i socialització de la plataforma K4CARE”.

A l’Annex 9 s’hi troba un document redactat per al projecte K4CARE, on s’hi detalla la informació del procés de Tailoring.

Des del punt de vista tecnològic, el Tailoring de la APO consisteix en obtenir un

subconjunt o particular de l’ontologia. Això es fa eliminant de l’ontologia original (APO) els conceptes que no estan relacionats amb un cert sector particular d’assistència. Amb el procés de Tailoring es genera una nova SubAPO, els continguts de la qual es refereixen únicament a una vista particular de la APO general.

Des del punt de vista mèdic, es van proposar dos tipus de Tailoring:

- Tailoring de Care Units: genera una SubAPO amb la informació concreta d’una care unit (per exemple: una SubAPO per HCAS). Això és útil per reduir els serveis que el sistema proporciona en cas de tenir un centre de Home Care que només ofereixi els HCNS bàsics però no HCAS.

- Tailoring de Entitats: genera una SubAPO amb la informació concreta d’un actor. Per exemple: una SubAPO per al Family Doctor (metge de família), o una SubAPO per a la Evaluation Unit (unitat d’avaluació). Una vegada s’obté la SubAPO, pot ser modificada per un usuari particular, permetent-li la generació de la seva configuració personal. Aquest tipus de Tailoring permet personalitzar el comportament del K4CARE a cada usuari.

Per tal d’ajudar a l’usuari a fer aquesta particularització de l’eina, en aquest PFC

es defineix una eina que permet l’extracció parcial de la APO de forma automàtica, i proporciona una interfície gràfica que mostra el resultat i permet personalitzar la APO sense necessitat de conèixer el llenguatge OWL, ni usar eines més sofisticades com el Protégé. Aquesta eina s’ha anomenat ATAPO, que vol dir: Automatic Tailoring of the K4CARE Actor Profile Ontology. Aquesta eina s’explica en el capítol 6.

5.1 El manegament de fitxers OWL

Per manegar el contingut de fitxers que segueixen el llenguatge OWL, s’ha implementat un OWL Wrapper que és un embolcall per una ontologia que permet l’abstracció i l’accés a l’ontologia a través de funcions del Wrapper. Va ser implementat per Joan Casals dins de la seva tesi de màster al juny de 2007 [17].


34

Amb aquestes funcions es pot accedir als elements d’una ontologia, afegir elements, crear relacions jeràrquiques, afegir propietats i restriccions, carregar i guardar una ontologia en un fitxer amb format OWL. Fa ús de les llibreries Jena. OWL Wrapper utilitza a l’hora altres classes que encapsulen els elements d’una ontologia.

Per tal de poder implementar les funcionalitats de Tailoring, en aquest PFC s’han

estudiat les seves funcions, s’han fet certes modificacions que s’expliquen al punt 5.2.3. i s’ha fet la documentació (JavaDoc) de totes les classes per poder comprendre el funcionament i poder fer-ne ús dins de la creació de SubAPOs. A l’Annex 10 es descriuen les funcions del OWL Wrapper, és a dir, el Javadoc realitzat.

Els canvis més importants en el codi que s’han fet en aquest PFC són:

En la versió de Joan Casals, les llistes no eren parametritzables, i això ha donat problemes en la implementació posterior. A fi d’evitar-ho, s’han parametritzat totes les llistes per fer-les totalment compatibles amb Java 5.0. Tot el codi per a la funcionalitat d’aquesta eina està implementat amb Java 5.0.

Una tasca important ha sigut la modificació de la funció saveToOWLFIle del Wrapper perquè guardés les propietats inverses ja que en la primera versió no es guardaven i és necessari per realitzar correctament el Tailoring. S’han afegit funcions de la llibreria Jena per poder implementar la funció.

També s’ha modificat la funció saveToOWLFIle per a que buidi el buffer i tanqui els fitxers guardats, per poder ser utilitzats després.

5.2 Tailoring de Care Units

Una primera versió del Tailoring de Care Units va ser implementada en Java per Joan Casals al maig de 2007 dintre de la seva tesi de màster [17]. Aquest codi Java genera una SubAPO particular per cada CareUnit.

Degut a canvis a l’estructura de l’APO i a la necessitat d’afegir funcions necessàries pel Tailoring, en aquest PFC s’ha revisat i modificat aquest codi, tal com s’explica més endavant.

Aquest tipus de Tailoring crea una SubAPO basada en alguna de les Care Units

existents a la APO, que serà una vista particular de l’ontologia. El resultat d’aplicar Tailoring de Care Units és una SubAPO en la qual només apareix l’estructura de l’ontologia que utilitza la Care Unit de la qual s’ha creat la SubAPO.

Es poden crear SubAPOs per qualsevol Care Unit existent actualment a la APO, inclòs les que s’afegeixin en qualsevol moment en un futur. Les care units que estan definides a la APO, i de les que, per tant, es poden crear SubAPOs actualment són:

- HCNSElement - RehabilitationElement

La SubAPO resultant manté la mateixa estructura que la APO primària. Les

classes principals de la SubAPO de Care Unit són totes les que defineixen conceptes que es necessiten en la Care Unit corresponent, que són les següents:

- Actions - Documents


35

- Entities - Procedures - SDA - Services

Cadascuna d’aquestes classes principals conté la jerarquia de totes les subclasses

que utilitza la Care Unit amb les seves propietats i restriccions que formen l’estructura segons l’estructura de l’ontologia general.

A la Figura 9 es pot veure la APO amb els elements abans esmentats.

Figura 8. Protégé - APO

Si comparem la Figura 9, que mostra la APO general amb la Figura 10, que

mostra la SubAPO de la Infermera, podem veure que hi ha elements que ja no hi estan continguts:


36

Figura 9. Protégé – Nurse_APO

5.2.1 Creació de la SubAPO

En aquest apartat fem una descripció en molt alt nivell del funcionament del Tailoring de Care Units. Els passos principals que es necessiten per extreure el coneixement particular d’una certa unitat assistencial són els següents:

1. Carregar l’ontologia original. 2. Crear totes les main classes excepte CareUnitElement. 3. Crear totes les subclasses que hereten de les classes principals creades i de la

Care Unit escollida. 4. Crear les relacions és-un (link) entre les classes.

Fins aquí s’ha creat l’estructura de les Entities, Services i SDA que intervenen en la Care Unit.

5. Crear les propietats i restriccions que afecten a les classes creades i afegir-les a

cada classe. 6. Crear els Documents, Procedures i Actions que afecten a les propietats i

restriccions creades i afegir-los a cada propietat o restricció. 7. Crear les relacions és-un (relacions pare-fill) entre les classes afegides. 8. Guardar la SubAPO creada en un fitxer .OWL.

El recorregut per la jerarquia de classes de l’ontologia es fa amb crides recursives,

això permet que es puguin afegir o eliminar elements o nivells de jerarquia en l’ontologia general i aquests canvis seran reconeguts en la creació de la SubAPO.

Cal recordar que no s’afegeixen Entities, Services i SDA que no pertanyen a la Care Unit escollida (no hereten de la Care Unit). Tampoc s’afegeixen Documents, Procedures i Actions no utilitzats per les Entities i Services afegits, que són aquells que no estan vinculats a propietats o restriccions de les Entities i Services.


37

5.2.2 Modificacions fetes sobre el codi previ

En aquesta secció es descriuen les modificacions realitzades per Ester Morales i

Sergio Martínez dintre d’aquest PFC.

Problema: Les classes filles en la SubAPO resultant no agafen les propietats i restriccions heretades de les classes pares. Solució: S’afegeixen aquestes restriccions i propietats heretades de les classes pare en el moment que es creen les classes filles i s’incorporen a l’estructura de classes de la SubAPO.

Problema: En l’estructura de classes principals (main classes) no apareix la classe principal SDA ni la seva jerarquia de classes. Solució: S’afegeix la classe principal SDA i la rutina de creació de l’estructura de classes incorpora a la SubAPO les relacions, propietats i restriccions de la jerarquia SDA.

Problema: La SubAPO resultant no té en compte les propietats i restriccions inverses, per exemple: actor llegeix document (actor Reads document) la seva propietat inversa és: document és llegit per actor (document isReadBy actor). Solució: En aquest cas la funció del Wrapper saveToOWLFIle (descrita al punt 6.1) no contempla aquesta opció, en canvi cada propietat té l’atribut inverse que guarda una referència de la propietat inversa. S’ha solucionat cridant directament a les llibreries Jena, en concret la funció: propertyInverve.setInverseOf(property) i s’ha afegit a la funció saveToOWLFIle de Wrapper de tal manera que en el moment de guardar a fitxer OWL, es recorren totes les propietats de la SubAPO i s’indica quina propietat és inversa de cada propietat en la referència a la SubAPO però ja en el format de Jena (OntModel).

5.2.3 Pseudocodi en alt nivell del Tailoring of Care Units

Hem desenvolupat el pseudocodi en alt nivell per tal d’estudiar a fons com es realitza el procés de Tailoring i poder fer les modificacions descrites al punt anterior, necessàries per al correcte funcionament. Author: Joan Casals Date: May 2007 Checked: Sergi Martinez and Ester Morales Date: November 2007 Function: CreateSubAPO(“name”); Description: Creates a Sub-APO (called SubAPO) starting with the service (Care Unit) with name “name”. Loads the SubAPO in OWL format with name “name”. Some individual functions are descrived and indicated like: //Descrived function (number): The rest of the functions and accions are descrived by their name. Pseudocode:


38

CreateSubAPO(“name”){ Wrapper APO; Wrapper SubAPO; MyClass CareUnit; APO = Load("APO.owl"); CareUnit = TakeOutClass(APO,"name of the CareUnit that is wanted to be created in the SubAPO"); SubAPO = CreateSubAPO(CareUnit); //Function with description:(1) Load(SubAPO, name+".owl"); } //Description: (1) Function (1): CreateSubAPO(MyClass CareUnit) returns Wrapper Description: Creates an object Wrapper (that represents an ontology) starting with a class that belongs to Care Unit. Returns the object Wrapper. Pseudocode: CreateSubAPO(MyClass CareUnit) returns Wrapper { //Looks over the APO’s main classes and creates the SubAPO’s structure of classes Visit all the main classes of the APO apart from ‘SDA’ and ‘CareUnitElement’; Add the previous main classes to the Sub-APO and GenerateTreatSons(SubAPO,c); //Function with description:(2) Take out class from the APO with the name ‘Procedure’; AddActionsDocuments(SubAPO,Procedure); //Function with description:(3) //Looks over all the APO’s classes and allocates properties to the SubAPO While(ThereAreClasses(APO)) do if (the class of the APO is also in the SubAPO) then //Allocates the APO’s properties to Add all the properties that contains the class of the APO to the class of the Sub-APO if they haven’t been added; If(the property is ObjectProperty)then Add the classes of the domain to the domain of the property; Add the classes of the range to the range of the property; If not //The property is DataTypeProperty Add the classes of the domain to the domain of the property; Endif Endif Endwhile Set relations father-son between the SubAPO’s properties and the APO’s relations to all the properties of the Sub-APO; Add to each class of the Sub-APO the necessary and sufficient restrictions and the necessary ones that has the same class in the APO; Return (SubAPO); } //Description:(2) Function (2): GenerateTreatSons(Wrapper SubAPO,MyClass c) returns list Description: Creates the hierarchy of classes from the SubAPO basing with a main class (recursive call). Returns a list with the new classes added to the SubAPO. Pseudocode: GenerateTreatSons(Wrapper SubAPO,MyClass c) returns list { While (ThereAreSons(c)) do son = NextSon(c); if (son and CareUnit have a fahter in common) then //CareUnit is the extracted class of the APO from where the APO wants to be


39

extracted Add son to the Sub-APO and to the returning list; if not list = GenerateTreatSons(SubAPO,son); //recursive call if (!Empty(list)) then AddClass(SubAPO,son); endif //Add fathers and sons While not (Final(list)) do grandSon = NextClass(list); if (son doesn’t have grandSon as a son) then Set relations father-son between son and grandSon; endif Add son to the returning list; endWhile endif endWhile Returns list; } //Description:(3) Function (3): AddActionsDocuments(Wrapper SubAPO,MyClass Procedure) Description: Adds to the SubAPO the actions and documents depending on the procedures. When this function is called, the structure of classes from the SubAPO that is in the pharameter has been already created. Pseudocode: AddActionsDocuments(Wrapper SubAPO,MyClass Procedure) { if (no HasSons(Procedure)) and SubAPO Contains("Procedure") then //Add to the SubAPO the actions hasStep = Gets from the APO the property ("hasStep") with the restriction "SOME.VALUES FROM"; //Checks if it is necessary, if not, if it is necessary and sufficient and if not, if it doesn’t exist. if (Exists(hasStep)) then Take the class Procedure and see if it contains the restriction ‘hasStep’; If Sub-APO doesn’t contain ‘step’, it has to be added. Otherwise it is a Service; endif //Adds to the SubAPO the documents //Add document to the SubAPO and does the linkers father-son }

5.3 Tailoring d’Entitats

Consisteix en la creació d’una SubAPO per un actor o grups d’actors (com per exemple la unitat d’avaluació) que és una visió particular de l’ontologia general per un actor concret. Això permet que un usuari només vegi la informació del model K4CARE que li afecta a ell directament, degut al seu rol dins del sistema. Això s’utilitza per definir el comportament dels agents intel·ligents de forma dinàmica i automàtica dins de la plataforma K4CARE.

Segons aquest model, cada usuari ha de construir la seva vista personal del model i aquesta s’emmagatzema a la base de dades del sistema. La capa intermitja de gestió


40

del coneixement (la Data Abstraction Layer) és la que redirigeix les consultes dels agents cap a la SubAPO corresponent al seu propietari.

El resultat del Tailoring d’actors és una SubAPO en la qual només apareix l’estructura de l’ontologia que utilitza l’actor del qual s’ha creat la SubAPO. Es poden crear SubAPOs per qualsevol Entity inclòs els que s’afegeixin en qualsevol moment futur. El resultat és un fitxer amb format OWL independent de l’estructura de l’ontologia general (APO).

Les entitats de les quals es poden crear SubAPOs són totes les que estiguin

definides a la APO, i que heretin de Entity. Actualment són:

- FamilyDoctor - HeadNurse - Nurse - PhysicalTherapist - PhysicianInCharge - PhysicianInChargeRehabilitation - RehabilitationServiceCoordinator - SocialWorker - ContinuousCareProvider - InformalCareGiver - OccupationalTherapist - Phsycologist - SocialOperator - SpecialistPhysician - SpeechAndLanguageTherapist - Patient - EvaluationUnit

La SubAPO resultant conté només els elements (classes) que utilitza l’Actor

escollit. Cadascuna d’aquestes classes principals conté la jerarquia de totes les subclasses que utilitza l’Actor amb les seves propietats i restriccions que formen la estructura segons l’estructura de l’ontologia general. En general, una SubAPO d’un actor tindrà:

- Actions - CareUnitElement - Documents - Entities (només el propi Actor) - Procedures - SDA - Services


41

Figura 10. Estructura de la SubAPO de l’actor Family Doctor

A la Figura 11 es pot veure com s’obtenen les classes a partir de l’actor, en aquest

cas el Doctor. A partir de les propietats readsDocument i writesDocument es poden obtenir els documents que penjaran de l’estructura de la SubAPO del Doctor. Les accions s’obtenen a partir de la propietat doesAction. Aquest només podrà veure aquelles accions que realitza. La propietat hasMember classifica el tipus d’actor, tenint en compte el grup d’actors dins el que es troba. Hi ha també una jerarquia secundària que indica a quines Care Unit pertany.

A la Figura 12 es mostra un exemple de SubAPO per a un actor, en aquest cas de la Infermera, on s’hi pot veure la seva estructura.

Figura 11. Protégé – SubAPO de Nurse


42

5.3.1 Creació de la SubAPO

La creació de la SubAPO per actor s’ha dissenyat i implementat de forma diferent a la de Care Unit, ja que en aquest cas és necessari que l’estructura de la SubAPO inclogui només l’estructura relativa a l’actor particular, que no serà tota l’estructura de la APO. Aquesta estructura es va deduint a partir de les relacions entre conceptes, de forma automàtica.

A partir de la classe de l’actor (que és classe filla), es va pujant per l’estructura, segons les relacions pare-fill (is-a), creant les classes pares fins arribar a les classes principals, un cop tenim l’estructura de l’actor s’afegeixen els documents als que té accés, les accions que realitza i els serveis en què intervé segons les restriccions i propietats que l’actor té a l’ontologia general (APO).

A continuació presentem una descripció en molt alt nivell del funcionament del

Tailoring of Actor Profiles: 1. Carregar l’ontologia original. 2. Crear totes les classes principals esmentades abans. 3. Crear la classe de l’Actor que es vol crear la seva SubAPO. 4. Crear les classes pare d’aquesta fins arribar a una main class. 5. Crear les relacions pare-fill (link) entre les classes. Fins aquí s’ha creat l’estructura de les Entities. 6. Crear les propietats i restriccions que afecten a les classes creades i afegir-les a

cada classe. 7. Crear els Documents, Actions i Services que afecten a les propietats i

restriccions creades i afegir-los a cada propietat o restricció. 8. Crear les relacions pare-fill (link) entre les classes afegides (documents, serveis i

accions). 9. Guardar la SubAPO creada en un fitxer .OWL.

Les relacions d’herència de l’estructura i les propietats i restriccions que afecten a

la estructura s’agafen de l’ontologia general, es tenen en compte les propietats i restriccions heretades i les propietats inverses.

El recorregut per la jerarquia de classes de l’ontologia es fa amb crides recursives, això permet que es puguin afegir o eliminar elements o nivells de jerarquia en l’ontologia general i aquests canvis seran reconeguts en la creació de la SubAPO.

No s’afegeixen Documents, CareUnitElements, Services i Actions no utilitzats per

l’Actor (segons les restriccions de l’ontologia general).

5.3.2 Pseudocodi en alt nivell de Automatic Tailoring of Actor Author: Sergi Martinez and Ester Morales Date: December 2007 Function: CreateSubAPO(“name”); Description: Creates a Sub-APO (called SubAPO) starting with the Actor (Entity) with name “name”.


43

Loads the SubAPO in OWL format with name “name”. Some individual functions are descrived and indicated like: //Descrived function (:): The rest of the functions and accions are descrived by their name. Pseudocode: CreateSubAPO(“name”){ Wrapper APO; Wrapper SubAPO; MyClass Actor; APO = Load(“APO.owl”); CareUnit = TakeOutClass(APO,”name of the Actor that is wanted to be created in the SubAPO”); SubAPO = CreateSubAPO(Actor); //Function with description:1) Load(SubAPO, name+”.owl”); } //Description: (1) Function (1): CreateSubAPO(MyClass Actor) returns Wrapper Description: Creates an object Wrapper (that represents an ontology) starting with a class that belongs to Actor. Returns the object Wrapper. Pseudocode: CreateSubAPO(MyClass Actor) returns Wrapper { Wrapper SubAPO; //Looks over the APO’s main classes and creates the SubAPO’s structure of classes Visit all the main classes of the APO apart from ‘SDA’ and ‘CareUnitElement’; Add the previous main classes to the Sub-APO and createAndAllocateparents(SubAPO,newc); //Function with description:2) //Looks over all the APO’s classes and allocates properties to the SubAPO While(ThereAreClasses(APO)) do if (the class of the APO is also in the SubAPO) then //Allocates the APO’s properties to Add all the properties that contains the class of the APO to the class of the Sub-APO if they haven’t been added; If(the property is ObjectProperty)then Add the classes of the domain to the domain of the property; Add the classes of the range to the range of the property; If not //The property is DataTypeProperty Add the classes of the domain to the domain of the property; Endif Endif Endwhile Set relations father-son between the SubAPO’s properties and the APO’s relations to all the properties of the Sub-APO; Add to each class of the Sub-APO the necessary and sufficient restrictions and the necessary ones that has the same class in the APO; Return (SubAPO); } //Description:2)


44

Function (2): GenerateAndAllocateparents(Wrapper SubAPO,MyClass c) Description: Creates the hierarchy of classes from the SubAPO basing with Actor class (recursive call). Pseudocode: createAndAllocateparents (Wrapper SubAPO,MyClass c) { While (ThereAreParents(c)) do parent = NextParent(c); if (parent is not a main class) then AddClass(SubAPO,parent); c.addFather(parent); parent.addChild(c); createAndAllocateparents (SubAPO, parent) //recursive call else AddClass(SubAPO,parent); c.addFather(parent); parent.addChild(c); endIf }

5.4 Personalització

Només les SubAPOs dels actors són les que poden ser personalitzades. Aquestes personalitzacions permeten modificar el perfil d’un usuari particular. Tenint en compte els coneixements mèdics dels experts, només hi ha dos conceptes que són susceptibles a ser personalitzats:

- Els documents que un actor pot llegir. - Les accions que un actor pot realitzar.

Qualsevol personalització ha de ser autoritzada pel Physician in Charge ja que:

1. El responsable ha d’estar al corrent de tots els canvis realitzats. 2. La autorització també indica temps. 3. Qualsevol canvi ha de ser legal, en particular aquells relacionats amb l’accés a

informació mèdica dels pacients amb informació privada.

Hi ha moltes maneres de realitzar la personalització de les SubAPOs. Per tal de decidir quina és la més adequada, es va fer un estudi en el K4CARE per resoldre aquest problema. Aquest estudi va donar les següents pautes a seguir per la realització de la personalització de SubAPOs: - Només es considera la personalització de SubAPOs per actor. - Només es poden personalitzar els documents que un actor pot llegir i les accions que un actor pot realitzar. - Qualsevol personalització ha d’estar validada pel corresponent cap de la unitat, ja que pot haver-hi informació mèdica privada. - S’afegeixen noves propietats temporals per distingir els documents i accions que estan pendents de validació i les que estan ja validades.

Aquesta solució és la més apropiada ja que no modifica l’estructura de la base de dades del sistema, i només el codi de la DAL.


45

5.4.1 Personalització de Documents

La APO conté informació sobre els drets d’accés a un document per cada tipus d’actor. Només es poden personalitzar aquells documents que es puguin llegir, afegint nous documents als que ja li corresponen a l’actor [18]. A continuació es mostrarà amb un exemple les diferents possibles solucions que es van plantejar a aquest problema:

Dr E. Guevara necessita verificar si una teràpia nova de rehabilitació afectarà al seu

pacient. Decideix tenir accés sistemàtic als documents de rehabilitació. Mr C. Kent – un Physiotherapist – pensa que la Mrs Margaret no millora degut al

tractament mèdic que porta i a una dificultat cognitiva. Decideix tenir accés sistemàtic a la avaluació cognitiva del MDE i demana permís per llegir els documents que contenen la teràpia.

Solució Adoptada: S’afegeixen dues noves propietats a les SubAPOs, que faciliten la validació de

les personalitzacions: - readsPendingToAdd s’activa quan l’usuari utilitza la ATAPO per a fer una

petició d’un document. - readsTemporal s’activa quan el PC autoritza el seu accés.

Aquesta solució és més apropiada ja que no modifica l’estructura de la BD, només

el codi de la DAL. Inclou noves relacions a la SubAPO per a emmagatzemar dades personalitzades. Per aquest motiu és la solució adoptada.

La personalització és temporal. L’usuari ha de poder eliminar el seu accés a la

lectura només d’aquells documents dels quals ha demanat accés addicional. Aquest canvi en la SubAPO també ha de ser notificat al PC.

És necessari presentar els documents dividits en grups segons el següent criteri: - Documents existents a la SubAPO: Són els documents que ja conté la SubAPO i que

pot accedir l’actor segons l’ontologia general. Aquests documents no es poden eliminar de la SubAPO.

- Documents temporals afegits a la SubAPO amb anterioritat: Són els documents que s’han afegit en una personalització, aquests documents passen a ser com els documents existents però sí que es poden eliminar de la SubAPO.

- Documents pendents d’afegir: Són els documents que un actor concret ha afegit a la SubAPO i estan pendents de la seva validació. Un cop validats aquests documents passen a ser documents temporals. Aquests documents es poden eliminar de la SubAPO si no han estat validats.

- Documents pendents d’eliminar: Són els documents temporals que un actor ha eliminat de la seva SubAPO i estan pendents de la seva validació. Un cop validats s’eliminen de la SubAPO.

- Documents no existents: Són la resta de documents que conté l’ontologia general i segons aquesta l’actor no pot accedir. Aquests documents són els que pot afegir a la seva ontologia i passen a ser documents pendents d’afegir.


46

Per poder distingir aquests diferents tipus de documents s’han definit les següents propietats pels documents:

Tipus de document Propietat Propietat inversa Existents reads

readsSometimes isReadBy isReadSometimes

Temporals readsTemporal isReadTemporalBy Pendents d’afegir readsPendingToAdd isReadPendingToAdd Pendents d’eliminar readsPendingToDel isReadPendingToDel

Taula 6. Propietat i propietat inversa segons el tipus de document.

Es llegeixen tots els documents de la SubAPO amb la funció getDocuments(SubAPO) que retorna una llista amb totes les classes fulla que pengen de la classe “Document”, utilitza crides recursives per detectar la jerarquia encara que canviï. Es classifiquen els documents segons el criteri de la Taula 5. Per la classificació s’ha d’utilitzar la propietat inversa que és la que pertany al document. Es llegeixen els documents no existents amb la funció getDocuments(APO), en aquest cas obtenim la llista de tots el documents de l’ontologia general excepte els que ja hem obtingut a l’anterior pas. Es presenten tots els documents ja classificats.

Els possibles moviments entre tipus de documents són:

- De no existents a pendents d’afegir. - De pendents d’afegir a no existents. - De temporals a pendents d’eliminar. - De pendents d’eliminar a temporals.

Els documents existents no es poden moure.

5.4.2 Personalització d’Accions

El conjunt d’accions possibles a ser realitzades pel actors estan estrictament definides al model de K4CARE. En aquest model, hi ha algunes accions que poden ser realitzades per més d’un tipus d’actor. Acords entre actors poden portar a una distribució de tasques per un període de temps [18]. A continuació es mostrarà mitjançant un exemple les diferents possibles solucions que es van plantejar a aquest problema:

El Dr Kildare – un PC – està molt ocupat organitzant el servei. Per aquesta raó,

decideix que – per un període de temps – ell realitzarà només aquelles accions (administració) que no poden ser fetes per ningú més.

Els Doctors (no PCs), han de realitzar accions mèdiques; en cas de necessitat, poden també realitzar accions de la Infermera. Per exemple, el Dr Jeckill està molt ocupat i decideix no realitzar accions d’Infermeria. Tot i així, el Dr Zivago sap que al centre de HomeCare hi ha problemes ja que tres infermeres estan malaltes. Llavors decideix realitzar ell mateix accions d’Infermeria per als seus pacients.


47

Una HN ha de fer accions d’organització però li està permès realitzar accions de les Nurses. Per exemple, la HN Ms Poppins sap que el mes que ve les infermeres estaran molt ocupades amb pacients molt malalts; decideix que durant aquest període farà algunes de les cures de les Nurses.

Solució Adoptada: Solucionar el problema de la mateixa manera que el document és personalitzat. Permetre a l’usuari que pugui eliminar-se accions (o desactivar-les). El PC o la HN ho autoritza. Això s’implementarà afegint noves propietats a la SubAPO: - doesPendingToDel: petició de l’usuari. - removedTemporal: si és autoritzada.

Aquesta solució sembla més apropiada ja que segueix el model d’autorització. Només el codi de la DAL és modificat. I totes les personalitzacions d’accions per part dels usuaris són validades pel PC. És similar a la solució de la personalització de documents. Aquesta va ser la solució adoptada.

La personalització d’accions consisteix en que un actor concret no realitzi una o varies accions de les que pot fer, per tant només es poden treure accions de la seva SubAPO, en canvi no pot afegir cap acció nova.

Llavors les accions estan dividides en quatre grups: - Accions existents a la SubAPO: Són les accions que ja conté la SubAPO i que

pot fer l’actor segons l’ontologia general. Aquestes accions es poden treure de la SubAPO dintre de la personalització.

- Accions tretes temporals: Són accions que han estan tretes amb anterioritat de la SubAPO degut a que l’actor concret no realitza aquesta acció. Són les accions que s’han tret en una personalització, aquests accions poden tornar a ser afegides posteriorment.

- Accions pendents d’eliminar: Són les accions que un actor ha eliminat de la seva SubAPO i estan pendents de la seva validació. Un cop validades s’eliminen de la SubAPO.

- Accions pendents d’afegir: Són les accions temporals que un actor concret havia eliminat de la SubAPO i ara vol tornar a afegir i estan pendents de la seva validació. Un cop validats aquestes accions passen a ser accions existents.

Per poder distingir aquests diferents tipus d’accions s’han definit les següents

propietats per les accions:

Tipus d’Acció Propietat Propietat inversa Existents does isSubjectBy Temporals removedTemporal isRemovedTemporalBy Pendents d’afegir doesPendingToAdd isSubjectPendingToAdd Pendents d’eliminar doesPendingToDel isSubjectPendingToDel

Taula 7. Propietat i propietat inversa segons el tipus d’acció.


48

5.4.3 Validació

La validació d’una personalització de documents consisteix en canviar la propietat

que afecta al document, una SubAPO pendent de validació té documents pendents de validar i passen a tenir l’estat validat segons la següent relació:

Pels documents:

Propietat documents pendents de validar Propietat documents validats isReadPendingToAdd isReadTemporalBy isReadPendingToDel S’elimina de la SubAPO

Pels actors: Propietat actor pendent de validar Propietat actor validat readsPendingToAdd readsTemporal readsPendingToDel S’elimina de la SubAPO

De forma semblant, la validació d’una personalització d’accions consisteix en canviar la propietat que afecta a l’acció, una SubAPO pendent de validació té accions pendents de validar i passen a tenir l’estat validat segons la següent relació:

Per les accions:

Propietat accions pendents de validar Propietat accions validades isSubjectPendingToAdd S’afegeix a la SubAPO isSubjectPendingToDel isRemovedTemporalBy

Pels actors: Propietat actor pendent de validar Propietat actor validat doesPendingToAdd S’afegeix a la SubAPO doesPendingToDel removedTemporal


49

6 ATAPO (Automatic Tailoring of the APO)

6.1 Descripció de l’eina ATAPO

ATAPO és una interfície gràfica per la creació automàtica i personalització de SubAPOs a partir d’un Actor o a partir d’una Care Unit. Un cop creada la SubAPO es pot visualitzar la jerarquia de classes resultant i les propietats i restriccions relacionades amb cada classe.

L’eina facilita el procés de personalització descrit al capítol anterior. La SubAPO per actor es pot personalitzar afegint documents que un actor concret cregui que ha d’afegir a la seva vista particular, o bé, eliminant accions que un actor concret no realitzarà dintre de les seves funcions. Aquesta personalització haurà de ser validada per un usuari autoritzat abans de ser definitiva. Els documents i accions afegits o eliminats de la SubAPO del actor es podran treure o afegir un cop l’actor cregui que ja no els necessita o bé que els torna a necessitar, també prèvia validació.

Per accedir a l’eina, l’usuari s’haurà de validar amb identificador d’usuari i

contrasenya, els usuaris autoritzats podran accedir a la pestanya de validacions per aprovar les personalitzacions que actors concrets hagin fet sobre la seva SubAPO.

L’eina ATAPO ha estat programada en llenguatge Java. De moment, la validació es fa contra una base de dades local, però el codi està implementat de forma que es pugui substituir per la base de dades del projecte K4CARE i s’hi accedeixi a través de la Data Abstraction Layer.

Figura 12. ATAPO – Validació d’usuaris Quan la validació es faci dins el sistema K4CARE, es podrà saber de forma

automàtica quin tipus d’actor correspon a l’usuari dins el sistema. A partir del tipus d’actor, l’eina ATAPO oferirà diferents funcionalitats a l’usuari.

Per exemple, un usuari només podrà generar la SubAPO corresponent al seu tipus d’actor, i només certs tipus d’actors estaran autoritzats a obtenir SubAPOs de certes


50

Care Units. D’altra banda, la validació de sol·licituds de personalització de perfils només estarà accessible al Physician in Charge i a la Head Nurse.

6.2 Funcionalitats de l’eina ATAPO

ATAPO (Automatic Tailoring of the APO) és una eina amb una interfície gràfica fàcil, que proporciona la creació de SubAPOs automàtica de la Actor Profile Ontology per a un Actor o Care Unit. Està programada en Java.

Les funcionalitats bàsiques de l’eina són la creació de SubAPOs per a un Actor o

Care Unit, la visualització d’aquestes SubAPOs mostrant les propietats i restriccions, personalització de les SubAPOs (només les d’actors), i la validació per part del PC o HN d’aquestes personalitzacions.

La ATAPO és una eina independent i que no està integrada a la plataforma web

del K4CARE. S’instal·la i executa en qualsevol ordinador i ha de ser possible realitzar Tailoring. Tot i això, s’ha implementat de manera que la interfície està separada de les funcions de Tailoring (procés per a generar una SubAPO). Com a resultat, les funcions es poden utilitzar en una altra interfície o aplicació.

La creació de SubAPOs per un Actor o Care Unit estan basades en crides a funcions: CreateSubAPO(Entity) o CreateSubAPO(CareUnit). Les crides es realitzen dintre la creació de la SubAPO.

Això és un prototipus de l’eina ATAPO. En aquest moment, no hi ha cap connexió

entre la base de dades de K4CARE per a la validació d’usuaris o per a l’emmagatzematge de SubAPOs. Aquests processos són simulats i executats a l’ordinador local. Tot i així, és dissenyat i preparat per a ser connectat amb la resta de fonts de K4CARE automàticament.

L’ATAPO serà una eina independent. No tindrà una interfície web. Serà una

aplicació que l’usuari podrà instal·lar al seu ordinador. Accedirà a la BD de K4CARE utilitzant un instància de la DAL i connexió a Internet. L’ús de ATAPO serà restringit als usuaris registrats dins la BD de K4CARE. La BD ha estat dissenyada per a emmagatzemar referències a SubAPOs personals. La ATAPO només utilitzarà la informació global de la APO i la informació particular de la SubAPO.

6.2.1 Creació de les SubAPOs

L’aplicació detecta els Actors i les Care Units presents en l’ontologia general (APO.owl). Les funcions getActorList(APO) i getCareUnitList(APO), que es troben al codi de Tailoring d’Actor i Tailoring de Care Unit, respectivament, retornen les llistes dels actors i Care Units presents en la APO mitjançant crides recursives, d’aquesta manera pot detectar nous elements o jerarquies que s’incorporin a la APO.

Es pot escollir qualsevol actor o Care Unit i crear la seva SubAPO.


51

Per la creació de la SubAPO utilitza la funció: Wrapper performTailoring(String entityName) que crea una SubAPO a partir d’una entitat descrita en els apartats anteriors, d’una forma transparent a l’usuari.

Implementa el patró Observer per tal de separar la vista (interfície) i el controlador (funcions) d’aquesta manera es poden utilitzar les funcions de Tailoring amb qualsevol altre tipus d’interfície.

La crida a les funcions es fa mitjançant threads independents per evitar l’aturada de l’aplicació mentre s’executen les funcions.

Les SubAPOs creades es guarden en un fitxer en format OWL i el nom del fitxer te el format: IdentificadorUsuari_tipusActor_APO.OWL per els actor o bé IdentificadorUsuari_tipusCareUnit_APO.OWL per les Care Units.

Figura 13. ATAPO – Creació de SubAPOs

6.2.2 Visualització de les SubAPOs

Es pot visualitzar la jerarquia de qualsevol SubAPO prèviament creada, es carrega el fitxer OWL generat i es genera el Wrapper com si fos l’ontologia general ja que té el mateix format, a partir d’aquí s’utilitzen les funcions del Wrapper per poder presentar les propietats i restriccions associades a cada classe.


52

Figura 14. ATAPO – Visualitzador de SubAPOs

6.2.3 Personalització de documents L’eina permet a l’usuari afegir-ne o bé eliminar-ne documents que, per qualsevol

motiu, vol llegir o escriure o al contrari. La llista de My Documents són els que conté el propi usuari, i aquests poden passar a la llista de ser pendents d’esborrar.

D’altra banda, un usuari es pot afegir un document que abans no tenia, i passarien a la llista de pendents de ser afegits.

Quan s’afegeix un document a la SubAPO, aquest s’incorpora a la jerarquia de

classes, d’això s’encarrega la funció addDocumentToSubAPO(MyClass document) que afegeix el document passat per paràmetre a la SubAPO, necessita de crides recursives, ja que si el nivell de jerarquia per sobre del document a afegir no existeix a la SubAPO, s’afegirà també amb la mateixa funció, d’aquesta forma es manté l’estructura de l’ontologia general.

Només s’elimina un document de la SubAPO quan la petició d’eliminació ha estat validada és dir quan el document passa de tipus pendent d’eliminar a no existents. Per eliminar un document i per aconseguir conservar la consistència de la SubAPO la solució adoptada és la de crear de nou la SubAPO i afegir els documents temporals, pendents d’afegir i pendents d’eliminar, d’aquesta manera s’evita que amb el pas del temps puguin haver inconsistències i es regeneri la SubAPO periòdicament.

Finalment s’incorpora al document la propietat que el distingirà segons la taula x,

per fer això es crida la funció addDocumentsAndProperty(ArrayList<MyClass> listDocs, String property, String inverseProperty) que afegeix una llista de documents, una propietat i la seva propietat inversa a la SubAPO. El document tindrà la propietat inversa i l’actor si no tenia aquesta propietat se li afegeix i si la tenia s’afegeix el document a la llista de classes de la propietat, (el document és llegit per un actor en canvi l’actor pot llegir varis documents).


53

Figura 15. ATAPO – Personalització de documents

6.2.4 Personalització d’accions

Inicialment, es llegeixen totes les accions de la SubAPO amb la funció

getActions(SubAPO) que retorna una llista amb totes les classes fulla que pengen de la classe “Action”, utilitza crides recursives per detectar la jerarquia encara que canviï.

Es classifiquen les accions segons el criteri de la taula anterior. Per la classificació s’ha d’utilitzar la propietat inversa que és la que pertany a l’acció.

Els possibles moviments entre tipus d’accions son:

- De existents a pendents d’eliminar. - De pendents d’eliminar a existents. - De temporals a pendents d’afegir - De pendents d’afegir a temporals

Quan s’elimina una acció, aquesta no desapareix físicament de la SubAPO, si no

que es canvien les propietats que afecten a l’acció i a l’actor segons la taula x, per fer això es crida a la funció changePropertyByActions(ArrayList<MyClass> listDocs, String property, String inverseProperty) la qual canvia a les propietats passades per paràmetre cadascuna de les accions de la llista.


54

Figura 16. ATAPO - Personalització d’accions

Un cop fets tots els canvis sobre la SubAPO, (personalitzacions) el fitxer es

guarda en el format: IdentificadorUsuari_tipusActor_APO_MOD.OWL, d’aquesta forma es podran identificar les SubAPOs en format owl que hagin estat personalitzades i que estiguin pendent de validació.

6.2.5 Validació de les SubAPOs

Es mostren totes les SubAPOs que tinguin pendent de validació alguna personalització de documents o d’accions que els actors hagin fet sobre les seves SubAPOs. Les SubAPOs amb canvis pendents de validacions tenen el format: IdentificadorUsuari_tipusActor_APO_MOD.OWL.


55

Figura 17. ATAPO – Validació de SubAPOs

Un cop fets totes les validacions sobre la SubAPO, el fitxer es guarda en el format: IdentificadorUsuari_tipusActor_APO.OWL, que és el format normal de la SubAPO, només passarà a tenir aquest format en el cas que es facin totes les validacions, si resten validacions per fer, el fitxer resultant continua tenint el format: IdentificadorUsuari_tipusActor_APO_MOD.OWL.



56

Resum de les principals funcions implementades necessàries per la personalització de SubAPOs de l’eina ATAPO:

Wrapper performTailoring(String entityName) Crea una SubAPO a partir de la entitat passada per paràmetre i retorna una

referència a la SubAPO en format Wrapper. ArrayList<MyClass> getActorList(Wrapper APO) Retorna una llista amb tots els actor que hi ha a l’ontologia passada per paràmetre. ArrayList<MyClass> getCareUnitList(Wrapper APO) Retorna una llista amb totes les Care Unit que hi ha a l’ontologia passada per

paràmetre. createModel (DefaultTreeModel model,DefaultMutableTreeNode root) Genera un arbre de classes en el format d’arbre de Java. getClass(DefaultTreeModel model, DefaultMutableTreeNode son) Funció recursiva utilitzada per createModel que va creant els nodes i branques en

el format d‘arbre de Java. ArrayList<MyClass> getDocuments(MyClass document) Funció recursiva que retorna una llista amb tots els documents que pengen de la

classe passada per paràmetre. ArrayList<MyClass> getActions(MyClass action) Funció recursiva que retorna una llista amb totes les accions que pengen de la

classe passada per paràmetre. addDocumentsAndProperty(ArrayList<MyClass> listDocs, String property, String

inverseProperty) Afegeix la llista de documents a la estructura de la SubAPO, amb la propietat

inversa passada per paràmetre, la propietat i els documents s’afegeixen a l’actor. changePropertyByActions(ArrayList<MyClass> listDocs, String property, String

inverseProperty) Canvia les propietats de la llista d’accions, amb la propietat i propietat inversa

passada per paràmetre. addDocumentToSubAPO(MyClass document) Funció recursiva que afegeix a la SubAPO el document passat per paràmetre,

incorporant-lo a la jerarquia creant les branques necessàries per mantenir l’estructura de l’ontologia general.

addActionToSubAPO(MyClass action) Funció recursiva que afegeix a la SubAPO l’acció passada per paràmetre,

incorporant-la a la jerarquia creant les branques necessàries per mantenir l’estructura de l’ontologia general.


57

6.3 Manual d’usuari per a l’eina ATAPO

Per iniciar l’aplicació, executar l’arxiu: ATAPO en el mateix directori on es trobi

l’ontologia general que ha de tenir el nom APO.owl. Un cop executada l’aplicació es mostra la pantalla de validació:

Figura 19. ATAPO – Validació d’usuaris

S’ha d’introduir el nom d’usuari i password vàlids per poder accedir a l’aplicació,

polsant el botó “validate” o prenen la tecla enter s’accedeix a l’aplicació:

Figura 20. ATAPO - Creació de SubAPOs


58

Creació de SubAPOs Es pot escollir entre crear un SubAPO per un Actor o per una Care Unit

seleccionant la pestanya corresponent. La tercera pestanya és per realitzar validacions de SubAPOs.

Es selecciona l’Actor o la care unit que es vol crear la SubAPO. Un cop seleccionat, s’activa el botó “create” i es suggereix un nom per guardar,

que serà el directori actual més “IdentificadorUsuari_tipusCareUnit_APO.OWL”, es pot canviar polsant el botó i es podrà escollir el directori on es guardarà la SubAPO.

Si ja existeix la SubAPO dintre del directori s’activa el botó “Show”, a cada nova

selecció, s’activa o desactiva el boto “Show” segons si existeix o no la SubAPO, també es pot cercar manualment amb el botó .

En la finestra Process es mostra informació sobre els processos efectuats, si es

polsa el boto “Clear” s’esborra aquesta informació.

Figura 21. ATAPO – Selecció d’Actor/Care Unit

Si es polsa el boto “Create” es crea automàticament la SubAPO per l’Actor o Care Unit que estigui seleccionat i es guarda en el directori especificat amb el format de nom “IdentificadorUsuari_tipusCareUnit_APO.OWL”.

Quan s’ha creat la SubAPO ho indica en el pannell Process: “The SubAPO has been created”:


59

Figura 22. ATAPO – Procés de creació

Polsant el botó “Exit” o tancant la finestra, finalitza l’aplicació.

Visualització de SubAPOs Al polsar el botó “Show” mostra com ha quedat la SubAPO:

Figura 23. ATAPO – Visualitzador de SubAPOs


60

Es pot navegar per l’estructura de la SubAPO, si es selecciona una classe es

mostren les seves propietats i restriccions:

Figura 24. ATAPO – Visualitzador de propietats/restriccions

Personalització de SubAPOs Polsant el botó “Actions Edition” s’entra en la pantalla personalització d’accions:

Figura 25. ATAPO – Personalització d’accions


61

Polsant el botó “Documents Edition” s’entra en la pantalla de personalització de documents:

Figura 26. ATAPO – Personalització de documents

Es treballa de igual forma tant en la pantalla de personalització de documents com

d’accions. Dintre d’aquesta pantalla es poden fer els moviments de documents permesos: Polsant el botó: si hi ha seleccionat un document de la llista de documents

existents, es passa el document seleccionat de la llista documents existents a la llista de documents pendents d’afegir.

Amb el mateix botó, si hi ha seleccionat un document de la llista documents pendents d’eliminar, es passa el document a la llista de documents temporals. Només pot haver documents seleccionats d’una llista (si es selecciona un document d’una llista deixen d'estar seleccionats els documents de les demés llistes).

Polsant el botó: si hi ha seleccionat un document de la llista de documents

temporals, es passa el document seleccionat de la llista documents temporals a la llista de documents pendents d’eliminar.

Amb el mateix botó, si hi ha seleccionat un document de la llista documents pendents d’afegir, es passa el document a la llista de documents no existents.

D’aquesta forma s’aconsegueixen tots els moviments permesos per a un actor en

la personalització de la seva SubAPO.


62

No es realitzen els canvis fins que es polsa el botó “save”, en aquest moment es guarden els canvis efectuats a la SubAPO.

Polsant el botó “back” , o bé tancant la finestra, es torna a la pantalla inicial. Validació de SubAPOs Si es vol validar una SubAPO s’accedeix per la tercera pestanya de la pantalla

inicial (Validation):


En aquesta pantalla es llistes totes les SubAPOs que tinguin pendent alguna

validació, es mostra el identificador de l’actor i el tipus d’actor, es selecciona la SubAPO que es vulgui validar, i es polsa el botó “Documents Validation” si es volen validar documents o be, “Actions validation” si es volen validar accions.

Polsant el botó “Documents Validation” s’accedeix a la pantalla de validació de

documents


63

Figura 28. ATAPO – Validació de SubAPOs (documents)

Es pot seleccionar un document pendent d’afegir i amb el boto passar-lo a

document temporal, o be es pot seleccionar un document pendent d’esborrar i eliminar-lo de la SubAPO.

El botó s’utilitza en cas que un document es trobi a Documents Pending to be added, però no es validin, tornaran a la llista All existing Documents, ja que aquell actor no podrà tenir el document seleccionat.

El botó s’utilitza quan un document que es troba a la llista dels Documents Pending to be removed, però que no poden ser eliminats per qualsevol motiu. Aquests retornen a la llista de Temporal Documents que és on estaven inicialment.

No es realitzen els canvis fins que es polsa el botó “save”, en aquest moment es guarden els canvis efectuats a la SubAPO.

Polsant el botó “Actions Validation” de la pantalla anterior, s’accedeix a la

pantalla de validació ‘accions:


64

Figura 29. ATAPO – Validació de SubAPOs (accions)

Es pot seleccionar una acció pendent d’eliminar i amb el boto passar-la a

acció eliminada temporalment, o bé es pot seleccionar una acció pendent d’afegir i afegir-la a la SubAPO.

El botó s’utilitza en cas que una acció es trobi a Actions Pending to be removed, però no es validin, tornaran a la llista Temporal Removed Actions.

El botó s’utilitza quan una acció que es troba a la llista de les Actions Pending to be added, però que no poden ser afegides per qualsevol motiu. Aquestes retornen a la llista Temporal Removed Actions que és on estaven anteriorment.

No es realitzen els canvis fins que es polsa el botó “save”, en aquest moment es

guarden els canvis efectuats a la SubAPO. Només es pot sortir de la aplicació des de la pantalla inicial.


65

7 Joc de proves

El procediment per realitzar les proves i verificacions de resultats consisteix en generar els fitxers OWL de les SubAPOs amb l’eina ATAPO i comprovar que siguin correctes obrint els mateixos fitxers amb l’eina Protégé, comparant que les sortides donades per les dues eines siguin iguals, en quant a estructura, propietats i restriccions de cada element de l’estructura, i que s’hagin realitzat els canvis que es pretenen sobre l’ontologia o sobre les SubAPOs. Així doncs, es realitzen proves sobre la creació de SubAPOs, personalització de documents, personalització d’accions, i validació de personalització de documents i d’accions.

Proves Creació de SubAPOs: Aquesta prova s’ha realitzat per cadascun dels actors que hi ha en l’ontologia, es

comprova l’estructura de la jerarquia de classes, dintre d’aquesta es comproven que tingui els documents, accions i serveis que l’actor pot accedir i per cadascun es comprova que tingui les restriccions i propietats que tenen a l’ontologia.

En aquest exemple es mostra la creació de una SubAPO per l’entitat Nurse i es mostren els documents que pot escriure.

Figura 30. ATAPO – Mostra de SubAPOs


66

Paral·lelament obrim el fitxer owl generat i l’obrim amb l’eina Protégé per realitzar les comprovacions descrites. Aquí es pot veure, com exemple, el detall de la mateixa propietat: els documents que Nurse pot escriure.

Figura 31. Protégé – SubAPO de la Nurse

Proves personalització de documents: Es comprova que el document afegit a la SubAPO s’hagi integrat correctament en

l’estructura de l’actor, en aquest cas s’ha afegit el document “DecisionDocument” a la SubAPO de l’entitat Nurse:

Figura 32. ATAPO – Edició de Documents


67

Un cop es salva la SubAPO s’obre el fitxer OWL generat amb el Protégé i es

comproven els resultats:

Figura 33. Protégé – Propietats de la Nurse

L’actor Nurse llegeix el document “DecisionDocument” amb la propietat pendent

de validar, ja que encara no ha estat validada la personalització i el document s’ha integrat a l’estructura de la SubAPO:


68

Figura 34. ATAPO – Inversa de la propietat

Proves Validació de SubAPOs: Es comprova que si s’ha fet una personalització, la SubAPO apareix a la pantalla

de validació (continuem amb l’exemple de personalització de l’entitat Nurse):


Es realitza la validació i es salva la validació:


69

Figura 36. ATAPO – Validació de documents

La SubAPO ha quedat validada per la personalització de documents, el document passa a tenir la propietat Temporal Document, obrim el fitxer OWL resultant amb el Protégé:

Figura 37. Protégé – Documents de la Nurse


70

L’actor Nurse pot llegir el document “DecisionDocument” per la propietat “readsTemporal”, veiem el document:

Figura 38. Protégé – Propietats dels Documents

Aquest exemple serveix per mostrar el procediment de proves realitzades, aquesta

prova es realitza per cada actor i en cada personalització i validació tant de documents com d’accions, el sistema és el mateix i es comprova que l’estructura de la SubAPO del fitxer OWL resultant sigui la correcta segons l’estructura que marca l’ontologia i els canvis realitzats.

Les SubAPOs es creen de nou cada cop que hi ha una personalització o validació i s’incorporen els documents o s’eliminen les accions d’anteriors personalitzacions i validacions, d’aquesta forma no es deteriora l’estructura o la consistència de la SubAPO per fer més o menys personalitzacions o validacions, cada cop que es realitza un canvi en una SubAPO és com si fos el primer cop que es fa sobre aquesta.


71

8 Conclusions i valoració

La realització d’aquest PFC ha estat des de el primer moment un repte. Per una banda entendre l’estructura de les ontologies i el model del projecte europeu K4CARE, i per l’altre l’objectiu del nostre PFC: la creació de SubAPOs a partir d’una ontologia i un cop creades, com fer la personalització i validacions de personalitzacions.

El primer objectiu a realitzar va ser comprovar si era possible la creació de

SubAPOs per actor. Va ser una gran satisfacció quan vam crear la primera SubAPOs per un actor, a partir d’aquest punt s’obria tot el camí que hem recorregut realitzant aquest PFC. Si dividíssim el PFC en dos parts el punt mig el marca aquest moment.

El segon pas a afrontar ha estat fer la personalització de SubAPOs. Per realitzar

aquesta tasca ens hem hagut de ficar de ple dins de l’estructura de les ontologies, ja que els canvis realitzats en una classe tenen efectes col·laterals en altres classes degut a la interrelació existent entre elles. Comprendre totes aquestes relacions ens ha portat a conèixer a fons l’estructura de les ontologies. Aquest coneixement ens dóna accés a la interpretació d’aquesta ontologia en particular i de qualsevol ontologia en general, sent aquest un món en ple desenvolupament dins de la intel·ligència artificial.

Estem satisfets amb el treball que hem fet desenvolupant l’eina ATAPO ja que

utilitza d’una forma transparent i automatitzada totes les funcions que hem implementat per la creació i personalització d’ontologies amb una interfície gràfica fàcil d’utilitzar.

Amb la creació d’aquest PFC, es vol aconseguir que la plantilla mèdica pugui fer ús d’aquesta eina de la manera més fàcil possible. La interfície gràfica de què disposa permet als usuaris entendre a cop d’ull la funcionalitat de l’eina de particularització d’ontologies mèdiques. ATAPO facilita als usuaris la personalització del sistema K4CARE de forma controlada i sempre validada pels encarregats de la plantilla d’assistència mèdica.

La dependència de les decisions per part dels metges ha dificultat la creació de

ATAPO, ja que totes les funcionalitats han hagut de ser definides i controlades pels metges. Aquest fet ha fet que en moltes ocasions, no poguéssim avançar o bé canviar coses degut a la incertesa dels clients.

S’han realitzat diversos estudis per determinar la millor solució a adoptar. S’ha

presentat, acceptat i publicat un article referent a la particularització d’ontologies per Actor en la 18th European Conference on Artificial Intelligence (ECAI'08), Workshop Knowledge Management for Healthcare Processes, Patras, Greece, 2008. Aquest article és publicat per Batet, M.; Gibert, K., Valls, A i Sergio Martínez i Ester Morales (veure Annex 11). La publicació d’aquest article ha estat un premi a la feina realitzada.

Una motivació afegida és la realització del PFC dins el marc del projecte

K4CARE, tota implementació i documentació ha estat realitzada pensant en la seva publicació dins el projecte, i en congressos [18], aprenent així la dinàmica de treball d’un projecte d’aquesta magnitud i complexitat.

La realització del PFC en equip ha estat una tasca positiva, ja que en aquells

camps en que un dels membres tenia mancances, l’altre no en tenia i per tant ho podia


72

resoldre. Això ha fet que tant un com l’altre aprengués coses noves. A més, en aquells moments més difícils i en que semblava impossible seguir endavant, hi ha hagut el màxim suport i ànims. Treball en equip és la millor forma de treballar en el desenvolupament de projectes amb aquesta complexitat.

Un aspecte que ens ha resultat gairebé impossible de dur a terme ha estat la repartició del treball i la divisió en dues parts o dos PFCs, ja que s’ha treballat completament en equip. Tot i això, s’han diferenciat clarament dues parts.

La realització del treball en cas d’un sol membre, hagués estat molt difícil i

gairebé impossible degut a les necessitats d’entrega de solucions i documentació que s’han anat marcant al llarg del curs.

Volem agrair als nostres directors de projecte i especialment a: Dra. Aïda Valls i

Montserrat Batet la seva col·laboració, sense la qual, no hagués estat possible la realització d’aquest PFC.


73

9 Treball futur

Els objectius bàsics de la creació de SubAPOs i personalització de SubAPOs s’han

assolit de forma satisfactòria. Es pot afirmar que poden donar-se per implementats en el cas d’actors i Care Units. Les validacions també han estat implementades i provades, i tots els casos estan controlats, de forma que qualsevol modificació en una SubAPO ha d’estar verificada pel responsable corresponent.

Queda pendent realitzar el control d’usuaris que poden executar l’eina, així com els permisos que tenen sobre les diferents opcions. Per exemple, en aquests moments es poden validar els canvis per tothom independentment del rol de l’usuari.

Creiem que aquesta metodologia ha obert altres vies de treball, com la creació

d’altres altres tipus de SubAPOs, com per exemple per pacient, en que es pogués crear i personalitzar SubAPOs segons el tipus de pacient, que recullin les peculiaritats individuals de cada pacient.

La continuació natural del nostre PFC és la integració total de l’eina ATAPO dins

del model K4CARE. Per fer-ho cal canviar la implementació de l’eina ATAPO per a que funcioni amb applets que puguin ser executats directament en el navegador d’Internet. Això ara mateix no és possible degut a que l’embolcall Wrapper que utilitza ATAPO utilitza alhora les llibreries Jena d’accés a arxius OWL, aquestes llibreries “pesen” massa per ser incorporades a la DAL. La solució passa per implementar un Wrapper per accedir a fitxers OWL directament o bé a través d’una OWL-API que pugui ser incorporada a la DAL, sense utilització de les llibreries Jena, la utilització de l’eina ATAPO un cop implementat el nou Wrapper seria pràcticament automàtica.

En altres àmbits fora del projecte K4CARE, es podrien incorporar les tècniques de

creació i personalització de SubAPOs a altres menes d’ontologies o en altres dominis.


74

10 Referències

[1] Campana, F.; Annicchiarico, R. & Riaño, D. . Knowledge-Based HomeCare eServices for an Ageing Europe. Deliverable D01,EU (2007), http://www.k4care.net/fileadmin/k4care/public_downloads/K4C_Model_D01.rar

[2] Gibert, K., Valls, A., Casals, J., Sample APOs, Deliverable D04.2, EU (2007) [3] Sánchez, D., Gibert, K., Valls, A., Casals, J., Tehcnical specification of the API for the

APO-v2, Internal document of the K4CARE project, 2007 [4] Real, F., Riaño, D., Bohada, J.: Automatic generation of formal intervention plans in the

sda* representation model. 20th IEEE International Symposium on COMPUTER-SCIENCE SYSTEMS (CBMS) (2007 in press)

[5] Ehrenfeld, M.: Nursing and Home Care in Europe, Int. Nurs. Rev. 45, 2, (1998) [6] Riaño, D.: The sda model v.1.0: a set theory approach. Report DEIMRT- 07-001, Dept. of

Computer Engineering and Maths, Universitat Rovira i Virgili, Tarragona, Spain (2007 [7] Wooldridge, M.: An introduction to multiagent systems. Wiley (2002) [8] Batet, M., Gibert, K., Valls, A.: The Data Abstraction Layer as

Knowledge Provider for a Medical Multi-agent System. Knowledge Management for Health Care Procedures, From Knowledge to Global Care, Lecture Notes on Artificial Intelligence, vol. 4924, D. Riaño et al.. Eds. Springer-Verlag. Amsterdam, 2008. pp. 87-100

[9] Studer, R. Benjamins, V.R. and Fensel, D.: Knowledge Engineering: Principles and Methods. IEEE Transactions on Data and Knowledge Engineering, 25 (1-2). 1998. 161-197

[10] Guarino, N., Giaretta, P., Ontologies and Knowledge Bases: Towards a terminological Clarification. In: Mars N (ed) Towards Very Large Knowledge Sharing (KBKS’95). University of Twente, Enschede, The Netherlands. IOS Press, Amsterdam, The Netherlands, pp25-32 (1995).

[11] Gómez-Pérez, A., Fernández-López, M. and Corcho, O.: Ontological Engineering, 2nd printing. Springer Verlag. ISBN: 1-85233-551-3 (2004)

[12] Dean, M., Schreiber, G., OWL Web Ontology Language Reference. W3C Working Draft, http://www.w3.org/TR/owl-ref/

[13] Noy, NF., Fergerson, RW., Musen, MA.: The knowledge model of Protégé-2000: Combining interoperability. In: Dieng R, Corby O (eds) 12th International Conference in Knowledge Engineering and Knowledge Management (EKAW’00). France. LNAI 1937, Springer-Verlag, (2000) 17-32.

[14] Casals, J., Gibert, K., Valls, A.: Enlarging a medical actor profile ontology with new care units. Knowledge Management for Health Care Procedures, From Knowledge to Global Care, Lecture Notes on Artificial Intelligence, vol. 4924, D. Riaño et al.. Eds. Springer-Verlag. Amsterdam, 2008. pp. 101-116

[15] Valls, A., Gibert, K., Casals, J., ISA: Intelligent Service Adder v.1. User’s Guide. Research Report, Department of Computer Science and Mathematics, Universitat Rovira i Virgili, Spain, DEIM-RR-07-005 (2007)

[16] Description of Work, Annex I, Sixth Framework programme. Specific Targeted Research or Innovation Project. 2005.

[17] Casals, J.: European HC model. Design and implementation of the APO. Master’s thesis, Escola Técnica Superior d’Enginyeria, Universitat Rovira i Virgili, Campus Sescelades, Av. Pasos Catalans 26 . Sant Pere i Sant Pau (43007), Tarragona. Catalunya (2007)

[18] Batet, M.; Gibert, K., Valls, A., Martínez, S., and Morales, E.: Tailoring of the Actor Profile Ontology in the K4Care Project. 18th European Conference on Artificial Intelligence (ECAI'08), Workshop Knowledge Management for Healthcare Processes, Patras, Greece, 2008.

http://www.k4care.net/fileadmin/k4care/public_downloads/K4C_Model_D01.rar

http://www.w3.org/TR/owl-ref/


75

11 Annexos Annex 1: Accions i Responsabilitats professionals de HCNS. Annex 2: Serveis de HCNS. Annex 3: Documents de HCNS. Annex 4: Procediments de HCNS. Annex 5: Accions i Responsabilitats professionals de HCAS-R. Annex 6: Serveis de HCAS-R. Annex 7: Documents de HCAS-R. Annex 8: Procediments de HCAS-R. Annex 9: Knowledge-Based HomeCare eServices for an Ageing Europe. FP 6 Specific Targeted Research or Innovation Project Thematic Priority 2: “Information Society Technology”. ATAPO: Automatic Tailoring of the Actor Profile Ontology (v.1.0) . Annex 10: Javadoc del OWLWrapper. Annex 11: Batet, M.; Gibert, K., Valls, A., Martínez, S., and Morales, E.: Tailoring of the Actor Profile Ontology in the K4Care Project. 18th European Conference on Artificial Intelligence (ECAI'08), Workshop Knowledge Management for Healthcare Processes, Patras, Greece, 2008.

Disseny i implementació d’una eina per particularitzar...

Documents

Transcript of Disseny i implementació d’una eina per particularitzar...