Yes. A hospital can implement AI-supported diagnostics on top of existing HIS/EHR, PACS and RIS systems without replacing them first, provided that the required data and context are reliably available through stable, documented extraction interfaces. If that access is missing, exceptions remain invisible or the existing core cannot support the workflow, then core replacement becomes a more prominent consideration.
In brief: AI diagnostics on legacy systems
An API and workflow layer can enable targeted AI modernization without immediately replacing the core, but it does not automatically remove the technical and organizational dependencies. Here, retrofit refers both to a read-only extension and to an extension with write-back; write-back places greater demands on the existing core.
- First assess whether all required data, context and access rights are actually available; the presence of an interface does not prove that the complete workflow can be executed.
- Preferably start with a read-only route and validate the data flow using your own anonymized data before considering write-back to core systems.
- Organize task preparation, context validation and processing centrally, so individual subsystems do not each have to manage their own connections to AI applications.
- Also assess deviations such as time-outs, incomplete scan series and AI indeterminacy: a retrofit is unsuitable if missing results are not given a visible status and follow-up action.
- An intermediary layer enables department-specific innovation, but technical debt, interfaces and dependencies on the legacy core remain.
- Assess the initial investment together with the ongoing costs of adapters, monitoring and managing the hybrid environment.
Can AI diagnostics be added on top of legacy systems without replacing them first?
Yes, a hospital can add AI-supported diagnostics on top of existing systems without immediately replacing that core. In this article, a retrofit is such an addition around the existing core: the supplementary layer extracts data and can write results back when the environment reliably supports this. This is only possible when the HIS/EHR, PACS and RIS make the required data available through stable, documented extraction interfaces. If that access is missing, an additional layer is not a solution for a closed data flow.
The first question, therefore, is not whether an AI application is technically attractive. The first question is which data a workflow requires, where that data is located today and through which route it may be extracted. Consider HL7 v2 feeds, authorized SQL replica access or DICOM C-MOVE and C-STORE services. These are examples of extraction interfaces. They make it possible to make data from existing core systems available without immediately replacing the entire core.
A retrofit therefore remains dependent on the existing environment. For example, one PACS may make images or related information available through a usable route, while another source contains data that cannot be accessed in a usable way. An interface that exists on paper can also be insufficient when documentation is absent, access is unstable or the required context is not included. Therefore, do not treat the presence of an interface as proof that the entire workflow can be executed.
Start read-first. The supplementary layer extracts data from existing systems and displays or processes it outside the core. This keeps the initial assessment focused on actual data availability, the completeness of the context and the functioning of the transfer. Writing to the EHR or another core system is a separate choice with a greater dependency on existing rules and validations.
Also define an assessment framework in advance. Determine which data must be available, which exceptions must become visible and when the selected route works sufficiently well to proceed. Test that assumption with a Proof of Concept using your own anonymized data before a production rollout. This clarifies whether the intended integration layer truly fits the hospital's systems, data flows, governance and supplier agreements.
Core replacement becomes a more prominent consideration when that foundation is missing: when essential data cannot be extracted reliably, when the required context remains structurally out of reach, or when the existing core cannot support the intended workflow. The retrofit route therefore first requires evidence of data accessibility.
Why a central Task Manager can limit separate AI connections
For this integration layer, AI-supported diagnostics concerns the route through which diagnostic context reaches AI processing and can become part of the workflow again. It is therefore not an assessment of the diagnostic outcome, but of the organization of the inference task. IHE AIW-I divides this organization across two roles: the Task Manager prepares and routes the task, while the Task Performer performs the inference.
The Task Manager is the central starting point for a request. This role gathers the diagnostic context available for the task and combines it with the required input parameters. Before sending, the Task Manager validates those parameters. This explicitly establishes the point at which the task is assembled and checked before AI processing begins. For a hospital that retains existing EHR, PACS or RIS environments, this makes the distinction visible: systems that supply context do not each need to organize complete task handling with every AI application separately.
After this preparation, the Task Manager sends the inference task asynchronously to the Task Performer. Sending and execution are therefore separate steps. The central role remains responsible for assembling and validating the task; the performing role processes the inference. This separation is relevant when multiple subsystems are involved in a diagnostic workflow. It prevents every subsystem from having to determine how to send a task to each individual AI application.
The value of this pattern therefore does not lie in an additional connection in itself, but in limiting a network of direct connections between subsystems. Without a central route, the same AI application may need to connect separately to different sources and departments. Then, each connection differs in where context is assembled, which input is checked and who controls processing. With a Task Manager, these steps are located in one recognizable place in the workflow layer, while the Task Performer focuses on inference. This gives decision-makers a concrete point for assessment: which context is gathered centrally, which parameters are validated before sending and which systems actually need to connect to the task flow.
When does an invisible exception flow make a retrofit unusable?
A retrofit can only be properly assessed when not only normal AI processing, but also deviations, have a visible place in the diagnostic workflow. A demonstration in which a complete scan series is supplied, the inference task is completed and a result is returned says little about the points at which that chain deviates. This is precisely where a connection that appears compatible on paper can lead to missing results, inquiries between departments and an unclear status for users.
Consider a time-out after a change to the network route or segmentation. AI processing may then not return in time, while the request has been sent from the source environment. All involved parties must be able to see that the task has not been completed, who follows it up and what the next step is. Otherwise, the task disappears from view: there is no usable result, but also no clear point at which the processing is recognizable as failed.
Incomplete scan series require the same attention. An inference task may be started while the required input is not yet complete. If the workflow does not contain a recognizable route for that situation, an input deficiency may only become apparent after processing has been requested, or remain outside the daily workflow. Users must then be able to determine that a task cannot proceed based on the available series, rather than having to find out why an expected result is missing.
AI indeterminacy also does not automatically fit into the regular flow. This means that processing has been performed technically, but does not produce a result that proceeds in the usual way. Without predefined handling, the task remains between two statuses: completed from a technical perspective, but without a clear next step in the diagnostic workflow. This increases the risk that users and systems have different views of what happened to the task.
This is where the choice between an additional API and workflow layer and a broader change to the core becomes practical. Can the selected route make time-outs, incomplete series and indeterminacy visible within existing processes, or does the status of a missing result remain dependent on manual inquiries? If a retrofit supports only the successful route, the connection with legacy hospital software falls short precisely at these moments.
What does an API intermediary layer gain, and what remains with the legacy core?
An API intermediary layer shifts the modernization choice: the hospital adds room for diagnostic AI and department-specific functions while the existing core remains in use. This differs from direct core replacement. The intermediary layer can organize data exchange and supplementary applications around the legacy core, but it does not take over that core's limitations, dependencies and technical debt.
| Comparison point | API intermediary layer around the legacy core | Direct replacement of the core |
|---|---|---|
| Where does modernization take place? | New AI applications and functions for a specific department are given a place outside the existing core. The core remains part of day-to-day care delivery. | Modernization is concentrated on the system that currently performs the core function. AI diagnostics thus becomes part of a broader change to the foundation on which existing processes rely. |
| What remains technically in place? | The legacy core remains present, including accumulated technical debt. Even when a new layer exposes data or adds functions, limitations of older components and existing dependencies remain relevant. | The existing core itself becomes the subject of change. This shifts the question from extending around an existing system to the consequences of transitioning to another core. |
| What architecture emerges? | A hybrid architecture: the legacy core and the supplementary integration or application layer operate alongside each other. The connection between them remains a fixed part of the environment. | The architecture is arranged around another core. The choice therefore concerns not only the connection of AI diagnostics, but also how broader processes are accommodated again. |
| What does this mean for department-specific innovation? | A department can connect supplementary diagnostic functions without the entire hospital environment having to change at once. This creates room for a targeted extension, provided that the required data exchange and responsibilities fit the existing systems. | Department-specific requirements are assessed within a core transformation program. The scope for innovation then relates to the configuration of that new core and the transition of existing processes. |
| Which compatibility question remains open? | An additional layer does not automatically resolve how results, data and responsibilities continue to move between existing systems. The hospital must therefore continue to assess the constraints the legacy core places on the supplementary route. | Replacement changes the core of the landscape, but does not remove the need for surrounding processes, systems and dependencies to connect to the new situation. |
| Where does a workflow portal fit? | A workflow portal can be used as a user layer within this route. It is not a replacement for the integration layer and does not eliminate technical debt in the legacy core. | Even with a new core, a portal can exist alongside the core system. Its presence does not in itself determine whether core replacement is required. |
Lower entry costs do not reduce the hybrid management burden
A retrofit primarily shifts costs between the beginning and the period afterward. The initial capital investment may be lower than with direct core replacement, while adapters and interface monitoring create an ongoing management and maintenance component. This comparison describes a cost structure; it does not determine which route is less expensive in every situation.
| Cost and management point | Retrofit on top of the legacy core | Implication for route selection |
|---|---|---|
| Initial Capex | The capital investment at the outset may be lower because the existing core is not replaced immediately. | A lower entry point shifts the question from a major replacement to a defined addition. It says nothing yet about the total management burden over time. |
| Adapters | Adapters connect the supplementary layer with existing systems and remain part of the hybrid architecture. | Every adapter is an ongoing dependency on the interfaces, data and changes on both sides of the connection. |
| Interface monitoring | The connections require continuous attention to determine whether the exchange still works as the workflow expects. | Monitoring is not a one-time delivery activity. It is part of the operational cost of a route that keeps multiple layers operating alongside one another. |
| Ongoing Opex | Management and maintenance of adapters and interface monitoring form a recurring operational component. | Include this component alongside the initial investment. Otherwise, a retrofit appears lightweight only at the point of purchase, while the management challenge only becomes visible later. |
| Hybrid management burden | The existing core, the new layer and the connection between them continue to operate together. | The choice is therefore not only about procurement. It is also about who carries management responsibility when suppliers, interfaces or work processes change. |
| Comparison with replacement | A retrofit emphasizes addition and ongoing management of the connections. | Direct replacement is not necessarily more expensive. The appropriate route depends on the existing core, the required connections and the capacity to manage the selected architecture. |
How do you apply the choice to your AI proposal?
Use the proposal to compare not only functions, but also the freedom and management burden created by the chosen architecture. Assess the points below as one coherent consideration: more room for your own selection and customized screens is balanced against the simplicity of a suite and the dependency that may result.
- Which AI application remains selectable? Establish whether the route leaves room to choose an AI application that fits the intended workflow. In a best-of-breed approach, freedom of selection is an explicit part of the choice. This freedom is only usable when the existing systems and the integration layer can actually supply the required data and context.
- Which screens can be customized? Ask whether user screens can align with how departments need to view and use information. Customized screens can be part of the supplementary layer within a best-of-breed route. However, they do not automatically resolve limitations in the HIS/EHR, PACS or RIS.
- What does an all-in-one software suite take over? An all-in-one suite can increase operational management simplicity. The organization then has fewer separate choices around applications and user layers. At the same time, specify clearly which components the suite includes and which existing systems or connections remain alongside it.
- What supplier dependency arises? Management simplicity can coincide with significant supplier dependency. Therefore, assess not only which functions are available now, but also how much room remains to choose another AI application, another screen or an additional connection later. Supplier dependency is not merely a contractual issue; it affects day-to-day management and change capacity.
- Where does the integration boundary remain? Specify which data comes from the legacy core, which steps take place in a supplementary layer and which functions remain within a suite. This makes it visible whether the proposal bypasses an existing limitation, makes it manageable or merely shifts it to another layer.
- Who carries management responsibility after go-live? Link freedom of choice to ownership. Multiple applications and customized screens create a different management challenge than a suite. Establish which party is responsible for connections, interface changes and their consequences for the workflow.
Read-only or write-back: where is the difference in the daily workflow?
The choice concerns where an AI result lands. Read-only keeps the supplementary layer separate from writing back to the EHR. Write-back returns the result to the existing workflow, but thereby increases the validation task and the consequences when the connection does not work as expected.
Is read-only a suitable first step?
Read-only can be a suitable first step when you first want to assess whether data, context and presentation work well together outside the core. This route can be implemented faster and more safely than deep write-back integration because the supplementary layer does not write data back to the EHR. This does not mean that read-only is risk-free or that it resolves all workflow questions.
The downside is context switching. Users may have to switch between the existing working environment and a separate presentation layer. The workflow is therefore spread across more than one screen or application. Assess where the result becomes visible, which context is available there and which action must still take place in the existing core afterward.
Why is write-back not automatically better?
Write-back can streamline the workflow because the result returns to the environment where daily documentation takes place. However, this connection is not merely a design choice. It ties the supplementary layer more directly to the EHR's rules, data and processing.
This makes more extensive validation necessary and increases the risks of failure. An error, missing context or divergent processing affects not only the presentation layer, but also the write-back route. Write-back is therefore not automatically the next step after a read-only trial. The route is only appropriate when the hospital can concretely assess the data flows, existing validations, exceptions and responsibilities surrounding that feedback loop.
The right route preserves both interoperability and freedom of choice
Interoperability must be a visible architectural characteristic, not a general promise in a proposal. For modular healthcare APIs, HL7 FHIR provides an anchor for data exchange. IHE AIW-I, in turn, describes roles for orchestrating AI workflows, including the Task Manager and Task Performer.[1][2][3]
These two topics answer different questions. A modular API layer concerns how data and functions can be exposed. Workflow orchestration concerns how an AI task receives context, is validated and is sent for processing. A route that explicitly addresses both topics makes the boundaries between core systems, the integration layer and supplementary applications clearer.
Standards do not automatically make data accessible. Existing systems, versions, supplier agreements and internal governance still determine whether an interface is available and which context can actually be used. An API layer is therefore only appropriate when the actual data flow has been demonstrated in advance. A workflow portal does not change that dependency; it can at most provide a place where users view or work with the outcome.
Freedom of choice deserves the same attention as the initial connection. An all-in-one route can simplify management, but supplier dependency can limit the ability to add another AI application, user layer or connection later. A best-of-breed route retains more room for choice, but requires management of the connections between its individual parts.
This shifts the decision question from which route appears most modern to what demonstrably remains interoperable. Record which dependencies remain in place contractually and operationally, who manages the connections and how deviations remain visible when the normal flow fails. This makes the route choice testable against the day-to-day operation of the architecture.
First define the process question and assessment framework
Start with a half-hour conversation about the existing process: where does delay arise, which actions require unnecessary attention and which decision point deserves support? Shazzoo can help define one clearly scoped use case and a clear assessment framework in advance. A Proof of Concept using your own data can then be an appropriate next step, so assumptions can be examined in the daily context before hardening, integration and a phased rollout are discussed.