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

Princípios de design

Tabela 1: princípios a serem observados

Elemento	Descrição	Justificativa
Guia de Implementação (IG)	Único IG evolutivo fornecendo documentação unificada e centralizada para laboratóriostodos e contemplanto todos os tipos de exames com perfis, terminologias e extensões específicos, conforme a necessidade.	Simplifica a governança, promove consistência e facilita a manutenção. A versão do IG reflete as mudanças de negócio e técnicas.
ValueSet (VS) para tipos de exames	Um VS contendo todos os códigos únicos para cada tipo de exame enviado pelo laboratório.	Padroniza a identificação da estrutura de informação laboratorial a ser enviada para a SES-GO. O versionamento assegura que quaisquer alterações (adições, remoções ou correções) sejam rastreadas e compatíveis.
Identificação do tipo de exame	Utilização de Bundle.meta.tag para identificar o tipo de exame.	Facilita a identificação da estrutura da informação do exame enviado, sem a necessidade de inspeção do Bundle. Perfil específico terá binding para o ValueSet comentado acima.
Versionamento	Política robusta para gerenciar e comunicar qualquer mudança em CodeSystem, ValueSet e outros.	Permite a evolução do sistema de forma controlada, sem comprometer a compatibilidade com integrações existentes.
Perfis FHIR para Bundles	Criação de perfis FHIR específicos para cada tipo de exame, refletindo as exigências de estrutura e elementos obrigatórios.	Permite que os dados sejam validados e processados de forma automatizada, assegurando a qualidade do conteúdo recebido. O versionamento dos perfis possibilita a evolução dos requisitos sem interromper a integração com sistemas legados.
Validação de dados	Processo de validação dos Bundles recebidos, considerando o código do exame (e sua versão) extraído do Bundle.meta.tag e os perfis associados.	Assegura que os dados estejam em conformidade com os requisitos do IG e dos perfis FHIR, mantendo a integridade e qualidade da informação. A validação diferenciada por versão permite identificar incompatibilidades e orientar os laboratórios sobre eventuais ajustes.

---

Tabela 2: Implementação Detalhada por Elemento Estratégico

Elemento Estratégico	Implementação Detalhada
Guia de Implementação (IG)	- Adotar versionamento semântico (ex.: MAJOR.MINOR.PATCH – 1.0.0, 1.1.0 etc.). - Incluir um changelog detalhado que registre todas as alterações, correções e atualizações. - Definir ciclos de vida para cada versão (datas de release, prazos para depreciação) e comunicar previamente aos laboratórios. - Disponibilizar o IG em um repositório versionado (ex.: Git) e oferecer exemplos práticos alinhados à versão em uso. - Estabelecer um processo formal de revisão e aprovação para atualizações.
CodeSystem (CS) e ValueSet (VS) para Tipos de Exames	- Utilizar versionamento semântico para o CS e VS, indicando MAJOR para mudanças que quebrem a compatibilidade, MINOR para incrementos compatíveis e PATCH para correções. - Manter documentação com histórico (changelog) das alterações em cada versão. - Estabelecer mecanismos de depreciação e migração para códigos modificados, garantindo que as versões antigas continuarão sendo interpretadas durante um período de transição. - Disponibilizar referências explícitas à versão utilizada em cada recurso ou Bundle, facilitando a validação.
Versionamento do CodeSystem e ValueSet	- Adotar o versionamento semântico (MAJOR.MINOR.PATCH): - MAJOR: alterações estruturais ou quebras de compatibilidade. - MINOR: inclusão de novos códigos ou elementos sem afetar a retrocompatibilidade. - PATCH: correções e ajustes menores. - Manter e divulgar um changelog que descreva as modificações e seus impactos. - Disponibilizar mecanismos automatizados para notificação de mudanças (por exemplo, alertas via API ou portais de desenvolvedores). - Implementar testes de regressão para confirmar que novas versões não afetem funcionalidades existentes. - Planejar a coexistência de múltiplas versões, disponibilizando um período de transição para clientes e laboratórios migrarem gradativamente.
Identificação do Tipo de Exame	- Incluir, no Bundle.meta.tag, não apenas o código, mas também uma referência à versão do CodeSystem utilizada. - Documentar a política de atualização dos códigos e as regras para migração em caso de mudança de versão. - Definir um mecanismo de validação que verifique inconsistências entre a versão indicada e a versão esperada pelo IG.
Tipo de Bundle	- Definir explicitamente, no IG, qual o Bundle.type aplicável para cada cenário (ex.: document para relatórios completos). - Registrar e versionar as definições e orientações de uso do Bundle.type. - Incluir nas atualizações do IG quaisquer mudanças que possam afetar o tipo definido, com comunicação antecipada aos laboratórios.
Perfis FHIR para Bundles	- Adotar versionamento semântico para cada perfil FHIR (ex.: 1.0.0, 1.1.0, etc.), registrando as alterações e incrementos. - Incluir metadados dos perfis (versão, data de emissão, autor/revisor) dentro da definição do recurso. - Documentar mudanças relevantes e impactos na validação dos Bundles. - Disponibilizar ambiente de testes e ferramentas de validação que suportem múltiplas versões dos perfis. - Implementar testes de regressão automatizados para garantir a compatibilidade dos Bundles com cada nova versão dos perfis.
Validação de Dados	- Desenvolver uma lógica de validação que: - Verifique o Bundle.meta.tag e confirme a correspondência com a versão do CodeSystem referenciada. - Valide o Bundle contra o perfil FHIR correspondente à sua versão, emitindo mensagens de erro claras e indicativas. - Incluir, nos relatórios de erro, informações sobre qual versão do perfil ou CS/VS foi esperado versus a versão recebida. - Centralizar as validações e manter um log histórico das versões testadas e dos problemas detectados. - Disponibilizar orientações e documentação de apoio aos laboratórios para a adoção da versão correta dos recursos.