#Interoperabilidade

0 Seguidores · 75 Postagens

Na verificação de integridade, interoperabilidade é a capacidade de diferentes sistemas de tecnologia da informação e aplicações de software se comunicarem, trocarem dados e usarem as informações que foram trocadas.

Job Gabriel Martin Fusco · Jul. 27, 2021

Bom dia!!!

Vaga Especialista de Integrações.

AFIP - Associação  Fundo de Incentivo à Pesquisa.

Requisitos 

* Conhecimentos avançado em Ensemble/Caché
* Integração com bancos Oracle /SQL Server

Será um diferencial ter atuação na área da saúde sistemas (LIS/HIS/RIS). Profissional deve atuar como líder técnico.

- Documentar estrutura dos sistemas;
- Participar de Reuniões técnicas com fornecedores/colaboradores;
- Responsável técnico pela arquitetura de integrações entre sistemas; 
- Responsável pela homologação de sistemas de terceiros;
- Responsável por manter catálogo de serviços de integração de dado;

0
0 160
Anúncio Ben Spead · Jul. 7, 2021

Olá Desenvolvedores!

Vocês já tiveram que converter mensagens HL7v2 para FHIR (Fast Healthcare Interoperability Resources) e acharam o processo de transformação complicado e confuso? A InterSystems está criando uma nova oferta de SaaS baseada em nuvem chamada de Serviços de Transformação de Mensagens do HealthShare que faz com que este processo se torne simples. Estamos muito empolgados de anunciar um Programa de Acesso Antecipado para esta nossa nova oferta e adoraríamos que vocês o utilizassem e então nos dessem seu feedback a respeito do mesmo! Para isso basta que vocês possuam uma conta grátis AWS, com um bucket S3 para colocar suas mensagens HL7v2 e outro bucket S3 para colocar a saída em FHIR. 

0
0 128
Job Rogerio de Oliveira · Jun. 24, 2021

Pessoal,

Procuro perfil de analista de integração / Ensemble (freelance). Interessados, por favor enviar mensagem de WhatsApp (61) 98405-2981.

Local de trabalho: 100% Remoto

Habilidades:  Cache DB, Object Script, InterSystems, Ensemble

Conhecimentos Necessários:

0
0 125
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
Artigo Claudio Devecchi · Mar. 11, 2021 7m read

Healthshare - Unified Care Record

Todas as instituições de saúde hoje, sejam públicas ou privadas, enfrentam os mesmos desafios:

Como fazer com que todas as informações de cada paciente sejam facilmente transmitidas dos seus sistemas de origem para as pessoas que precisam delas e vice-versa?

E como utilizar todas estas informações para melhorar a tomada de decisões, a qualidade do atendimento e os resultados?

Para atingir estes objetivos e fazer com que a informação consolidada do indivíduo seja finalmente disponibilizada para os diversos usos é preciso que as informações fluam por uma série de processos que vão desde a coleta da informação no sistema de origem, o seu tratamento, até as diferentes formas de disponibilização para os usuários finais.

E é exatamente esta a especialidade do produto HealthShare Unified Care Record da InterSystems. Ele atua em todas as etapas do processo, de forma rápida, através de inúmeras ferramentas e funcionalidades, as quais explanarei a seguir:

Interoperabilidade e Governança

Esta etapa engloba todos os mecanismos de coleta e tratamento 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 assegure flexibilidade, governança e segurança, além de performance e escalabilidade. Se qualquer sistema de origem “cair” a plataforma deve ter mecanismos de notificação para o time que gerencia o processo, assegurando que se o sistema voltar nenhuma informação será perdida.

A plataforma deve ser escalável tanto para “plugar” novas fontes de informação, quanto para suportar todas as requisições dos consumidores e usuários.

É 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, e que esteja preparada para trabalhar com os sistemas de prontuário eletrônico conhecidos no mercado brasileiro e fornecer outras abordagens de captura de dados que não exijam que o sistema de origem tenha API’s prontas para fornecer as informações necessárias.

Gestão de Terminologia

Quando se junta informações de diferentes sistemas e fontes, se junta também inúmeros sistemas de codificações, sejam eles públicos ou proprietários. Exemplos: CID10, TUSS, LOINC, SNOMED CT, CBHPMl, etc.

Isso pode gerar uma dificuldade para interpretar todos estes distintos sistemas de codificação.

Um exemplo hipotético de terminologia:

0 sistema A registrou no episódio de atendimento de um determinado paciente o código “S53 – Luxação, entorse e distensão das articulações e dos ligamentos do cotovelo”, referente ao sistema de codificação CID10. O mesmo código foi registrado pelo sistema B com uma ligeira diferença na descrição, por exemplo “Luxação e dist. das art. e dos ligamentos do cotovelo”, sofrendo uma abreviação por uma questão de limitação do campo descrição no sistema de origem.

Se os diagnósticos tratarem da mesma pessoa e do mesmo sistema de codificação, o profissional usuário da informação consolidada espera ver e interpretar as informações apresentadas da mesma maneira, não com descrições distintas.

Se os diagnósticos tratarem da mesma pessoa, mas de sistemas de codificações distintos, é importante que o sistema ofereça mecanismos de De/Para das tabelas de codificação para serem aplicadas apenas no consumo das informações, facilitando assim a interpretação das informações aos seus usuários e a aplicação de algoritmos pelos cientistas de dados.

Também é fundamental que todo tratamento de terminologia não altere e mantenha a informação que foi registrada no seu sistema de origem, com o seu devido sistema de codificação. Esse princípio é importante para que se mantenha e respeite todo o lastro da informação original e evite interpretações equivocadas em função do tratamento do dado.

Modelo Canônico de Dados e múltiplas formas de “input” ou consumo

Considerando apenas trocas de informações da área da saúde, há uma infinidade de protocolos. Temos por exemplo o HL7v2, o CCD, o PIX, o PDQ, DICOM para imagens, ASTM para laboratórios e o mais moderno HL7 FHIR, em diversas versões. No mercado nacional temos o TISS, que é utilizado para a saúde suplementar, entre muitos outros.

Todos estes padrões de interoperabilidade carregam informações relevantes do paciente e muitos deles são baseados em modelos de dados completamente distintos. E mesmo quando não surge um novo, todos estes citados anteriormente sofrem constantes atualizações. Sem considerar os modelos de mensagens proprietários no mercado brasileiro.

Levando em conta toda a variedade e dinamismo das mensagens, a InterSystems decidiu construir um modelo de dados central chamado de SDA (Summary Document Architecture) que fosse de simples entendimento, extensível e completo o suficiente para realizar a tradução, importação e exportação de todos estes protocolos que carregam as mensagens dos pacientes.

Isso dá uma enorme vantagem para quem irá construir regras de negócio para notificações clínicas, para sistemas de decisões clínicas (CDSS), algoritmos de predição ou para quaisquer outros processos ou fluxos de negócio.

Isso porque não exige que o especialista do negócio conheça os protocolos de entrada e saída, mas sim de apenas um único modelo de dados extremamente simplificado.

Outra vantagem é que a própria InterSystems mantem atualizada as bibliotecas de transformações dos protocolos conhecidos, tanto de entrada (captura) quanto de saída (consumo) para este modelo canônico central.

Gestão de Consentimento

Em 2018, o Brasil passou a fazer parte dos países que contam com uma legislação específica para proteção de dados e da privacidade dos seus cidadãos. Isso significa que os dados pessoais e sensíveis não podem ser deliberadamente utilizados sem a obtenção da expressa autorização do seu proprietário. Mesmo antes de entrar em vigor esta legislação, a plataforma HealthShare já contava com as seguintes funcionalidades:

• Cadastrar e manter políticas de consentimento dos dados em nível de ecossistema, de estabelecimento, ou por indivíduo, dando a opção de quais dados serão utilizados e para qual finalidade. • Armazenar o registro do consentimento, considerando-o também como parte das informações do paciente. • Aplicar as políticas de consentimento em toda a plataforma, fornecendo aos consumidores logs e mensagens específicas do motivo da não exibição de determinado grupo de informação. • Fornecer API’s para que além da plataforma, outros sistemas e usuários possam acessar e utilizar estes registros de consentimento.

Visualizador Clínico, Serviços e API’s

Depois que todas as informações do paciente são captadas, normalizadas e trabalhadas pela plataforma em todas as etapas descritas anteriormente, elas são disponibilizadas através de serviços na plataforma de Registro Unificado de Saúde. O consumo destes serviços pode ocorrer de diversas maneiras, partindo de diferentes profissionais ou sistemas de informação.

A plataforma HealthShare Unified Care Record fornece nativamente as seguintes formas:

Visualizador Clínico: Trata-se de uma aplicação responsiva que exibe aos profissionais de saúde e times de cuidado todas as informações relevantes do paciente. Nesta aplicação é possível visualizar todo o histórico evolutivo dos exames do paciente, as alergias, os sinais vitais, os exames e laudos de radiologia, etc. Essa aplicação pode ser acessada através do próprio sistema de prontuário eletrônico ou vista através de um “frame” embutido no mesmo. • Mensageria: Consiste na entrega de mensagens clínicas, alertas ou notificações clínicas utilizando todo o potencial da plataforma de interoperabilidade e a riqueza das bibliotecas e protocolos disponíveis. • API’s de Consumo: A plataforma fornece um conjunto de API’s para trabalhar com todos os tipos de interações com a plataforma. Por exemplo: Serviços de Interação com o Master Patient Index (PIX, PDQ, Golden Record, etc.) Serviços de Gestão de Consentimento, podendo ser acessado por outros sistemas para fins de LGPD. Serviços de Cadastro de Usuários e Profissionais possibilitando a sincronização com o Single Sign-On da Organização. Serviços de Auditoria (ATNA). Qualquer interação com a plataforma gera um registro de log. Serviços de obtenção do Registro Unificado do Paciente, expostos de inúmeras formas (Documento PDF, TXT, XML, JSON, CDA, CCD, HL7, etc.) HL7 FHIR: Possibilita o acesso aos dados do paciente utilizando as últimas versões do poderoso protocolo HL7 FHIR e todas as suas capacidades.

Conclusão

O que as instituições estão buscando, cada vez mais, é uma abordagem holística do cuidado contínuo, da prevenção e da experiência centrada no paciente.

E para viabilizar de forma completa este objetivo tão almejado, é preciso que todas as informações do indivíduo sejam colocadas dentro de uma mesma “caixa”, independentes do local, da instituição, do sistema, da tecnologia e do tipo de informação que é coletada, podendo ser de saúde, administrativo financeira, assistencial, comportamental e social, registro das interações do paciente com a instituição, autorizações do convênio, etc.

É literalmente colocar o paciente no centro de tudo. É quebrar a fronteira dos silos e fazer uso das informações para o benefício do paciente e consequentemente de todos os que estão envolvidos no processo que o suporta.

2
0 137
Artigo Lorenzo Scalese · Fev. 1, 2021 8m read

Olá comunidade,

  O OpenAPI-Client Gen acaba de ser lançado, este é um aplicativo para criar um cliente de produção de interoperabilidade IRIS a partir da especificação Swagger 2.0.

  Em vez da ferramenta existente ^%REST que cria um aplicativo REST do lado do servidor, o OpenAPI-Client Gen cria um modelo de cliente de produção de interoperabilidade REST completo.

Instalação por ZPM:

zpm "install openapi-client-gen"

  Como gerar produção a partir de um documento Swagger?   É muito simples.

Abra um terminal e execute:

Set sc = ##class(dc.openapi.client.Spec).generateApp(<applicationName>, <Your Swagger 2.0 document>>)

  O primeiro argumento é o pacote de destino onde as classes de produção serão geradas. Ele deve ser um nome de pacote válido e não existente.
O segundo, é o documento Swagger. Estes valores são aceitos:
  1) File path.
2) %DynamicObject.
3) URL.
  A especificação deve estar no formato JSON.
  Se sua especificação usa o formato YAML, ela pode ser facilmente convertida em JSON com ferramentas on-line como onlineyamltools.com
  Exemplo:

Set sc = ##class(dc.openapi.client.Spec).generateApp("petshop", "https://petstore.swagger.io:443/v2/swagger.json")
Write "Status : ", $SYSTEM.Status.GetOneErrorText(sc)

  Dê uma olhada no código gerado, podemos ver muitas classes, divididas em muitos subpacotes:  

  • Business Services: petshop.bs
  • Business Operations: petshop.bo
  • Business Processes: petshop.bp
  • Aplicação REST Proxy: petshop.rest
  • Ens.Request e Ens.Response: petshop.msg
  • Objeto de entrada ou saída analisado: petshop.model.Definition
  • Classe de configuração de produção: petshop.Production    

Classe de operação de negócios

Para cada serviço definido no documento Swagger, existe um método relacionado denominado por <VERB><ServiceId>.

Aprofunde-se em um simples método gerado GETgetPetById  

/// Retorna um único animal de estimação
Method GETgetPetById(pRequest As petshop.msg.getPetByIdRequest, pResponse As petshop.msg.GenericResponse) As %Status
{
    Set sc = $$$OK, pURL = "/v2/pet/{petId}"
    Set pHttpRequestIn = ..GetRequest(pRequest)
    Set pHttpRequestIn.ContentType = pRequest.consume
    Set pURL = $Replace(pURL, "{petId}", pRequest.pathpetId)
    $$$QuitOnError(..Adapter.SendFormDataArray(.pHttpResponse, "get", pHttpRequestIn , , , pURL))
    Set pResponse = ##class(petshop.msg.GenericResponse).%New()
    Set sc = ..genericProcessResponse(pRequest, pResponse, "GETgetPetById", sc, $Get(pHttpResponse),"petshop.msg.getPetByIdResponse")
    Return sc
}

 

  • Em primeiro lugar, o objeto %Net.HttpRequest é sempre criado pelo método GetRequest, fique à vontade para editar e adicionar alguns cabeçalhos, se necessário.
  • Em segundo lugar, o objeto HttpRequest é preenchido usando pRequest `petshop.msg.getPetByIdRequest' (Ens.Request subclass).
  • Em terceiro lugar, EnsLib.HTTP.OutboundAdapter é usado para enviar solicitação http.
  • E, finalmente, há um processamento de resposta genérico pelo método genericProcessResponse:
Method genericProcessResponse(pRequest As Ens.Request, pResponse As petshop.msg.GenericResponse, caller As %String, status As %Status, pHttpResponse As %Net.HttpResponse, parsedResponseClassName As %String) As %Status
{
    Set sc = $$$OK
    Set pResponse.operation = caller
    Set pResponse.operationStatusText = $SYSTEM.Status.GetOneErrorText(status)
    If $Isobject(pHttpResponse) {
        Set pResponse.httpStatusCode = pHttpResponse.StatusCode
        Do pResponse.body.CopyFrom(pHttpResponse.Data)
        Set key = ""
        For  {
            Set key = $Order(pHttpResponse.Headers(key),1 , headerValue)
            Quit:key=""
            Do pResponse.headers.SetAt(headerValue, key)
        }
        Set sc = ##class(petshop.Utils).processParsedResponse(pHttpResponse, parsedResponseClassName, caller, pRequest, pResponse)
    }
    Return sc
}

  Então, podemos analisar um método um pouco mais complexo POSTuploadFile

Method POSTuploadFile(pRequest As petshop.msg.uploadFileRequest, pResponse As petshop.msg.GenericResponse) As %Status
{
    Set sc = $$$OK, pURL = "/v2/pet/{petId}/uploadImage"
    Set pHttpRequestIn = ..GetRequest(pRequest)
    Set pHttpRequestIn.ContentType = pRequest.consume
    Set pURL = $Replace(pURL, "{petId}", pRequest.pathpetId)
    If pHttpRequestIn.ContentType = "multipart/form-data" {
        Set valueStream = ##class(%Stream.GlobalBinary).%New()
        Do:$Isobject(pRequest.formDataadditionalMetadata) valueStream.CopyFrom(pRequest.formDataadditionalMetadata)
        Do:'$Isobject(pRequest.formDataadditionalMetadata) valueStream.Write($Zcvt(pRequest.formDataadditionalMetadata,"I","UTF8"))
        Set:'$ISOBJECT($Get(mParts)) mParts = ##class(%Net.MIMEPart).%New()
        Set mimePart = ##class(%Net.MIMEPart).%New(valueStream)
        Do mimePart.SetHeader("Content-Disposition", "form-data; name=""additionalMetadata""; filename=""additionalMetadata""")
        Do mParts.Parts.Insert(mimePart)
    } Else { 
        Do pHttpRequestIn.InsertFormData("additionalMetadata", pRequest.formDataadditionalMetadata)
    }
    If pHttpRequestIn.ContentType = "multipart/form-data" {
        Set valueStream = ##class(%Stream.GlobalBinary).%New()
        Do:$Isobject(pRequest.formDatafile) valueStream.CopyFrom(pRequest.formDatafile)
        Do:'$Isobject(pRequest.formDatafile) valueStream.Write($Zcvt(pRequest.formDatafile,"I","UTF8"))
        Set:'$ISOBJECT($Get(mParts)) mParts = ##class(%Net.MIMEPart).%New()
        Set mimePart = ##class(%Net.MIMEPart).%New(valueStream)
        Do mimePart.SetHeader("Content-Disposition", "form-data; name=""file""; filename=""file""")
        Do mParts.Parts.Insert(mimePart)
    } Else { 
        Do pHttpRequestIn.InsertFormData("file", pRequest.formDatafile)
    }
    If $ISOBJECT($Get(mParts)) {
        Set mimeWriter = ##class(%Net.MIMEWriter).%New()
        Do mimeWriter.OutputToStream(.stream)
        Do mimeWriter.WriteMIMEBody(mParts)
        Set pHttpRequestIn.EntityBody = stream
        Set pHttpRequestIn.ContentType = "multipart/form-data; boundary=" _ mParts.Boundary
    }
    $$$QuitOnError(..Adapter.SendFormDataArray(.pHttpResponse, "post", pHttpRequestIn , , , pURL))
    Set pResponse = ##class(petshop.msg.GenericResponse).%New()
    Set sc = ..genericProcessResponse(pRequest, pResponse, "POSTuploadFile", sc, $Get(pHttpResponse),"petshop.msg.uploadFileResponse")
    Return sc
}

  Como você pode ver, é exatamente a mesma lógica: GetRequest, preenchendo %Net.HttpRequest, enviar solicitação, processamento de resposta genérica.
 

Classe Proxy REST

Uma aplicação proxy REST também é gerada.
Esta classe REST usa um Projection para criar automaticamente a aplicação web relacionada (ex: "/petshoprest", consulte petshop.rest.REST e petshop.rest.Projection).   Este proxy REST cria a mensagem Ens.Request e envia-a para o Business.Process.

Class petshop.rest.REST Extends %CSP.REST [ ProcedureBlock ]
{

Projection WebApp As petshop.rest.Projection;

...

ClassMethod POSTaddPet() As %Status
{
    Set ensRequest = ##class(petshop.msg.addPetRequest).%New()
    Set ensRequest.consume = %request.ContentType
    Set ensRequest.accept = $Get(%request.CgiEnvs("HTTP_ACCEPT"),"*/*")
    Set ensRequest.bodybody = ##class(petshop.model.Definition.Pet).%New()
    Do ensRequest.bodybody.%JSONImport(%request.Content)
    Return ##class(petshop.Utils).invokeHostAsync("petshop.bp.Process", ensRequest, "petshop.bs.ProxyService")
}

ClassMethod GETgetPetById(petId As %String) As %Status
{
    Set ensRequest = ##class(petshop.msg.getPetByIdRequest).%New()
    Set ensRequest.consume = %request.ContentType
    Set ensRequest.accept = $Get(%request.CgiEnvs("HTTP_ACCEPT"),"*/*")
    Set ensRequest.pathpetId = petId
    Return ##class(petshop.Utils).invokeHostAsync("petshop.bp.Process", ensRequest, "petshop.bs.ProxyService")
}
...
ClassMethod POSTuploadFile(petId As %String) As %Status
{
    Set ensRequest = ##class(petshop.msg.uploadFileRequest).%New()
    Set ensRequest.consume = %request.ContentType
    Set ensRequest.accept = $Get(%request.CgiEnvs("HTTP_ACCEPT"),"*/*")
    Set ensRequest.pathpetId = petId
    Set ensRequest.formDataadditionalMetadata = $Get(%request.Data("additionalMetadata",1))
    set mime = %request.GetMimeData("file")
    Do:$Isobject(mime) ensRequest.formDatafile.CopyFrom(mime)
    Return ##class(petshop.Utils).invokeHostAsync("petshop.bp.Process", ensRequest, "petshop.bs.ProxyService")
}
...
}

  Então, vamos testar a produção com este proxy REST.  

Abra e inicie o petshop.Production

Crie um animal de estimação

  Altere o número da porta, se necessário:

curl --location --request POST 'http://localhost:52795/petshoprest/pet' \
--header 'Content-Type: application/json' \
--data-raw '{
  "category": {
    "id": 0,
    "name": "string"
  },
  "id" : 456789,
  "name": "Kitty_Galore",
  "photoUrls": [
    "string"
  ],
  "tags": [
    {
      "id": 0,
      "name": "string"
    }
  ],
  "status": "available"
}'

  A produção é executada no modo assíncrono, portanto, a aplicação proxy restante não espera pela resposta. Este comportamento pode ser editado, mas normalmente, a produção de interoperabilidade usa o modo assíncrono.   Veja o resultado no visualizador de mensagens e no traço visual

EDIÇÃO: desde a versão 1.1.0, a aplicação Proxy Rest funciona em modo de sincronização

  Se tudo estiver bem, podemos observar um código http de status 200. Como você pode ver, recebemos uma resposta do corpo e ela não está analisada.

O que isso significa?
Isso ocorre quando resposta da aplicação/json ou a resposta 200 da especificação Swagger não é preenchida.
Nesse caso, a resposta 200 não está preenchida.  

Obtenha uma animal de estimação

  Agora, tente obter o animal de estimação criado:

curl --location --request GET 'http://localhost:52795/petshoprest/pet/456789'

  Verifique o traço visual:

  Desta vez, esta é uma resposta da aplicação/json (a resposta 200 está completa nas especificações Swagger). Podemos ver um objeto de resposta analisado.   ### API REST - Gerar e baixar

Além disso, essa ferramenta pode ser hospedada em um servidor para permitir que os usuários gerem e baixem o código.   Uma API REST e um formulário básico estão disponíveis:  

Nesse caso, o código é simplesmente gerado sem compilar, exportado e, em seguida, tudo é excluído.
Este recurso pode ser útil para centralização de ferramentas.
  Veja o README.md para informações atualizadas.     Obrigado pela leitura.  

0
0 235
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 Anton Umnikov · jan 11, 2021 8m read

IRIS External Table é um projeto de código aberto da comunidade InterSystems, que permite usar arquivos armazenados no sistema de arquivos local e armazenamento de objetos em nuvem, como o AWS S3, como tabelas SQL. IRIS External Table

Ele pode ser encontrado no GitHub https://github.com/intersystems-community/IRIS-ExternalTable, Open Exchange https://openexchange.intersystems.com/package/IRIS-External-Table e está incluído no InterSystems Package Manager, ZPM.

Para instalar o External Table a partir do GitHub, use:

git clone https://github.com/antonum/IRIS-ExternalTable.git
iris session iris
USER>set sc = ##class(%SYSTEM.OBJ).LoadDir("<path-to>/IRIS-ExternalTable/src", "ck",,1)

Para instalar usando o ZPM Package Manager:

USER>zpm "install external-table"

Trabalhando com arquivos locais

Vamos criar um arquivo simples parecido com este:

a1,b1
a2,b2

Abra seu editor favorito e crie o arquivo ou apenas use uma linha de comando no linux/mac:

echo $'a1,b1\na2,b2' > /tmp/test.txt

No IRIS SQL, crie uma tabela para representar este arquivo:

create table test (col1 char(10),col2 char(10))

Converta a tabela para usar o armazenamento externo:

CALL EXT.ConvertToExternal(
    'test',
    '{
        "adapter":"EXT.LocalFile",
        "location":"/tmp/test.txt",
        "delimiter": ","
    }')

E finalmente, consulte a tabela:

select * from test

Se tudo funcionar conforme o esperado, você verá uma saída como esta:

col1    col2
a1  b1
a2  b2

Agora volte ao editor, altere o conteúdo do arquivo e execute novamente a consulta SQL. Uau!!! Você está lendo os novos valores de seu arquivo local no SQL.

col1    col2
a1  b1
a2  b99

Lendo dados a partir do S3

Em https://covid19-lake.s3.amazonaws.com/index.htmlhttps:você pode obter acesso a dados atualizados constantemente sobre o COVID, armazenados pela AWS no data lake público.

Vamos tentar acessar uma das fontes de dados neste data lake: s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states

Se você tiver a ferramenta de linha de comando AWS instalada, pode repetir as etapas abaixo. Caso contrário, vá direto para a parte SQL. Você não precisa de usar um AWS específico instalado em sua máquina para acompanhar a parte SQL.

$ aws s3 ls s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states/
2020-12-04 17:19:10     510572 us-states.csv

$ aws s3 cp s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states/us-states.csv .
download: s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states/us-states.csv to ./us-states.csv

$ head us-states.csv 
date,state,fips,cases,deaths
2020-01-21,Washington,53,1,0
2020-01-22,Washington,53,1,0
2020-01-23,Washington,53,1,0
2020-01-24,Illinois,17,1,0
2020-01-24,Washington,53,1,0
2020-01-25,California,06,1,0
2020-01-25,Illinois,17,1,0
2020-01-25,Washington,53,1,0
2020-01-26,Arizona,04,1,0

Portanto, temos um arquivo com uma estrutura bastante simples. Com cinco campos delimitados.

Para expor esta pasta S3 como um External Table, primeiro, precisamos criar uma tabela "regular" com a estrutura desejada:

-- create external table
create table covid_by_state (
    "date" DATE, 
    "state" VARCHAR(20),
    fips INT,
    cases INT,
    deaths INT
)

Observe que alguns nomes de campo como “Date” são palavras reservadas no IRIS SQL e precisam ser colocados entre aspas duplas. Em seguida, precisamos converter esta tabela “regular” para a tabela “externa”, com base no bucket AWS S3 e tipo CSV.

 -- convert table to external storage
call EXT.ConvertToExternal(
    'covid_by_state',
    '{
    "adapter":"EXT.AWSS3",
    "location":"s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states/",
    "type": "csv",
    "delimiter": ",",
    "skipHeaders": 1
    }' 
)

Se você observar com atenção, os argumentos dos procedimentos EXT.ExternalTable são o nome da tabela e a string JSON, contendo vários parâmetros, como localização para procurar por arquivos, adaptador, delimitador, etc. Além da AWS S3, o External Table oferece suporte ao armazenamento BLOB do Azure, Cloud Buckets e o sistema de arquivos local. O GitHub Repo contém referências para a sintaxe e as opções suportadas em todos os formatos.

E finalmente, consulte a tabela:

-- query the table
select top 10 * from covid_by_state order by "date" desc

[SQL]USER>>select top 10 * from covid_by_state order by "date" desc
2.  select top 10 * from covid_by_state order by "date" desc

date    state   fips    cases   deaths
2020-12-06  Alabama 01  269877  3889
2020-12-06  Alaska  02  36847   136
2020-12-06  Arizona 04  364276  6950
2020-12-06  Arkansas    05  170924  2660
2020-12-06  California  06  1371940 19937
2020-12-06  Colorado    08  262460  3437
2020-12-06  Connecticut 09  127715  5146
2020-12-06  Delaware    10  39912   793
2020-12-06  District of Columbia    11  23136   697
2020-12-06  Florida 12  1058066 19176

Compreensivelmente, leva mais tempo para consultar dados da tabela remota, do que na tabela "IRIS nativa" ou com base global, porém, ela é completamente armazenada e atualizada em nuvem e está sendo puxada para o IRIS "nos bastidores".

Vamos explorar mais alguns recursos do External Table.

%PATH e tabelas, com base em vários arquivos

Em nossa pasta de exemplo, o bucket contém apenas um arquivo. Mais frequentemente, ele teria vários arquivos com a mesma estrutura, onde nome do arquivo identifica o carimbo de data/hora ou deviceid de algum outro atributo que desejaremos usar em nossas consultas.

O campo %PATH é adicionado automaticamente a cada External Table e contém o caminho completo para o arquivo de onde a linha foi recuperada.

select top 5 %PATH,* from covid_by_state

%PATH   date    state   fips    cases   deaths
s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states/us-states.csv    2020-01-21  Washington  53  1   0
s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states/us-states.csv    2020-01-22  Washington  53  1   0
s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states/us-states.csv    2020-01-23  Washington  53  1   0
s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states/us-states.csv    2020-01-24  Illinois    17  1   0
s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states/us-states.csv    2020-01-24  Washington  53  1   0

Você pode usar este campo %PATH em suas consultas SQL como em qualquer outro campo.

Dados ETL para "Tabelas Regulares"

Se sua tarefa é carregar dados do S3 em uma tabela IRIS, você pode usar o External Table como uma ferramenta ETL. Apenas faça:

INSERT INTO internal_table SELECT * FROM external_table

No nosso caso, se quisermos copiar os dados sobre COVID do S3 para a tabela local:

--create local table
create table covid_by_state_local (
    "date" DATE, 
    "state" VARCHAR(100),
    fips INT,
    cases INT,
    deaths INT
)
--ETL from External to Local table
INSERT INTO covid_by_state_local SELECT TO_DATE("date",'YYYY-MM-DD'),state,fips,cases,deaths FROM covid_by_state

JOIN entre IRIS - tabela nativa e externa. Consultas federadas

External Table é uma tabela SQL. Ele pode ser unido a outras tabelas, usado em subseleções e UNIONs. Você pode até combinar a tabela IRIS “Regular” e duas ou mais tabelas externas de fontes diferentes na mesma consulta SQL.

Tente criar uma tabela regular, como os nomes de estado correspondendo com códigos de estado, como por exemplo, Washington – WA. E junte-a com nossa tabela baseada em S3.

create table state_codes (name varchar(100), code char(2))
insert into state_codes values ('Washington','WA')
insert into state_codes values ('Illinois','IL')

select top 10 "date", state, code, cases from covid_by_state join state_codes on state=name

Altere 'join' para 'left join' para incluir linhas para as quais o código de estado não foi definido. Como você pode ver, o resultado é uma combinação de dados do S3 e sua tabela IRIS nativa.

Acesso seguro aos dados

A AWS Covid Data Lake é público. Qualquer pessoa pode ler dados dele sem qualquer autenticação ou autorização. Na vida real, você desejará acessar seus dados de forma segura, evitando que estranhos espiem seus arquivos. Os detalhes completos da AWS Identity and Access Management (IAM) estão fora do escopo deste artigo. Mas o mínimo que você precisa saber é que você precisa de pelo menos a chave de acesso e a chave secreta da conta da AWS para acessar dados privados em sua conta. https:

AWS usa autenticação de chave/segredo de conta para assinar solicitações. https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys

Se você estiver executando o IRIS External Table na instância EC2, a maneira recomendada de lidar com a autenticação é usar as funções da instância EC2 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html. O IRIS External Table será capaz de usar as permissões dessa função. Nenhuma configuração extra é necessária.

Em uma instância local/não EC2, você precisa especificar o AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY, especificando variáveis de ambiente ou instalando e configurando o cliente AWS CLI.

export AWS_ACCESS_KEY_ID=AKIAEXAMPLEKEY
export AWS_SECRET_ACCESS_KEY=111222333abcdefghigklmnopqrst

Certifique-se de que a variável de ambiente esteja visível em seu processo IRIS. Você pode verificá-lo executando:

USER>write $system.Util.GetEnviron("AWS_ACCESS_KEY_ID")

Ela deve retornar o valor da chave.

ou instale o AWS CLI, seguindo as instruções aqui https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-linux.html e execute:

aws configure

O External Table poderá, então, ler as credenciais dos arquivos de configuração do aws cli. Seu shell interativo e o processo IRIS podem estar sendo executados em contas diferentes. Certifique-se de executar aws configure na mesma conta do seu processo IRIS.

0
0 227
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
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
Anúncio Angelo Bruno Braga · Nov. 16, 2020

Olá Desenvolvedores,

Esta semana é a semana de votação para o Concurso de Interoperabilidade InterSystems Interoperability! Então, é a hora de você dar o seu voto para a melhor solução de interoperabilidade desenvolvida com a plataforma de dados IRIS.

🔥 Você decide: VOTE AQUI 🔥

 

Como votar? É fácil: você tem direito a um voto, e seu voto vai ou para a Nominação pelos Experts ou para a Nominação pela Comundade.

0
0 80
Anúncio Angelo Bruno Braga · Nov. 3, 2020

Olá Desenvolvedores!

Aqui estão os bônus tecnológicos do Concurso de Interoperabilidade InterSystems que irão lhe dar pontos extras durante a votação:

  • Uso do Business Process BPL ou Business Rule DTL 
  • Uso de Adaptadores de Interoperabilidade Customizados
  • Uso da Production EXtension(PEX) Java ou .NET 
  • Uso do Workflow 
  • Implantação usando o pacote ZPM 
  • Uso de contêiner Docker 

Vejam os detalhes abaixo.

0
0 118
Anúncio Angelo Bruno Braga · Out. 29, 2020

Olá Comunidade!

É com grande prazer que convidamos todos os desenvolvedores para o o próximo Webinar Inicial do Concurso de Interoperabilidade InterSystems! O assunto deste webinar é o Concurso de Interoperabilidade.

Neste webinar, nós iremos falar a respeito das funcionalidades de interoperabilidade de nossa plataforma de dados InterSystems IRIS, iremos fazer uma demonstração de como criar uma solução de interoperabilidade básica no IRIS e demonstrar como utilizar o PEX. Além disto iremos discutir e responder perguntas de como criar soluções de interoperabilidade utilizando as plataformas de dados InterSystems IRIS e IRIS for Health.

Dara e Horário: Segunda, 2 de Novembro — 12:00 BRT (horário de Brasília)

Palestrantes:  
🗣 @Stefan Wittmann, InterSystems Product Manager 
🗣 @Eduard Lebedyuk, InterSystems Sales Engineer
🗣 @Evgeny Shvarov, InterSystems Developer Ecosystem Manager


0
0 72