OngGhiaLeng_FYP.doc - visit site - SIM University by wuzhenguang

VIEWS: 3 PAGES: 89

									           SIM UNIVERSITY
 SCHOOL OF SCIENCE AND TECHNOLOGY




     DATABASE DESIGN FOR
   PATIENT CARE APPLICATIONS




  STUDENT   : ONG GHIA LENG (Y0704430)
  SUPERVISOR: DR HINNY PE HIN, KONG
  PROJECT CODE: JAN2010/BME/0046


      A project report submitted to SIM University
in partial fulfilment of the requirements for the degree of
            Bachelor of Biomedical Engineering

                    November 2010
                                               TABLE OF CONTENTS
ABSTRACT ................................................................................................................................................ 5


ACKNOWLEDGEMENTS ............................................................................................................................ 6


LIST OF FIGURES ....................................................................................................................................... 7


LIST OF TABLES ......................................................................................................................................... 7


1       INTRODUCTION ............................................................................................................................... 8


2       PROJECT OBJECTIVES AND METHODOLOGY .................................................................................. 12

    2.1     Project Aims .................................................................................................................................... 12

    2.2     Methodology ................................................................................................................................... 13


3       REQUIREMENT ANALYSIS .............................................................................................................. 15

    3.1     Technical Findings ........................................................................................................................... 15
        3.1.1        Electronic Health Records ..................................................................................................... 15
        3.1.2        Database Management Systems ........................................................................................... 15
        3.1.3        Database Designing ............................................................................................................... 16
        3.1.4        Unified Modelling Language (UML) ....................................................................................... 17
        3.1.5        Structured Query Language (SQL) ......................................................................................... 18
        3.1.6        Health-IT Standards ............................................................................................................... 18
        3.1.7        Health Level 7 (HL7) .............................................................................................................. 19

    3.2     Literature Review ............................................................................................................................ 20
        3.2.1        Singapore Electronic Medical Record (EMR) Systems ........................................................... 20
        3.2.2        International Standards Adoption ......................................................................................... 22
        3.2.3        Adaption and scalability ........................................................................................................ 23

    3.3     Current Situation ............................................................................................................................. 23
        3.3.1        Interview with a current EMR user (Interview 1) .................................................................. 23
        3.3.2        EMR System Survey (Interview 2) ......................................................................................... 24
        3.3.3        Possible Improvements to Current Situation ........................................................................ 25

    3.4     Analysis of Findings ......................................................................................................................... 26
        3.4.1        Major Need for change ......................................................................................................... 26



JAN2010/BME/0046 – BME499 Capstone Project Final Report                                                                                              2|Page
       3.4.2       Limitation for change ............................................................................................................ 26


4      SYSTEM DEFINITION ...................................................................................................................... 27

     4.1   Functional Requirements Description ............................................................................................. 27

     4.2   Non-Functional Requirements Description ..................................................................................... 28

     4.3   Implementation Requirements Description .................................................................................... 28

     4.4   Interface Requirements Description ................................................................................................ 28

     4.5   Lifecycle Workflow .......................................................................................................................... 29


5      DATABASE DESIGN ........................................................................................................................ 31

     5.1   Use Case Diagram ........................................................................................................................... 31

     5.2   Entity Relationship Diagram ........................................................................................................... 34

     5.3   Data Types ...................................................................................................................................... 35

     5.4   Access Levels ................................................................................................................................... 37

     5.5   HL7 Reference Information Model .................................................................................................. 38

     5.6   Physical Design................................................................................................................................ 39

     5.7   User Interface.................................................................................................................................. 40

     5.8   System Implementation .................................................................................................................. 41


6      DISCUSSION .................................................................................................................................. 42

     6.1   Rationales and Justifications for Improvements ............................................................................. 42

     6.2   Benefits and Cost ............................................................................................................................ 43

     6.3   Why HL7? ........................................................................................................................................ 43


7      PROJECT MANAGEMENT ............................................................................................................... 44


8      CONCLUSIONS ............................................................................................................................... 49


9      RECOMMENDATIONS.................................................................................................................... 51


10     CRITICAL REVIEW .......................................................................................................................... 52


11     REFLECTIONS................................................................................................................................. 53

JAN2010/BME/0046 – BME499 Capstone Project Final Report                                                                                             3|Page
    11.1         Experience gained in database design ....................................................................................... 53

    11.2         Problems met ............................................................................................................................. 53


APPENDICES ........................................................................................................................................... 55

    Appendix A – HL7 EHR-S Functional Model .............................................................................................. 55

    Appendix B – HL7 EHR-S FM Direct Care Functions .................................................................................. 56

    Appendix C – Minutes of Interviews with Healthcare Professionals ......................................................... 60

    Appendix D – Use Case Descriptions ......................................................................................................... 62

    Appendix E – ERD Normalisation Technique............................................................................................. 66

    Appendix F – SQL (MS Access) Data Types ............................................................................................... 69

    Appendix G – HL7 Data Types ................................................................................................................... 70

    Appendix H – Data Types Specifications ................................................................................................... 73

    Appendix I – MS Access Data Tables ........................................................................................................ 85


REFERENCES ........................................................................................................................................... 89




JAN2010/BME/0046 – BME499 Capstone Project Final Report                                                                                             4|Page
ABSTRACT
Electronic Health Records and Health Care Management Systems are widely used by
healthcare providers. They are highly versatile and can be altered to different needs and
functions. Most importantly, they enable easy information sharing and archival.


Since the birth of these electronic healthcare support systems, hospitals, clinics and
software development firms have developed various kinds of management systems and
are constantly trying to provide the most up-to-date systems. Different system adaptation
together with the countless types of clinical data and records generated by a diversity of
medical devices resulted in a bewildering range of healthcare records and systems were
utilized by different healthcare providers. The existence of different systems and
communication languages thus creates difficulty for the software to share and transfer
information freely. If a patient chooses to seek healthcare services from different places,
duplicate copies of his record will thus be created and stored at the different centres.
Multiple records waste storage space, incur additional cost, increase administrative
workload and raise the chance of data anomalies. Despite these issues, a universal health-
IT standard is still lacking in the current healthcare systems.


As such, a universal Health-IT standard needs to be adapted to enable interoperability and
data sharing. In this project, we demonstrate the integration of Health Level 7 (HL7)
Standards with our Database Design for Patient Care Applications with a holistic goal of
creating a single nationwide system for all healthcare providers and institutions.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                              5|Page
ACKNOWLEDGEMENTS
I would like to show my gratitude to my project supervisor, friends and family who have
made contributions to making this Capstone project a successful one.
It would not have been possible without their support and patience.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                          6|Page
LIST OF FIGURES
Figure 2.1: Graphical representation Singapore EHR Network ..................................................................... 12
Figure 2.2: Project Work Flow – Database Development Lifecycle ............................................................... 14
Figure 3.1: Database Designing Process ....................................................................................................... 16
Figure 4.1: Hospital A&E Visit Lifecycle ......................................................................................................... 30
Figure 5.1: Use Case Diagram for Hospital Visit ............................................................................................ 32
Figure 5.2: Entity-Relationship Diagram ....................................................................................................... 35
Figure 5.3: HL7 RIM Six Backbone Classes (in UML format) .......................................................................... 38
Figure 5.4: Data table for Patient profile ...................................................................................................... 40
Figure 5.5: GUI Representation of our EHR System ....................................................................................... 41




LIST OF TABLES
Table 3.1: Healthcare IT systems adoption by local healthcare clusters ....................................................... 21
Table 5.1: Use Case Description for “Register Patient” ................................................................................. 33
Table 5.2: Attributes table for ‘patient’ (patient information) ...................................................................... 37
Table 5.3: Access Rights in Database system ................................................................................................ 38
Table 7.1: Project Schedule ........................................................................................................................... 46
Table 7.2: Project Gantt Chart (Part 1) .......................................................................................................... 47
Table 7.3: Project Gantt Chart (Part 2) .......................................................................................................... 48




JAN2010/BME/0046 – BME499 Capstone Project Final Report                                                                                         7|Page
1   INTRODUCTION

Electronic Medical Record (EMR) systems are currently used extensively across the
healthcare eco-system to share and view patient’s electronic medical records. EMR is a
record in digital format that is capable of being shared across different health care
settings, by being embedded in network-connected enterprise-wide Patient Record
Systems1.



In order to achieve integrated and coordinated healthcare, a single nationwide Electronic
Health Record (EHR) system should be created and be used by all healthcare providers.
This integrated EHR system should be generated using global health-IT standards to
create the opportunity for interoperability. This EHR system used must be capable of
storing and accessing data generated by medical devices used currently and also need to
take into account any plausible new devices that might be invented and used in the future.
This will ensure that all patients related records are stored together to provide accurate
clinical data and information that would support effective healthcare management and
delivery. This database model must also be able to accept a wide variety of data types and
be flexible at the user interface so that it can be customized to cater to different usage and
requirements. To achieve the aim of having such a global health IT standards, many
different standards had been created. These includes the Health Level Seven (HL7)
standard and the GS1 standard. Both the HL7 and GS1 have many benefits that enable
the realisation in the Healthcare sector of all health and economic benefits related to
automatic identification, traceability and data synchronisation. However, HL7 standard,
which is set by the global standardisation body, the HL7 International, have a wide
adaptation and is used globally. This thus creates the opportunity for a truly global system
that allows healthcare providers across different countries the ability to have an
interoperable system whereby patient data could be shared and used easily with the
patient consent.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                                 8|Page
To ensure the development and achievement of a single nationwide EHR system, careful
implementation plans need to be drawn up to ensure successful adoption by all healthcare
providers. Given the scale and the complexity of the healthcare provider landscape, many
factors will determine the successful implementation of this system development
including,

1. Infrastructure development,

2. Necessary regulatory framework maturation,

3. Appropriate funding models,

4. Sufficient infocomm manpower

5. Achieving national acceptance by everyone involved.

This is no trivial challenge and would require everyone’s involvement in order to
succeed2.



Review on the existing patient care systems revealed that Singapore healthcare clusters
currently adopt a variety of patient care systems. As a result of the different systems
employed, patient’s data sharing is hindered resulting in a lack of cooperation among
healthcare providers and causing a lack of interoperability. With the lack of
interoperability, this created several issues including:



1. Extra administrative workload whereby the patient would need to be re-interviewed to
provide even basic information such as addresses or telephone number every time a
change of departments or healthcare facilities/provider occurs. The need to replicate such
data input also created the opportunity for human error incident potentially resulting in
data anomalies.



2. The presence of data anomalies could thus potentially lead to incorrect patient
management decision by taken by the clinicians.


JAN2010/BME/0046 – BME499 Capstone Project Final Report                             9|Page
4. Incorrect patient management decision could also arise from not having access to any
previously documented patient’s medical data/history including any drug allergy
especially in case of emergency.



4. Lack of data compatibility even between different department of the same facilities
such as the pharmacy or nursing ward created the potential of miscommunication which
could result in a wrong drug being prescribed.



5. Maintaining different systems increases the overall cost needed. To balance such costs,
the healthcare provider would inevitability pass on some of it to the patients. This is
especially important with an ageing population whereby the healthcare cost subsidies
provided by the states will also concomitantly increase. This could result in a snowballing
social effect of more taxes being needed to cover such cost.



As such, there is an important need to provide a common EHR system platform for easy
access to patient’s records by all healthcare providers. Besides the requirement of a
common interface and system platform, there is also a need to ensure that the EHR allow
scalability. Having such a scalable system will thus ensure that the system is ready and
prepared for the future where a larger ageing population healthcare need is taken into
account. Combining such scalability and having a common interface and system platform
will ensure the system retains all the benefits of the EHR for patient’s healthcare needs
including,



1. Providing healthcare staff with quick, accurate and complete patient medical records
thereby reducing workload and any chance of human error.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                             10 | P a g e
2. Enable healthcare providers to make accurate and informed patient management
decisions.



3. Allowing hospital to provide better co-ordinated healthcare, especially when patients
get referral to other hospitals or inter-cluster specialist clinics or in emergency situation
whereby instant patient management decision need to be taken.



4. The use of a single EHR system can reduce cost significantly to patients by eliminating
the need for repeat tests by doctors across institutions. Eliminating such repeated tests is
also beneficial to the psychological health of the patients.



5. Cost saving for the patients could also be derived from the healthcare institution cost
saving whereby the maintenances cost of having a single system is plausibly cheaper than
compared to multiple systems.



Together the importance of having a single nationwide EHR system cannot be
understated. Database is an important back-bone of a successful EHR system and the
process of database designing consists of a series of research, analysis, planning and
implementation processes which can be used to create an improved EHR system. In this
project, we will learn the 3 major database designing processes and apply HL7 standard
components to the design to illustrate our intended system.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                              11 | P a g e
2     PROJECT OBJECTIVES AND METHODOLOGY

2.1   PROJECT AIMS

The aim of this project is to design an improved EHR System for implementation in
Singapore healthcare network to provide patient care applications. Currently, the
Singapore healthcare network consisted of 5 broad clusters as summarised in Figure 2.1.




                      Figure 2.1: Graphical representation Singapore EHR Network




According to HL7 Electronic Health Record System Functional Model (HL7 EHR-S
FM)3, there are 3 major functional categories of an EHR and they are summarised in
Appendix A. In this project, we will focus on Direct Care functions where the system will
be used in delivery of healthcare services. The designing of an EHR system includes the
application of database designing skills into the development process. From planning and
requirement realisation to implementation, we take this chance to learn the fundamentals
of database designing and its application.



JAN2010/BME/0046 – BME499 Capstone Project Final Report                            12 | P a g e
Medical records may include a whole range of data in comprehensive or summary form,
including demographics, medication and allergies, laboratory test results and images and
billing information. Thus, we will use HL7 for data standardization and data structuring
to enable interoperability and to create a channel for seamless large data flow among the
healthcare providers.



Following the software development of the EHR system, careful implementation plan
including compatible hardware procurement must be made to allow connectivity and
scalability among the healthcare network. The system should be incorporated into the
clusters’ existing systems and not replacing them. To allow smooth adoption by the
healthcare providers, the implementation plan must be introduced in phases, taking into
consideration that the hospitals are still in full operation and healthcare services must not
be disrupted. Faults and system failure resulting in loss of important patient records must
be prevented.



In summary, the objectives of this project are:

      1. To learn the fundamentals of database designing methods to create an integrated
         and multi-functional EHR database system;
      2. To understand the importance and implementation of HL7 standard for different
         data types and its ability to enable robust connection and scalability within
         Singapore healthcare network.



2.2     METHODOLOGY

Database designing involves a series of pre-designing phases which involves project
planning, requirement realisation, and system definition to identify the aims and
specifications of the database. Achieving good planning and having a good understanding
of the project requirements and system definition would thus help render the database
designing steps including Conceptual, Logical and Physical designing much simpler.
Careful implementation plans can then be made to ensure that the system is able to

JAN2010/BME/0046 – BME499 Capstone Project Final Report                              13 | P a g e
operate and bring minimal amount of disruption to the healthcare industry. Figure 2.2
shows the developmental lifecycle of database designing.




         Database Designing




                              Figure 2.2: Project Work Flow – Database Development Lifecycle

We first begin by researching on the types of patient record systems currently used in
local healthcare community; types of database management systems; available health IT
standards available for adoption. Using these information, we were then able to define
our system requirements such as the functions and type of patient information which
should be found in our EHR system.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                                        14 | P a g e
3     REQUIREMENT ANALYSIS

In order to create an improved EHR system, we need to assess the current deployed
system(s) and technology involved. We begin by performing background research with a
visit to the hospital to observe and understand existing EHR system, including the type of
technology and global standards it involves and a review on the medical record system
currently used. This will allow us to identify how an EHR system should operate and
enable us to verify the required specifications.



3.1     TECHNICAL FINDINGS

3.1.1   Electronic Health Records

The Health Information Management Systems Society’s (HIMSS) defines EHR as a
longitudinal electronic record of patient health information generated by one or more
encounters in any healthcare delivery setting. Included in this information are patient
demographics, progress notes, problems, medications, vital signs, past medical history,
immunizations, laboratory data, and radiology reports. The EHR automates and
streamlines the clinician's workflow. The EHR has the ability to generate a complete
record of a patient encounter and support other care-related activities directly or
indirectly via interface—including evidence-based decision support, quality management,
and outcomes reporting4.



3.1.2   Database Management Systems

Database Management System (DBMS) is a set of computer programs that are used to
control the creation, maintenance, and the use of a database5. Two popular DBMSs are
Object-Oriented Database Management System (OODBMS) and Relational Database
Management System (RDBMS). These technologies are employed by software
developers and implemented in local hospitals to provide a DBMS to manage EHR. Due
to the advancement of technology, new data types are generated by new medical devices
and medical records no longer contains only traditional text reports and numbers. New

JAN2010/BME/0046 – BME499 Capstone Project Final Report                            15 | P a g e
clinical information such as diagnostic images, high-quality test videos and complex
cardiac reports are generated daily. The existence of high-technology data types do not
allow the OODBMS and RDBMS to be scaled up or work in high complexity. This
resulted in the existence of dissimilar system management technologies across hospitals,
clinics, institutions and agencies in Singapore, and consequence in limited
communication and data sharing between different systems or healthcare clusters.



However, Object-Relational Database Management System (ORDBMS), a combination
of the above technologies can be developed to bring diversity to EHR. ORDBMS is
similar to using RDBMS with an OODBMS model where data resides in the database and
is manipulated collectively with queries. It bridges the gap between RDBMS and
OODBMS using Structured Query Language (SQL) programming or Object-Relational
Mapping (ORM). The objects in ORDBMS has data embedded and are deployed within
an abstracted/logical data model. We will use this feature to embed patient details into
their diagnostic images and store it in the database for future retrieval.



3.1.3   Database Designing

In order to create an ORDBMS, the process of database designing can be divided into
three main phases as seen in Figure 3.1:




                               Figure 3.1: Database Designing Process




JAN2010/BME/0046 – BME499 Capstone Project Final Report                            16 | P a g e
Conceptual – In the first step of database designing, the concept of our intended system
derived from preceding system definition will be formalised and represented in a
graphical manner. The system goals will be further elaborated and remodelled to
conceptual diagrams such as Use Case Diagrams using Unified Modelling Language
(UML).



Logical – Once the system goals and the underlying concepts have been confirmed,
detailed planning for the type of contents and their relationship will be realised at this
stage. Entity Relationship Diagrams (ERD) can be used in logical design phase to
illustrate the interrelationships between data in a database. Data Normalization eliminates
redundant data and only store data in one location in the database to reduce potential of
data anomalies. Data normalization is thus critical to development an efficient database
system.



Physical – This is when logical database design is translated into coded programs.
Programming software is used to link up the relationship between data types so that the
database is able to store information for retrieval and manipulation. SQL Programming is
used at this stage to establish relational data system. Objects such as tables and columns
are created based on entities and attributes that were defined during modelling phase. The
physical structures are used to display and structure data storage with low-level
algorithms are used to perform data retrieval and manipulation.



The three stages of database designing need to be carefully planned and executed in
sequence with different software separately.



3.1.4   Unified Modelling Language (UML)

Unified Modelling Language (UML) is a standard general purpose modelling language
used to create visual models of systems including database systems. UML comprises 14


JAN2010/BME/0046 – BME499 Capstone Project Final Report                             17 | P a g e
types of diagrams to present structural, behavioural and relational information. These
diagrams include Use Case diagram, Activity diagram and Class diagram6.



There are many UML Design Software available and Visual Paradigm is a powerful and
popular free tool for designing UML Diagrams and is adapted here in this project for
generating the UML diagrams.



3.1.5   Structured Query Language (SQL)

Structured Query Language (SQL) is a computing language in American National
Standards Institute (ANSI) standard that can be used to execute queries to access and
manipulate databases, through create, edit, delete and even retrieval functions. SQL
Programming can be utilised through various RDBMS programs such as Microsoft
Access, SQL Server and MySQL software.



3.1.6   Health-IT Standards

There are various types of Health-IT standards and their existence help to provide a
foundation for data sharing and efficient communication within a network. These IT
standards are developed by Standards Development Organisations (SDOs), Special
Interest Groups (SIGs) and other initiatives. The three main organizations that currently
create standards related to EHRs are: Health Level Seven (HL7), Comite Europeen de
Normalization – Technical Committee (CEN TC) 215, and the American Society for
Testing and Materials (ASTM) E317. Many sets of standards are hence created and used
by different vendors to create various systems, which are being adapted and favoured by
different healthcare providers. In order to have one successful system, it is important to
adhere to a single standard in order to achieve systems interoperability.



Both technical and clinical standards are needed to create interoperable EHR. The use of
standard clinical terminologies and structured data organization enhances the ability to


JAN2010/BME/0046 – BME499 Capstone Project Final Report                            18 | P a g e
interoperate in a meaningful way and for EHR data to be retrieved and transform for
other usage with ease.



3.1.7   Health Level 7 (HL7)

HL7 International is a not-for-profit, American National Standards Institute (ANSI)-
accredited standards developing organization8. It is dedicated to providing a
comprehensive framework and related standards for the exchange, integration, sharing,
and retrieval of electronic health information that supports clinical practice and the
management, delivery and evaluation of health services. HL7 provides standards for
interoperability that improve healthcare delivery, optimize workflow, reduce ambiguity
and enhance knowledge transfer among stakeholders, including healthcare providers,
government agencies, the vendor community, fellow SDOs and patients.



HL7 develops the most widely used healthcare-related electronic data exchange standards
and is used to transmit structured, encoded, data between applications. This messaging
standard exists in two versions, HL7 v2.x and HL7 v3.x. Version 3 includes a Reference
Information Model (RIM) which provides a much more robust ability to represent
complex relationships. However it is not very much implemented by current EHR
systems due to the high cost required to revise the HL7 interface and the lack of
compatible systems.



HL7 also has an EHR system Functional Model (EHR-S FM) which includes a reference
list of over 160 functions that may be present in an EHR system. EHR functions are
categorised into Direct Care, Supportive and Information Infrastructure in EHR-S FM9.
We will focus and work on Direct Care (DC) functions in this project and a complete list
of DC functions can be found in Appendix B.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                          19 | P a g e
3.2     LITERATURE REVIEW

3.2.1   Singapore Electronic Medical Record (EMR) Systems

With the help of infocomm technology (IT) integration, Singapore healthcare industry
adopted the use of EMR extensively with the aim of improving Singapore’s healthcare
quality and patient care. As technology advances, many EMR systems have been
developed to cater the needs of various healthcare facilities. These healthcare IT systems
are pre-developed and often made of up different components due to different
functionalities it offers. An illustration of the different functionalities in different
healthcare IT systems can be seen in Table 3.1 showing a case study of the various
Singapore Healthcare clusters in 200310. For example, the SMS Health Systems was
adapted by the SingHealth and NHG clusters but not by the other clusters. As such, a
patient who might have been receiving treatment at the NHG cluster were to be
transferred to another cluster that did not adapted this might as a result possibly miss his
medical appointment.




  IT Systems                      Description

  SMS Health Systems              Tan Tock Seng Hospital developed an SMS system to
                                  transmit information to its doctors.

                                  SingHealth and the NHG have deployed SMS for
                                  patients at Specialist Outpatient Clinics through
                                  appointment reminders and queue management.

  National Heart Center and This solution integrates the Internet, SMS, web portal,
  Singapore General               and mobile phones to monitor patients’ vital signs at
  Hospital                        home. The system sends SMS alerts to both doctors
                                  and the patients whenever vital signs are beyond set
  - home tele-care solution
                                  thresholds.

  National University             CPSS at National University Hospital enables an


JAN2010/BME/0046 – BME499 Capstone Project Final Report                             20 | P a g e
  Hospital computerized              integrated view of patient data from multiple source
  patient support system             systems such as X-rays, laboratory results, surgical
                                     operating notes, discharge summaries, clinical results,
  (CPSS)
                                     and reports.

  SingHealth motorized               SingHealth designed the wireless light box to allow
  mobile triple LCD X-ray            doctors to bring digital images and EMRs to patients’
                                     bedsides for more effective, personal consultations.
  light box

  Changi General Hospital            Changi’s IPG allows patients to obtain information on
                                     treatments, surgical procedures, and aftercare of 25
  interactive patient guide
                                     common medical conditions through online video and
  (IPG)
                                     printable text.

                  Table 3.1: Healthcare IT systems adoption by local healthcare clusters




The use of multiple EMR systems is a major problem for health record sharing. As a
result, the Electronic Medical Record Exchange (EMRX) was created as a channel for
cross-cluster exchange of patient health information. Despite its pivotal capability to
allow information transfer across healthcare institutions, there is no data standardization
or structured data but just a document-level exchange system11.



Furthermore, it was discovered that the EMRX system were incapable of seamless
document exchange. Diagnostic images such as X-Ray radiographs were unable to be
exchanged properly due to the different image protocols, backend configurations, lack of
standards adoption and structured data model. Overall, this creates additional burden and
confusion on the healthcare providers and potentially results in data anomalies, which in
turn increases the risk of erroneous patient management.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                                    21 | P a g e
3.2.2   International Standards Adoption

The inability to exchange important patient health information across Singapore
healthcare network is a result of the lack of a common standard adoption by the
healthcare providers and the software creators. As such, Health Level Seven (HL7)
Singapore was launched in 2008 to help local healthcare community adopt HL7
standards12.



In the early years of clinical systems development in Singapore, HL7 v2.3 standard was
adopted by the 2 main healthcare clusters. But it was later discovered that there were
significant variations in the standard, thus data exchangeability was not easily achievable.
System modifications to enable data sharing are costly without direct benefits to the
clusters. Hence, it was decided that clinician-readable patient information was sufficient
for treatment and that machine-readable data was not needed. Thus, authorities steered
away from plans that require massive rebuilding of existing systems13.



Due to the low demand and high modification cost involve in implementing HL7 v2.3,
there was a lack of adoption of the standard by healthcare application vendors. As a
result, only few vendors invested in adoption of the HL7 v2 interfaces for their system.
Similarly, when HL7 came up with Version 3, not many vendors were inclined to adopt
the new standards.



Nonetheless, a major improvement of the HL7 version 3 over version 2 is the inclusion of
the Reference Information Model (RIM)14. This RIM provides a more robust ability to
represent complex relationships and can be used for representation of translational
research data in a form that can be exchanged within Singapore healthcare community to
promote clinical research. This thus provides a consistent platform for system interface to
allow data sharing and enable interoperability and robust connection within Singapore
healthcare network.



JAN2010/BME/0046 – BME499 Capstone Project Final Report                              22 | P a g e
3.2.3     Adaption and scalability

The use of EHR systems may have brought numerous benefits and convenience to
healthcare providers but a review on the existing systems and major trends in
demographics identified some challenges for our current healthcare system including15:

         Ageing population and the increased burden of chronic conditions such as
          diabetes, hypertension, high cholesterol levels and stroke which requires long-
          term health management.
         The constant rising public expectations of healthcare services.
         The current fragmented and relatively uncoordinated healthcare services.
         Rapid advances in infocomm, medical sciences and technologies and biomedical
          research

As such, it is critical that any unified healthcare system needs to be adaptive with the
ability to scale up taking into account the constantly changing social and technology
development.



3.3       CURRENT SITUATION

To better observe and learn the adoption status of actual EMR in local healthcare
community, an interview and a system survey were conducted. Interviewee names and
healthcare institutions are not disclosed for privacy and confidentiality reasons.



3.3.1     Interview with a current EMR user (Interview 1)

An interview was held with a staff nurse who works in a hospital ward to understand
possible problems which are affecting the delivery of quality healthcare.



An EMR system (renamed as System A) is used in the ward to view patient information
and medical reports. As primary care providers, Nurses were not able to edit report, add
remarks or comments to Patient’s EMR. As such, some important observations by the
nurses could not be included in the report. System A allows view-only access to most

JAN2010/BME/0046 – BME499 Capstone Project Final Report                              23 | P a g e
common data, such as clinical notes, orders and inpatient medical records, but was
lacking in Electrocardiography (ECG) records, as it still exists in hard copy till date. A
separate file folder needs to be stored and kept for such printed copies of records.



Payment also exists as a tricky issue in the hospital wards. As a result of the inability of
the system to fully trace patient’s payment, a small proportions of patients were not billed
or charged correctly due to the poor setup and operation of the billing system adopted in
the hospital.



Despite the fact that the all patient records are confidential and that the usage of the EMR
systems is bounded by the Computer Misuse Act, and professional codes of conduct to
not to misuse EMR, it was found that nurses are able to view all patients’ reports with no
restrictions. This thus created the opportunity for abuse of the EMR and access to
patient’s information and data by unscrupulous users. Although the system requires user
log-in authentication, it is not known if any access to a patient’s record were recorded.
This interview was performed without visual access to System A.



3.3.2   EMR System Survey (Interview 2)

A special and authorised appointment was made with another active user of another EMR
system (renamed to System B) to observe the hospital work flow and system functions of
existing EMR system.



Coincidentally, this professional care provider is also another user of System A. As such,
this interview also provided us with the opportunity to better understand which of the two
systems, A or B, is a better system by allowing a direct comparison between the two
systems to be made.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                                24 | P a g e
An advantage of System B over System A is the access rights limitation. System A does not
have any access restriction. Once logged in, the nurse would have full access to all
patients’ information and data. However, in System B, different users are given different
system access level and access right. For example, a technologist who performs and
completes diagnostic orders, were given access rights to the e-orders system but have
limited access to the reports section. Despite that, he was able to add remarks and special
instructions to patient’s record.



Besides the access rights limitation, we were shown System B and it displayed more
information with more concise tabs and categories of clinical notes such as X-Ray
information, surgical notes when compared to System A. Accordingly, System B is also
shared among the different clusters and hospitals. Nonetheless, some information such as
the reports and radiology diagnostic images are viewed separately in another web based
portal and requires the “fetching” of data from an external database thus not allowing
complete interoperability or fully providing ease of usage.



3.3.3   Possible Improvements to Current Situation

From Interview 1, some of the possible improvements which can be considered include:

   1. Allowance and capabilities for inputs of nursing notes for reference.
   2. All medical records including ECG to be stored electronically.
   3. A stored record of all healthcare personnel accessing patient database.
   4. Enable a Pop-Up window to remind user of tracked access and agreement with
        confidentiality terms.



In Interview 2, user was required to access multiple systems to view complete patient
records. Correcting this by having a fully integrated system would be important. This
would allow:

   1. Having a single centralised database system to prevent duplication of information.
   2. Provide the flexibility for user customization.

JAN2010/BME/0046 – BME499 Capstone Project Final Report                             25 | P a g e
      3. Provide the capability of opening multiple records in the single system for easy
           data comparison.



3.4       ANALYSIS OF FINDINGS

3.4.1      Major Need for change

From the issues derived from literature review and interviews, we are clear about the
current problems:

      1. Wide variety of EMR systems in local healthcare network
      2. Current EMRX system are unable to enable information exchange freely between
           healthcare clusters
      3. Variations in data types hinder exchange capabilities.
      4. Lack of data standardization, structured data and IT standards.
      5. Record information being stored in multiple systems causing duplication
      6. Data extraction to aid clinical decision support system, clinical research and
           disease surveillance was not possible.
      7. Healthcare services are fragmented and generally uncoordinated within
           institutions.

As such, it is important to development and design an interoperable and scalable ERM
system that corrects and improve on all these issues.



3.4.2      Limitation for change

While enabling system interoperability, we are bound by many challenges:

          Privacy and security framework within systems
          Protection measures against unauthorised access
          Access levels control
          Budget constrains
          Achieving acceptance from healthcare community
          Ensure sufficient manpower to support and system maintenance.

JAN2010/BME/0046 – BME499 Capstone Project Final Report                            26 | P a g e
4     SYSTEM DEFINITION

4.1       FUNCTIONAL REQUIREMENTS DESCRIPTION

The functional requirements of EHR system should include the following to ensure
improved delivery of quality healthcare services to patients.

         “One patient, One EHR.”:
          A single copy of EHR for every patient. Duplicates shall be prevented.
         Fully integrated system:

          The intended system design should include as many functions as possible to avoid
          the needs of separate systems.

         HL7 EHRS FM Direct Care Functions:

          Includes care management, clinical decision support, operations management and
          communication

         HL7 EHRS FM Supportive Functions:
          Including   clinical   support,    measurement,     analysis,   research,   reports,
          administrative and financial capabilities
         HL7 EHRS FM Information Infrastructure Functions:
          Includes security, health record information management, registry and directory
          services, standard terminologies & terminology services, standards-based
          interoperability, business rules management, workflow management
         Voice and handwriting input capabilities:

          To offer users different input methods.

         Record staff access:
          Staff access to patient records are recorded for privacy and security reasons
         Chronic disease management:

          With the increase of chronic diseases in Singapore, it is important that we make
          use of the database for managing chronic conditions in our patients.

         Link patient with immediate family:


JAN2010/BME/0046 – BME499 Capstone Project Final Report                                   27 | P a g e
          Capability to link patient profile with immediate family members’ profile for
          convenience at record retrieval in case of any emergency.



4.2       NON-FUNCTIONAL REQUIREMENTS DESCRIPTION

Some of the non-functional requirement descriptions are:

         The hardware must be able to support the scalability and complexity of this EHR
          system; allow storage of large data files and to offer the chance for expansion in
          the future.
         The system must be in operation at all times.
         The system shall enable online data access and offline data reading.
         The system shall contain the capability for large amount of secured data retrieval.



4.3       IMPLEMENTATION REQUIREMENTS DESCRIPTION

To achieve success after the system creation, the implementation process must include
the following:

         To achieve buy-in by majority of users
         A backup system
         FAQ and manuals
         Training to all users
         Technicians and service engineers to standby for system failure and to implement
          improvements based on any feedbacks.
         Alternative solution if system fails


4.4       INTERFACE REQUIREMENTS DESCRIPTION

To ensure ease of usage and scalability, the system interface is critical. Some of the
interface requirement descriptions important for the success of the system are:

         Web-based Portal


JAN2010/BME/0046 – BME499 Capstone Project Final Report                                28 | P a g e
         Works on most common web browsers
         Has a template
         Flexible and allow user customization according to needs
         Adaptive to different computer systems
         Fixed image resolution for viewing image, compatibility with most common
          image protocol
         Able to allow viewing and editing of few records at one time for comparison
         User-friendly
         Easy to learn as clinicians do not have time available for training and getting used
          to EHR system.



4.5       LIFECYCLE WORKFLOW

The HL7 Functional Model consists of 3 broad function categories to provide support in
delivery of care to patient. There are immeasurable workflows in a healthcare institution,
and each work flow can produce one database design model. We will focus on one work
flow in this project to demonstrate database designing methods. Direct care function is
the most commonly known function group and a series of actions from Care Management
to proceed was selected.



The workflow in Figure 4.1 depicts a cycle of events when a patient visits the Accident
and Emergency (A&E) Department in a hospital.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                                29 | P a g e
                              Hospital A&E
                             Visit Lifecycle




                             Figure 4.1: Hospital A&E Visit Lifecycle




The A&E visit lifecycle begins when a patient arrives at the A&E Department after for
example an accident. In this case, the patient is conscious but suffers minor injuries and
complains of headache and chest pain. The patient goes through the registration
procedure and was assess by an A&E Doctor on duty. Due to Patient complaints, the
doctor decided to put the Patient through a series of tests to check for any internal
injuries. Fortunately, the patient passes all the tests and was discharged from the A&E
Department along with some medications.



This A&E visit lifecycle includes the system communication to other major departments
in the hospital and falls under HL7 FM Direct Care (Care Management) functions and
would be an ideal tool to demonstrate database designing methods in this project.


JAN2010/BME/0046 – BME499 Capstone Project Final Report                             30 | P a g e
5     DATABASE DESIGN

There different methods and technologies are used to complete the 3 database design
phases:

      1. Conceptual Design – UML Use Case Diagram
      2. Logical Design – Entity Relationship Diagram (ERD)
      3. Physical Design – Data tables, SQL Programming, GUI



5.1     USE CASE DIAGRAM

Using the above A&E hospital visit lifecycle, we first identify the users who will be
accessing system and what are the functions and goals in which the proposed Patient Care
System will need to accomplish. As evident from Figure 5.1, we identified that several
users will need to access the system to complete the patient visit lifecycle. This includes
the administrator, the technologist, the nurse and doctor and finally the pharmacist. What
the system will need to accomplish ranges from the initial patient registration, doctor
consultation, test results order/input and review and finally to discharge and payment.
Together a schematic diagram to show how our system connects each user with the
intended use cases illustrating the workflow and system-user relationship of an A&E visit
is illustrated in Figure 5.1.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                             31 | P a g e
                         Figure 5.1: Use Case Diagram for Hospital Visit




This use case diagram consists of 5 main users who will be accessing the system at
different time in the process to View, Create, Edit and Delete part of patient’s health
record in order to complete the hospital visit lifecycle. Visual Paradigm was used to
create this UML Use Case Diagram.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                         32 | P a g e
Following each use cases are a flow of actions that are performed in order to complete
one use case. Table 5.1 shows the use case description of the use case 1 “Register
Patient” to show the users and system’s involvement in completing a common goal. The
use case descriptions of the other use cases can be found in Appendix D.




  Actor           Use Case                                  Process Description

                                       1. Admin enters Patient ID

                                       2. System displays Patient information tab and the

              Register Patient              following 6 tabs:

                                            2.1. Registration

            GOAL: A patient is              2.2. Visit Records

               received at the              2.3. Diagnostics
             registration counter
                                            2.4. Reports
            and receives a Queue
 Admin                                      2.5. Drug Prescriptions
                    Card.
                                            2.6. Payments

                                       3. Admin goes to the Register Patient tab to verify
               **Queue card
                                            and update the arrival or re-visiting status
           contains Patient name
           and identification (ID) 4. System records the time of Patient arrival.
                   number              5. System creates a new Visit Record is Patient is
                                            not making a re-visit

                                       6. Admin issues a Queue Card to patient.

                        Table 5.1: Use Case Description for “Register Patient”




JAN2010/BME/0046 – BME499 Capstone Project Final Report                                    33 | P a g e
5.2       ENTITY RELATIONSHIP DIAGRAM

Entity Relationship Diagram (ERD) is a graphical representation of relationship between
data in an EHR system. The following ERD is a result of normalisation process whereby
data sets undergo progressive re-modelling stages known as normal forms to eliminate
duplication of data and organise them into an efficient and logical structure. This process
ensures that data are only stored in one location in the database and decreases the
possibilities of data anomalies caused by additions and deletions.



The process of normalisation happens in usually 3 steps or more, if desire:

      1. First Normal Form (1NF)

          Elimination of duplicate data which may contain the same information format,
          creation of new tables for groups of related data and identify a primary key. The
          primary key (PK) will be responsible for linking the tables.

      2. Second Normal Form (2NF)

          Remove subsets of data which is not directly related to the PK and create new
          separate tables for them. In this form, the foreign keys (FK) can be used to create
          relationships between the tables

      3. Third Normal Form (3NF)

          Data which is not dependent on the PK can be removed from database.

      4. Additional normal forms are not commonly utilized but can be applied if required.
          They include Fourth Normal Form (4NF), Fifth Normal Form (5NF), Boyce Codd
          Normal Form (BCNF), and Domain-Key Normal Form (DK/NF).

          (See Appendix E for Normalisation process.)


After the completion of the data modelling, relationship between them were created.
There are 3 types of relationships in ERD:

         One to One


JAN2010/BME/0046 – BME499 Capstone Project Final Report                               34 | P a g e
         One to Many
         Many to Many (must be converted to “one to many” first)



The following Figure 5.2 shows our final ERD after the application of 3 normalization
process:




                               Figure 5.2: Entity-Relationship Diagram




5.3       DATA TYPES

All data stored is saved as attributes and it is important that we classify them correctly as
part of the database design process. These are critical building blocks of an efficient and
fast database system.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                              35 | P a g e
For data standardisation, each data needs to be classified according to SQL Data types for
database programming purposes, and HL7 Data types for adoption of international data
standard to enable seamless information transfer and extraction in the future.



We have created a sample list of data types which will exist in our pilot system. There are
many kinds of information used in healthcare settings. For this project, only certain
amount of data sets is selected for each entity of patient information and use as an
example as illustrated in Table 5.2. The first column indicates the name of the attributes;
second column indicates the SQL data types (see Appendix F for complete list of SQL
data types used in Microsoft Access); third column indicating HL7 data types (see
Appendix G for complete list of HL7 Data Types); fourth column indicating the
maximum length allowed; fifth column is the description of the data and finally an
example of the data type for easy reference.



                                              patient
                   Description: Patient’s personal and contact information.
                     One patient should only have one set of information.
                                   HL7        Max
                     MS Access
    Attribute                     Data    Length              Description         Example/Format
                    Data Types
                                   type    (char)
patientID (PK)      Text          II      15            Patient’s          unique S7850631F          or
                                                        identification         or E6052312P
                                                        passport number           (foreigners)
patientName         Text          PN      50            Patient’s full name       Siti Norharti Binte
                                                                                  Ibrahim Hafiz
patientGender       Yes/No        BL      1             Patient’s gender          F or M
patientDOB          Date/Time     TS      17            Patient’s Date of Birth, dd/mm/yyyy,
                                                        if known. Otherwise, hh:mm
                                                        input estimated DOB.
patientAge          Integer       INT     3             Patient’s age according 46
                                                        to the actual DOB, if

JAN2010/BME/0046 – BME499 Capstone Project Final Report                                    36 | P a g e
                                                                   known.
  patientRace             Text             ST         10           Primary       race        which Malay
                                                                   Patient belongs to.
  patientCitizenship      Text             ST         20           Patient’s nationality.          Singaporean
  patientClass            Text             CS         10           Subsidy class                   B2
  patientAddress          Text             AD         100          Primary          residential Blk                    516
                                                                   address                         Sembawang
                                                                                                   Avenue        5    #10-
                                                                                                   3429         Singapore
                                                                                                   623516
  patientTel              Text             TEL        20           Main contact number.            +6585126332
                           Table 5.2: Attributes table for ‘patient’ (patient information)

  Please refer to Appendix H for the complete list of data types (attributes) used in this
  project.



  5.4    ACCESS LEVELS

  Patient medical records exist as highly private and sensitive information and should be
  handled carefully to prevent unauthorised access. With aid of security and regulatory
  framework in place, it is essential to define system access levels for different users and
  control their access to confidential information and how the data should be used.



  Table 5.3 lists the access rights associated with each user and define the amount of
  information they can view and edit in the same EHR system, in the case of the A&E visit.
  In addition, proper staff education and user authentication framework must be put in
  place to ensure that the staffs do not misuse their access rights.

                                                Visit                                               Drug
ACTORS          Patient    Registration                        Diagnostics        Reports                            Payments
                                              Records                                            Prescriptions
Doctor            Y              Y                Y                  Y                  Y               Y               Y
 Nurse            Y              Y                Y                  Y                  Y               Y               Y
                                                               (read only)       (read only)      (read only)
Admin             Y              Y                Y                  Y                                  Y               Y


  JAN2010/BME/0046 – BME499 Capstone Project Final Report                                                   37 | P a g e
                                                                                                                  (read only)                                             (read only)
Technologist                       Y                             Y                            Y                           Y                           Y
                        (read only)                      (read only)                 (read only)
Pharmacist                         Y                             Y                            Y                           Y                           Y                           Y
                        (read only)                      (read only)                 (read only)                  (read only)                (read only)
                                                                     Table 5.3: Access Rights in Database system

     ** Letter “Y” in Access tables indicates Yes, and access rights are granted.



     5.5        HL7 REFERENCE INFORMATION MODEL

     After we have obtained the required standard data types and important functionalities of
     our system, we can create an interoperable database of consistent format and types. Here,
     we will attempt to adopt the HL7 RIM in the design of our EHR system.



     The RIM consists of six back-bone classes that have different specialized attributes as
     illustrated in Figure 5.3. To enforce semantic expressions, specific mandatory vocabulary
     domains have been defined for representing the content values of some attributes. Each
     Data Type also contains one or more Properties.
                                                                                                                                                                                     ActRelationship
                                                                                                                                                                                typeCode : CS
                                                                                                                                                                                inversionInd : BL
                                                                                                                                                          outboundRelationship
                                                                                                                                                                                contextControlCode : CS
                                                                                                                                                                           0..n contextConductionInd : BL
                                                                                                                                                                                sequenceNumber : INT
                                                                                                                                                           1 source             priorityNumber : INT
                                                                                                                                                    Act                         pauseQuantity : PQ
                                                                                                          Participation
                                                                                                                                    classCode : CS                              checkpointCode : CS
               Entity                                                                              typeCode : CS                                                                splitCode : CS
     classCode : CS                                                  Role                          functionCode : CD                moodCode : CS
                                    player                                                                                                                                      joinCode : CS
                                                       classCode : CS                              contextControlCode : CS..        id : SET<II>
     determinerCode : CS           0..1                                                                                                                                         negationInd : BL
                                                0..n   id : SET<II>                                sequenceNumber : INT . 0..n      code : CD
     id : SET<II>                                                                                                                                                               conjunctionCode : CS
     code : CE                            playedRole   code : CE                          1        negationInd : BL                 negationInd : BL
                                                                                                                                  1 derivationExpr : ST                         localVariableName : ST
     quantity : SET<PQ>                                negationInd : BL                     0..n   noteText : ED                                                                seperatableInd : BL
                                                       addr : BAG<AD>                              time : IVL<TS>                   text : ED
     name : BAG<EN>                                                                                                                                                        inboundRelationship 0..n
                                                       telecom : BAG<TEL>                                                           title : ST
     desc : ED                                                                                     modeCode : CE
     statusCode : SET<CS>                              statusCode : SET<CS>                        awarenessCode : CE               statusCode : SET<CS>                target
                                       scopedRole                                                                                   effectiveTime : GTS
     existenceTime : IVL<TS> ...                       effectiveTime : IVL<TS>                     signatureCode : CE
                                                0..n   certificateText : ED                                                         activityTime : GTS                   1
     telecom : BAG<TEL>                                                                            signatureText : ED
                                   0..1                quantity : RTO                    source performInd : BL                     availabilityTime : TS
     riskCode : CE
                                   scoper              positionNumber : LIST<INT> 1  ...           substitutionConditionCode : CE
                                                                                                                           ..       priorityCode : SET<CE>
     handlingCode : CE
                                                                                                                                    confidentialityCode : SET<CE>
                                                               1 target                                                    .        repeatNumber : IVL<INT>
                                                                                                                                    interruptibleInd : BL
                                                                           outboundLink 0..n                                        levelCode : CE
                                                                  0..n           RoleLink                                           independentInd : BL
                                                                                                                                    uncertaintyCode : CE
                                                          inboundLink typeCode : CS                                                 reasonCode : SET<CE>
                                                                         effectiveTime : IVL<TS> ...                                languageCode : CE




                                                       Figure 5.3: HL7 RIM Six Backbone Classes (in UML format)




     JAN2010/BME/0046 – BME499 Capstone Project Final Report                                                                                                                                38 | P a g e
It is extremely useful and applicable to exchange messages based on the HL7 clinical and
health data. Based on the RIM, each clinical data derived in Section 5.3 can be converted
into RIM-based components for sharing among different clinical systems to perform tasks
or transactions.



To enable interoperability, RIM classes should be incorporated into tables in the database
and each table will be referenced to other data type by a common foreign key. When the
foreign key is called upon, we will be able to access the attribute values related to it. This
complex design of database table can provide better access efficiency to the wide variety
of data types. After we have created the relational table, we will make use of Object-
Relational Database Management System to map our design tables and implement it.




5.6   PHYSICAL DESIGN

Following the identification of the system goals, conceptual and logical design, our
design is then transformed into working components such as data tables in Microsoft
Access, a SQL Design Software. Data tables are important building blocks of a database
as it stores all electronic health record in a categorised manner. SQL is capable of relating
data tables with forms for displaying, modifying and deleting of data. User is able to
access the back-end data tables using the forms as interface.



Figure 5.4 shows a data tables for patient information, created in Microsoft Access. Each
column of the selected attributes has been given their respective data types and a list of
sample patient details have been loaded onto the list. Other data tables can be found in
Appendix I.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                               39 | P a g e
                              Figure 5.4: Data table for Patient profile




5.7   USER INTERFACE

Due to the ever growing types of healthcare information and healthcare support functions,
it is important that the user interface remains as a neat graphical representation of the
available functions and its content. A good, organised and intuitive user interface allows
end-user to adapt quickly to the new system and increase the chance of winning user
acceptance.



Although we are not able to use SQL Programming to produce a prototype of an
improved EHR system, we have created a Graphical User Interface (GUI) of our
proposed system for illustration purposes. GUI Design Studio from carretta.com was
used. We may not be able to generate a prototype but an early planning of the GUI will
give us an idea how the final product will look like and discern where each element
should be placed on the interface.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                            40 | P a g e
Figure 5.5 shows an example of how our EHR system GUI will look illustrating how
patient information and the other tabs options available for navigation are displayed.




                          Figure 5.5: GUI Representation of our EHR System




5.8   SYSTEM IMPLEMENTATION

Once the improved EHR system has been created and finalized, it must be incorporated
effectively into the daily operations of the healthcare organization with adequate support
and maintenance. Implementing a new system can be a massive challenge for any
healthcare institution. It includes installation of system on all workstations,
configurations, database hardware, network equipments, conversion of data, and
possibility of redesigning processes for considerations.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                             41 | P a g e
6     DISCUSSION

A lot of investments and infocomm technologies have been used to integrate IT into
healthcare. Health-IT systems are used extensively in our healthcare eco-system to
support delivery of healthcare services and appropriate care. However, a detailed research
into the state of matters revealed that health-IT systems in Singapore are lagging behind
the rising quality expectations and the advancements of medical devices. There is thus a
strong need for an improved integrated Electronic Health Records (EHR) system as an
enabler for seamless information exchange across clusters and data standardization.



6.1     RATIONALES AND JUSTIFICATIONS FOR IMPROVEMENTS

From the interviews and literature search performed, we were able to identify many of the
current problems associated with existing EMR systems as mentioned previously. For the
problems which we have identified through system view and interviews, I was able to
support my aims with the following justifications:

      1. Integrated system to include all functions and controls –
            To cater to the diverse needs of healthcare institutions and achieve acceptance.
            To create a common platform for standardised information exchange and
             sharing.
            Replace the need of having too many systems with different functions.
            Saves time and effort to access multiple systems
            Patient is able to go to different healthcare provider for more appropriate care
             without worrying about information transfer.
            More coordinated health care services.
      2. Data standardisation.
            Encoded data for data extraction for clinical decision support, research and
             disease surveillance.
      3. One Patient, One EHR.
         One piece of information to avoid duplication.
         Patients do not have to repeat redundant tests.

JAN2010/BME/0046 – BME499 Capstone Project Final Report                               42 | P a g e
6.2     BENEFITS AND COST

The key benefits of implementing the above improved EHR are:

      1. Increase healthcare quality
      2. Improve quality of life
      3. Reduce medical costs
      4. Ability to extract important information for disease surveillance in cases of a virus
         epidemic and clinical research.



6.3     WHY HL7?

International standard such as HL7 plays a critical role in creating an opportunity for
interoperability and data exchange by allowing development of a common platform for
EMRs to connect. HL7 Version 3 has a Reference Information Model (RIM) which
provides robust ability to represent complex relationships and is an ideal modelling tool
for implementation. To achieve data standardisation, we implemented the HL7 RIM Data
Type standard in our system so that we will be in sync with other vendors who adopt HL7
RIM.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                                43 | P a g e
7      PROJECT MANAGEMENT

In order to manage the year-long Capstone project, I made used of the project
management skills acquired from UniSIM core module PMJ300 Project Management.
Emphasise has been put on project integration, scope management and time management.
Very ambitious goals were set at the commencement of the project. However due to the
lack of critical technical knowledge required to fully complete this project; I eventually
devoted much time on learning basics and reading on background information. The
project management skills were put into good use and contributed to the completion of
this project.



According to the project objectives, I was able to produce the following project schedule
(Table 7.1) and Gantt Charts (Table 7.2 and 7.3):

 Tasks and Schedule for Capstone Project JAN2010/BME/0046


                                                                      Duration
 S/N    Task Name                                                     (man-      Start       End
                                                                      days)


        Project Initial Phase


        First meet up with Supervisor for first time
 1                                                                    1 Day      30 Jan 10   30 Jan 10
        - discussion on project objectives


 2      Second meet up with Tutor on discussion of Project Proposal   1 Day      26 Feb 10   26 Feb 10


 3      Literature research                                           20 Days    16 Feb 10   7 Mar 10


 4      Preparation of Project Proposal (TMA 01)                      15 Days    22 Feb 10   8 Mar 10


 5      Submission of Project Proposal                                -          -           8 Mar 10


        Project 2nd Phase


 6      Study in details – HL7 Reference Information Model            10 Days    9 Mar 10    18 Mar 10




JAN2010/BME/0046 – BME499 Capstone Project Final Report                                            44 | P a g e
7     Design survey                                                3 Days    19 Mar 10   21 Mar 10


8     Conduct ‘Needs Assessment’ in health care industry           6 Days    22 Mar 10   27 Mar 10


9     Analyze results                                              4 Days    28 Mar 10   31 Mar 10


10    Study Object-relational mapping                              8 Days    1 Apr 10    8 Apr 10


11    Study UML Designing Methods                                  12 Days   9 Apr 10    20 Apr 10


12    Study SQL Programming                                        5 Days    21 Apr 10   25 Apr 10


13    Prepare Interim report                                       15 Days   26 Apr 10   10 May 10


      Project 3rd Phase


14    Study Database Designing process                             15 days   24 May 10   21 Jun 10


15    Conceptual Design                                            8 Days    22 Jun 10   14 Jul 10


16    Logical Design                                               8 Days    15 Jul 10   31 Jul 10


17    Physical Design                                              8 Days    1 Aug 10    14 Aug 10


18    HL7 Implementation                                           8 Days    15 Aug 10   31 Aug 10


      Project 4th Phase


19    Troubleshooting                                              5 Days    1 Sep 10    17 Sep 10


      Meet with Tutor and discuss on the evaluation and possible
20                                                                 1 Day     18 Sep 10   18 Sep 10
      further improvement of this project


21    Amendments or further improvements                           5 Days    19 Sep 10   1 Oct 10


      Project Final Phase


22    Preparation of Final Report                                  15 Days   1 Oct 10    5 Nov 10


23    Discuss with tutor on Final Report                           1 Day     6 Nov 10    6 Nov 10


24    Review and Submit Final Report                               5 Days    7 Nov 10    15 Nov 10


25    Prepare Banner for presentation                              2 Days    16 Nov 10   20 Nov 10




JAN2010/BME/0046 – BME499 Capstone Project Final Report                                      45 | P a g e
26    Prepare for Q&A session                                 3 Days   21 Nov 10   27 Nov 10

                                Table 7.1: Project Schedule




JAN2010/BME/0046 – BME499 Capstone Project Final Report                                46 | P a g e
                                                                     Jan-10          Feb-10                        Mar-10                        Apr-10                  May-10                      Jun-10
Week No.                                                               1       2     3    4       5      6     7     8    9      10     11      12    13   14    15     16    17      18   19   20     21   22   23
Activities
First meet up with Supervisor for first time
- discussion on project objectives


Second meet up with Tutor on discussion of Project Proposal

Literature research

Preparation of Project Proposal (TMA 01)

Submission of Project Proposal

Study in details – HL7 Reference Information Model

Design survey

Conduct ‘Needs Assessment’ in health care industry

Analyze results

Study Object-relational mapping

Study UML Designing methods

Study SQL Programming

Prepare Interim report

Study Database Designing process

Conceptual Design

Logical Design

Physical Design

HL7 Implementation

Troubleshooting

Meet with Tutor and discuss on the evaluation and possible further
improvement of this project

Amendments or further improvements

Preparation of Final Report

Discuss with tutor on Final Report

Review and Submit Final Report

Prepare Banner for presentation

Prepare for Q&A session




                                     Project initial phase                    Project 2nd phase        Project 3rd phase         Project 4th phase              Project Final phase


                                                                                                      Table 7.2: Project Gantt Chart (Part 1)
                                                                          Jul-10                        Aug-10                             Sep-10                     Oct-10                    Nov-10
Week No.                                                             24   25     26    27       28     29    30      31     32        33     34   35      36   37    38    39      40     41   42    43   44
Activities
First meet up with Supervisor for first time
- discussion on project objectives


Second meet up with Tutor on discussion of Project Proposal

Literature research

Preparation of Project Proposal (TMA 01)

Submission of Project Proposal

Study in details – HL7 Reference Information Model

Design survey

Conduct ‘Needs Assessment’ in health care industry

Analyze results

Study Object-relational mapping

Study UML Designing methods

Study SQL Programming

Prepare Interim report

Study Database Designing process

Conceptual Design

Logical Design

Physical Design

HL7 Implementation

Troubleshooting

Meet with Tutor and discuss on the evaluation and possible further
improvement of this project

Amendments or further improvements

Preparation of Final Report

Discuss with tutor on Final Report

Review and Submit Final Report

Prepare Banner for presentation

Prepare for Q&A session




                                     Project initial phase                Project 2nd phase           Project 3rd phase               Project 4th phase             Project Final phase


                                                                                            Table 7.3: Project Gantt Chart (Part 2)
8   CONCLUSIONS

EHR system has shown to offer many benefits such as reducing the costly medical fees,
enhancing communication and cooperatibility between healthcare providers. In order to
achieve success in this large developmental project, it will require a lot of time,
technology, manpower, monetary investments together with nation’s involvement. With
the incorporation of international standard HL7, we are able to standardise data exchange
methods.



As HL7 remains as a complex technical standard, it contains many detailed
documentations of structured data types, class diagrams, state diagrams, use case models
and terminology for adoption by IT vendors. However, its complexity and the vast
amount of information were too complicated for my full understanding and total
application. Despite much efforts made to research on the possible techniques and
methods used by other system developers, I was not able to fully implement HL7 in my
EHR design model.



An enormous amount of time was spent looking for examples of HL7 RIM
implementation. However, such searches often lead to situation whereby restricted access
to HL7 documentations hinders the process and further limited my ability to get sufficient
information for full understanding of the implementation methodology and process. Not
fully willing to accept such disappointment, the progress of this project was thus stuck at
this stage for a considerable amount of time in the search for the HL7 standards adaption.
As such, this resulted in a major delay in the subsequent steps of the project where the
full implementation of the HL7 could not be fully accomplished as originally planned.



Furthermore, as a result of the shortage of time, we also did not get the opportunity to
learn and use Object-orientated Database Management systems and Relational Database
Management systems in our system to link complex data types such as diagnostic images
and patient demographics necessary for the full implementation of the HL7 standards.
Thus the proposal to use Java and SQL Programming was also not achieved.



Nonetheless, importantly we were able to design a robust database model to show
integration and efficiency in storing patient medical record by avoiding duplication
through UML Modelling and Entity Relationship Diagram. It is with great interest and
positivity that this project has indeed provided a learning path towards Database
Designing and I believe the skills can similarly applied for other problems.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                        50 | P a g e
9   RECOMMENDATIONS

There are a lot of areas for expansion in this project due to its ability to scale-up.
Naturally, the full implementations of the HL7 standards need to be firstly achieved to
create a truly single nationwide system that allow integration and interoperability among
the healthcare clusters in Singapore. Upon the full proper implementation in Singapore,
the next step would be to look into system interoperability between countries. Achieving
this would confer significant benefits such as cost saving for patients whom are then able
to easily transfer their medical records when seeking for alternative healthcare in
different countries.




                                                                           (Chapters 1-9)

                                                               Word Count: 8,678 words




JAN2010/BME/0046 – BME499 Capstone Project Final Report                            51 | P a g e
10 CRITICAL REVIEW

Great efforts have been made in the implementation of HL7 standards in EHR. Large
amount of funds are also required for restructuring the existing medical records,
procurement of new hardware and equipments to store medical records and to establish
connection between institutions. Not many vendors and private healthcare players are
willing to invest heavily in this new system as some consider that view-only medical
information is sufficient for applying appropriate treatment and care.



A major advantage of having such a nationwide EHR system is the ability to extract data
whenever needed. This is especially important in situation of pandemic or epidemic when
disease surveillance is needed. However, such advantage do not provide much direct
benefits to the many private healthcare providers as compared to the public healthcare
institutes and as a result they are not willing to support or participate in the
implementation of such nationwide EHR system especially with the considerable
investment needed. This remains as a major roadblock and it is questionable whether the
initiative to create a new nationwide EHR platform would be feasible in Singapore
context without the government lead initiative and financial supports.



For a holistic objective to create and implement a large scale EHR system, the scope of
this project should be increased and be performed as a group to better illustrate the EHR
database design, prototype, hardware required and even the cost involved. The cost
effectiveness of the new EHR system implementation can then be appropriately
calculated to truly determine if having such a system will really bring any significant
savings.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                           52 | P a g e
11 REFLECTIONS

11.1 EXPERIENCE GAINED IN DATABASE DESIGN

As a Biomedical Engineering student in UniSIM, I was not equipped with the right sets
of skills such as UML Modelling, SQL programming, Java programming or experiences
with using Visual Basic when I took up this project. I had thought that it would be a great
learning experience to be able to learn these new skill sets based outside classroom.
Indeed, I truly experience an extraordinary learning curve trying to understand and master
these skills independently against the backdrop of my job and family commitments.



The self-learning experience was challenging, tedious and very time consuming. I had to
build a foundation for my technical understanding and it was not smooth-sailing for me.
The terms such as Database Management Systems were new to me. Luckily, technical
information is easily available on the World Wide Web so I was able to identify very
useful information to build up my foundation on database designing methods. However,
needing to juggle my current heavy work requirement and commitment also taught me
greatly about the difficulty of mastering good time-management skills needed to
accomplish every task needed within a fixed time frame.



11.2 PROBLEMS MET

The research process for this project requires the detailed understanding of current
healthcare IT systems adopted by healthcare providers so that we can better propose
constructive improvements. Due to the confidentiality of patient related information and
protection against potential hackers from the internet, healthcare institutions do not
disclose and publish any private and institutional level information online. Thus, it was
extremely difficult for me to source and research for specific facts of current systems and
whether international standards have been adopted. Fortunately, I was able to receive
kind help from 2 healthcare professionals working in a local hospital to accept a short
interview with me. Due to their busy schedule, I was only given 10mins of their time.
Such short interview also meant that I was only given a quick snapshot of the current

JAN2010/BME/0046 – BME499 Capstone Project Final Report                             53 | P a g e
status of the healthcare system in Singapore. No doubt, if given more time with them, I
would definitely learn a lot more.



In addition, on hindsight, a more realistic goal may be needed than originally envision.
Not being an expert in the field nor knowing the system, I had innocently believed that
the information required could be easily found from the internet. However, due to the
sensitive nature of all these data, there are only very limited information that could be
gather in such searches. It is with good fortune that I managed to receive the kind help of
2 healthcare professionals that helped enormously with shaping my understanding and
providing me with a glimpse of the healthcare system. As such, a more realistic goal of
perhaps researching and understanding of the HL7 standards might be more appropriate
rather than the ambitious goal of a full implementation of it given the enormous amount
of time needed just to identify and obtain even the most basic information needed to start
the project. Nonetheless, this does not take away the importance of fully implementing
the HL7 standards and having a truly single nationwide system.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                             54 | P a g e
APPENDICES

APPENDIX A – HL7 EHR-S FUNCTIONAL MODEL


The EHR-S Functional Model is composed of a functional outline (which is divided into
three sections, direct care, supportive and information infrastructure), functional profiles
(which overlay the outlined functions) and assigned priorities for the functions in the
profile. Within the three main sections are thirteen subsections.
                              DC.1 Care Management
 Direct Care                  DC.2 Clinical Decision Support
                              DC.3 Operations Management and Communication
                              S.1 Clinical Support
 Supportive                   S.2 Measurement, Analysis, Research and Reports
                              S.3 Administrative and Financial
                              IN.1 Security
                              IN.2 Health Record Information and Management
                              IN.3 Registry and Directory Services
 Information
                              IN.4 Standard Terminologies & Terminology Services
 Infrastructure
                              IN.5 Standards-based Interoperability
                              IN.6 Business Rules Management
                              IN.7 Workflow Management




JAN2010/BME/0046 – BME499 Capstone Project Final Report                              55 | P a g e
APPENDIX B – HL7 EHR-S FM DIRECT CARE FUNCTIONS
Direct care EHR-S functions are the subset of EHR-S functions that enable delivery of
healthcare and offer clinical decision support.
       ID #                                       Name
DC.1              Care Management
DC.1.1 H          Record Management
DC.1.1.1          Identify and Maintain a Patient Record
DC.1.1.2          Manage Patient Demographics
DC.1.1.3          Data and Documentation from External Sources
DC.1.1.3.1        Capture Data and Documentation from External Clinical Sources
DC.1.1.3.2        Capture Patient-Originated Data
DC.1.1.3.3        Capture Patient Health Data Derived from
                  Administrative and Financial Data and
                  Documentation
DC.1.1.4          Produce a Summary Record of Care
DC.1.1.5          Present Ad Hoc Views of the Health Record
DC.1.2            Manage Patient History
DC.1.3            Preferences, Directives, Consents and Authorizations
DC.1.3.1          Manage Patient and Family Preferences
DC.1.3.2          Manage Patient Advance Directives
DC.1.3.3          Manage Consents and Authorizations
DC.1.4            Summary Lists
DC.1.4.1          Manage Allergy, Intolerance and Adverse Reaction List
DC.1.4.2          Manage Medication List
DC.1.4.3          Manage Problem List
DC.1.4.4          Manage Immunization List
DC.1.5            Manage Assessments
DC.1.6            Care Plans, Treatment Plans, Guidelines, and Protocols
DC.1.6.1          Present Guidelines and Protocols for Planning Care
DC.1.6.2          Manage Patient-Specific Care and Treatment Plans

JAN2010/BME/0046 – BME499 Capstone Project Final Report                           56 | P a g e
DC.1.7          Orders and Referrals Management
DC.1.7.1        Manage Medication Orders
DC.1.7.2        Non-Medication Orders and Referrals Management
DC.1.7.2.1      Manage Non-Medication Patient Care Orders
DC.1.7.2.2      Manage Orders for Diagnostic Tests
DC.1.7.2.3      Manage Orders for Blood Products and Other Biologics
DC.1.7.2.4      Manage Referrals
DC.1.7.3        Manage Order Sets
DC.1.8          Documentation of Care, Measurements and Results
DC.1.8.1        Manage Medication Administration
DC.1.8.2        Manage Immunization Administration
DC.1.8.3        Manage Results
DC.1.8.4        Manage Patient Clinical Measurements
DC.1.8.5        Manage Clinical Documents and Notes
DC.1.8.6        Manage Documentation of Clinician Response to Decision Support
                Prompts
DC.1.9          Generate and Record Patient-Specific Instructions
DC.2            Clinical Decision Support
DC.2.1          Manage Health Information to Provide Decision Support
DC.2.1.1        Support for Standard Assessments
DC.2.1.2        Support for Patient Context- Driven Assessments
DC.2.1.3        Support for Identification of Potential Problems and Trends
DC.2.1.4        Support for Patient and Family Preferences
DC.2.2          Care and Treatment Plans, Guidelines and Protocols
DC.2.2.1        Support for Condition Based Care and Treatment Plans, Guidelines,
                Protocols
DC.2.2.1.1      Support for Standard Care Plans, Guidelines, Protocols
DC.2.2.1.2      Support for Context-Sensitive Care Plans, Guidelines, Protocols
DC.2.2.2        Support Consistent Healthcare Management of Patient Groups or
                Populations


JAN2010/BME/0046 – BME499 Capstone Project Final Report                           57 | P a g e
DC.2.2.3        Support for Research Protocols Relative to Individual Patient Care
DC.2.2.4        Support Self-Care
DC.2.3          Medication and Immunization
DC.2.3.1        Support for Medication and Immunization Ordering
DC.2.3.1.1      Support for Drug Interaction Checking
DC.2.3.1.2      Support for Patient Specific Dosing and Warnings
DC.2.3.1.3      Support for Medication Recommendations
DC.2.3.2        Support for Medication and Immunization Administration
DC.2.4          Orders, Referrals, Results and Care Management
DC.2.4.1        Create Order Set
DC.2.4.2        Support for Non-Medication Ordering
DC.2.4.3        Support for Result Interpretation
DC.2.4.4        Support for Referrals
DC.2.4.4.1      Support for Referral Process
DC.2.4.4.2      Support for Referral Recommendations
DC.2.4.5        Support for Care Delivery
DC.2.4.5.1      Support for Safe Blood Administration
DC.2.4.5.2      Support for Accurate Specimen Collection
DC.2.5          Support for Health Maintenance: Preventive Care and Wellness
DC.2.5.1        Present Alerts for Preventive Services and Wellness
DC.2.5.2        Notifications and Reminders for Preventive Services and Wellness
DC.2.6          Support for Population Health
DC.2.6.1        Support for Epidemiological Investigations of Clinical Health Within
                a Population.
DC.2.6.2        Support for Notification and Response
DC.2.6.3        Support for Monitoring Response Notifications Regarding a Specific
                Patient’s Health
DC.2.7          Support for Knowledge Access
DC.2.7.1        Access Healthcare Guidance
DC.2.7.2        Patient Knowledge Access


JAN2010/BME/0046 – BME499 Capstone Project Final Report                         58 | P a g e
DC.3            Operations Management and Communication
DC.3.1          Clinical Workflow Tasking
DC.3.1.1        Clinical Task Assignment and Routing
DC.3.1.2        Clinical Task Linking
DC.3.1.3        Clinical Task Tracking
DC.3.2          Support Clinical Communication
DC.3.2.1        Support for Inter-Provider Communication
DC.3.2.2        Support for Provider –Pharmacy Communication
DC.3.2.3        Support for Communications Between Provider and Patient and/or
                the Patient Representative
DC.3.2.4        Patient, Family and Care Giver Education
DC.3.2.5        Communication with Medical Devices




JAN2010/BME/0046 – BME499 Capstone Project Final Report                  59 | P a g e
APPENDIX         C     –   MINUTES        OF       INTERVIEWS        WITH       HEALTHCARE
PROFESSIONALS
Date: 20th July 2010
Time: 12:05pm
Interview Title: Interview 1
Present: Evon Ong and healthcare professional, Person A
Venue: Standing outside a patient’s ward in hospital
Qn1         Hi, Are you using and accessing electronic health records in the wards?
Person A    Yes I am, I log in to System A daily to access patient records to help me decide the
            application of appropriate care to my patients.
Qn2         What do you access in System A in your line of work?
Person A    Due to the restricted access, we are only allowed to view patient health reports and
            results from the system.
Qn3         Based on the information you can access, are there any useful health records which
            are missing from this system?
Person A    Certainly! Till date, we are still unable to view ECG records in the system as the
            machines still generates hard copy records and it is almost impossible for anyone to
            enter the data into the system. So we have to keep a separate folder for ECG records,
            it is very inconvenient for us, especially when we need to access information quickly.
Qn4         That sounds really inconvenient.
            Talking of data entry, are you given access to edit information in System A?
Person A    Not at all, we are not given rights to write notes in a patient health record. Although
            we are the primary care providers for patients, we are unable to note down important
            observations and special instructions. Despite restricted editing rights, we can easily
            access all patients’ profile in the system!
Qn5         That is indeed convenient. Do you have to log-in specially to see record of other
            patients who are not under your care?
Person A    Not at all.. anyone can access patient records once they log in to the system with their
            log-in IDs.
Qn6         If that is the case, do you know if the system actually track your access to other
            patient profile not under your care?
Person A    Hmmm... not that I know of. I hope this information helps you!



JAN2010/BME/0046 – BME499 Capstone Project Final Report                                     60 | P a g e
Date: 20th July 2010
Time: 1:10pm
Interview Title: Interview 2
Present: Evon Ong and healthcare professional, Person B
Venue: Seated in a healthcare facility in front of a workstation
Qn1         Hi, are you using and accessing electronic health records?
Person B    Yes I am, I use System B daily to access patient list and to track which of the patient
            are required to go through tests. I can also read their health records at the same time.
            Here, let me show you. (Person B logs into System B)
Qn2         Wow that is alot of function tabs and information available. You have access to all of
            them?
Person B    Of course not, although we may see a lot of information and functional tabs at log-in,
            the system usually have programmed access controls for all users, so we can only
            access and see the information we are allowed to.
Qn3         Can this system access all patient’s profile in the hospital?
Person B    Yes! I can see all the patient health records and this system is also shared with other
            healthcare facilities in the same cluster. However it looks like only InPatient data is
            shared and not all. Even if the patient profile does not reside in our local system,
            System B will fetch data from other facilities for display in our workstations.
Qn4         That sounds really convenient.
            Talking of data entry, are you given access to edit information in System B?
Person B    No, only view permission is given.
Qn5         Do you happen to also access System A for your work?
Person B    Yes.
Qn6         Are you able to edit the information inside?
Person B    Not so much of editing existing information. But due to my scope of work, I am able
            to contribute remarks, findings and give special instructions in System A.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                                       61 | P a g e
    APPENDIX D – USE CASE DESCRIPTIONS
Actor       Use Case                        Process Description
                                            7. Admin enters Patient ID
                                            8. System displays Patient information tab and the
            Register Patient                   following 6 tabs:
                                               8.1. Registration
            GOAL: A patient is                 8.2. Visit Records
            received         at      the       8.3. Diagnostics
            registration counter and           8.4. Reports
Admin       receives a Queue Card.             8.5. Drug Prescriptions
                                               8.6. Payments
            **Queue card contains 9. Admin goes to the Register Patient tab to verify
            Patient      name       and        and update the arrival or re-visiting status
            identification          (ID) 10. System records the time of Patient arrival.
            number                          11. System creates a new Visit Record is Patient is
                                               not making a re-visit
                                            12. Admin issues a Queue Card to patient.
            Health Screening and 1. Nurse receives Queue Card from Patient enters
            Record Retrieval                   Patient ID into System
                                            2. System displays Patient information and the 6
            GOAL: Queue card is                tabs accordingly.
            passed to the Nurse at 3. Nurse selects Visit Records to view past visit
Nurse
            screening station. Nurse           records.
            performs              health       3.1. System displays visits related to Patient ID
            interview at entrance. A 4. Nurse opens visit record to update observations
            brief     observation      is      at health screening station
            saved into visit record.        5. System saves visit record after completion.
            Consultation                    1. Doctor receives Queue Card from Patient enters
Doctor                                         Patient ID
            GOAL: Queue card is 2. System displays Patient information and the 6


    JAN2010/BME/0046 – BME499 Capstone Project Final Report                                   62 | P a g e
            passed to the Doctor at         tabs accordingly.
            consultation      station. 3. Doctor goes to the Reports tab
            Doctor conducts health 4. System displays list of past Reports associated
            assessment and records          with Patient ID to access orders and reports
            observations          and       history
            findings.                    5. Doctor selects Patient’s current visit with
                                            “Arrived” status and clicks “New Medical
                                            Report”
                                         6. System launches Report Writer
                                         7. Doctor conducts physical assessment on Patient
                                            while noting down the findings using Report
                                            Writer
                                         8. System saves and creates a timestamp on the
                                            Medical Report.
                                         1. Doctor goes to the Diagnostics tab
                                         2. System displays list of past test/diagnostic
            Process        diagnostic
                                            orders associated with Patient ID
            tests/orders
                                         3. Doctor selects “New Order” for Patient
                                         4. System generates a new order and displays
            GOAL: Doctor makes a
Doctor                                      options.
            diagnostic test order for
                                         5. Doctor puts in an order (EG. Chest X-Ray)
            patient and is sent to the
                                         6. System sends order to Technologist in the
            Technologist           for
                                            respective department for completion
            completion.
                                         7. An order ID is created based on the type of
                                            orders given.
            Review         Diagnostic 1. Doctor enters Patient ID
            Results                      2. System displays Patient information and the 6
                                            tabs accordingly.
Doctor
            GOAL:             Patient 3. Doctor goes to the Reports tab
            completes test ordered 4. System displays list of past Reports associated
            by Doctor and returns to        with Patient ID

    JAN2010/BME/0046 – BME499 Capstone Project Final Report                          63 | P a g e
            the consultation station 5. Reports are listed according to their creation
            with Queue card. Doctor               date.
            access diagnostic results 6. Doctor opens and reviews the Report. (EG. X-
            (reports)     from        work        ray report)
            station      and        updates 7. Doctor makes care plans for the Patient.
            previous        observation 8. Doctor re-opens the Medical Report which he
            notes.                                wrote earlier and selects “Edit” to add new
                                                  findings/conclusions derived from the chest X-
                                                  Ray
                                               9. System saves and creates a new timestamp on
                                                  Doctor’s Medical Report
                                               1. Doctor goes to the Drug Prescriptions tab
            Drug Prescription                  2. System displays list of past prescriptions and
                                                  drug allergies associated with Patient ID.
            GOAL: After making 3. Doctor selects “New Prescription” to order
            care      plans,        Doctor        medications for Patient
            orders drug for patient 4. Drugs code, name and dosage amounts are
Doctor
            through the system and                entered into the System.
            is     validated        by     a 5. System saves and generates a Prescription ID.
            Pharmacist. Drugs are 6. The completed prescription is sent to the
            collected          at        the      Pharmacist for validation and packing
            Pharmacy.                          7. Patient is instructed to collect the prescribed
                                                  medication directly at the Pharmacy
            Discharge                          1. Doctor goes to the Visit Records tab
                                               2. System summarizes the following activities
            GOAL: While Patient is                which have been performed:
            collecting      the       drug,       2.1. Health consultation & assessment
Doctor
            Doctor       verifies        and      2.2. Diagnostic Orders – Tests/X-Ray
            discharge patient from                2.3. Drug Prescriptions
            the department. System                2.4. Reports generated
            will need to make sure 3. Doctor verifies and confirms the summary

    JAN2010/BME/0046 – BME499 Capstone Project Final Report                                    64 | P a g e
           that the drugs are duly 4. Doctor clicks “Discharge Patient”
           collected            before 5. Patient can proceed to make payment at the
           summarizing              visit      Cashier where the Administrator is.
           record.
                                            1. Administrator enters Patient ID and goes to the
                                               Payments tab
           Payment
                                            2. System displays the list of items and the costs.
                                            3. Administrator verifies with Patient on the list of
           GOAL: Queue card is
                                               services/items received.
           passed        to          the
                                            4. System totals up the cost
Admin      Administrator      at     the
                                            5. Administrator collects payment according to
           cashier. Patient makes
                                               Patient preferred method of payment
           payment     for    all    the
                                            6. Admin takes note of payment method and
           services, test and drugs
                                               clicks “PAID” to complete payment process
           received.
                                            7. System saves and creates a timestamp on the
                                               Payment record




   JAN2010/BME/0046 – BME499 Capstone Project Final Report                                 65 | P a g e
APPENDIX E – ERD NORMALISATION TECHNIQUE
1st Normal Form
The requirements to satisfy the 1st NF:
      Each table has a primary key: minimal set of attributes which can uniquely
       identify a record
      The values in each column of a table are atomic (No multi-value attributes
       allowed).
      There are no repeating groups: two columns do not store similar information in
       the same table.


   Un-normalized Students table:

Student#          AdvID         AdvName         AdvRoom          Class1        Class2

123               123A          James           555              102-8         104-9

124               123B          Smith           467              209-0         102-8


   Normalized Students table:

Student#           AdvID         AdvName       AdvRoom          Class#

123                123A          James         555              102-8

123                123A          James         555              104-9

124                123B          Smith         467              209-0

124                123B          Smith         467              102-8



2nd Normal Form

The requirements to satisfy the 2nd NF:
      All requirements for 1st NF must be met.
      Redundant data across multiple rows of a table must be moved to a separate table.
           O The resulting tables must be related to each other by use of foreign key.
JAN2010/BME/0046 – BME499 Capstone Project Final Report                           66 | P a g e
Students table

Student#         AdvID    AdvName          AdvRoom

123              123A     James            555

124              123B     Smith            467



Registration table

Student#                    Class#

123                         102-8

123                         104-9

124                         209-0

124                         102-8



3rd Normal Form
The requirements to satisfy the 3rd NF:
      All requirements for 2nd NF must be met.
      Eliminate fields that do not depend on the primary key;
          That is, any field that is dependent not only on the primary key but also on
           another field must be moved to another table.


Students Table:

Student#          AdvID         AdvName           AdvRoom

123               123A          James             555

124               123B          Smith             467




JAN2010/BME/0046 – BME499 Capstone Project Final Report                         67 | P a g e
Student Table:

Student#                   AdvID

123                        123A

124                        123B



Advisor Table:

AdvID              AdvName                   AdvRoom

123A               James                     555

123B               Smith                     467




JAN2010/BME/0046 – BME499 Capstone Project Final Report   68 | P a g e
APPENDIX F – SQL (MS ACCESS) DATA TYPES
Microsoft Access Data Types
Data type        Description                                                     Storage
Text             Use for text or combinations of text and numbers. 255
                 characters maximum
Memo             Memo is used for larger amounts of text. Stores up to 65,536
                 characters. Note: You cannot sort a memo field. However,
                 they are searchable
Byte             Allows whole numbers from 0 to 255                              1 byte
Integer          Allows whole numbers between -32,768 and 32,767                 2 bytes
Long             Allows    whole    numbers      between   -2,147,483,648     and 4 bytes
                 2,147,483,647
Single           Single precision floating-point. Will handle most decimals      4 bytes
Double           Double precision floating-point. Will handle most decimals      8 bytes
Currency         Use for currency. Holds up to 15 digits of whole dollars, plus 8 bytes
                 4 decimal places. Tip: You can choose which country's
                 currency to use
AutoNumber       AutoNumber fields automatically give each record its own 4 bytes
                 number, usually starting at 1
Date/Time        Use for dates and times                                         8 bytes
Yes/No           A logical field can be displayed as Yes/No, True/False, or 1 bit
                 On/Off. In code, use the constants True and False (equivalent
                 to -1 and 0). Note: Null values are not allowed in Yes/No
                 fields
Ole Object       Can store pictures, audio, video, or other BLOBs (Binary up              to
                 Large OBjects)                                                  1GB
Hyperlink        Contain links to other files, including web pages
Lookup Wizard Let you type a list of options, which can then be chosen from a 4 bytes
                 drop-down list



JAN2010/BME/0046 – BME499 Capstone Project Final Report                            69 | P a g e
APPENDIX G – HL7 DATA TYPES
HL7 Version 3 Basic Data type Specifications


Name                  Symbol Description
Boolean               BL      The Boolean type stands for the values of two-valued
                              logic. A Boolean value can be either true or false.
Encapsulated Data     ED      Data that is primarily intended for human interpretation
                              or for further machine processing outside the scope of
                              this   specification.   This   includes   unformatted      or
                              formatted    written    language,   multimedia    data,    or
                              structured information in as defined by a different
                              standard (e.g., XML-signatures.) Instead of the data
                              itself, an ED may contain only a reference (see TEL.)
                              Note that the ST data type is a specialization of the ED
                              data type when the ED media type is text/plain.
Character String      ST      Text data, primarily intended for machine processing
                              (e.g., sorting, querying, indexing, etc.) Used for names,
                              symbols, and formal expressions.) Note that the ST data
                              type is a specialization of the ED data type when the ED
                              media type is text/plain.
Coded        Simple CS        Coded data, consists of a code and display name. The
Value                         code system and code system version is fixed by the
                              context in which the CS value occurs. CS is used for
                              coded attributes that have a single HL7-defined value
                              set.
Concept Descriptor    CD      Coded data, is like a CE with the extension of modifiers.
                              Modifiers for codes have an optional role name and a
                              value. Modifiers allow one to express, e.g., "FOOT,
                              LEFT" as a postcoordinated term built from the primary
                              code "FOOT" and the modifier "LEFT".
Instance Identifier   II      An identifier to uniquely identify an individual instance.

JAN2010/BME/0046 – BME499 Capstone Project Final Report                             70 | P a g e
                             Examples are medical record number, order number,
                             service catalog item number, etc. Based on the ISO
                             Object Identifier (OID)
Telecommunication TEL        A telephone number or e-mail address specified as a
Address                      URL. In addition, this type contains a time specification
                             when that address is to be used, plus a code describing
                             the kind of situations and requirements that would
                             suggest that address to be used (e.g., work, home, pager,
                             answering machine, etc.)
Postal Address      AD       For example, a mailing addresses. Typically includes
                             street or post office Box, city, postal code, country, etc.
Person Name         PN       A name of a person. Person names usually consist of
                             several name parts that can be classified as given, family,
                             nickname etc. PN is a restriction of EN.
Integer Number      INT      Positive and negative whole numbers typically the
                             results of counting and enumerating. The standard
                             imposes no bounds on the size of integer numbers.
Decimal number      REAL     Fractional numbers. Typically used whenever quantities
                             are measured, estimated, or computed from other real
                             numbers. The typical representation is decimal, where
                             the number of significant decimal digits is known as the
                             precision.
Physical Quantity   PQ       A dimensioned quantity expressing the result of
                             measurement. It consists of a real number value and a
                             physical unit. Physical quantities are often constrained to
                             a certain dimension by specifying a unit representing the
                             dimension (e.g. m, kg, s, kcal/d, etc.) However, physical
                             quantities should not be constrained to any particular unit
                             (e.g., should not be constrained to centimeter instead of
                             meter or inch.)
Monetary Amount     MO       The amount of money in some currency. Consists of a

JAN2010/BME/0046 – BME499 Capstone Project Final Report                           71 | P a g e
                             value and a currency denomination (e.g., U.S.$, Pound
                             sterling, Euro, Indian Rupee.)
Point in Time       TS       A time stamp.
General     Timing GTS       One or more time intervals used to specify the timing of
Specification                events. Every event spans one time interval (occurrence
                             interval). A repeating event is timed through a sequence
                             of such occurrence intervals. Such timings are often
                             specified not directly as a sequence of intervals but as a
                             rule, e.g., "every other day (Mon - Fri) between 08:00
                             and 17:00 for 10 minutes."




JAN2010/BME/0046 – BME499 Capstone Project Final Report                         72 | P a g e
APPENDIX H – DATA TYPES SPECIFICATIONS
patient
Description: Patient’s personal and contact information.
One patient should only have one set of information.
Attribute           MS            HL7    Max       Description              Example/Format
                    Access        Data Length
                    Data          type   (char)
                    Types
patientID (PK)      Text          II     15        Patient’s      unique S7850631F          or
                                                   identification     or E6052312P
                                                   passport number          (foreigners)
patientName         Text          PN     50        Patient’s         full Siti       Norharti
                                                   name                     Binte     Ibrahim
                                                                            Hafiz
patientGender       Yes/No        BL     1         Patient’s gender         F or M
patientDOB          Date/Time     TS     17        Patient’s Date of dd/mm/yyyy,
                                                   Birth, if known. hh:mm
                                                   Otherwise, input
                                                   estimated DOB.
patientAge          Integer       INT    3         Patient’s         age 46
                                                   according to the
                                                   actual DOB, if
                                                   known.
patientRace         Text          ST     10        Primary          race Malay
                                                   which          Patient
                                                   belongs to.
patientCitizenship Text           ST     20        Patient’s                Singaporean
                                                   nationality.
patientClass        Text          CS     10        Subsidy class            B2
patientAddress      Text          AD     100       Primary                  Blk            516


JAN2010/BME/0046 – BME499 Capstone Project Final Report                                73 | P a g e
                                                 residential               Sembawang
                                                 address                   Avenue 5 #10-
                                                                           3429     Singapore
                                                                           623516
patientTel          Text        TEL     20       Main           contact +6585126332
                                                 number.


registration
Description: Admission information recorded upon arrival.
One registration per day.
Attribute         MS Access HL7        Max      Description                       Example
                  Data Types    Dat    Lengt
                                a      h
                                type
visitID (PK)      Text          II     9        System-generated           visit V20010652
                                                identification       number
                                                after successful arrival of
                                                a Patient at the hospital.
patientID (FK1)   Text          II     15       Patient’s             unique S7850631F or
                                                identification or passport E6052312P
                                                number                            (foreigners)
admissionType     Text          CS     10       Method of admission into Em
                                                hospital
                                                Ac – Accident
                                                Em – Emergency
                                                LD – Labor/Delivery
                                                Sc – Scheduled
                                                Ro – Routine
admissionDate     Date/Time     TS     10       Date       of    arrival     at dd/mm/yyyy
                                                Hospital             (system
                                                timestamp)

JAN2010/BME/0046 – BME499 Capstone Project Final Report                                74 | P a g e
admissionTime      Date/Time      TS         5       Time       of    arrival    at hh:mm
                                                     Hospital             (system
                                                     timestamp)
apptDate           Date/Time      TS         10      Scheduled       appointment dd/mm/yyyy
                                                     Date to arrive
apptTime           Date/Time      TS         5       Scheduled       appointment hh:mm
                                                     Time to arrive
apptLocation       Text           CS         20      Department in which the Cardiology
                                                     Patient is registered to.
adminName          Text           CS         6       Contains the Staff ID of 263540
                                                     the    administrator       who
                                                     registered the Patient’s
                                                     arrival – System should
                                                     automatically        display
                                                     staff name


visit_records
Description: Summary of patient’s visit to hospital.
One registration creates one visit record.
Attribute          MS Access HL7             Max     Description                      Example
                   Data Types     Dat        Lengt
                                  a          h
                                  type
visitID (PK)       Text           II         9       System-generated           visit V20010652
                                                     identification number after
                                                     successful arrival of a
                                                     Patient at the hospital.
patientID (FK1)    Text           II         15      Patient’s              unique S7850631F or
                                                     identification or passport E6052312P
                                                     number                           (foreigners)
orderID (FK2)      Text           II         9       System-generated           order O31268900

JAN2010/BME/0046 – BME499 Capstone Project Final Report                                  75 | P a g e
                                             verification number after a
                                             successful order.
reportID (FK3)   Text         II     9       System-generated        report R40212550
                                             verification number after
                                             completing a report.
prescrID (FK4)   Text         II     9       System-generated          drug P51198110
                                             prescription    verification
                                             number after submitting a
                                             successful prescription to
                                             Pharmacy.
arrivalFever     Yes/No       BL     1       Patient’s fever status at Yes
                                             arrival.
arrivalTemp      Integer      REA 4          Patient’s temperature at 36.7
                              L              arrival.
arrivalTravel    Yes/No       BL     1       Indication if Patient has Yes/No
                                             travelled in past week.
arrivalCountry   Text         ST     75      Last country visited.           United States
                                                                             of    America,
                                                                             New York
arrivalObserv    Memo         ED     1000    Observations and health Text text text...
                                             complaints                and
                                             information from Patient.
visitDesc        Text         ED     300     A short description of visit Text text text...
                                             purpose.
docIC            Text         CS     6       Clinician who is assigned 15137H
                                             to be in-charge of Patient,
                                             enter Doctor’s MCR no. –
                                             System                 should
                                             automatically       display
                                             Doctor’s name
visitStatus      Text         CS     2       Status of Patient in the OP

JAN2010/BME/0046 – BME499 Capstone Project Final Report                           76 | P a g e
                                                 hospital
                                                 AR – arriving
                                                 OP – outpatient
                                                 IP – inpatient
                                                 DC - discharged


diag_orders
Description: Information on diagnostic test and orders which are ordered by Doctors, for
Patients.
One patient can have many diagnostic tests/orders.
Attribute         MS Access HL7         Max      Description                       Example
                  Data Types     Dat    Lengt
                                 a      h
                                 type
orderID (PK)      Text           II     9        System-generated         order O31268900
                                                 verification number after a
                                                 successful order.
patientID (FK1)   Text           II     15       Patient’s            unique S7850631F or
                                                 identification or passport E6052312P
                                                 number.                           (foreigners)
visitID (FK2)     Text           II     9        System-generated           visit V20010652
                                                 identification number after
                                                 successful arrival of a
                                                 Patient at the hospital.
orderDate         Date/Time      TS     10       Request date which the dd/mm/yyyy
                                                 specific    order/test       is
                                                 required to be carried out.
orderType         Text           CD     10       Type of order request MRI225L
                                                 required to be carried out.
                                                 The orders are coded and
                                                 the last letter indicates

JAN2010/BME/0046 – BME499 Capstone Project Final Report                                77 | P a g e
                                                location of the site of
                                                interest.
orderDesc          Text           ED      300   A short description on the Text text text...
                                                area of the body which we
                                                are         interested               in
                                                examining,                or       any
                                                findings         which          require
                                                further clarifications.
orderReason        Text           ED      300   A short phrase on why the Tumor
                                                order is required.                        detected below
                                                                                          skin…
orderPriority      Text           ST      1     Urgency          of       the    order P
                                                requested.
                                                S – Stat (do immediately)
                                                A – As soon as Rpossible
                                                R – routine
                                                P – Pre-operative
                                                T – timing critical
orderStatus        Text           CS      2     Status of order                           CM
                                                CA – cancelled
                                                CM – completed
                                                HD – on hold
                                                IP – in process
                                                SC - scheduled
orderCost          Currency       MO      14    Cost        of        the        order S$568.30
                                                requested             –         system
                                                generated


diag_reports
Description: A document which is generated by technologist and doctors to record their
findings during and after diagnostic tests.

JAN2010/BME/0046 – BME499 Capstone Project Final Report                                        78 | P a g e
One test has one report. A patient can have many reports.
Attribute         MS Access HL7         Max      Description                     Example
                  Data Types     Dat    Lengt
                                 a      h
                                 type
reportID (PK)     Text           II     9        System-generated       report R40212550
                                                 verification number after
                                                 completing a report.
patientID (FK1)   Text           II     15       Patient’s              unique S7850631F or
                                                 identification or passport E6052312P
                                                 number.                         (foreigners)
orderID (FK2)     Text           II     9        System-generated         order O31268900
                                                 verification number after a
                                                 successful order.
visitID (FK3)     Text           II     9        System-generated           visit V20010652
                                                 identification number after
                                                 successful arrival of a
                                                 Patient at the hospital.
createdDate       Date/Time      TS     10       Date which the report was dd/mm/yyyy
                                                 created.            (system
                                                 timestamp)
createdTime       Date/Time      TS     5        Time when the report was hh:mm
                                                 created.            (system
                                                 timestamp)
reportType        Text           ST     2        The document type which PR
                                                 the report belongs to:
                                                 CN – consultation
                                                 DI – Diagnostic Imaging
                                                 DS – discharge summary
                                                 ED          –    emergency
                                                 department report

JAN2010/BME/0046 – BME499 Capstone Project Final Report                              79 | P a g e
                                             PR – progress note
reportVersion    Integer      REA 3          Version      of     the    report 2.1
                              L              created, dependent on the
                                             number of times the report
                                             is edited.
reportConfid     Text         CS     1       Document confidentiality R
                                             status
                                             V – Very restricted
                                             R – Restricted
                                             U – Usual Control
reportContent    Memo         ED     30,00   Document body content, Text text text...
                                     0       usually long and uses
                                             many medical terms
reportStatus     Text         CS     3       Report status                       Doc
                                             Dic – dictated
                                             Doc – documented
                                             Pro – In progress
                                             Inc – incomplete
reportWriter     Text         CS     6       Creator of the particular 15137H
                                             report document, it could
                                             be either a staff nurse or
                                             Doctor. Staff ID or MCR
                                             number are to be keyed in
                                             respectively.
repeditDate      Date/Time    TS     10      Date which the report was dd/mm/yyyy
                                             last      edited.         (system
                                             timestamp).
repeditTime      Date/Time    TS     5       Time which the report was hh:mm
                                             last      edited.         (system
                                             timestamp).
repEditor        Text         CS     6       Person who edited the 15137H

JAN2010/BME/0046 – BME499 Capstone Project Final Report                              80 | P a g e
                                                   report must be recorded.
                                                   The system should capture
                                                   the person ID at log-in.


drug_prescp
Description: A list of medications which is prescribed to a Patient for treatment.
A patient can have many drug prescriptions given.
Attribute          MS Access HL7          Max      Description                      Example
                   Data Types     Dat     Lengt
                                  a       h
                                  type
prescrID (PK)      Text           II      9        System-generated          drug P51198110
                                                   prescription      verification
                                                   number after submitting a
                                                   successful prescription to
                                                   Pharmacy.
prescrCode         Text           CS      10       Unique      National      Drug 58627-0601
(PK)                                               Code for the prescribed
                                                   drug.
patientID (FK1)    Text           II      15       Patient’s                unique S7850631F or
                                                   identification or passport E6052312P
                                                   number                           (foreigners)
drugAllergies      Text           CS      50       List of drugs which patient Penicillin
                                                   is allergic to.
prescrDate         Date/Time      TS      10       Date     which     the    drug dd/mm/yyyy
                                                   prescription was created.
                                                   (system timestamp)
prescrTime         Date/Time      TS      5        Time      when    the     drug hh:mm
                                                   prescription was created.
                                                   (system timestamp)
prescrVersion      Integer        REA 3            Version     of    the     drug 1.4

JAN2010/BME/0046 – BME499 Capstone Project Final Report                                 81 | P a g e
                              L              prescription           created,
                                             dependent on the number
                                             of times the prescription
                                             may be edited.
prescrEditdate   Date/Time    TS     10      Date         which            the dd/mm/yyyy
                                             prescription      was        last
                                             edited.                (system
                                             timestamp).
prescrEdittime   Date/Time    TS     5       Time         which            the hh:mm
                                             prescription      was        last
                                             edited.                (system
                                             timestamp).
prescrAmount     Text         PQ     10      Dosage and strength of the kcal/d
                                             drug prescribed.
prescrTimeunit   Text         GTS    100     Frequency of drug intake.           3       tablets,
                                                                                 twice a day,
                                                                                 until 18th Dec
                                                                                 2010
prescrEffdate    Date/Time    TS     10      Start date for drug intake.         dd/mm/yyyy
prescrUnitcost   Currency     MO     12      Cost of drug prescribed by S$568.30
                                             item.
prescrNotes      Memo         ED     1000    Additional                          Text text text...
                                             notes/instructions      to    be
                                             attached        with         drug
                                             prescription.
prescrDoc        Text         CS     6       Doctor who created and 15137H
                                             edited          the          drug
                                             prescription. MCR number
                                             is entered – system can
                                             display doctor’s name.



JAN2010/BME/0046 – BME499 Capstone Project Final Report                              82 | P a g e
statement
Description: An invoice statement which summarises the total and the itemised cost of the
services and tests which has been provided for Patient during time of stay in hospital.
Attribute          MS Access HL7         Max      Description                      Example
                   Data Types     Dat    Lengt
                                  a      h
                                  type
invoiceID (PK)     Currency       II     10       System-generated invoice IV80163002
                                                  identification number after
                                                  Administrator              has
                                                  confirmed the charges and
                                                  is now ready to collect
                                                  payment.
patientID          Text           II     15       Patient’s            unique S7850631F or
                                                  identification or passport E6052312P
                                                  number                           (foreigners)
orderID            Text           II     9        System-generated       order O31268900
                                                  verification number after a
                                                  successful order.
visitID            Text           II     9        System-generated           visit V20010652
                                                  identification number after
                                                  successful arrival of a
                                                  Patient at the hospital.
prescrID           Text           II     9        System-generated           drug P51198110
                                                  prescription    verification
                                                  number after submitting a
                                                  successful prescription to
                                                  Pharmacy.
costUnit           Currency       MO     14       Cost of services, tests and S$568.30
                                                  drugs received during visit
                                                  to hospital.

JAN2010/BME/0046 – BME499 Capstone Project Final Report                                83 | P a g e
invoiceTotal     Currency     MO     14      Total cost of one hospital S$1,568.30
                                             visit.
chargeType       Text         ST     10      Patient preferred method Cash
                                             of payment.
invoiceDate      Date/Time    TS     10      Date which the tax invoice dd/mm/yyyy
                                             was      created.    (system
                                             timestamp)
invoiceTime      Date/Time    TS     5       Time when the tax invoice hh:mm
                                             was      created.    (system
                                             timestamp)
invoiceStatus    Text         CS     10      Status    of   the   invoice Paid
                                             generated.




JAN2010/BME/0046 – BME499 Capstone Project Final Report                      84 | P a g e
APPENDIX I – MS ACCESS DATA TABLES
Entity name: patient




Entity name: registration




JAN2010/BME/0046 – BME499 Capstone Project Final Report   85 | P a g e
Entity name: visit_records




Entity name: diag_orders (short for Diagnostic orders)




JAN2010/BME/0046 – BME499 Capstone Project Final Report   86 | P a g e
Entity name: diag_report (short for Diagnostic Reports)




Entity name: drug_prescp (short for Drug Prescriptions)




JAN2010/BME/0046 – BME499 Capstone Project Final Report   87 | P a g e
Entity name: statement




JAN2010/BME/0046 – BME499 Capstone Project Final Report   88 | P a g e
REFERENCES

1
      Health  Information    and     Management         Systems,     Electronic   Health     Records      -
http://www.himss.org/ASP/topics_ehr.asp
2
 Infocomm Development Authority of Singapore (iDA), June 2006, iN2015 Healthcare and Biomedical
Sciences Report
3
    HL7 Electronic Health Record System                 Functional   Model    (EHR-S       FM),    HL7    -
http://www.hl7.org/ehr/downloads/index_2007.asp
4
      Health  Information    and     Management         Systems,     Electronic   Health     Records      -
http://www.himss.org/ASP/topics_ehr.asp
5
 Database management system, Wikipedia - http://en.wikipedia.org/wiki/Database_management_system
6
           Unified           Modelling        Language           (UML),         Wikipedia        -
http://en.wikipedia.org/wiki/Unified_Modeling_Language
7
  Electronic Health Records Overview, National Institutes of Health, National Center for Research
Resources - http://www.ncrr.nih.gov/publications/informatics/ehr.pdf
8
    Health Level 7 (HL7), http://www.hl7.org/
9
    HL7 Electronic Health Record System                 Functional   Model    (EHR-S       FM),    HL7    -
http://www.hl7.org/ehr/downloads/index_2007.asp
10
  Chien Earn LEE, June 2006, Singapore Case Study: EMR Exchange, Health Information Technology and
Policy Briefing Book, Pg 17
11
  Ministry of Health, 3 March 2010, Question No: 302, Update on the National Electronic Health Records
System, Parliamentary QA
12
     Health Level 7 Singapore, http://www.hl7.org.sg/
13
  Chien Earn LEE, June 2006, Singapore Case Study: EMR Exchange, Health Information Technology and
Policy Briefing Book, Pg 17
14
     Health Level 7, Reference Information Model, http://www.hl7.org/implement/standards/rim.cfm
15
  Infocomm Development Authority of Singapore (iDA), June 2006, iN2015 Healthcare and Biomedical
Sciences Report




JAN2010/BME/0046 – BME499 Capstone Project Final Report                                            89 | P a g e

								
To top