Axiomatic Selection of Health and Social Care Web Services on the Basis of Use Cases

Abstract

in recent years remote patient monitoring systems, which are conceived to monitor patient and store the recorded data, employ Service Oriented Architectures (SOA). In health care systems, if on the one hand the SOA features allow enriching the offer of services to patients and their families, on the other hand the problem arises of selecting the most appropriate set of web services for homogeneous groups of users or for each individual clinical case. In this paper, we propose a methodology based on the Axiomatic Design for the composition and selection of web services, which are based on the case stories studied, built using semi-structured interviews to different stakeholders involved in the care process. The proposed methodology detects in a systematic way all functional requirements by taking into account the different stakeholders involved in the process and their interactions. Thus, it identifies the interested actors for a specific health protocol, and consider all information to be exchanged and the Web Services to be implemented. The development of this methodology opens interesting scenarios even in areas not currently affected by such systems, such as health and safety at work for monitoring patients with chronic illnesses or for their work reintegration following acute clinical events. A specific case study is considered in order to illustrate the proposed approach.

Clinical risk evaluation of medical device software: an axiomatic design-based methodology

“…This mapping among different domains allows to associate the risk of malfunction occurring with a multi-dimensional perspective. However, at the same time, the mapping makes it possible to decouple the areas of application [9]. Thus, the solution to a precise problem can be sought in a specific area.…”

“…The application of axiomatic decomposition involves a mapping process among three conceptual domains of Figure 2 [9]. In this context, the operational specifications of the device constitute the customer attributes (CA) of the process.…”

“…They correspond to the collaborations (interactions) among various Use Cases. In this way, the first level decomposition describes the network of interactions among Use Cases [9,12]. This network of interactions is graphically represented by a design matrix.…”

“…It continues with successive decompositions of functionalities up to a level of detail that enables its implementation by developers. In the last stage of decomposition, the decomposed functional requirements (FR) are elementary functions, while the design parameters (DP) are data sets, corresponding to the objects of the upper classes [9][10][11][12]. Instead, the project variables (PV) are codes, algorithms, subroutines, machine codes, compilers to accomplish the DPs [10,11].…”

“…This matrix is built by placing the use cases along the lines of a square matrix. The corresponding columns show the reciprocal collaborations or interactions [9,12]. At this point, we assume the following condition: a collaboration is only possible if the case of use indicated in the column of the matrix activates any event, which changes the status of the case of use indicated in the corresponding row.…”