Context
A hospital blocks beds for many reasons, and until now every ward kept that record for itself. There was no central place for it. Anyone who wanted to know which beds were currently unavailable had to ask. An evaluation across all wards was not possible that way, and free capacity went unnoticed.
Approach
A SAPUI5 app in which bed blocks are recorded and released again. The same app evaluates the blocks: which beds, for how long, on which ward. It sits in the Fiori launchpad next to the applications the wards use anyway.
How it is built
The frontend is SAPUI5, and that was a deliberate choice: UI5 brings the building blocks along, tables, filters, forms, date pickers. That made it possible to show everything important right away instead of building it anew. The backend delivers OData services from ABAP with CDS views.
The app builds on the two bed-type applications from 2022: a shared SAPUI5 library carries central functions such as Excel import and export, and a locking concept for frontend and backend prevents two people from changing the same record at the same time. Catalogs, groups, roles and tiles in the launchpad are part of the delivery, as is the transport from E through P.
| Component | Technology | Decision |
|---|---|---|
| Frontend | SAPUI5 | Tables, filters, forms and date pickers come ready made with the framework |
| Backend | ABAP, CDS views, OData | The evaluation happens in the data model, not in the interface |
| Library | Shared SAPUI5 library | Excel import and export and the locking concept exist once for both applications |
| Launchpad | Catalogs, groups, roles, tiles | The app starts where the wards already work |
Learnings
- UI5 delivers the components an app like this needs. The work sat in the data model and in the evaluation, not in the interface.
- The benefit comes from the evaluation across all wards, not from the recording.
- A shared library pays off from the second app onwards.
- The locking concept was necessary, because several wards touch the same data.