We.Can Connect PPS2. Documentação Data: Páginas: 30 Acesso: Interno/Externo. Referência: Documentação 1.1 Versão: Co-promotor Líder: HIS

Transcrição

1 We.Can Connect PPS2 Documentação Data: Páginas: 30 Acesso: Interno/Externo Referência: Documentação 1.1 Versão: Co-promotor Líder: HIS Co-promotores: IPN; Meticube; UC; INOVAMAIS; UA; MediaPrimer; IT; Plux; TEGIS; Maisis; FEUP; First Solutions; Take the Wind; EDIGMA; Biosurfit; CRIAVISION; UM; Exatronic; UBI; Sinfic; INOV INESC INOVAÇÃO. Parceiros: PT Prime; ARSC; AVIDA; Hospital Infante D.Pedro; Rovisco Pais; HUC; ACSS; SSRAM.

2 Autores Nome Contacto Função Carlos Cardoso Autor Revisões Versão Autor(es) Descrição Data de Fim Direitos Copyright TICE.Healthy 2012 Todos os direitos de propriedade intelectual são pertença do TICE.Healthy. Nenhuma parte deste documento pode ser reproduzida, transmitida ou traduzida por qualquer meio sem a autorização escrita dos seus autores. Todas as marcas registadas usadas neste documento são propriedade dos respectivos donos. TICE.Healthy 2/34

3 Índice 1. INTRODUÇÃO OBJECTIVO ÂMBITO AUDIÊNCIA ORGANIZAÇÃO DO DOCUMENTO DESENVOLVIMENTO O QUE É UM ARQUÉTIPO Arquétipos Base UML ARQUÉTIPOS ARQUITETURA ATUAL REFERENCE INFORMATION MODEL Contexto RIM Dados Demográficos: Contexto do ato: API DOS SERVIÇOS ESTRUTURA DO ARQUÉTIPO EDIÇÃO DE ARQUÉTIPOS FLUXO EDIÇÃO E PERSISTÊNCIA DE ARQUÉTIPOS TIPOS BASE DEFINIÇÃO E ESTRUTURA ARQUÉTIPO BODY XML TEMPLATE IMPLEMENTAÇÃO JAVA JAVASCRIPT TICE.Healthy 3/34

4 Índice de figuras Figura 1 - Estrutura dos Arquétipos Base... 7 Figura 2 - Arquitetura... 8 Figura 3 - RIM Contexto Figura 4 - Estrutura RIM Figura 5 - API dos Serviços Figura 6 - Estrutura do Arquétipo Figura 7 - Edição de Arquétipos Figura 8 - Header blood pressure Figura 9 - Data blood pressure Figura 10 - Data Person State blood pressure Figura 11 - Protocol blood pressure Figura 12 - Interface blood pressure Figura 13 baseschema.xsd Figura 14 - Estrutura do body do arquétipo Figura 15 - Archetype XML Figura 16 - Extrato body definition Figura 17 - Extrato body description Figura 18 - Template protótipo - blood pressure Figura 19 - Cliente Rest Figura 20 - Ler body Figura 21 Ler Descrição Figura 22 - Conteúdo XML Figura 23 Contexto RIM Figura 24 - Serviço para a persistência no RIM Figura 27 - API JS - healthy Figura 28 - GET Archetype Figura 29 - setarchetype Figura 30 - setparticipations Figura 31 - setobservation Figura 32 - setobsarchetypecontext Figura 33 - POST Observation TICE.Healthy 4/34

5 1. Introdução 1.1. Objectivo O objetivo deste documento é auxiliar os outros parceiros em futuras implementações de aplicações que usem os arquétipos para a interoperabilidade entre sistemas. Podem encontrar no repositório, arquétipos já modelados que podem usar para os testes de persistência de informações no RIM Âmbito No âmbito do projeto TICE.Healthy o PPS2 We.Can Connect permitirá a interoperabilidade entre os diversos sistemas pessoais, privados e instituições de saúde facilitando a adoção de Standards por parte dos outros parceiros no Projeto, de modo a que estes se possam articular e comunicar convenientemente Audiência Os leitores alvo deste documento são os parceiros do PPS2 do projeto TICE.Healthy Organização do Documento Capítulo Resumo 1 Objetivo, Âmbito, Audiência 2 Arquétipos Base, UML, Arquitetura, RIM, API dos Serviços e Estrutura do Arquétipo 3 Edição dos Arquétipos, fluxo e persistência de arquétipos 4 Tipos Base, Estrutura 5 Arquétipo, body, Templates 6 Implementação Java 7 Exemplo prático TICE.Healthy 5/34

6 2. Desenvolvimento 2.1. O que é um Arquétipo São representações de conhecimentos clínicos, ou seja, estamos a designar ideias e modelos de todas as coisas existentes segundo e dentro de algum contexto. Cada arquétipo define um conjunto de atributos definidos no modelo de referência RIM no âmbito clínico ou organizacional. Os arquétipos são modelos baseados em restrições de entidades de domínio ou negócio estruturado, assim cada um descreve as configurações de instâncias de dados cujas classes são descritas com modelo de referência Arquétipos Base Na nossa arquitetura, os arquétipos base consistem em três modelos de entradas relacionadas com uma actividade clínica: Observação Permite registar tudo o que é observado, medindo ou obtendo respostas dos pacientes a determinadas perguntas. Avaliação Constam em avaliações, diagnósticos e planos. Instrução São um conjunto de afirmações que podem ser efetuadas, como ordem de medicação, lembrar alguém para fazer algo, monitorização, acompanhamento e exames UML Na figura 1 podemos ver a estrutura que define os arquétipos base, Cada arquétipo sintetiza informação considerada essencial para a caracterização um determinado ato. Uma parte comum a cada arquétipo base é o Header que contém um modelo não modelável mantendo-se igual para cada especialização: - Observação, Avaliação e Instrução onde cada uma poderá ser modelada de acordo com as necessidades do especialista do domínio. TICE.Healthy 6/34

7 Figura 1 - Estrutura dos Arquétipos Base 2.2. Arquétipos Quando falamos arquétipos estamos a designar ideias e modelos de todas as coisas existentes segundo e dentro de algum contexto. Cada arquétipo define um conjunto de atributos definidos no modelo de referência RIM no âmbito clínico ou organizacional. Levando para o contexto deste relatório os arquétipos são modelos e baseados em restrições de entidades de domínio ou negócio estruturado; assim, cada um descreve as configurações de instâncias de dados cujas classes são descritas com o modelo de referência. TICE.Healthy 7/34

8 2.3. Arquitetura Atual UI Figura 2 - Arquitetura A figura 2 ilustra a arquitetura atual, onde a camada mais baixa é responsável pela persistência dos dados contendo a base de dados RIM que contém os dados clínicos, o RIMDMG que terá os dados demográficos e a base de dados administrativa que irá conter dados de gestão. A camada imediatamente acima contém os serviços para a consumo dos arquétipos e também a gestão dos mesmos em ambiente cooperativo (em construção). No seguimento situa-se a camada de segurança (em construção) que irá conter mecanismos de validações e regras entre as destintas camadas. No topo temos as aplicações, o broker que terá a responsabilidade de efetuar a comunicação para o exterior, interfaces gráficas com pequenas aplicações para situações específicas como é o caso de questionários de avaliação psicológica, componentes e interfaces para os arquétipos que possibilitem a introdução e validação de dados (em construção) e o editor de arquétipos que possibilitam aos especialistas do domínio a modelação dos arquétipos para um determinado ato. TICE.Healthy 8/34

9 2.4. Reference Information Model O RIM especifica a gramática das mensagens, como constituintes básicos da linguagem, os nomes, verbos, etc. Especifica também as relações possíveis entre os componentes, assim como os tipos de dados possíveis utilizando uma abordagem orientada a objetos que proporciona uma representação explícita da semântica e sintaxe da informação transportada numa mensagem HL7. O modelo RIM, figura 5 é baseado numa estrutura com três classes pricipais, sendo estas: Entity, Role e Act e estão interligadas através de três classes de associação: Participation, RoleLink e ActRelationship Contexto RIM Dados Demográficos: Entity Organizações capazes de participar em atos. A hierarquia da entidade abrange temas vivos (incluindo os seres humanos), as organizações, materiais, locais e suas especializações. Role Uma entidade participa num ato com um determinado papel / regra. Note-se que uma entidade com funções específicas pode participar de um ato de muitas maneiras. O papel / regra define a competência da entidade Contexto do ato: Participation Associação entre um ato e uma determinada regra / papel com uma determinada entidade a desempenhar essa regra / papel. Act Registo de algo que está a ser feito, foi feito, pode ser feito, ou se destine ou pediu para ser feito. ActID Registo que deve ser utilizado para guardar informação de identificação do serviço, local, ou outras informações relacionas, ou definidas no do tipo <II> da API do RIM. TICE.Healthy 9/34

10 Figura 3 - RIM Contexto A figura 4 mostra-nos o contexto do RIM onde é apresentado os dados demográficos e o contexto do ato. Neste momento vamos estar apenas focados no contexto do ato como já havia sido referido acima. Num exemplo simples que seria medir a tensão arterial, estaríamos a fazer uma observação onde teríamos de registar medições efetuadas a um determinado paciente, ou seja o ato propriamente dito, e para complementarmos toda esta informação será necessário o contexto com os dados dos participantes em determinado ato. A figura 5 apresenta a estrutura do RIM 2.41 onde podemos ver os diversos relacionamentos entre as tabelas e os tipos de dados usados. Para um maior conhecimento aconselha-se a documentação disponibilizada em TICE.Healthy 10/34

11 TH_2013_PPS2_Documentação Figura 4 - Estrutura RIM 2.41 TICE.Healthy 11/34

12 2.5. API dos serviços A API da camada dos serviços está disponível em: aqui poderão consultar todos os serviços disponíveis para a manipulação dos arquétipos. Figura 5 - API dos Serviços Para a implementação deste exemplo vamos usar os serviços marcados a vermelho. Usando o método GET para um determinado arquétipo e digitando o ID 453 podemos obter o JSON do arquétipo, neste caso temos o objecto Archetype completo que contém o body. Caso queiramos o mesmo arquétipo em XML podemos entrar na aplicação (necessário credenciais) e obter o XML do arquétipo, durante a leitura deste documento é explicado a estrutura XML do arquétipo. O serviço POST Archetypes/upload é um serviço dedicado apenas para o editor de arquétipos que visa a persistência do arquétipo modelado no repositório via editor de arquétipos. TICE.Healthy 12/34

13 2.6. Estrutura do Arquétipo Figura 6 - Estrutura do Arquétipo TICE.Healthy 13/34

14 Na figura 7 podemos observar a estrutura de um arquétipo que é um ficheiro descrito em XML. Detalhando o seu conteúdo e explicando os seus campos temos: Archetype Elemento raiz do arquétipo que contêm todos os outros elementos. id Identificador único para cada arquétipo no repositório de arquétipos. header Informação do cabeçalho que será preenchida a quando da modelação do arquétipo ou seja no Editor de Arquétipos, onde todas as informação ficarão guardadas no HeaderDetails. header -> type Defini qual o tipo do arquétipo base, pode ser uma observação, avaliação ou uma instrução. header -> name Nome do arquétipo (ex: blood_pressure). header -> author Nome do autor que criou o arquétipo. header -> keywords Palavras chave que são que possam relacionar os conceitos clínicos do arquétipo. body Conteúdo modelado com o Editor de Arquétipos, pode conter diversos tipos de dados. body -> participations Defini quem participa num determinado ato, ou seja numa observação puderam participar duas pessoas o especialista e a pessoa observada. Aqui já estamos na presença de dados de contexto. body -> definition este campo é composto por grupos que irão conter diversos atributos. Por sua vez os atributos contêm propriedades ou itens, onde cada propriedade pode conter listas. body -> description este campo contêm a descrição, nome e id de todos os campos definidos para o body, assim dentro deste campo existe o elemento language onde que irá conter essas descrições para cada língua escolhida no arquétipo, digamos que nesta parte será tratada a internacionalização. Data -> Campo que vai conter dados para a persistência, este campo é livre pudendo suportar uma qualquer estrutura de dados. (em execução). minimumparticipations -> Aqui temos o mínimo de participações de num determinado arquétipo, esta validação têm no mínimo um participante por cada arquétipo base ou seja uma observação, instrução ou avaliação. TICE.Healthy 14/34

15 3. Edição de Arquétipos 3.1. Fluxo edição e persistência de arquétipos Para a edição dos arquétipos é utilizado um editor (em execução) que permite a construção de raiz para um determinado arquétipo onde este reúne determinados conceitos clínicos. Também é possível importarmos arquétipos (comunidade OpenEHR) já modelados e adaptá-los ao cenário pretendido. Figura 7 - Edição de Arquétipos A linguagem formal que expressa os arquétipos é conhecida por ADL (Archetype Definition Language) é conhecida por ser uma linguagem de descrição. O ADL pode ser usado para descrever restrições a dados que são instanciados por outros modelos de informação. A figura 8 apresenta um fluxo desde a criação do arquétipo até a sua persistência no repositório, assim um determinado especialista do domínio pode modelar o arquétipo através do editor e depois guardar esse mesmo arquétipo no repositório. TICE.Healthy 15/34

16 Pegando no exemplo da pressão arterial vamos observar como fica a modelação do mesmo no editor começando assim pela informação que compõe o cabeçalho do arquétipo. Figura 8 - Header blood pressure Na figura 9 vemos as descrições dadas ao Header do blood pressure, no entanto a parte do Description contêm outros detalhes como explicado no subcapítulo 2.5, assim passamos para a parte da Definition onde podemos ver a modelação do body. Figura 9 - Data blood pressure Na figura 10 ao lado direito podemos até escolher em que unidades queremos que determinada quantidade seja apresentada, neste caso foi escolhido em mm[hg]. TICE.Healthy 16/34

17 O separador Person State especifica entre outras coisa a posição da pessoa no ato da medição como pudemos ver ao lado direito da figura 11. Figura 10 - Data Person State blood pressure De seguida podemos observar a parte do Protocol na figura 12, que define entre outras especificações o local onde foi efetuada a medição, o método etc. O separador Participation defini quem participa nesta observação como já explicado anteriormente no subcapítulo 2.5. Figura 11 - Protocol blood pressure TICE.Healthy 17/34

18 Assim no final o editor apresenta-nos uma visão geral da Interface para tudo o que foi modelado, ou seja aquilo que seria a representação gráfica ideal para este arquétipo é apresentado na figura 13. Figura 12 - Interface blood pressure TICE.Healthy 18/34

19 4. Tipos Base 4.1. Definição e estrutura Nesta parte começamos por dar uma breve explicação do nosso baseschema XSD (XML Schema Definition), este descreve a estrutura dos arquétipos que são um documento XML. Por se tratar de um documento muito extenso vamos dar uma visão geral e focarmonos nos tipos de dados que vamos usar para a representação gráfica. Figura 13 baseschema.xsd A figura 14 apresenta graficamente uma descrição do ficheiro baseschema.xsd. O ficheiro está disponível no endereço onde podem consultar todos os tipos de dados definidos para o nosso modelo. Como queremos representar o que está dentro do conteúdo do body sendo que é a parte modelada, vamos apresentar a estrutura do seu elemento, tendo em conta que este já foi explicado anteriormente. TICE.Healthy 19/34

20 Figura 14 - Estrutura do body do arquétipo A figura 15 expressa o body onde podemos ver declarações que restringem as estruturas de dados descritas ao nível da informação. Podemos ver a multiplicidade ao nível dos elementos. Assim esta estrutura irá manter-se para cada arquétipo modelado facilitando assim o tratamento futuro dos dados nele contidos. TICE.Healthy 20/34

21 5. Arquétipo Podem consultar os arquétipos disponíveis através dos serviços como explicado no subcapítulo 2.4. No seguimento é apresentado o XML que compõe o blood pressure onde aparecem todas as informações especificadas no editor de arquétipos. Todos estes campos já foram explicados anteriormente. Figura 15 - Archetype XML A figura 16 apresenta o arquétipo da pressão arterial, a parte que compõe o header será uma parte estática para os arquétipos base, e relativamente à modelação de dados é feita apenas no body (será explicado mais à frente na secção 5.1), resta falar aqui do campo data (em construção), este campo é um campo livre que pode albergar diferentes estruturas de dados para a persistência, daí ser necessário validar qualquer entrada de dados para não criar lixo no RIM. TICE.Healthy 21/34

22 5.1. body XML Depois de se conhecer a estrutura base do body podemos analisar o seu conteúdo para o exemplo que temos vindo a seguir (blood pressure), a figura 17 apresenta um extracto do conteúdo onde se dá especial atenção ao rectângulo que está a preto pois serão os atributos que contêm a informação a representar. Figura 16 - Extrato body definition De seguida apresentamos um extracto, figura 18, ainda do mesmo ficheiro que nos mostra o elemento description onde estão representados por língua as descrições para os respetivos Id s. É neste campo que ficam guardadas as descrições para a internacionalização do arquétipo, neste caso apenas temos a língua EN. TICE.Healthy 22/34

23 Figura 17 - Extrato body description Uma forma de aceder directamente às informações do body é recorrer ao XPath que nos permitirá navegar por qualquer elemento e atributo que constam no documento XML, neste caso o body. Na secção implementação neste documento podemos ver exemplos de como usar o XPath Template No seguimento e continuando com o arquétipo blood pressure, idealizamos uma representação gráfica do mesmo que irá conter e descrever os Data types que seriam necessários à representação gráfica: Label -> Descrição do componente. Grafic componentes -> Representação dos componentes gráficos contendo componentes simples e compostos. Baseschema types -> São os tipos base usados nos arquétipos que por sua vez também validam o arquétipo, podem ser encontrados no endereço body types -> São os tipos definidos no corpo do body (XML) dentro do arquétipo, onde cada um destes tipos é validado pelo XSD referido no ponto acima, cada tipo será afectado pelas regras (mandatário, mínimo, máximo). Entity Manager types -> São os possíveis tipos que puderam ser mapeados no gestor de entidades a fim de se conseguir a representação. TICE.Healthy 23/34

24 Assim desta forma poderíamos ter uma representação gráfica para a medição da pressão arterial, onde seriam introduzidos os valores da medição, notas necessárias ao ato, a posição na qual o paciente se encontra, assim como a sua estatura como podemos ver na figura 19. Figura 18 - Template protótipo - blood pressure Os dados da estatura e posição encontra-se numa lista que foram preenchidos a quando a edição do arquétipo, no decorrer deste documento irei explicar onde se podem obter esses mesmos dados para puderem ser apresentados na ComboBox. TICE.Healthy 24/34

25 6. Implementação 6.1. Java Neste exemplo usa-se o arquétipo com id 601 (do tipo Observation) para persistir informação relativa ao ato médico, medição da tensão arterial. Como foi documentado anteriormente, para persistir um determinado arquétipo é necessário contexto. O contexto inclui três elementos básicos que são obrigatórios, sendo estes: Participações (Participation) - Os nossos participantes são os ID s 4 e 5; Identificação do ato (ActID) - Contém informação que foi simulada, mas numa situação real deverá conter informação apropriada. (informação da plataforma e / ou outro conteúdo relativo á transacção de dados); Ato (Act) - Neste caso o ato é do tipo Observation e então temos de criar um objecto deste tipo que irá conter as participações e respetivos ID s. (ATENÇÃO) Cada um dos elementos em cima referidos contêm informação própria do rimhl7v3 para assim garantir a compatibilidade na hora de exportar informação, que deve ser preenchida conforme as especificações de uma mensagem hl7v3. Para persistir esta informação precisamos de: Um cliente Restful que irá utilizar os serviços para a gestão e persistência dos arquétipos disponíveis em que contém a informação dos serviços disponíveis. A utilização do cliente para trazer o arquétipo com o id 601 fica como se pode ver na figura 20. (ATENÇÃO) As libs necessárias neste momento á implementação são: rimapi (download do rimapi) Jersey 1.13 (JAX-RS RI) TICE.Healthy 25/34

26 Client client = Client.create(); WebResource webresource = client.resource(" bresources/archetypes/by/601"); Archetype archetyperesponse = webresource.get(archetype.class); Acrescentamos Document conteúdo criando desc = um archetyperesponse.getbody(); XML Document Figura 19 - Cliente Rest Assim que recuperamos o arquétipo, podemos proceder à leitura do body. De forma simples podemos encontrar os atributos que contêm o body como é apresentado na figura 21. List<Element> nodes = desc.selectnodes("//attribute"); List<String> fields = new ArrayList<>(0); for (Element node : nodes) { id = node.attributevalue("id"); type = node.attributevalue("type"); req = node.attributevalue("required"); fields.add(id + ":" + type); } Assumido que as informações representadas pelo body só contêm um atributo, então podemos saber a informação do nome e descrição para língua portuguesa como representado na figura 22. Esta informação pode ser útil para representar graficamente os atributos. Figura 20 - Ler body O seguinte passo seria preencher a informação no data do arquétipo. O data deve ser um objecto XML figura 23, sendo que a sua estrutura pode ser modelada de diferentes maneiras assumindo que o template saberá como representar esta informação assim que esta seja recuperada. List<Element> languages = desc.selectnodes("//attr"); String lang = "pt"; Iterator<Element> it = languages.iterator(); String nome, langdesc; while (it.hasnext()) { Element element = it.next(); if (id.equals(element.attributevalue("id")) && element.getparent().attributevalue("id").equals(lang)) { nome = element.attributevalue("name"); langdesc = element.attributevalue("description"); } } } Figura 21 Ler Descrição TICE.Healthy 26/34

27 Document xmldata = new DocumentFactory().createDocument(); Element datafield = xmldata.addelement("stringfield"); datafield.settext( all data ); archetyperesponse.setdata(xmldata); Assim que se tenha todas as informações relativas ao contexto, já pudemos persistir o arquétipo: Figura 22 - Conteúdo XML Participation part1 = new Participation(); part1.setroleinternalid(4l); Participation part2 = new Participation(); part2.setroleinternalid(5l); Set<Participation> partset = new HashSet(0); partset.add(part1); partset.add(part2); Set<II> ids = new HashSet<II>(0); ids.add(new II("id", "application id, other Info", "location,ids,etc...")); Observation obscontext = new Observation(); obscontext.setactids(ids); obscontext.setparticipations(partset); ObservationArchetype observationarchetype = new ObservationArchetype(archetypeResponse); observationarchetype.setcontext(obscontext); Figura 23 Contexto RIM Na figura 24 podemos ver a simulação de dados de contexto necessários à persistência, estes dados num futuro serão fornecidos por outras aplicações dentro da plataforma que agrega os PPS s. Finalmente na figura 25 será invocado o serviço para a persistência. WebResource webresourcerim = client.resource(" s/observation"); ClientResponse responsea; responsea = webresourcerim.type("application/xml").post(clientresponse.class, obsararchetype); Figura 24 - Serviço para a persistência no RIM Note-se que este exemplo foi simulado o contexto de um determinado ato apenas para testarmos a persistência de dados no RIM, futuramente esses dados terão de vir de outras aplicações podendo mudar a forma de como se implementa o cliente. TICE.Healthy 27/34

28 6.2. Javascript Este capítulo tem como objetivo demonstrar uma implementação via Javascript que usará a API JS que foi desenvolvida com base no RIM. Assim será possível a construção de PackageApp s via HTML/Javascript que possibilita invocar serviços para a persistência de informação no RIM. Em traços gerais o primeiro passo será consumir um arquétipo que esteja disponível e publicado no repositório dos arquétipos. De seguida será necessário a construção do campo data (campo livre), neste exemplo foi usada uma estrutura XML que contêm os valores selecionados num determinado formulário em HTML, no seguimento será necessário invocar outro serviço para a persistência dos dados. Podem aceder à API do JS em healthy.oobian.com onde terão acesso à seguinte estrutura Javascript que deverá ser implementada da seguinte forma: <script src=" min.js"></script> <script src="healthy/rim/type/rimdatatype.js"></script> <script src="healthy/archetype.js"></script> <script src="healthy/rim/type/enum.js"></script> <script src="healthy/archetypetype.js"></script> <script src="healthy/archetypeheader.js"></script> <script src="healthy/headerdetails.js"></script> <script src="healthy/rim/type/cd.js"></script> <script src="healthy/rim/type/ts.js"></script> <script src="healthy/rim/type/qset.js"></script> <script src="healthy/rim/type/ii.js"></script> <script src="healthy/rim/type/ivl.js"></script> <script src="healthy/rim/type/pq.js"></script> <script src="healthy/rim/participation.js"></script> <script src="healthy/rim/act.js"></script> <script src="healthy/rim/observation.js"></script> <script src="healthy/observationarchetype.js"></script> Figura 25 - API JS - healthy A figura 27 mostra a ordem na qual deveremos ter os nossos scripts para uma interpretação correta do Browser. No seguimento passarei a explicar toda a implementação para o formulário PHQ9 que será HTML/Javascript. TICE.Healthy 28/34

29 O primeiro passo será consumir o arquétipo correto para o formulário PHQ9. Neste caso é o arquétipo com o id 7 no repositório. $.ajax({ type: "GET", url: " etypes/by/7", datatype: "json" }).success(function(data) }); Figura 26 - GET Archetype Nesta figura 28 podemos ver como através da camada de serviços disponíveis podemos aceder ao respectivo arquétipo, assim de seguida vamos ter de pegar nos seus valores e preencher o objecto Archetype. function setarchetype(jsonarchetype, formoptions) { var archetype = new Archetype(); archetype.setid(new Number(jsonArchetype.id)); archetype.minimumparticipations = new Number(jsonArchetype.minimumParticipations); archetype.header = new ArchetypeHeader(); var jsonheader = jsonarchetype.header; archetype.header.settype(new String(jsonHeader.type)); archetype.header.setname(new String(jsonHeader.name)); archetype.header.setauthor(new String(jsonHeader.author)); archetype.header.details = []; var jsondetails = jsonheader.detail; if (jsondetails.length === undefined) { var headerdetails = new HeaderDetails(); headerdetails.setlanguage(new String(jsonDetails.language)); headerdetails.setuse(new String(jsonDetails.use)); headerdetails.setmisuse(new String(jsonDetails.misUse)); headerdetails.setconceptname(new String(jsonDetails.conceptName)); headerdetails.setpurpose(new String(jsonDetails.purpose)); var keys = []; for (var i = 0; i < jsondetails.keyword.length; i++) { keys[i] = new String(jsonDetails.keyword[i]); } headerdetails.setkeywords(keys); archetype.header.details[0] = headerdetails; } else { for (var i = 0; i < detailsarray.length; i++) { var headerdetails = new HeaderDetails(); headerdetails.setlanguage(new String(detailsArray[i].language)); headerdetails.setuse(new String(detailsArray[i].use)); headerdetails.setmisuse(new String(detailsArray[i].misUse)); headerdetails.setconceptname(new String(detailsArray[i].conceptName)); headerdetails.setpurpose(new String(detailsArray[i].purpose)); var keys = []; var i = 0; for (var key in detailsarray[i].keywords) { keys[i++] = new String(key); } headerdetails.setkeywords(keys); archetype.header.details[i] = headerdetails; } } headerdetails = null; archetype.setdata(new String(formOptions)); archetype.setbody(new String(jsonArchetype.body)); return archetype; } Figura 27 - setarchetype TICE.Healthy 29/34

30 A figura 29 mostra-nos como deveremos preencher o arquétipo, que independentemente do mesmo será sempre preenchido desta forma, pois a estrutura do seu header será sempre igual. Nesta função, setarchetype são passados o jsonarchetype que representa o arquétipo que vem do serviço e o formoptions que representa uma estrutura de dados definida em XML. A seguinte função setparticipations faz parte do contexto para o RIM que neste caso foi preenchida da seguinte maneira: function setparticipations() { var part1 = new Participation(0, 6); var part2 = new Participation(1, 7); var Part = []; Part[0] = part1; Part[1] = part2; var IDs = new Array(); IDs[0] = new II("id", "idapp", "location"); return {IDs: IDs, Part: Part}; } Figura 28 - setparticipations Ainda preenchendo o contexto temos a função setobservation onde são passados os ID s, participantes e arquétipo já devidamente preenchido. function setobservation(ids, Part, responsearchetype) { var obscontext = new Observation(); obscontext.setactids(ids); obscontext.setparticipations(part); obscontext.setarchetypeid(responsearchetype.getid()); obscontext.setclasscode(responsearchetype.getheader().gettype()); return obscontext; } Figura 29 - setobservation A figura 31 apresenta uma função onde é criada uma nova observação para a qual são setados os valores dos ID s, quem participa na observação, qual o arquétipo e o seu tipo que foi usado para este ato. Finalmente será criado o objecto para a persistência com a função setobsarchetypecontext, onde é passado o contexto e o arquétipo. function setobsarchetypecontext(obscontext, responsearchetype) { return {"ObservationArchetype": new ObservationArchetype(obsContext, responsearchetype)}; } Figura 30 - setobsarchetypecontext TICE.Healthy 30/34

31 { "ObservationArchetype":{ "id":5, "header":{ "type":"observation", "name":"questpq9", "author":",null,null,null", "details":[ { "language":"pt", "use":"avaliação psicológica.", "misuse":"outro tipos de avaliações que não a psicológica.", "conceptname":"questpq9", "purpose":"questionário de Saúde do Paciente (PHQ-9). ", "keywords":[ "phq9", "avaliação psicológica" ] } ] }, "data":"<p1>3</p1><p2>3</p2><p3>3</p3><p4>3</p4><p5>3</p5><p6>3</p6><p7>3</p7><p8>3 </p8><p9>3</p9><p10>1</p10>", "minimumparticipations":1, "context":{ "archetypeid":5, "classcode":"observation", "participations":[ { "internalid":0, "roleinternalid":6 }, { "internalid":1, "roleinternalid":7 } ], "actids":[ { "root":"id", "extension":"idapp", "assigningauthorityname":"location" } ] } TICE.Healthy 31/34

32 } } Podemos ver a cima como ficará o objecto para a persistência no RIM. O último passo será invocar o serviço para guardar esta observação. function persistobservation(obsarchetype) { $.ajax({ type: 'POST', url: " contenttype: 'application/json', data: JSON.stringify(obsArchetype) }).success(function(data) { }); } Figura 31 - POST Observation A figura 33 mostra a invocação do serviço para a persistência da informação no RIM. Toda a informação para construção de uma PackageApp encontra-se disponível no portal evida. TICE.Healthy 32/34

33 6.3. Navegação no Campo data De modo a facilitar a navegação no campo data do arquétipo foi elaborado um esquema hierárquico que permite ter a percepção dos campos a preencher para a persistência. Assim a figura 32 a baixo apresenta foi elaborada com base no arquétipo Demo visto ser este exemplo que possui mais elementos para a representação. Como se pode observar, é provável que muitos elementos possam aparecer no campo data, e quando digo podem aparecer, é porque este campo vai inteiramente depender da modelação feita no Editor de Arquétipos. Caso só modelasse-mos o body do arquétipo apenas só com um elemento só esse elemento é que iria aparecer no data. De uma forma geral todos os elementos têm um id que corresponde ao atributo no campo body. Um dos elementos que podemos ver é o lower e upper estes elementos correspondem a intervalos (por ex. datas), que no RIM correspondem ao tipo IVL. Sempre que existem listas que já vêem preenchidas no body do arquétipo, que são possíveis de recuperar, estas podem ser persistidas no campo codestring que poderá aparecer como um filho de outro elemento. Uma vez que o campo data se trata de uma estrutura de dados em XML necessita de uma validação por parte de um ficheiro XSD que para cada arquétipo é gerado este mesmo ficheiro para validação e consistência dos dados, assim quando se está a tentar persistir informação no RIM é necessário o conhecimento não só dos tipos que são suportados pela API do RIM assim como o conhecimento deste campo para um determinado arquétipo. TICE.Healthy 33/34

34 Figura 32 - Campo "data" do arquétipo TICE.Healthy 34/34