Pular para conteúdo

EHRPoster - Envio de informações clínicas em FHIR R4

A API EHRPoster é usada para enviar informações clínicas para a plataforma em formato FHIR. Essa API possui uma única operação (POST), através da qual as informações são enviadas, encapsuladas em um recurso Bundle, do tipo “transcation” (“type” = “transaction”). A mensagem deve ser codificada em representação JSON (Content-Type application/fhir+json; Accept application/fhir+json).

Para suporte em formato XML (Content-Type application/fhir+xml; Accept application/fhir+json), favor solicitar a liberação antes de utilizar a API.

A API usa autenticação OAuth2. Credenciais diferentes são utilizadas nos ambientes de QA (quality assurance) - usado para testes prévios e homologação da integração - e PRD (Produção) - usado para integrações testadas e aprovadas para uso produtivo. Para obter uma credencial de acesso à API entre em contato com o administrador da API.

ehrposter

AAPI suporta diferentes tipos de Bundle, cada tipo associado a um caso de uso. Cada Bundle suportado pela API é especificado em um perfil FHIR, que possui uma “url” que o identifica. Atualmente, a API suporta os seguintes perfis:

Caso de Uso Descrição URL do perfil
Sumários de eventos clínicos Usado para representação de informações clínicas geradas em contatos assistenciais ambulatorias (Registro de Atendimento Clínicio), internações (Sumário de Alta) ou de pronto atendimento (Sumário de Pronto Atendimento). http://ehrrunner.com/fhir/StructureDefinition/EventSummary-1.0
Resultados de exames laboratoriais Usado para representação de resultados de exames laboratorias. http://ehrrunner.com/fhir/StructureDefinition/Laboratory-1.0
Resultados de exames de imagens Usados para representação de resultados de exames de imagem. http://ehrrunner.com/fhir/StructureDefinition/ImageDiagnosticReport-1.0

Cada Bundle deve sempre conter um recurso FHIR principal (obrigatório), acompanhado, conforme o caso, de recursos FHIR complementares (obrigatórios e opcionais - conforme cardinalidade indicada para cada caso de uso), todos registrados na plataforma por requisições do tipo “POST”. Esses recursos são indicados na tabela abaixo.

Caso de Uso URL do perfil Recurso principal Recursos complementares (obrigatórios e opcionais)
Sumário de Eventos Clínico http://ehrrunner.com/fhir/StructureDefinition/EventSummary-1.0 Encounter (1..1) Condition (0..*)
Procedure (0..*)
ServiceRequest (0..*)
MedicationRequest (0..*)
AllergyIntolerance (0..*)
Observation (0..*)
Resultados de Exames Laboratorial http://ehrrunner.com/fhir/StructureDefinition/Laboratory-1.0 DiagnosticReport (1..1) ServiceRequest (0..*)
Binary (1..1)
Resultado de Exames de Imagem http://ehrrunner.com/fhir/StructureDefinition/ImageStudyReport-1.0 DiagnosticReport (1..1) ServiceRequest (0..*)
Binary (1..1)

O recurso FHIR principal deve possuir ainda:

  • um identificador (“identifier”) com informações sobre a identificação do registro no sistema de origem;

  • uma referência para o paciente, sujeito das informações clínicas.

Nos exemplos apresentados nessa documentação, as propriedades indicadas entre chaves duplas (formato Postman) {{ }} representam variáveis que devem ser substituídas pelos valores adequados, conforme o caso.

A seguir, é apresentado um exemplo de como o recurso Bundle é formado.

{
   "resourceType":"Bundle",
   "meta":{
      "profile":[
         "http://ehrrunner.com/fhir/StructureDefinition/Laboratory-1.0"
      ]
   },
   "type":"transaction",
   "entry":[
      {
         "fullUrl":"urn:uuid:report-1",
         "resource":{
            "resourceType":"DiagnosticReport",
            (...)
            "identifier":[
               {
                  "system":"urn:oid:{{oidSistemaOrigem}}",
                  "value":"{{recordId}}"
               }
            ]
            (...)
            "subject":{
               "reference":"Patient?identifier=urn:oid:{{patientIdOid}}%7C{{patientId}}"
            },
            (...)
         },
         "request":{
            "method":"POST",
            "url":"DiagnosticReport"
         }
      }
      // entry de recursos complementares
      (...)

   ]
}
As variáveis neste exemplo são:

Variável Significado Obervações
oidSistemaOrigem Identificador único (oid) do sistema (instância) que envia a informação Esse valor é fornecido pela governaça da plataforma. O valor é associado à credencial de segurança gerada para o parceiro que utiliza o serviço, sendo que recursos enviados contento valores não registrados pela governança são rejeitados pela API.
recordId Identificador local do registro que está sendo integrado Idealmente, esse valor deve conter o id único (ex. chave primária da tabela) no sistema de origem. É utilizado para rastreabilidade das integrações, correção de erros de integração ou substituição das informações enviadas por versões mais novas (atualizações) dos recursos. Para resultados de exames, sugere-se que esse valor contenha o número da OS (LIS ou RIS)
patientIdOid Identificador (oid) do sistema de nomes utilizado para identificar o paciente São suportados*: CPF (OID: 2.16.840.1.113883.13.237) e CNS (OID: 2.16.840.1.113883.13.236)
patientId Identificador do paciente CPF ou CNS, conforme o patientIdOid disponível.

*para suporte a outros NamingSystem, favor contatar o administrador da API.