Introduction 2
Organizational context 3
Description of the current state 4
Enterprise functions 4
Fetch patient information 4
Update patient records 4
Patient admission 4
Get treatment plan 4
Consult 4
Create treatment plan 4
Register images 4
Create external beam plan 4
Contour organs 4
Perform ct scan 4
Execution of diagnostic and therapeutic procedures 4
Appointment scheduling 4
Assessment of the current state 11
Description of planned state 12
International Comparison 13
Discussions and lessons learnt 14
Acknowledgment 15
References 15
Glossary 15
Introduction
Oncology patients might be treated with linear accelerators at outpatient radiotherapy departments. These departments require multiple computer-based application components to provide all enterprise functions. Thanks to the differences in linear accelerator machines, departments might use different components, or are able to have one component provide all functions.
As of June 7th, the Academic Medical Centre (AMC) and VU University Medical Centre (VUmc), both located in Amsterdam, have merged into one larger collaboration Amsterdam University Medical Center (AUmc). With the merger outpatient clinics are divided between the two locations, therefore a proper model of all enterprise functions, software components, and hardware components, is required.
The Oncology Information System (OIS) that is used in the AMC is Mosaiq and the OIS that is used in the VUmc is Aria. Mosaiq is an efficient care management for radiation oncology. All patient information is collected and accessible, from diagnosis through treatment and follow-up, so you can deliver the best possible care for every patiënt. Aria is a comprehensive information and image management solution that lets you oversee all aspects of oncology care for your patients. Aria combines radiation, medical and surgical oncology information into a complete, OIS that allows you to manage the patient's entire journey.
In this paper we give an overview of all actions performed to facilitate patient care, software and hardware components used by the radiotherapy department at the VUmc. We will also assess the current state in comparison with the AMC radiotherapy department, and describe a possible future state which eases the merger of both AMC and VUmc departments. Our goal of this report is to provide a better overview of how these two departments function and which possible obstacles they might run into during the merger.
Organizational Context
Organogram
Description of the Current State
Enterprise functions
The following list contains descriptions of all major functions which take place within the radiotherapy department. Each function can be found within the reference model for enterprise functions.
Patient admission
New patients presenting themselves at the radiotherapy first need to be administratively registered within the information systems. Since the VUmc's HIS (Epic) does not cover all required functionalities, the department has its own Oncology Information System (OIS) for patient management. This OIS (Aria) is able to communicate with the hospital wide HIS so a new patient at the radiotherapy department should already be known within the HIS. During patient admission a first consult and ct scan are planned so a patient's care process can start.
Fetch patient information
Since the radiotherapy department uses its own OIS, some patient values may already be entered in the hospital wide HIS when a new patient presents itself at the department. To prevent manually transcribing said data an automated communication channel is put in place. Using the Health Level 7 communication protocol, and a communication server running Biztalk, all initial data for in the OIS is fetched from the HIS.
Update patient records
After the initial data is fetched from the HIS, all changes to the patient within the HIS are automatically pushed to the OIS and vice versa. So if a patient's demographic data changes, the OIS will automatically contain the new information. The same goes for new appointments made for the radiotherapy department. All new appointments made in the OIS are automatically pushed to the HIS so other departments are aware of the availability of the patient.
Consult
Before a patient's care process actually starts, and at set points during the treatment, a patient will have a consult with the physician to assess their situation.
Create treatment plan
After the first consult and initial ct scan was made a treatment plan will be created. This defines the dose given to the patient, over a set number of fractions, at what precise location.
Get treatment plan
The treatment plan mentioned above is used by the lab technician the assess what a patient's treatment will look like, and by a physician during any follow up consults to see the treatment this patient is getting.
Register images
When multiple scans are made of a patient, one can not merge these scans into one image since a patient will have moved in between. This problem can be solved by registering one image to another. Registering an image is the process of slightly rotating or translating an image while it's on top of another fixed image, until a minimum in difference of pixel values is found. This registration results in two scans, of one patient, with both of them being in the same orientation.
Create external beam plan
After a physician has created a treatment plan, a lab technician needs to implement the plan. This is done by calculating over which angles a specific dose can be supplied, so the target area reaches the prescribed dose with minimal damage to the surrounding tissue. The final external beam plan will consist of a set of angles over which the machine needs to rotate, which doses to supply at which points, and which shape the beam needs to have.
Contour organs
To create a plan all organs and the tumor or area that need to be treated first need to be contoured. Contouring is the process of marking the edges of each organ or tumor so they're better visible within the image, and future calculations can be done with these segmentations.
Perform ct scan
For all treatment planning and beam planning processes a ct scan is required. This is to locate the tumor, determine its size, and define the center point of the radiation dose. So the first step right after a patient's first consult at the radiotherapy, is performing a ct scan.
Appointment scheduling
Now a patient's care process is defined, and a physician has defined how many fractions and consults a patient should have, all of the appointment can be made. So this final step is adding the patient to the calendar of the assigned machine, lab technicians, and physician if it's a consult.
Execution of diagnostic and therapeutic procedures
After all of the previous steps are performed, and the entire future patient care process is defined, a patient can actually receive the procedures. So in this case it's a patient receiving a fraction of the prescribed dose at one of the machines.
Application Components
The VUmc uses a fairly straightforward setup of their applications. Aria functions as the Oncology Information System (OIS). A vast majority of the enterprise functions utilized in the department are found within Aria. External beam planning, contouring, image registration, treatment planning and questionnaires are all part of this application. The comprehensive list of possible functions in Aria allows the department to keep the number of software based applications low.
As part of the merger between the AMC and VUmc, both hospitals have opted to require the use of the same HIS, Epic. However, Epic does not offer the same suite of functions that Aria does. This results in a relatively low usage of Epic within the department. Epic is mainly used in the registration of the patient when they present themselves for the first time. In this case a new patient is created in Aria, which will subsequently fetch additional relevant patient information from Epic. Furthermore, Epic is used to plan the patient for their initial CT scan and finally when the treatment process is completed, and the performed treatment can be sent to the financial department for billing. In essence, Epic acts as a jumping off point for the treatment process and as a return point for when the treatment is complete.
The main way to communicate between Aria and Epic is through a communication server, Biztalk. Biztalk services several departments within the hospital that require the sharing of data between their own information system and Epic. Sharing the data is mostly done with the use of the Health Level 7 (HL7) standard for the transfer of clinical data. An exception to this can be found in the handling of the initial CT Scan, which will directly transfer to Aria through the Digital Imaging and Communications in Medicine – Radiotherapy (DICOM-RT) standard.
Two of the available Linear Accelerator (LINAC) devices in the department are ViewRay MRIdian devices, these devices do not interact with Aria. Instead they are designed to work with ViewRay’s OIS. As such the department runs 2 separate OISs. ViewRay OIS fulfills the same tasks as Aria, but only for the MRIdian devices.
Pentaho is a Business Intelligence software suite that is used for reporting on patients’ status and progress within the department. This application reads data from Epic, Aria and ViewRay OIS to build aggregate data reports that are easier to read than to manually search and collect the data from each application.
Treatment Process
Typically, once a patient is referred to the radiotherapy department the Logistical Planning Bureau (LPB) will start arranging an appointment with the physician and a Computed Tomography (CT) device. The patient is informed of their upcoming appointment and they will present themselves to the front desk for registration on the day of the appointment. At this point the receptionist registers the patient’s data in the oncology information system (Aria). Aria will automatically fetch the relevant data from the electronic patient record (Epic) to automatically complete the patient information.
A physician sits down with the patient to provide a consultation. In this consultation the patient is informed about the proceedings of their treatment. Afterwards the patient is referred to make an initial CT scan. This scan is saved in Epic and subsequently imported into Aria.
With the CT scan imported into Aria a lab technician can start on contouring the organs. A physician contours the difficult organs and the area to treat, usually the tumour. These contours are used in the creation of the external beam planning. A lab technician uses one of Aria’s subsystems to perform this task. Once this has been completed a physician will complete the treatment plan with prescribing radiation doses and approves the final plan. A clinical physicist may provide a second opinion on the viability of the plan. Once the treatment plan has been locked in the LPB starts scheduling the patient.
The patient then follows the treatment plan as prescribed. Until the treatment is completed the patient receives doses of radiation according to the earlier made plan. The lab technician administers the doses of radiation with the use of Aria, which will load the treatment plan and send it to the Linear Accelerator (LINAC) to be used. This cycle will continue until the patient has received all required doses of radiation and has no more planned treatments. At this point the patient’s records are updated to reflect the completed treatment in Aria and Epic, the lab technician finishes up the treatments and the physician writes a closing letter.
The described process is not a complete overview of the steps taken during treatment, many variations of the process occur due to unforeseeable situations that can, and do occur during the day to day operations of the radiotherapy unit. Furthermore, the MRIdian devices have not been incorporated into this overview, only Varian devices. MRIdian devices use a different OIS that is completely separate from Aria and Epic and are not interoperable at the time of writing. However, the process of treating patients with a MRIdian device is not completely different than treating patients with a Varian device, and are generally the same.
3LGM2
A three-layer graph-based meta model (3LGM2) is a model designed to describe, change and plan health information systems. 'Three- layer' references the structure of this model, since it's divided in three major parts.
The first layer is the Domain Layer, this describes the enterprise functions and entities within the scope of the model. In our case the modeled enterprise functions are actions performed by either a patient, or the employees while at the department of radiotherapy of the VUmc hospital. Entities are the people or objects performing said functions. So two of our entities are the previously mentioned patients and employees.
This domain layer is connected to the Logical Tool Layer, which is a collection of tools (e.g. software components) which are used to perform the functions described in the Domain Layer. Every component from the Logical Tool Layer has a line connecting it to the function which is dependent on it. This provides an overview of which application is responsible for which function, so the vital components stand out. Using these connections one can also create an overview of functions that are performed by multiple tools.
The final layer, the Physical Tool Layer, models, as the name suggests, the physical components which are responsible for supporting the second layer. E.g. a computer which runs a software component from the second layer.
All three layers combined should give an overview of all functions and entity types at the radiotherapy department, which logical tools these actions are dependent on, and which physical tools these actions are performed on. These models can be compared to other similar departments to emphasize differences in our health system architectures, and possible easier configurations. Figure 2 is an overview of our entire model, Figures 3-5 are more readable figures for each layer individually.
Figure 2: Overview of all three layers in our 3LGM2 model.
Assessment of the Current State
Quality in General
Quality has been assessed through interviews with employees within the department. Each employee fulfilled a different role, and as such a wide variety of experiences has been taken into account in this report.
Many employees were generally positive in regards to the applications they were working with and no severe issues could be identified. Smaller nuisances were brought forward, and these will be covered in this report. In general, however, each reported issue has already been identified by the department, and solutions are in place or underway to solve or mitigate these issues.
Quality of Structures
Quality of Software Based Applications
As the application that supports the most enterprise functions, Aria is the main application within the department. Generally, the other applications are in place to support Aria. The main strength of Aria is that it does not require additional applications to fulfill the treatment related enterprise functions. As an All-in-One system, many subcomponents exist within Aria so that each step in the treatment process can be performed within the same environment with the same data across steps.
Another strength of Aria is that there are no designated PCs for each specific step of the treatment process. Although not all PCs are powerful enough to operate every subcomponent of Aria, such as the contouring, they are not locked out from accessing the functionality. One exception exists in the external beam planning. Due to licensing costs the VUmc has a limited amount of concurrent users that are allowed to use the external beam planning component. This is solved by banning the use of the component from all PCs except the ones that are assigned to external beam planning duties.
Aria is generally regarded as a powerful and useful application. However, it is also regarded as slow. Aria has a tendency to require significant time to process requests or switch to another component. This time spent waiting adds up, and causes annoyance with users. Efforts are planned to increase the speed at which Aria operates. Namely, a new Aria server has been planned.
One of the functionalities of Aria is the possibility to inspect the current state of the care path of the patient. Whenever a step is completed, the health professional responsible has to manually set the task to complete. If a prior task has not been completed, the following tasks do not unlock. When a task was mistakenly not set to complete, this can result in delays in the process as the other health professionals cannot start on working their tasks.
ViewRay MRIdian devices do not interact with Aria and/or Epic. Instead they are designed to work with ViewRay’s own OIS. Unfortunately, this OIS also does not possess the capability to communicate with either Aria and/or Epic. This means that the relevant information has to be transferred by hand for each patient that requires treatment on the MRIdian Device. Manual data transfers can be vulnerable to mistakes. ViewRay already has been approached to include an HL7 coupling in their OIS, and this issue should be resolved in the near future.
Quality of Physical Data Processing Systems
The hardware used by the department is equally straightforward as the software. Each software component runs on its own server, if needed and are generally segmented from each other. Communication between components, if possible, is handled by a central communication server that also services several other departments.
Not all PCs used have the necessary processing power to handle all functionality of Aria. But these PCs are generally not used by the healthcare professionals that are tasked with performing the tasks associated with the functionality. For instance, the PCs used by the receptionists do not require the processing power to perform external beam planning or image registration, and as such do not have it.
Because the DICOM files created from the CT scans can, and do, get quite large, the department has opted to not store these within Aria’s own database. Instead, these files are saved to a second server, the Aria fileshare, which sole purpose is to store these DICOM images. Aria is pointed to where to find the images on the Aria fileshare instead. The Aria fileshare in its current state uses somewhat outdated hardware. For instance, the Hard Disk Drives (HDD) in the server are limited to a size of 2TB each. Without upgrades to the hardware, whenever a HDD reaches its storage capacity, another one would have to be added to the server to keep up with storage demands. Fortunately, a replacement is planned so that the limitations on HDD size can be eliminated.
Description of planned state
With the merger of the AMC and VUmc in progress, both hospitals’ radiotherapy departments will also have to be merged. The issue lies in the fact that the AMC radiotherapy department uses a different suite of software based applications to run their day to day operations.
Whereas the VUmc department uses Aria as their OIS, the AMC department uses Mosaiq. Each OIS is designed to operate with a specific brand of LINAC devices. Aria, which is developed by Varian, is designed to work with Varian devices. Similarly, Mosaiq is designed to work with Elekta devices. This lack of interoperability poses a problem in simply merging the existing departments, since this would mean that a single department would run multiple OIS suites for each half of the LINAC devices.
Since the radiotherapy department will be moving to the VUmc location, Aria has been selected as the OIS for the new, combined, department. When compared to Mosaiq, Aria offers several advantages. Namely the fact that Aria offers a complete range of subcomponents that are used in the treatment process. Mosaiq, for instance, does not offer the contouring functionality natively, RayStation is used for this purpose instead. However, users of both systems have not expressed any negativity towards either system.
This still leaves the issue of the LINAC devices only working with one OIS. While alterations can be made to the devices to work with a different OIS, this will void any warranty on the devices and would open up the hospital to legal liability. In our opinion, the best way to proceed with the merger of the departments is to phase out the AMC department over time. Each LINAC device has an average life-span of 10 years, depending on current state of the device, available funds and/or recent advances in technology. When an Elekta devices in the AMC reaches its end of life, it should be replaced with a Varian device. This 10 year timeline should give both locations enough time to prepare for the upcoming changes.
From an operations point of view the AMC and VUmc departments are not dissimilar. Small differences do exist. For instance, the lab technician will contour some of the easier organs prior to the physician contouring the tumour and more difficult organs in the VUmc, whereas the physician will do all the contouring in the AMC. Furthermore, when a patient comes in for their initial consult, the VUmc will have them scheduled for a planning CT scan on the same day as the consult. The AMC department will start scheduling only when the patient has had their initial consult.
International Comparison
This comparison includes the VUmc, AMC and Braunschweig Medical Center departments. When comparing these three departments, the first thing that can be noted is that the process used it close to equal. The main differences lie in the used software packages. For instance, where the AMC and VUmc use Epic for their HIS, Braunschweig Medical Center uses SAP. Braunschweig Medical Center and the VUmc use Aria as their OIS, while the AMC uses Mosaiq. Each medical center uses a different communication server, but they each fulfill the same purpose.
Another point to note is that Braunschweig Medical Center still uses paper based applications in their treatment process, both the AMC and VUmc have eliminated these. Paper based applications carry the risk of loss of data. When a document gets lost in the process, issues may arise when the data that was stored on the document is required in the safe continuation of the treatment of the patient. Therefore, it is not unwise to consider transferring the duties of a paper based system to a software based application system.
In terms of capacity, the VUmc has treated roughly 53,500 patients in 2017. When compared to the AMC (56,000) and Braunschweig Medical Center (65,000) it is the smallest of the three. However, when comparing the radiotherapy departments, Braunschweig Medical Center ends up being the smallest of the three at 1412 patient admissions in 2017. Compare this to the AMC (2500) and VUmc (3856). Furthermore, the AMC and VUmc each have 6 LINAC devices and a personal CT Scanner available, while Braunschweig Medical Center only has 3 LINAC devices and uses the CT Scanner of the radiology department.
Short of the aforementioned differences, all three departments function in much the same way, with very similar software and hardware setups. No major differences could be found during the time we met with the other departments.
Discussions and Lessons Learnt
Created models were noted as generally being accurate representations of reality. The radiotherapy department of the VUmc utilizes an efficient way of treating patients with minimal drawbacks that do not sufficiently impact quality of care to make drastic changes to the way things are done.
Acknowledgment
We would like to thank the following persons for their much appreciated assistance in our endeavours to write this report.
Roy Kossen
Ilse van der Zwart – Schoneveld
Saar van ‘t Holt
George D’Arnaud
Miguel Palacios
Richard van Zanten
References
Winter, A., Haux, R., Ammenwerth, E., Brigl, B., Hellrung, N., Jahn, F. (2010).
Health Information Systems Architectures and Strategies
ISBN: 978-1-84996-441-8.
Glossary