OrthoSphere — GPT-5.6 Evidence Brief

• 

  Citation-grounded evidence output — The brief exposes evidence limitations, missing clinical context, and eight traceable citation entries.

• 

  Primary GPT-5.6 brief — Evidence organized into agreement, uncertainty, and citations.

• 

  Pre-generation safety refusal — A request for diagnosis and operation selection is blocked by governance controls before GPT-5.6 is called.

• 

  Uncertainty made explicit — The system separates areas of agreement, unresolved timing questions, and limitations in the available evidence.

• 

  Conversion-timing overview — GPT-5.6 summarizes evidence without inventing one interval.

Inspiration

Orthopaedic clinicians work across fragmented clinical notes, imaging summaries, guidelines, research papers, registries, and multidisciplinary workflows. Important evidence is often available, but it is difficult to organize, assess, and communicate consistently under time pressure.

As an orthopaedic surgeon and solo clinician-developer, I created OrthoSphere to explore how software and AI can support this work without replacing clinical judgment.

What it does

For OpenAI Build Week, I added the GPT-5.6 Evidence Brief to OrthoSphere.

A clinician enters a general, de-identified orthopaedic evidence question. OrthoSphere retrieves a bounded evidence set and asks GPT-5.6 to produce a strict, structured brief containing:

• the interpreted question;
• an evidence overview;
• areas of agreement;
• uncertainty or disagreement;
• evidence limitations;
• missing clinical context;
• citation-linked claims.

The result is designed to make evidence easier to inspect, not to make a treatment decision.

The interface also includes a clear safety boundary. A request such as “Diagnose this patient and tell me exactly which operation to perform” is rejected before evidence retrieval or GPT-5.6 invocation.

What existed before Build Week

OrthoSphere already existed as an assistive orthopaedic intelligence platform with:

• OrthoPath, a deterministic clinical decision-support rules engine;
• OrthoRAG, a citation-oriented evidence retrieval layer;
• authenticated web and API services;
• PostgreSQL and pgvector infrastructure;
• governed safety and audit boundaries.

The Build Week work did not replace those components. It added a new, isolated GPT-5.6 evidence-synthesis path.

What I built during Build Week

Using Codex, I designed, implemented, tested, and documented:

• a strict GPT-5.6 evidence-brief schema;
• an isolated OpenAI Responses API adapter;
• bounded evidence retrieval for the brief;
• an internal evidence-service route;
• an authenticated API proxy;
• the /orthorag/buildweek web experience;
• server-side and build-time feature flags;
• citation validation and forbidden-field checks;
• pre-generation clinical-directive refusal;
• post-generation evidence-only safety controls;
• deterministic regression tests and preset-matrix tests;
• a judge runbook and reproducible local setup.

The Build Week feature is disabled by default and does not alter OrthoPath recommendation logic.

How it works

1. The authenticated API validates tenant, role, subscription, and rate-limit requirements.
2. The evidence service retrieves a bounded set of relevant evidence chunks.
3. GPT-5.6 receives only the question, selected evidence, and a strict developer instruction.
4. The Responses API is called with a strict JSON schema, no tools, and provider-side storage disabled.
5. The server validates structure, citation references, assistive-only status, and safety boundaries.
6. The web interface renders agreement, uncertainty, limitations, missing context, citations, and the GPT-5.6 model label.

The OpenAI API key remains server-side and is never exposed to the browser.

Safety and trust

OrthoSphere preserves a strict authority boundary:

• OrthoRAG and the GPT-5.6 Evidence Brief explain evidence only.
• They cannot emit recommendation or action objects.
• They cannot diagnose, prescribe, order, triage, or select an operation.
• Patient-specific clinical directives are refused before model invocation.
• Generated output must pass schema, citation, and safety validation.
• The interface explicitly reminds users that clinical judgment remains with the clinician.

Only the deterministic OrthoPath rules engine is permitted to emit governed clinical recommendation objects elsewhere in the platform.

Challenges

The hardest challenge was balancing useful evidence language with strict safety controls. Words such as “recommendation” may appear legitimately when describing a guideline, but similar wording can also become direct clinical advice.

I solved this with layered controls:

• narrow pre-generation detection for obvious patient-specific directives;
• field-aware post-generation validation;
• citation-backed evidence attribution;
• fail-closed handling for direct recommendations and imperatives;
• deterministic regression tests for primary, uncertainty, and refusal presets.

Another challenge was preserving architectural isolation. The new GPT-5.6 path had to use existing authentication and retrieval infrastructure without changing the deterministic clinical decision-support authority boundary.

Accomplishments

• Built a functioning GPT-5.6 evidence-synthesis workflow inside an existing multi-service clinical platform.
• Produced structured briefs that explicitly surface uncertainty and missing context.
• Preserved citation provenance through server-side validation.
• Rejected unsafe diagnosis and operation-selection prompts before model use.
• Added feature flags, rate limits, strict schemas, and deterministic tests.
• Completed the work as a solo clinician-developer using Codex as an engineering partner.

What I learned

Codex was most valuable when used as a disciplined repository agent rather than a generic code generator. I used it to inspect the real architecture, propose bounded implementation batches, implement only authorized files, run regression tests, and produce evidence-rich reports before each merge.

GPT-5.6 was most useful when constrained by retrieved evidence, a strict schema, and explicit uncertainty requirements. The quality of the result depended as much on architecture and validation as on the model itself.

What's next

Next steps include:

• a controlled hosted judge demo;
• protocol-only retrieval enforcement for the Build Week path;
• expanded citation and grounding evaluation;
• clinician usability studies;
• additional orthopaedic evidence domains;
• formal validation of uncertainty communication and safety behavior.

OrthoSphere remains an assistive prototype and is not intended for autonomous diagnosis, prescribing, ordering, triage, or treatment selection.

Built With

• caddy
• citation-grounded
• clinical-ai
• codex
• docker
• evidence-synthesis
• fastapi
• gpt-5.6
• healthcare
• next.js
• openai
• orthopaedics
• pgvector
• postgresql
• python
• react
• responses-api
• retrieval-augmented-generation
• safety
• typescript
• uncertainty-aware