Usability of Software Architecture Design Pattern in Medical Process Re-engineering Model

International Journal of Application or Innovation in Engineering & Management (IJAIEM)

Web Site: www.ijaiem.org Email: editor@ijaiem.org, editorijaiem@gmail.com

Volume 2, Issue 6, June 2013 ISSN 2319 - 4847

Usability of Software Architecture Design Pattern in Medical Process Re-engineering Model

UMESH BANODHA

1

and KANAK SAXENA

2

Department of Computer Applications

Samrat Ashok Technological Institute

Vidisha (M.P.), INDIA

A BSTRACT

This paper describes various aspects of the architecture styles and design patterns on Medical process re-engineering model.

The paper uses the service oriented architecture (SOA) style that provides the communication between various medical process reengineering components. It also focuses on the usability of various design patterns in medical process reengineering model.

The main contribution of this paper is to show the architecture of individual design patterns to be implemented with the proper usage in order to increase the reengineering among components. The architecture of individual design patterns show design area where indicated design is implemented. This paper used five design pattern namely Façade, Mediator, Proxy, observer and

Visitor, among which proxy design pattern uses 80% of reengineering component followed by Façade which is of 78% in medical process reengineering which is merge with the SOA style. The proper usages of design patterns will increases percentage of the reengineering among components which describe the design of each component. As a result of the combination of architecture style and design patterns increases the percentage of reengineering among components.

Keywords: Components, Service oriented architecture style, Medical process re-engineering, Design Patterns.

1.

I NTRODUCTION

1.1. Medical Process modeling approach

Medical process is defined as the art of healing, i.e., a gradual process of medicine tending to cure. It is a method that helps to understand the actions, work flow, and tasks of an organization, and how the tasks are executed. Process modeling captures the process flow and the actors in the process with the actions performed. The focus in process modeling is on the functional processes which are entities that start with an initial event and end with a result. A process has always an input and an output, input triggers the process and process results in an output [5, 6].

The process consists of four steps (Figure1) in the highest abstraction level. Each of the steps and the relations between them are depicted in more detail in Figure 2. Process begins when the patient arrives to the reception of a hospital/clinic to meet doctor /staff as an initial event. It ends when the patient is discharged as a result. The actor of the processes is a doctor with support unless mentioned otherwise [1, 7].

Figure 1 Process Modeling Approach

Volume 2, Issue 6, June 2013

Figure 2 Detailed steps of modeling approach

Page 329




1.2.

Medical process re-engineering (MPR) model

A medical process is “a set of logically related tasks performed to achieve a defined outcome”, as shown in figure 3.

The model defines six activities: [2]

Figure 3 A MPR Model

Medical Definition: Medical Goals are identified within the context of the promotion and maintenance of health, saving and extending of life. This can be done in the context of cost reduction, time reduction, quality improvement, personnel development, and empowerment. Goals may be defined at the initial level or for a specific stage of the medical process.

Process Identification: Processes that are critical to achieve the goals defined in medical definition are identified. They may then be prioritized by importance, need for change, or in any other way that is more appropriate for the reengineering activity in view of MPR.

Process Evaluation: The existing process is thoroughly analyzed and measured. Process tasks that are identified are evaluated in terms of the costs, times consumed by process tasks and quality/performance problems are isolated.

Process specification and design: Based on information obtained during the first three MPR activities, use cases are prepared for each process which contains the specification of the process, a new set of tasks, which are obtained from medical design control. The Medical design control includes project verification & validation plans, creation of input

&design output documents, requirements specification with descriptions and many more.

Prototyping: A redesigned medical process must be prototyped before it is fully integrated into the medical domain.

This activity “tests” the processes so that refinements can be made with precision and time. The tests covers validation and verification at the following levels – planning, system level, Mechanical, electrical process validation and field or/and clinical level.

Refinement and instantiation: Based on feedback from the prototype, the medical process is refined and then instantiated within a medical system.

Domain Engineering: The outcomes possible in form of specific development, embedded system, electro-mechanical systems, critical system design technique for safety, reliability &compliance, fault free analysis, failure mode effects analysis, risk analysis of all considerable factors, reliability analysis, decision making/design, trade-off analysis, engineering tool & product selection, design for standards & regulatory compliance.[3, 8]

1.3.

Architecture Styles

The software architecture discipline is centered on the idea of reducing complexity through abstraction which tries to reduce, factor out details so that the user/programmer can focus on few concepts at time and separation of concerns that are synonymous with feature of behaviors which results in the least possibilities of the features that overlap in functionality.

An architectural style is a set of principles, one can use to build a system typically it, depends on the era to be focus. An architectural style improves partitioning and promotes design reuse by providing solutions to frequently recurring problems. More specifically, an architectural style determines the vocabulary of components and connectors of that can be used in instances of certain style, together with a set of constraints on how they can be combined or include topological constraints on architectural descriptions (e.g., no cycles). Other constraints are having to do with execution semantics, might also be part of the style definition.” The major benefit of Architecture style is that they provide a way to have a conversation between the technology agnostics with common Language. This allows us to facilitate a higher level of conversation that is inclusive of patterns and principles, without getting into the specification. There are many

Volume 2, Issue 6, June 2013 Page 330



Volume 2, Issue 6, June 2013 ISSN 2319 - 4847 architectural styles as pipe and filter, data centric, client server etc. among which we use the SOA which express the relationships between requesters, providers, services, descriptions, and discovery services in the case where agents take on both requester and provider roles [9]. The service requester sends a message in the form of a request for information, or to perform an operation, and receives a message from the service provider that contains the result of the request or operation. The service provider receives the request, processed the message, and sends a response [18]. The detail of

SOA is described in section 2.1.

1.4.

Design Patterns

The idea behind software design patterns originated from the field of architecture and the work of Christopher

Alexander. In a simple language it is ‘a reusable solution to a problem in a particular context. Design patterns are focus of prose that capture software designers’ experience and record successful solutions to recurring design problems in a form that may be applied again by designer when they encounter similar situations. They describe the problem with solution, when to apply and the consequences of the solution.

A Software design pattern provides us a general solution to a common problem in software design. It is a description or template for how to solve a problem. Patterns provide us reusable solutions to commonly encountered programming challenges [10]. This helps us speed up the Design and overall Development Time and Effort thereby resulting in cost savings. The various kind of design patterns which are used in MPR are as follows.

Mediator: Medical sections/component where complex interactions occur among various active medical elements

(medical employee or other) of Medical Reengineering Model i.e. increasing dependencies.

Façade: Medical structure is highly coupled elements (component/elements) interaction where the patients needs frequent interaction with internal elements/component.

Visitor: In medical process where there is a need for special services that are implemented differently for each and every patient in question in the component (sections), and where the service provider (medical department) should have the knowledge of how to provide a specific service to in question patients.

Proxy: There a situation where there is service providers that receive many request and for some reason (secure information of patient, efficiency, etc) cannot or should not respond to the requests directly.

Observer: There is a need for monitoring changes in order to ensure consistency, improvement, and future enhancement or to enforce certain protocols in structures [14].

2.

M ODELING

System modeling is a technique to express, visualize analyze and transform the architecture of a MPR. It is used to ensure that a developing process model evolves in a consistent manner and that use task of integrating the process components is simplified in this paper to model the MPR. We use the SOA to include the possibility to describe constraints on the relationships others focus on different connections between components

2.1 Service-oriented architecture style

The static part of the architectural style [11, 16], which involves three different types of elements: Medical elements

(Definition), messages (communication), and specification documents (Reports). These three groups are organized into individual packages. The figure 4 explains an integrated overview of all three packages. The Medical elements like

Medical Definition and Medical Services (Tests/Medication/Future check-up) are mandatory required for the static model. In our case, a Medical Definition can play different Roles at the each iteration of Medical process reengineering, i.e., a Service Provider(Medical Labs/Hospitals) can require the communication with Patients and vice versa. The Diagnosis Agency is considered as subclass of Medical Labs/Hospitals because it provides services dedicated especially to publishing (subscribes) and querying the service specifications. A Service Requestor (Patients: require for medical recovery) interacts with Medical Services via a particular Session instance i.e. medical re-engineering process.

This session contains the information about the present state of the interaction for each patient since it is possible that different patients interact with the same medical service simultaneously. Hence, the session represents the actual connection between patients and a service i.e. medical process steps. [12]

A medical process re-engineering needs to initiate a reconfiguration usually has to communicate this to other affected medical components, we also provide the necessary types of messages: The Query message is used when searching the diagnosis agency for Doctors/ Expert Knowledge Banks, and the Documents to specialist doctor and Discharge the patient messages are used for the creation and cancellation of a session.

We also include representations of Reports in the static model. They are necessary to describe reconfiguration operations in which a medical process dynamically searched at run-time and bound to certain requirements. There are




Volume 2, Issue 6, June 2013 ISSN 2319 - 4847 two types of Reports: Requirements (Future medication /enhancement) and serviceSpecifications (Doctors / Expert

Knowledge Banks), which both contain a set of Properties. In the case of a Future medication /enhancement, these properties are required by a patient for the tests/medication and future check-up. In the case of a Doctors / Expert

Knowledge Banks describing a particular tests/medication, these properties are guaranteed by the Medical Lab /

Hospitals with certain assumptions. [4, 13, 18]

Figure 4 Service-oriented architecture style

2.1.1 Analysis

The study of the service-oriented architecture style has been implemented on 1000 data records of General patients are taken from various resources. The table1.1 shows that the Percentages of Re-Engineering The service-oriented architecture style provides communication between various medical components. There are various types of services considered in medical process reengineering and find out the Percentages of Re-Engineering Component use in serviceoriented architecture style. The Graph 1.1 shown that the service requester, session, request, specific documents, & requirements are the highest (12%) communicated reengineered components in the service-oriented architecture style.

The Graph shown that the Diagnosis agencies & Service specification are second highest (9%) communicated reengineered components. The Graph also shown that services and query have (6%) communicated reengineered components and service provider & top level management have (4%) communicated reengineered components. While

Patient Discharge has only 2% communicated reengineered components [17, 18]

Table 1.1

Re-engineering component of SOA

Types of Services Percentages of Re-Engineering Component

(Based on 1000 data records of patients in general )

Service requester (Patients) 12

Session (Consulting to Doctor) 12

Services (Tests/ Medication) 6

Service Provider (Hospital)

Diagnosis Agencies

Request (Specialist Doctors)

Component (top level management)

Specific Documents (Reports)

Requirements(Future medication/enhancement)

4

9

12

4

12

12

Service Specification (Expert knowledge Bank ) 9

Query( Patients further problems)

Patient Discharge

6

2





14

12

Representation of Service Oriented Architecture service requester

(Patients)

Session (Consulting to Doctor)

Services (Tests/

Medication)

Service Provider

(Hospital)

Diagnosis Agencies 10

8

6

4

2

Request (Specialist

Doctors)

Component (top level management)

Specific Documents

(Reports) requirements(Future medication/enhance ment) service Specif ication

(Expert know ledge

Bank )

Query( Patients further problems)

Patient Discharge

0

Services

Graph 1.1

Re-engineering component of SOA

2.2 Design Pattern Model

In this section we study the impact of a combination of an Architecture style and Design patterns of medical process model. For this we are considering the service oriented architecture style and their communication reengineering components. Other side we are considering the all design patterns which are mentioned in section 1.3. First, we study the combination of individual design pattern and SOA. At the last we study the impact of combination of all design pattern and SOA [15].

Proxy Design Pattern

For proxy design pattern we analyze the services where the proxy design pattern are used or the combination of services where the proxy design pattern is used. The table 1.2 show that percentages of Re-Engineering Component of Proxy design patterns used in SOA.

Table 1.2

Re-Engineering Component of Proxy design patterns used in SOA

Service oriented style used in Proxy Design patterns

Percentages of Re-Engineering

Component used in Proxy design patterns service requester 12

Sessions 12

Services

Diagnosis Agencies

6

9

Specific Documents requirements service Specification

Query

12

12

9

6

Patient Discharge 2

The Graph 1.2 show that the following services where the implementation of proxy design patterns occurs. The Graph show that the Service requester, services, specific documents, Requirements are the services where the percentage of reengineering proxy patterns is highly reengineered. While the percentage of reengineering proxy patterns used in rest of services

According to their percentage is as follows Diagnosis agencies, service specification, services, query, and patient discharge.

service requester

SOA used in Proxy Patterns

6

4

2

0

14

12

10

8

Sessions

Services

Diagnosis Agencies

Specific Documents requirements service Specification

Query services of styles used in proxy patterns

Patient Discharge

Graph 1.2

Service oriented style used in Proxy Pattern





Façade Design Pattern

For Facade design pattern we analyze the services where the Facade design pattern are used or the combination of services where the Facade design pattern is used. The table 1.3 show that percentages of Re-Engineering Component of

Facade design pattern used in SOA.

Table 1.3

Re-Engineering Component of Facade design patterns used in SOA service oriented style used in Facade design patterns service requester

Session

Services

Diagnosis Agencies

Percentages of Re-Engineering Component used in Facade design patterns

12

12

6

9

Request

Specific Documents service Specification

Query

12

12

9

6

The Graph 1.3 show that the following services where the implementation of Facade design pattern occurs. The Graph show that the Service requester, session, Request, specific documents are the services where the percentage of reengineering Facade patterns is highly reengineered. While the percentage of reengineering Facade patterns used in rest of services according to their percentage are as follows Diagnosis agencies, service specification, services, query.

SOA used in Facade design pattern

14

12

10

8

6

4

2 service requester

Session

Services

Diagnosis Agencies

Request


Query

0 percentage of Reengineering used in Facade

Graph 1.3

Service oriented style used in Facade Pattern

Observer Design Pattern

For observer design pattern we analyze the services where the observer design pattern are used or the combination of services where the observer design pattern is used. The table 1.4 show that percentages of Re-Engineering Component of observer design pattern used in SOA.

Table 1.4

Re-Engineering Component of observer design patterns used in SOA

The Graph 1.4 show that the following services where the implementation of observer design pattern occurs. The

Graph shows that the Service provider and the component (top-level management) are the services where the percentage of reengineering observer patterns is equally reengineered.

SOA used in observer Pattern

5

4

3

2

1

0

Service Provider

Component

Percentage of Reengineering used in observer

Graph 1.4

Service oriented style used in observer Pattern





Visitor Design Pattern

For Visitor design pattern we analyze the services where the Visitor design pattern are used or the combination of services where the Visitor design pattern is used. The table 1.5 show that percentages of Re-Engineering Component of

Visitor design pattern used in SOA.

Table 1.5

Re-Engineering Component of Visitor design patterns used in SOA

Service oriented style used in Visitor design patterns


Component used in Visitor design patterns

Sessions 12

Services

Request


6

12

12

9

Query 6

The Graph 1.5 show that the following services where the implementation of Visitor design pattern occurs. The Graph show that the Session, Request, specific documents are the services where the percentage of reengineering Visitor patterns is highly reengineered. While the percentage of reengineering Visitor patterns used in rest of services according to their percentage are as follows Service specification, services and query.

SOA used in Visitor pattern

14

12

10

8

6

4

Sessions

Services

Request


Query

2

0

Percentage of Reengineering used in visitor

Graph 1.5

Service oriented style used in Visitor Pattern

Mediator Design Pattern

For Mediator design pattern we analyze the services where the Mediator design pattern are used or the combination of services where the Mediator design pattern is used. The table 1.6 show that percentages of Re-Engineering Component of Mediator design pattern used in SOA.

Table 1.6

Re-Engineering Component of Mediator design patterns used in SOA service oriented style used in

Mediator design patterns


Component used in Mediator design patterns

Services

Service Provider

Patient Discharge

Volume 2, Issue 6, June 2013

6

4

2

Page 335




The Graph 1.6 show that the following services where the implementation of Mediator design pattern occurs. The

Graph show that the percentage of reengineering Visitor patterns used in services according to their percentage is as follows Services, Service provider, Patient discharge.

SOA used in Mediator pattern

7

6

5

4

3

2

Services

Service Provider

Patient Discharge

1

0

Percentage of Reengineering used in Mediator

Graph 1.6 Service oriented style used in Mediator Pattern

2.3 Service Oriented Architecture style used in various Design Pattern

After study of individual design pattern used in service oriented architecture style, we interested to study the impact of combination of all design pattern used in service oriented architecture styles. For this we took the aggregate percentage of all reengineering components of individual design pattern used in service oriented architecture style. The table1.7 show that the overall percentage of services used in various design patterns

The Graph 1.7 shows that the Services of medical process reengineering of service oriented architecture style used in various design pattern. The Graph shows that the services of Façade, Proxy design patterns are the highly reengineering in service oriented architecture style. The graph shows that the services of visitor design patterns is the just below the highly reengineering in service oriented architecture style. Finally the services of mediator and observer design pattern are very low reengineering in service oriented architecture style. The result is based on 1000 data records of patients in general taken from various resources. The results may be varying if records are changed/modifies. If the

Detailed steps of modeling approach are changed then result may be also changed

Table 1.7

Re-Engineering Component of Various design patterns used in Service oriented style

Design Patterns used in Medical Percentage of SOA used in Various reengineering Model design patterns

Façade 78

Mediator

Proxy

Visitor

Observer

12

80

57

8

SOA used in various design patterns

90

80

70

60

50

40

30

20

10

0

Percentage of

SOA used in

Various design patterns

Façade Mediator Proxy

Design Patterns

Visitor Observer

Graph 1.7

Service oriented Architecture style used in various design Pattern





3.

F UTURE WORK AND L IMITATION

This work is on experimenting different software architecture concepts with the impact of reengineering ideas; to express rules, constraints and control mechanisms in the medical domain. The medical process reengineering model in richer as to architectural feature are more intelligible to domain experts and end users and lend themselves better to the application of styles and patterns in the later phases of development.

One major impediment to our work was the lack of appropriate documentation of early design decision in favor of medical process reengineering model. This work deals only with the styles and design patterns with limitations.

Though this work is in infant stage only but it gives the comparison with declaration of the result. The testing is drawn on the only on the 1000 data sets of general patients albeit a very large one where as it can be extended to various nature of patients data set.

The analysis identifies the situation that gave rise to the reengineering concepts with the styles and patterns. The work can be extended with the future phases of development. The work is experimented only on the medical data collected from the single sources, but practically the data belongs to different source of same patients which creates the ambiguity as well as the inconsistency. This work can be further enhanced with the above limitation and also can be extended to the concept of data correlated with the significant difference.

Thus, in future the work need a more objective assessment of the lost/ benefit ratio of events, need more guidance in the decision making when to add/ remove an event from reengineering code and lastly develop systematic procedures and tool support for the removes inappropriate events from the medical process reengineering models.

4.

C ONCLUSIONS

The paper deals with the analysis of model with the impact of architecture styles and design patterns based on 1000 records (data sets) of general patients. It also emphasize on the factors and events where the impact of reengineering is high at low. It results in arrival/first time assessment of the patient, planning the care, Treatment and evaluation of patient and Discharge Referral or Follow-ups of patient among the all phases, the planning the care is require high impact of reengineering over the other three phase of architectural style. Similarly among five design pattern like

Façade, mediator, observer, proxy and visitor the proxy design pattern is highly used in medical process reengineering.

System modelling methods to be used with the reengineering of large systems cannot be found “off the shelf”, but have to be adapted to suit the specific heads of reengineering.

References

[1.] P. Nykanen and J. Makinem, “Integration of medication information in electronics patient record systems”, The dementia patient case. Turku School of economics, Research report LTH-1:2007, Turku, 2007.

[2.] “An inventory of the certification criteria for electronic patient records”, Eurorec organization, Brussels, 2006, www.eurorec.org.

[3.] Binder, R., “Design for reuse is for real, American Programmer”, vol.6, no.8, August 1993, 30-37.

[4.] Lim, W. C., “Effects of Reuse on Quality, Productivity and Economics”, IEEE Software, Sept.1994, 23-30.

[5.] Wang, ”Modelling information architecture for the organization. Information and Management” 32, 6, 1997, pp.

303-315.

[6.] R. Weber, “Conceptual modeling and ontology: Possibilities and pitfalls”, Journal of Database Management,14, 2,

2003, pp. 1-20.

[7.] Makinen,J. Et.Al., ”Process Models of medication Information”, Procd. Of the 42 nd

Hawaii International Conf. on

System sciences 2009, 1-7.

[8.] Clark, L.A., et. Al., “Using software Engineering Technology to improve the quality of Medical Processes”,

ICSE’08,May, 10-18, Germany.

[9.] M. Champion, C. Ferris, E. Newcomer, and D. Orchard. “Web Service Architecture”, W3C Working Draft, 2002. http://www.w3.org/TR/2002/WD-ws-arch-20021114

[10.] Hamed Yaghoubi Shahir, Ehsan Kouroshfar, Raman Ramsin, “Using Design Patterns for Refactoring Real-World

Models”, 35th Euromicro Conference on Software Engineering and Advanced Applications, 2009, pp 436-441.

[11.] Object Management Group. “UML specification version”,1.4,2001 http://www.omg.org/uml/.

[12.] Luciano Baresi, et.al.,”Modeling and Analysis of Architectural Styles Based on Graph Transformation”, 2003, 6 th

ICSE workshop on component base software engineering automated reasoning and prediction, Portland, 67-72.

[13.] P. Bottoni, A. Sch¨urr, and G. Taentzer. “Efficient Parsing of Visual Languages based on Critical Pair Analysis and Contextual Layered Graph Transformation”, In Proc. IEEE Symposium on Visual Languages, September

2000. Long version available as technical report SI-2000-06, University of Rom.





[14.] U.Banodha , K.saxena, “Impact of Design Patterns for Medical Process Re-engineering”, International journal of

Applied Engineering Research, Vol. 6, No.5 April 2011, 866-870.

[15.] U.Banodha , K.saxena, “Impact of Pipe and Filter Style on Medical Process Re-engineering”, International Journal of Engineering Sciences, October 2011

[16.] U.Banodha, K.saxena, “A Software Architecture Styles for Medical process Re-engineering”, World Congress on

Engineering and Computer Science (WCECS), IAENG, San Francisco, USA, October 2011

[17.] D. Varr´o.”Towards symbolic analysis of visual modeling languages”,In Paolo Bottoni and Mark Minas, editors,

Proc. GT-VMT 2002: International Workshop on Graph Transformation and Visual Modelling Techniques, volume 72 of ENTCS, . Elsevier , Barcelona, Spain, October 11-12 2002,. pages 57–70.

[18.] U.Banodha , K.saxena, “Comparison of Software Architectures Styles in Medical Process re-engineering Model”,

International Journal of Wisdom Based Computing (IJWBC), Vol. 2(1), April 2012, pp42-46.

AUTHORS

KANAK SAXENA , Ph. D. in computer Science from the Devi Ahilya University, Indore, INDIA. She is professor in the Computer Applications Department at the Samrat Ashok Technological Institute affiliated to Rajiv Gandhi Technical University, Bhopal. Her Current research focuses on Database Systems, Parallel computing, Data Uncertainty and design and other interests include Network security and performance and

Software Engineering. She is the member of editorial board of various international journals. She is the member of the international committee of the International Conference on Computer Science and Its Applications. She

Published more than 75 research Papers in Various Conferences and Journals National / International).

UMESH BANODHA , Assistant Professor at Samrat Ashok Technological Institute, VIDISHA (M.P.), an

Autonomous Institute, affiliated to Rajiv Gandhi Technical University, Bhopal. I did MCA, M.Tech

(Honors) and Pursuing Ph.D. My Area of interest Software Engineering / Architecture, Databases, UML, object oriented, Programming Languages etc. I am member of various international / National journals. I published number of research papers in various conferences and journals (National / International).


Usability of Software Architecture Design Pattern in Medical Process Re-engineering Model

Usability of Software Architecture Design Pattern in Medical Process Re-engineering Model

UMESH BANODHA

and KANAK SAXENA

Related documents

Products

Support

Usability of Software Architecture Design Pattern in Medical Process Re-engineering Model

Usability of Software Architecture Design Pattern in Medical Process Re-engineering Model

UMESH BANODHA

and KANAK SAXENA

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib