Skip to main content

Modelo Computacional

O presente modelo computacional refere-se ao Registro de Imunobiológico Administrado em Rotina de imunização, ou simplesmente RIA-R.

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 Rotina (RIA-R) pode ser obtido aqui. A escolha de JSON, em vez de XML ou Turtle, é arbitrária. Contudo, não prejudica o objetivo de esclarecer o modelo computacional.

Importante

O documento acima contém sequências como {{id-es-ria}} que devem ser substituídos por valores apropriados e específicos de cada registro. Todos eles são comentados abaixo. Outras informações não foram substituídas por sequências, como dadas, por exemplo.

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-R

O Registro de Imunobiológico Administrado em Rotina (RIA-R) realiza-se por meio dos recursos Composition e Immunization. Estes dois recursos FHIR não são usados conforme definidos, mas por meio de perfis (profiles) que estabelecem as adaptações/restrições nacionais. Adicionalmente, os perfis empregados são combinados em um documento por meio de um terceiro recurso, Bundle, ou seja, este terceiro recurso é empregado apenas para "empacotar" as informações necessárias.

Respire fundo, tudo isso é explicado em detalhes neste texto. A ilustração abaixo fornece a ideia de que um registro de imunobiológico administrado em rotina é um Bundle reúne dois outros recursos, por meio dos perfis nacionais, sendo que um deles faz referência para o outro.

Bundle (pacote)

Conforme mencionado acima, 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. Este recurso "empacota" os recursos Composition e Immunization, respectivamente, os perfis nacionais destacados abaixo:

Enquanto a figura acima é útil para compreendermos a relação entre recursos e perfis, a informação correspondente a ser transferida usa outra representação, aqui vamos ilustrar com JSON.

Neste caso do RIA-R, 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 (sem omissões). Esta representação permite identificar os dois recursos FHIR que compõem um registro de imunobiológico administrado, citados anteriormente.

{
"resourceType": "Bundle",
"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 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.

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.

Meta

Todo recurso possui a propriedade id e Meta, não incluídas aqui pelo motivo de se tratar da criação de um recurso. Neste caso, o id deve ser ignorado pelo servidor, assim como meta.versionId e meta.lastUpdated. Observe que meta ainda possui outros atributos opcionais. Consulte detalhes em https://www.hl7.org/fhir/resource.html#meta.

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, "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",
"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-R, repetidos abaixo por conveniência:

Há uma "conexão" entre os dois recursos do RIA-R fornecidos no Bundle. 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-R, o registro de imunobiológico administrado faz referência para a imunização propriamente dita, que é fornecido em recurso próprio, ou seja, o recurso que fornece detalhes da 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-R 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 Rotina (perfil)

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

As propriedades obrigatórias deste perfil são documentadas abaixo. Uma única 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" (finalizado ou concluído) e "entered-in-error" (cancelado por informação errada). 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á o código "RIA", correspondente a "Registro de Imunobiológico Administrado". Este código é o correto para este cenário, conforme abaixo.

"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 identifica o recurso referenciado, neste caso, um indivíduo, por meio das propriedades system e value. O value indica o código propriamente dito do documento de identificação do indivíduo. No trecho ilustrado abaixo é empregado o CNS do indivíduo. Contudo, o CPF pode ser utilizado em vez do CNS. O CNS é fornecido pela 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, neste caso, o valor predefinido conforme ilustrado 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. Neste caso, a referência não é realizada 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"
}
]
}
]

As observações acima cobrem todas as propriedades obrigatórias, a única opcional, relatesTo, é documentada em Substituição de um registro.

Imunobiológico Administrado (perfil)

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

status. Define o Estado do evento. Os estados possíveis são: preparation ("Solicitado"), on-hold ("Suspenso"), completed ("Concluído") e entered-in-error ("Cancelado por informação errada"). Observe que o valor a ser fornecido é o código destacado em negrito, em inglês.

"status": "completed"

vaccineCode. Identifica o imunobiológico administrado por meio de um conceito codificado. Para tal devem ser informados system e code, enquanto version é opcional. O system identifica o conjunto de imunobiológicos, enquanto code um imunobiológico específico, por exemplo, para "Soro antidiftérico" o código correspondente é 10, conforme ilustrado no trecho abaixo.

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

O acesso aos códigos para identificação do imunbiológico pode ser obtido aqui.

patient. Identifica o indivíduo que recebeu o imunobiológico. Trata-se de referência definida pela propriedade identifier, que é composta por duas outras propriedades, system e value. Conforme ilustrado abaixo, é fornecido o CNS do indivíduo em questão. Contudo, também pode ser fornecido o CPF em vez do CNS.

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

A identificação do paciente, ilustrada acima, é suficiente. Contudo, também pode vir acompanhada de duas outras propriedades não ilustradas, reference e type.

occurenceDateTime. Data ou data e hora em que o imunobiológico foi administrado. Conforme ilustrado abaixo, o imunobiológico foi administrado no dia 20 de maio de 2021, pouco após as 17h (horário de Brasília). Este formato indicado pela letra Z no final significa que a hora é UTC, e Brasília está três horas antes da hora UTC.

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

manufacturer. O fabricante do imunobiológico definido por meio do objeto identifier, definido por duas propriedades: system e value. O valor para system é fixo e exatamente aquele ilustrado abaixo, enquanto value identifica o fabricante dentre aqueles definidos em Fabricante do Imunobiológico. O valor 141 utilizado no trecho abaixo identifica o Instituto Vital Brazil.

"manufacturer": {
"identifier": {
"system": "http://www.saude.gov.br/fhir/r4/CodeSystem/BRFabricantePNI",
"value": "141"
}
},

Além de system e value também pode ser fornecida a propriedade use, que detalha o identificar em usual, oficial, temporário e outros. Esta propriedade não é obrigatória. As opções disponíveis são definidas por IdentifierUse.

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

"lotNumber": "LOTE-XA-2345"

expirationDate. Data da expiração do imunobiológico. Esta propriedade é opcional. Em tempo, todas as demais são obrigatórias.

site. Define a localização anatômica da aplicação de uma substância. As localizações possíveis estão identificadas por Local de Aplicação, e o valor 7 é empregado para "Glúteo".

"site": {
"coding": [
{
"system": "http://www.saude.gov.br/fhir/r4/CodeSystem/BRLocalAplicacao",
"code": "7"
}
]
},

route. Via por meio da qual o imunobiológico foi administrado. Os valores possíveis são definidos em Via de Administração, e o código 10885, utilizado no trecho abaixo, refere-se à via "Intradérmica".

"route": {
"coding": [
{
"system": "http://www.saude.gov.br/fhir/r4/CodeSystem/BRViaAdministracao",
"code": "10885"
}
]
},

performer. Identifica o profissional que administrou o imunobiológico. No trecho abaixo é fornecido o CNS do profissional que administrou o imunobiológico por meio da sequência {{individuo-cns}}.

"performer": [
{
"actor": {
"reference": "/Practitioner/{{individuo-cns}}"
}
}
]

protocolApplied. O protocolo seguido. Este protocolo é estabelecido por meio de uma propriedade e extensões.

A propriedade doseNumberString identifica a dose aplicada. O valor é definido pelo conjunto Dose do Imunobiológico. No trecho abaixo o valor empregado é 9, que indica dose única.

"protocolApplied": [
{
"doseNumberString": "9",
"extension" : [
... comentado abaixo ...
]
}
]

No trecho acima as extensões foram omitidas por simplicidade. Uma delas é obrigatória (Estratégia de Vacinação), a outra é opcional (BREstrategiaVacinacaoPesquisa).

A extensão Estratégia de Vacinação é obrigatória. O uso desta extensão se dá por meio de duas propriedades: (a) url e (b) conceito codificado. O valor da url é predefinido (fixo). O valor é fornecido no trecho abaixo. O valor do conceito codificado classifica a estratégia de vacinação. Neste caso, o valor 1 é empregado, correspondente à "Rotina".

{
"url": "http://www.saude.gov.br/fhir/r4/StructureDefinition/BREstrategiaVacinacao-1.0",
"valueCodeableConcept": {
"coding": [
{
"system": "http://www.saude.gov.br/fhir/r4/CodeSystem/BREstrategiaVacinacao",
"code": "1"
}
]
}
},
Estratégia de Vacinação

"Estratégia de Vacinação" foi empregado pela RNDS como "nome de fantasia" tanto para identificar uma extensão (extension) quanto um CodeSystem, respectivamente aqui e aqui. Os respectivos identificadores únicos, contudo, são: http://www.saude.gov.br/fhir/r4/StructureDefinition/BREstrategiaVacinacao-1.0 e http://www.saude.gov.br/fhir/r4/CodeSystem/BREstrategiaVacinacao. Observe que apesar da aparência, tais identificadores não são endereços de páginas na web.

A outra extensão, BREstrategiaVacinacaoPesquisa, é opcional, conforme mencionado anteriormente. Esta extensão é empregada para identificar detalhes da administração de imunobiológico em um cenário de pesquisa e, para tal, informações adicionais são necessárias. Neste caso tais informações são fornecidas como extensões desta extensão. Ou seja, apenas para deixar claro, um extensão também pode conter extensões. As extensões contidas na extensão opcional são: (a) numeroProtocoloEstudoANVISA; (b) numeroVersaoProtocoloEstudo e (c) numeroRegistroVacinaAnvisa. Veja o trecho que ilustra a extensão opcional abaixo.

{
"url": "http://www.saude.gov.br/fhir/r4/StructureDefinition/BREstrategiaVacinacaoPesquisa-1.0",
"extension": [
{
"url": "numeroProtocoloEstudoANVISA",
"valueString": "GU1AMT9CYR"
},
{
"url": "numeroVersaoProtocoloEstudo",
"valueString": "F3D1U354V6"
},
{
"url": "numeroRegistroVacinaAnvisa",
"valueString": "WWZZJJWIBF"
}
]
}

O trecho acima ilustra a extensão opcional, com a propriedade url fixa e demais propriedades estabelecidas por meio de extensões.

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.