Robust design of web services supporting the home administration of drug infusion in pediatric oncology

Cancer home care is a sector of particular relevance for the Italian health service. The budget ceilings imposed by public finance pose the need to reduce hospitalisation costs, moving patients from treatment to home care as much as possible. This is especially true in the field of pediatric oncology, where a protected family environment offers a variety of benefits to young patients and their families. However, in order to guarantee adequate assistance services, an integrated information system for management must be devised as the center of gravity of a coordinated network of, even heterogeneous, actors. This paper focuses on the identification and evolving development of web services for regulation and control of home administration of drug infusion in pediatric oncology. The Service Oriented Architecture (SOA) remains the software architecture of reference, whereas the methodological approach is open to a reconsideration of the continuous improvement of the whole process in light of the ceaseless progress of medical science and information technology. In this paper, his goal is achieved by using a methodological design approach that combines the UML modeling based on Case Stories and the process optimization of Axiomatic Design. Case Stories allow the formalization of end users' requirements in UML language, easily interpreted by software developers. On the other hand, Axiomatic Design allows optimizing the design process by identifying the most robust solutions in terms of greater logical coherence and lesser systemic complexity. We analyze a case study focused on the design of web services supporting the home administration of drug infusion, for young cancer patients in home care. Then, we show how the UML-modeling methodology can be used to design new services on the basis of specific Use Cases. Finally, through the Axiomatic design approach we verify the proposed solutions, by identifying the robust set of web services to be implemented.


Premise
Cancer home care is an important field for the national health service. The spending limits imposed by public finance pose the need to reduce in-patient costs in hospitals, relocating home care as much as possible [1]. This is even more true in the field of pediatric oncology, where a protected family setting offers several benefits to young patients and their families. In order to guarantee suitable care services, however, it is necessary to devise an Integrated Information Management System [1][2][3]. This can be achieved by developing an open platform of services, constituting the center of gravity of a well coordinated network of heterogeneous actors [4][5][6]. The primary purpose of such a network is the provision of medical, social and psychological interventions with a service level adequate to the gravity of Research Council (CNR) of Italy and financed by the Ministry of Education, Universities and Research [7]. The general objective of H@H is creating a network of integrated health and social services and interoperable devices/systems to better improve the quality of life of people/families both with difficulties and with any particular problems, through solutions, which guarantee the greatest possible autonomy within their own environment. The experience of the Gaslini Institute is an authentic best practice considering the similar centers operating in health systems with universal coverage welfare. Thus, such experience has been posed as object of our analysis.

Project phases
The H@H Project has been launched by proposing a methodology, based on Unified Modelling Language (UML), to identify health and social care web services on the basis of Case Stories. [7,8]. In this paper, this methodology is also used to study the current process of home administration of drug infusion at the Gaslini Institute. Thus, it is required the to identify the web services necessary to implement the overall mechanism of data exchange in the H@H platform. At this point, it seems appropriate to use the Axiomatic Design optimization procedure, so that starting from system use cases a robust set of web services to be implemented could be defined. Both above-mentioned methodologies are combined in order to be applied in sequence. The first design phase, called "As is", represents the picture of the non-optimized process. Then, the application of the Axiomatic Design follows, which leads to the identification of an optimized set of web services (To be phase).

Process optimization
The proposed method led, also, the rethinking of the entire administration of the in-home medication regimen process; in this case, the definition of the H @ H platform constitutes an essential technological lever to allow the use of different services for patients [7,8]. This platform cannot only transmit web services of direct assistance to cancer patients, but can also support access to various socio-educational services.
SOA is an open type architectural protocol, which makes the system integrable and interoperable with a myriad of Web services already available or easily implemented. In this context, Axiomatic Design can play a dual roleInnanzitutto, può ridefinire le attività del processo di somministrazione di farmaci anche in termini di ottimizzazione snella [9][10][11][12][13]. Secondly, this operational definition is the premise for identifying the set of robust web services to be implemented.
The following paragraphs will emphasize the process of breaking down user requirements. Each level of functional decomposition allows, through a top-down logic, to first identify the web services to be offered to young patients, then the elementary actions of which they are composed. Finally, subsequent breakdowns may make it possible to construct the conceptual design of the system to be entrusted to the work of the developers.

Definitions
In this paper, we will refer to terms such as case study, case story and use case. A case study is a factual representation of what happened along with some analysis that provides insights and learning for the future [13]. In the social and life sciences, a case study is a research method involving in-depth and detailed examination of a subject of study (the case), as well as its related context conditions [13,14]. Whereas, a case story depicts what happened through people, place, and plot and brings emotional context into the portrayal of what happened. Finally, a use case is a list of actions or event steps typically defining the interactions between a role (known in -UML as an actor) and a system to achieve a goal [15]

Methodological approach
The proposed methodology is based on using the UML modeling techniques on Case Stories and on a process of axiomatic decomposition of functional requirements of the system [16]. The main purpose of the system analysis methodologies referring to the Use Cases aim to capture the system requirements to be implemented from the real world. Therefore, as a first step, Case Stories are built. They describe the system functioning from the involved useractor's point of view [8,17]. They are then combined, analyzed and translated into UML language-type Use Cases [18]. This level of formalization allows us to identify the interactions among the parties and to define an accurate sequence diagram. At this stage, it is already possible to identify web services for applying to the implementation or re-design. However, without a proper optimization process, the result would be highly related to the software designers' skill and experience [19,20]. For this reason, it is proposed to improve the UML modeling techniques, turning to a selection of web services to be implemented or re-designed on a quantitative basis [20,21]. In this sense, axiomatic design provides us with a powerful assessment tool, based on a solid theoretical basis, consisting of axioms and corollaries, easily applicable [22][23][24]. In fact, the relations among the different components of the system are reported in terms of design matrices. This allows us to keep trace of the decomposition operations and to attribute a measurement to different decompositions, but referable to the same level of detail.

Method of application of axiomatic selection
The application of axiomatic decomposition foresees a mapping process among four conceptual domains, i.e., customer functional, physical and process domains ( Figure  1). In this context, Case Stories represent the description in semi-formal language of the system behavior with respect to the requests of the various actors [15][16][17][18]. Therefore, in order to activate the axiomatic selection, we can consider Case Stories as customer attributes (CA) of the process. Hereinafter, the Use Cases are identified as high-level functional requirements (FR). Design parameters (DP) are created by designers. They correspond to the collaborations (interactions) among various Use Cases. In this way, firstlevel decomposition describes the network of interactions among Use Cases [16,20]. Finally, we can consider the process variables (PV) coinciding with the applications, which implement services to be selected (WS) [16]. They represent the implementation tools of the data communication system, described in a formal way through UML diagrams [24]. Axiomatic Design continues with successive decompositions of the selected web services up to a certain level of detail that allows their implementation by developpers. In the last stage of decomposition, the decomposed functional requirements are elementary functions, whereas the design variables (DP) are a data sets corresponding to the objects of upper level classes [24][25][26]. In the SOA architecture we can identify the Web services (WS) to be implemented based on the project matrix between functional requirements (FR) and design parameters (DP). In the case that we will present later, we will neglect the design of the implementation phase.

Project constraints
During the axiomatic decomposition phase of the FR it is necessary to consider the constraints of the project. We can distinguish two classes of limitations in the implementation of web services in a health care setting ( Figure 1). The first limitation concerns the regulatory restrictions related to the processing of health data. In fact, these data are classified as highly sensitive. Therefore, the legislature has established a set of strict rules to protect patient privacy, where noncompliance is a criminal offense. The second limitation concerns non-functional constraints. For example, medical equipment must be as compatible as possible with the SOA, as to limit the manual intervention of communication of health parameters to the management platform. Figure 2 schematically illustrates the modalities of application of AD.

Home administration of drug infusion in pediatric oncology
The case study under review is about the optimization process of drug infusion dispensing. To this end, a number of interviews have been carried out with the healthcare workers at Gaslini Hospital in Genoa, parents, patients and other actors. The actors involved are stylized in the general scenario of the process of Figure 2 with the little man icon.
This interview allowed us to identify the primary and recurrent activities for this process. These activities can be summarized in the following synthetic semiformal description (High-level Case Story)  Checking for drug availability (locker state, nonautomated);  Change of therapy;  Change of modality;  Change of drug;  Prescription of drug by the hospital doctor;  Withdrawal of drug at the hospital pharmacy;  Administration of drug by parents or healthcare professional (nurse, doctor); Practically, administration of drug is activated by the management device. At this point, the system detects that the drug is about to end and sends the alert to the control center.
The control center contacts the hospital doctor who prescribes the medicine administered by the hospital pharmacy where the patient's parent goes to collect it. At the end of the process, the availability of the drug is updated.

Process re-design
Process re-design of drug infusion administration foresees the implementation of an IT centralized Platform (H@H Platform). The exchange of information among various involeved actors is carried out through web services in SOA architecture. Identifying the web services to be implemented consists in re-designing the whole administration process, considering the constraints and intrinsic features of the current process [9,10]. As a result, the first phase of the selection process has been characterized by a series of indepth interviews with the healthcare workers at Gaslini Hospital in Genoa, parents, patients and other actors. This activity allowed preparing a series of Case Stories, which describe in a semi-structured way the state of the art of the completely pediatric home care process. Each Case Story represents a single portion of the entire process [17,8]. In this work, we tackle a twofold challenge. On the one hand, it is necessary to formalize the proposal for a non-optimized solution in terms of UML [18]. The second challenge regards the attempt to optimize the entire process based on an axiomatic approach [16]. This translates into the reengineering of the entire process [11,12]. In this context, the H@H platform becomes the focus of change. Axiomatic Design will allow to identify a robust set of web services to be conveyed through the platform.

General scenario of the process of prescribing and dispensing drug infusion
From the above-mentioned Case Story, it is possible to outline the general scenario of the process of home administration of drug infusion. This general scenario already represents a first solution for the re-engineering of the process. It foresees the introduction of the H@H Platform and the use of web services as a tool for information exchange. In terms of UML, Figure 2 illustrates the high-level design of the process. The represented actors and Use Cases are described in detail in section 3.3.2 hereafter.

Process Use Cases
In the diagram shown in Figure 2, the main Use Cases of the Case Story relating to the prescription and dispensing of drug infusion are highlighted. In addition, Use Cases describing the management of the device that dispensing the drug are reported. In particular, the Use Cases are the following: 1) Prescribe therapy or prescription of the drug therapy (dose and drug) made by the hospital doctor; 2) Dispense drug or the issue of the drug on the basis of the doctor's prescription. This activity is carried out by a pharmacy in a hospital or a territorial pharmacy depending on the type of drug; 3) Administer drug or administration of the drug by a medical device (for example, for drugs injected by continuous infusion) or by the patient's parents.
These three activities can include (extend) the update of the medical record managed by the H@H Platform. The specific activities on the device, on the other hand, are the following: 1) Check device functionality or the control of variables indicating the functioning of the medical device. A specific case of this Case is given by the analysis of malfunctions (Check device malfunction); 2) Check drug availability, describes a functionality of the Platform that verifies when the drug is about to end on the basis of consumption, and purchase of the drug itself; 3) Manage alert or management of the alerts on the basis of the functions mentioned at point 1 (malfunctioning, management of the drug, etc.). These alerts are primarily managed by the hospital service center, which sends an alert to the hospital doctor.

Representation of the general scenario in terms of interactions among Use Cases
The same Case Story allows us to identify the interactions (collaborations) that can be defined among various Use Cases [16,20]. At the level of general scenario such relations can be represented by the collaboration diagram reported in Figure 3.

Fig. 3 Collaboration diagram
In the following, we limit the analysis only to the simple process of prescribing and dispensing drug infusion. Alert Use Cases that are not dependent on the availability of the drug will not be treated. In this case, the boundary of the application is the set of Use Cases and relations indicated in blue color. The components shown in red color represent, instead, the management of other types of alert reporting.
They are mostly reports of technical malfunction of the administration devise of the drug infusion.

Matrix representation equivalent to the collaboration diagram
Based on the general scenario and the relevant collaboration diagram we can build the first-level design matrix. This matrix represents the series of actions that allow the execution of the whole process. This representation is obtained by considering Use Cases as fuctional requirements (FRs) [16,20]. As a consequence, they are inserted in order of activation according to the standard execution of the process on the matrix rows. In the columns of the design matrix, we consider as design parameters (DPs) the possible interactions (collaborations), which may exist among different Use Cases during the execution process. In particular, a collaboration between Use Case X and Use Case Y can be defined as the Use Case X method that enables any kind of processing in the Use Case Y. In other words, it can be said that the Use Case X interacts or cooperates on the Use Case Y only when it activates a method that causes Use Case Y to change its state. Therefore, Get () methods do not produce collaborations. In relation to the previous collaboration diagram there are the Following collaborations among first-level Use Cases ( Figure  4). As you can see, the design matrix associated with the current representation of the process state of the art does not comply with the axiom of independence [23]. The matrix is neither diagonal nor triangular. This means that the Use Cases are not independent from one another. Observing the previous collaboration diagram, we notice that the three identified critical situations correspond to the three cycles in Figure 3. This means that the axiom of independence ensures that there are no loops/cycles in the process, in which the information is likely to remain in a state of indeterminacy.

Use Cases re-definition
This situation leads us to the position to intervene to optimize the process. From the point of view of axiomatic design we can introduce three new Use Cases. In this way we would have a functional decoupling, which would lead to a lower triangular type of the design matrix, in order to determine a well-defined sequential path of actions. This intervention, in general, corresponds to transform a directed cyclic schema into a directed acyclic one, As is well known [27], a network of nodes and arcs is acyclic if an only if it possesses a topological ordering of its nodes. It means, whenever we assign a label to a node at an iteration, the node has only outgoing arcs and they all must necessarily point to nodes that will be assigned higher labels in subsequent iterations.
Consequently, this labeling gives a topological ordering of nodes. Provided that the nodes are labelled in ancestral order (parents come before children) a directed acyclic graph can be represented as a trinagular adjacency matrix. (traniangular superior). Note that, by labelling nodes in an opposite way, we obtain a trangular inferior matrix. A network that contains a directed cycle has no topological ordering, and conversely. For this reason, we introduce the following Use Cases:  Figure 5 represents the collaboration diagram of the process of prescribing and dispensing drug infusion. As we observe in this figure, there are no more cycles, and consequently, the process follows a well defined sequential path.

Applying the axiom of independence
The introduction of these three use cases allows us to redefine the first-level design matrix, as shown in Figure 6.

Fig.6 Optimized process design matrix
The new design matrix is of a lower triangular type. Therefore, at this level the process of prescribing and dispensing the drug infusion meets the indications of the axiom of independence. In fact, the process described in the Use Story represents a coherent sequence of activities.

Level assessment of the functional independence
Axiomatic Design also allows improving the degree of functional independence of the various Use Cases of the scenario. In this case, we will have to resort to the evaluation of the Reangularity of the matrix (R) [20,21]. For this purpose, we should first assume that the elements of the design matrix ( ), which represent interactions, have a value of 1. Vice versa we can pose the same elements ( ) equal to 0. This measure indicates how close a square matrix is to the corresponding unit matrix. R is a value between 0 and 1. Reangularity relates the angles between the axes of the design parameters, while semiangularity measures the magnitude of the diagonal elements [27][28][29] as follows: (1) The Reangularity index can be expressed as follows: (3) where represents the angle between columns vectors. The ideal uncoupled design ( ) is obtained by that is when axis are orthogonal. Otherwise, the design can be decoupled ( ) or coupled ( ).
Accordingly, in our case for R=1, the matrix is unitary, so all the Use Cases would be independent. This would be the ideal solution. In this case, the application of Eq. (1) gives us a reangularity value R=0,258345. This means that any other reconfiguration of the same design matrix, while respecting the independence axiom, must not have a value of R below this threshold.

Complexity vs. functional decoupling
The degree of reangularity could be improved by introducing a new Use Case, but in this case, we would have to deal with the axiom of information. In fact, the information content of the new representation of the design matrix should be at most equal to the one of the original design matrix. The axiom of information thus limits the degree of functional decoupling that may be introduced at the design phase. This axiom allows us to avoid that the new design configuration does not enhance the level of complexity of the system [23]. As regards information systems, it is convenient to estimate their size in terms of Function Points [30][31][32]. Function Points represent the functional point of view of the end-user. In addition, they also have the advantage of being a universally recognized measurement standard [32]. In this way, we can put the Function Point estimation deduced from the process optimized in the previous paragraphs, as an upper limit, with respect to any improvements in the degree of functional decoupling, which would result in an increase in the level of complexity of the system.

Decomposition Use Cases by zigzagging process
The detailed information, taken from the Case Story of the drug infusion administration process, allows us to identify the sequence of actions that trigger the execution of the process. These actions constitute the second-level functional requirements, or the decomposition of the corresponding Use Cases. At this point, the zigzagging process between the Functional Domain and the Physical Domain allows to associate, with each action of the sequence of execution of the process (FRij), a specific second-level interaction (DPij).

Second-level matrix representation FR-DP
The rules for generating the second-level FR-DP design matrix are the same as those followed in paragraph 3.3.4. In particular, as in the previous case, we can state that there is a collaboration from the Use Case X towards the Use Case Y, if there is a method related to the Use Case X that changes the status of the Use Case Y. In the same way, we can define the interactions among second-level activities, such as the behaviour of a given action that induces a processing towards another action. The greater detail of the second-level of decomposition allows us to identify the actions of the drug administration process. They correspond to the methods of the same Use Cases constituting the general scenario of the process. In a preliminary way, we identify the actions that generate first-level collaborations. This means selecting communication actions among Use Cases. They are shown in Figure 7.

Second level design matrix considerations
At this point, starting from Figure 6 and considering the collaborations among Use Cases shown in Figure 7, it is possible to build the second level FR-DP design matrix (Figure 9 attached). The Xs in Figure 9 can be interpreted in this way. The black Xs are internal elaborations to the specific Use Case. For this reason, they are graphically enclosed in a square. The red Xs are, instead, external to the squares that delimit the actions inside the individual Use Cases. They represent the methods that, starting from a specific Use Case, activate a process in another Use Case. These actions are performed using the methods shown in Figure 7. The description of the elements of the Figure 9 are attached in the summary matrix of Table 2.

3.6
Considerations around the axiomatic decomposition levels of the system

Stratification of functional decomposition levels
The axiomatic decomposition of functional requirements can be pushed up to a level of stratification such that the produced UML diagrams can be used to automatically produce the software. In fact, there are commercially suitable cases, which automatically generate software on the basis of particularly detailed UML diagrams [33]. Figure 8 illustrates the stratification of analysis levels. Each decomposition level reports the corresponding UML diagrams. However, the following question arises: is it advisable to proceed to a decomposition of elementary detail? The following paragraph presents reflections on this question.

The limits of an exaggerate stratification
Excessive stratification of axiomatic decomposition levels can lead to a paralysis of software deployment and upgrade activities [33]. Axiomatic Design methodology and UML modeling are designed for software development processes that follow either the cascading or the V model. These models are suitable for large, centrally driven software implementations, but are quite rigid for developing procedures with not particularly complex functionality in a web environment [34]. The most real risk is to allocate too many resources to the production of project documentation, which then the continuous system updates risk to make quickly obsolete. To avoid this, in recent years many software houses have preferred to use more efficient development techniques based on agile software development [33,34].

Agile software development
Agile software development is based on the close connection between developer and end-user with the prototype production of different versions of the software product. In this way, programmers focus on implementing a limited number of features, which they periodically show to the end user. If the prototype passes the customer's tests, further functionalities are implemented. Otherwise, the end user's comments are noted down and the software is updated. This methodology allows for a participatory implementation between the service provider and the customer. In addition, the basic versions of the procedure can be brought into production immediately, and the missing functionalities can be put into production for subsequent releases [33]. As you can see, this methodology is particularly efficient in emergency situations, but the lack of a complete trace between the user specification and the technical solution adopted can lead to situations of annoying misunderstanding between programmer and end user [33]. In this case, there may be cases of publication of procedures that do not completely meet the user specifications, for which the client and supplier are blaming themselves for the causes of failure [34].

How to combine AD and UML design with agile software development techniques?
In order to avoid the situations described in paragraph 3.6.2 some authors [33,34] have proposed the use of UML modeling or Axiomatic Design, also, in the case of agile programming and web environment. In this case, the stratification of the axiomatic decomposition is limited to high levels of detail intended for the understanding of the final client. The diagrams produced will be simple sketches, shared by the end-user, with which the programmers will proceed in their work. Instead, the technical solutions to be adopted will remain the exclusive competence of the developers. In our case, this solution corresponds to using only the UML diagrams of the first two layers of Figure 9.
The adoption of this solution corresponds to limiting the application of Axiomatic Design to the levels of greater abstraction of the process of administration of infusion drug.
This allows us to keep the general requirements of the system under control, delegating to each actor the technological adaptation best suited to their own infrastructure. The H@H Platform continues to be the coordination center for all activities, updating and making available UML diagrams and XSDL diagrams on the information to be exchanged.

Selection approach
Mapping between the Physical Domain and the Process Domain leads us to the definition of the so-called web services matrix (WS). This matrix is mirroring the optimized design matrix, due to the interdomain zigzagging process [16]. It schematized the dependencies between the interactions with the previously defined Use Cases (Collaborations) and the web services to be implemented.
Interactions are the rows of the matrix, while WS are the columns. The Process Domain allows the designer to assign a specific mode of implementation to the functional requirements expressed as Use Cases. The zigzagging process is iterative. Therefore, the selection of an implementation intervention may require the reformulation of some functional requirements. This means that functional decomposition takes place simultaneously on two domains.
This separation between the functional requirements side represented by the mapping between the Functional domain and the Physical Domain and the implementation side represented by the relations between the Physical Domain and the Process Domain is particularly significant. In this way, functional requirements are decoupled from implementation solutions. This allows a dynamic approach to the management of the prescription and dispensing process of drug infusion to be pursued. In fact, the introduction of new therapies or new technological tools may also require a reconsideration of the functional requirements of the system. This mechanism allows to verify the existence of the same functional requirements in a constantly evolving context such as the health sector. Figure 10 summarizes this process of parallel double mapping and the contextual application of the axioms of independence and information.

Web services Identification
In our case the approach proposed in paragraph 3.7.1 can be simplified. The H @ H project was developed based on the SOA architecture. This means that Web services can be identified based on the project matrix of Figure 9 [16].This is equal saying that each web service is logically consistent, as the correlation matrix of Figure 9 respects the independence axiom. Moreover, respecting the information axiom means minimise the system complexity. The axiomatic decomposition has involved two levels only. These two levels have allowed us to identify the web services and the relevant methods (actions) to implement. They represent the conceptual scheme of the system, as illustrated by Table 2. Further levels of decomposition allow us, instead, to define the logical design of the system. In this case, every interaction becomes data file, while methods become elementary processing.

Conclusions
Home administration process of drug infusion in pediatric oncology has several issues of concern. First of all, the continuity in drug infusion administration must be ensured.
This means not only tracking medical devices, so to settle any cause malfunctions within a reasonable time, preventing weak patients, such as those having cancer from being damaged. It should also be considered that the process itself of drug dispense implicates various actors involved, also outside the treatment center of reference for the patient.
Therefore, web services to be implemented must allow the identification of the pharmacies nearest to the patient's home, verify and update the availability of the drug bags and manage the yields. The H@H Platform is an open-type. This type guarantees the interoperability with heterogenous systems, but also the possibility to extend services to provide the young patients with, as a psychological support or to integrate them with the social and school service of the area. In this sense, on the basis of Case Stories, we have shown that UMLmodeling methodology allows to design new services also on the basis of specific Use Cases. Then, through the Axiomatic design approach we verified the proposed projectual solutions, by identifying the robust set of web services to be implemented.