#InterSystems IRIS for Health

0 Seguidores · 307 Postagens

InterSystems IRIS for Health™ é a primeira e única plataforma de dados do mundo projetada especificamente para o rápido desenvolvimento de aplicações de saúde, para gerenciar os dados mais críticos do mundo. Inclui poderosos recursos prontos para uso: processamento e análise de transações, um modelo de dados de saúde extensível, desenvolvimento de solução baseada em FHIR, suporte para padrões de interoperabilidade em saúde e muito mais. Tudo isso permitindo que os desenvolvedores percebam valor e criem aplicações inovadoras, rapidamente. Saber mais.

Artigo Bob Kuszewski · Maio 20, 2021 5m read

Migrando do Java Business Host para o PEX

Com o lançamento do PEX a partir do InterSystems IRIS 2020.1 e InterSystems IRIS for Health 2020.1, nossos clientes tem agora uma melhor forma de utilizar Java nas Produções de interoperabilidade que através da utilização do Java Business Host. O PEX (Production EXtension) disponibiliza um conjunto completo de APIs para criar componentes de interoperabilidade e está disponível tanto em Java quanto em .NET. O Java Business Host foi descontinuado e será aposentado em versões futuras.

Vantagens do PEX

  • Permite que desenvolvedores criem qualquer componente da Produção de interoperabilidade em Java ou em .NET
  • Estruturas de mensagens mais complexas podem ser enviadas através dos componentes
  • Configurações simplificadas
  • Fluxo de trabalho simplificado , sem utilização de ObjectScript.

O resto deste artigo está focado em como realizar a migração de código existente do Java Business Host para o PEX.

Visão Geral

As classes e interfaces utilizadas pelo PEX são diferentes das do Java Business Host (JBH). Nós iremos disponibilizar uma visão geral das diferenças neste artigo mas a documentação completa te dará maior profundidade sobre o assunto.

Convertendo um Business Service do Java Business Host para o PEX

Para criar um Business Service PEX você precisará implementar a com.intersystems.enslib.pex.BusinessService ao invés da com.intersystems.gateway.bh.BusinessService.

O padrão de design utilizado pelo PEX para Business Service mudou de um onde era esperado que o serviço iniciasse o processo de produção de mensagens para o padrão onde o serviço implementa uma função que é invocada periodicamente para produzir mensagens.

No JBH, seu código seria algo como isso

  @Override
  public boolean OnInit(Production p) throws Exception {
    production = p;

    if (messageThread == null) {
      Messager messager = new Messager();
      messageThread = new Thread(messager);
      messageThread.start();
    }
  
    return true;
  }

No PEX, você precisa apenas implementas três funções

  public void OnInit() throws Exception {
    // Inicialização
    return;
  }

  public Object OnProcessInput(Object messageInput) throws Exception {
    // Aqui é onde você invoca a SendMessage() ou SendMessageAsync()

    return null;
  }

  public void OnTearDown() throws Exception {
    // Desligar
    return;
  }

Você também precisará alterar como as configurações são utilizadas, mensagens são entregues e onde o registro de log é feito. Falaremos mais sobre estas alterações abaixo.

Convertendo um Business Operation do Java Business Host para PEX

Para criar um Business Operation PEX você precisará implementar a com.intersystems.enslib.pex.BusinessOperation ao invés da com.intersystems.gateway.bh.BusinessOperation.

O padrão de design para os Business Operations é estruturalmente o mesmo entre o JBH e o PEX entretanto os parâmetros para os dois principais pontos de entrada forma alterados.

Mudanças no OnInit()

No PEX o OnInit() não recebe parâmetros.

Mudanças no OnMessage()

No PEX o OnMessage() recebe um Object genérico no lugar da String utilizada no JBH. Isto permite que o criador da produção de interoperabilidade envie qualquer tipo de mensagem desejada.

No JBH sua aplicação ficaria mais ou menos algo assim:

  public boolean OnMessage(String message) throws Exception {
    // Lógica de negócio aqui
    return true;
  }

No PEX o parâmetro é um Objeto Java genérico, que você deve instanciar apropriadamente, que permite que você transmita mensagens mais complexas que apenas strings. Aqui está um exemplo de como extrair uma requisição que é do tipo file stream.

  public Object OnMessage(Object request) throws Exception {
    com.intersystems.jdbc.IRISObject streamContainer = (com.intersystems.jdbc.IRISObject)request;
    com.intersystems.jdbc.IRISObject str = (com.intersystems.jdbc.IRISObject)streamContainer.get("Stream");
    String originalFilename = (String)streamContainer.get("OriginalFilename");

    Long contentSize = (Long)str.get("Size");
    String content = (String)str.invoke("Read", contentSize);

    // Lógica de negócio aqui

    return null;
  }

Você também precisará alterar como as configurações são utilizadas, mensagens são entregues e onde o registro de log é feito. Falaremos mais sobre estas alterações abaixo.

Settings

A declaração das configurações também foi simplificada.

No JBH as configurações era declaradas através da string SETTINGS e recuperada através de código, algo como isso:

  String setting = production.GetSetting("Min");
  if (!setting.isEmpty()) {
    min = Integer.parseInt(setting);
  }

No PEX as configurações são apenas campos de membros públicos, desta forma elas são automaticamente carregadas quando a classe é instanciada.

  public int Min = 0;

Qualquer campo de membro público está disponível para ser atribuído em sua produção de interoperabilidade desde que o campo do membro seja um tipo base Java (String, int, etc.).

Mensagens

O envio de Mensagens no PEX é mais poderoso. No JBH mensagens são enviadas como strings. No PEX as mensagens são enviadas como objetos - tanto IRISObject, para objetos definidos em ObjectScript, ou uma subclasse subclass of com.intersystems.enslib.pex.Message, para classes definidas em Java.

No JBH seu código seria algo assim

  production.SendRequest(value.toString());

No PEX seria algo como isso

  MyExampleMessageClass req = new MyExampleMessageClass("mensagem a ser enviada"); 
  SendRequestAsync(Target, req);

Logging

As funções para registro de Logs são todas similares, apenas nomeadas de forma diferente.

No PEX você registraria uma mensagem informativa através da LOGINFO()

  LOGINFO("mensagem recebida");

Gateway de Objetos

O Java Business Host precisava de seu próprio gateway. Com o PEX você pode utilizar um Java gateway apenas para toda sua necessiade de Java. Ou então usar vários, você escolhe. Aqui você encontra uma boa introdução ao gateway.

Conclusão e Feedback

Se você ainda não experimentou utilizar o PEX, o que falta ? O PEX disponibiliza a habilidade de resolver uma quantidade muito mais ampla de problemas de negócio com menos codificação, além de permitir que agora tudo também seja feito em .NET.

Se você tiver dúvidas ou problemas migrando suas aplicações de JBH para PEX, entre em contato conosco pelo WRC.

0
0 104
InterSystems Oficial Angelo Bruno Braga · Maio 20, 2021

Java Business Host está aposentado

Com o lançamento do PEX no InterSystems IRIS 2020.1 e no InterSystems IRIS for Health 2020.1, nossos clientes tem agora uma melhor forma de utilizar Java nas produções que através do Java Business Host. O PEX disponibiliza um conjunto completo de APIs para criar componentes de interoperabilidade e está disponível tanto para Java quanto para  .NET.

0
0 69
Anúncio Rochael Ribeiro · Maio 11, 2021

 

O evento Hospitalar Digital Journey está começando, com discussões importantes sobre a Medicina

pós-pandemia e a Transformação Digital na Saúde, entre outros temas que envolvem a comunidade e especialistas.​

Para falar sobre os benefícios da Interoperabilidade, a InterSystems convidou Antonio Valadares, gerente de TI

do Hospital Israelita Albert Einstein. 

   

0
0 218
Anúncio Angelo Bruno Braga · Maio 6, 2021

Olá Comunidade,

Estamos felizes em convidar todos os desenvolvedores para o Webinar de Lançamento do Concurso de Programação Acelerador FHIR da InterSystems
 dedicado ao Concurso de Programação Acelerador FHIR da InterSystems !

Neste webinar iremos conversar e demonstrar como utilizar o Acelerador FHIR como serviço..

Data & Horário: Segunda-feira, 10 de Maio — 14:00 horário de Brasília

Palestrantes:  
🗣 @Evgeny Shvarov, Gerente do Ecossistema para Desenvolvedores da InterSystems
🗣 @Regilo Regilio Guedes de Souza, Executivo de Serviços InterSystems
🗣 @Anton Umnikov, Arquiteto de Soluções na Nuvem Sênior InterSystems
🗣 @Patrick Jamieson, Gerente de Produto InterSystems - Plataforma de Informática em Saúde

0
0 61
Anúncio Angelo Bruno Braga · Maio 5, 2021

Olá Comunidade,

Juntem-se à próxima competição de programação online da InterSystems:

🏆 Concurso de Programação Acelerador FHIR da InterSystems 🏆

Envie uma aplicação que utilize o InterSystems FHIR-as-a-service na AWS ou auxilie desenvolvendo soluções utilizando o Acelerador FHIR da plataforma de dados IRIS da InterSystems.

Duração: de 10 de Maio a 06 de Junho de 2021

Total em prêmios: US$8,750 


0
0 105
InterSystems Oficial Benjamin De Boe · Abr. 8, 2021

A versão 2020.4 do InterSystems IRIS, IRIS for Health e IRIS Studio já se encontram disponíveis para uso geral.

A plataforma de dados InterSystems IRIS 2020.4 torna inda mais fácil desenvolver, implantar e gerenciar akes it even easier to develop, deploy and manage aplicações de ponta e processos de negócio que unem dados e silos de aplicações. Ela possui várias novas funcionalidades, incluindo:

Melhorias para desenvolvedores de aplicações e interfaces, incluindo:

0
0 100
InterSystems Oficial Jeff Fried · Mar. 29, 2021

Três novos conjuntos de versões de manutenção foram disponibilizados:  

  • Caché  2018.1.5, Ensemble 2018.1.5 e HSAP 2018.1.5
  • InterSystems IRIS 2019.1.2, IRIS for Health 2019.1.2 e HealthShare Health Connect 2019.1.2
  • InterSystems IRIS 2020.1.1, IRIS for Health 2020.1.1 e HealthShare Health Connect 2020.1.1

Os kits para instalação e os contêineres podem ser baixados na página de Distribuição de Softwares do WRC.

0
0 151
InterSystems Oficial Pete Greskoff · Mar. 29, 2021

23 de Março de 2021 – Alerta: Problema em Potencial de Integridade de Dados na Aplicação dos Arquivos de Journal em Espelhamento

A InterSystems corrigiu um defeito que pode causar problemas de consistência de dados em membros não primários do espelhamento em circunstâncias extremamente raras. Este defeito afeta todas as versões lançadas dos produtos InterSystems.

0
0 217
Artigo · Mar. 26, 2021 5m read

Acabamos de terminar o segundo dia de sessões de foco - com MUITO conteúdo excelente! Com trilhas paralelas, é difícil acompanhar - mas uma vantagem de uma conferência virtual é que você pode assistir a tudo o que perdeu sob demanda!

No blog de ontem (Destaques do dia 1), cobri a maioria dos anúncios especiais, como InterSystems IRIS Adaptive Analytics e o FHIR Accelerator Service, então é hora de nos voltarmos para alguns temas estratégicos mais amplos hoje.

0
0 86
Artigo Fernando Ferreira · Mar. 25, 2021 6m read

Olá comunidade,

  Nesta 4ª parte vamos falar de uma funcionalidade do InterSystems IRIS Reports chamada de “Bursting”. Vamos primeiro relembrar o que já vimos até o momento.

Entendemos o que é o InterSystems IRIS Reports, instalamos os ambientes: Designer e Server, verificamos os diversos tipos e formatos de relatórios que podemos desenvolver, e entendemos como distribuir um relatório em diversos formatos.

Mas afinal o que é o “Bursting”? Antes de demonstrar está funcionalidade em ação, vamos primeiro refletir sobre a sua necessidade.

Todos nós já nos deparamos com necessidade de processar relatórios com milhares de linhas, e este tipo de relatório normalmente tem um alto custo de processamento no banco de dados com milhares de linhas que não são destinadas a um único usuário, você precisa segregar as informações por região, por alguma categoria seja de produto ou um tipo de exame, ou por alguma hierarquia existente para o seu tipo de negócio. Sem o InterSystems IRIS Reports, você precisaria desenvolver uma ou mais queries aplicando técnicas para filtrar dados com as opções de “filtro” que usuário precisa ou pode ter acesso, e podem ocorrer mais de uma execução por diversos usuários ao longo do dia.

0
0 177
Artigo Fernando Ferreira · Mar. 17, 2021 10m read

Olá Comunidade,

Chegou a hora de iniciarmos o desenvolvimento dos relatórios utilizando o InterSystems IRIS Reports, powered by Logi Analytcs.

Lembrando que na primeira parte do artigo falamos o que é o InterSystems IRIS Reports, e como ele vem facilitar a vida dos desenvolvedores na entrega de relatórios, e na segunda parte executamos o procedimento de instalação dos ambientes server e designer e o procedimento para fazer o download dos binários de instalação!

Alguns conceitos importantes antes de iniciarmos o desenvolvimento sobre os tipos de relatórios que podemos desenvolver:

  • Estáticos: Os relatórios e seus resultados não podem ser modificados pelo usuário final. O layout e os dados inclusos são definidos pelo desenvolvedor.
  • Dinâmicos: Os relatórios podem ser modificados pelos usuários finais, como no estático o layout e dos dados são inclusos pelo desenvolvedor, porém o usuário final consegue modificá-los em tempo de execução.
  • Ad Hoc – Relatórios e dados são construídos e modificados em tempo de execução pelo usuário final. 
2
0 426
Artigo Fernando Ferreira · Mar. 4, 2021 6m read

Olá comunidade,

              Vamos para a 2º parte do artigo InterSystems IRIS Reports.

Somente relembrando na primeira parte do artigo falamos dos desafios existentes para atender a demanda das áreas de negócios, clientes ou usuários finais com a entrega de relatórios em diversos formatos e suas melhorias, e como o InterSystems IRIS Reports vem para facilitar está demanda, facilitando o desenvolvimento, a administração, o deploy de relatórios em diversos formatos, bem como a automação da distribuição por e-mail ou pastas e integração (build-in) em suas aplicações já existentes!

O InterSystems IRIS Reports, powered by Logi Report se encontra disponível para download no WRC (https://wrc.intersystems.com/wrc/coDistribution.csp), lembrando que para clientes que já possuem o licenciamento InterSystems IRIS Advanced Server ou InterSystems IRIS Advanced for Health, precisam somente abrir um chamado solicitando o serial para a instalação do InterSystems IRIS Reports, sem custo adicional.

Como mencionando no artigo anterior o InterSystems IRIS Reports é divido em dois componentes:

Server: O ambiente servidor tem a sua finalidade de administrar as configurações e segurança. É também onde os usuários finais via browser têm acesso aos relatórios, você pode agendar execução de relatórios, aplicar filtros e modificar os relatórios disponibilizados.

Designer: O ambiente designer por sua vez é onde os relatórios são desenvolvidos. É possível visualizar os relatórios antes de disponibilizar acessando diretamente a bases de dados.

0
0 332
Artigo Ron Sweeney · Fev. 10, 2021 7m read

Se você está procurando uma maneira inteligente de integrar sua solução IRIS no ecossistema Amazon Web Services, aplicativos sem servidor ou script python baseado em boto3, usar a API Nativa IRIS para Python pode ser o caminho a seguir. Até que você precise obter ou definir algo no IRIS, você não tem que ir muito longe com uma implementação em produção para fazer sua aplicação funcionar de um maneira incrível, então, espero que você encontre valor neste artigo e construa algo que seja importante para outros ou somente para você, pois ambos são igualmente válidos.

imagem

Se você está procurando algumas justificativas para implementar isso:

  • Você precisa acertar a trigger de geração de pré-token no Cognito para pesquisar e inserir o contexto de ID do paciente no token para uma solução baseada em SMART on FHIR(R) implementando um fluxo de trabalho com OAUTH2.
  • Você deseja publicar as configurações de ajuste de provisionamento do IRIS com base no tipo de instância, grupo de nós, toaster ou cluster ECS que você disparou para executar o IRIS no anel zero.
  • Você quer impressionar a família e os amigos no Zoom com suas habilidades de gerenciamento do IRIS sem que o seu shell saia da AWS cli.

O ponto

Aqui, vamos provisionar uma função lambda da AWS que se comunica com o IRIS e fornecer alguns exemplos sobre como provisioná-la e como interagir com ela em várias capacidades, na esperança de que possamos discutir sobre isso e publicá-la no pip para tornar as coisas mais fáceis.

Com pressa????

imagem

Confira o streaming

<iframe width="560" height="315" src="https://www.youtube.com/embed/mA0VzKOYhBk" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen mark="crwd-mark"></iframe>

Em todo o caso...

Para participar da diversão, você precisará definir algumas coisas em seu plano de voo.

Rede

Você tem o IRIS em execução da maneira que deseja, rodando em uma AWS VPC com exatamente duas sub-redes e um grupo de segurança que permite acesso ao super servidor rodando IRIS... usamos 1972 por motivos nostálgicos e pelo simples fato de que a InterSystems se deu ao trabalho de registrar essa porta no IANA, e se você adicionar a nova porta em /etc/services sem fazer isso, não é a melhor prática, mas tudo bem. Em nosso caso, é um conjunto de instâncias EC2 espelhadas com verificações de integridade adequadas em torno de um balanceador de carga de rede AWS v2.

imagem

Classe de exemplo importada

De alguma forma, você conseguiu criar e importar a classe na raiz deste repositório para o namespace %SYS em sua instância IRIS. A seguir está um exemplo da classe que gera a saída acima. Se você está se perguntando por que precisamos importar uma classe aqui, consulte a nota abaixo, onde a abordagem recomendada é provisionar algumas classes de wrapper para uso por meio do python.

Nota do Docs: Embora esses métodos também possam ser usados com as classes InterSystems definidas na Biblioteca de Classes, a melhor prática é chamá-las indiretamente, de dentro de uma classe ou rotina definida pelo usuário. Muitos métodos de classe retornam apenas um código de status, passando os resultados reais de volta em um argumento (que não pode ser acessado pela API nativa). As funções definidas pelo sistema (listadas em Funções ObjectScript na Referência ObjectScript) não podem ser chamadas diretamente.

Classe de Exemplo:

Class ZDEMO.IRIS.Lambda.Operations Extends %Persistent
{
  ClassMethod Version() As %String
  {
   Set tSC = 0

   Set tVersion = $ZV
   if ( tVersion '="" ) { set tSC = $$$OK }

   Set jsonret = {}
   Set jsonret.status = tSC
   Set jsonret.payload = tVersion

   Quit jsonret.%ToJSON()
  }
}

Observe acima que decidi trabalhar com base na convenção de sempre retornar um objeto JSON como uma resposta, que também me permite retornar o status e possivelmente preencher a lacuna ao retornar algumas coisas por referência.

Acesso AWS

Obtenha algumas chaves de acesso IAM que permitirão que você provisione e invoque a Função Lambda com a qual iremos mudar o mundo.

Verificação antes do voo:

IRIS            [ $$$OK ]  
VPC             [ $$$OK ]  
Subnets         [ $$$OK ]  
Security Group  [ $$$OK ]  
IAM Access      [ $$$OK ]  
Imported Class  [ $$$OK ]  

$$$OK, Vamos lá.

Empacotando a API Nativa IRIS para Python para uso na Função Lambda

Esta é a parte que seria fantástica se fosse um pacote pip, especialmente se fosse apenas para Linux, já que as funções da AWS Lambda são executadas no BoXenLinux. No momento deste commit, a API não está disponível via pip, mas somos engenhosos e podemos lançar a nossa própria.

mkdir iris_native_lambda
cd iris_native_lambda
wget https://github.com/intersystems/quickstarts-python/raw/master/Solutions/nativeAPI_wheel/irisnative-1.0.0-cp34-abi3-linux_x86_64.whl
unzip nativeAPI_wheel/irisnative-1.0.0-cp34-abi3-linux_x86_64.whl

Crie connection.config

Exemplo: connection.config

Crie seu manipulador, index.py ou use aquele na pasta de exemplos, no repositório de demonstração no GitHub. Observe que a versão de demonstração usa variáveis de ambiente e um arquivo externo para as informações de conectividade IRIS.

Exemplo:
index.py

Agora compacte-o para uso:

zip -r9 ../iris_native_lambda.zip *

Crie um bucket S3 e carregue o zip de função nele.

cd ..
aws s3 mb s3://iris-native-bucket
s3 sync iris_native_lambda.zip s3://iris-native-bucket  

Isso conclui o empacotamento da API e do manipulador para uso como uma função AWS Lambda.

Agora, clique no console para criar a função ou use algo como o Cloudformation para executar o trabalho:

  IRISAPIFunction:
    Type: "AWS::Lambda::Function"
    DependsOn:
      - IRISSG
      - VPC
    Properties:
      Environment:
        Variables:
          IRISHOST: "172.31.0.10"
          IRISPORT: "1972"
          NAMESPACE: "%SYS"
          USERNAME: "intersystems"
          PASSWORD: "lovetheyneighbor"
      Code:
        S3Bucket: iris-native-bucket
        S3Key: iris_native_lambda.zip
      Description: "Função API Nativa IRIS para Python"
      FunctionName: iris-native-lambda
      Handler: "index.lambda_handler"
      MemorySize: 128
      Role: "arn:aws:iam::8675309:role/BeKindtoOneAnother"
      Runtime: "python3.7"
      Timeout: 30
      VpcConfig:
        SubnetIds:
          - !GetAtt
            - SubnetPrivate1
            - Outputs.SubnetId
          - !GetAtt
            - SubnetPrivate2
            - Outputs.SubnetId
        SecurityGroupIds:
          - !Ref IRISSG

Isso foi BASTANTE, mas agora você pode enlouquecer e chamar o IRIS através da função lambda com Python e mudar o mundo.

Execução!

Da forma como o descrito acima é implementado, espera-se que a função seja passada em um objeto de evento que é um tanto estruturado para reutilização, você pode ver a ideia no exemplo de objeto de evento abaixo:

    {
      "method": "Version",
      # importante, se o método não requer argumentos, aplique "none"
      "args": "none"
      # exemplo de método com argumentos, separados por vírgulas
      # "args": "thing1, thing2"
    }

agora você pode, se tiver tolerância para exemplos em linha de comando, dar uma olhada na execução abaixo usando a AWS CLI:

(base) sween @ basenube-pop-os ~/Desktop/BASENUBE
└─ $ &#x25b6; aws lambda invoke --function-name iris-native-lambda --payload '{"method":"Version","args":"none"}' --invocation-type RequestResponse --cli-binary-format raw-in-base64-out --region us-east-2 --profile default /dev/stdout
{{\"status\":1,\"payload\":\"IRIS for UNIX (Red Hat Enterprise Linux for x86-64) 2020.2 (Build 210U) Thu Jun 4 2020 15:48:46 EDT\"}"
    "StatusCode": 200,
    "ExecutedVersion": "$LATEST"
}

Agora, se dermos um passo adiante, a AWS CLI oferece suporte a aliases, então crie um para você mesmo e você pode brincar com total integração com o seu comando aws legal. Aqui está um exemplo de alias cli:

└─ $ &#x25b6; cat ~/.aws/cli/alias 
[toplevel]
whoami = sts get-caller-identity

iris = 
  !f() {
   aws lambda invoke \
     --function-name iris-native-lambda \
     --payload \
     "{\"method\":\""${1}"\",\"args\":\"none\"}" \
     --invocation-type RequestResponse \
     --log-type None \
     --cli-binary-format raw-in-base64-out \
     gar.json > /dev/null
     cat gar.json 
     echo
     echo
  }; f

...e agora, você pode apenas fazer...
imagem

Se cuide! – Argumentos técnicos são bem-vindos!

1
0 175
Artigo Angelo Bruno Braga · Mar. 2, 2021 9m read

A especificação do FHIR Terminology Service descreve um conjunto de operações nos recursos CodeSystem, ValueSet e ConceptMap. Entre essas operações, as quatro operações a seguir parecem ser as mais amplamente adotadas:

O desenvolvimento de uma implementação parcial da especificação tem sido uma forma eficaz de explorar o novo framework FHIR introduzido no IRIS for Health 2020.1. A implementação inclui quatro operações listadas acima e oferece suporte a interações de leitura e pesquisa para os recursos CodeSystem e ValueSet.

É importante observar que a implementação usa classes persistentes do Plain ObjectScript como fonte para tabelas de terminologia.

Instalação e teste com uma estratégia de exemplo

A lista a seguir descreve as etapas básicas de instalação e teste:

  1. Instale o IRIS for Health 2020.1 ou mais recente.
  2. Configure um novo namespace usando o menu System Administration > Configuration > System Configuration > Namespaces no Portal ou executando o comando do ##class(HS.HC.Util.Installer).InstallFoundation("<name for the new namespace>") no namespace HSLIB. Em seguida, importe as classes das pastas src/cls e samples/cls do repositório intersystems-ru/fhir-terminology-service no GitHub.
  3. Crie um conjunto customizado de metadados FHIR com base no conjunto R4 com parâmetros de pesquisa adicionais definidos em dummy-search-parameters.json. Isso pode ser feito usando o utilitário interativo ##class(HS.FHIRServer.ConsoleSetup).Setup() ou executando o comando:
do ##class(HS.FHIRServer.Installer).InstallMetadataSet("", "", "HL7v40", $lb("<directory with dummy-search-parameters.json>"), 1)
  • Esta etapa é necessária para que as operações $expand e $validate-code suportem solicitações HTTP GET.
  • Observe que os arquivos do conjunto de metadados FHIR empacotados com InterSystems IRIS estão no diretório <installation directory>/dev/fhir/fhir-metadata.
  1. Crie um novo endpoint FHIR com base no novo conjunto de metadados e na classe Sample.iscru.fhir.fts.SimpleStrategy. Novamente, isso pode ser feito usando o utilitário interativo ou executando o comando:
do ##class(HS.FHIRServer.Installer).InstallInstance("<web app URI, e.g. /csp/terminology>", "Sample.iscru.fhir.fts.SimpleStrategy", "")
  1. Permita o acesso não autenticado ao novo endpoint: use o utilitário interativo ou execute os seguintes comandos:
set strategy = ##class(HS.FHIRServer.API.InteractionsStrategy).GetStrategyForEndpoint("<web app URI>")
set config = strategy.GetServiceConfigData()
set config.DebugMode = 4
do strategy.SaveServiceConfigData(config)
  1. Popule o Sample.iscru.fhir.fts.model.CodeTable:
do ##class(Sample.iscru.fhir.fts.model.CodeTable).Populate(10)
  1. Importe o arquivo fhir-terminology-service.postman_collection.json para o Postman, ajuste a url variável definida na coleção e teste o serviço em Sample.iscru.fhir.fts.model.CodeTable, que é uma classe persistente simples.

Interações FHIR suportadas

Atualmente, o único parâmetro de pesquisa com suporte para CodeSystem e ValueSet é url.

Os métodos HTTP GET e HTTP POST são suportados para as quatro operações listadas acima.

A tabela a seguir lista algumas das possíveis solicitações HTTP GET na classe Sample.iscru.fhir.fts.model.CodeTable.

URI
(a ser acrescentado com http://<server>:<port><web app URI>)
Descrição
/metadataObtém o recurso de declaração de capacidade do endpoint.
/CodeSystem/Sample.iscru.fhir.fts.model.CodeTableLê o recurso CodeSystem correspondente à classe Sample.iscru.fhir.fts.model.CodeTable.
/ValueSet/Sample.iscru.fhir.fts.model.CodeTableLê o recurso ValueSet correspondente à classe Sample.iscru.fhir.fts.model.CodeTable.
/CodeSystem?url=urn:CodeSystem:CodeTablePesquisa o recurso CodeSystem por url.
/CodeSystemEnvia todos os recursos do CodeSystem disponíveis.
/ValueSet?url=urn:ValueSet:CodeTablePesquisa o recurso ValueSet por url.
/ValueSetEnvia todos os recursos do ValueSet disponíveis.
/CodeSystem/$lookup?system=urn:CodeSystem:CodeTable&code=TESTDado o sistema e o código, obtêm todos os detalhes sobre o conceito.
/ValueSet/$expand?url=urn:ValueSet:CodeTableExpande o ValueSet.
/CodeSystem/Sample.iscru.fhir.fts.model.CodeTable/$validate-code?code=TESTValida se um código está no sistema de código.

Criando uma estratégia personalizada

A fim de expor suas próprias classes persistentes como sistemas de código/conjuntos de valores FHIR, você precisará criar sua classe de estratégia personalizada ao subclassificar o iscru.fhir.fts.FTSStrategy e, em seguida, criar um endpoint FHIR com base na nova estratégia personalizada (veja a instalação no passo 4 acima).

Um parâmetro de classe e pelo menos três métodos devem ser substituídos por sua classe de estratégia:

  • O parâmetro de classe StrategyKey deve receber algum valor único. O nome da classe atual parece ser uma boa opção.
  • O método de classe getCodeTablePackage() deve retornar o nome do pacote para um determinado sistema de código (ou conjunto de valores) identificado por sua URL canônica. Normalmente, todas as classes de terminologia pertencem a um pacote, portanto, esse método normalmente retornaria um e o mesmo nome de pacote, independentemente dos valores dos argumentos.
  • Os métodos de classe getCodePropertyName() e getDisplayPropertyName() devem retornar nomes de propriedades de classe que correspondem aos elementos de conceito code e display. Classes diferentes podem ter propriedades diferentes mapeadas para elementos de terminologia code/display.

Outros métodos e parâmetros de iscru.fhir.fts.FTSStrategy que você pode achar apropriado substituir são os seguintes:

  • O método da classe listCodeTableClasses() precisa ser sobrescrito para dar suporte às solicitações de pesquisa que resultam no retorno de todos os sistemas de código disponíveis (ou conjuntos de valores). Este método deve retornar uma lista de nomes de classes de todas as classes de terminologia disponíveis. Sample.iscru.fhir.fts.SimpleStrategy contém a seguinte implementação básica deste método:
/// Retorna uma lista de todas as classes de tabela de código disponíveis.
ClassMethod listCodeTableClasses() As %List
{
    #dim sql As %String = "SELECT name FROM %Dictionary.ClassDefinition WHERE name LIKE '" _ ..#codeTablePACKAGE _ ".%' ORDER BY name"
    #dim resultSet As %SQL.StatementResult = ##class(%SQL.Statement).%ExecDirect(, sql)
    if (resultSet.%SQLCODE '= 0) && (resultSet.%SQLCODE '= 100) $$$ThrowStatus($$$ERROR($$$SQLError, resultSet.%SQLCODE, resultSet.%Message))

    #dim return As %List = ""
    while resultSet.%Next()
    {
        set return = return _ $lb(resultSet.name)
    }

    quit return
}
  • O método da classe isExcludedProperty() deve ser substituído se alguma propriedade particular de suas classes persistentes não aparecer nos recursos CodeSystem. Por padrão, este método filtra as propriedades de Collection, Identity, Internal, MultiDimensional e Private. Observe que a referência de objeto e as propriedades de fluxo atualmente não são suportadas e são ignoradas pelo framework.

  • Os parâmetros de classe codeSystemUrlPREFIX e valueSetUrlPREFIX, e os métodos getCodeSystemForClassname(), getValueSetForClassname(), determineCodeTableClassname() e determineCodeSystemForValueSet() controlam como os nomes de classe são mapeados para URLs canônicas e vice-versa. Por padrão, o seguinte esquema de nomenclatura é usado para URLs canônicas: | CodeSystem | ValueSet | | ----------------------------------------- | --------------------------------------- | | urn:CodeSystem:<short class name> | urn:ValueSet:<short class name> |

Observe que o logical id (também conhecido como server id) de um recurso CodeSystem/ValueSet é igual ao nome completo de sua classe correspondente.

A FAZER

Atualmente falta suporte para controle de versão de sistemas de código, hierarquias de conceito e operação de $subsumes, recurso de ConceptMap e muitas outras coisas. Ideias e pull requests são bem-vindos!

0
0 97
Artigo Fernando Ferreira · Fev. 23, 2021 2m read

Olá comunidade,

Todos nós já conhecemos o poder da solução InterSystems IRIS Data platformou IRIS for Health, a facilidade de desenvolver aplicações utilizando Object Script, Java, Node.JS, Python, .NET,  com alto desempenho e confiabilidade do nosso banco de dados multi-modelo altamente escalável de forma horizontal ou vertical, o poder da interoperabilidade entre aplicações, com outros bancos de dados, a possibilidade de integrar utilizando diversos protocolos como REST, SOA, MQTT, FTP, etc., a nossa solução de BI, NLP, tudo em um mesmo binário, em uma mesma plataforma, o que facilita a vida do desenvolvedor a entregar soluções inovadoras e confiáveis!

Mesmo entregando soluções inovadoras, existe um desafio diário para muitos desenvolvedores, demandada pelas áreas de negócios, seja para entregar informação para clientes e ou usuários internos/externos etc., que são os relatórios.

0
0 211
Artigo Claudio Devecchi · Fev. 8, 2021 10m read

HealthShare Patient Index

Enterprise Master Patient Index - Este é o nome dado ao processo que faz com que os inúmeros cadastros e registros coletados dos vários sistemas das instituições e redes de saúde sejam identificados univocamente e interligados através de um identificador único por indivíduo.

Isto viabiliza uma infinidade de benefícios para as instituições ou redes de saúde, pois permite, além da gestão das duplicidades em um mesmo sistema de prontuário eletrônico, que todos os dados segregados por número de cadastro sejam visualizados de forma consolidada por indivíduo. Cada vez mais, as instituições estão buscando uma abordagem holística do cuidado contínuo, da prevenção e da experiência centrada no paciente.

Falando sobre o produto Healthshare Patient Index da InterSystems, podemos dividi-lo em 6 grandes grupos de funcionalidades.

1 - Integração das informações cadastrais dos pacientes

Esta etapa engloba todos os mecanismos de coleta das informações nos sistemas de origem, seja através de API’s com protocolos específicos de saúde como o HL7, seja através de processos específicos ou customizados.

Neste ponto, é importante que a plataforma de integração ofereça uma série de requisitos de interoperabilidade que assegure flexibilidade, governança e segurança.

É muito comum sistemas de prontuário eletrônico internacionais fornecerem nativamente exportações de dados usando o protocolo HL7, que neste caso também é nativo nos produtos da Intersystems. Os sistemas nacionais geralmente demandam processos menos padronizados, e é por isso que é necessário que a plataforma seja de fácil e rápida implementação.

Geralmente as informações são enviadas ou disponibilizadas no momento em que o paciente é admitido nos estabelecimentos de saúde.

A arquitetura deste processo é definida conforme as necessidades de cada organização e disponibilidade dos recursos computacionais.

2 - Análise Qualitativa e Normalização

Normalizar significa trazer para um mesmo plano de comparação informações demográficas que foram cadastradas de formas completamente diferentes. É também nesta etapa que todo o “lixo” é removido. Isto não quer dizer que a informação seja ruim, mas que não serve para o processo do MPI.

Se os dados fossem comparados sem esta etapa, provavelmente cadastros de um mesmo indivíduo nunca seriam comparados, dada à discrepância de sistema para sistema.

Se observarmos o processo de cadastro de cada estabelecimento e sistema de origem, veremos uma infinidade de formas de entrada dos dados e diversas maneiras de armazenamento das informações. Isso depende de como cada sistema foi concebido e como cada processo foi implementado em cada setor da organização.

Um exemplo típico é o processo de admissão em alas emergenciais. Muitas vezes o paciente precisa ser atendido antes mesmo de ser identificado. Isso gera uma série de especificidades que precisam ser tratadas em uma análise qualitativa antes mesmo da implementação do processo de captura dos dados.

O outro exemplo muito comum é o cadastramento de recém nascidos. Cada caso é um caso. Em alguns sistemas os nomes são cadastrados com um prefixo “RN DE” seguido pelo nome da mãe. Isso porque os pais não sabem o nome dos bebês antes do parto e eles já precisam constar nos sistemas de prontuário eletrônico. Como todos os sistemas geralmente exigem o CPF, eles podem ser cadastrados com o mesmo CPF da mãe. É claro que este é só um exemplo de uma situação pontual, mas cada caso deve ser estudado e endereçado da forma mais adequada possível.

Além das especificidades de processo, há as que são de armazenamento dos dados. Documentos como CPF, RG e carteirinhas de seguro são armazenados com pontos e traços em alguns sistemas. Em outros são armazenados sem. O mesmo ocorre com datas. Nomes geralmente são armazenados em um único campo, uns com caixa baixa, outros com alta. Alguns são abreviados pela limitação de caracteres.

Endereços são os vilões na normalização. Os sistemas mais modernos são baseados no CEP, outros não. Os que não são sofrem muitas abreviações devidos aos sufixos, títulos ou até mesmo pela limitação dos caracteres.

Enfim, mesmo que em instituições mais modernas tecnologicamente, há sempre os sistemas legados. Estes também são incorporados ao processo de MPI porque trazem informações históricas valiosas para todo o processo assistencial.

Culturalmente e diferentemente dos sistemas norte americanos, os sistemas brasileiros possuem um único campo para capturar os nomes. Para melhorar a eficácia do processo de vinculação é importante que os sistemas tenham a capacidade de separar os nomes, considerando também os primeiros nomes compostos.

Outra capacidade não menos importante é a capacidade de trabalhar com as abreviações nos endereços. Isto requer um dicionário específico de abreviações para o nosso país.

3 - Indexação ou formação dos pares de comparação

Nesta etapa é que se decide quais serão os cadastros que serão comparados entre si, formando assim os chamados pares de comparação.

A decisão de se comparar registros não se baseia apenas nos documentos do paciente, assim como o CPF. Isso acontece porque há casos que não se tem o CPF do paciente ou casos que os filhos recebem o CPF dos pais. Para isto é necessário que o processo utilize os dados probabilísticos, assim como o nome, a data de nascimento, o sexo, os dados de contato e o endereço.

É preciso que este processo tenha algoritmos sofisticados para que os sistemas não gerem um número excessivo de comparações indevidas, assim como não deixem de fora comparações necessárias.

Por exemplo: A comparação de todos os “Josés” com todos os outros “Josés” não seria tão eficaz, pois poderia acarretar numa sobrecarga de processamento.

Outro ponto não menos importante nesta fase é a capacidade de se trabalhar com algoritmos fonéticos para o mercado brasileiro, que são completamente diferentes dos algoritmos americanos.

Isso significa que nomes escritos de maneiras diferentes ou equivocadas também serão considerados no processo. Exemplo: Dois cadastros de um determinado paciente com os nomes Walter Xavier e Valter Chavier podem se referir ao mesmo indivíduo.

O Healthshare MPI utiliza um processo extremamente eficiente de análise combinatória que evita este tipo de problema, utilizando tanto informações demográficas determinísticas quanto probabilísticas.

4 - Pontuação dos pares

Para cada par de comparação gerado, todas as variáveis demográficas são pontuadas separadamente: Primeiros nomes, nomes do meio, sobrenomes, documentos, sexo, cep, telefones, e-mails e endereços.

Antes de iniciar a comparação, é determinado um peso com uma pontuação máxima e mínima para cada variável, considerando a singularidade de cada uma. Por exemplo, o sexo possui um peso menor que a data de nascimento, que possui peso menor que o nome, que possui um peso menor que o CPF. E assim por diante.

Cada variável possui um algoritmo específico não binário de comparação que vai atribuir uma pontuação entre a mínima e a máxima para cada variável demográfica.

Exemplo: Se o sexo for o mesmo, serão atribuídos 2 pontos. Se não for o mesmo será atribuída a pontuação mínima, -4 pontos. Se o CPF for o mesmo, serão atribuídos 14 pontos,

Primeiros nomes e sobrenomes comuns também recebem pontuações menores que nomes mais comuns, assim como Silva e Souza.

Nomes de casada e solteira também devem ser considerados aqui no Brasil.

5 - Avaliação e determinação do identificador unívoco dos pares

Antes desta etapa, é necessário configurar as faixas de pontuação ou limiares que serão utilizados para vincular (mesmo indivíduo) ou não vincular (indivíduos diferentes) os pares de cadastro.

Neste ponto, pode-se definir também a faixa de pontuação dos pares que irão para uma lista de trabalho, passíveis de uma avaliação ou revisão humana.

Limiares a serem configurados:

Vínculo Automático – Acima de quantos pontos os pares serão automaticamente vinculados. Exemplo: Se o total de pontos dos pares estiver acima de 35 os mesmos serão automaticamente vinculados e não necessitarão de revisão humana.

Vínculo com posterior avaliação na Lista de Trabalho – Entre quantos pontos os pares irão para a lista de trabalho como vinculados (mesmos indivíduos) para avaliação humana. Exemplo: Os pares entre 30 e 35 pontos serão vinculados, mas poderão sofrer revisão de um profissional ou equipe designados para esta tarefa.

Não vínculo – Abaixo de quantos pontos os pares não serão vinculados. Exemplo: Se o total de pontos dos pares for abaixo de 30 eles não serão vinculados (indivíduos diferentes).

Não vínculo com revisão posterior na Lista de Trabalho – Entre quantos pontos os pares irão para a lista de trabalho como não vinculado (indivíduos diferentes) para uma revisão humana. Exemplo: Os pares entre 25 e 30 pontos não serão vinculados, mas poderão sofrer revisão de um profissional ou equipe designados para esta tarefa.

Há várias situações de exceções, onde mesmo pares com pontuação elevada podem não se referir ao mesmo indivíduo. Um exemplo típico são os gêmeos, que moram na mesma residência. Para isso é necessário que o produto disponibilize de artifícios para identificar estes casos.

Há outras situações que pares com baixa pontuação podem sofrer revisões se determinadas situações ocorrerem. Exemplo: pares com o mesmo CPF e data de nascimento e baixa pontuação. Este caso é no mínimo curioso, pois pode apontar um problema na baixa qualidade dos dados.

No HealthShare Patient Index, estes dispositivos são chamados de regras de vinculação (rules), que prevalecem sobre a regra de pontuação.

O produto já possui nativamente uma série de regras de exceção e elas são fundamentais para a segurança e confiabilidade de todo o processo.

Após esta etapa, todos os cadastros recebem um identificador universal denominado MPIID - Master Patient Index Identification. Os cadastros que possuírem o mesmo MPIID são referentes ao mesmo indivíduo.

6 – Serviços e API’s

Concluindo todo o processo de vinculação (Matching), é essencial que a plataforma ofereça maneiras passivas ou ativas de se comunicarem ou interoperarem com os sistemas de origem ou outros sistemas. Neste momento entram novamente todos os requisitos de interoperabilidade do produto, que já estão presentes na plataforma HealthShare da Intersystems.

As API’s de consumo do MPI são disponibilizadas neste momento através de protocolos conhecidos (HTTP Soap ou Rest) para que sistemas consigam obter as informações desejadas para diversos casos de uso.

Estes são alguns exemplos comuns de consumo de API’s do HealthShare MPI:

• Obter identificadores de outros sistemas partindo do identificador do sistema consumidor. Este tipo de consulta é denominada pelo IHE como PIX. Exemplo: Antes de enviar a prescrição para o laboratório o sistema de origem envia o seu identificador do cadastro e recebe uma resposta da API com o número do identificador do mesmo paciente no laboratório.

• Realizar pesquisas probabilísticas por dados demográficos. Exemplo: Consultar se existem cadastros demográficos para o paciente de nome Claudio Devecchi Junior. Este tipo de consulta é denominada pelo IHE como PDQ).

• Obter o melhor dado demográfico (Golden Record ou Composite Record) de um determinado paciente para enriquecer os cadastros demográficos ou para aproveitar os seus dados no momento de um determinado cadastro.

Existem também mecanismos ativos, onde o MPI se comunica com os sistemas para enviar informações úteis. Estes mecanismos também podem ser acionados de forma passiva através da chamada das Api’s.

Alguns exemplos são:

• No momento que um cadastro está sendo incluído ou atualizado o MPI pode fazer uma chamada retornando o identificador universal - MPIID. Desta forma o sistema de origem sempre ficará atualizado com este identificador. Quaisquer mudanças nas Listas de Trabalho são gatilhos para este tipo de chamada (callback)

• Quando algum cadastro for incluído e o MPI identificar que já existe esta mesma pessoa no mesmo sistema de origem, já é possível enviar uma notificação de duplicidade. Para os casos de resolução das duplicidades, é importante que exista um serviço específico para receber as mensagens de fusão de pacientes (PIX merge).

Conclusão

Todo o processo descrito anteriormente demonstra um pouco de como o produto HealthShare Patient Index trata dos desafios na área com relação aos cadastros e identificação dos pacientes e como é importante tratar das especificidades não somente do país, mas de organização para organização.

No próximo artigo, falaremos um pouco de como funciona o Healthshare Unified Care Record (UCR) e de como ele é fundamental para ajudar as instituições na abordagem holística do cuidado contínuo, da prevenção e da experiência centrada no paciente.

0
0 145
Job João Henrique de Sá · Fev. 6, 2021

*Analista Ensemble Júnior / Pleno

Próximo Metrô Clínicas

REQUISITOS:

* COS / Portal
* Conhecimento em barramento e protocolos RESTFull / SOAP 
* Integração com banco de dados Oracle / SQL Server

ATIVIDADES:
* Integração de sistemas hospitalares
* Administração do ambiente Ensemble
* Análise de Dados

Enviar CV com pretensão salarial
.

Contratação CLT ou PJ tempo indeterminado

Empresa ..................: JHealth Informatics
Email ........................: rh@jhealth.com.br

0
0 165
Anúncio Angelo Bruno Braga · Fev. 4, 2021

Olá Desenvolvedores,

É um prazer convidá-los, a todos, para o nosso Webinar de lançamento do Concurso InterSystems Grand Prix!

O tópico deste webinar é dedicado ao nosso mega Concurso Grand Prix. Convidamos vocês a utilizarem nossos vários recursos e tecnologias como  o IntegratedML, Native API, multi-modelo, analytics and NLP, Open API e Interoperabilidade e IKO.

Neste webinar falaremos sobre os os tópicos esperados dos participantes e mostraremos como desenvolver, construir e implantar suas aplicações na Plataforma de Dados InterSystems IRIS.

Data & Horário: Segunda-feira, 8 de Fevereiro — 12:00 horário de Brasília

Palestrantes:  
🗣 @Evgeny Shvarov, Gerente do Ecossistema para Desenvolvedores da InterSystems

E alguns de nossos Gerentes de Produtos ... mantenha-se atento às novidades !


<--break->

0
0 53
Artigo Claudio Devecchi · Fev. 1, 2021 3m read

Quando se fala em tecnologia da informação nas instituições de saúde, principalmente nos hospitais e organizações de medicina diagnóstica, os CIO’s e a área de TI sabem muito bem que para que tudo funcione bem, é necessário que um número muito grande de sistemas e aplicações funcionem de maneira integrada.

Talvez a área da saúde seja uma das áreas mais heterogêneas do ponto de vista de negócio, pois engloba além da gestão administrativo financeira, hospitalar, clínica e diagnóstica, uma infinidade de outros sistemas, como o sistema de controle de estacionamento, de hotelaria, dos restaurantes, da recepção, de farmácias, etc. Isso sem contar os sistemas de informação das empresas terceirizadas.

Com tudo isso, é quase que impossível concentrar em um único sistema ou banco de dados todas as informações geradas durante o ciclo completo de atendimento de um paciente. É muito comum, por se tratar de sistemas, de tecnologias e fornecedores diferentes, que uma única pessoa tenha sido cadastrada facilmente em mais de dez sistemas e bancos de dados diferentes, com identificações próprias para cada um.

Considerando todo este cenário, para conseguir operacionalizar os processos, é imprescindível que as empresas tenham plataformas que promovam a interoperabilidade destes sistemas, assim como o IRIS for Health e Health Connect da InterSystems.

Em outras palavras, é preciso que os sistemas “se conversem” para que as informações geradas sejam automaticamente integradas de um sistema para outro, mantendo assim uma consistência e compatibilidade, mesmo que em sistemas e bancos de dados separados.

Ainda assim, as informações podem ser geradas e coletadas em momentos diferentes. Exemplo: Um determinado paciente passou pelo atendimento em uma clínica e neste evento foi orientado a realizar exames específicos na mesma ou em outra instituição e retornar quando os exames estivessem prontos. Além do cadastro e da coleta de informações demográficas deste paciente na clínica, foram realizados outros cadastros no momento da admissão deste paciente nos sistemas de medicina diagnóstica.

Ou seja, se levarmos em conta o processo assistencial de uma única pessoa, teremos informações pertencentes a diferentes cadastros, sob identificações e dados demográficos distintos, coletados por pessoas e de maneiras diferentes.

O fato é que se as empresas não fizerem nada para tratar especificamente desta questão, elas ficarão reféns da segregação dos dados gerados por cadastro, e não consolidados por indivíduo, independentes de quando e onde o mesmo foi atendido. Sempre terão uma visão parcial e não integral de todo o processo, tanto para fins assistenciais, quanto para quaisquer outros fins.

Cada vez mais, os gestores e profissionais de saúde sabem do valor de se ter a visão consolidada de todas as informações geradas em torno do paciente, independentes do tempo e do local, sejam elas administrativas, financeiras, comportamentais e principalmente relacionadas à saúde. Se pararmos pra pensar, nós mesmos gostaríamos de ver num único aplicativo todos os nossos dados de saúde, como os exames por exemplo, independente da instituição que nos atendeu.

Este sonho já está virando realidade em muitas instituições. Graças às plataformas de saúde como InterSystems Healthshare, e produtos como Healthshare Patient Index é possível levar a gestão de informações na área da saúde para o próximo patamar.

No próximo artigo, falaremos um pouco de como funciona o Healthshare Patient Index e de como ele é fundamental para ajudar as empresas a visualizarem o paciente como um único indivíduo e não apenas como um ou mais cadastros.

0
0 149
Artigo Murray Oldfield · jan 18, 2021 9m read

Na última postagem, agendamos a coleta de métricas de desempenho durante 24 horas usando pButtons. Nesta postagem, vamos ver algumas métricas essenciais que estão sendo coletadas e como elas estão ligadas ao hardware do sistema. Também começaremos a explorar a ligação entre as métricas do Caché (ou de qualquer plataforma de dados InterSystems) e as métricas do sistema. Além disso, veremos como você pode usar essas métricas para entender a integridade diária de seus sistemas e diagnosticar problemas no desempenho.


[Veja aqui uma lista de outras postagens do autor na comunidade em inglês](https://community.intersystems.com/post/capacity-planning-and-performance-series-index)

Grupos alimentares de hardware

Grupos alimentares de hardware

Como você verá a medida que avançarmos por esta série de postagens, os componentes do servidor que afetam o desempenho podem ser categorizados como:

  • CPU
  • Memória
  • E/S de armazenamento
  • E/S de rede

Se algum desses componentes estiver sobrecarregado, o desempenho do sistema e a experiência do usuário serão prejudicados. Todos esses componentes estão inter-relacionados, e mudanças em um deles pode afetar os outros, às vezes com consequências inesperadas. Já vi um caso em que corrigir um problema de gargalo de E/S em uma matriz de armazenamento fez o uso de CPU subir para 100%, e a consequência foi uma experiência do usuário ainda pior, pois o sistema ficou livre de repente para fazer mais trabalho, mas não tinha os recursos de CPU necessários devido ao aumento da atividade e taxa de transferência dos usuários.

Também veremos como a atividade do sistema do Caché tem impacto direto nos componentes do sistema. Se houver recursos de E/S de armazenamento limitados, uma mudança positiva que pode ser feita é o aumento da memória do sistema e o aumento da memória dos buffers globais do Caché, o que pode diminuir a E/S de leitura de armazenamento do sistema (mas talvez aumente o uso de CPU!).

Uma das métricas de sistema mais óbvias que deve ser monitorada regularmente ou verificada se os usuários relatarem problemas é o uso de CPU. Pode-se verificar utilizando o top ou nmon no Linux e AIX, ou Monitor de Desempenho do Windows. Como a maioria dos administradores de sistema verificam os dados de CPU regularmente, ainda mais quando são apresentados em gráficos, uma olhada rápida fornece uma boa compreensão da integridade atual do sistema: o que está normal, ou um surto repentino de atividade, que pode ser anormal ou indicar um problema. Nesta postagem, vamos dar uma olhada rápida nas métricas de CPU, mas nos concentraremos nas métricas do Caché. Começaremos verificando os dados do mgstat e como ver os dados em gráficos pode dar uma boa compreensão da integridade do sistema rapidamente.

Introdução ao mgstat

O mgstat é um dos comandos do Caché incluídos e executados no pButtons. O mgstat é uma ferramenta excelente para coletar métricas básicas de desempenho para ajudar a entender a integridade dos sistemas. Veremos os dados do mgstat coletados durante 24 horas em um pButtons, mas, se você quiser capturar dados além do pButtons, o mgstat também pode ser executado sob demanda de forma interativa ou como um trabalho em segundo plano pelo terminal do Caché.

Para executar o mgstat sob demanda pelo namespace %SYS, o formato geral é:

do mgstat(sample_time,number_of_samples,"/caminho_do_arquivo/arquivo.csv",page_length)

Por exemplo, veja abaixo o comando para executar em uma tarefa em segundo plano por uma hora com um período de amostragem de 5 segundos e salvar a saída em um arquivo csv:

job ^mgstat(5,720,"/data/mgstat_data_e_hora_de_hoje.csv")

Por exemplo, para exibir na tela sem algumas colunas, chame a rotina através do label dsp132: Deixarei como tarefa para vocês a verificação da saída para que vocês entendam melhor a diferença.

do dsp132^mgstat(5,720,"",60)

As informações detalhadas das colunas do mgstat estão disponíveis no Guia de monitoramento do Caché na documentação mais recente do Caché: Documentação online da InterSystems

Sobre os dados do mgstat

O pButtons agrupa os dados em um único arquivo HTML, facilitando a navegação e empacotando os dados para envio aos especialistas de suporte da Central de Suporte (WRC) para diagnosticar problemas no desempenho. Entretanto, quando você executa o pButtons por conta própria e deseja exibir os dados em gráficos, eles podem ser separados novamente em um arquivo csv para processamento em gráficos, por exemplo, com o Excel, usando um script de linha de comando ou apenas cortando e colando os dados.

Nesta postagem analisaremos algumas métricas do mgstat para mostrar como somente uma visão rápida dos dados pode indicar se o sistema está com bom desempenho ou se há problemas atuais ou potenciais que afetarão a experiência do usuário.

Glorefs e CPU

O gráfico abaixo mostra o uso de CPU do servidor de banco de dados em um local que executa uma aplicação de hospital com uma alta taxa de transações. Note o pico de atividade durante a manhã, quando há vários ambulatórios, com uma queda durante o almoço, diminuindo então à tarde e à noite. Neste caso, os dados vêm de _(Total)% Tempo do Processador do Monitor de Desempenho do Windows. O formato do gráfico corresponde ao perfil diário de trabalho, sem picos ou depressões incomuns, o que é normal para esse local. Fazendo o mesmo em seu local, você pode começar a estabelecer uma linha de base do que é "normal". Um grande pico, especialmente um de longa duração, pode ser um indicador de problema. Uma postagem futura se concentrará na CPU.

Tempo de CPU

Como referência, este banco de dados está em um servidor Dell R720 com dois processadores E5-2670 de 8 núcleos. O servidor tem 128 GB de memória e 48 GB de buffers de globais.

O próximo gráfico mostra mais dados do mgstat: Glorefs (referências globais) ou acessos ao banco de dados no mesmo dia que o gráfico de CPU. As glorefs indicam a quantidade de trabalho ocorrendo durante a carga de trabalho atual. Embora as referências a globais consumam tempo de CPU, nem sempre elas consomem outros recursos do sistema, como leituras físicas, devido à maneira como o Caché usa o pool global de buffers de memória.

Referências a globais

Nas aplicações típicas do Caché, há uma correlação muito forte entre as glorefs e o uso de CPU.

Outro modo de olhar esses dados de CPU e glorefs é dizendo que a redução das glorefs reduz o uso de CPU, permitindo a implantação em servidores com menos núcleos ou a escalabilidade de sistemas existentes. É possível reduzir as referências globais tornando uma aplicação mais eficiente. Voltaremos a esse conceito em postagens futuras.

PhyRds e Rdratio

O formato da representação gráfica dos dados PhyRds (leituras físicas) e Rdratio (proporção de leituras) do mgstat também pode fornecer informações do que se esperar do desempenho do sistema e ajudar a planejar a capacidade. Vamos analisar com mais detalhes a E/S de armazenamento no Caché em postagens futuras.

PhyRds são simplesmente Operações de Entrada e Saída por Segundo (IOPS) de leitura nos bancos de dados do Caché. Você deverá ver os mesmos valores nas métricas do sistema operacional para discos lógicos e físicos. Lembre-se de que, ao verificar as Operações de Entrada e Saída por Segundo (IOPS) do sistema operacional, também podem estar sendo exibidos dados de outras aplicações que não o Caché. Dimensionar o armazenamento sem levar em conta as Operações de Entrada e Saída por Segundo (IOPS) esperadas é uma receita para o desastre. Você precisa saber as IOPS de seu sistema em horários de pico para planejar a capacidade corretamente. O gráfico abaixo mostra PhyRds entre meia-noite e 15h30.

Leituras físicas

Observe o grande salto de leituras entre 5h30 e 10h. Também há picos menores às 11h e um pouco antes das 14h. Qual você acha que é a causa desses picos? Você também vê esse tipo de picos em seus servidores?

Rdratio é um pouco mais interessante: é a proporção de leituras de blocos lógicos em comparação a leituras de blocos físicos. Portanto, é a proporção de quantas leituras são de buffers de globais (lógicos) da memória e quantas são do disco, que são algumas ordens de grandeza mais lentas. Uma Rdratio alta é uma boa coisa, e chegar perto de zero por longos períodos não é bom.

Proporção de leituras

Observe que, quando as leituras físicas estão altas, Rdratio cai para perto de zero. Nesse local, me pediram para investigar quando o departamento de TI começou a receber ligações de usuários informando que o sistema estava lento por longos períodos. Isso estava acontecendo de maneira aparentemente aleatória durante várias semanas quando me pediram para verificar o sistema.

_Como o pButtons havia sido agendado para execução diária de 24 horas, foi relativamente simples analisar os dados de várias semanas passadas para começar a ver um padrão de PhyRds alta e Rdratio baixa, com uma correlação com as ligações de suporte.*

Após uma análise mais detalhada, descobriu-se que a causa era um novo funcionário que executava diversos relatórios com parâmetros ruins, além de consultas mal escritas sem índices apropriados, o que causava muitas leituras no banco de dados. Essa era a causa da lentidão aparentemente aleatória. Como esses relatórios de longa execução lêem dados dos buffers de globais, a consequência é que os dados interativos dos usuários estavam sendo obtidos do armazenamento físico, em vez da memória, e o armazenamento estava sendo sobrecarregado para atender às solicitações de leitura.

O monitoramento das métricas PhyRds e Rdratio dará uma ideia da integridade de seus sistemas e talvez permitirá que você descubra relatórios ou consultas ruins. Pode haver um motivo válido para uma PhyRds alta: talvez um relatório precise ser executado em determinada hora. Com os sistemas operacionais modernos de 64 bits e servidores com alta capacidade de memória física, você deverá conseguir minimizar a PhyRds em seus sistemas de produção.

Caso a PhyRds esteja alta em seu sistema, você pode considerar algumas estratégias: - Melhorar o desempenho aumentando o número de buffers (globais) de banco de dados (e a memória do sistema). - Relatórios ou extrações de longa duração podem ser feitos fora do horário comercial. - Relatórios somente leitura de longa duração, trabalhos em lote ou extrações de dados podem ser feitos em um servidor Shadow ou um membro de espelhamento assíncrono para minimizar o impacto nos usuários interativos e para diminuir a carga de recursos do sistema, como CPU e Operações de Entrada e Saída por Segundo (IOPS).

Geralmente, é bom ter uma PhyRds baixa, e é nossa meta ao dimensionar os sistemas. Entretanto, se a PhyRds estiver baixa e os usuários estiverem reclamando do desempenho, você pode verificar outros fatores para confirmar que o armazenamento não é o gargalo. A quantidade de leituras pode estar baixa porque o sistema não consegue mais atender à demanda. Veremos o armazenamento com mais detalhas em uma postagem futura.

Resumo

Nesta postagem, verificamos como olhar graficamente as métricas coletadas no pButtons pode fornecer uma compreensão da integridade rapidamente. Em postagens futuras, analisarei com mais detalhes a ligação entre as métricas de sistema e do Caché e como você pode usá-las para se planejar para o futuro.

0
0 155
Artigo Guillaume Rongier · jan 11, 2021 9m read

Swift-FHIR-Iris

Aplicativo iOS para exportar dados HealthKit para o InterSystems IRIS for Health (ou qualquer repositório FHIR)

main

Índice

Objetivo desta demonstração

O objetivo é criar uma demonstração de ponta a ponta do protocolo FHIR.

O que quero dizer com de ponta a ponta é, de uma fonte de informação como um iPhone. Colete seus dados de saúde no formato Apple (HealthKit), transforme-os em FHIR e envie para o repositório InterSystems IRIS for Health.

Essas informações devem ser acessíveis por meio de uma interface web.

iPhone -> InterSystems FHIR -> Página Web.

Como executar esta demonstração

Pré-requisitos

  • Para a parte do cliente (iOS)
    • Xcode 12
  • Para o servidor e aplicativo web
    • Docker

Instale o Xcode

Não há muito o que falar aqui, abra a AppStore, procure por Xcode, instale.

Abra o projeto SwiftUi

Swift é a linguagem de programação da Apple para iOS, Mac, Apple TV e Apple Watch. É o substituto do objective-C.

Clique duas vezes em Swift-FHIR-Iris.xcodeproj

Abra o simulador clicando na seta superior esquerda.

xcode

Configure o simulador

Vá em Health

Clique em Steps

Add Data

simulator

Inicie o servidor InterSystems FHIR

Na pasta raiz deste git, execute o seguinte comando:

docker-compose up -d

No final do processo de construção, você será capaz de se conectar ao repositório FHIR:

http://localhost:32783/fhir/portal/patientlist.html

portal

Este portal foi feito por @diashenrique.

Com algumas modificações para lidar com os passos de atividade da Apple.

Brinque com o aplicativo iOS

O aplicativo primeiro solicitará que você aceite o compartilhamento de algumas informações.

Clique em authorize

authorize

Então você pode testar o servidor FHIR clicando em 'Save and test server'

As configurações padrão apontam para a configuração do docker.

Se tiver sucesso, você pode inserir as informações do seu paciente.

Nome, Sobrenome, Aniversário, Gênero.

Salve o paciente para FHIR. Um pop-up mostrará seu ID FHIR único.

savepatient

Consulte este paciente no portal:

Acesse: http://localhost:32783/fhir/portal/patientlist.html

Podemos ver aqui, que há um novo paciente "toto" com 0 atividades.

patient portal

Envie suas atividades:

Volte para o aplicativo iOS e clique em Step count

Este painel resume a contagem de passos da semana. No nosso caso, 2 entradas.

Agora você pode enviá-los para o InterSystems IRIS FHIR clicando em enviar.

ios send

Consulte as novas atividades no portal:

Podemos ver agora que o Toto tem duas novas observações e atividades.

portal activites

Você pode eventualmente clicar no botão do gráfico para exibi-lo como um gráfico.

portal charts

Como funciona

iOS

A maior parte desta demonstração é construída em SwiftUI.

https://developer.apple.com/xcode/swiftui/

Que é o framework mais recente para iOS e co.

Como verificar a autorização para dados de saúde

Ele está na classe SwiftFhirIrisManager.

Esta classe é um singleton e estará carregando todo o aplicativo com a anotação @EnvironmentObject.

Mais informações em: https://www.hackingwithswift.com/quick-start/swiftui/how-to-use-environmentobject-to-share-data-between-views

O método requestAuthorization:

    // Solicita autorização para acessar o HealthKit.
    func requestAuthorization() {
        // Solicitando autorização.
        /// - Tag: RequestAuthorization

        let writeDataTypes: Set<HKSampleType> = dataTypesToWrite()
        let readDataTypes: Set<HKObjectType> = dataTypesToRead()

        // pedido de autorização
        healthStore.requestAuthorization(toShare: writeDataTypes, read: readDataTypes) { (success, error) in
            if !success {
                // Trata o erro aqui.
            } else {

                DispatchQueue.main.async {
                    self.authorizedHK = true
                }

            }
        }
    }

Onde healthStore é o objeto de HKHealthStore().

O HKHealthStore é como um banco de dados de dados de saúde no iOS.

dataTypesToWrite e dataTypesToRead são os objetos que gostaríamos de consultar no banco de dados.

A autorização precisa de um propósito e isso é feito no arquivo xml Info.plist adicionando:

    <key>NSHealthClinicalHealthRecordsShareUsageDescription</key>
    <string>Read data for IrisExporter</string>
    <key>NSHealthShareUsageDescription</key>
    <string>Send data to IRIS</string>
    <key>NSHealthUpdateUsageDescription</key>
    <string>Write date for IrisExporter</string>

Como conectar a um repositório FHIR

Para esta parte usei o pacote FHIR do Smart-On-FHIR: https://github.com/smart-on-fhir/Swift-FHIR

A classe usada é a FHIROpenServer.

    private func test() {

        progress = true

        let url = URL(string: self.url)

        swiftIrisManager.fhirServer = FHIROpenServer(baseURL : url! , auth: nil)

        swiftIrisManager.fhirServer.getCapabilityStatement() { FHIRError in

            progress = false
            showingPopup = true

            if FHIRError == nil {
                showingSuccess = true
                textSuccess = "Connected to the fhir repository"
            } else {
                textError = FHIRError?.description ?? "Unknow error"
                showingSuccess = false
            }

            return
        }

    }

Isso cria um novo objeto fhirServer no singleton swiftIrisManager.

Em seguida, usamos getCapabilityStatement()

Se pudermos recuperar a declaração de capacidade do servidor FHIR, isso significa que nos conectamos com sucesso ao repositório FHIR.

Este repositório não está em HTTPS, por padrão, a apple bloqueia este tipo de comunicação.

Para permitir o suporte HTTP, o arquivo xml Info.plist pode ser editado assim:

    <key>NSAppTransportSecurity</key>
    <dict>
        <key>NSExceptionDomains</key>
        <dict>
            <key>localhost</key>
            <dict>
                <key>NSIncludesSubdomains</key>
                <true/>
                <key>NSExceptionAllowsInsecureHTTPLoads</key>
                <true/>
            </dict>
        </dict>
    </dict>

Como salvar um paciente no repositório FHIR

Operação básica verificando primeiro se o paciente já existe no repositório

Patient.search(["family": "\(self.lastName)"]).perform(fhirServer)

Isso pesquisa por paciente com o mesmo sobrenome.

Aqui, podemos imaginar outros cenários, como token Oauth2 e JWT para unir o patientid e seu token. Mas para esta demonstração, mantemos as coisas simples.

Em seguida, se o paciente existe, nós o recuperamos, caso contrário, criamos o paciente:

    func createPatient(callback: @escaping (Patient?, Error?) -> Void) {
        // Cria um novo paciente
        let patient = Patient.createPatient(given: firstName, family: lastName, dateOfBirth: birthDay, gender: gender)

        patient?.create(fhirServer, callback: { (error) in
            callback(patient, error)
        })
    }

Como extrair dados do HealthKit

Isso é feito consultando o healthkit Store (HKHealthStore())

Aqui nós estamos consultando os passos.

Prepare a consulta com o predicado.

        //Semana passada
        let startDate = swiftFhirIrisManager.startDate
        //Agora
        let endDate = swiftFhirIrisManager.endDate

        print("Collecting workouts between \(startDate) and \(endDate)")

        let predicate = HKQuery.predicateForSamples(withStart: startDate, end: endDate, options: HKQueryOptions.strictEndDate)

Em seguida, a própria consulta com seu tipo de dados (HKQuantityType.quantityType(forIdentifier: .stepCount)) e o predicado.

func queryStepCount(){

        //Semana passada
        let startDate = swiftFhirIrisManager.startDate
        //Agora
        let endDate = swiftFhirIrisManager.endDate

        print("Collecting workouts between \(startDate) and \(endDate)")

        let predicate = HKQuery.predicateForSamples(withStart: startDate, end: endDate, options: HKQueryOptions.strictEndDate)

        let query = HKSampleQuery(sampleType: HKQuantityType.quantityType(forIdentifier: .stepCount)!, predicate: predicate, limit: HKObjectQueryNoLimit, sortDescriptors: nil) { (query, results, error) in

            guard let results = results as? [HKQuantitySample] else {
                   return
            }

            process(results, type: .stepCount)

        }

        healthStore.execute(query)

    }

Como transformar dados HealthKit em FHIR

Para esta parte, usamos o pacote Microsoft HealthKitToFHIR

https://github.com/microsoft/healthkit-to-fhir

Este é um pacote útil que oferece factories para transformar HKQuantitySample em FHIR Observation

     let observation = try! ObservationFactory().observation(from: item)
      let patientReference = try! Reference(json: ["reference" : "Patient/\(patientId)"])
      observation.category = try! [CodeableConcept(json: [
          "coding": [
            [
              "system": "http://terminology.hl7.org/CodeSystem/observation-category",
              "code": "activity",
              "display": "Activity"
            ]
          ]
      ])]
      observation.subject = patientReference
      observation.status = .final
      print(observation)
      observation.create(self.fhirServer,callback: { (error) in
          if error != nil {
              completion(error)
          }
      })

Onde item é um HKQuantitySample, em nosso caso, um tipo stepCount.

O factory faz a maioria do trabalho de converter 'unit' e 'type' para FHIR codeableConcept e 'value' para FHIR valueQuantity.

A referência ao PatientId é feita manualmente, lançando uma referência json fhir.

let patientReference = try! Reference(json: ["reference" : "Patient/\(patientId)"])

O mesmo é feito para a categoria:

      observation.category = try! [CodeableConcept(json: [
          "coding": [
            [
              "system": "http://terminology.hl7.org/CodeSystem/observation-category",
              "code": "activity",
              "display": "Activity"
            ]
          ]
      ])]

Por fim, a observação é criada no repositório fhir:

      observation.create(self.fhirServer,callback: { (error) in
          if error != nil {
              completion(error)
          }
      })

Backend (FHIR)

Não há muito a dizer, é baseado no modelo fhir da comunidade InterSystems:

https://openexchange.intersystems.com/package/iris-fhir-template

Frontend

É baseado no trabalho de Henrique, que é um bom front end para repositórios FHIR feitos em jquery.

https://openexchange.intersystems.com/package/iris-fhir-portal

0
0 151
Artigo Murray Oldfield · Dez. 8, 2020 8m read

Sua aplicação está implantada e tudo está funcionando bem. Ótimo, bate aqui! Então, do nada, o telefone começa a tocar sem parar – são os usuários reclamando que, às vezes, a aplicação está "lenta". Mas o que isso significa? Às vezes? Quais ferramentas você tem e quais estatísticas você deve examinar para encontrar e resolver essa lentidão? A infraestrutura do seu sistema está à altura da tarefa de carga do usuário? Que perguntas de design de infraestrutura você deveria ter feito antes de entrar em produção? Como você pode planejar a capacidade de um novo hardware com confiança sem excesso de especificações? Como você pode parar o telefone de tocar? Como você poderia ter impedido o telefone de tocar em primeiro lugar?


Veja aqui uma lista das outras postagens desta série


Esta será uma jornada

Este é a primeira postagem de uma série que explorará as ferramentas e métricas disponíveis para monitorar, revisar e solucionar problemas de desempenho de sistemas, bem como considerações de design e arquitetura de sistema que afetam o desempenho. Ao longo do caminho, iremos percorrer algumas trilhas para entender o desempenho do Caché, sistemas operacionais, hardware, virtualização e outras áreas que se tornam tópicos a partir de seu feedback nos comentários.

Seguiremos o ciclo de feedback fornecido pelos dados de desempenho para visualizar as vantagens e limitações das aplicações e da infraestrutura implantadas e, em seguida, voltar para uma melhor concepção e planejamento de capacidade.

Não é preciso dizer que você deve revisar as métricas de desempenho constantemente. É lamentável o número de vezes que os clientes são surpreendidos por problemas de desempenho que estavam visíveis por um longo tempo, se eles tivessem olhando os dados. Mas, é claro, que a questão é: quais dados? Começaremos a jornada coletando algumas métricas básicas do Caché e do sistema para que possamos ter uma ideia da integridade do seus sistema atual. Em postagens posteriores, mergulharemos no significado das principais métricas.

Há muitas opções disponíveis para o monitoramento do sistema – internamente do Caché e externamente. Vamos explorar um monte deles nesta série. 

Para começar, veremos minha ferramenta favorita para coleta contínua de dados que já está instalada em todos os sistemas Caché – o ^pButtons.

Para ter certeza de que você tem a última cópia do pButtons, reveja a seguinte postagem:

https://community.intersystems.com/post/intersystems-data-platforms-and-performance-%E2%80%93-how-update-pbuttons

Coletando métricas de desempenho do sistema – ^pButtons

O utilitário Caché pButtons gera um relatório de desempenho em HTML legível a partir dos arquivos de log que ele cria. A saída das métricas de desempenho pelo pButtons pode ser facilmente extraída, mapeada e revisada. 

Os dados coletados no arquivo HTML pelo pButtons incluem:

  • Configuração do Caché: com configuração, mapeamentos de unidades, etc.
  • mgstat: Métricas de desempenho do Caché – a maioria dos valores são médios por segundo.
  • Unix: vmstat e iostat – recursos do sistema operacional e métricas de desempenho.
  • Windows: monitor de desempenho – recursos do Windows e métricas de desempenho.
  • Outras métricas que serão úteis.

A coleta de dados do pButtons tem muito pouco impacto no desempenho do sistema, as métricas já estão sendo coletadas pelo sistema, o pButtons simplesmente as empacota para facilitar o arquivamento e transporte. 

Para manter uma linha de base, para análise de tendências e solução de problemas, é uma boa prática realizar uma coleta com o pButtons de 24 horas (meia-noite à meia-noite) todos os dias, para um ciclo de negócios completo. Um ciclo de negócios pode durar um mês ou mais, por exemplo, para capturar dados de processamento no final do mês. Se você não tiver nenhum outro monitoramento de desempenho externo ou coleta, você pode executar o pButtons durante o ano todo. 

Os seguintes pontos-chave devem ser observados:

  • Mude o diretório de log para um local longe dos dados de produção para armazenar arquivos de saída acumulados e evitar problemas de disco cheio!
  • Execute um script do sistema operacional ou compacte e arquive o arquivo pButtons regularmente. Isso é especialmente importante no Windows, pois os arquivos podem ser grandes.
  • Revise os dados regularmente!

No caso de um problema que necessite de análise imediata, os dados do pButtons podem ser visualizados (coletados imediatamente) enquanto as métricas continuam a ser armazenadas para a coleta no final dos dias de execução.

Para obter mais informações sobre pButtons, incluindo visualização, interrupção de uma execução e adição de coleta de dados personalizados, veja o Guia de Monitoramento Caché na documentação mais recente do  Caché: 

http://docs.intersystems.com

Os dados do arquivo HTML pButtons podem ser separados e extraídos (para arquivos CSV, por exemplo) para processamento em gráficos ou outra análise por script ou simplesmente recortar e colar. Veremos exemplos da saída em gráficos posteriormente na próxima postagem.

É claro que, se você tiver problemas urgentes de desempenho, entre em contato com a Central de Suporte (WRC).

Agende a coleta de dados de 24 horas do pButtons

O ^pButtons pode ser iniciado manualmente a partir do prompt do terminal ou agendado. Para agendar uma coleta diária de 24 horas:

  1. Inicie o terminal Caché, mude para o %SYS namespace e execute o pButtons manualmente uma vez para configurar as estruturas de arquivo do pButtons:

    %SYS>d ^pButtons Current log directory: /db/backup/benchout/pButtonsOut/ Available profiles: 1 12hours - 12 hour run sampling every 10 seconds 2 24hours - 24 hour run sampling every 10 seconds 3 30mins - 30 minute run sampling every 1 second 4 4hours - 4 hour run sampling every 5 seconds 5 8hours - 8 hour run sampling every 10 seconds 6 test - A 5 minute TEST run sampling every 30 seconds

Selecione a opção 6. para teste, amostragem de execução de TESTE de 5 minutos a cada 30 segundos. Observe que sua numeração pode ser diferente, mas o teste deve ser óbvio.

Durante a execução, execute Collect^pButtons (conforme mostrado abaixo), você verá informações incluindo o runid. Neste caso, “20160303_1851_test”.

%SYS>d Collect^pButtons
Current Performance runs:
    <strong>20160303_1851_test</strong>        ready in 6 minutes 48 seconds nothing available to collect at the moment.
%SYS>

Observou que esta execução de 5 minutos leva 6 minutos e 48 segundos para finalizar? O pButtons adiciona um período de carência de 2 minutos a todas as execuções permitindo um tempo para a coleta e ordenação dos logs no formato HTML. 

  1. IMPORTANTE! Altere o diretório de saída do log pButtons - o local de saída padrão é a pasta /mgr. Por exemplo, no Unix, o caminho para o diretório de log pode ser assim:
do setlogdir^pButtons("/algum_lugar_com_muito_espaço/perflogs/")

Certifique-se de que o Caché tenha permissões de gravação para o diretório e que haja espaço em disco suficiente disponível para acumular os arquivos de saída.

3. Crie um novo perfil de 24 horas com intervalos de 30 segundos executando o seguinte:

write $$addprofile^pButtons("<strong>My_24hours_30sec</strong>","24 hours 30 sec interval",30,2880)

Verifique se o perfil foi adicionado ao pButtons:

%SYS>d ^pButtons
Current log directory: /db/backup/benchout/pButtonsOut/
Available profiles:
     1  12hours     - 12 hour run sampling every 10 seconds
     2  24hours     - 24 hour run sampling every 10 seconds
     3  30mins      - 30 minute run sampling every 1 second
     4  4hours      - 4 hour run sampling every 5 seconds
     5  8hours      - 8 hour run sampling every 10 seconds
     6  My_24hours_30sec- 24 hours 30 sec interval
     7  test        - A 5 minute TEST run sampling every 30 seconds

select profile number to run:
Nota: Você pode variar o intervalo de coleta - 30 segundos é bom para monitoramento de rotina. Eu não usaria menos de 5 segundos para uma execução de rotina de 24 horas (…”,5,17280), pois os arquivos de saída podem se tornar muito grandes à medida que pButtons coleta dados a cada tique do intervalo. Se você está resolvendo problemas em um determinado momento do dia e deseja dados mais granulares, use um dos perfis padrão ou crie um novo perfil personalizado com um período de tempo mais curto, por exemplo, 1 hora com intervalo de 5 segundos (…”,5,720). Vários pButtons podem ser executados ao mesmo tempo, portanto, você pode ter pButtons curtos com intervalo de 5 segundos em execução ao mesmo tempo que os pButtons de 24 horas.
  1. Dica Para sites UNIX, revise o comando disk. Os parâmetros padrão usados com o comando 'iostat' podem não incluir os tempos de resposta do disco. Primeiro exiba quais comandos de disco estão configurados atualmente:
%SYS>zw ^pButtons("cmds","disk")
^pButtons("cmds","disk")=2
^pButtons("cmds","disk",1)=$lb("iostat","iostat ","interval"," ","count"," > ")
^pButtons("cmds","disk",2)=$lb("sar -d","sar -d ","interval"," ","count"," > ")

Para coletar estatísticas de disco, use o comando apropriado para editar a sintaxe de sua instalação do UNIX. Observe o espaço à direita. Aqui estão alguns exemplos:

LINUX:     set $li(^pButtons("cmds","disk",1),2)="iostat -xt "
AIX:       set $li(^pButtons("cmds","disk",1),2)="iostat -sadD "
VxFS:      set ^pButtons("cmds","disk",3)=$lb("vxstat","vxstat -g DISKGROUP -i ","interval"," -c ","count"," > ")

Você pode criar arquivos HTML pButtons muito grandes, executando os comandos iostat e sar. Para avaliações regulares de desempenho, geralmente uso apenas o iostat. Para configurá-lo há apenas um comando:

set ^pButtons("cmds","disk")=1

Mais detalhes sobre como configurar pButtons estão na documentação on-line.

5. Programe o pButtons para iniciar à meia-noite no Portal de Gerenciamento > Operação de Sistema > Gerenciado de Tarefas:

Namespace: %SYS
 Task Type: RunLegacyTask
 ExecuteCode: Do run^pButtons("My_24hours_30sec")
 Task Priority: Normal
 User: superuser
 How often: Once daily at 00:00:01

Coletando dados com pButtons

O pButtons disponível em versões mais recentes das Plataformas de Dados InterSystems incluem a coleta automática. Para coletar e ordenar manualmente os dados em um arquivo HTML no %SYS namespace, execute o seguinte comando para gerar quaisquer arquivos de saída HTML pButtons pendentes:

do Collect^pButtons

O arquivo HTML estará no logdir que você configurou no passo 2 (se você não configurou, vá e faça agora!). Caso contrário, o local padrão é <Caché install dir/mgr> <Caché install dir/mgr>

Os arquivos são nomeados como <hostname_instance_Name_date_time_profileName.html><hostname_instance_Name_date_time_profileName.html> Ex. vsan-tc-db1_H2015_20160218_0255_test.html

Considerações sobre o Monitor de Desempenho do Windows

Se o sistema operacional for Windows, o Monitor de Desempenho do Windows (perfmon) pode ser usado para coletar dados em sincronia com as outras métricas coletadas. Em distribuições Caché mais antigas do pButtons, o perfmon do Windows precisa ser configurado manualmente. Se houver uma demanda nos comentários da postagem, escreverei uma postagem sobre a criação de um template perfmon para definir os contadores de desempenho a serem monitorados e agendar a execução para o mesmo período e intervalo que o pButtons.

Resumo

Esta postagem nos fez começar a coletar alguns dados para analisar. No final da semana, começarei a examinar alguns dados de amostra e o que isso significa. Você pode acompanhar os dados coletados em seus próprios sistemas. Vejo você então.

http://docs.intersystems.com

0
0 199
Anúncio Angelo Bruno Braga · Dez. 4, 2020

Olá Desenvolvedores!

Aqui estão os bônus tecnológicos para o Concurso Analítico da InterSystems que irão prover pontos extras na votação:

  • InterSystems IRIS BI 
  • InterSystems IRIS NLP
  • IntegratedML
  • Uso de dados reais
  • Implantação em Pacote ZPM
  • Uso de contêiner Docker 

Vejam os detalhes abaixo:

InterSystems IRIS BI - 1 ponto

O InterSystems IRIS BI é uma funcionalidade do IRIS que lhe permite a opção de criar cubos e tabelas pivô a partir dos dados persistentes do IRIS e entregar estes dados como informação para usuários através do uso de painéis interativos.

Aprenda mais

0
0 72
Anúncio Tatiana Krupenya · Dez. 2, 2020

É um prazer anunciar que o DBeaver suporta a plataforma de dados InterSystems IRIS nativamente desde a versão 7.2.4. Você não precisa realizar uma configuração manual mais, basta identificar o ícone do IRIS na lista de conexões. 

<--break->Todos os campos necessários já vem preenchidos mas, não se esqueça de colocar seu usuário e senha !!!!

0
0 405
Anúncio Angelo Bruno Braga · Nov. 23, 2020

Olá Desenvolvedores,

Concurso de Interoperabilidade da InterSystems chegou ao seu fim. Obrigado a todos pela participação em nossa empolgante maratona de codificação !

E agora é o momento de anunciarmos os vencedores ! 

 

Nossos aplausos e congratulações vão para os seguintes desenvolvedores e suas aplicações:

2
0 124
Anúncio Angelo Bruno Braga · Nov. 23, 2020

Olá Comunidade,

É um prazer convidá-los para o  encontro online com os ganhadores do Concurso de Interoperabilidade da InterSystems!

Dia e horário: Sexta-feira, 27 de Novembro de 2020 – 12:00 horário de Brasília

O que lhe aguarda neste encontro virtual ?

  • A biografia de nossos ganhadores.
  • Demonstrações de suas aplicações.
  • Uma discussão aberta sobre as tecnologias utilizadas, bônus, dúvidas e planos para os próximos concursos.

0
0 88
Artigo Mark Bolinsky · Nov. 23, 2020 9m read

Introdução

Recentemente, a InterSystems concluiu uma comparação de desempenho e escalabilidade da IRIS for Health 2020.1, cujo foco foi a interoperabilidade do HL7 versão 2. Este artigo descreve a taxa de transferência observada para diversas cargas de trabalho e também apresenta diretrizes de configuração geral e dimensionamento para sistemas nos quais a IRIS for Health é usada como um mecanismo de interoperabilidade para as mensagens do HL7v2.

A comparação simula cargas de trabalho parecidas com as de ambientes em produção. Os detalhes da simulação são descritos na seção Descrição e metodologia das cargas de trabalho. As cargas de trabalho testadas consistiram de cargas de Patient Administration (ADT) e Observation Result (ORU) do HL7v2 e incluíram transformações e novo roteamento.

A versão 2020.1 da IRIS for Health demonstrou uma taxa de transferência sustentada de mais de 2,3 bilhões de mensagens (entrada e saída) por dia com um servidor simples com processadores escaláveis Intel® Xeon® de 2ª geração e armazenamento Intel® Optane™ SSD DC P4800X Series. Os resultados mais que dobraram a escalabilidade em relação à comparação de taxa de transferência anterior do Ensemble 2017.1 HL7v2.

Durante os testes, a IRIS for Health foi configurada para preservar a ordem PEPS (primeiro a entrar, primeiro a sair) e para fazer a persistência completa das mensagens e filas para cada mensagem de entrada e saída. Ao fazer a persistência das filas e mensagens, a IRIS for Health proporciona proteção dos dados caso haja travamento do sistema, além de recursos completos de procura e reenvio de mensagens passadas.

Além disso, as diretrizes de configuração são abordadas nas seções abaixo, que ajudarão a escolher uma configuração e implantação adequadas para atender às exigências de desempenho e escalabilidade de suas cargas de trabalho.

Os resultados mostram que a IRIS for Health consegue atender a altíssimas taxas de transferência de mensagens em hardware de prateleira e, na maioria dos casos, permite que um único servidor pequeno forneça interoperabilidade de HL7 para toda a organização.


Visão geral dos resultados

Foram usadas três cargas de trabalho para representar diferentes aspectos da atividade de interoperabilidade do HL7:

  • Carga de trabalho T1: usa passagem simples de mensagens HL7, com uma mensagem de saída para cada mensagem de entrada. As mensagens são passadas diretamente do serviço empresarial do Ensemble (Ensemble Business Service) para a operação de negócios do Ensemble (Ensemble Business Operation), sem um mecanismo de roteamento. Nenhuma regra de roteamento foi usada, e nenhuma transformação foi executada. Foi criada uma instância de mensagens HL7 no banco de dados por mensagem de entrada.
  • Carga de trabalho T2: usa um mecanismo de roteamento para alterar uma média de 4 segmentos da mensagem de entrada e roteá-la para uma única interface de saída (1 para 1 com uma transformação). Para cada mensagem de entrada, foi executada uma transformação de dados, e foram criados dois objetos de mensagem HL7 no banco de dados.
  • Carga de trabalho T4: usa um mecanismo de roteamento para rotear separadamente mensagens modificadas para cada uma das quatro interfaces de saída. Em média, 4 segmentos da mensagem de entrada foram modificadas em cada transformação (1 entrada para 4 saídas com 4 transformações). Para cada mensagem de entrada, foram executadas quatro transformações de dados, foram enviadas quatro mensagens de saída, e foram criados cinco objetos de mensagem HL7 no banco de dados.

As três cargas de trabalha foram executadas em um sistema físico de 48 núcleos com dois processadores escaláveis Intel® Xeon® Gold 6252, com das unidades Intel® Optane™ SSD DC P4800X de 750 GB, com o Red Hat Enterprise Linux 8. Os dados são apresentados como o número de mensagens por segundo (e por hora) de entrada, o número por segundo (e por hora) de saída, bem como o total de mensagens (de entrada e de saída) em 10 horas por dia. Além disso, o uso de CPU é apresentado como medida dos recursos de sistema disponíveis para determinado nível de taxa de transferência. 

Resultados de escalabilidade

Tabela 1: Resumo da  taxa de transferência das quatro cargas de trabalho nesta configuração de hardware testada:

*Carga de trabalho combinada, com 25% de T1, 25% de T2 e 50% de T4


Descrição e metodologia das cargas de trabalho

As cargas de trabalho testadas incluíram mensagens de Patient Administration (ADT) e Observation Result (ORU) do HL7v2, com um tamanho médio de 1,2 KB e uma média de 14 segmentos. Cerca de 4 segmentos foram modificados pelas transformações (para cargas de trabalho T2 e T4). Os testes representam 48 a 128 interfaces de entrada de 48 a 128 interfaces de saída enviando e recebendo mensagens por TCP/IP.

Na carga de trabalho T1, foram usados quatro namespaces separados, cada um com 16 interfaces; na carga de trabalho T2, foram usados três namespaces, cada um com 16 interfaces; na carga de trabalho T4, foram usados quatro namespaces, cada um com 32 interfaces; e, na última "carga de trabalho combinada", foram usados três namespaces, com 16 interfaces para carga de trabalho T1, 16 para carga de trabalho T2 e 32 para carga de trabalho T4.

A escalabilidade foi mensurada aumentando-se gradualmente o tráfego em cada interface para descobrir a taxa de transferência mais alta com critérios de desempenho aceitável. Para que o desempenho seja aceitável, as mensagens devem ser processadas a uma taxa sustentada, sem filas, sem atrasos mensuráveis na entrada das mensagens, e o uso médio de CPU deve ficar abaixo de 80%.

Testes anteriores demonstraram que o tipo de mensagem HL7 usado não é significativo para o desempenho e a escalabilidade do Ensemble. Os fatores significativos são o número de mensagens de entrada, o tamanho das mensagens de entrada e saída, o número de novas mensagens criadas no mecanismo de roteamento e o número de segmentos modificados.

Além disso, testes anteriores demonstraram que o processamento de campos específicos de uma mensagem HL7 em uma transformação de dados não costuma impactar o desempenho de forma significativa. As transformações feitas nesses testes usaram atribuições bem simples para criar novas mensagens. É importante salientar que processamentos complexos (como o uso de consultas SQL extensivas em uma transformação de dados) podem fazer os resultados variarem.

Testes anteriores também indicaram que o processamento de regras não costuma ser significativo. Os conjuntos de regras de roteamento usados nos testes tiveram uma média de 32 regras, e todas eram simples. É importante salientar que conjuntos de regras extremamente grandes ou complexos podem fazer os resultados variarem. 

Hardware 

Configuração do servidor

Os testes utilizaram um servidor com processadores escaláveis Intel® Xeon® Gold 6252 "Cascade Lake" de 2ª geração, com 48 núcleos de 2,1 GHz em um sistema com 2 soquetes, 24 núcleos por soquete com 192 GB de DR4-2933 DRAM e interface de rede Ethernet de 10 Gbits. Foi usado o sistema operacional Red Hat Enterprise Linux Server 8 para esse teste, com a IRIS for Health 2020.1

Configuração do disco

É feita a persistência completa no disco das mensagens que passam pela IRIS for Health. Nesse teste, duas unidades Intel® Optane™ SSD DC P4800X de 750 GB internas do sistema foram usadas, dividindo-se os bancos de dados em una unidade e os registros de log em outro. Além disso, para garantir uma comparação real, foi ativado o commit síncrono nos registros de log para forçar a durabilidade dos dados. Para a carga de trabalho T4 descrita anteriormente neste documento, cada mensagem HL7 de entrada gera aproximadamente 50 KB de dados, que podem ser divididos conforme indicado na tabela 2. Os diários de transações geralmente são mantidos na linha por menos tempo que os logs ou dados das mensagens, e isso deve ser levado em conta ao calcular o espaço em disco total necessário.

Tabela 2: Requisitos de disco por mensagem HL7 de entrada para carga de trabalho T4  

ContribuinteRequisito de dados
Dados do segmento4,5 KB
Objeto da mensagem HL72 KB
Cabeçalho da mensagem1 KB
Log de regra de encaminhamento0,5 KB
Diários de transações42 KB
Total50 KB

Lembre-se de que a carga de trabalho T4 usa um mecanismo de roteamento para rotear separadamente mensagens modificadas para cada uma das quatro interfaces de saída. Em média, 4 segmentos da mensagem de entrada foram modificadas em cada transformação (1 entrada para 4 saídas com 4 transformações). Para cada mensagem de entrada, foram executadas quatro transformações de dados, foram enviadas quatro mensagens de saída e foram criados cinco objetos de mensagem HL7 no banco de dados.

Ao configurar sistemas para uso em produção, os requisitos reais devem ser calculados considerando-se os volumes de entrada diários, bem como o agendamento de limpeza de mensagens HL7 e a política de retenção de arquivos de registros de logs. Além disso, é necessário configurar no sistema um espaço adequado para registros de log, para evitar que os volumes de disco de registros de log fiquem cheios. Os arquivos de registros de log devem ficar em discos separados fisicamente dos arquivos de banco de dados, tanto por questões de desempenho quanto de confiabilidade.

Conclusão

A taxa de transferência de mensagens HL7v2 da InterSystems IRIS for Health demonstrada nesses testes ilustra a enorme capacidade de taxa de transferência com uma configuração básica de servidor de prateleira com 2 soquetes para dar suporte a cargas de trabalho de mensagens bastante exigentes de qualquer organização. Além disso, a InterSystems está comprometida a aprimorar constantemente o desempenho e a escalabilidade a cada versão, além de aproveitar os benefícios das tecnologias mais recentes de servidor e nuvem.

O gráfico abaixo apresenta uma visão geral e um comparativo do aumento da taxa de transferência das comparações anteriores do Ensemble 2015.1 e Ensemble 2017.1 com processadores Intel® E5-2600 v3 (Haswell) e a comparação do Ensemble 2017.1 com processadores escaláveis Intel® Platinum Series (Skylake) de 1ª geração em relação aos resultados mais recentes com os processadores escaláveis Intel® Xeon® Gold Series (Cascade Lake) de 2ª geração executando a IRIS for Health 2020.1.

Gráfico 1: Taxa de transferência de mensagens (em milhões) por 10 horas em um único servidor

A InterSystems IRIS for Health continua aumentar a taxa de transferência de interoperabilidade a cada versão, além de oferecer flexibilidade quanto aos recursos de conectividade. Como o gráfico acima mostra, a taxa de transferência de mensagens aumentou significativamente e, com cargas de trabalho T2, dobrou em relação a 2017 e mais que triplicou em relação a 2015 na mesma janela de 10 horas e sustentou mais de 2,3 bilhões de taxas de mensagens em 24 horas.

Outro indicador importante dos avanços da IRIS for Health é a melhoria da taxa de transferência com cargas mais complexas T2 e T4, que incorporam transformações e regras de roteamento, ao contrário da operação única de passagem da carga de trabalho T1.  

A InterSystems está disponível para conversar sobre soluções de acordo com as necessidades de interoperabilidade de sua organização.

0
0 116