Chapter 3: Research Methodology
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*
CLA INS P1 P2 Lc Data Le
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*
CLA INS P1 P2 Lc Data Le
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* -*
CLA INS P1 P2 Lc Data Le
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 -* -*
CLA INS P1 P2 Lc Data Le
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*
CLA INS P1 P2 Lc Data Le
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* -*
CLA INS P1 P2 Lc Data Le
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* -*
CLA INS P1 P2 Lc Data Le
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* -*
CLA INS P1 P2 Lc Data Le
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* -*
CLA INS P1 P2 Lc Data Le
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* -*
CLA INS P1 P2 Lc Data Le
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* -*
CLA INS P1 P2 Lc Data Le
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*
CLA INS P1 P2 Lc Data Le
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*
CLA INS P1 P2 Lc Data Le
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
Previous History Info-3 100
Previous History Info-4 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.
REQ2: Supports Patient Registration
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
REQ1: Supports Patient Registration
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
implementation of Key Management System (KMS)
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
implementation of Key Management System (KMS)
b. Encrypted record that to be written on a smartcard with an
implementation of Key Management System (KMS)
c. Encrypted record that to be written on a database
d. Unencrypted record that to be written on a smartcard without any
implementation of Key Management System (KMS)
e. Unencrypted record that to be written on a smartcard with an
implementation of Key Management System (KMS)
f. Unencrypted record that to be written on a database
Table 3.8 Performance Test Plan #2
Data Format Smartcard
Database With KMS Without KMS
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
implementation of Key Management System (KMS)
b. Set of encrypted records that written on a smartcard with an
implementation of Key Management System (KMS)
c. Set of encrypted records written on a database
Table 3.9 Performance Test Plan #3
Number of
Encrypted
Records
Smartcard
Database With KMS Without KMS
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
implementation of Key Management System (KMS)
b. A Set of encrypted records that to be written on a smartcard with an
implementation of Key Management System (KMS)
c. A set of encrypted record that to be written on a database
112
Table 3.10 Performance Test Plan #4
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
Table 3.11 Performance Test Plan #5
Number of records in
card/database
Source
Smartcard Database
1
10
100
1000
10000
100000