DEV Community: Anonloopdev.eth

Spark Triage: Building an AI Assistant for Emergency Care

Anonloopdev.eth — Fri, 16 Oct 2026 07:26:37 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

Spark Triage: Building an Open-Weight AI Assistant for Emergency Care

In an emergency department, every minute matters. Healthcare professionals often have to assess several patients under pressure, organize clinical information, and determine who needs attention first.

I built Spark Triage to explore how AI agents and deterministic clinical rules can support this process while keeping healthcare professionals in control.

My goal is to build something that can eventually be adapted to healthcare environments in Nigeria, including facilities where internet connectivity and resources may be limited.

What I Built

Spark Triage is an AI-powered emergency triage desk assistant that helps organize patient information and generate proposed urgency levels for clinical review.

The system explores how AI can help process presenting complaints, identify supporting evidence, and organize triage workflows. It combines an AI agent with deterministic rules based on the adult South African Triage Scale (SATS) ruleset.

Rather than allowing a language model to make the final decision on its own, the system separates AI assistance from rule-based scoring. A nurse or clinician can review, confirm, or override a proposed result.

I see potential applications in hospitals, emergency departments, and healthcare organizations looking to improve the organization of their triage workflows. However, Spark Triage is still a prototype and requires further clinical validation before it can be used for real patient care.

Try the Demo

Live demo: Open Spark Triage

Please use synthetic patient information only. The prototype is intended for demonstration and evaluation, not for making real clinical decisions.

Source Code

GitHub repository: github.com/onloopdev/spark-triage

The repository contains the project implementation and documentation for its triage workflow, AI-agent integration, and deployment approach.

How I Built It

I built Spark Triage using Python, an AI-agent workflow, open-weight language models, Ollama, and the Model Context Protocol (MCP).

The architecture separates the main responsibilities:

AI agent: Helps process presenting complaints and identify supporting evidence.
Deterministic triage rules: Calculate proposed urgency using coded rules instead of relying solely on the language model.
MCP integration: Provides a structured way for the agent to interact with application tools and operations.
Human oversight: Keeps the clinician involved in reviewing and confirming or overriding proposed results.
Audit and evaluation: Supports the inspection of workflow actions and assessment of agent behaviour.

The development configuration defaults to Qwen2.5:3B, while the Docker configuration specifies Gemma 4:31B through an Ollama-hosted endpoint.

Online Demo, Open-Weight Models, and Hospital Deployment

The current public demo uses an online Ollama inference endpoint. For hospital deployment, my intended approach is to run a compatible open-weight model on infrastructure controlled by the hospital, following the deployment options documented in the GitHub repository.

This distinction is important. I want hospitals to have the option of controlling where AI inference takes place and how patient information is stored, rather than depending entirely on an external AI service.

A hospital-controlled deployment could reduce dependence on external inference services and support greater control over sensitive data. However, local deployment, offline operation, secure storage, and recovery during power or network interruptions must be implemented and properly tested before those capabilities can be promised.

My longer-term goal is to adapt Spark Triage to the realities of Nigerian healthcare facilities, where affordability, privacy, infrastructure, and reliable access to care all matter.

Why Open Innovation Matters

For me, open innovation means having the freedom to adapt technology to the needs of the people it is intended to serve.

Open-weight models allow developers to experiment with different models, explore local inference, and reduce dependence on proprietary AI APIs. In healthcare, these choices matter because privacy, infrastructure costs, data control, and accountability are just as important as model performance.

I am particularly interested in the potential for this approach in Nigeria, where some healthcare facilities face unreliable internet connectivity and limited resources. A properly configured local deployment could give hospitals more control over their AI infrastructure and reduce reliance on external services.

Open-source development also creates opportunities for developers and qualified healthcare professionals to inspect the implementation, identify weaknesses, and contribute improvements.

I want Spark Triage to grow through collaboration and careful evaluation, with clinicians remaining responsible for clinical decisions.

What Comes Next?

My next priorities are to improve the agent workflow, strengthen testing and evaluation, document deployment requirements, and explore how the system could be adapted to local healthcare needs.

Before real-world clinical use, the system will need appropriate clinical review, validation, privacy safeguards, and testing in the environments where it is intended to operate.

I see Spark Triage as a starting point: an opportunity to explore how open-weight AI and transparent rules can support healthcare workflows without removing human judgment from the process.

Explore the Project

Live demo: Spark Triage
Source code: GitHub — onloopdev/spark-triage

Thanks for checking out Spark Triage. Feedback, technical suggestions, and contributions are welcome.

Arrays in solidity for complete beginners

Anonloopdev.eth — Tue, 08 Mar 2022 08:45:28 +0000

When you want a collection of something,you can use an array. There are two types of arrays in solidity.

Fixed arrays.
Dynamic arrays.

// Array with a fixed length of 2 elements.
Uint[2] fixed array;
//Another fixed array, can contain 5 strings:
String [5] string array;
// A dynamic array- has no fixed size , can keep growing and increasing.
Uint[ ] dynamic array;
Person [ ] people; // dynamic array,we keep adding.
Note:

Remember that state variables are stored permanently in the Blockchain?
So creating a dynamic array of structs like this can be useful for storing structured data in your contract, kind of a database.

PUBLIC ARRAYS
You can declare an array as public, and solidity will automatically create a getter method for it. The syntax looks like:
Person [ ] public people.
So other contracts could be able to read from, but not write to, this array. So this is a useful pattern for storing public data in your contract.

How Zero Knowledge Proofs Can Change Ethereum Blockchain Applications.

Anonloopdev.eth — Sun, 06 Mar 2022 07:55:08 +0000

Zero proof knowledge is a protocol that enables one party, called the prover, to convince another, the verifier, that a statement is true without revealing any information beyond the veracity of the statement.
In other words, one can say that ZKP is the ability to prove honest computations without revealing inputs.

The honest computation can be used for scalability and privacy.

ZKPs must satisfy three properties.

Completeness: If the statement is true, an honest Verifier will be convinced by an honest prover.
Soundness: If the statement is false, no cheating prover can convince the honest verifier.
Zero knowledge: If the statement is true, no verifier learns anything other than the fact that the statement is true.

Brief History of ZKPs
1985 paper "The knowledge Complexity of interactive prove systems" Shafi Goldwasseer, Silvio Micali and Charles Rackoff.
First coined the term Zero-Knowledge Proofs for their interactive protocol.

Zk-SNARKs highlights the evolution of the most popular ZKP.
-2011 - first paper to coin the term ZK-SNARKs(Succinct Non-interactive Arguments of Knowledge ) (Bit+11) (by Nir Bitansky and Ran Canneti)
-2013- was the first time ZK-Snarks are made applicable for general computing.
The "Pinocchio" Paper (PHGR13) (by Bryan Pamo and Craig Gentry)....
-2016- made Zk-Snarks really efficient and standard that it is still used today. Groth16(by Jen's Groth)

Non-interactive ZKPs
--NIZK are a particular type of zero knowledge proofs in which the prover can generate proof without interaction with the verifier.
--NIZK protocols are very suitable for Ethereum Blockchain application, because they allow a smart contract to act as a verifier. This way, anyone can generate a proof and set it as a part of transaction to the smart contract, which can perform some action depending on whether the proof is valid or not.

The most preferable Non interactive Zero knowledge proof is ZK-SNARKs proofs

*Key differences between SNARKS and STARKS *

For SNARKs

based on elliptic curves and is not quantum resistant and is vulnerable to quantum attacks.
requires a trusted setup and if the secrets used to create these keys in the trusted set up event are not destroyed, the secrets could be utilized to forge transactions by false verifications. 3.has the most developer libraries, published code, projects, and developers actively working on the technology. 4.Gas fee is far cheaper for the end-user and proof size is more smaller.

For STARKS

the base technology for STARKs relies on hash functions and it makes it quantum resistant.
no trusted set-up is required to begin utilizing STARKs in a network.
proof size is more large and verification takes time and it requires more gas.
lacks developer documentation and community

How is the trusted setup process different between Groth16 and PLONK? **
**Groth16 requires a one time trusted setting because it is actually a proving system with circuit-specific common reference string. That means the proof system can only support a fixed circuit in the setup phase for the prover. That means, when the proof system is used in other applications, we must re-run the setup phase with different parameters. We have two phases , and phase 1 is the powers of tau and the phase 2 which is dependent on the circuit.
Why

PLONK utilizes a trusted setup with an updatable reference string. So with PLONK we have an original reference string that can be used to build proofs with any type of circuit. I'm other words, the reference string is UNIVERSAL, and we do not have to recreate a trusted setup for every circuit created. Secondly, there is a way for multiple parties to participate in the trusted setup such that it is secure as long as any one of them is honest. So the more participants, the more secure a secret is.