Healthcare MIS mobile app

01Context

The client builds and runs the management information system a hospital's finance office lives in: source systems feeding a data warehouse, an ETL chain, and desktop MIS and BI clients on top of it. The numbers the director wants already exist. They exist on a desktop inside the hospital network.

So the distance between wanting this month's result and having it is a working day and a request to the finance office. Closing that distance is the whole product. The system, the warehouse and the brand are the client's, so this case study stays with the engineering problem and my part in it.

02Challenge

The BI engine has no HTTP API. It reads the warehouse directly, so this was never an integration. It needed a backend of its own, sitting next to the database and speaking SQL, and a phone that under no circumstances reaches that database.

The environment sets the rest. Hospital finances are commercially and politically sensitive without a single patient record in them: a vendor working to ISO 9001 and ISO/IEC 27001, its own security manager who goes through the thing before anything ships, a certified ISMS the app may fall inside the scope of, and still no answer on how the phone reaches data in the hospital network. Whatever that answer turns out to be, the architecture must not rest on a guess.

And the data fights back. The first real export triples the totals if you add it up exactly the way its accompanying note suggests: a derived currency reading counted twice, a subtotal row dressed up as a cost centre, and an unclosed December that turns missing costs into a 26-million profit. Catching precisely this class of error is what the dashboard is for, so making it would have been fatal.

03What I built

A React Native app (iOS, Android and a web build from the same source) and a TypeScript backend, in one monorepo split along a line that has commercial meaning: the reusable platform never learns the customer's name, and everything true only of this product (warehouse mappings, KPI definitions, the design system) sits on the other side. A test holds that line.

Every shape that goes over the wire is a schema both sides derive their types from, and every read goes through a single data-source interface, so the transport decision could stay open while the product was built. The dashboard states what its numbers are measured against: when the source data was last refreshed, separately from when the response was assembled, and whether the month on screen is closed or still moving.

No customer data ever entered the repository, not anonymised, not as a demo. Development runs on synthetic data, and the expected shape of the warehouse is written down as a proposed schema for the client to correct in place, which turned a request that had gone unanswered twice into a question that answers itself.

04Result

The chain runs end to end over the client's real finance export (warehouse cube, domain maths, contract, API, device), with the accounting traps documented and filtered out rather than quietly averaged away. Four complete visual directions were built over real numbers, so the design choice is made by looking rather than guessing.

It is not in production, and the case study says so: it waits on the client's answer for how the phone reaches data inside the hospital, and on the authenticated flow that follows from it. What exists draws a clear line between the security controls that are done and the ones that are still only planned, and that is the part a hospital's security manager reads first.