Traceability Management Framework for Patient Data

Traceability Management Framework for Patient Data in Healthcare Environment * * ' * S. M. AQIL BURNEY HUSSAIN SALEEM NADEEM MAHMOOD TAHSEEN A. JILANI [email protected],

[email protected] , [email protected], [email protected] " Department of Computer Science (UBIT) University of Karachi Karachi, Pakistan paramedics etc. but no unified functional system currently exist for the exchange of comprehensive healthcare information across the wide spectrum of healthcare networks. Regional health information organizations (RHIOs) and national health information network (NHIN) have been proposed as vital building blocks in providing such a system, but these face many challenges, including delineation and implementation of accepted standards for healthcare data, accurate patient identification and record matching, and the definition of incentives for accelerated deployment of health information technology [5]. In this research we have worked on the approach of implementation of patient data management model (PDMM) and mechanism of access to data using traceability management with temporal or non-temporal change control. In order to improve the access mechanism, we have proposed a framework for better traceability management of patient data and services offered in the hospital along with other functional requirements. With the introduction in this section, the paper is organized as follows: In section II, a discussion on configuration management and traceability relationship is presented along with patient data management workflow of requirement analysis. Requirement traceability approach using patient database schema and traceability model is discussed in section III. In section IV, explanation for classifying inter-relationships for better traceability is discussed. In section V, a proposed framework for patient data management integrated with traceability model that identify and realize trace relationships is explained. The conclusion and future work is mentioned in section VI.

Abstract--Change management or configuration management is becoming necessity for every facet of software system development. Traceability of objects i.e. artifacts or information units becomes core talent for authentic determination of the parametric information over the explicit instance of time. This paper presents the evolving and useful concept of traceability management wrapped in change management paradigm that provides perception for requirement analysis phase. We have analyzed the patient data requirements workflow model with respect to the traceability management process. We have proposed a new approach for better traceability of patient data management model (PDMM) for identification and realization of trace relationships within requirements (lRTRR) in healthcare environment. We have named the model as PDMM-IRTRR framework. The key activities represented in the proposed framework are also highlighted. Keywords-configuration; traceability; requirements; leT; software; management; healthcare; information system;

I.

INTRODUCTION

The concept and approach of traceability in change management is now becoming vigorous area of research in the field of software engineering. Generation of various information units is also an important activity to maintain and produce high quality information system software. These information units are generated continuously by means of access via query system throughout the lifetime of software. These are highly inter-related so that the effect of change imparts subsequent or concurrent changes on all relevant dependencies, since the access mechanism and the development procedures become more and more iterative and interdependent for an improved and authentic information product outcome. We have focused on healthcare system. Healthcare systems that deal with the patient care and services are very complex in nature. These systems require traceability management due to the changing nature of the problem e.g. the patient's parametric information dependency for which cure is to be suggested may vary with respect to time. The best practice is to provide right treatment to the right patient at the right time. Failing in doing so e.g. in case of emergency becomes hazardous to the patient's life. For this purpose, the utmost important thing is to develop the patient management system. The patient relevant information could be available at real time using information and communication technology (lCT). Fortunately, there is strong expertise of healthcare, ICT, hospitals, clinics and

II. A.

DISCUSSION

Configuration Management & Traceability Relation

Configuration or change management (CM) is a life-time movement which is useful when functional to the whole life­ cycle of the system. The software configuration management (SCM) strategy is supported through SCM tools. SCM identifies, controls, audits, and reports status accounting & modifications that usually occur throughout the process of any software being developed and/or after it has been released for use. The whole parametric information generated or created as measurement of software engineering becomes artifact or a unit (of information) of a software configuration. SCM is structured in a way that facilitates systematic management of change [15].

978-1-4244-5540-9/10/$26.00 ©2010 IEEE 264

The configuration is composed of set of interconnected and interrelated objects known as software configuration items (SCIs) 1 being produced as a result of software engineering activity. In addition to data, programs, and documents; the development environment that is used to create software system can also be placed under configuration control. All SCIs are accumulated in a repository that employ mechanisms and data structures to guarantee data integrity and integration support for other tools. This also maintains updated information sharing among all concern stakeholders, and gear back and forth functions in support of version and change control [I5]. A configuration object after development and review, tum out to be a baseline object. These objects when modified or changed, transformed into the version of that object. The advancement of a program, file or document can be tracked by examining the revision history of all configuration objects. Basic and composite objects form an object pool from which versions and variants are created. Version control is the set of procedures and tools for managing the use of these objects. Change control is a procedural action that ensures quality and consistency, as changes are made to a configuration object. The change control process begins with a change request, leads to a decision to make or reject the request, and finish off with a controlled update of the SCI that is approved for change. The configuration audit is also a software quality assurance (SQA) activity ensuring that quality is maintained whether change actions are in progress or ended. Status reporting about each change, handover information to those with a need to know [I5]. Software configuration management is not an independent activity. The whole association of SCM thoroughly depends on traceability or trace dependency. In general and also in the context of the requirements engineering, traceability theory could be defined rigorously. The comprehensiveness of the information concerning to every step in a progression over any instance of time is referred to as traceability. This is the skill to chronologically correlate distinctively identifiable entities in a verifiable manner that verifies the history and/or location by means of recorded identification. Traceability of requirements for a software project is a common concept, that when used, can offer considerable benefits [13]. Reference [18] defined the term "requirements traceability" as an explicit tracing of requirements to other requirements, models, test requirements, and other traceability items such as design and user documentation. It is also defined by [6] as the ability to describe and follow the life of a requirement, in both a forward and backward direction. This leads to the general defmition of traceability, which would be defmed as the concept of "a connection" among information units.

The conceptual development and observation of traces in static and dynamic change scenario can be sketched encompassing healthcare system. It is required to implement the patient data management model (PDMM) with the element of traceability management. A requirement analysis work flow for patient data management (PDM) in healthcare is proposed by [2]. The implementation of PDMM requirement analysis work flow includes the integration of ontological knowledge-base explicitly linked with the existing information system. This requires the creation and mapping of ontological categories for trace purpose, based on the information stored in database system containing all relevant patient information. The details of the ontology in healthcare system can be referred through [14]. The changes or modifications could be static or dynamic specifically called temporal2 and non-temporal. Temporal aspect is significantly important in our approach for change control which is quite complex and hard to achieve manually. However it is very helpful in analyzing and understanding hypothetical or missing information/records. Fig. I gives a work flow of PDMM by highlighting and categorizing the important and critical patient information in a typical healthcare environment which helps to maintain patient record and cure history.

f-Ent +-RegiserstratHospi ion Carta At Pf ----, Takes ASSIgned appomtment

� b IN :

admi�t ed

1

Patie�N'1 nt'sDatRegia stration EMPLOYEE

ent DatPataibase

C� Medicine

Patient Data Patient

Figure I. Requirement Analysis: Workflow Model for Patient Data Management (PDMM) [2]

The purpose of this model is to analyze the importance of patient's data to improve healthcare organization'S services and functions. The data and the associations are classified as temporal and non temporal data items. The

B. Requirement Analysis: Work Flow for Patient Data

Management in Healthcare Environment 1

OUT

Intercepted bY��

2

SCI is also called artifact, information unit or traceability item

265

Temporal means time based

treatment data is represented with a clock in the model, showing the fact that the treatment data is temporal in nature. Treatment may have variation with the passage of time and an up-to-date version of record must be maintained in order to retrieve that data when required. Time stamping in PDMM is one of the most important parameter for traceability management in this process. The data concerning to the doctors, looking after the patients, and the paramedical staff, busy in performing duties in the wards needed to be stored in the database or repository. Patient's admission, stay, shifting, and/or leaving information is also needed to be stored. These relationships are also temporal relationships. The model depicts the workflow, information flow, functions and services in a typical healthcare environment. It also indicate technical setup showing workstations, and data flow in circuit connected to the patient database and servers, with the objective to incorporate those features which best suit to information accessibility. The access mechanism of various parametric information units of the PDMM along with traceability vigilance and change control is clarified in the next section. III.

Working Pntctice (Sufficirnl r"fl:oun:rs. time&suJlPort) (Ongoingeoopel'1ltioll

anti coordination)

Ofwhltl (information)

1

_M

Traceability

_M

t

In what way (acensto&prtscntalion ofinformllfion)

Ability to organize and mllintain

rtquircd

II1I('cabilil�' rcquirC'lIlcnlll inrormalionrornl;'.tiblr

ofrnd-IIStnl

End-user perspective

Figure 2.

System perspective

Traceability ontology according to end-user and system perspective

Two significant forms of RT are (i) Pre-RS 3 and (ii) Post-RS traceability. Fig. 3 explains this concept with traceability phenomena. Pre-RS traceability refers to those aspects of requirements life prior to inclusion in the RS, and Post-RS traceability refers to those aspects of requirements life that result from inclusion in the RS. Various techniques have been proposed to cater the problem but much of the work has been done in the Post-RS traceability [6]. The research focus is on implementation of the methodology of access and retrieval of temporal information at any workstation present in PDMM scheme. It is usually difficult to find traces of some evident parameters according to the schema of Patient Database of various HIMS4 since the information units are either missing or get corrupted, then are hypothetically re-created with the help of interrelationships that exist inherently in the repository of software i.e. HIMS. Table 1 show the schema with some evident parameters for which units of information is generated. The traceability phenomenon is usually left at the early phase. It is rationale that there exist inherent relationships among various information units. Such relationship can be identified as Post-RS. The requirements are then traced from, and back to, a baseline (RS) through a succession of units in which they are distributed. Changes to the baseline are needed to be re-propagated through this succession [6].

ApPROACH

This is quite important to visualize the traceability phenomena and significance of traceability management, as to identify the stakeholders who wish to obtain the time varying information through information software. In traceability phenomena, according to the end-user perspective, traceability "of what item i.e. information unit" and "traceability in what way i.e. access and presentation of information" depends on "the user ... who wants it", "the task that is needed to be carried out" with "why" and "when" information, and upon the "project/query characteristics". Similarly according to the system perspective, traceability depends on "working practices of resources, time, support and ongoing cooperation & coordination", "the awareness of information required to be traceable", "the ability to obtain and document required information" and "the ability to organize and maintain required information for flexible traceability requirements of end-users for supporting change, or restructuring". Fig. 2 describe the traceability ontology well with the above two perspectives [6]. In the domain of traceability management, the significance of requirement traceability (RT) has grown over the years, as development procedures became more iterative and interdependent [7]. According to RT: "A software requirement specification is traceable if (i) the origin of each of its requirements is clear and if (ii) it facilitates the referencing of all requirements in future development [8].

Pre·RS Traceability

IRTRR

Post·RS Traceability HIMSSelup

C

1-+-0

· · · ·

HIMS - PDMM Interface ,------------,

Figure 3.

3

4

266

Traceability phenomena

RS means requirements specification HIMS: Hospital Information Management System

TABLE 1.

PATIENT DATA MANAGEMENT MODEL (PDMM) SCHEMA [2]

PATIENT:

DOCTOR:

{Doctor_id,

(a)

([)

D_name,Department,Type,

Pager,Cell} IN:

OUT: WARD:

(b)

Date_time, Activation_start,Activation_end,Update_time, ConsultinLdoctor} {PJeg_Do, Ward_Do, Bed_DO,

{PJeILDo,

Figure 4.

Date_time, Consulting_doctor}

{Ward_Do, Activation_start, Staff,

{Ward_Do, ActivatioD_start,

Doctor_id,

Activation_end,Update_time} BED: STAFF: EMPLOYEE :

TREATMENT :

{Bed_Do, Ward_Do, {ID,

V.

Type}

{Emp_Do, E_address,E_contact,E_Type, Hire_Date,Birth_Date,Designation, Salary} {TreatmeDt_Do, Patient_id, Doctor_id,

Treatment_date, Provisional_diagnosis,Remarks, Test_Reports_required,Next_visit, Activation_end,Update_time}

-� '

(e)

(e)

Scenario mapping of Patient Database schema and types of relationships [16]

PROPOSED MODEL: PDMM-IRTRR FRAMEWORK

PDMM

IRTRR

�m ·. -��

-..

The Pre-RS phase compnses of mformal methods of data extraction and creation of new information units, and thus makes it very difficult to fmd relationships. Fig. 3 can be referred for further clarity. As a solution, a Traceability framework is proposed by [16] to furnish this problem. It works as a post RS activity to discover the hidden relationships. The framework is referred as "IRTRR, Identification and Realization of Trace Relationships within Requirements". Fig. 6 shows IRTRR framework. The detail is explained in section V. We have mapped IRTRR framework on PDMM. This framework can be integrated with various RT activities. It helps in generating traces more accurately, efficiently and at an earlier stage. IV.

(\ A,B)I

We have proposed the PDMM-IRTRR framework linked with traceability management as a connected backbone as shown in Fig. 5.

Duty_hours,Responsibility}

Activation_start,

(eI)

Fig. 4(a) represents the disjoint but inter-linked relationship. Fig. 4(b) represents partially overlapped, Fig. 4(c) represents transitively connected relationship, Fi�. 4(d) represents part-of (inscribed-circumscribed) relatIOnship and Fig. 4(e) represents the relationship of approximately equal-to [16].

Ward_name,Activation_end,Update_time} WARDDOCTOR:

0 , , (, ,

0--8

{ReILDo, P_name,P_address,P_contact, Gender,Age,Date_oCBirth}

-=

-

Figure 5.

The PDMM-IRTRR Framework

There are two main distributions of the PDMM-IRTRR framework. PDMM is described earlier in section II (B). IRTRR has two main stages: (1) the Identification of trace relationships and (2) the Realization of trace relationships. The identification stage performs (i) analysis of traces named here as "Analyze" and (ii) finding associations of traces named "Associate". The realization stage (iii) Classify and (iv) Filter, the traces [16]. The IRTRR framework is shown in Fig. 6. This framework depicts an activity to be performed immediately after the requirement specification phase. The identification part, is concerned with the discovery of the hidden traces of information units, whereas the realization part involves the validity and comprehension of traces generated in the identification part. Both these parts are equally important to identify and realize the trace relationships that exist inherently. The four process stages of RS Phase in IRTRR model are briefly explained below.

CLASSIFYING INTERRELATIONSHIPS FOR BETTER TRACEABILITY

To analyze and develop traces of PDMM, it is necessary to build up a better comprehension of the various types of interrelationships that can exist. The classification presented here is taken from the set theory concept and mapped to PDMM paradigm. For ease of understanding, we have taken three scenarios; A, B and C as sets comprising of schema parameters as mentioned in Table 1. Fig. 4 presents the scenario mapping of patient database schema and some possible types of relationships.

267

, The IRTRR proces, REAUZATION

I DENTI FICAnON

RT Process

-

VI.

RS Phase

W N >..J

II) co

e

II.

« Z «

Figure 6.

, r--

r--

r--

W I-

>-

r----

'--

comply the techniques in developing traces of information units more efficiently and quickly.

« U 0 Ul Ul

r---

«

'--

... --

iii Ul « ..J u

'--

0:: w I..J

u:

-

From this research, we reached to a point that there is an emergent need of improved and comprehensively accessible mechanism of patient's distributed Data Bank that provide dynamic, authentic and complete patient's instant history. Traceability management is needed and useful as catalyst. We have introduced some of traceability techniques. We are working on other enhanced methods such as dynamic traceability using Petri-nets modeling. Our research group is currently working on the implementation of such techniques using SCM and traceability tools for medical assistant software to facilitate improved medical services for patients and other stakeholders in the hospital setting.

r-

..

II) co 0 II.

'--

Requirement Traceability Process and The IRTRR Framework [16]

This stage involves the detailed study and analysis of the requirement. As a result of this activity the requirements are to be broken down into atomic product functions. The output of this activity is a set of product functions that are atomic and cannot be further broken down. Any representation can be used to represent this set such as a list, but if a logical grouping is applied and the requirements are arranged in a hierarchical structure, then this structure helps to develop associations among the various levels of requirements. B. Associate: The association or mutual linkage of atomic information units is determined at this stage. The association can be based on set theory as represented in Fig. 5. Techniques of RT can be applied to find these relationships such as "matrix sequences" [I], "RT matrices" [3], "keyphrase dependencies" [10] and "hypertext" [11] etc. Any appropriate representation can be chosen, such as by using a meta-language or generating a dependency graph to depict the relationships. C. Classify: The relationships generated as a result need to be reorganized according to the product functions from which the relationships are generated. This is imperative to figure out the overall system and to develop a global outlook of the relationships that are present in the system. More than one parameter can be used to classify the relationships. D. Filter: The output of this stage is a set of filtered relationships among the requirements that are found from the RS.

A.

CONCLUSION AND FUTURE WORK

Analyze:

[I] [2]

[3] [4] [5] [6] [7] [8] [9] [10]

[II] [12]

[13] [14]

[15]

The identification and realization process must be executed iteratively. This can further be extended with other interim techniques for traceability management such as "cross referencing" [4], "templates" [9] "integration documents" [12], "assumption-based truth maintenance networks" and "constraint networks" [17] etc. in addition to the techniques discussed in section V(B). The framework

[16] [17] [18]

268

REFERENCES Brown PG, "QFD: Echoing the voice of the customer", AT & T Technical Journal, pp.21-31, MarchiApril 1991. Burney A, Mahmood N, & Ahsan K, "TempR-PDM: A conceptual temporal relational model for managing patient data", In Proc. of 9th WSEAS IntI. Conf. on AI, Knowledge Engineering and Data Bases (AlKED'IO),Cambridge,UK,February 20-22,pp. 237-243,2010. Davis AM, "Software requirements: analysis and specification", Prentice-Hall,Inc.,1990. Evans MW, "The software factory: A fourth generation software engineering environment",JW & Sons,1989. Gold JD & Ball MJ, "The health record banking imperative: A conceptual model",IBM Systems Journal,Vol. 46,No. 1,2007. Gotel OCZ & Finkelstein ACW, "An analysis of the requirements traceability problem", Proc. 1st IEEE Int. Conf. on Requirements Engineering,pp.94-102,Colorado Springs,April 1994. lEE, "Tools and techniques for maintaining traceability during design", IEE Colloquium, Computing and Control Division, Professional Group CI,Digest No. 19911180,1991. IEEE Standard 830-1998, "IEEE recommended practice for software requirements specifications",IEEE,New York,1998. Interactive Development Environments, "Software through pictures: Products and services overview",IDE Inc.,1991. Jackson J, "A keyphrase based traceability scheme", In IEE Colloquium on Tools and Techniques for Maintaining Traceability During Design,Computing and Control Division,Professional Group CI,Digest No. 19911180,pp.2-1-2/4,1991. Kaindle H, "The missing link in requirements engineering", ACM SIGSOFT Software Engineering Notes, Vol. 18, No.2, pp.30-39, 1993. Lefering M, "An incremental integration tool between requirements engineering and programming in the large", Proc. IEEE IntI. Symposium on Requirements Engineering,San Diego, California, pp 82-89,Jan 4-6,1993. Leon M, "Staying on track", Intelligent Enterprise, pp.54-57, September 2000. Payne VL & Metzler DP, "Hospital Care Watch (HCW): An ontology and rule-based intelligent patient management assistant", Proc. of 18th IEEE Symposium on Computer-Based Medical Systems (CBMS'05),2005. Pressman RS, "Software engineering: A practitioner'S approach", McGraw-Hili,7th Edition,2010. Saleem H & Zaidi FA, "Identification and realization of trace relationships within requirements", In Proc. of IntI. Conf. on Software Engineering (ICSE'06),Lahore,Pakistan,14-15 April 2006. Smithers T, Tang MX, & Tomes N, "The maintenance of design history in ai-based design", In IEE Colloquium, Computing and Control Division,Professional Group CI,Digest No. 19911180, 1991. Spence I, & Probasco L, "Traceability studies for managing requirements with use cases",Rational Software Corporation,1998.