CLINICASE

Inspiration

CLINICASE started from a simple problem we noticed while looking at One Health data.

Environmental teams, laboratories, public health organisations, and hospitals may all collect information about the same real world situation, but they often store that information differently.

One system may use one name for a measurement while another system uses a different name. Units may also be different. Even when the data can technically be transferred, the receiving system may misunderstand what the original data actually meant.

For example, a laboratory may simply report arsenic as 0.014.

That sounds clear at first, but arsenic could mean total arsenic, dissolved arsenic, or inorganic arsenic. These do not always mean the same thing.

A computer can easily convert the value into another format, but it should not guess which type of arsenic was actually measured.

That became the main idea behind CLINICASE.

We wanted to build a system where artificial intelligence can help people, but important decisions still remain with humans.

The principle behind the project is simple.

Artificial intelligence suggests.

Humans approve.

Standards validate.

The meaning of the information should remain the same when it moves between systems.

What it does

CLINICASE is a One Health interoperability platform that connects environmental observations, laboratory information, health context, human review, and follow up in one place.

A citizen or volunteer can first report something they observe in their environment.

For example, they may notice unusual water colour, algae, foam, waste, or a strange smell.

They can also provide measurements and photographs if they have them.

We intentionally allow users to say that they are not sure or simply skip information.

We do not want the system to force someone to enter information they do not actually know.

The evidence can then be explored geographically.

We created an interactive globe that includes OneAquaHealth research locations such as Coimbra, Toulouse, and Figueira da Foz.

The platform can also display weather information from Open Meteo to provide additional environmental context.

The main part of CLINICASE is the interoperability process.

Information first enters from System A.

CLINICASE examines the data and identifies what is clearly known and what is still uncertain.

Rules are applied first.

Artificial intelligence can assist by suggesting possible mappings, but the system does not allow artificial intelligence to silently decide important medical or environmental meanings.

If the source simply says arsenic, the platform does not automatically decide that it means dissolved arsenic, total arsenic, or inorganic arsenic.

A human reviewer sees the uncertainty and makes the final decision.

The reviewer can approve the mapping, change it, or reject it.

After approval, CLINICASE converts the information into the HL7 FHIR R4 standard.

The data is then validated.

If something important is incorrect, such as a unit, the transfer is stopped until the problem is corrected.

The validated information is then transferred to another independent system called System B.

System B creates new resource identifiers.

This allows us to test whether two systems can still understand the same information even when their internal identifiers are different.

CLINICASE reads the information back from System B and compares the important meaning of every field.

In our recorded test, all thirteen semantic fields were preserved.

The system also creates an Evidence Passport.

The Evidence Passport records where the information came from, what decisions were made by the reviewer, whether validation succeeded, how the information was transferred, and integrity information related to the exchange.

CLINICASE also includes review and safety tools, clinical context, follow up, retesting, analytics, geographic evidence, and governed artificial intelligence support.

Architecture

The architecture of CLINICASE is designed around one complete flow of information.

Citizen and Environmental Data

goes to

CLINICASE Frontend

goes to

FastAPI Backend

goes to

Case and Evidence Management

goes to

Interoperability Engine

goes to

Rules and Artificial Intelligence Suggestions

goes to

Human Reviewer

goes to

FHIR Standardisation

goes to

FHIR Validation

goes to

System B

goes to

Semantic Comparison

goes to

Evidence Passport

goes to

Clinical Context and Follow Up

The frontend is where citizens, reviewers, coordinators, and other users interact with the platform.

The backend manages the cases, observations, evidence, interoperability process, review decisions, and communication between different parts of the system.

The interoperability engine is responsible for understanding incoming data and preparing it for FHIR.

The artificial intelligence layer is designed as an assistant rather than a decision maker.

The human review layer sits between suggestions and final standardisation.

Only after review does the information move into FHIR validation.

System B represents another independent system receiving the information.

The semantic comparison layer then checks whether the important meaning survived the transfer.

Finally, the Evidence Passport keeps a traceable history of the complete journey.

How we built it

We built the frontend using React, TypeScript, Vite, and Tailwind CSS.

CesiumJS and MapLibre are used for geographic visualisation.

The backend was developed using Python and FastAPI.

PostgreSQL and Supabase are used for storing application data.

For healthcare interoperability, we used HL7 FHIR R4 together with selected OneAquaHealth Implementation Guide constraints.

We also used SNOMED CT and CDS Hooks for health related terminology and clinical context.

Open Meteo is used to bring weather information into the environmental context.

For artificial intelligence support, CLINICASE uses an NVIDIA hosted model through an OpenAI compatible interface.

LangGraph supports parts of the artificial intelligence workflow.

Docker is used for containerisation.

We also prepared Kubernetes deployment files and GitHub Actions workflows.

Render is used for the online deployment.

Testing was also an important part of the project.

The project includes more than eight hundred backend tests and more than one hundred and fifty frontend tests.

We also created application level checks for different context scenarios.

Challenges we ran into

One of the biggest challenges was deciding where artificial intelligence should be allowed to help and where it should stop.

It would have been easy to let the model automatically decide how every field should be mapped.

However, that would create exactly the type of problem we wanted to solve.

If the original information is unclear, the system should preserve that uncertainty rather than hide it.

We therefore designed the artificial intelligence layer so that it can provide suggestions but cannot silently make sensitive decisions.

Another difficult problem was deciding how to prove that information kept the same meaning after moving to another system.

Simply checking whether the same identifiers existed in both systems would not be a strong test.

We therefore made System B deliberately generate different identifiers.

After the transfer, CLINICASE compares the important fields instead.

This helped us test interoperability based on meaning rather than internal database identifiers.

Another challenge was bringing together environmental observations, health standards, geographic information, artificial intelligence, human review, clinical context, and follow up without making the system confusing.

We solved this by organising the user experience into a clear journey from evidence collection to follow up.

Accomplishments that we are proud of

The part we are most proud of is that CLINICASE does not treat interoperability as simple data conversion.

We built the project around preserving meaning.

The system can clearly show when information is ambiguous instead of pretending that everything is certain.

Artificial intelligence can assist without controlling the final decision.

Human reviewers remain responsible for sensitive mappings.

Validation can stop incorrect information before it is transferred.

System B allows us to demonstrate an actual exchange between separate systems.

We intentionally change resource identifiers during that transfer.

After the data returns, we compare its meaning.

In our recorded network test, all thirteen semantic fields were preserved.

We are also proud of building the Evidence Passport so that important decisions and transformations can be inspected later.

The project combines environmental evidence, FHIR interoperability, geographic context, human review, artificial intelligence governance, clinical context, follow up, and testing inside one platform.

What we learned

The biggest thing we learned is that interoperability is not only about making two systems communicate.

Two systems can exchange valid data and still misunderstand each other.

The structure of a file may be correct while the meaning is wrong.

FHIR gives us a strong standard for exchanging healthcare information, but safe interoperability also requires good terminology, correct units, provenance, human review, and careful handling of uncertainty.

We also learned something important about artificial intelligence.

Making artificial intelligence more powerful is not always the safest solution.

Sometimes the better design is to clearly define what the model is not allowed to decide.

For CLINICASE, artificial intelligence is useful because it can reduce repetitive work and help reviewers understand information faster.

But a human remains responsible when the meaning of the source data is uncertain.

We also learned that interoperability should be tested using the actual meaning of information, not only identifiers and file structures.

What is next for CLINICASE

The next step is to connect CLINICASE with more real world One Health data sources.

We want to integrate exports from the OneAquaHealth Citizen Science App and connect the platform with real laboratory data feeds.

We also want to expand our validation against the OneAquaHealth Implementation Guide and strengthen terminology checking.

Future versions will include stronger consent workflows, authentication, access control, and organisation level permissions.

We also want to test the platform across more independent systems and support additional environmental measurements.

A major future goal is to work with a water authority, public health organisation, research institution, or laboratory and evaluate the platform using real operational workflows.

CLINICASE is designed to work between existing systems rather than forcing organisations to replace the tools they already use.

Our long term goal is to make environmental and health data exchange easier to understand, easier to audit, and much safer when information moves from one organisation to another.