Skip to main content

Modelo Computacional

O presente modelo computacional refere-se ao Registro de Imunobiológico Administrado em Campanha, ou simplesmente RIA-C.

O modelo computacional, até pelo nome, é para consumo de integradores (profissionais com habilidades em desenvolvimento de software). Gestores e outros profissionais não interessados em detalhes técnicos podem consultar o modelo de informação correspondente.

Orientações gerais

A representação JSON completa de um Registro de Imunobiológico Administrado em Campanha (RIA-C) pode ser obtido aqui.

Importante

O documento acima contém campos identificados por sequências como {{id-lab-ria}} que devem ser substituídos por valores apropriados e específicos de cada registro. Todos eles são comentados abaixo. Adicionalmente, não os interprete como as únicas variações possíveis.

Os modelos computacionais empregados pelo Ministério da Saúde e empregados para a integração com a RNDS estão registrados e publicados amplamente.

As partes de um RIA-C

O Registro de Imunobiológico Administrado em Campanha (RIA) realiza-se por meio dos recursos Composition e Immunization.

Estes dois recursos FHIR não são usados conforme toda a flexibilidade original, mas por meio de perfis (profiles) que estabelecem as adaptações/restrições nacionais.

Os perfis que detalham o registro de imunização no país são

Bundle (pacote)

Um terceiro recurso FHIR é necessário para montar um documento de um registro de imunobiológico administrado, o recurso FHIR Bundle, que funciona como um um contêiner para outros recursos FHIR.

Neste caso do RIA-C, a representação JSON de um documento a ser enviado, com algumas partes suprimidas, é fornecida abaixo. Todos os detalhes serão fornecidos nas seções seguintes. Esta representação permite identificar os dois recursos FHIR citados anteriormente,

{
"resourceType": "Bundle",
"meta": {
"lastUpdated": "2001-06-23T15:41:19-03:00"
},
"identifier": { ... omitido ... }
"type": "document",
"timestamp": "2001-06-23T15:41:19-03:00",
"entry": [
{
"fullUrl": "urn:uuid:transient-0",
"resource": {
"resourceType": "Composition",
...
},
{
"fullUrl": "urn:uuid:transient-1",
"resource": {
"resourceType": "Immunization",
...
}
}
]
}

Esta representaçào refere-se ao recurso Bundle, o que é constatado pelo valor da propriedade resourceType. A propriedade meta permite identificar quando foi realizada a última alteração deste Bundle. A propriedade identifier será comentada posteriormente. Veja que o objeto correspondente foi omitido. A propriedade type indica o propósito do Bundle, no caso, trata-se de um documento (document). A propriedade timestamp indica o instante em que o Bundle foi criado, provavelmente o mesmo instante da última atualização, fornecida na propriedade meta.lastUpdate.

A outra propriedade da estrutura parcial acima é entry, justamente aquela por meio da qual são fornecidos os recursos agrupados no Bundle, ou seja, um Composition e um Immunization, por meio dos perfis nacionais, conforme será detalhado nas seções seguintes.

Bundle (identifier)

O identificador (propriedade identifier) do Bundle cuja representação JSON foi omitida no exemplo acima, é definida por um objeto com duas propriedades: system e value.

A definição dos valores destas propriedes, conforme ilustrado abaixo, faz uso do identificador do solicitante e do identificador do registro, respectivamente representados pelas sequências {{identificador-solicitante}} e {{id-es-ria}}.

"identifier": {
"system": "http://www.saude.gov.br/fhir/r4/NamingSystem/BRRNDS-{{identificador-solicitante}}",
"value": "{{id-es-ria}}"
}

O identificador do solicitante, representado acima por {{identificador-solicitante}}, é fornecido pela RNDS quando o pedido de solicitação de acesso à RNDS é aprovado. Cada estabelecimento de saúde terá o seu próprio identificador fornecido pela RNDS. Consulte identificador do solicitante para detalhes.

O identificador do registro, por outro lado, representado acima por {{id-es-ria}}, é um identificador criado pelo estabelecimento de saúde para unicamente identificar cada registro de imunobiológico administrado. Quaisquer dois registros produzidos por um estabelecimento de saúde devem, necessariamente, possuir identificadores distintos.

O estabelecimento de saúde pode optar por criar identificadores sequenciais, por exemplo, "1", "2", e assim por diante. Ou ainda, "2020-09-04-0001", "2020-09-04-0002" e assim sucessivamente, dentre inúmeras outras possibilidades.

Informação

Um identificador universalmente único (Universally Unique IDentifier) ou UUID pode ser gerado de várias formas. Por exemplo, veja como em Java e JavaScript.

De posse tanto do identificador do solicitante, digamos "99", quanto do identificador de um registro a ser enviado para a RNDS, "04/09/2020-cdYQj", o trecho do JSON correspondente à propriedade identifier do Bundle a ser enviado para a RNDS, seria

"identifier": {
"system": "http://www.saude.gov.br/fhir/r4/NamingSystem/BRRNDS-99",
"value": "04/09/2020-cdYQj"
}

Em consequência, a estrutura JSON pode ser reescrita, considerando o preenchimento da propriedade identifier, conforme abaixo:

{
"resourceType":"Bundle",
"type":"document",
"timestamp":"2020-03-20T00:00:00-03:00",
"meta": {
"lastUpdated": "2020-03-20T00:00:00-03:00"
},
"identifier": {
"system": "http://www.saude.gov.br/fhir/r4/NamingSystem/BRRNDS-99",
"value": "04/09/2020-cdYQj"
},
"entry": [
{
"fullUrl": "urn:uuid:transient-0",
"resource": {
"resourceType": "Composition",
...
},
{
"fullUrl": "urn:uuid:transient-1",
"resource": {
"resourceType": "Immunization",
...
}
}
]
}

Bundle (recursos agrupados)

Um Bundle é empregado para reunir recursos FHIR, e entry, destacada abaixo, é a propriedade onde os recursos devem ser fornecidos, observe que é um array. No caso em questão, este array deve possuir duas entradas:

  "entry": [
{
"fullUrl": "urn:uuid:transient-0",
"resource": {
"resourceType": "Composition",
...
},
{
"fullUrl": "urn:uuid:transient-1",
"resource": {
"resourceType": "Immunization",
...
}
}
]

Estas duas entradas, conforme comentado acima, devem estar em conformidade com os perfis nacionais definidos para o RIA-C.

Há uma "conexão" entre os recursos do RIA-C. O recurso Composition faz referência ao recurso Immunization, o que é comentado na seção seguinte.

Referências entre recursos

O FHIR faz uso extensivo do conceito de referência. Ou seja, muitos dos elementos que compõem um recurso são referências para outros recursos.

Neste caso específico do RIA-C, o registro de imunobiológico administrado faz referência para a imunização propriamente dita, que é fornecido em recurso próprio, ou seja, a descrição do evento no qual a vacina é administrada.

Cada entrada do array é um objeto formado por duas propriedades, uma que identifica o recurso e permite referenciá-lo (fullUrl), e uma contendo o recurso propriamente dito (resource).

Na representação JSON abaixo os recursos são apenas parcialmente fornecidos. Apenas a propriedade resourceType foi fornecida para ambos os recursos. E a propriedade section fornecida apenas para o primeiro recurso.

Cada recurso possui o seu próprio resourceType e, portanto, sabe-se que os dois recursos fornecidos no Bundle de um RIA-C são um Composition e Immunization, nesta ordem.

Adicionalmente, a primeira entrada do array, recurso Composition, referencia a segunda entrada, Immunization, conforme a propriedade section.entry[0].reference, ilustrando a referência entre recursos.

  "entry": [
{
"fullUrl": "urn:uuid:transient-0",
"resource": {
"resourceType": "Composition",
...
"section": [
{
"entry": [
{
"reference": "urn:uuid:transient-1"
}
]
}
]
},
{
"fullUrl": "urn:uuid:transient-1",
"resource": {
"resourceType": "Immunization",
...
}
}
]

Registro de Imunobiológico Administrado em Campanha (perfil)

Um documento de registro de imunobiológico administrado é definido pela RNDS por meio do perfil Registro de Imunobiológico Administrado em Campanha.

As propriedades obrigatórias deste perfil são documentadas abaixo. Uma outra propriedade, não obrigatória, faz parte deste perfil, relatesTo. Esta propriedade é comentada na seção Substituição de um registro.

status. Identifica o estado do documento. São possíveis dois valores: "final" e "entered-in-error". Neste caso, o valor correto é "final", para indicar que o documento está concluído. A representação JSON correspondente é fornecida abaixo:

"status": "final"

type. Identifica o tipo do documento por meio da propriedade coding, que é um array, neste caso, de uma entrada apenas e obrigatória. O objeto correspondente a tal entrada possui duas propriedades, system e code. A primeira define o conjunto de valores possíveis, neste caso, o Tipo de Documento. A segunda, um dos valores possíveis. Dentre eles há "RIA", que representa "Registro de Imunobiológico Administrado", valor a ser utilizado neste cenário.

"type": {
"coding": [
{
"system": "http://www.saude.gov.br/fhir/r4/CodeSystem/BRTipoDocumento",
"code": "RIA"
}
]
},

subject. O indivíduo vacinado, ou melhor, uma referência para o indivíduo vacinado. A referência é definida pela propriedade identifier, que é detalhada por duas outras propriedades, system e value. A primeira, system, define o domínio de valores (namespace). A segunda, o valor que identifica o indivíduo em questão. Neste caso, o valor necessariamente deve ser o CNS do indivíduo. Abaixo segue a representação de subject na qual, em vez do CNS de um indivíduo, é fornecida a sequência {{individuo-cns}}.

"subject": {
"identifier": {
"system": "http://www.saude.gov.br/fhir/r4/StructureDefinition/BRIndividuo-1.0",
"value": "{{individuo-cns}}"
}
},

date. Data e hora em que o documento foi gerado, por exemplo:

"date" : "2020-03-20T00:00:00-03:00"

author. Identifica o responsável pelo conteúdo do registro, ou melhor, à semelhança de subject, é uma referência para o responsável, neste caso, o estabelecimento de saúde em questão. O estabelecimento é identificado pelo seu código CNES, abaixo representado pela sequência{{lab-cnes}}.

"author":[
{
"identifier":{
"system":"http://www.saude.gov.br/fhir/r4/StructureDefinition/BREstabelecimentoSaude-1.0",
"value":"{{lab-cnes}}"
}
}
],

title. O título do documento, para registro de imunobiológico administrado é o valor fornecido abaixo.

"title": "Registro de Imunobiologico Administrado na Campanha"

section. Define as seções empregadas pelo registro. Neste caso há uma única seção na qual é registrado o Imunobiológico Administrado em Campanha. Ou seja, a única seção é um recurso FHIR, Immunization definido pelo perfil citado e referenciado no documento não pelas propriedades system e value, conforme os casos anteriores, mas por uma referência interna ao documento. Isto é feito pela propriedade reference, e o valor deve coincidir com um fullUrl definido no Bundle.

"section": [
{
"entry": [
{
"reference": "urn:uuid:transient-1"
}
]
}
]

Imunobiológico Administrado em Campanha (recurso)

O perfil Imunobiológico Administrado em Campanha detalha o evento de imunização na qual um paciente é vacinado. As propriedades pertinentes são identificadas abaixo.

extension. Permite definir o tipo de grupo de atendimento empregado na vacinação em campanha. Conforme representado em JSON abaixo, o grupo é aquele de código "000907", referente a "Enfermeiro(a)".

"extension": [
{
"url": "http://www.saude.gov.br/fhir/r4/StructureDefinition/BRGrupoAtendimento",
"valueCodeableConcept": {
"coding": [
{
"system": "http://www.saude.gov.br/fhir/r4/CodeSystem/BRGrupoAtendimento",
"code": "000907"
}
]
}
}
],

status. Define o Estado do evento. Os estados possíveis são: "solicitado" (preparation), "suspenso" (on-hold), "concluído" (completed) e "cancelado por informação errada" (entered-in-error). Observe que o valor a ser fornecido é o código correspondente entre parênteses, em vez da representação textual em português.

"status": "completed"

vaccineCode. Identifica o imunobiológico administrado em campanha vacinal, o que é feito por meio de um único código definido por uma terminologia (coding). Em particular, pelas propriedades system, que identifica a terminologia e code, o código definido na terminologia correspondente ao imunobiológico administrado. Conforme ilustrado abaixo, o código 86 é empregado, correspondente à descrição "Covid-19-Coronavac-Sinovac/Butantan".

"vaccineCode": {
"coding": [
{
"system": "http://www.saude.gov.br/fhir/r4/CodeSystem/BRImunobiologico",
"code": "86"
}
]
}
Imunobiológico

O acesso aos códigos para identificação do imunbiológico pode ser realizado em BRImunobiologico. Em geral, na aba "Overview" os códigos seriam fornecidos, neste caso, terá que ser feito o download dos códigos em um arquivo XML a partir do botão no canto superior direito.

patient. Identifica o indivíduo que recebeu o imunobiológico. Trata-se de referência definida pela propriedade identifier, que é um objeto definido por duas outras propriedades, system e value. Conforme ilustrado abaixo, deve ser fornecido o CNS do indivíduo em questão.

"patient": {
"identifier": {
"system": "http://www.saude.gov.br/fhir/r4/StructureDefinition/BRIndividuo-1.0",
"value": "{{individuo-cns}}"
}
}

occurenceDateTime. Data e possivelmente hora em que o imunobiológico foi administrado.

"occurrenceDateTime": "2021-05-20T20:04:28.202Z",

manufacturer. O fabricante do imunobiológico definido por meio de duas propriedades: reference e display. No exemplo abaixo, a organização indicada é o Instituto Butantan, conforme o CNPJ. E o nome do fabricante definido como "Butantan/Sinovac".

"manufacturer": {
"reference": "/Organization/61821344000156",
"display": "Butantan/Sinovac"
},

lotNumber. Código do lote do imunobiológico.

"lotNumber": "LOTE-XA-2345"

performer. Identifica o profissional e a ocupação correspondente (CBO) de quem administrou o imunobiológico.

"performer": [
{
"function": {
"coding": [
{
"system": "http://www.saude.gov.br/fhir/r4/CodeSystem/BRCBO",
"code": "223505"
}
]
},
"actor": {
"reference": "/Practitioner/{{individuo-cns}}"
}
}
]

protocolApplied. O protocolo, ou recomendações seguidas por quem administrou a dose. Neste caso é esperado o código correspondente à dose. O código 9 define que a dose é única.

"protocolApplied": [
{
"doseNumberString": "9"
}
]

Substituição de um registro

Um registro de imunobiológico administrado já submetido para a RNDS pode ser substituído. A substituição pode ter como finalidade a retificação de informação fornecida. O documento que substitui passa a ser o registro ativo. O fluxo abaixo ilustra um cenário de substituição:

  1. Estabelecimento envia registro R para a RNDS com identificador local I (gerado pelo estabelecimento).
  2. RNDS produz o identificador N para o registro R. Na representação JSON abaixo este identificador é definido por {{id-rnds-ria}}. Neste ponto, existem dois identificadores pertinentes ao registro R, I e N, respectivamente, aquele fornecido pelo próprio estabelecimento e aquele definido pela RNDS.
  3. Estabelecimento detecta necessidade de retificação e monta um novo registro S, observando as orientações abaixo:
    1. O registro S, cujo conteúdo deve substituir o registro R, é confeccionado observando as orientações acima.
    2. O identificador local do registro S deve ser o mesmo do registro R, ou seja, I. Noutras palavras, o identificador local do registro retificador e do registro substituído devem ser iguais.
    3. A Composition correspondente ao registro S deve incluir a propriedade relatesTo. Esta propriedade é opcional e utilizada apenas para indicar a substituição. Em particular, esta propriedade identifica o registro a ser substituído, neste caso, o registro R. A identificação é ilustrada abaixo, onde a propriedade reference faz uso do identificador N, aquele fornecido pela RNDS, para identificar o registro R.
"relatesTo": [
{
"code": "replaces",
"targetReference": {
"reference": "Composition/{{id-rnds-ria}}"
}
}
],

O identificador atribuído pela RNDS a qualquer registro submetido de forma satisfatória é retornado por meio do header identificado por content-location ou location. Consulte identificador atribuído pela RNDS ao resultado para detalhes.