Especificaciones

OpenOnco es un proyecto de especificaciones-primero. Cada detalle arquitectónico, clínico y de gobernanza está enmarcado en un documento de marcado abajo specs/ that is versioned and open to public review. 10 active specifications cover everything from intended-use design constraints to the shape of every YAML entity in the KB. The full text lives at gythub.com/romeo111/OpenOnco/specs.

Hierarquía de la fuente de la verdad (de CLAUDE.md): cuando las especificaciones en conflicto, el orden vinculante es 1. CARTA.md → 2. otros specs/*.md → 3. CLAUDE.md → 4. README.MD. Cualquier cosa bajo legacy/ No es autoritario.

Especificaciones activas (10)

Gobernanza CHARTER.md

Carta y gobernanza

Project governance, scope (what it does and what it explicitly does not), intended-use design constraints (§15 with constraints C1-C7), the solo-maintainer workflow for source-traceable content (§6.1), patient-data privacy (§9.3), forbidden prompt patterns for LLMs (§8.3 — LLMs do not make clinical decisions).

Leer en GitHub → Marcación en bruto

Clínico CLINICAL_CONTENT_STANDARDS.md

Normativa de contenido clínico

Normas de contenido clínico: formato de cita (source_id + posición + parafrase + página), taxonomía a nivel de evidencia (Tier 1-6), flujo de trabajo de firma de revisión, STUB → revisado los criterios de transición. Cada reclamación en una Indicación / Regimen / RedFlag enlaces a una entidad Fuente.

Leer en GitHub → Marcación en bruto

Datos DATA_STANDARDS.md

Normas de datos — Modelo de paciente

Patient profile data model. FHIR R4/R5 + mCODE alignment on the roadmap. Code systems: LOINC + ICD-10/O-3 + RxNorm + CTCAE v5.0. No SNOMED CT and no MedDRA in the MVP (license gates). Profile fields and semantic interoperability.

Leer en GitHub → Marcación en bruto

Esquema KNOWLEDGE_SCHEMA_SPECIFICATION.md

Especificación del esquema de conocimiento

Pydantic schemas for every KB entity — Disease / Indication / Regimen / Algorithm / Biomarker / Drug / Test / Workup / RedFlag / Contraindication / MonitoringSchedule / SupportiveCare / Source. Defines fields, validators, referential-integrity rules, and the migration roadmap to PostgreSQL.

Leer en GitHub → Marcación en bruto

Fuentes SOURCE_INGESTION_SPEC.md

Ingestión y licencias de origen

Cómo ingerimos fuentes: la matriz de alojamiento (referenciado vs hosted vs mixto) con justificación H1-H5, las puertas de clasificación de licencia, la lista de verificación de acceso a un código (§8), la Lista de verificación hospeded-source (§20) y el protocolo SourceClient para APIs en vivo.

Leer en GitHub → Marcación en bruto

Pruebas REFERENCE_CASE_SPECIFICATION.md

Caso de referencia: "Paciente cero"

Un caso sintético de referencia VHC-MZL como prueba de aceptación de P0. Define cada campo requerido para perfil de paciente (selección §2), las aseveraciones estructurales críticas para la salida de render del Plan (§1.3) y los hitos M1-M6 para ampliar la cobertura.

Leer en GitHub → Marcación en bruto

Motor MDT_ORCHESTRATOR_SPEC.md

Orquesta MDT + Procedente de la Decisión

Orchestrate_mdt rules (R1-R9 for treatment, D1-D6 for diagnostic), role activation logic (required / recommended / optional), the Open Questions mechanism (Q1-Q6 + DQ1-DQ4 — the engine refuses to decide without the required data), and a decision-provenance graph for audit-grade explanation.

Leer en GitHub → Marcación en bruto

Motor DIAGNOSTIC_MDT_SPEC.md

TDM de fase diagnóstica (pre-biopsia)

Modo pre-biopsia: cuando la histología no está disponible el motor emite un DiagnosticPlan con un breve de trabajo en lugar de un plan de tratamiento. CARTA §15.2 C7 regla dura. DiagnosticaWorkup + DiagnostPlan esquemas, generate_diagnostic_brief(), orchestrate_mdt polimorfo con reglas DQ1-DQ4.

Leer en GitHub → Marcación en bruto

Clínico WORKUP_METHODOLOGY_SPEC.md

Metodología de la investigación de trabajo

Cómo construimos un trabajo básico para cualquier área de oncología. Jerarquía de fuentes (Nivelo 1: NCCN/ESMO/EHA/BSH/WHO/ASH), Listas de verificación de integridad de pruebas/trabajo, el proceso de 7 pasos para ampliar la cobertura a un nuevo dominio, anti-patrón.

Leer en GitHub → Marcación en bruto

Motor SKILL_ARCHITECTURE_SPEC.md

Arquitectura orientada a las habilidades (funciones de la MDT como habilidades)

Formaliza roles de MDT (hematólogo/patólogo/radiólogo/etc.) como habilidades verificadas clínicamente — cada habilidad lleva versión, fuentes, last_reviewed, clinical_lead. Orizont de dimensionamiento (~12-15 MVP → 50-60 completo), diseño de 8 dominios, plan de refactor de 5 fases.

Leer en GitHub → Marcación en bruto

Fuente de la reglamentación (PDF)

PDF reglamentario Guidance-Clinical-Decision-Software_5.pdf

Guía del software de apoyo a la decisión clínica de la FDA

The official FDA guidance on non-device CDS classification under §520(o)(1)(E). Hosted under specs/ as a PDF. CHARTER §15 cites concrete criteria 1-4 from this document to justify OpenOnco's non-device positioning.

Ver el PDF en GitHub →

Cómo actualizamos las especificaciones

Proyecto individual. Una persona responsable publica las actualizaciones con comprobaciones automáticas y trazabilidad de las fuentes. La revisión clínica externa es opcional y se registra por separado.

Todas las especificaciones están escritas en ucraniano-primero (la interfaz y los revisores clínicos son UA), pero términos técnicos y nombres de licencia permanecen en inglés en línea. v0.1 (draft) en el encabezado y se golpea en menor / mayor dependiendo de los cambios de ruptura.

Cumplimiento + privacidad (visualización rápida)

Garantía	Especificación	Lo que significa
FDA non-device CDS	`CHARTER.md §15`	La Carta describe objetivos de diseño; no establece una clasificación regulatoria ni una validación clínica.
No hay datos sobre el paciente	`CHARTER.md §9.3`	`patient_plans/` y cualquier paciente HTML es gitignored. Todos los ejemplos son sintéticos.
Solo maintainer delivery	`CHARTER.md §6.1`	The maintainer verifies sources and tests; external clinical review is optional.
No hay juicio clínico LLM	`CHARTER.md §8.3`	Los LLM no seleccionan regímenes, no generan dosis y no interpretan biomarcadores para la selección de terapia.
No hay tratamiento sin histología	`CHARTER.md §15.2 C7`	El motor se niega a generar un plan de tratamiento sin `disease.id` or `icd_o_3_morphology` — sólo un Plan de Diagnóstico.
Antiautomatización-bias	`CHARTER.md §15.2 C6`	≥2 pistas alternativas siempre se muestran lado a lado; la alternativa nunca se oculta.
Hosting de origen por defecto = referenciado	`SOURCE_INGESTION_SPEC.md §1.4`	No duplicamos bases de datos externas; el alojamiento requiere una justificación explícita H1-H5.
Free public resource → non-commercial	`CHARTER.md §2`	De esto dependen muchas licencias (ESMO CC-BY-NC-ND, OncoKB académico, ATC). Un nivel pagado desencadenaría una auditoría de licencias.
El lenguaje basado en IP selecciona automáticamente	`client-side, opt-out`	Para mostrar la interfaz en su idioma, su navegador busca su país desde su IP a través de un servicio de terceros (GeoJS, con El sistema de control de la calidad de la energía nuclear (SVP) es el que permite la medición de la capacidad de los sistemas de control y de control del calor. as fallback). Only your IP is sent, with no referrer. These direct geo requests do not use the OpenOnco API; the providers determine their own logging and retention policies. The detected country and your manual language choice are stored only in your browser (localStorage) and the manual switch always overrides the IP guess. Ukrainian is shown only for Ukrainian IP addresses; English everywhere else. By using the site you consent to this country lookup — to avoid it, pick a language manually and your choice is remembered.