Fast and Correct: Building FHIR Software with graphpg and Coding Agents

Speed and correctness often trade against each other. In healthcare software the trade is worse, because a fast mistake can expose a patient record or double-book a clinician.

I got both on a FHIR R5 platform: a data model with more than 170 tables, row-level security, appointment booking, a patient portal and a clinician workspace. I did not write an API layer, and the system refuses to break its own rules. Two things made that possible. graphpg is an open-source engine I built that turns a PostgreSQL schema into GraphQL and REST. The second is an agentic software factory: coding agents that work inside rules the database and the generated contract enforce.

I won't give you a delivery date, because scope and integrations set that. This article is about what the method changes: how much you stop writing, and how much you stop worrying about.

Why healthcare builds run slow

A clinical product carries a lot of plumbing. Each table gets endpoints. Each endpoint gets pagination, filters, and an authorization check. A nested screen requires a resolver that does not fire one query per row. None of that is clinical work, yet all of it has to be right.

Ask any agency you are comparing how much of their estimate is plumbing like this. The answer tells you where your budget goes.

Velocity: the API layer disappears

graphpg reads the PostgreSQL catalog at startup and serves a GraphQL API and a REST API from it. Filtering, ordering, pagination and nested writes come with the schema. Each request compiles into one SQL statement, so a nested chart query is one round trip.

Add a column in a migration, and the API, the schema export and the typed client change with it. You write no endpoint and update no resolver.

The engine is also quick to start. On this schema, 173 tables at the time, graphpg built the full GraphQL schema in 85 ms and PostGraphile took 880 ms. I measured both on PostgreSQL 18.6 on 2 October 2026, before graphpg 1.0, so rerun it on your own schema before you trust the ratio.

Time moves from plumbing to the part clients notice: the clinical workflow and the screens.

Correctness: the database refuses to be wrong

I put access control and scheduling integrity in PostgreSQL, not in application code.

Patients can read their own record. The public can read a sanitized doctor directory. A clinician opens a patient's chart only with a care relationship or a full-chart approval, and the API answers with a typed PATIENT_CHART_ACCESS error otherwise. Row-level security enforces these rules on every query, whoever wrote the query, human or agent.

Booking works the same way. The database refuses to book one practitioner twice at the same time:

ALTER TABLE appointments ADD CONSTRAINT appointments_practitioner_no_overlap
  EXCLUDE USING gist (practitioner_id WITH =, period WITH &&)
  WHERE (status NOT IN ('cancelled', 'entered-in-error', 'noshow'));

When two patients race for one slot, the loser gets a typed SLOT_UNAVAILABLE error, not a double booking. These controls support a HIPAA program. They do not replace one.

Agents: fast because the checks are fast

An agentic software factory is not a chatbot that suggests snippets. Agents take a task, change the code, run the checks and fix what fails. The factory part is the set of rules and checks around them.

Agents go wrong when nothing checks them. They invent a field, skip an authorization filter, or change one place and miss four others. The method removes those failure modes:

The project carries a written rule file for agents. They model FHIR tier by tier, write every schema change as a migration, and never hand-edit the generated GraphQL schema or the generated TypeScript types.
GraphQL Code Generator turns the graphpg schema into typed operations. A field that does not exist is a compile error, not a runtime surprise.
Row-level security holds even when an agent forgets a filter.
More than 40 database test scripts run on PGlite, PostgreSQL compiled to WebAssembly. Applying every migration takes about 2 seconds and the suites about 3 more, so an agent gets an answer in seconds.
Playwright browser tests run against a throwaway stack that uses the published graphpg image.

I review the migrations and the policies. The agents do the repetitive work of screens, forms and tests, and the checks catch what they get wrong.

I wrote more about the two key guardrails on mihai.ltd: end-to-end type safety for AI coding agents and row-level security for AI-built apps. The design of the engine is in Why GraphQL and REST Should Share One Engine. The graphpg documentation covers agents that build applications and configuration.

What this is, and what it is not

It is a FHIR R5 data model with GraphQL and REST APIs generated from it. Each resource keeps its full FHIR payload as JSONB, and the columns the product queries sit next to it.

It is not a certified or conformant FHIR server, and HL7 does not endorse it. The database checks structure with JSON Schema, which is not full FHIR profile validation. If your product has to exchange data with hospital systems, that needs a conformant endpoint, and we scope it as its own piece of work.

Work with Innovi Pro

Speed without correctness is a liability in healthcare, and correctness without speed is a budget problem. The method gives you both, and it keeps agent work checkable.

Here is how an engagement starts:

A paid architecture and scoping engagement of one to two weeks at a fixed fee, ending in a written recommendation, a risk list and a costed roadmap.
Delivery in two-week cycles, with working software at the end of each. The five phases are in how Innovi Pro delivers custom healthcare software.
An architecture audit first, if you already have a FHIR stack and want a second opinion.

If you are planning a clinical product, book a discovery call. Bring your workflow and your deadline, and we will tell you what the method can and cannot do for them.