Guia de Implementação da SES GO - Segurança - Local Development build (v0.0.2) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Referências

Abaixo segue uma apreciação das relações que podem ser estabelecidas entre instâncias de recursos FHIR, em particular, por meio do tipo de dados Reference. Na sequência são fornecidas as necessidades a serem atendidas pela estratégia de assinatura digital e, por fim, as restrições impostas sobre o tipo de dados Reference para atender tais necessidades.

Convém reiterar que o contexto contemplado é o da transferência de informação em saúde assinada digitalmente. Há várias questões envolvidas. Por exemplo, o excerto da especificação do padrão FHIR, Copiando recursos e atribuindo novos IDs, esclarece a necessidade de atualizar referências usadas por instâncias transferidas:

"Quando recursos são trocados entre sistemas, pode ser necessário atribuir novos IDs lógicos a eles. Quando um recurso recebe um novo ID lógico, nada no recurso é alterado além do Resource.id, mas qualquer referência que aponte para esse recurso precisa ser atualizada. A necessidade de novos IDs depende do contexto, assim como a forma como as referências aos recursos são atualizadas."

Isso motiva uma compreensão ampla do emprego de referências, o que é feito abaixo, seguido de necessidades definidas para o contexto em questão e as repercussões destas necessidades, registradas na forma de restrições.

Compreendendo referências

Esta seção investiga as relações estabelecidas entre instâncias, sem perda de generalidade, pela relação entre uma instância de Observation e a instância de Patient, respectivamente, uma observação realizada sobre um paciente. Quaisquer outros recursos poderiam ser empregados. Tanto que o foco está concentrado no tipo de dados Reference, o tipo por meio do qual estas ligações entre instâncias pode ser realizado.

Considere abaixo a instância do recurso Observation. O elemento subject do tipo Reference liga esta instância a um paciente que possui um identificador de negócio com o valor x. Neste caso, o tipo Resource não identifica necessariamente uma instância de Patient. Em vez disso, fornece um identificador de negócio para uma entidade, neste caso, um paciente.

{
   "resourceType" : "Observation",
   "status" : "final",
   "code" : {
      "text" : "massa"
   },
   "subject" : {
      "identifier" : {
         "value" : "x"
      }
   }
}

Esta instância é autocontida. Observe que há uma referência lógica por meio da propriedade identifier de Reference. A variante abaixo também é autocontida e, novamente, a instância de Patient correspondente ao paciente sobre o qual a observação é feita não é indicada diretamente. O que é fornecido é um identificador de negócio (CPF) que identifica o paciente.

{
   "resourceType" : "Observation",
   "status" : "final",
   "code" : {
      "text" : "massa"
   },
   "subject" : {
      "identifier" : {
         "system" : "https://saude.br/sid/cpf",
         "value" : "123.456.789-00"
      }
   }
}

O cenário abaixo também ilustra uma instância autocontida. À semelhança do caso anterior, nenhuma instância de Patient é diretamente indicada, apenas um simples texto é fornecido. Em tempo, a interpretação do contexto clínico das informações e das informações propriamente ditas está além do escopo de interesse.

{
   "resourceType" : "Observation",
   "status" : "final",
   "code" : {
      "text" : "massa"
   },
   "subject" : {
      "display" : "Seu José da padaria"
   }
}

Na variante abaixo, também autocontida, a instância de Observation indica diretamente a instância de Patient presente internamente no elemento contained.

{
    "resourceType": "Observation",
    "contained": [
        {
            "resourceType": "Patient",
            "id": "1",
            "name": [
                {
                    "text": "José da Silva"
                }
            ]
        }
    ],
    "status": "final",
    "code": {
        "text": "massa"
    },
    "subject": {
        "reference": "#1"
    }
}

Os cenários acima ilustram instâncias que não referenciarem diretamente uma instância externa. Por outro lado, a instância abaixo faz referência a uma instância de Patient por uma URL absoluta (a URL de localização da instância).

{
   "resourceType" : "Observation",
   "status" : "final",
   "code" : {
      "text" : "massa"
   },
   "subject" : {
      "reference" : "http://algum.server/Patient/x"
   }
}

A instância acima usa uma URL absoluta, enquanto aquela abaixo, usa uma URL relativa. Ambas são referências para instâncias externas.

{
    "resourceType": "Observation",
    "status": "final",
    "code": {
        "text": "massa"
    },
    "subject": {
        "reference": "Patient/x"
    }
}

Ainda é possível empregar o elemento Reference.reference, no contexto de um Bundle, para indicar uma instância externa à instância de Observation, conforme abaixo.

{
    "resourceType": "Observation",
    "status": "final",
    "code": {
        "text": "massa"
    },
    "subject": {
        "reference": "urn:uuid:550e8400-e29b-41d4-a716-446655440000"
    }
}

Estas possibilidades de uso do tipo de dados Reference, ilustradas acima, são sumarizadas na tabela abaixo.

Necessidades

• N1 Quando uma instância aponta para um conteúdo externo, a informação em saúde registrada depende do conteúdo referenciado (ou então a referência poderia ser removida). Isso significa que, ao assinar a instância, o signatário certifica apenas a referência, e não a integridade completa da informação. Dessa forma, mesmo que o conteúdo referenciado seja alterado, a assinatura da instância continua válida para o receptor, pois a referência não foi alterada. Tendo em vista a indisponibilidade, no momento, de um serviço que assegure o conteúdo indicado por uma referência, essa situação não é aceitável, e a estratégia de assinatura deve abranger apenas instâncias autocontidas, ou seja, aquelas que não possuem referências a conteúdos externos não assinados.

• N2 A informação em saúde assinada deve ser transferida por meio de um Bundle, cuja preservação (manutenção) não é obrigatória para garantir a validação da assinatura digital. Isso significa que, ao receber o Bundle, suas instâncias podem ser extraídas e armazenadas em outros repositórios sem comprometer a validade da assinatura.

• N3 A estratégia deve adotar padrões técnicos amplamente reconhecidos e considerados sólidos para a definição e validação da assinatura digital, alinhando-se às diretrizes do FHIR e a outras recomendações aplicáveis.

Restrições

As necessidades acima impõem as seguntes restrições a serem observadas pelo presente guia:

• Toda a informação em saúde a ser assinada está registrada em um conjunto de instâncias FHIR. Esse conjunto define o que será assinado. A definição deste conjunto faz parte do escopo da saúde e está além do foco corrente, aqui restrito à produção da assinatura de tal conjunto.
• Uma instância de Provenance deve ser criada para guardar a assinatura propriamente dita no elemento Provenance.signature, além de uma referência para cada instância do conjunto assinado. Tais referências serão registradas no elemento Provenance.target.
• Todas as instâncias do conjunto assinado, bem como a instância de Provenance, devem estar contidas em um Bundle. Esse Bundle é utilizado para a transferência da informação em saúde assinada juntamente com a correspondente assinatura.
• Todo valor do tipo de dados Reference, presente no conjunto assinado, inclusive na instância de Provenance, deve satisfazer as seguintes regras:
  • Se o valor de Reference.identifier é utilizado, então Reference.reference não poderá ser utilizado e vice-versa. Ou seja, o uso de um inibe o uso do outro. O uso de Reference.identifier é o método recomendado para identificar conceitos de negócio, sempre que o cenário permitir.
  • Se o valor de Reference.reference é fornecido, ele deve obrigatoriamente ser um UUID no formato urn:uuid:[uuid], onde [uuid] é um UUID válido, por exemplo, urn:uuid:550e8400-e29b-41d4-a716-446655440003.
  • Para cada valor de Reference.reference, contido no conjunto assinado e na instância de Provenance, deve existir uma entrada no Bundle cujo fullUrl possui o mesmo valor.