← All articles

Rebuilding healthcare's front door from first principles

Why Treat is rebuilding healthcare's front door from first principles: simple for patients, rigorous underneath, built to scale.

Author: Jarno Keskikangas, Software Architect · Published 5 September 2026 · 4 min read

Behind a simple path to care sits a great deal of complexity. Healthcare is regulated, the data is sensitive and systems have to talk to each other according to national standards. At Treat we decided to rebuild healthcare's front door from first principles: simple for patients, rigorous underneath, built to scale. Here I explain what that means in practice and what I have learned along the way.

Where we started

The first principle was not a technology but a question: what does a patient actually need when they have a health concern? The answer is surprisingly simple. They want to describe their situation once, get a professional's assessment quickly and know what the right next step is.

In today's systems, a large share of the time is spent before the patient even reaches the right professional: phone queues, forms, repeating the same story. That time is not care. It is a cost of the structure, shifted onto the patient.

Simple for patients

In Treat you describe your concern in a chat, in your own words. The AI asks structured follow-up questions that the doctor would otherwise have to ask one at a time, and compiles them into a summary. A licensed doctor assesses the case during service hours (every day 08:00–20:00), usually within minutes: the average wait for a doctor has been 2 min 14 s, measured during service hours. In 62 % of cases no further appointment was needed.

Simple does not mean lightweight. You identify yourself with strong authentication, such as Finnish bank credentials or a mobile certificate, because a health service requires it. But you do it once, and after that the path is straight.

Treat is not an emergency service. In an emergency, call 112.

Rigorous underneath

There are no shortcuts under the surface.

  • Every clinical decision is made by a licensed doctor. The AI does not diagnose, treat or assess urgency. It prepares.
  • Responsibilities are spelled out. The professional making the assessment is the controller of the patient record, and Treat processes the data on their behalf. This is not legal pedantry; it determines who decides what.
  • Kanta is part of the workflow, not an add-on. The doctor's entries and prescriptions are delivered to Kanta, Finland's national health record service, and to the national Prescription Centre, and Kanta records are fetched only with your explicit consent, whose scope, wording and timestamp are recorded.
  • The Treat application runs on Google Cloud in Finland. Region europe-north1, EU Data Boundary. Personal data stays within the EEA; AI processing takes place in the EU and Idura processes identification data in the EU. Encryption with customer-managed keys, permissions per service account, and logs with the personal identity code and clinical free text redacted.

Built to scale

To me, scaling means the structure should not have to change when there are many times more patients and doctors. That is a design objective that guides every choice: each service has its own identity and its own bounded permissions, so adding a new part does not open up the old ones. Doctors have previously handled more than 108,000 chat visits on the Treat platform.

Scalability applies to employers too, but in the opposite direction: an employer never sees an individual employee's health information, only aggregated, anonymised reporting with small groups suppressed. That boundary is in the structure, not in a contract appendix.

Lessons from certified patient-record systems

Before Treat, I led architecture for Finland's certified patient-record systems and their Kanta integrations. A few general lessons that guide Treat's structure:

  • Regulation is a design input, not a final review. If responsibilities, retention periods and the grounds for disclosure are thought through only at the end, they become patches.
  • Traceability is a feature. Who did what and when, and what the patient consented to, must be demonstrable afterwards. Consent that cannot be verified is not consent.
  • Structured data is the price of interoperability. National standards feel heavy, but they are the reason a prescription works at any pharmacy.
  • Complexity does not disappear; it moves. If the patient's path is simple, someone has to carry the complexity. Its place is in the architecture, not in the patient's daily life.
  • Real patient data does not belong in a development environment. Treat's product development uses anonymised data only.
  • Boring core, fast surface. The core that holds patient data uses established, well-understood technology. Experiments happen at the edges.

What this means for you

You describe your situation once. The doctor sees it structured and decides. The prescription is at the pharmacy and the entry is in Omakanta, your own view of your national health record. Treat complements occupational healthcare rather than replacing it, and if you need an in-person appointment or tests, the doctor directs you to where you are entitled to them.

Our goal is for getting the right care in minutes to be a normal expectation, not an exception. That is only possible if nothing is compromised underneath.

About the author

Jarno Keskikangas

Jarno Keskikangas

Software Architect

Software Architect at Treat and part of the founding team. Previously led architecture for Finland's certified patient-record systems and Kanta integrations.

Not sure what to do next?

Tell us in your own words. A licensed doctor usually reviews your situation within minutes during service hours.

Start with Treat