Sistema de gestão da qualidade · hospitais

Gestão da qualidade hospitalar em uma única base de dados.

O QualyFactor é um QMS (Quality Management System) para operação hospitalar: ouvidoria, educação permanente, gestão de leitos, não-conformidades, gestão documental, projetos e comissões operam sobre o mesmo banco de dados, com escopo por unidade, trilha de auditoria e regras críticas apuradas no próprio banco.

app.qualyfactor.com Ver arquitetura ↓

Ficha técnica

Classe: QMS — Sistema de Gestão da Qualidade hospitalar
Plataforma: Aplicação web SSR — Nuxt 4 · Vue 3 · TypeScript
Banco de dados: PostgreSQL (Supabase) · RLS em todas as tabelas
Implantação: Multi-tenant — escopo por unidade hospitalar em todas as consultas
Interoperab.: HL7 FHIR R4 — application/fhir+json
Idioma: Português (pt-BR)

01 · MÓDULOS

Módulos funcionais

Cada módulo opera sobre o mesmo modelo de dados e a mesma camada de autorização. Não há integrações internas entre sistemas distintos — é um único sistema.

OUVIDORIA

Ouvidoria

Registro e tratativa de manifestações com controle de SLA, portal público por unidade e relatórios por período.

EDUCAÇÃO

Educação Permanente

Cursos com avaliação e certificado, matriz de obrigatoriedade por cargo com apuração de compliance e treinamento presencial com lista de presença e frequência mínima.

LEITOS

Gestão de Leitos

Mapa de leitos por setor, internações, transferências e altas, com o censo refletindo o estado atual da ocupação.

NÃO-CONF.

Não-Conformidades

Registro, classificação e tratativa de não-conformidades com planos de ação e acompanhamento de status.

DOCUMENTOS

Gestão Documental

Repositório documental com controle de versão, fluxo de aprovação e publicação para as unidades.

PROJETOS

Projetos

Carteira de projetos por unidade com fases, tarefas e prazos; progresso e indicadores apurados no banco de dados, não no cliente.

COMISSÕES

Comissões

Comissões hospitalares com agenda de reuniões, registro de presença, verificação de quórum, pauta e atas.

COMUNICAÇÃO

Ponto Vital

Feed de comunicação institucional com publicações e stories, segmentado por unidade.

PESQUISA

Pesquisa de Satisfação

Aplicação pública de pesquisas de satisfação vinculadas à unidade, com tabulação dentro do sistema.

02 · ARQUITETURA

Fluxo de dados em camadas

O cliente nunca executa operações de dados diretamente no banco. Toda leitura e escrita de negócio passa pela API do servidor, que aplica autorização, escopo de unidade e validação antes de tocar o PostgreSQL.

Interface (SSR) Vue 3 · TypeScript

estado e regras de apresentação

Composables camada de domínio

HTTP · JSON

API do servidor Nitro · autorização · validação

SQL com escopo de unidade

PostgreSQL RLS · triggers · RPCs

a.Multi-tenancy por unidade. Toda consulta é filtrada pela unidade hospitalar ativa; a RLS no banco atua como segunda camada de contenção, não como substituta do filtro.
b.Regras críticas no banco. Notas de avaliação, emissão de certificados e contadores de projeto são calculados por triggers e funções RPC no PostgreSQL — o cliente não tem permissão de escrita sobre essas colunas.
c.Operações administrativas isoladas. Criação e alteração de usuários ocorrem exclusivamente em funções serverless dedicadas, com validação de JWT e do papel do chamador; chaves privilegiadas não circulam na aplicação.
d.Auditoria e retenção. Tabelas de negócio carregam colunas de auditoria e usam exclusão lógica (soft-delete) — registros não são destruídos fisicamente pelo fluxo normal.
e.Dados assistenciais protegidos. Informações de pacientes não aparecem em logs; a superfície de banco exposta ao cliente é mínima e coberta por testes de privilégio.

03 · INTEROPERABILIDADE

API HL7 FHIR R4

O QualyFactor expõe uma camada de interoperabilidade no padrão HL7 FHIR R4 para integração com outros sistemas de saúde. É uma camada adicional sobre a mesma base de dados — sem replicação nem sincronização paralela.

Recursos servidos em application/fhir+json, conforme a especificação R4.
Conversão bidirecional entre o modelo interno e os recursos FHIR (ex.: Patient, Organization) feita no servidor.
Mesmas tabelas, mesma autorização: a camada FHIR não contorna o escopo de unidade nem a RLS.
Interface REST convencional — legível por qualquer cliente FHIR padrão.

exemplo · fhir r4

GET /api/fhir/Patient/{id}
Accept: application/fhir+json

HTTP/1.1 200 OK
Content-Type: application/fhir+json

{
  "resourceType": "Patient",
  "id": "…",
  "identifier": [{ "system": "…", "value": "…" }],
  "name": [{ "text": "…" }],
  "managingOrganization": {
    "reference": "Organization/…"
  }
}

04 · ACESSO

Acesso ao sistema

Ambiente de produção

app.qualyfactor.com

O acesso é provisionado pela administração de cada instituição — não há cadastro público. Credenciais iniciais são entregues pelo gestor da unidade, com troca de senha obrigatória no primeiro acesso.

Entrar →