Clarity from Chaos: Josh Bunting on Solving Australia’s Fragmented Health Data Problem
Q1. zHealth has delivered projects across NT Health, NSW Health, Mater, SWARH, and Austin Health, very different healthcare organisations with very different legacy systems, governance structures, and clinical priorities. When you go into a new engagement, what is the most common misconception a healthcare organisation has about its own data before you start?
The most common misconception is that the problem is the data. Almost every organisation we walk into believes its data is poor, incomplete or untrustworthy, and that the fix is a bigger warehouse or a new BI tool. What we usually find is that the data in the source clinical systems is better than anyone thinks. Patient administration, orders, results and medications are captured in structured form every day because the hospital cannot run without them. What is broken is access to that data and the shared meaning of it.
The pattern repeats across jurisdictions. Data is copied out of the clinical system into a warehouse, mapped over months or years, and by the time a dashboard appears the figures are three to six months old and no longer match what the clinician sees on the ward. Every request for a new view becomes a ticket in a backlog that never clears. People conclude the data is bad, when in fact the data is fine and the copy is stale. The person who is blocked is usually the person making the decision, and that is an access problem, not a skills or attitude problem. Access problems are fixable.
The second gap is semantic. Two hospitals in the same network will both report “patients waiting” and mean different things: different clock start rules, different treatment of deferred patients, different handling of transfers. Nobody has written these local rules down because everyone inside the site already knows them. Until those definitions are agreed and encoded once, in a governed layer that everyone queries, every new report re-litigates the same argument.
The third gap shows up the moment a hospital changes hands or changes platform. Nobody can produce a complete list of the interfaces that keep the place running. The HL7 feeds between the patient administration system, pathology, radiology, pharmacy, theatre and billing were built one at a time over fifteen years, by people who have since left, and the only accurate specification is the message traffic itself. We now start every migration by listening to the interface engine before we read any document, because the messages tell the truth and the documents tell a story.
So the first weeks of an engagement are less about technology and more about surfacing the undocumented business rules and interfaces, agreeing definitions with the people who own the numbers, and proving that a near real-time view over the source system reconciles to the counts the clinicians already trust. Once that trust exists, the technology choices become straightforward.
Q2. zHealth is currently delivering integration, data migration and delivery management on the program that transitions Gold Coast Private Hospital from Healthscope’s systems onto Mater’s platforms, with dozens of clinical applications and their interfaces to be moved under a transitional services agreement with a fixed end date. What has been the hardest technical or organisational obstacle, and what has it taught you about sequencing a multi-system integration so that clinicians are not disrupted?
Some contexts first. Gold Coast Private Hospital became Mater Private Hospital Gold Coast on the first of August 2026. On that day the ownership changed but the technology did not: the hospital kept running on Healthscope’s patient administration, clinical, pharmacy, imaging, theatre and billing systems under transitional services agreements, with a target of the first of February 2027 to exit those agreements and stand entirely on Mater’s platforms. Roughly fifty-four applications sit inside that scope. Our people hold the integration architecture, the analytics and data migration lead, business analysis and delivery management roles inside Mater’s program, with the integration built on InterSystems IRIS for Health and HealthShare Health Connect, which Mater already runs.
The hardest obstacle is that the patient never goes home. This is not a greenfield build where you cut over on a quiet weekend. It is a full private hospital with theatres, an emergency department, maternity and cardiology running at capacity every day while the systems beneath it are swapped, and every one of those departments is joined to the others by interfaces nobody fully inventoried when the hospital was sold. ADT, orders, results, scheduling, charges, clinical documents, medication orders and administrations, DICOM to imaging, FHIR to newer applications, and a long tail of file-based batch feeds. The technical work of rebuilding those interfaces on IRIS is well understood. The organisational obstacle is that two health organisations with different governance, different environments and a limited pool of people who understand the legacy side all have to move in step against a contractual clock, and the clock does not care that the test environment was late.
What it has taught us about sequencing comes down to four rules. First, inventory from the wire, not the wiki. Before anyone designs anything, capture what actually flows between systems, message type by message type, sender by sender, because that list is the real scope and it is always longer than the documented one. Second, sequence by clinical pathway rather than by system. Moving pathology in isolation is easy and proves nothing; moving admit, order, result and discharge for a single ward proves the hospital can run. We take one pathway end to end, then treat it as a pattern to be repeated, in three-week increments, rather than fifty-four parallel projects. Third, run old and new side by side and reconcile the traffic before anyone is asked to trust the new path. If the message counts and the charge totals do not match, the cutover waits. Fourth, treat data migration and integration as one stream. The historical record a clinician needs on day one and the live interface that keeps it current on day two are the same problem viewed at different times, and separating them into two teams is how you end up with a patient whose past and present disagree.
Clinicians are not disrupted when the change arrives inside the workflow they already use and when the people testing it are the people who use it. A test engineer can prove an ORU message validates; only a theatre nurse can tell you the result landed on the right chart at the right moment. We put clinical users into testing from the first increment, and we hold a change until they, not we, are satisfied.
Q3. Your work with NT Health reduced upgrade timelines through automation of release management and testing. What does responsible release automation look like in a healthcare environment specifically, and what safeguards do you build in that a purely commercial software company might not think to include?
Some context first. In the Northern Territory I led solution delivery for the Core Clinical Systems Renewal Program, with TrakCare based electronic health record, across every public hospital and remote clinic in the Territory. When you consolidate onto one platform you also consolidate your release risk: a single upgrade now touches emergency departments, wards, pharmacies and remote community clinics thousands of kilometres apart at the same time. Release management stopped being an engineering hygiene topic and became a patient safety topic.
The automation itself is not exotic: continuous integration builds, automated regression suites written against the clinical specification rather than the screen, defects raised automatically into Jira when a test fails, and more recently AI assisted generation of release notes that translate the vendor’s global release into what actually changes for a local clinician. That last piece alone halved the time it took to produce release documentation. Together these shortened upgrade cycles substantially and, more importantly, made them predictable. We have since packaged the approach as a specification-driven test automation toolkit for TrakCare so that a health service does not have to rebuild it from scratch.
The safeguards are where healthcare differs. Automation accelerates the evidence, never the decision. Every release still passes through a documented, human, clinically represented change approval, and the automation exists to put better evidence in front of that group faster. Regression suites are written from clinical workflows, not from technical functions: admit a patient, chart a medication, discharge to a remote clinic, and confirm the discharge summary arrives. A green build that has not exercised the discharge pathway is not a green build.
Second, the release calendar is clinical, not commercial. Nothing goes in during hospital code yellow windows or on the days a remote clinic has limited support staff on site. Third, rollback is rehearsed, not written. Fourth, interfaces are treated as first class citizens of the release: a TrakCare upgrade can pass every internal test and still break the HL7 feed to pathology or the discharge summary to My Health Record, so downstream systems are in the regression scope. We applied the same discipline when our clients moved its secure clinical messaging from Telstra Argus to HealthLink, a change that looks like a vendor swap on paper and is in practice a cutover of every referral and discharge summary leaving the public system, so it was rehearsed and verified end to end with the receiving practices before the switch. Finally, the change is communicated in the workflow. Release notes nobody reads are not a safeguard; in-application guidance that appears when the changed screen opens is.
A commercial software company optimises release automation for velocity. In healthcare we optimise it for the ability to say, with evidence, exactly what changed, who approved it, and how to undo it, and then to go faster because of that confidence rather than in spite of it.
Q4. The SWARH project delivered a self-service data layer that enabled advanced analytics on elective wait-list data across multiple hospitals. How did you approach building a system that clinicians and administrators could trust enough to act on, and what did you learn about the difference between technically accurate data and data people are willing to use to make hard decisions?
The South West Alliance of Rural Health is a group of Victorian regional health services sharing a TrakCare platform, with Barwon Health as the lead. The brief was a semantic layer over live TrakCare data, delivered as governed views on InterSystems IRIS for Health running against a read-only mirror of production, with elective waitlist as the first data domain and Colac as the first site, designed to extend to the other member services. It brought together waitlist data from two health services so managers could see, in one place and near real time, who was waiting, for what, for how long and where. We followed it with a data strategy for the alliance so the approach could be extended deliberately rather than site by site.
Trust came from four decisions. The first was to reconcile before we visualised. Before anyone saw a chart, the waitlist counts from the semantic layer were reconciled line by line to the lists the booking clerks and surgeons already worked from. If the new number did not match the old number, we did not explain the difference away; we found it, and usually it was an undocumented local rule that needed to be encoded.
The second was to agree definitions with the people who would be held accountable for them. What starts the clock, how a patient who defers is treated, how a category change is recorded. Those are policy decisions and they belong to the health service, not the data team. We wrote them down, encoded them once, and made the logic visible so that anyone challenged on a figure could show the working.
The third was timeliness. A waitlist figure that is three months old is politically useful and clinically useless. Reading from a live mirror rather than a periodic extract meant the list a manager acted on in the morning was the list the clinic saw that afternoon.
The fourth was to keep exploration and statutory reporting as separate processes. People need to ask questions freely without fear that an exploratory query becomes a number in a ministerial briefing. The regulatory submission still goes through the pipeline it always did.
The lesson is that technically accurate data is a necessary condition and nowhere near a sufficient one. People act on numbers when they know where the number came from, when they agreed the definition behind it, when it is current enough to still be true, and when they can defend it to someone who does not want to hear it. That is the difference between an answer and an answer you can defend.
Q5. zHealth works extensively with InterSystems technology. Can you describe how that relationship functions in practice, where the boundary sits between the platform and zHealth’s own engineering, and what has made that partnership effective for large-scale, safety-critical health integration in Australia?
The simplest description is one we used on stage together at InterSystems READY 2026 in Bangkok: InterSystems builds the product, we deliver. zHealth is an InterSystems implementation partner across Australia, New Zealand and South East Asia. The platform side of the boundary is TrakCare and IntelliCare as the electronic health record, IRIS for Health and HealthShare Health Connect as the data and interoperability engine, and HealthShare components such as the enterprise master patient index and provider directory. Those are products with roadmaps, support and regulatory conformance that no consultancy should try to replicate.
Our side of the boundary is everything that turns the platform into a working solution for a specific hospital. That includes the interface library we maintain for HL7, FHIR, secure messaging and My Health Record connections, which is what our architects are drawing on inside Mater’s Gold Coast program today; the semantic layers and analytics built on IRIS, such as the SWARH waitlist work; release and test automation around TrakCare upgrades; and newer work like an AI assisted draft discharge summary that is generated inside the hospital firewall and pushed straight into TrakCare for the clinician to review and sign. Much of our team spent years running these products inside health departments before zHealth existed, so we bring the operator’s view of the platform, not just the implementer’s.
What makes it effective is that the platform is already in the hospital. In Australian public health the safest integration is the one that does not add a new vendor to the architecture. Building the interoperability, analytics and automation on the engine the health service already licenses, secures and supports removes a whole category of risk before we write a line of code. It also means that when something goes wrong at two in the morning, the escalation path is one the hospital already has.
The relationship also runs in both directions. We are close enough to the product teams to feed back what we see in live regulated environments, most recently around InterSystems Data Studio and how conversational analytics should sit on top of governed data. In Bangkok we demonstrated its assistant answering a pharmacy director’s question about the cost pattern of a high-cost treatment directly from dispensing data, with no pre-built report, and the questions from the room were about governance before they were about the model, which is exactly the right order. A partnership works in safety-critical settings when the partner is honest about sequencing and risk, including telling a customer when the right answer is to wait for the next platform release rather than build a workaround. That honesty is what InterSystems and the health services both rely on us for.
Q6. You co-founded zHealth to solve a problem that has existed in healthcare IT for decades. What convinced you this was the problem worth building a company around, and what is the biggest thing you have learned about healthcare organisations, the people and institutions, that you did not fully appreciate before?
I have been staring at the same problem from three different clients. In 2004 I was a patient administration system administrator at the Mater Hospital in Brisbane, writing HL7 interfaces through Cloverleaf and Crystal Reports. At eHealth NSW I spent eight years on HealtheNet, the state-wide health information exchange, building the integration governance that let discharge summaries, pathology results and medications move between hospitals and primary care across the largest health system in the country. Then in the Northern Territory I led delivery of the technical program that consolidates the legacy systems with one, for a population spread across some of the most remote communities in Australia. Twenty-two years after I started at the Mater, our team is back inside Mater helping it absorb a hospital, which tells you something about how small this industry is and how long the problem has been waiting.
The moment was not a single event but a recognition. In every jurisdiction the systems were different, the vendors were different and the politics were different, and the failure mode was identical: good data locked in systems that could not share it, copied into warehouses that were stale by the time anyone looked, and a queue of clinicians and managers waiting for someone with the right access to answer a question they could have answered themselves. My co-founder Tan Do and I had worked together for close to fifteen years by then across two of those jurisdictions. We had solved the problem locally three times. zHealth was the decision to stop solving it locally and to build the patterns, the interface library, the governed data layer and the delivery method, once, so we could carry them to the next hospital instead of starting again.
What I did not fully appreciate is how much of the problem is about trust between people rather than compatibility between systems. Institutions move at the pace of their governance, and I used to see that as friction. I now see it as the thing that keeps patients safe, and our job is to make the evidence arrive faster rather than to route around the process. I underestimated how often the person blocked from the data is the most senior clinician in the building, and how quickly practice changes when insight is placed inside the workflow rather than in a report they have to go and find. In the Territory we watched clinicians change how they managed dialysis in remote communities because the data finally sat inside the record they already used.
And I underestimated how small the Australian health IT community is, and how far a reputation for telling the truth about sequencing and risk carries. We do not body shop and we do not do free proofs of concept, because both let everyone avoid a decision. We would rather do a paid pilot with the decision built in and be judged on whether the hospital acted on the result.
Qx. Anything else you wish to add?
The next chapter of this problem is artificial intelligence, and the temptation is to repeat the warehouse mistake at a larger scale by shipping copies of clinical data to a single model. Our view is the opposite: bring AI to governed data, do not bring data to one AI model. Every control the organisation already runs stays in force, the assistant sees only what it has been allowed to see, and the generated query is visible so governance can check the working.
The clearest example is a pharmacy assistant built on InterSystems Data Studio, which we showed live at READY 2026. A pharmacy director asks which products in the formulary treat hepatitis C; the assistant recognises the direct-acting antivirals from the product master, joins them to the dispensing data and totals the cost by year. Spend ramps up sharply in 2016 and falls away by 2018, and her final question is simply: why? The assistant explains that the new antivirals were listed on the PBS in 2016 with far higher cure rates, treatment surged, and by 2018 the backlog of patients had been treated. None of that is in the loaded data. It comes from blending the query result with external clinical and policy knowledge, and it answers in minutes a question that would once have sat in an analyst’s queue for weeks.
What makes it governed rather than merely clever is that the SQL stays on screen to be read, kept and re-run, every response carries an audit trace, and when a question is incomplete the assistant asks rather than guesses. The signal is the same one we saw at SWARH: when clinicians and executives can ask in plain language and see the working, the dashboard backlog finally starts to clear.
Anyone who wants to compare notes can find us at www.zhealth.com.au or reach me directly on LinkedIn.
……………………………………….
Josh Bunting is Co-Founder and Director of zHealth, an Australian digital health consultancy specialising in clinical systems integration, data engineering and analytics for hospitals and government. He has spent more than 20 years inside public and private healthcare IT, starting as a patient administration system administrator at the Mater Hospital in Brisbane, then more than eight years at eHealth NSW where he led integration and delivery for HealtheNet, the state-wide health information exchange that won a 2015 Australian Innovation Merit Award. He later served as Director of Solution Delivery for the Northern Territory’s Core Clinical Systems Renewal Program, chairing its Central Design Authority as the Territory replaced six legacy clinical systems with a single InterSystems TrakCare based electronic health record. Josh is TOGAF certified, holds a Bachelor of Information Systems from QUT, and lives in Humpty Doo in the Northern Territory with his wife Paige and their nine children, where he also coaches youth basketball.
Links: www.zhealth.com.au | linkedin.com/in/josh-bunting
Sponsored by InterSystems