Management information system for hospital managers
This month's result on a phone, from the client's own MIS and BI stack. Read-only, aggregates only, never patient data.
- Client
- A Czech healthcare software vendor, not named by agreement
- Sector
- Healthcare
- Kind
- Client project
- Status
- In delivery
- Role
- Design, UX/UI, build, long-term maintenance
- Year
- 2026
- 1
Context
The client builds and runs the management information system a hospital's finance office works in: source systems feeding a data warehouse, an ETL chain, and desktop MIS and BI clients on top of it. The numbers a director wants already exist. They exist on a desktop inside the hospital network.
- 2
Problem
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 management view of the organisation's finances, read in seconds on a phone.
- 3
Constraints
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.
Hospital finances are commercially and politically sensitive without a single patient record in them. The vendor works to ISO 9001 and ISO/IEC 27001 and has its own security manager who reviews everything before it ships. How the phone reaches data inside the hospital network was still an open question, so the architecture could not rest on a guess.
- 4
Role
Tolaron designs and builds the mobile app and its backend, and maintains them after release. The system, the warehouse and the brand are the client's.
- 5
Solution
A React Native app for iOS and Android, with a web build from the same source, and a TypeScript backend, in one monorepo split along a line with commercial meaning: the reusable platform never learns the customer's name, and everything true only of this product 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 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.
- 6
Outcome
The chain runs end to end over the client's real finance export: warehouse cube, domain maths, contract, API, device. The accounting traps in the data, a derived currency reading counted twice, a subtotal dressed up as a cost centre, an unclosed month, are documented and filtered out rather than averaged away. Four visual directions were built over real numbers, so the design choice is made by looking.
Not yet in production. It waits on the client's answer for how the phone reaches data inside the hospital network, 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 still planned; that is the part a security manager reads first.
- 7
Technology
React Native and TypeScript on the phone and in the web build. A TypeScript backend against the warehouse over SQL. Shared schemas for every wire shape. Synthetic data for development.
The client is not named and no screens are shown, by agreement between the parties. Everything above is the engineering problem and Tolaron's part in it.
