Clinical guidelines
NCCN and ESMO recommendations, which set the framework for action by tumour type and stage.
Technology
How we ensure every conclusion is verifiable
A clinical decision support system is only useful if the person using it can check what it is based on. This page explains which sources feed Sphera, how they are kept up to date, why every statement links back to its origin, and which principles govern the handling of patient data.
Which sources does the system draw on?
Recognised clinical and regulatory sources, never unreferenced generated content. The knowledge base combines professional guidelines, indexed literature, trial registries and official pharmacological documentation, and every piece keeps its provenance.
Indexed literature
Scientific publications identified by their PMID, so every reference can be located and checked.
Clinical trial registries
Registered trials, relevant when a biomarker opens the door to an investigational option.
Official pharmacological sources
Summaries of product characteristics from CIMA, EMA and FDA, plus BIFIMED for reimbursement conditions in the Spanish national health system.
Interpretation standards
The AMP/ASCO/CAP framework for classifying the actionability of somatic variants by evidence tier.
How is the knowledge base kept up to date?
Updating is part of maintaining the system, not a task that falls on the hospital. When a guideline publishes a new version, or a summary of product characteristics changes an indication or a contraindication, the knowledge base is reviewed and the current reference is incorporated.
Every statement in the report is dated and linked to the version of the source used at that moment. If a recommendation changes months later, it is therefore possible to know exactly which evidence supported the original assessment — essential for reviews and audits.
Why do we reject black boxes?
Because in a clinical setting a conclusion that cannot be verified cannot be adopted. Whoever signs off a treatment decision needs to be able to walk through the reasoning behind it: which variant was detected, what evidence makes it actionable, with what degree of certainty and under which pharmacological conditions. Traceability is a clinical requirement and, looking at the regulatory framework for health software, a design requirement too: an auditable system is an assessable system.
That is why in Sphera every statement in the report links to its original source — PMIDs, clinical trials, guidelines and summaries of product characteristics — and the board can audit the reasoning step by step, including the points where evidence is weak, disputed or contradictory. Showing uncertainty as well is part of not being a black box.
How do we handle patient data?
With design principles defined from the architecture up, not as a layer added afterwards. These principles guide development and are specified with each centre according to its security and data protection policies.
Data minimisation
The system works with the data strictly necessary to assess the case. Identifying information that does not contribute to the decision is neither requested nor processed.
Pseudonymisation
Cases are processed with pseudonymised identifiers, so the link to the patient's identity remains under the control of the centre.
GDPR compliance
The design incorporates the principles of the General Data Protection Regulation: lawfulness, purpose limitation, minimisation and technical measures proportionate to the risk. Processing details are documented with each collaborating centre.
Adaptable deployment, including on-premise
The modular architecture allows processing to be hosted on the infrastructure the centre chooses, including deployment on the hospital's own servers (on-premise) where its policies require it.
What we describe here are design principles and deployment options. Specific security and data protection commitments are formalised with each centre during the technical evaluation.
How does it integrate with hospital systems?
By working with the centre's IT department, not around it. Because we develop the platform ourselves, we adapt output formats to the document the board already uses, define the exchange route with the hospital information system (HIS) or the electronic health record viewer according to the hospital's requirements, and adjust the integration logic to its workflows. Interoperability is approached as joint work: the centre knows its systems and we know the platform.
Sphera OncoCore is a platform under development, intended for research and clinical evaluation purposes. It does not hold CE marking as a medical device and is not intended for use as a diagnostic or prescribing tool. Every clinical decision remains the responsibility of the treating healthcare professional.