CognitiveBayes Diagnostics - Autism and Neurodivergence Diagnostic Tool
Problem to Solve
Despite considerable advances in understanding of the neurobiology of Autism Spectrum Disorder (ASD), its method of
diagnosis has barely changed since it was devised some 50 years ago. It is cumbersome, lengthy (18 months to 3 years
in the UK), and fraught with subjective mistakes.
Who is affected?
• Autism spectrum disorder (ASD) patients.
• ASD patient families.
• ASD patient carers.
Who is the End-user of This Tool?
• Medical Doctors
• General Practitiners (GPs)
• Clinicians
• Psychologists
• Psychiatrists
• Specially trained Pervasive Developmental Disorder (PDD) assessors.
Objective
The objective of this project is to deploy a diagnostic tool that analyses standardised medical data to instantly calculate the probability of a subject
having autism or another neurodivergent trait or disorder. This tool has already been developed beyond proof of concept and up to working prototype stage
with excellent performance on simulated data. The goal is to deploy it as a specialised tool configured for controlled access only
to specialist and consultant medical professionals, following further model development, evaluation on real patient data,
and publication in a peer-reviewed journal.
Medical professionals need this demonstrably accurate, objective, relatively quick (but not shoddy), and cost-effective
diagnostic tool to bring the process of autism and other neurodivergence diagnosis into the 21st century.
The deployed application will reduce and eventually eliminate the long queue of patients waiting for diagnosis, together with the foreboding
and distress that goes with these for patients and their families. It will enable families of confirmed diagnosed patients
to access specialised and customised educational institutions and resources, interventions, support, and therapies
in a timely manner.
It will bring the current antiquated and laborious system of autism, neurodivergence, and PDD diagnosis into the digital and computer age.
How does the tool work?
This Clinical Decision Support System (CDSS) functions via a secure, user-friendly frontend interface where clinicians input formatted medical records, questionnaire parameters, observational data, and most importantly quantitative medical laboratory determined parameters from MRIs, genetic, and genomic tests. They then receive a real-time predicted probability (expressed as a percentage) indicating the likelihood of an autism or related neurodivergent diagnosis. Personally Identifiable Information (PII) is excluded at the input stage - it would be the responsibility of the clinician to link and associate this tool's provided Diagnosis ID Number to the right patient. However, redunduncies would be built into the deployment to deal with any PII that slips through.
Once the clinician submits the data, the payload triggers a containerised application executed by AWS Fargate, which pulls an environment container image from Amazon Elastic Container Registry (ECR) to evaluate the underlying mathematical conditional logic of a learned Bayesian Network model. This containerised serverless design scales automatically based on demand when auto-scaling policies are configured, and eliminates the need to manage persistent server overhead.
To safeguard data privacy and ensure that PII and Protected Health Information (PHI) do not propagate down the data pipeline, incoming structured and unstructured text inputs are proactively scanned and sanitised using Amazon Macie and Amazon Comprehend Medical, which automatically detect and flag medical-grade sensitive identifiers before calculations run.
The entire cloud infrastructure is architected under the AWS Shared Responsibility Model to comply with international healthcare privacy and data governance frameworks. All operational inputs and telemetry are piped directly into an Amazon S3 storage bucket configured with Object Lock. This provides an immutable, WORM-compliant compliance log layer, ensuring that necessary GDPR and the Data Protection Act 2018 records (in the UK) as well as HIPAA audit trails (in the USA) are safely preserved for their legally mandated retention period.
Cloud Architectural Flow Description (Provisional)
Clinician App Frontend
│
▼ ( Secure HTTPS / REST Requests + Auth Token )
Amazon API Gateway
│
├──► ( Validates JWT Token ) ──► Amazon Cognito ◄── ( User Pools and Identity Verification )
│
▼ ( Authorised Payload )
Amazon Comprehend Medical ( PII Detection and Redaction )
│ ( Scans & redacts PII )
│
▼ ( Sanitised Medical Data Payload )
│
AWS Fargate (ECS) ( Serverless Container / Task Execution )
│
├──► ( Pulls container image ) ◄── Amazon ECR
│ ( Container Image: Bayesian Inference Engine )
│
├──► ( Executes Bayesian Inference Loop )
│ ( Conditional probability calculations )
│
├──► ( Writes probability outputs ) ────────► Amazon DynamoDB
│ ( Persistent diagnostic score store )
│
├──► ( Triggers inference notification ) ──────────► Amazon SNS
│ ( Real-time notifications )
│ └──► Clinician Email
│
▼ ( Streams execution traces and audit telemetry )
│
Amazon CloudWatch
│ ( Request latency, inference duration, error tracking )
│
▼ ( Automated Log Export Pipeline )
│
Amazon S3 ◄── ( WORM Compliance via Object Lock )
│ ( Immutable audit trail - GDPR / DPA 2018 / HIPAA )
│
└──► Healthcare Compliance Vault
Architecture Diagram
Provisional Cloud Architecture Diagram
N.B. - This architecture is yet to be finalised - under review.
Software, Cloud, and Data Engineering Trade-offs
Under Review - the following is a log of some of my brainstorm considerations:
1.
Model Software
The prototype model was developed in the .cmpx format, which is the original model file format used by AgenaRisk (the predecessor to agena.ai). This is a
binary proprietary format specific to Agena's software.
Modern agena.ai uses JSON for model representation, which makes models more portable and easier to integrate with other
systems. However, full backward compatibility is maintained - the system can still read and parse legacy .cmpx files
from older AgenaRisk versions and convert them to the newer JSON format.
The APIs available for Java, Python, and R all support both formats, allowing import of .cmpx files and export of models
to either .cmpx or JSON format depending on needs.
2.
Why this separate cloud deployment? Why not just use agena.ai's platform offering?
Consider a scenario where the final, completed Bayesian Network model template is replicated and deployed across multiple
AWS Regions (e.g. UK, Europe, USA, and Canada), utilising multiple Availability Zones within each Region for high
availability. The system must support concurrent access by multiple, geographically distributed users at the same or
overlapping times. These users will query the same model parameters simultaneously, providing distinct input arguments
to execute isolated, stateless inferences.
There is the option to develop a custom frontend interface to the native agena.ai cloud platform, instead of the custom cloud
deployment described in this project. Initially, the case for using the custom cloud option
described in this project seemed enhanced by considerations of Auto Scaling and Load
Balancing. However, it turns out agena.ai's managed hosting service is built on Kubernetes and Kafka. This inherently includes:
- Kubernetes for Auto-Scaling and Ingress Routing: handles Horizontal Pod Autoscaling to automatically adjust the number of running application instances based on computational demand, alongside built-in services and ingress controllers for network load balancing.
- Apache Kafka for Asynchronous Event Streaming: handles heavy data pipelines, event buffering, and model execution streams efficiently, safely decoupling data production from asynchronous model computation.
Stateless Inference Model
Bayesian Network inference is inherently stateless - each inference request is independent and doesn't require the service to maintain session state across requests. This is ideal for horizontal scaling. User A's inference with parameters {e.g. X=5, Y=10, Z=15} doesn't interfere with User B's inference with parameters {e.g. X=2, Y=8, Z=14}.
Eventually, the choice to use the custom cloud deployment described in this project is made on the basis of desired:
1. high availability
2. low latency
3. legal compliance requirements
4. level of detail of logged medical records
5. data sovereignty.
3.
Cloud Environment - Run serialised version or model itself?
3a. Model Itself - Compute Options
To run the actual Bayesian Network model in the cloud, its storage environment must be paired with a compute environment:
| Option | Architecture | Verdict |
|---|---|---|
| 1 | Serverless: S3 + Lambda | S3 is purely object storage - the model cannot execute inside S3. Lambda is event-driven, max 15 min runtime, not suitable for 24/7 inference. |
| 2 | Container: ECR + Lambda | ECR bypasses Lambda's 50 MB deployment package limit via Docker-based Lambda functions. Still inherits Lambda's 15-minute timeout and ephemeral compute. |
| 3 | Continuous Compute: EC2 or Fargate | Spins up a persistent environment. Loads AgenaRisk model at startup, stays warm 24/7. Ideal for long-running inference, stable isolated runtime, complex CPT unpacking. |
Decision: AWS Fargate - serverless container, 24/7 uptime, no infrastructure management, pulls AgenaRisk runtime + model JSON from ECR at startup.
Lambda is event-driven (and can be time-driven via CloudWatch Events / EventBridge), designed for short bursts, not persistent runtime. The model must stay active and available 24/7, therefore Lambda is not the right fit.
3b. Model Serialisation Options
| Format | Status | Pros | Cons |
|---|---|---|---|
| AgenaRisk JSON | Current standard (agena.ai) | Native format, transparent, interoperable, cloud-native, human-readable | None for this use case |
| .cmpx | Legacy - still supported | Backward compatible with older agena.ai / AgenaRisk software | Binary proprietary - not interoperable, not ideal for cloud deployments |
| PMML | Not natively supported by agena.ai | Open standard | AgenaRisk does not export PMML natively - custom mapping required |
| ONNX | Incompatible | Cloud-native | No Bayesian Network support - designed for neural networks only |
| joblib | Incompatible | Python only - incompatible runtime |
Decision: AgenaRisk JSON - exported directly from agena.ai, bundled into Docker image alongside AgenaRisk API runtime, loaded once at Fargate container startup.
3c. Serialised Version vs Model Itself
| Serialised model | Containerised model | |
|---|---|---|
| What are we looking at | Model state saved to AgenaRisk JSON / .cmpx, loaded at runtime |
Entire AgenaRisk runtime + model + application code bundled in Docker image |
| Execution | Must match deserialisation environment | Runs natively - no translation layer |
| Model complexity | Limited by format's expressiveness | Unlimited - full AgenaRisk CPT structure runs as-is |
| Dependencies | Must be reconstructed at load time | All bundled in image |
| Versioning | Model file + code versioned separately | Single image version = model + code + runtime |
| Clinical auditability | Harder - model state in binary/XML | Easier - full source behaviour preserved |
| AgenaRisk fit | Partial - JSON is readable but runtime still needed | Complete - AgenaRisk API + JSON model + inference engine all in one image |
4. Server or Serverless Compute?
| Server: EC2 | Serverless Container: Fargate | Serverless Function: Lambda | |
|---|---|---|---|
| Type | Virtual machine | Serverless container (ECS) | Serverless function |
| Runtime | Indefinite - 24/7 | Indefinite - 24/7 | Max 15 minutes |
| Infrastructure management | Developer manages OS, patching, scaling | AWS managed | None |
| Cold start | None (always on) | ~ 30 sec (first start only) | 2 to 10 sec per invocation |
| Always-on cost | ~ £60-100 per month | ~£120-180 per month | Very high at 24/7 continuous load |
| Auto-scaling | Manual / custom | Configurable - ECS Service Auto Scaling | Automatic |
| AgenaRisk runtime | Runs natively | Runs natively in container | Timeout too short for complex inference |
| Complex CPT unpacking | Stable isolated environment | Stable isolated environment | Ephemeral - rebuilt per invocation |
| Suitable for 24/7 Bayesian inference |
Decision consolidation: AWS Fargate - serverless container gives 24/7 availability without EC2 infrastructure management overhead. AgenaRisk API runtime + model JSON bundled in ECR image, initialised once at container startup, warm for all subsequent inference requests.
Cost Optimisations
Under review - coming soon.
One of many options is to utilise AWS's private pricing agreements under its Enterprise Discount Programs (EDP) to
obtain maximum value-for-money.
Technical Details
Coming soon.
🏆 Proof of Concept and Early Prototype
Project: A causal Bayesian Network model for early diagnosis of autism
Please get in touch to schedule a demonstration.
N.B. - This model requires agena.ai / AgenaRisk Software as prerequisite to run.
🏆 Remaining Major Milestones
1. Use further agena.ai / AgenaRisk utilities and capabilities to obtain an even more robust model.
2. Further refinement of model capabilities: for example MRI scan types currently modelled as node
states would be drilled down into full nodes - Longitudinal MRI, ROI-based volumetry, tensor-based morphometry,
surface-based morphometry, and voxel-based morphometry would each be modelled as a full node.
3. Real patient data, instead of the synthetic data used so far, will be used and the obtained model performance
metrics such as accuracy, precision, F1-score, sensitivity, and specificity duly documented.
4. An object-oriented Multiobject Bayesian Network Model (MBNM) version would be built and compared to the
improved mainstream version in terms of performance.
5. Detailed publication in a peer-reviewed scientific journal.
6. Submit model to the Medicines and Healthcare products Regulatory Agency (MHRA) and the National Institute
for Health and Care Excellence (NICE) for approval for clinical use in the UK, while approval in the USA would be
sought from the Food and Drug Administration (FDA) and the Centers for Medicare & Medicaid Services (CMS).