A UDENTIVA embute na própria arquitetura a maturidade de processo exigida para software de saúde. Esta página apresenta, com evidências, nosso ciclo de vida de desenvolvimento, os níveis de capacidade SPICE / ISO-IEC 15504, nossos mecanismos contínuos de registro e controle de erros, nossos critérios de versão e segurança e nosso histórico de desenvolvimento.
Fundamento: Regulamento sobre Sistemas de Gestão de Informação em Saúde (MevzuatNo 39682), art. 6 e art. 20 — exigência de certificação de qualidade de software (CMMI/SPICE).
A definição de processos, a implementação e os produtos de trabalho rastreáveis estão estruturados; mecanismos de medição quantitativa, prevenção de defeitos e melhoria contínua operam em produção. A declaração oficial de nível de capacidade está sujeita a avaliação (appraisal) independente.
O SPICE avalia os processos por nível de capacidade, de 0 a 5. A UDENTIVA está estruturada para atender às expectativas dos Níveis 1-3 no nível de definição de processo/implementação/produtos de trabalho rastreáveis; para os Níveis 4-5, mecanismos de medição quantitativa e melhoria contínua estão em operação. A declaração oficial de nível está sujeita a avaliação independente.
Os mecanismos de controle quantitativo e melhoria contínua dos Níveis 4-5 operam abaixo com suas evidências (medição ao vivo, registro de erros/CAPA, logs de implantação).
Cada área de processo corresponde a uma implementação concreta na UDENTIVA e a uma evidência auditável. O processo não é um documento, é código em execução.
| Área de Processo | Aplicativo UDENTIVA | Evidência |
|---|---|---|
| ENG.1 Elicitação de Requisitos | Definição de requisitos por mapa de fases + fatia vertical (vertical slice); o contrato de projeto UDENTIVA.md fixa os requisitos. | UDENTIVA.md (REGRAS DE OURO), especificação técnica 02_tech_spec/, mapa de fases/módulos |
| ENG.4 Design de Software | Monólito modular; os pacotes de contexto não compartilham as tabelas uns dos outros; comunicação por interface; serviço externo = adapter. | regra de fronteira internal/{identity,patient,billing,export,...}; ADR-001..008 |
| ENG.5 Construção de Software | SQL explícito (sqlc, sem ORM); context como primeiro parâmetro em cada função; encapsulamento de erros %w; dinheiro = numeric. | override de tipo em sqlc.yaml (numeric→string), db/queries/*.sql, gofmt/golangci-lint |
| ENG.6 Integração de Software | Cadeia loopback PHP(BFF) ↔ Go ↔ PostgreSQL ↔ Redis; única superfície pública. | web/core/ApiClient, saúde de componentes /healthz (db+redis) |
| ENG.7 Teste de Software | Teste de isolamento cross-tenant (o mais crítico), idempotência, conflito de agendamento, precisão monetária, 2FA/OTP, vetor TOTP RFC6238, QR (verificação OpenCV+ISO). | internal/integration/*_test.go, platform/totp/totp_test.go, go test ./... |
| SUP.1 Garantia de Qualidade | Cada PR deve cumprir as REGRAS DE OURO; lint limpo; se o teste de isolamento estiver vermelho na CI, não há merge. | golangci-lint, Definition of Done kontrol listesi |
| SUP.8 Gestão de Configuração | Controle de versão Git (branch core); versionamento sequencial de esquema com goose; artefatos de build são copiados como backup. | git, goose_db_version tablosu, .tools/deploy yedekleri |
| SUP.9 Resolução de Problemas | Registro de auditoria append-only + outbox de e-mail/SMS (registro de cada envio) + disciplina de backup/rollback de deploy. | audit_log, email_outbox/sms_outbox, bin/server.exe.bak-* rollback |
| SUP.10 Gestão de Solicitações de Mudança | Cada mudança de esquema é uma nova migração numerada; reversível (goose Down); aprovação do classificador de deploy. | db/migrations/0001..0027, +goose Up/Down |
| MAN.3 Gestão de Projeto | Entrega por fatia vertical (cada fatia funciona de ponta a ponta); notas de handover de sessão. | super-devam.md, faz tablosu (DoD per dilim) |
| MAN.6 Medição | Verificação de saúde, medição de capacidade, métricas de envio de e-mail/SMS, volume de auditoria, telemetria de eventos ao vivo. | /healthz, painel de Monitoramento de Processos & Qualidade (evento/erro/deploy/KPI) |
As responsabilidades são divididas em camadas; a autoridade do domínio está em um único ponto e é isolada por loopback. O navegador vê apenas o BFF fino e nunca consegue acessar diretamente as camadas de domínio e dados.
| Camada | Responsabilidade e Segurança | Localização |
|---|---|---|
| Sunum (BFF) | PHP 8.4 — BFF fino: sessão, render, CSRF, roteamento. SEM regra de negócio/DB. Única superfície pública (IIS:443). | web/ |
| Uygulama / Domain | Monólito modular em Go — a ÚNICA autoridade do domínio. RBAC, regras de negócio, transações. Escuta apenas 127.0.0.1. | api/internal/ |
| Veri | PostgreSQL — cada tabela com tenant_id + RLS FORCE; SQL explícito (sqlc), parametrizado. Dinheiro em numeric. | api/db/ |
| Cache / Fila | Redis — sessão, idempotência, bloqueio distribuído, fila asynq (SMS/e-Fatura). | platform/redisx |
| Nesne Depolama | Compatível com S3 — arquivos grandes (radiografias) via presigned/stream; blob nunca no DB. | platform/storage |
| Serviço Externo (adapter) | e-Fatura, SMS (NetGSM), e-mail (SMTP), (futuramente e-Nabız/MEDULA/DICOM) — abstraídos por trás de uma interface. | internal/notify |
A medição não é uma declaração, é um sistema em funcionamento. Todas as operações são contadas ao vivo (sucesso/falha), os erros de produção são capturados em um registro permanente e o framework de KPI abaixo é vinculado a ações periódicas. As fontes de dados são tabelas reais: event_counter (contador de operações ao vivo), error_log (registro permanente de erros), deploy_log (registro de implantações).
| Área de Medição | KPI | Meta | Fonte de Dados | Período | Ação |
|---|---|---|---|---|---|
| Segurança de isolamento de tenant | cross-tenant test fail | 0 | CI / izolasyon testi | her PR | Bloqueio de merge |
| Erro de produção | erro explícito (5xx/panic) | 0 | error_log (persistente) | contínuo/ao vivo | RCA + CAPA zorunlu |
| Taxa de sucesso das operações | success / toplam event | ≥ 99% | event_counter (ao vivo) | contínuo/ao vivo | Causa-raiz em caso de queda |
| Tempo de resolução | MTTR (resolução média) | ↓ tendência decrescente | error_log (resolved) | mensal | Trend incelemesi |
| Confiabilidade de implantação | taxa de rollback | < %5 | deploy_log | 30 dias | Rollback review |
| Segurança de identidade | 2FA/OTP kritik olay | 0 | audit + event_counter | mensal | Hardening |
| Confiabilidade de mensageria | SMS/e-posta failure | ↓ baixo | *_outbox | diário | Revisão de provedor |
| Prontidão de restauração | sucesso do teste de restore | %100 | DR test (hedef) | trimestral | Atualizar runbook |
Todo erro de produção passa por um ciclo padrão de análise de causa-raiz (RCA) e ação corretiva/preventiva (CAPA); a recorrência do mesmo erro é impedida por controle de regressão e monitoramento de tendências.
O erro de produção (5xx/panic) é capturado automaticamente → error_log persistente (em repetição da mesma assinatura, count++, tendência de defeitos).
Determina-se o nível (error/panic), o impacto e o número de repetições; a prevalência é medida pelos contadores de eventos com falha.
A análise de causa-raiz é realizada e registrada no painel de Monitoramento de Processos.
A ação corretiva + ação preventiva (código, teste, regra de migração, controle de segurança) é definida e registrada.
Adiciona-se um teste/regra que impede a repetição do mesmo erro; é monitorado por telemetria contínua.
As tendências de KPI (MTTR, taxa de erros, rollback) são avaliadas periodicamente; para erros recorrentes, abre-se uma ação em nível de processo.
A essência do SPICE Nível 5: registro contínuo de erros, mantê-los sob controle, prevenção de defeitos e melhoria contínua. A UDENTIVA opera esses mecanismos em produção.
O audit_log imutável (append-only) registra permanentemente cada operação crítica; email_outbox/sms_outbox registram cada envio (status, attempts, error). Nenhum evento se perde silenciosamente.
Envelope de erro consistente {error:{code,message}}; erro interno/stack nunca é vazado. Antes de cada deploy, backup do binary + web; em caso de outage, rollback em segundos com bin/server.exe.bak-*.
Arquitetura fail-closed: sem contexto RLS, 0 linhas; a idempotência impede operações duplicadas; dinheiro em numeric torna impossível o erro de float; a whitelist (dataset de exportação) previne injeção de SQL. Os erros são impedidos desde o design.
Componentes críticos são verificados por dois métodos independentes: vetor de teste TOTP RFC6238, decode OpenCV cv2 + codeword de referência ISO/IEC 18004 para QR, teste de isolamento cross-tenant.
Em cada sessão, auditoria de segurança → achados → hardening (ex.: RBAC de fase2/fase3 adicionado, 2FA, Export API). A memória institucional é preservada com notas de processo (super-devam.md).
Uma nova exigência regulatória (Visão VEM) é convertida diretamente em funcionalidade de produto e em evidência; as mudanças na legislação são monitoradas continuamente e registradas no mapa de conformidade.
Uma única base de código, restrição por flag — sem fork.
Versão rastreável nas camadas de esquema, fonte, implantação e API.
Todo o processo de desenvolvimento está sob controle de versão; cada implantação é reversível (rewind/rollback).
Segurança não é um recurso, é a própria arquitetura. Regras inegociáveis, cuja violação implica rejeição do PR:
O sistema foi construído com fatias verticais, cada uma funcionando de ponta a ponta. Abaixo estão as fases e a cronologia dos trabalhos recentes de segurança/regulação.
pgx+sqlc, goose, teste de RLS fail-closed, WithTenantTx, middleware de sessão, login+RBAC, auditoria, loopback PHP↔Go, base asynq, health.
CRUD de Paciente + teste de isolamento cross-tenant → Agendamento (exclusion constraint + Redis lock) → Odontograma/Plano de tratamento (FDI, append-only) → Cobrança/Conta corrente/Caixa (derive, idempotente) → adapter e-Fatura (fast-follow) → Estoque → Radiografia (S3) → Lembrete por SMS (asynq backoff).
Tier de operador de plataforma (super-admin) (X-Platform-Key, plano de identidade separado); gestão de tenants, modelo de assinatura/faturamento, medição de capacidade, editor de versão legal, reCAPTCHA, configurações NetGSM.
i18n (20 dil, key-based, RTL); 20 tema + klinik public site (/s/{slug}) + lead-booking; demo klinik siteleri.
Primitivo OTP compartilhado; redefinição de senha + magic-link + ativação de conta (SMTP real); núcleo de SMS NetGSM; auth público multi-tenant; gestão de usuários da clínica.
TOTP (RFC6238) + códigos de reserva; QR OBRIGATÓRIO (independente de externos, qr.js sem violar CSP; verificado de forma independente com OpenCV+ISO); verificação de telefone por SMS (consentimento KVKK).
Visão VEM (Modelo de Dados Mínimo) com 12 export views + Export API (definida por SuperUser, travada por tenant, fail-closed); mapa de Legislação & Conformidade; revisão de contratos legais 100% orientada à legislação.
Central de Suporte com acompanhamento de tickets; documentação de processos SPICE (esta página); auditoria de segurança contínua + hardening.
Para informações detalhadas sobre arquitetura, segurança e conformidade regulatória, entre em contato com nossa equipe.
We use cookies necessary for core functionality; analytics and marketing cookies are enabled only with your consent. Política de cookies