link to architecture page
link to applications page
link to software page
link to open specification page
link to project information page
link to bibliography page
link to follow-on activities page
link to news page

link to index page
link back to applications page

Applying Provenance in Organ Transplant Management

Treatment of patients through the transplantation of organs or tissue is one of the most complex distributed medical processes currently carried out. This complexity arises not only from the difficulty of the surgery itself but also from a wide range of associated processes, rules and decision making which accompany any transplantation case. Depending on the country where a particular transplant is being carried out procedures and the level of electronic automation of information / decision making may vary significantly. However, it is recognized worldwide that ICT solutions which increase the speed and accuracy of decision making can have a very significant positive impact on patient care outcomes.

The Organ Transplant Management (OTM) Application aims to speed up the allocation process of solid organs to improve graft survival rates. Its policy implements the Spanish guidelines for organ and tissue procurement and Spanish regulations for allocation, as Spain is world leader in the area,and its model is followed by other countries. OTM uses standard web service technology and has been adapted to be provenance-aware, by interacting with the provenance stores in order to keep track of the distributed execution of the allocation process for audit purposes.


The diagram above summarizes the different administrative domains (solid boxes) and units (dashed boxes) that are modelled in the OTM application. Each of these interact with each other through Web Service interfaces (circles) that send or receive messages. The Regional or National Organ Transplant Authority (OTA) is an administrative domain with no internal units. In a transplantation management scenario, one or more hospital units may be involved: the hospital transplant unit, one or several units that provide laboratory tests and the unit that is responsible for the patient records (which will use the EHCR application services. The diagram also shows some of the data stores that are involved: apart of the patient records, these include stores for the transplant units and the OTA recipient waiting lists (WL). Hospitals that are the origin of a donation also keep records of the donations performed, while hospitals that are re-cipients of the donation may include such information in the recipient's patient record. The OTA has its own records of each donation, stored case by case.

The OTM application was modeled in conjunction with the Spanish National Government FIS Carrel project, a project carried out jointly between Hospital St. Pau i Santa Creu and UPC in Barcelona Spain. It has been developed in Java 1.5 and the modular components are deployed as web services. The user interface of the OTM Application is the OTM GUI, a web application developed in Java 1.5 using the Google Web Toolkit. This application serves DHTML web pages that allow the user to interact with the OTM components representing the user's organizational unit.

Overview of the Organ Transplant Management Scenario

An organ transplant case management is a distributed medical process where decisions are taken by different actors in different institutions, and actions should be coordinated among these actors in order to solve the case. In case of organ transplants there is an extra issue that is time: organs (such as heart, lung, intestine, liver, pancreas, kidney) deteriorate rapidly between when they become available and implantation (becoming useless in less than 6 hours in some cases) – creating significant time pressure on transplantation. Furthermore cases normally arise with a waiting list of patients waiting for a suitable organ and a donation being made at a given moment in time meaning that the organ then must be assigned to one of the waiting patients (or none if no good matches are found). The activities of the individuals and organizations involved in this case management are governed by several authorities during the transplantation process. In particular the duty transplant surgeon takes initial responsibility for coordinating the process, the Regional and national Authorities take charge of assignment of organs to potential recipient and retrieval/implantation teams manage the medical process of the actual operation (in most cases the same team carries out both steps). A typical sequence in outline occurs as follows:

  • A donor becomes available.

  • The donor is assessed for potential donations by the duty transplant surgeon and his/her team.

  • Data from medical records and these examinations is passed to the immunology center to carry out potential matching tests and to the Organ Transplant Authority to begin the search for a match.

  • After making a national check for extremely urgent cases, the OTA begins a round robin process of all potential regional following established matching criteria. Hospital with potential recipients in order decide whether or not an organ could be assigned to one of their patients.

  • Immunology results are used to inform this process where available.

  • Once a decision is made, urgent arrangements are made for the recipient to be contacted and prepared.

  • Medical procedure and accompanying logistics are prepared.

  • In most cases a team from the center at which the recipient will have the organ implanted will travel to the center where the extraction will take place to perform the extraction and subsequently return with the organ to the implantation site.

  • The implantation surgery is followed by post care and monitoring of outcomes.

 

Provenance issues in OTM

As well as generic logging functions carried out by system components, the OTM application requires more advanced analysis of the outcomes of organ transplantation cases: both in terms of results generated by the software systems and in terms of records of events which occurred in the real world. Requirements for analysis come both from legal requirements (such as the Real Decreto 2070/1999/30th December: regulating activities related to the procurement and clinical usage of human organs and tissues and other Spanish law for systems to be deployed in Spain) and clinical good practice. The following example provenance questions are a sample of what would be of high value:

  • where did medical information used on each step of the process came from,

  • which medical actor was the source of information.

  • what kind of medical record was available to actors on each step of the process

  • when a given medical process was carried out, and who was responsible for it.

  • when a decision was taken, and what was the basis of the decision

  • which medical actors were asked to provide medical data for a decision

  • which medical actor refused to provide medical data for a decision

An example

To illustrate how provenance is handled in the OTM application, let us see how the provenance of a medical decision is recorded and then queried. For that we will select some few steps in a tipical transplant case. Let us consider a patient who has previously given consent to donate his organs. As the patient’s health declines and in foresight of a potential organ donation, one of the doctors requests the full health record for the patient and then orders a serology test through the OTM appli-cation. After brain death is observed and logged into the system (along with the re-port certifying the brain death), if all requested data and analysis results have been obtained, a doctor is asked to make a decision about the patient being a potential donor. This decision is explained in a report that is submitted as justification. The following figure shows a simplified view fo this scenario, depicting the medical workflow that actors should follow in this case.

As OTM is a distributed system, the execution of the medical workflow is distributed in different modules. Each module is responsible for monitoring parts of this process, and record the relevant events and informations for a case. Coordination and information sharing between these modules is achieved by message exchanges among them. The following figure shows the messages exchanged by the different modules of the OTM application in the same scenario.


The Transplant Unit User Interface passes requests (TU.1, TU.2) to the OTM Donor Data Collector service, which gets the electronic record from the EHCR system (OTM.1, OTM.2). Sometimes all or parts of the record are not in the same insti-tution but located in another institution (HC.1, HC.2). The Donor Data Collector service also sends the request for a serology test to the laboratory and gets back the result (OTM.4), along with a detailed report of the test. Reports are also passed in the case of the Brain Death notification (TU.3) and the final decision report (TU.5).

To make the OTM application provenance-aware, not only all interactions between the different components of the system are recorded, but also the causal relationships that link a given interaction with previous ones. This was done by modifying the code of the OTM application to make explicit such relations. The following figure gives an intuitive view of the effect of such relationship recording.

These explicit dependency relationships between interactions are the ones that allow to create meaningful traces about the provenance of a given decision or a given data item. We can see this by inspecting the documentation that OTM would produce in such scenario. The figure below graphically represents the subset of the p-assertions produced by the provenance-aware OTM which are related to the donation decision. The part of the process that happens within the electronic system is represented by interaction p-assertions (regular boxes) for all interactions (TU.x, OTM.x, HC.x), and relationship p-assertions (response_to, caused_by, based_on) capturing dependencies between data. By making these dependencies explicit we can not only connect different interactions but actually answer provenance question by tracing back such dependencies.

Even though what happens in the system has a parallelism to what happens in the real world, this is not enough to fully answer which is the provenance of a given decision. To solve this, the OTM system connects the documentation about the electronic process to the real world by adding actor state p-assertions stating who logged the information in the system (is_logged_in) and when (not shown in picture), which are the reports that justify a given state in the system (justified_by), who are the authors of these reports (authored_by) and when the action reported was performed or the decision taken (not shown). Following back the p-assertions graph in the above figure OTM can trace the provenance of the donation decision (right-most box int he figure), how it was based in some data and test requests, how a brain death notification is also involved, who requested the information, where it came from (in some cases it might come from the EHCR from another hospital), who authored the justifying reports in the main steps of the process.

These provenance traces can be graphically represented to the users by means of the provenance tools. Some of these tools also allow to do further analysis over these traces. The following figure shows how the tool depitcs a provenance trace for a donation case top the user.

During the process to make the OTM Application provenance-aware, we had to find equilibrium between the amount of collected data and the level of interference such data collection may cause in the real medical process. The use of the reports and the information logged by the staff does not give full information about what happens in real world, but gives more than enough information to trace the individual or team involved, while not introducing an excessive increase of work-load on the medical staff (we use the same reports medical staff already produces). It is important to note that the person who is logged in might not always be who authors the justifying reports (both are recorded in OTM), and the time when things are re-ported to the system might not be the time when things have happened (both also recorded in OTM). This is common practice in medical teams: most of reporting is delegated to a team member having the proper credentials and time to do it, although the report may be later checked and even signed by a prominent member of the team.

Benefits of using provenance in OTM

By transforming OTM into a provenance-aware application,

  • we augment OTM with a capability to produce at run-time an explicit representation of the process actually taking place;

  • such representation can be then queried and analysed in order to extract valuable information to validate, e.g., the decisions taken in a given case, or to make an audit of the system over a period of time.