DocumentaçãoSuporteCosta Rica · Contato
ESENPT
Fale conosco
Infraestrutura

Repositórios Cloud

Projetos clínicos raramente param por falta de ideias. Param esperando onde guardar os dados. Entregamos o repositório já operando —FHIR, imagens médicas ou documental assinado— com a autenticação, a autorização, a auditoria e a conformidade já resolvidas.

Solicitar uma proposta→Ver o que inclui
O ponto de partida

Montar o repositório não é o projeto. É o pedágio para poder começá-lo.

Nenhuma organização de saúde quer estar no negócio de operar servidores. Quer publicar resultados de laboratório, compartilhar um estudo com outro centro, guardar um consentimento que sirva como prova. Mas antes disso é preciso resolver um servidor FHIR, um servidor de autorização, a validação contra o perfil nacional, a criptografia, a residência dos dados, o backup, a auditoria e alguém que atenda às três da manhã. Esse pedágio se paga em meses e com uma equipe que a maioria das instituições não tem nem quer contratar. Nós já o pagamos: você recebe o repositório andando.

O que implantamos

Três repositórios, uma só plataforma embaixo

Você escolhe o que precisa custodiar. O que sustenta o repositório —identidade, autorização, auditoria, criptografia, backup e operação— não é cotado à parte: é a mesma base para os três e já vem incluída.

R4 / R5

Repositório FHIR

Dados clínicos estruturados

Quando você precisa

Quando você precisa armazenar e expor informação clínica —pessoas, resultados, vacinas, condições, medicação— de forma que outro sistema a entenda sem um integrador sob medida para cada conexão.

  • API FHIR RESTful

    Busca, leitura, escrita, transações e operações padronizadas sobre R4 ou R5, com paginação e controle de concorrência.

  • Perfilamento e validação

    Cada recurso é validado contra o guia nacional ou institucional no momento da escrita, e não em uma auditoria meses depois.

  • Terminologia resolvida

    SNOMED CT, LOINC e os ValueSets nacionais disponíveis para validar, expandir e traduzir códigos sem montar um servidor à parte.

  • Extração em massa

    Bulk Data e operações de exportação para analytics, relatórios e painéis, sem sobrecarregar a API que atende a operação clínica.

  • Versionamento e histórico

    Cada alteração preserva a versão anterior: é possível reconstruir o que o dado dizia em uma data determinada.

PACS / VNA

Repositório de imagens

Estudos e laudos por imagem

Quando você precisa

Quando os estudos ficam presos no PACS do fabricante, tirá-los de lá tem custo a cada vez, e compartilhar um caso com outro centro ainda significa gravar um disco.

  • Arquivo DICOM e VNA

    Armazenamento neutro de fabricante: os estudos deixam de depender do equipamento ou do fornecedor que os gerou.

  • DICOMweb

    WADO-RS, QIDO-RS e STOW-RS para que visualizadores e sistemas clínicos consumam os estudos pela web, sem instalar nada na estação.

  • Visualizador integrado

    Visualização diagnóstica e de referência dentro do prontuário, com o acesso controlado pelo mesmo servidor de autorização.

  • Ingestão e roteamento

    Recepção a partir de modalidades e PACS existentes, com regras de roteamento, conciliação de estudos e anonimização para ensino e pesquisa.

  • Laudo estruturado

    O laudo do estudo também é publicado como recurso FHIR, para que o prontuário o leia sem precisar abrir o visualizador.

Assinado digitalmente

Repositório documental

Documentos com valor probatório

Quando você precisa

Quando um consentimento, um sumário de alta ou um atestado precisa ser atribuível a quem o emitiu e comprovadamente não alterado — e hoje é um PDF solto em uma pasta compartilhada.

  • Assinatura e selagem

    Assinatura digital em formatos de longa duração e carimbo do tempo, para que o documento siga verificável anos depois de emitido.

  • Verificação na entrada

    Todo documento que entra é verificado: assinatura válida, certificado vigente e cadeia de confiança completa, antes de ser arquivado.

  • Índice e recuperação

    Registro e repositório com metadados consultáveis, para encontrar o documento certo sem precisar abrir todos.

  • Retenção e preservação

    Políticas de retenção por tipo documental e preservação da validade da assinatura ao longo do tempo.

  • Publicação padronizada

    Exposição por meio de perfis de intercâmbio documental, para que outro estabelecimento recupere o documento sem desenvolver uma integração própria.

Base comum — sempre incluída

Justamente o que costuma ser subestimado na cotação e acaba sendo metade do projeto.

Identidade e autorização

Servidor de autorização próprio com SMART on FHIR e IHE IUA, registro de aplicações cliente e permissões por papel e por caso de uso.

Auditoria e rastreabilidade

Cada acesso registrado com quem, o quê, quando e de onde, em formato consultável e com a retenção que a sua norma exigir.

Criptografia e residência

Criptografia em trânsito e em repouso, com a localização dos dados definida e declarada por escrito desde o primeiro dia.

Backup e recuperação

Backups com restauração testada periodicamente. Um backup que ninguém tentou restaurar ainda não é um backup.

Monitoramento e suporte

Observabilidade, alertas e um canal com tempos de resposta comprometidos. Quando algo falha, quem descobre não é a equipe clínica.

Saída sem sequestro

Seus dados são seus e saem completos, em formato padronizado, no dia em que você pedir. Sem resgate nem conversões sob medida.

O que você não precisa contratar à parte
  • Servidor de autorização
  • Certificados e sua rotação
  • Auditoria e retenção
  • Backup com restauração testada
  • Monitoramento e alertas
  • Ambiente de testes
  • Atualização de versões
  • Suporte com resposta comprometida
Acesso

O repositório não é o risco. Quem pode ler o quê, sim.

Um repositório clínico sem arquitetura de acesso é um incidente com data pendente. Implantamos o circuito completo de autenticação e autorização, não uma lista de usuários com senha.

  1. 01

    A aplicação se identifica

    Cada sistema que consulta o repositório está registrado como cliente, com sua própria credencial e seu próprio alcance. Não existe uma conta compartilhada que meia equipe conhece.

    • OAuth 2.0
    • Registro de clientes
  2. 02

    A pessoa se autentica

    O profissional entra com a identidade que a sua organização já usa —incluída a assinatura digital nacional quando cabe— e não com um usuário criado apenas para este sistema.

    • OpenID Connect
    • IHE IUA
  3. 03

    Emite-se uma permissão restrita

    O token entregue diz exatamente o que se pode fazer e sobre o quê: esta pessoa, estes recursos, somente leitura, por este tempo. Uma permissão ampla é uma brecha esperando data.

    • Scopes SMART
    • patient/ · user/ · system/
  4. 04

    O repositório decide e recorta

    O repositório não confia que o cliente se comporte: valida a permissão a cada chamada, aplica o consentimento e devolve apenas o que a permissão alcança.

    • Autorização por recurso
    • Consentimento
  5. 05

    Fica o rastro

    Cada acesso —o concedido e o negado— fica registrado de forma consultável. Quando alguém perguntar quem viu aquele prontuário, há resposta e não uma investigação.

    • ATNA
    • AuditEvent

SMART on FHIR e IHE IUA não são um capricho técnico. São a razão pela qual uma aplicação clínica de terceiros pode se conectar ao seu repositório sem que você lhe abra o banco de dados, e pela qual o seu repositório pode aceitar a identidade de outra instituição sem precisar criar usuários. Um esquema próprio funciona bem até o dia em que é preciso integrar-se com mais alguém.

Conformidade

Guardar o dado não basta: ele precisa cumprir o perfil

Um repositório que aceita qualquer coisa transfere o problema a quem consome. Validamos contra o guia de implementação no momento da escrita, quando corrigir ainda é barato.

Quando existe guia nacional

A situação

A Costa Rica já publicou seus guias de implementação HL7© FHIR© R5: Core, terminológico, resultados de laboratório e laudos de imagens médicas. O que for publicado precisa cumpri-los.

Como resolvemos

O repositório é configurado contra esses perfis: cada recurso que entra é validado, e o que não cumpre é rejeitado ou separado com o motivo explícito, em vez de contaminar o repositório. A Meddyg participou do desenho, perfilamento e publicação desses guias.

Quando ainda não existe

A situação

Em muitos domínios —e em muitos países— ainda não há um perfil nacional publicado, e esperar que exista não é opção para um projeto que já tem data.

Como resolvemos

Definimos um perfil institucional mínimo sobre o padrão base, tomando dos modelos de referência internacionais o que sabemos que o guia nacional vai acabar exigindo. Desde o primeiro dia o dado é guardado em uma forma que migra para o guia nacional sem reescrever o que já foi carregado.

O que a validação realmente verifica

Estrutura e cardinalidade

Que o recurso traga os elementos que o perfil exige e nenhum dos que o perfil proíbe.

Terminologia

Que os códigos pertençam ao ValueSet que o perfil vincula, e não a uma lista interna parecida que mais ninguém entende.

Referências

Que aquilo que o recurso aponta exista e seja do tipo correto, para que o prontuário não fique cheio de links quebrados.

Regras do perfil

As invariantes que o guia declara e que nenhuma verificação estrutural detecta sozinha.

Evidência entregável

Um relatório de conformidade que pode ser apresentado a quem pedir, com o detalhe do que foi validado e com que resultado.

Operação

O que significa exatamente «chave na mão»

É fácil de dizer e difícil de cumprir. Estes são os compromissos concretos que ficam por escrito, e a forma como cada um é verificado.

Disponibilidade

O compromisso

Um nível de serviço acordado por escrito, com janelas de manutenção anunciadas e tempos de resposta diferenciados por severidade.

Como se verifica

Relatório periódico de disponibilidade e incidentes, com o detalhe de cada evento, sua causa e o que foi alterado para não se repetir.

Backup e recuperação

O compromisso

Frequência e retenção definidas, e objetivos de recuperação acordados antes de assinar, em vez de descobertos durante o incidente.

Como se verifica

Testes de restauração periódicos e documentados sobre um ambiente real, não sobre um procedimento escrito.

Criptografia e residência

O compromisso

Criptografia em trânsito e em repouso, e a localização física dos dados definida e declarada desde o início do contrato.

Como se verifica

Documento de arquitetura e configuração, revisável pelo seu encarregado de segurança ou de proteção de dados pessoais.

Versões e atualizações

O compromisso

Atualização do motor, dos pacotes de perfis e das terminologias, incluída a convivência entre R4 e R5 enquanto o ecossistema termina de se decidir.

Como se verifica

Ambiente de testes com a versão nova antes de tocar em produção, e um plano de reversão escrito para cada mudança maior.

Observabilidade

O compromisso

Monitoramento do repositório e de suas integrações, com alertas que chegam à nossa equipe antes de o problema chegar a um consultório.

Como se verifica

Painéis de uso, latência e erros acessíveis para a sua equipe, e não apenas para a nossa.

Saída sem sequestro

O compromisso

Seus dados são seus. No dia em que decidir levá-los, saem completos e em formato padronizado, com as imagens em DICOM e os recursos em FHIR.

Como se verifica

Um plano de saída escrito desde o contrato: o que se exporta, em que formato e em quanto tempo é entregue.

Método

Da decisão ao repositório em produção

Seis etapas. A segunda é a que evita a maioria dos incidentes, e é a que quase sempre se pula quando o repositório é comprado por catálogo.

  1. 01

    Escopo e dimensionamento

    Definimos o que o repositório vai custodiar, quem o consulta, com que volume e a que ritmo cresce. Daqui sai um tamanho real e um custo de operação crível, não uma cotação de catálogo.

    O que fica
    • Casos de uso e volumes
    • Dados e documentos a hospedar
    • Dimensionamento e custo de operação
  2. 02

    Desenho do acesso

    Definimos quem são os clientes, o que cada um pode pedir, como a pessoa se autentica e qual o papel do consentimento. É a etapa mais barata para descobrir que alguém poderia ler além da conta.

    O que fica
    • Matriz de clientes e permissões
    • Desenho SMART on FHIR / IUA
    • Política de auditoria e retenção
  3. 03

    Implantação e endurecimento

    Levantamos os ambientes, aplicamos o endurecimento, a criptografia e a residência acordada, e deixamos o backup testado antes de entrar o primeiro dado real.

    O que fica
    • Ambientes de testes e produção
    • Configuração de segurança documentada
    • Backup com restauração verificada
  4. 04

    Carga e conformidade

    Carregamos os dados ou os estudos existentes validando contra o perfil, e separamos desde o início o que não cumpre, em vez de deixá-lo entrar e descobrir quando alguém o consultar.

    O que fica
    • Migração ou ingestão inicial
    • Relatório de conformidade
    • Tratamento acordado de exceções
  5. 05

    Integração

    Conectamos o repositório aos seus sistemas clínicos, aos visualizadores, às modalidades e ao ecossistema ao qual deva responder.

    O que fica
    • Integrações em operação
    • Testes de ponta a ponta
    • Documentação técnica de interfaces
  6. 06

    Operação e transferência

    Operamos o repositório com os compromissos acordados e deixamos a sua equipe capaz de entender o que acontece lá dentro, mesmo que não precise operá-lo.

    O que fica
    • Runbook de operação
    • Painéis e alertas
    • Capacitação da equipe interna
Entregáveis

O que fica nas mãos da organização

Não um servidor e uma senha: o repositório operando e tudo o que é preciso para auditá-lo, explicá-lo e, se um dia quiser, levá-lo embora.

O repositório operando

Ambientes de testes e produção implantados, endurecidos e monitorados, com os acessos entregues à sua organização.

Arquitetura de acesso documentada

Clientes registrados, alcances por papel e caso de uso, e o procedimento para cadastrar ou revogar um consumidor sem depender de nós.

Relatório de conformidade

Quais perfis o repositório valida, com que resultado sobre os dados carregados e quais exceções ficaram abertas e por quê.

Runbook de operação

Backup, restauração, escalonamento e os procedimentos para as falhas que já sabemos que vão acontecer alguma hora.

Auditoria consultável

O registro de acessos com a retenção definida e a forma concreta de responder quem viu o quê, sem abrir um chamado com o fornecedor.

Plano de saída

O que se exporta, em que formato padronizado e em quanto tempo. Escrito desde o início, não negociado no dia em que se quer migrar.

Experiência

Repositórios que já operam

Os três tipos de repositório desta página correspondem a trabalho que a Meddyg já executou, e não a uma linha de catálogo.

RepositórioFHIR em produção

Primeiro servidor FHIR nacional para o EDUS/CCSS

A Meddyg implementou e colocou em produção o primeiro servidor FHIR que receberia as notificações de doenças de notificação obrigatória, vacinas e resultados de laboratório do EDUS da Caixa Costarriquenha de Seguro Social, e posteriormente de outros estabelecimentos de saúde.

RepositórioImagens médicas

Arquiteturas PACS em hospitais públicos da República Dominicana

A Meddyg implementou arquiteturas de PACS e estações de trabalho de diagnóstico para o intercâmbio de imagens médicas sob o padrão DICOM em hospitais públicos do Serviço Nacional de Saúde (SNS).

RepositórioDocumental assinado

Assinatura digital de recursos FHIR com o Banco Central da Costa Rica

O BCCR convidou a Meddyg a colaborar na integração do formato JAdES na GAUDI, sua plataforma de assinatura digital e selagem. A Meddyg prestou a assistência técnica para que as equipes do BCCR habilitassem a assinatura de recursos FHIR.

RepositórioConformidade

Os guias contra os quais validamos, ajudamos a escrever

A Meddyg participou do desenho, perfilamento e publicação dos guias de implementação HL7© FHIR© R5 da Costa Rica: Core, terminológico, resultados de laboratório e laudos de imagens médicas. A validação do repositório não se configura de fora do padrão.

Os casos acima correspondem a trabalho documentado da Meddyg. DICOM, HL7© FHIR©, IHE e SMART on FHIR são padrões e modelos de referência que aplicamos, não clientes nem certificações.

Para quem

Quem acaba precisando de um repositório gerenciado

Quase nunca é uma área de tecnologia procurando servidores, e sim um projeto clínico que precisa avançar.

Hospitais e clínicas privadas

Que precisam de uma base clínica padronizada sem montar —nem sustentar— uma área de infraestrutura para operá-la.

Centros de imagem e laboratórios

Que querem deixar de depender do PACS do fabricante e entregar seus resultados onde o clínico já trabalha.

Instituições públicas de saúde

Que devem cumprir o guia nacional e comprovar rastreabilidade de cada acesso à informação de uma pessoa.

Empresas de software clínico

Que precisam de um backend FHIR conforme para o seu produto, sem desviar a equipe para construir e operar um próprio.

Seguradoras e operadoras

Que recebem informação clínica de terceiros e devem custodiá-la com controle de acesso, retenção e valor probatório.

Programas nacionais e regionais

Que precisam de um ponto de recepção confiável para notificações, registros ou relatórios de muitos estabelecimentos ao mesmo tempo.

Autodiagnóstico

Sinais de que você precisa de um

Você tem um projeto clínico parado esperando onde guardar os dados.
Precisa de um servidor FHIR em produção e ninguém na sua equipe já operou um.
Tirar os estudos do PACS atual tem custo a cada tentativa.
Exigiram que cumprisse o guia nacional e você não tem com que validar o que publica.
Não consegue responder hoje quem consultou o prontuário de uma pessoa no mês passado.
Guarda documentos que deveriam ter valor probatório e hoje são arquivos sem assinatura.

Se reconhece dois ou mais, o problema não é de orçamento de infraestrutura: é de tempo. Um repositório gerenciado entra em operação em semanas, e não no próximo ciclo orçamentário.

Há quanto tempo o seu projeto espera por infraestrutura?

Conte-nos o que precisa custodiar e quem deve consultá-lo. Dizemos qual repositório lhe corresponde, o que inclui, em quanto tempo entra em operação e quanto custa mantê-lo andando.

Solicitar uma proposta→Falar com um especialista
Continuidade

Antes e depois do repositório

O repositório resolve onde os dados vivem. Em torno dele há decisões que convém tomar antes e trabalho que continua depois.

Avaliação de interoperabilidadeQuando ainda não há clareza sobre quais sistemas produzem a informação que o repositório vai receber.Definição de arquiteturasQuando o repositório é uma peça de uma arquitetura maior que ainda não está definida.Guias de ImplementaçãoQuando o perfil contra o qual o repositório deve validar ainda não está escrito nem publicado.Modelagem de dadosQuando o que vai ser carregado significa coisas diferentes conforme o sistema de onde vem.Camada FHIRQuando os sistemas que alimentam o repositório não falam FHIR e não vão ser substituídos.Integração com HIEQuando o repositório deve, além disso, responder a um ecossistema nacional de intercâmbio.
Ver todos os serviços→