chapter 3: research methodology - um...

Chapter 3: Research Methodology

67

3.1 KEY METHODOLOGICAL APPROACHES

In this thesis, a number of methodology tasks were carried out before concluding the

significance of this research. Due to the complex nature and heterogeneous of EMR

systems and smartcard technology, methodological rigidity remains a disputable goal by

itself. A practical approach has been necessary, to be able to carry out the studies whilst

respecting the obligations of participating medical practitioners and other health personnel.

To compensate for the lack of exact control of the research environment, I have chosen to

maximize the approaches to allow for a broad methodological approach. The principal

methods are initially described in this section, followed by a review of the individual

methods in the subsequent sections.

The key methodological approaches in this research can be summarized as:

1. Background study on the research topic

There was tremendous time spent on the background study to get a thorough

understanding of research area. These studies were aimed to identifying

problem statements and the objectives of the research area. This was important

to gather an in-depth foundation of the research.

2. Literature searches on the relevant components, systems and technologies

involved

The current research involves two key components to be reviewed, the EMR

systems and smartcard technology. A review of relevant literature in these two

68

components was essential to understand the past researches and works done in

the research area and to understand the technical aspects of both components.

3. Non-participatory observations of selected systems and technological

components.

Some limitations found in the research scope restricted from conducting an

extensive observations on the existing systems. Due to the lack of observation

sites for EMR implementations in Malaysia, this research focuses on non-

participatory observation to identify EMR practices and smartcard modeling

techniques to the systems.

4. Prototype development and Testing

Based on the findings from above approaches, a prototype application was

developed as part of the outcome of this research. Testing was carried out on the

prototype to validate the claims of this research topic that smartcard technology

can be implemented to secure medical records on EMR systems.

Based on these key methodologies, further approaches were taken to:

1. Develop Software Modeling Technique

2. Requirement Capturing and Modeling & Analysis

3. Test and validate precision of the result.

4. Conclude the current research and recommend for future enhancement.

69

Figure 3.1 summarizes all methodological tasks carried out in this research.

Figure 3.1: Methodology Approaches of this research

Most of the findings on the first two approaches, background study and review of literature,

were presented in details in Chapter 1 and Chapter 2 respectively. In this chapter, a detailed

description of various methodological studies on smartcard technology and EMR software

development is presented.

Identify Problem Statements and

Objectives

Review relevant literature

Review technical aspects of EMR

and Smartcard Technology

Identify EMR Practices &

Implementation Models

Identify Modeling Technique for

EMR Smartcard

Develop Software Modeling

Technique

Requirement Capturing and

Modeling & Analysis

Develop, Test and Validate

precision of the result

Conclude the research and

Recommend future enhancement

70

3.2 IDENTIFY THE MODELING TECHNIQUE FOR EMR SMARTCARD

Another major methodological study involved in this research is to identify modeling

techniques for EMR smartcard and how they are implemented in the development part. In

this section File Base Modeling technique for structuring and storing of the medical data

and Security Modeling technique for encrypting the records are presented in detail.

3.2.1 FILE BASE MODELING TECHNIQUE

A File-Base Modeling technique refers to implementation of smartcard memory mapping

to a Windows operating system like file-folder architecture. This section describes the

commands defined in ISO/IEC 7816-4 related to File System API. Refer to Appendix A for

further findings on ISO/IEC 7816-4. Figure 3.2 illustrates the supported commands classes

of File System API, Security API and other Industrial-Specific APIs.

The commands identified for this research will be presented in each definition section.

Depending on the size of record created (Lc) or expected (Le) and data value, the Lc, Le,

Data blocks are varies in command values.

• (XX*) indicates the value for this field depending on the byte command for the

individual record

• (-*) indicates the field is not applicable for this command

• (XX..XX*) indicates number of bytes need to be sent.

71

Figure 3.2: File Base Modeling Sample for Smartcard

3.2.1.1 Select File

This command establishes a logical pointer to a particular file in the smartcard's file

system. This pointer is required for any file manipulation operations.

72

Command Implemented

00 A4 00 00 XX* -* -*

CLA INS P1 P2 Lc Data Le

3.2.1.2 Read Binary

This command is used by the application on the reader side to retrieve a part of an EF on

the card. However, the EF must be a transparent file (not record-oriented). If the Read

Binary command is attempted on a record-oriented EF, the command will abort with an

error indicator being returned from the card.

The Read Binary command takes two parameters: an offset pointer from the start of the

file to the initial byte to be read, and the number of bytes to be read and returned to the

reader.

Command Implemented

00 B0 00 00 -* -* XX*


Header Body

Header Body

73

3.2.1.3 Write Binary

This command is used to insert data into a transparent EF on the card. This command can

be used to set a series of bytes in the EF (i.e. set selected bits within a specified byte to a

value of 1), clear a series of bytes or perform a write of a series of bytes in the EF.

Command Implemented

00 B0 00 00 -* -* XX*


3.2.1.4 Update Binary

A reader-side application can utilize this command to directly erase and store a contiguous

sequence of bytes in a transparent EF on the card. It effectively functions as a write

command i.e. a string of bytes provided in the command are written into the EF on the card.

The input parameters consist of an offset pointer from the start of the file as well as the

number of bytes to be written.

Command Implemented

00 D0 XX* XX* XX* XX..XX* -*


Header Body

Header Body

74

3.2.1.5 Erase Binary

The Erase Binary command is used to clear bytes within a transparent EF on a card.

Similarly to the previous commands, the input parameters comprise an offset from the start

of the EF to the segment of bytes to be erased as well as the number of bytes to be erased.

Command Implemented

80 0E 00 00 00 -* -*


3.2.1.6 Read Record

This command is used to read and return the contents of one or more records in an EF on a

card. Unlike the previous command, the EF for the Read Record command must be a

record-oriented file. If it is applied to a transparent EF, the command will abort and an error

will be returned to the reader.

The following may be returned from this command, depending on the input parameters:

• A specified record

• All the records from the beginning of the file to a specific record

• All the records from a specific record to the end of the file

Header Body

75

Command Implemented

00 B2 XX* XX* -* -* XX*


3.2.1.7 Write Record

This command is used to write a record into a record-oriented EF. As with the Write

Binary command, this command can be used to write a record into an EF, set or clear

specific bits within a specific record in an EF. Some addressing shortcuts to specify the

record to be written to include the first or last record in an EF, the next or previous record

in an EF or a specific record within an EF identified by a number.

Command Implemented

00 DC XX* XX* XX* XX..XX* -*


3.2.1.8 Append Record

The Append Record command is used to add a record to the end of a linear, record-

oriented EF or to write the first record to a cyclic, record-oriented EF on a card.

Header Body

Header Body

76

Command Implemented

00 E2 00 XX* XX* XX..XX* -*


3.2.1.9 Update Record

This command writes a specific record into a record-oriented EF on a card. As with the

Update Binary command, the old record is erased and the new one is written into the EF.

Command Implemented

00 DC XX* XX* XX* XX..XX* -*


3.2.2 SECURITY API MODELING TECHNIQUE

This section describes the commands and techniques defined in ISO/IEC 7816-4 related to

Security API. The commands implemented for this research will be presented in each

definition section. Depending on the size of record created (Lc) or expected (Le) and data

value, the Lc, Le, Data blocks are varies in command values.

Header Body

Header Body

77

• (XX*) indicates the value for this field depending on the byte command for the

individual record

• (-*) indicates the field is not applicable for this command

• (XX..XX*) indicates number of bytes need to be sent.

3.2.2.1 Verify and Change PIN

This command is to verify and change PIN. If the PIN verification is successful, the

security state register will be set equal to the security state of this PIN. At the same time the

old PIN will be replaced by the new PIN. The attempts error counter will be initialized to

maximum tries. If the PIN verification is not successful, the PIN cannot be changed and the

remaining attempt count will decrease by 1. Data field consist of old PIN (8bytes) and new

PIN (8bytes).

Command Implemented

80 24 00 XX* 10 XX..XX* -*


Header Body

78

3.2.2.2 Internal Authentication

This command allows the authentication of the card by the external world. It allows the

external device to present the challenge code so that the card can make use of similar

authentication key inside the card to compute and return the result for the terminal to

authenticate it.

Command Implemented

00 88 00 XX* XX* XX..XX* -*


3.2.2.3 External Authentication

This command allows the authentication of the external world by the card.

Command Implemented

00 82 00 00 08 XX..XX* -*


Header Body

Header Body

79

3.2.2.4 Get Challenge

This command is for the external device to request a challenge code from the card. The

challenge code will be used during secure messaging and external authentication. Once

challenge code is generated, it will be valid unless the power to the card is terminated or

another Get Challenge command is executed. After receiving this command, card will send

the Le bytes of challenge code to the card terminal. If the next command is external

authentication, then card will decrypt the data received using the external authentication

key and compare the result with the challenge code.

Command Implemented

00 84 00 00 -* -* XX*


3.2.2.5 Get Response

Get Response command is to request the card to return the data in response to previous

command.

Command Implemented

00 C0 00 00 -* -* XX*


Header Body

Header Body

80

3.2.3 DATA ENCRYPTION TECHNIQUE

In this section, the implementation of encryption standard on EMR Smartcard will be

presented. The selected smartcard for this implementation supports triple – Data Encryption

Standard (3DES) algorithm for encryption and decryption of the patient’s medical data.

3DES is a well-known industrial standard encryption algorithm which was originally

derived from single DES. Most smartcards support 3DES as common encryption standard

although theoretically it has been attacked before. Thus the 4-Level security architecture

will enhance the overall security standard of the card and the data.

The implementation method of 3DES in EMR Smartcard is illustrated in Figure 3.3

Figure 3.3 A 3DES Encryption/Decryption Procedure

81

3.2.4 MEMORY MAPPING TECHNIQUE

The key task of implementing any smartcard application is to create the memory mapping

of the card. Memory mapping is a technique in smartcard application development where

the entire applications memory structure is being presented logically. APDU commands in

File System, as described in the earlier section, when executed on a smartcard will create

the memory allocations. The APDU’s arrangement in application environment will

determine how well the card’s memory will be mapped.

3.2.4.1 File Organization in EMR Smartcard

EMR Smartcard is a 16KB microprocessor card. Through memory mapping and execution

of APDU command, the file system on the card can be organized in Windows-like folder

architecture. Using this architecture format, a root directory like “C:\” will be created on

the card prior to create any other folder or files. “C:\” will be mapped as “MF” or master

file. Similar to Windows folder structure, smartcards only allow on root directory to be

created on its memory. Access to the underneath folders or files will need authentication

from MF whether to allow or disallow any further read/write operation. Upon creation of

MF, other files or folders can be created with proper internal authentication.

MF can have any number of Definition Files or DFs. DFs are like folders that contain

Elementary Files (EFs). The limit to the number of files is depends on the size of the

memory and memory allocation for each file. Typically smartcards can hold data for

multiple applications. In EMR Smartcard implementation, DFs are created for store

different type of data, based on the application needs. DFs for Patient’s Personal

Information, Allergies, Emergency Information, and Previous Medical History were

82

created to store relevant information on individual files under each folder. DFs also will be

protected in this EMR Smartcard implementation. DF security keys are stored in EF1

directly under MF. This will allow MF to authenticate each DFs using the valid key as and

when required.

Upon creation of DFs, EFs for each type of data were created. Patient’s Personal

Information will contain EFs for Patient’s Name, NRIC No, Registration No, Address, and

Contact Numbers and so on, depending on the application or healthcare providers need. DF

for Emergency Information will contain Patient’s Blood Group, Next-of-Kin Name,

Address, Contact Numbers and etc.

The detailed file organization for EMR Smartcard is illustrated in Table 3.1.

Table 3.1 File Organization for EMR Smartcard

File type Folder Type (DF) Record Field (EF) Record Size

MF Security Key File 100

DF1 Patient Personal Information Patient Name 100

NRIC No 12

Registration No 20

Address 200

Contact No 30

DF2 Emergency Next-of-Kin 100

Address 200

Contact No 30

Blood Group 5

DF3 Allergies Allergy Info-1 100

Allergy Info-2 100

Allergy Info-3 100

Allergy Info-4 100

DF4 Previous History Previous History Info-1 100

Previous History Info-2 100



83

MF can also contain EF directly under the root directory. Access to EFs directly under MF,

is protected using the security options that MF contains. In EMR Smartcard, EF1 created to

keep SecretKeys for other folder.

In this file organization, 1597 bytes have been used from the total of 16384 bytes card,

which is only a 10 percent (10%) utilization. Upon execution of related APDU commands

and the defined file organization, EMR Smartcard will be formatted as illustration in Figure

3.4.

Figure 3.4 Memory Mapping of EMR Smartcard

84

3.2.4.2 Security of EMR Smartcard File Organization

MasterFile (MF) is created with a SecretKey1 embedded to it. Any access to the card

memory will require verification of the SecretKey1 at MF. Upon verification of

SecretKey1, the permission will be granted to access the DFs underneath. Again, based on

the security key setting, the access to the DFs will require authentication of respective

SecretKey.

To access patients personal data, the user application at System Level, will require

submitting SecretKey2. Upon successful authentication the application will be permitted to

read the content of ElementaryFiles (EF) created under EMR DF1.

With similar read and write operations, or commonly referred as “Encoding” and

“Decoding” respectively, by sending APDU commands, the entire card memory mapping

will be created. Medical practitioners with the use of Secure Access Module in Smartcard-

Level can get authentication to access the card to update their patient’s medical record.

3.3 SOFTWARE DEVELOPMENT METHODOLOGY

It is important to select a correct development methodology as it helps to produce a better

quality product, in terms of documentation standards, acceptability to the user,

maintainability and consistency of software. In object oriented development, an iterative

cycle of development is both necessary and desirable (Bennett et al., 2002). The object

oriented methodology selected for this project is Unified Software Development Process

85

(USDP). This methodology combines features of Objectory, Object Modeling Technique

and Booch Method which were three of the leading object oriented methodologies of the

1990s (Bennett et al., 2002). The next section gives a summary on Unified Software

Development Process.

3.3.1 OBJECTORY

The objector process divides the development cycle into four phases which are inception,

elaboration, construction and transition phase. In the inception phase the scope of the

project is determined. The user requirements in the form of use case will be determined in

this phase. In the elaboration phase the architectural planning for the system is done. Risk

management for the project is conducted in this phase. The construction of the system is

done in an iterative cycle until the product is complete. The system is then passed to the

community in the transition phase for the acceptability of the system. When the objectives

of the project are met then the development cycle ends. Objectory method supports

component development method because of its iterative phase and focus on small

component development. The components are developed in small scale and tested. Then it

progresses to the larger component. The disadvantage of this approach is that the iterative

cycle takes up more time (Jacobson, 2002).

3.3.2 OBJECT MODELLING TECHNIQUE

Object modeling technique (OMT) developed by Rumbough is a software development

methodology that concentrates more on analysis and design phase. In the analysis phase,

the problem statement is developed into three views. The three views are object model,

86

dynamic model and functional model. Object model represents the static representation of

the system for example classes and associations. The dynamic model, on the other hand,

represents the state transition model typically capturing the changes in the states of objects.

Finally the functional model handles the flow of data. In the analysis phase, the

architectural base for the system is established. Processes are organized into subsystems

and corresponding flows and task are allocated accordingly. The final phase is the object

design phase where the algorithm is for the object and classes identified. This methodology

gives minimal consideration to the implementation and testing phase. The phases identified

are executed in a sequence. In each phase, the processes and steps can be iterated to achieve

the objective. (Burback, 1998)

3.3.3 BOOCH METHOD

Similar to OMT, Booch method concentrates more on the analysis and design phase rather

than the implementation and testing. There are two divisions on the analysis phase which is

the customer requirement analysis, and the second is the domain analysis. In the domain

analysis, the classes, attributes and objects are established. In the design phase, the

architecture is developed. The logic design will be mapped to the physical design.

Prototype is developed and tested in an iterative manner.

3.3.4 UNIFIED SOFTWARE DEVELOPMENT PROCESS (USDP)

The unified software development process is an iterative and incremental software

development framework. It is a combination of the three different object oriented modeling

methodologies (Wikipedia, 2007).

87

The underlying principle of this methodology is almost similar to the waterfall model. In

the waterfall model, there are seven sequential phases; feasibility study, requirement

analysis, analysis and design, implementation, testing and maintenance. The disciplines

stated in the USDP are similar to the phases in the traditional waterfall life cycle. The

traditional life cycle is adopted within the four identified phases which are inception,

elaboration, construction and transition. These phases reflect the different emphasis on

tasks that are necessary in systems development process workflow. It further defines a

series of activities that are to be carried out as part of the workflow and specifies the roles

of the people who will carry out those activities. The important fact to bear is that, in the

waterfall lifecycle activities, the phases are one and the same. In iterative lifecycle like the

USDP, the activities are independent of the phases and it is a mix of the activities that

change as the project proceeds (Bennett, 2002). Figure 4.2 illustrates how USDP phases

and workflows are combined. In this figure, the workflows are defined as disciplines.

Figure 3.5: Unified Process disciplines and phases (Schlegel, 2002)

88

In Figure 3.5, the disciplines are the workflows similar to the waterfall lifecycle model. The

diagram illustrates the emphasis of different disciplines across the phases. Each iteration

results in an increment which is a release of the system which contains improved

functionality compared to the previous release. (Wikipedia, 2007)

The unified process is divided into four phases. The smallest phase is the inception phase.

In the inception phase, the objectives of the system are outlined. The use cases are

established and the project milestones are set. In the elaboration phase, the requirements set

in the initial phase are validated according to the scope. The architecture of the system is

also outlined in this phase. The construction phase is the largest phase. Each iteration

results in a new release of the software. The final phase is the transition phase where the

system will be exposed to the users for testing. The advantage of this methodology is that it

tries to eliminate high risk in the early phase of the project.

Table 3.2 outlines the activities aligned with the phases identified in the unified software

development process.

Table 3.2: Activities and Deliverables for the phases in USDP

Phase Activity Deliverables

Inception Requirement Capture and Modeling

Requirement List

Use case model

Elaboration Requirement Analysis Analysis Model

System Design Architecture Diagram

Class Design Design Models

Interface Design Design Models with interface design

Construction Construction Developed system

Transition Testing Tested system

Implementation Installed system

89

Each activity has its deliverables. In this research, the development process will be

explained in terms of the activities in each phase.

3.4 REQUIREMENT CAPTURING AND MODELING

The core part of any software development is to find out what is the exact requirement by

the user. Prior to this, the target users of the software need to be identified first. The target

users for this software are students and beginners in the modeling field. Therefore, the

development of the software functionality is developed according to their needs. End-user

requirements act as a limitation boundary for a system that help to direct the activities

towards what the end users needs and expects from the system. Failure to identify the

system requirements during the early days might result in the following problems:

� Changing requirements

� Ambiguous requirements

� Assumed requirement.

3.4.1 INITIAL REQUIREMENT

The following are initial requirements for this program. These requirements are the

common requirements for the commercial healthcare information systems. The validity and

feasibility study will be done on these requirements to derive the valid requirement for the

development of the tool. Further elaboration of this process is done in the next section.

90

REQ1: Supports User Authentication through Smartcard

REQ2: Supports Patient Registration

REQ3: Supports Medical Diagnostics

REQ4: Supports Drug Prescriptions

REQ5: Supports Effective Retrieval of Patient’s Medical History

REQ6: Supports Secure Encoding of Patient’s Medical Record into Smartcard

REQ7: Supports Management of User Profiles

REQ8: Supports Verification of system entries through Audit Trial

REQ9: Support Further Expansion.

3.4.1.1 DEFINING REQUIREMENT

Each initial requirement will be analyzed according to its feasibility and the constraints to

develop each component of the system. During the analyzing phase, certain requirements

might be ruled out and some might be considered valid as long it is according to the scope

of the system. The user requirements are analyzed to check if they are still valid within the

scope and can be completed within the time frame to meet the objectives of the system.

REQ1: Supports Secure User Authentication through Smartcard

User authentication to the system and data retrieval process needs to be secured at

higher level. On top of standard password control mechanism, a Security Access

Module (SAM) card should be used to secure the access to the system.


The system is required to provide a user interface to capture/enter patient’s

registration information. Patient’s name, NRIC number, address, next-of-kin, blood

type, allergies and other personal identifications are basic to create a patient record.

91

REQ3: Supports Medical Diagnostics

While receiving diagnostic or medical treatment from a healthcare practitioner, the

current medical diagnostic information needs to be captured. These information

include, type of treatment, diagnostic, or medical consultation.

REQ4: Supports Drug Prescriptions

A patient’s treatment record needs to be further elaborated in prescription record.

Type of drug or medication they received will be used for future references.

REQ5: Supports Effective Retrieval of Patient’s Medical History

The system also needs to be able to effectively retrieve a patient’s medical history

using the Patient Registration ID. The medical history includes which health

institution the patient went to, when did the patient went, who treated or diagnosed

them, what prescription they received and other related information are to be

retrieved from patient’s card.

REQ6: Supports Secure Encoding of Patient’s Medical Record into Smartcard

The system also needs to be able to write patient’s medical records onto a

smartcard. The medical records must be formatted effectively prior to transfers to a

secure smartcard platform and to be guarded with encryption keys within the

smartcard memory.

REQ7: Supports Management of User Profiles

As part of security measure, the system should manage user profiles for access

control purposes. Critical user access features like who can access the system, what

92

information should be made available for them and what they can do with the

retried information should be managed properly.

REQ8: Supports Verification of system entries through Audit Trial

The system must have the ability to log read, create, update, and delete access

records initiated by individuals and processes for systems containing confidential

and restricted data. All audit records must be identified by a unique record key or

number, and include User identifier/name of user, Time/date of access, Device

identifier if a smartcard reader used for access control, type of data being accessed

or activity being performed, Type of action (e.g. read, write, update, delete, or copy)

or access for diagnostic purposes.

3.4.2 REQUIREMENT MODELING

The requirements identified can be illustrated via a use case diagram in UML. A use case

diagram shows the users of the system who are known as actors. Actors as well as their

roles in the context of this system are defined as below:

• Patient

o The patient is the owner of the health record which is held in the smartcard

provided to him or her. The patient would need to key in the pin to allow the

authorized user to view and update his or her record. A patients interaction

will interact in this system via the smartcard application layer

93

• Doctor

o The doctor interacts with the system via the clinical management application

layer. A doctor views the record, updates the diagnostic information and

provides the required subscription.

• Administrator

o The administrator in this system will act as the person who updates the

patient information and chronology of prescription or payment. The

administrator will not have any access to the patient medical record.

Use cases describe the interaction between a primary actor which is the initiator of the

interaction and system itself and this interaction can be represented as a sequence of simple

steps. Use cases can be defined into two different levels, namely the abstract use case level

and system use case level. The abstract level use case is usually tied to the business process

in contrast with the system use cases are often described as the functionality of the system

the user interacts with (Wikipedia, 2008).

The abstract use cases for the administrative and medical records for this system are

outlined in Table 3.3. Abstract use cases do not specify the interaction in specific with the

system. It looks at the overall task that exists within the domain therefore the use cases

defined in Table 3.3 are in the form of generalized task within the healthcare domain and

this is illustrated in Figure 3.6.

94

Table 3.3 Abstract Healthcare domain Use Case

Abstract Use Case Task

• Admission , discharge, transfer

• Scheduling and Appointment

• Diagnosis, assessment, decisions, conclusions

• Clinical Activities: visits, diagnostic procedures, treatments, care procedures

• Medical Communication: Access to patient, Order reporting, Result reporting

• Documentation: Medical reports, Medical documentation

Documentation

Patient

Doctor

Administrator

Scheduling,

Appointment

Communications

Activities and

Procedures

Diagnosis,

Assessment, Decision, Conclusion

Figure 3.6 Abstract Use Cases

95

The functionality that can be done in the system is shown as task in a use case diagram.

Figure 3.7 shows the task the user of the system can do. Figure 3.8 shows the use case for

the smartcard module. For each task, the description is provided in Table 3.4 as the use

case description.

Table 3.4: Use Case Descriptions

Use Case Task Use Case Description

Maintain Patient Record User is able to choose the options to maintain patient’s record

Add Patient Record User will be able to add new patient’s record

Update Patient Record User will be able to update existing patient’s record. The detail

view of the record will vary according to the role of the user

accessed in to the module

View Patient Record User will be able to view the patient’s record. The detail view of

the record will vary according to the role of the user accessed in

to the module

Maintain Medical Diagnosis User is able to choose the options to maintain the patient’s

medical diagnosis results

Add Medical Diagnosis User will be able to add medical diagnosis section on a patient’s

record.

Update Medical Diagnosis User will be able to update the medical diagnosis and

examination results done on the patient. This module can be

accessed only by a doctor.

View Medical Diagnosis User will be able to view the patient’s diagnosis records

Maintain Prescription User is able to choose the options to maintain the prescription

type for each patient

Add Prescription User will be able to add prescription on the patient record

Update Prescription User will be able to update prescription on the patient record.

This action will be only done by authorized personal

View Prescription User will be able to view the prescribed medication for the visit

Authenticate User User will be able to login and view the information according to

the underlying rule-based mandatory and discretionary within the

96

smartcard communication with the system

ReadMedicalRecord User will be able to insert the card and retrieve the information

from the card with security authentication

WriteMedicalRecord User will be able to insert the card and write information to the

card with security authentication

ViewPesonalDetails User will be able to insert the card and retrieve personal

information of the patient

Top Package::Doctor

Add Patient Record

Update Patient

Record

View Patient Record

View Medical

Diagnostic

Add Medical

Diagnostic

Update Medical

Diagnostic

Update Prescription

Add Prescription

View PrescriptionInvalid Pin

Top Package::Front Desk

Authenticate User

SmartCardModule

Top Package::patient

SECURE MEDICAL RECORD CLINIC MANAGEMENT SYSTEM

Maintain Patient

Record

Maintain Medical

Diagnostic

Maintain

Perscription

«extends»

Invalid Pin

«extends»

Invalid Pin

«extends»

*

*

**

*

*

«extends»

* *

*

*

*

*

Figure 3.7 Use Case Diagram for Secure medical record clinic management system

97

Patient

Read Medical Record

Write medical

Record

View Personal

Information

*

*

*

**

*

SmartCard

Figure 3.8 Use Case Diagram for Smartcard

3.5 REQUIREMENT ANALYSIS

The task for the use case diagram is defined after the requirement selection was done to the

eight user requirements defined earlier. Four valid requirements are defined and used as the

requirement for the tool development. After the requirements have been mapped as task in

the use case, each use case is analyzed to identify the classes involved in the project. The

process of identifying classes from each use case is known as use case realization.

3.5.1 USE CASE REALIZATION

Selected use case will be examined separately to discover the classes involved. Once the

classes are identified the collaboration between the identified classes will be defined. This

section will explain the use case for the user defined requirement below.

98


The system is required to provide a user interface to capture/enter patient’s registration

information. Patient’s name, NRIC number, address, next-of-kin, blood type, allergies and

other personal identifications are basic to create a patient record.

Use Case Involved

• Add Patient Record

• WriteMedicalRecord

• ReadMedicalRecord

� Add Patient Record

This use case supports the requirement of the system to create patients record in the

system when the user registers in a healthcare institution. The user registration will be

done by the front desk administrator via the clinic management system. Once the record

has been updated in the database, the record is then written to the card using the

smartcard access module. The classes used to realize this use case is illustrated in

Figure 3.9.

99

Add Patient Record

PatientClinicManagementUI SmartCardSys SmartCardConnector PatientManagement

Figure 3.9 Use Case Realization for Add Patient Record Use Case

The collaboration between the identified classes is explained in a collaboration

diagram. The collaboration states the methods invoked in the identified class to show

the interaction between the user and the system. Figure 3.10 explains the interaction of

classes and the methods for this use case.

Figure 3.10 Collaboration diagram for Add Patient Record Use Case

100

� Write Medical Record

This use case will incorporate three classes which facilitates the interaction between the

smartcard system and the clinic health management. As an example once the

administrator registers a new patient in the clinic management system the information

then needs to be updated into the patient’s health card. Involvement of classes is very

minimal for this use case as the bulk of the processing is done via methods within the

smartcard system. The methods invoked during the interaction of the identified classes

in Figure 3.11 is defined in the collaboration diagram in Figure 3.12

Figure 3.11 Write Medical Record Use Case realization

Figure 3.12 Write Medical Record Collaboration Diagram

101

� Read Medical Record

In this use case three classes which facilitate the interaction between the smartcard

system and the clinic health management will be incorporated. When a patient visits

the healthcare provider, their EMR Smartcard will be read by front-desk staff for

registration and then by the medical practitioner during diagnostics or prescription.

Only a very minimal for this use case involve in this process as the much of the

processing is done within the smartcard system. The methods invoked during the

interaction of the identified classes in Figure 3.13 is defined in the collaboration

diagram in Figure 3.14

Figure 3.13 Read Medical Record Use Case realization

Figure 3.14 Read Medical Record Collaboration Diagram

102

3.6 ANALYSIS AND DESIGN

The sequence diagram shows the behavioral aspect of the system. The sequence diagram

will stress on the object instance during the event interaction. After the realization process,

the classes for the system were identified. Identified classes in the collaboration diagram

differ in their name or totally removed considering the implementation constraints. The

sequence diagram will show the series of interaction between the user and the classes or the

objects involved. The section below explains and illustrates the sequence diagram for the

action Add Patient Record.

Figure 3.15 Add Patient Record sequence diagram

103

In this sequence diagram, the primary user is the doctor who login to the system using

the main ClinicManagementUI. The system will then permits or denies the access to the

user by authenticating his EMR user smartcard.

In the event of a new patient registration, upon successful authentication, the user can

access the patient registration form or AddPatientUI. The user will be required to enter

patient’s personal information, allergy information, emergency information and

previous medical history information on user interface and insert the information on a

database. The user will receive a confirmation from the system if the patient’s

information has been added successfully.

After adding the patient information or on the next visit of the patient, the user can

update the information on the card by issuing WriteRequest to the

SmartCardConnector. All access to the smartcard memory require authentication from

the card and it the user obtained a successful authentication, he/she can write

information on to the card. Writing information to the card memory needs a session key

via OpenWriteSession command. Once the session has been established between the

card reader and the smartcard, relevant medical information will be transferred or

“encoded” onto the smartcard’s memory. The smartcard application will then received

the RespondAPDU to inform the card write session has been completed and will to

close the session. Upon successful of the CloseWriteSession, the UI will be closed the

system will return to initial stage.

104

In this sequence, the 4-level authentication procedure has been implemented as below:

• System Level: When the user login to the system. Smartcard will be used to

authenticate the user.

• Transmission Level: Between the SmartcardConnector and SmartCardUI. The

session is fully encrypted and requires authentication before proceeding

• Card Level : Access to the card memory is protected by SecretKeys at MF and

DF levels.

• Data Level : All data stored on the card have been encrypted using 3DES

3.7 A SYSTEMATIC TEST PROCEDURE

EMRSmartcard system test plan is to provide a set of test procedures that complies with

standard recommendation by international and industrial authorities. In this research three

test methodologies are to be carried out.

1. General Security Test Plan to evaluate security of all layers of system

2. Compliance Test Plan to evaluate compliance of security levels on all security

layers

3. Performance Evaluation Test Plan to evaluate the read/write operation with and

without a smartcard implementation.

These test plans are not intended to exercise every possible condition, but it will cover the

most common scenarios and enough error conditions to demonstrate basic error handling.

105

The test plan cannot anticipate limitations that exist within development components, such

as smartcard operating system and interface development tool (Visual Basic).

3.7.1 GENERAL SECURITY TEST PLAN

Security in healthcare information systems generally poses challenges at two levels:

• Communication Level

Communication security may be realized as secure messaging (secure objects) or

secure connections (secure channels).

• Application Level

Application security deals with the improvement of authorization and access control

including the definition of roles and decision support.

106

Figure 3.16 : Layered security model (Bernd, 2000)

Figure 3.16 presents this layered security model based on the concepts–services–

mechanisms–algorithms view with different levels of granularity containing possible

elements for each level. Only a few examples are given for the service-mechanism

relationship.

The below test plan is constructed to evaluate the characteristics of Security Services and

Security Mechanism layers as defined in Figure 3.16.

107

Table 3.5 Security Services – Security Mechanisms Test Plan

Security services Security Mechanisms Existence / Compliance

Identification/Authentication Digital Signature / Smartcard

PIN

Authorization and Access

Control

Digital Signature / Smartcard

PIN

Integrity Digital Signature / Smartcard

PIN, Encryption

Confidentiality Encryption

Accountability Audit Trails, Logs

Availability Access Control, Digital

Signature/ Smartcard PIN

Non-repudiation Digital Signature/ Smartcard

PIN

3.7.2 COMPLIANCE TEST PLAN

These test procedures are part of Common Criteria for Information Technology Security

Evaluation (CCITS) that suggests the following steps to test and evaluate any Target of

Evaluation (TOE). TOE in the current research environment is identified as smartcard

components and the corresponding integration components on clinical management system.

Below are the functional requirements applicable for this Compliance Test Plan:

108

Table 3.6 Compliance Test Plan

Functional Requirements applicable Compliance

The TOE security functions shall require each user to be successfully

authenticated before allowing any other TOE security functions-mediated

actions on behalf of that user.

The TOE security functions shall require each user to identify itself before

allowing any other TOE security functions-mediated actions on behalf of

that user.

The TOE security functions shall monitor user data stored within the TOE

scope of control for on all objects

The TOE security functions shall explicitly deny an information flow

The TOE security functions shall be able to apply a set of rules in

monitoring the audited events and based upon these rules indicate a potential

violation of the TOE security policy.

The TOE security functions shall ensure that unauthorized users are unable

to observe the operations

The TOE security functions shall provide the capability to determine

whether physical tampering with the TOE security functions’ devices or

TOE security functions’ elements has occurred.

109

3.7.3 PERFORMANCE EVALUATION TEST PLAN

The third test plan that suggested for the EMRSmartcard system is to evaluate the

performance of the smartcard itself. There are five scenarios to be evaluated with different

parameters and matrix.

1. Reading Speed of a medical record under different scenarios

2. Writing Speed of a medical record under different scenarios

3. Reading Speed of a set medical records under different scenarios

4. Writing Speed of a set medical records under different scenarios

5. Retrieval Speed of smartcard records versus database records

The recommended Test Procedures are:

1. Reading Speed of a medical record under six scenarios:

a. Encrypted record that written on a smartcard without any

implementation of Key Management System (KMS)

b. Encrypted record that written on a smartcard with an implementation of

Key Management System (KMS)

c. Encrypted record that written on a database

d. Unencrypted record that written on a smartcard without any


e. Unencrypted record that written on a smartcard with an implementation

of Key Management System (KMS)

f. Unencrypted record that written on a database

110

Table 3.7 Performance Test Plan #1

Data Format Smartcard

Database With KMS Without KMS

Encrypted

Unencrypted

2. Writing Speed of a medical record under six scenarios:

a. Encrypted record that to be written on a smartcard without any


b. Encrypted record that to be written on a smartcard with an


c. Encrypted record that to be written on a database

d. Unencrypted record that to be written on a smartcard without any


e. Unencrypted record that to be written on a smartcard with an


f. Unencrypted record that to be written on a database


Data Format Smartcard


Encrypted

Unencrypted

111

3. Reading Speed of a set medical records under multiple scenarios:

a. Set of encrypted records that written on a smartcard without any


b. Set of encrypted records that written on a smartcard with an


c. Set of encrypted records written on a database


Number of

Encrypted

Records

Smartcard


1

10

100

1000

4. Writing Speed of a set medical records under multiple scenarios:

a. A Set of encrypted records that to be written on a smartcard without any


b. A Set of encrypted records that to be written on a smartcard with an


c. A set of encrypted record that to be written on a database

112


Number of

Encrypted

Records

Smartcard

Database With

KMS

Without KMS

1

10

100

1000

5. Retrieval Speed of smartcard records versus database records

a. Search and Retrieve an encrypted record from smartcard

b. Search and Retrieve an encrypted record from database


Number of records in

card/database

Source

Smartcard Database

1

10

100

1000

10000

100000

chapter 3: research methodology - um...

Documents