Prontuário eletrônico médico open source, com API aberta desde a concepção.
Um contraponto aos prontuários de mercado que fecham seu ecossistema e não liberam suas APIs.
É no grupo que a conversa do projeto acontece.
Prontuários eletrônicos comerciais, em geral, fecham seus dados. Sair de um fornecedor ou integrar outro sistema costuma ser difícil, caro ou simplesmente impossível. A clínica gera os dados, mas depende da boa vontade de quem vende o software para acessá-los.
O OpenClinic nasce como contraponto: um prontuário cujo código é aberto e cuja API é, desde o primeiro dia, tratada como um produto tão importante quanto a própria interface. E cuja licença, a AGPL-3.0, impede que alguém pegue o que nasceu aberto e feche.
Missão, princípios e escopo completos em vision.md.
Um prontuário parece um CRUD. Não é.
O HL7 FHIR não é um formato de exportação que se acrescenta no fim. No OpenClinic, ele é a forma como o sistema pensa (decisão 0001). O padrão organiza informação em bundles: conjuntos montados para fazer sentido a quem lê, reunindo dados de várias entidades e repetindo o que o contexto clínico exigir. Um banco relacional quer exatamente o oposto: normalizar, separar, não repetir nada.
Esse descasamento não é um obstáculo que se resolve uma vez e passa. Ele reaparece a cada recurso novo que o sistema implementa: um esquema que responde bem a um recurso pode inviabilizar a consulta que outro exige. É a restrição que governa cada decisão de modelagem deste projeto, e vai continuar governando.
Some-se o que a regulação exige de um prontuário, e que molda o modelo de dados antes da primeira linha de código:
- Nada é apagado de verdade: exclusão marca, não remove.
- Toda informação carrega de onde veio e quem a registrou, de forma permanente.
- O registro precisa sobreviver vinte anos.
- Dados de clínicas diferentes nunca se encostam.
- Quem acessou o quê fica registrado em trilha que ninguém pode editar.
Nenhum desses requisitos é opcional. O mapeamento completo das normas está em compliance.md; os requisitos de produto, em prd.md.
Se isso te parece um problema interessante em vez de um aborrecimento, você é o tipo de pessoa que este projeto procura.
Toda decisão de arquitetura vira um documento com contexto, consequências assumidas e, obrigatoriamente, as alternativas descartadas e o motivo. Ficam em docs/decisions/, que é sempre a fonte atual do que já está fechado e do que segue em aberto.
Três regras valem aqui:
Argumento é assinado. Quem defende uma posição assina. O projeto não atribui opinião a ninguém por conta própria.
Tese vencida não é apagada. Ela permanece no registro, explicando o que já foi pesado. Discordar e perder não apaga sua contribuição do histórico do projeto.
Decisão não se fecha com gente ausente. Encaminhamento verbal no fim de uma reunião, com participantes fora da sala, não vale como decisão tomada.
Isso quer dizer que aqui se defende ideia por escrito e se aceita ser contrariado em público. Dá mais trabalho que abrir um pull request e sumir, e é de propósito.
Detalhes em GOVERNANCE.md.
A conversa do projeto acontece no grupo de WhatsApp. Entre. Se o link estiver expirado, avise por uma Issue.
Quem chega de fora, ou prefere um canal público e permanente, abre uma Issue, que é a porta registrada e pesquisável do projeto, e o time responde por lá.
A contribuição mais valiosa hoje é ajudar a fechar as decisões que ainda estão em aberto. Elas estão marcadas como tal no índice de decisões, e são as mais caras de reverter depois. Traga sua posição ao grupo ou registre-a numa Issue: posição assinada entra no registro da decisão.
Experiência especialmente bem-vinda: HL7 FHIR e interoperabilidade em saúde, modelagem de dados clínicos, segurança da informação em dado sensível e quem já operou um prontuário na prática e sabe onde dói. Não é preciso programar para contribuir: donos e gestores de clínica são parte da comunidade que este projeto quer formar, e o que eles sabem da operação orienta o desenho tanto quanto o código. Guia completo em CONTRIBUTING.md.
| Documento | O que contém |
|---|---|
docs/vision.md |
Missão, problema, princípios e escopo |
docs/prd.md |
O que o sistema precisa fazer, e por quê |
docs/modulos.md |
Proposta de arquitetura de módulos da V1 |
docs/cadastros.md |
Dicionário de dados dos cadastros, insumo para o esquema de banco |
docs/conformidade-sbis.md |
Matriz de rastreabilidade da certificação SBIS v5.2 |
docs/decisions/ |
As decisões de arquitetura, uma por arquivo |
docs/compliance.md |
Normas brasileiras aplicáveis (LGPD, ANVISA, SBIS, RNDS, TISS) |
docs/roadmap.md |
As fases do projeto |
docs/reunioes/ |
O que cada reunião decidiu e deixou em aberto |
GOVERNANCE.md |
Como o projeto é conduzido, e como isso deve evoluir |
CONTRIBUTING.md |
Como participar |
SECURITY.md |
Como reportar uma vulnerabilidade |
Distribuído sob a GNU Affero General Public License v3.0.
Qualquer pessoa pode usar, modificar e hospedar o OpenClinic, inclusive comercialmente, desde que mantenha as modificações abertas sob a mesma licença. Existe também a previsão de uma licença comercial alternativa para quem não puder cumprir essa condição. Detalhes e limites em licensing.md.
Copyright © 2026 Dr. Daniel Dorta Santiago de Carvalho Duarte, CRM 174209, e colaboradores do OpenClinic.
A documentação deste repositório é escrita em português, que é onde está a comunidade do projeto, e brasileira é a regulação que o condiciona. Código, identificadores, mensagens de commit e a especificação da API seguem o padrão internacional e são escritos em inglês.
Iniciativa OpenClinic