The Challenge
A hospital group moved its patient management from paper and separate tools onto one hospital information system. The software came from a third-party vendor, and three facilities, a main hospital and two others, share a single instance and a single data set. The system holds real patient records and drives national health insurance claims, so a wrong calculation changes what a patient pays and what the hospital is reimbursed. The group needed people who understood both the clinical and insurance rules and the way the software actually behaved, and who could tell the vendor’s developers exactly what was wrong.
What Nexora Did
Nexora worked as the QA and business analysis team between the hospital group and the vendor’s developers. The vendor builds and fixes the product. Nexora tests it, explains it and keeps the list of open problems honest.
- Reproduced problems seen in production on a separate test environment, then wrote them up with the exact steps and data used
- Wrote test cases and confirmed that delivered fixes behaved as specified
- Documented the business rules, key terms and data flows of the system in a shared wiki
- Logged and followed change requests raised by hospital staff, each with a module, priority and status
- Kept the working agreements and meeting notes that tell all parties which issue list is current
Modules in Scope
The system covers the whole patient journey, from registration and appointments through outpatient and inpatient care, electronic medical records, electronic orders for drugs and services, labs, imaging, billing, pharmacy, inventory, the operating room, emergency care and sterile supply. Nexora documented each module with its purpose and the places where one module depends on another. Registration creates the patient and the visit, clinical orders feed billing, and billing feeds insurance claims. Most defects turn out to sit at one of those hand-offs, so the documentation follows data across them instead of describing each screen on its own.
Writing the Rules Down
The most useful thing Nexora produced is a domain knowledge document that states how the system should behave, rule by rule. Each rule has an identifier, a type (validation, computation, constraint, process or trigger), the behaviour the system must show and, where one exists, the regulation behind it. A tester no longer has to guess whether an odd result is a defect. Examples of what the rules settle:
- A patient has one permanent record number, and possible duplicates are flagged before a new record is saved
- Clinical records and financial records stay in separate domains: an invoice never lives inside a medical record
- A finalized clinical document cannot be edited in place; changes go through a versioned workflow with an audit trail
- A cost cannot be claimed to the insurer twice, and an item with no valid clinical order is never counted as insured
Insurance Claims
The hardest area is the claim process for national health insurance. A claim starts only from a finalized bill, items are grouped into a batch, the batch is finalized and locked, and an XML file in the insurer’s required format is generated and submitted through the insurer’s portal and an integration engine. Each batch then carries a status the hospital must follow: submitted, unscrubbed, accepted or rejected. Nexora wrote down the rules for every step, including what happens when a bill is refunded after a batch was built, when a submission is retried after a timeout, and when only part of a batch is rejected. The system must not silently rewrite an XML file that was already generated, and it must keep the rejection reason so staff can fix and resend.
How Issues Were Handled
The test environment and the production system are kept strictly apart. Production holds real patients and real bills, so nothing is tested there. Problems are reproduced on the test environment first. Before a bug is raised, the analyst checks it against the written rules, because some behaviour that looks wrong is correct by design. Reports state the patient record, invoice number and date used so a developer can follow the same steps. Issues, bugs and open questions were tracked in a versioned issue log, and change requests were reviewed separately in a regular meeting. Sets of recorded cases and vendor release notes were kept next to the logs so a fix could be traced to a release.
Lessons Written Down
The team kept a short lessons-learned page for anyone joining. Several entries are small but cost real time when missed: the system shows different screens depending on the active organization and department, so a missing feature is often a wrong department; and a confirmed correct behaviour should be recorded in the test case straight away so the next person does not re-argue it.
What the Client Gets
The hospital group has a written reference for how its system should behave, a repeatable way to reproduce and report defects to the vendor, and a maintained list of requested changes with owners and status. Operating figures such as patient volumes, defect counts and claim volumes belong to the hospital group and are not published here.
Tech Stack and Why It Matters
Nexora did not build the core product, so there is no application stack to list. The work sits on the practice side: spreadsheets and a tracker for issues, a company wiki for the domain record, screen recordings for reproduction and an integration engine on the insurance side. In a hospital system the cost of a misunderstood rule is paid by patients and by the hospital’s reimbursements, which is why the rules are written down before the defects are argued.