On 12 September, I helped organise and judge a healthcare AI hackathon at OpenAI in London. We brought builders together to take the NHS 10 Year Health Plan and explore where technology could help put its ambitions into practice.
I also built two connected electronic patient record systems, or EPRs, for participants to work with: one for a GP practice and one for a hospital. Around them, I built a simulated NHS neighbourhood of 50,000 synthetic patients, with primary-care messaging, document and telephony management, community care, wearables, and pharmacy services.
I wanted people to be able to follow a patient through several services and build something that changed what happened next. A discharge letter could arrive in primary care. Someone could request a test, contact the patient, or arrange a home visit. The resulting work would appear in another part of the simulation.
That became NHS-SIM. It also became an experiment in how much I could build with coding agents once I gave them a structured repository and a way to check their own work.
You can explore the live simulator. The source is available in Anima’s NHS-SIM repository.
Figure 1. The neighbourhood is the starting point. Each location opens a different workplace in the same synthetic healthcare system.
The NHS 10 Year Health Plan for England describes three shifts: hospital to community, analogue to digital, and sickness to prevention. The published plan gave us a direction. We needed problems that people could actually build against.
For hospital to community, consider a discharge that creates work for a GP, a pharmacy, and a community team. A useful project could track the handover, identify missing information, and check whether the receiving service completed its task.
For analogue to digital, consider an incoming letter or a telephone request. A project could help match it to the right patient, prepare a task for review, route it to the right person, and retain a record of what happened. Turning a letter into text is one step in that workflow.
For sickness to prevention, a project could explore how to combine a synthetic patient’s longitudinal record with readings from a wearable, then organise a review or follow-up. The simulation gives builders somewhere to test the information flow. It does not establish whether an intervention improves health.
Those are examples of problems the environment makes available, rather than claims about what individual hackathon teams delivered.
The breadth of the simulator came from following those workflows. I built two EPRs, one for primary care and one for hospital care. Around them are a messaging system, document management for primary care, a primary-care telephony system, pharmacy dispensing and purchasing, community visits, and a home interface for wearable devices and readings. Supporting APIs cover services such as diagnostics and referrals, alongside lightweight NHS-shaped adapters and a staff identity emulator.
These are fictional interpretations of the kinds of systems NHS organisations use across a neighbourhood. They represent distinct jobs and handoffs, with synthetic people and records. They do not claim compatibility with commercial EPRs or reproduce the full behaviour of those products.
Figure 2. Primary care brings the record and incoming work together. Here, a fictional patient’s discharge summary sits alongside the follow-up it creates.
Figure 3. The hospital presents the same patient through a different workflow. A shared identity lets builders follow a handover across services.
I started with an empty repository and built the deployable box first. A pnpm monorepo separated the applications from shared packages for contracts, the simulation engine, UI, and adapters. The initial UI setup included TanStack and shadcn. The interfaces then developed their own layouts around the work each service needed to do.
I kept deployment deliberately compact. One application container serves the frontends and APIs through one public port. PostgreSQL runs in a separate backing container. There are several workplaces in the browser, but starting the neighbourhood does not require a separate deployment for each one.
The shared contracts package was an important early decision. It defines entities, validates actions, and holds the registry the build uses to discover systems. A prescription or referral needs a common meaning when several parts of the application handle it. That becomes especially important when different agents are implementing those parts.
Figure 4. Building the application structure first gave each workplace shared contracts and one deployment model. AI-generated process illustration.
From there, I layered in lessons from the Cursor and OpenAI teams. OpenAI’s harness engineering account describes making repository knowledge, application behaviour, and feedback accessible to coding agents. Cursor’s work on long-running agents describes dividing planning and implementation into distinct roles. I applied those ideas to a smaller, specific problem: building this simulator.
I imported pstack, the agent skills from cursor/plugins, into the repository. It supplied reusable working practices for planning, implementation, review, and verification. Codex and Cursor use the same local skill tree, so project instructions have one home. The healthcare-specific requirements sit alongside it in the repository: the architecture, synthetic-data constraints, API contracts, and what counts as a completed workflow.
The pstack principle I kept returning to was “build the lever”. For this project, that meant creating a verification skill before repeatedly asking agents to check features by hand.
The project-specific verify-nhs-sim skill gives an agent commands to inspect the running environment, launch it when needed, exercise workflows, and save evidence. It turns “check that this works” into a concrete task. One journey creates an isolated team world, orders a test through the GP API, advances simulation time, and checks that diagnostics exposes an available result.
That last step matters. An accepted request proves that the system received an order. Reading the result from the receiving service proves more of the workflow. When I checked the simulator for this write-up, that journey completed successfully.
This was my version of loop engineering. Give an agent a bounded task and an observable completion condition. Have it implement the change, run the application, inspect the resulting state, and fix whatever prevents that condition from being met. Keep the evidence in files so a later pass can inspect it. The loop has a reason to stop once the intended behaviour is demonstrated.
Figure 5. The verification skill makes the engineering feedback loop executable: implement, run, inspect, and repair failures until the intended behaviour is demonstrated. AI-generated process illustration.
The checks covered different failure modes. Typechecking caught disagreements between packages. Tests exercised state transitions and access boundaries. The build checked the assembled application. Runtime journeys checked that work could cross services. Browser verification let me inspect what a person would actually see.
Figure 6. Pharmacy work has its own lifecycle. Prescribing, dispensing, collection, and stock movement are distinct events in the simulation.
Once the shared structure and feedback loop existed, I used an orchestrator and subagents to develop the system in parallel workstreams. The orchestrator held the overall task and divided it into bounded pieces. Workers could focus on a particular workflow, while separate review and verification work checked the result.
The boundary of a task mattered more than the number of workers. A hospital attendance lifecycle touches its data model, transitions, API actions, and UI. Keeping that connected work with one owner made it possible to reason about the whole change. A separate reviewer could challenge the design, and the orchestrator could check its interaction with the rest of the neighbourhood.
Figure 7. A schematic of the orchestrator and subagent pattern. Each worker owns connected feature changes, and failures return with evidence. The three workstreams illustrate the pattern rather than a historical worker count. AI-generated process illustration.
That gave me a way to build out the EPRs and the surrounding operational systems without every agent needing the entire project in context. Shared contracts and a common verification route made their outputs easier to integrate. Parallelism still required decisions about ownership and dependencies.
Figure 8. Document handling is part of the simulation’s operational work. An incoming letter needs a patient, an owner, and a processing outcome.
Figure 9. Messagey keeps patient conversations in a dedicated workspace. Delivery state, replies, assignment, and completion are part of the work an integration can inspect.
The population brought a different engineering problem. Fifty thousand patients need histories that can be searched and retrieved without repeatedly copying or scanning the entire population. The repository’s expansion to that scale introduced indexed storage and a shared population baseline, with team changes stored separately.
That arrangement gives teams a common starting population while keeping their interventions isolated. One team’s consultation or task should not alter another team’s experiment. The histories remain generated examples. The population’s size does not make it an epidemiologically validated model of an NHS neighbourhood.
Time is another shared part of the design. The world can pause or advance so participants can inspect delayed work without waiting through a real afternoon. A test request can become a result later. A visit can progress. An injected outage can hold up a handover. That makes sequence and unfinished work available to an agent as things it can investigate.
Figure 10. The home interface adds synthetic wearable history to the neighbourhood. Readings provide information for workflow experiments, not a validated health assessment.
Building this clarified where I spent my own engineering effort. I chose the boundaries, decided which healthcare behaviours mattered, made the system observable, and checked whether the pieces agreed. The verification skill was especially useful because it made those checks repeatable across workstreams.
Now the hackathon is over, I want the simulator to remain useful as a place to test healthcare agents. Can an agent recover from a rejected referral without creating a duplicate? Can it notice that a requested result never arrived? Can it keep track of a handover until the receiving service has acted?
NHS-SIM gives those questions a concrete starting state and an inspectable outcome. Establishing real clinical benefit would require different evidence. My next interest is to make the workflow experiments repeatable enough that we can compare approaches and see exactly where they fail.