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: [email protected], [email protected] Volume 2, Issue 6, June 2013 ISSN 2319 - 4847
Usability of Software Architecture Design Pattern in Medical Process Re-engineering Model

UMESH BANODHA1 and KANAK SAXENA2
Department of Computer Applications Samrat Ashok Technological Institute Vidisha (M.P.), INDIA
ABSTRACT
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 Faade, Mediator, Proxy, observer and Visitor, among which proxy design pattern uses 80% of reengineering component followed by Faade 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. INTRODUCTION
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
Figure 2 Detailed steps of modeling approach
Volume 2, Issue 6, June 2013
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
Page 330

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. Faade: 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. MODELING
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
Page 331

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 ) 12 12 6 4 9 12 4 12 12 9 6 2
Service requester (Patients) Session (Consulting to Doctor) Services (Tests/ Medication) Service Provider (Hospital) Diagnosis Agencies Request (Specialist Doctors) Component (top level management) Specific Documents (Reports) Requirements(Future medication/enhancement) Service Specification (Expert knowledge Bank ) Query( Patients further problems) Patient Discharge
Page 332

Representation of Service Oriented Architecture
service requester (Patients) Session (Consulting to Doctor) Services (Tests/ Medication) Service Provider (Hospital) Diagnosis Agencies
14
Percentage of Re-Engineering Component
12 10 8 6 4 2 0
Services
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
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 Percentages of Re-Engineering patterns Component used in Proxy design patterns service requester Sessions Services Diagnosis Agencies Specific Documents requirements service Specification Query Patient Discharge 12 12 6 9 12 12 9 6 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.
SOA used in Proxy Patterns
Percentage of Re-engineering used in proxy
service requester Sessions
14 12 10 8 6 4 2 0 requirements service Specification Query Services Diagnosis Agencies Specific Documents
services of styles used in proxy patterns
Patient Discharge
Graph 1.2 Service oriented style used in Proxy Pattern
Page 333

Faade 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 Percentages of Re-Engineering Component design patterns used in Facade design patterns service requester Session Services Diagnosis Agencies Request Specific Documents service Specification Query 12 12 6 9 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
Services of style used in Facade
12 10 8 6 4 2 0 percentage of Reengineering used in Facade
service requester Session Services Diagnosis Agencies Request Specific Documents service Specification Query
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
services of styles used in observer pattern
5 4 Service Provider 3 2 1 0 Percentage of Reengineering used in observer Component
Graph 1.4 Service oriented style used in observer Pattern
Page 334

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 Percentages of Re-Engineering design patterns Component used in Visitor design patterns Sessions Services Request Specific Documents service Specification Query 12 6 12 12 9 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
services of style used in visitor
12 10 8 6 4 2 0 Percentage of Reengineering used in visitor
Sessions Services Request Specific Documents service Specification Query
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 Percentages of Re-Engineering Component used in Mediator design patterns 6 4 2
Services Service Provider Patient Discharge
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
services of style used in Mediator pattern
6 5 4 3 2 1 0 Percentage of Reengineering used in Mediator Services Service Provider Patient Discharge
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 Faade, 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 Faade 78 Mediator 12 Proxy 80 Visitor 57 Observer 8
SOA used in various design patterns

90 80 70 60 50 40 30 20 10 0 Faade Mediator Proxy Design Patterns Visitor Observer
Percentage of SOA used in Various design patterns
Percentage of SOA used in Various design patterns
Graph 1.7 Service oriented Architecture style used in various design Pattern
Page 336

3. FUTURE WORK AND LIMITATION

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. CONCLUSIONS
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 Faade, 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 42nd 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, ICSE08,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, 6th ICSE workshop on component base software engineering automated reasoning and prediction, Portland, 67-72. [13.] P. Bottoni, A. Schurr, 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.
Page 337

[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. Varro.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 5770. [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).
Page 338

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

Uploaded by

Copyright:

Available Formats

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

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

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

Uploaded by

Copyright:

Available Formats

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