ICW - Technology for Health

Software Master Class

The Software Master Class (SMC) is part of the university cooperation between ICW and the study program "Medical Informatics" run jointly by the University of Heidelberg and the Heilbronn University. It is a special seminar on software engineering that is offered once a year to exceptional students, who have displayed excellent software development skills throughout their studies. During this seminar, students will participate in real-life projects in the field of medical informatics. The topics of the SMC are driven by the University Hospital Heidelberg (ZIM) representing the customer role in these projects. The software solutions are based on the eHealth Framework (eHF). Working with the eHF will provide students with solid, relevant experience in latest methods and software technologies, like model driven software development (MDSD) and agile processes. ICW and University personnel support the course as supervisors and instructors.

Abstract

The Pancreas-Cancer-Registry is a specialized cancer registry that will be built by the University Hospital of Heidelberg along with other University Hospitals. For this real life project the students developed a proof of concept application based on the eHF as the development and application platform. In due course a separate therapy module and a web GUI were developed. The development of the therapy module was model-driven using the eHF Generator. The web GUI makes use of the Google Web Toolkit (GWT).

Background

Note: Most of the rest of this article is based on the presentation from the ICW Developer Conference by Hauke Hund and Björn Mehner, which you can see above.

Before the students could commit the first lines of code they had to understand the medical domain, pancreatic cancer. (Before we could commit the first lines of code we had to understand our medical domain, pancreatic cancer.) The purpose of the registry is the collection of patient data to enhance cancer treatment and research for that specific kind of cancer, since the mortality rate for pancreas cancer is extremely high and the amount of available data about cancer therapies is rather small. Pancreatic cancer has a very low survival rate of about 1 percent. This means that people with pancreatic cancer usually only survive about 4 - 6 months after being diagnosed with it.

Looking at Germany we can see that about 12,900 people are diagnosed with pancreatic cancer each year. In the year 2000, 12,100 died from it. So, what is the problem with pancreatic cancer? Pancreatic cancer is one of these bad cancers where you don't have a specific symptom attached to it. So when someone gets diagnosed with pancreatic cancer they usually get diagnosed because there are metastases already (where the tumour has spread to other parts of the body beyond the primary site). If there are not, they are admitted with a diagnosis like abdominal pain or pain in the back or something similar. To connect this symptom to a pancreatic cancer is quite hard. Because people are diagnosed so late, it is hard to get them into clinical trials or even to design clinical trials because there really aren't very many documented cases about.

So what the university hospitals that designed the science project we worked on really wanted to do is to introduce a German-based network to help gather more information about pancreatic cancer and to document more cases in a common way over these 5 university hospitals in Germany: Greifswald, Heidelberg, Marburg, Munich and Ulm.

What they wanted to do is develop a web application with four main parts. The first is a simple internet forum to help connect the scientists and let them communicate with each other. The second is a serum and tissue bank to store histological specimens and to provide added value, photos of these specimens. The third part, a system to develop, perform and document clinical trials and the fourth part, the one we developed a prototype for using eHF, was the pancreas cancer registry.

The application has three data tabs. The first one is for personal data, the second one is for documenting medical data, and the third is for documenting the course of the therapeutic methods applied. When adding medical data you can use the ICD 10 codes field - if you don't know the correct code you will get some suggestions. During the course of therapy, there are therapies prescribed and documented. There is also the chance to document reactions. [To see the application in action, view the video from 07:40 -12:40.]

SMC Application Architecture

Since the pancreas registry is built on top of eHF we first want to give a brief description how to create an eHF based application before going into further details about the pancreas registry’s architecture. An eHF application is a bundled set of modules and corresponding configuration and data.

Here are the typical steps to create an application based on eHF:

1 Select a number of eHF modules to assemble into an application (and/or optionally, build your own custom modules using the eHF Generator)
2 Create an assembly project to put them together
3 Additionally, do some configuration to glue the modules together and configure them
4 Push the button and an application is assembled.

Let's talk about the software architecture we used for the SMC prototype. The whole thing is a web application. What we see in the next image is the component model more or less.

Starting on the bottom of the Software Architecture image the light blue rectangular box, labeled Modules, represents the backend. Here we see a lot of individual modules. The blue colored modules were used directly from the eHF, (Record Medical, Record Admin, Codesystem, and Codesystem Repository) they are ready to use and we were able to leverage our use cases here. The orange colored modules were developed by the master class (Therapy, an additional Codesystem Repository) and the green rectangles at the top of the image are generated GWT GUI elements.

So what was used from the eHF? Directly, we could use the Record Medical module, for example, to store the medical data like weight and height and so on. The Record Admin module was used to store the patient’s personal data. Both of these modules make use of Codesystems.

Custom Modules

Starting on the bottom of the Software Architecture image the light blue rectangular box, labeled Modules, represents the backend. Here we see a lot of individual modules. The blue colored modules were used directly from the eHF, (Record Medical, Record Admin, Codesystem, and Codesystem Repository) they are ready to use and we were able to leverage our use cases here. The orange colored modules were developed by the master class (Therapy, an additional Codesystem Repository) and the green rectangles at the top of the image are generated GWT GUI elements.

So what was used from the eHF? Directly, we could use the Record Medical module, for example, to store the medical data like weight and height and so on. The Record Admin module was used to store the patient’s personal data. Both of these modules make use of Codesystems.

The Therapy module UML diagram shows how the data is structured and stored. In Eclipse, we used the Topcase UML editor to edit this model. On the top of the image you can see the AbstractTherapy class. This stores a simple description and derived from that a Resection in the therapy. The Therapy is a 1…* (one to many) concatenation with TherapyMethods.

We made heavy use of codes to define the value ranges for a therapyType. We also used a Code for the resectionType in the Resection class and also an AnnotatedCode for the methodType in TherapyMethod. In the AbstractTherapy class there are some free getters, data access methods (loadScopeByTherapyType, loadTherapiesByType), and we defined them here so the eHF Generator could go ahead and add them to the data access stack.

Summary

In this project eHF 2.5 was used as an EHR (Electronic Health Record) so you can see it is not always about building PHRs (Personal Health Records) but it can be used for many things. Here it is being used for a project in a clinical environment. The eHF Generator helped us to develop quickly and produce reliable software. We discovered some missing functionality in eHF, which was mainly due to the new context in which we used the framework. Overall, we were able to find and fix bugs, and improve the documentation in eHF 2.7. The results are now on the partner DVDs.