Part 2 of 2. Part 1 is here.
In my first article, I described the patchwork (“duct tape”) that keeps many public hospitals going: paper records, siloed electronic systems, shared documents, local lists, WhatsApp messages and a great deal of human memory and improvisation.
What should hospitals do about this?
A March 2026 paper from Chris Hani Baragwanath Academic Hospital, or Bara, describes an attempt to answer that question in a real clinical service. It’s not a formal impact evaluation and doesn’t claim to offer a blueprint for every hospital. It shows how one team tried to improve access and use of clinical information in a setting where paper records, legacy systems and local workarounds must coexist.
At Bara, most clinical departments still rely on paper-based health records. At the same time, separate legacy systems handle laboratory data, radiology, and admissions and discharges. Clinicians also use tools such as Google Forms and Docs, WardWorx and Trello, usually on their personal devices. The lack of integration of these systems leads to fragmentation and risks to patient confidentiality.
Lesson 1: start where the pain is real and buy-in is strong
The team chose to start in paediatric surgery and to proceed in phases. The department was small enough for close collaboration, big enough to show impact, already had some experience with electronic records and had staff buy-in because duplicate data entry had become such a burden.
The stated aim was to give healthcare professionals “modern access to clinical data”. High level goals apart from adoption and use of the new electronic system were improved data quality, support for research and a scalable proof of concept for the hospital and other Wits clinical platforms.
Lesson 2: fit the system to the work
Many digital projects begin with big ambition and only later discover the realities of workflow. This one started with a clinical service feeling the pain of fragmented work, which both informed the redesign and improved the chances of adoption.
The system was co-designed with clinicians to fit existing workflows and to be intuitive, efficient and, in the authors’ words, “preferable (even enjoyable) to use”. During the transition it was introduced as a primary source of patient information alongside paper records rather than as an instant full replacement.
The aim was to capture accurate, reliable and comprehensive data that would save clinician time, support better decisions and enable secure, anonymised access for research.
The Bara team had judged that installing a big commercial hospital IT system was an unrealistic approach because of cost, infrastructure needs, connectivity problems, staffing demands and lack of flexibility. Their alternative was more practical: keep the existing laboratory, admissions and radiology systems, and build a new layer that could gradually connect them.
The technical design was pragmatic[1]. At the centre was a shared data store built around FHIR, an international standard for structuring health information so it can be organised consistently and exchanged more easily in future. Clinicians use a mobile app on ordinary smartphones, linked to a central server in a way that is fast and data efficient. In plain terms, the team built a phone-based front end for clinical work, linked to a back end that could combine information from existing systems with new clinician-entered data.
Direct links between systems are planned, but because that takes time and resources, an interim workaround was used to move information across.
Lesson 3: sequence matters
In resource-constrained settings, choosing good technical architecture is important. Correct sequencing is also vital. The project was designed to be useful even without full integration, which in a public hospital setting may be the only way projects like this get off the ground.
Lesson 4: address specific pain points
The paper shows what “useful” means. Phase 1 included user registration and biometric authentication, patient file creation and search, admissions and discharges, task management, procedure and operation notes, discharge summaries, theatre scheduling, morbidity and mortality notes, handover and patient lists, laboratory and radiology requests, and import of laboratory results using robotic process automation (RPA). RPA is software that mimics the steps a person would take to fetch information from an older system.
In other words, the Bara team focused on day to day functionalities that keep a clinical service running. Just as important, the paper shows what the new system was meant to replace – elements such as WardWorx, HealthSpace, Google Calendar, typed theatre lists, Google doc call sheets, weekly handover documents, and the NHLS (National Health Laboratory Service) system.
Lesson 5: software is only part of the story
The paper also highlights the enabling conditions: extensive stakeholder involvement, support from management and frontline staff, a trust-based relationship between the doctors and the developer, rapid response to technical problems, built-in user feedback, and that clinicians could use smartphones they already had and knew how to use. No additional devices or extra staff were required for data entry.
Legal and ethical issues were addressed from the start via formal legal advice and ethics inputs, consent and assent procedures and security measures, including automatic anonymisation of records exported for research.
Sustainability was treated as a governance and funding issue. A university management committee oversaw long-term direction and financial oversight, while phased funding came from Surgeons for Little Lives, a private philanthropist, and later the Wits Faculty of Health Sciences.
Reasons for caution
The paper reports informal observations rather than definitive outcome data. The authors say healthcare professionals appear to spend less time on data entry and retrieval and have better access to clinical data, but they also say each department will only formally evaluate impact after an appropriate post-implementation period.
The model is partly transitional. Paper records are still present alongside the new system. Full integration is incomplete. Robotic process automation is an interim measure, not an end state.
Bara also has favourable conditions that may not be easily reproduced, including philanthropic support, strong leadership backing, a trusted developer, and a department with unusual readiness and motivation.
Even so, there’s a great deal here for other hospitals to learn from.
- Don’t ban the duct tape before you understand the work it is doing.
- Don’t begin with the dream of a total hospital-wide replacement. Start with one service, one troublesome workflow, and one team that wants relief.
- A system that removes pain from everyday work is worth more than one that promises “transformation” later.
- Don’t assume your technical architecture will save the day. Pay equal attention to adoption, trust, governance, training and feedback.
- Don’t think of workaround culture as a sign of failure. It may be the best source of design intelligence.
- Digital projects succeed through attention to governance, relationships and workflow.
We need mores stories like this one that share experience of how to improve a real clinical service in a real hospital, under real constraints.
[1] The underlying tools included Flutter for the mobile app, gRPC for data transfer, and Microsoft ASP.NET as the middleware layer between the app and the server. API-based system integration is planned.