7 Patient registry information system development and implementation

From Parent-Wiki
Jump to: navigation, search

Methodological guidelines » 7 Patient registry information system development and implementation

7.1 Computer based Patient Registry Information System
7.2 Development of Registry Information System
7.2.1 Important role of users
7.2.2 Software testing
7.2.3 Training
7.3 Different options to obtain the Registry system

Computer based patient registry information systems are nowadays typically web-based and allow end users to access the study database through the Web using a web browser. Many of them also operate on Software as a Service model (SaaS).

Key principles:

  • Computer based information system development is an engineering approach following the so called Software Developing Life Cycle with its phases:
    • Planning and Requirement Analysis
    • Defining software (SW) Requirements
    • Designing the product architecture
    • Building or Developing the Product
    • Testing the Product
    • Deployment in the Market and Maintenance
  • Active user involvement in the computer based PR information system development is crucial for project success.
  • users are typically involved in all stages of SDLC except in the product building stage
  • users are especially needed as a key members in system analysis and system design process, as user requirements drive the entire system development
  • users involvement in the SW development increases user acceptance of the system
  • proper user training (use of SW combined with PR content and rules) is essential for successful use of a computer based PR information system

Healthcare is information-intensive, generating huge amounts of data every day. It is estimated that up to 30% of the total health budget may be spent on handling information [1].

Also patient registries are dealing with data and information, collecting it, looking for it, storing it, analysing it. It is therefore imperative that information in patient registries is designed and managed in the most effective way possible in order to ensure high quality and reliable outcomes using information technology (IT).

In this chapter the basics of patient registry information system development and implementation will be described by presenting a typical software development lifecycle and emphasizing the importance of the (end)user in this process. The different possibilities to obtain patient registry software (SW): in-house development, buying/using PR SW product or outsource the development of PR SW will be addressed. Training in PR software is very essential to the proper and efficient use of the application, therefore it will be covered as a special topic.

After reading this chapter the reader will:

  • understand the basics of SW development lifecycle and different SW development models
  • understand the importance of user involvement in SW development
  • be aware of different options to obtain PR SW

7.1 Computer based Patient Registry Information System

Laudon [2] defines an information system technically as a set of interrelated components that collect (or retrieve), process, store and distribute information to support decision making and control, helping people analyse the problems and visualize complex subjects, and create new products.

There are three main activities in each information system (see Figure 7.1): input, processing, and output which produce the needed information. Feedback in an information system is output returned to the information system with the aim to evaluate and refine the input.

Also a Patient Registry can be seen as an information system. Input is the data on patient health issues, processing is done by classifying, arranging or calculating the data, outputs are relevant reports, alerts etc. Feedback can be, for example, a quality report on data collected which will initiate better data quality control.

Computer based patient registry information systems used for clinical data collections in research and operational settings are usually called Electronic data capture (EDC) applications or SW. They are used to collect clinical data in electronic forms. Modern EDC software applications are typically web-based and utilize a thin client. This allows end users to access the study database through the Web through a web browser without the need for the installation of an application on the local computer. Many of them also operate on Software as a Service model (SaaS).

Figure 7.1: Main components of an information system

7.2 Development of Registry Information System

Computer based information system development (short software development) is an engineering approach following the so called Software Developing Life Cycle (SDLC). Typical stages of SDLC are [3]:

  1. Planning and Requirement Analysis (requirements gathering and system analysis, feasibility study (economical, operational & technical), planning of basic project approach)
  2. Defining software (SW) Requirements (preparing and approving - by customer/user - of Software requirements specification document)
  3. Designing the product architecture (preparing and approving the product architecture)
  4. Building or Developing the Product (building a product, code generation)
  5. Testing the Product
  6. Deployment in the Market and Maintenance (formally release of the product, includes user training, regularly maintenance is required)

There is also an international standard for software life-cycle processes - ISO/IEC 12207. Standard that defines all the tasks required for developing and maintaining software.

There are various software development life cycle models prescribing a series of steps to ensure success in SW development. The most important and popular SDLC models followed in the industry are [3]:

  • Waterfall Model
  • Iterative Model
  • Spiral Model
  • V-Model
  • Big Bang Model

The other related methodologies are Agile Model, RAD Model – Rapid Application Development and Prototyping Models. More on SW development process models can be read in Tutorial on Software Development Life Cycle (http://www.tutorialspoint.com/sdlc/index.htm).

7.2.1 Important role of users

Regardless of the selected model of SW development the active user involvement in the development cycle is crucial for project success. Users have the domain knowledge and have their expectation towards the functionalities of the SW application. User requirements drive the entire system-building effort. Users must have sufficient control over the design process to ensure that a system reflects their priorities and information needs, not the biases of the technical staff. Working on the design also increases users’ understanding and acceptance of the system. Insufficient user involvement in the development effort is a major cause of system failure. The required degree of users’ involvement is dependent on the nature of the system built and also on the selected SW development model. For example Agile model and prototyping require more intense user involvement then traditional approaches.

Users are typically involved in all stages of SDLC except in the product building stage. They are especially needed as key members in system analysis and system design process (see chapter 6.5 ‘The role of information system methodologies and techniques in the phase of patient registry creation’ where some modelling techniques are presented), in testing (user tests should be performed e.g. acceptance test) and especially in the deployment phase where training of the end users is very important.

7.2.2 Software testing

“Software testing is a process of analysing a software item to detect the differences between existing and required conditions (that is defects/errors/bugs) and to evaluate the features of the software item” (ANSI/IEEE 1059 standard).

Testing is executing a SW system or its components with the intent to assess if SW satisfies agreed and specified requirements / functionalities or not.

In the process of testing usually software tester, software developer, project lead/manager and end user are involved [4]. In SDLC testing can be started from the requirements gathering phase and lasts till the deployment of the software. However it also depends on the development model (see chapter 7.2 ‘Development of Registry Information System’) that is being used.

Testing is performed in different forms like for example during a Requirements gathering phase where analysis and verification of requirements is also considered as testing or code testing executed by the developer (Unit type testing).

Proper testing is undoubtedly a very important task in SW development. Therefore a lot of standards dealing with SW testing and quality assurance are used by SW developers (e.g. ISO).

Two testing types can be distinguished: manual testing where a system is tested manually without using any automated tools and automation testing where system is tested using special tools (for example scripts or another SW). Automation testing is used to re-run the test scenarios that were performed manually, quickly and repeatedly.

There exist different methods which can be used for SW testing: black box testing, white box testing, grey box testing.

There are two main levels of SW testing: functional testing and non- functional testing.

Functional testing assesses functionalities of the system. Examples of functional testing are:

  • Unit testing – testing functional requirements of a unit;
  • Integration testing – testing if different components work together correctly;
  • System testing – testing the system as a whole in an environment close to the production environment;
  • Regression testing – if any change is made to SW, then we have to test SW again, and
  • Acceptance testing – testing the SW system in production environment by end user, this testing is also a legal and contractual requirement for acceptance of the system.

Non- functional testing:

  • Performance testing – testing speed, capacity, stability, scalability; load testing, stress testing;
  • Usability testing – testing efficiency of use, learnability, memorability etc.;
  • Security testing – testing security and vulnerability of the system (confidentiality, authentication etc.);
  • Portability testing – testing SW when it is moved in another environment (another computer with operating system).

All the tests should be well documented. Documentation usually includes: Test Plan, Test Scenario, Test Case and Traceability Matrix.

Further reading on SW testing: Software testing tutorial from tutorialspont.com (http://actoolkit.unprme.org/wp-content/resourcepdf/software_testing.pdf)

7.2.3 Training

Proper user training is probably one of the most important aspects of successfully rolling out a new SW, but is often the most poorly executed task. The training has to be planned in advance, tailored to the audience’s needs, and executed by lectures with knowledge on adult learning theory and experience in adult lecturing (not just IT experts). Nowadays training could be executed also online as distance learning modules, when the audience is from a different location or it is difficult to ensemble users in one place at the same time.

A training program related to PR should be a combination of learning PR content and PR SW usage. When training program is being prepared the following questions have to be asked [5]:

  • Who is the audience?
  • What are the learning objectives?
  • What are the best mechanisms for disseminating the information?
  • What is the best approach to ensure that learning has occurred?

7.3 Different options to obtain the Registry system

Information systems for PR can be built in-house, outsourcing of the development of PR application can take place or some product packages can be bought (this option includes also buying SW as a service) from PR, which has usually then to be tailored to in-house needs or by an external partner. All of the possibilities have their pros and cons. The differences will be described below.

The first step is to determine if there are any viable products on the market that will meet business needs and it can be bought as an off the shelf SW package. If so, a careful analysis of all identified off-the-shelf products should be made. The features, functions, benefits and costs of the products have to be analysed. Usually the product will not fit PR requirements completely and it will require customization. In cost estimation the time and cost of this task must also be included. Another important cost factor is ongoing licensing and maintenance costs in the product lifecycle – it can make off-the shelf SW a very expensive option. The benefits of buying a SW package are: lower initial costs, reduced time to deployment, higher success rates, availability of training support, access to user manuals and documentation.

Interesting reading about Electronic data Capture SW is available on http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3049639.

PR can be built in-house when the organisation possesses enough internal technical capacity. The major benefits in building SW in-house are: organisation has overall control of the development process, the IT experts can be involved already in planning PR (see chapter 6.5 ), the organisation has a clear understanding on how the SW works, the future development is in control of organization. There are also some common challenges to build PR in-house [6]: Unrealistic deadline, vague definition of project deliverables, inadequate time allotted for SW design, little or no testing, lack of quality assurance process, lack of proper project management, insufficient resources for ongoing maintenance and support, documentation that is overlooked or avoided.

Outsourcing the PR SW development is usually chosen when there is no in-house development staff or they do not possess enough technical capacity. Outsourcing means that there is a dependence on an external company to complete SW for PR. Therefore a strong business relationship will be critical and effective communication between the organizations will be a critical success factor. To select a proper outsourcing SW company focus should be placed on its [7]: experience, approach, infrastructure, quality, reputation, stability, culture.

The major benefits of outsourcing are: reduced project and financial risks, clearly defined requirements and deliverables, use of the most up-to-date design capabilities, reduced project timeline and budget and SW is easy to maintain and enhance.

Quick guide on Outsourcing SW projects guideline can be found on http://www.bhmi.com/pdf/Outsourcing%20Guidelines.pdf.


  1. Catalogue of National Health Information Sources in Ireland, HIQA, July 2010 http://www.hiqa.ie/system/files/HI-Catalogue.pdf [accessed 5th June 2014]
  2. Laudon, C. Kenneth in Jane P. Laudon. 2012. Management in Information Systems – Managing
  3. 3.0 3.1 Software Development Life Cycle Tutorial, tutorialspoint.com, http://www.tutorialspoint.com/sdlc/index.htm [accessed 5th June 2014]
  4. Software Testing Tutorial, tutorialspoint.com, http://actoolkit.unprme.org/wp-content/resourcepdf/software_testing.pdf [accessed 22nd October 2014]
  5. Shinder, Deb, Plan your end-user training strategy before software roll-out, March 2006 http://www.techrepublic.com/article/plan-your-end-user-training-strategy-before-software-roll-out/ [accessed 5th June 2014]
  6. Buy, Build or BHMI, BHMI; http://www.bhmi.com/buy_build_or_bhmi.html [accessed 5th June 2014]
  7. Outsourcing guidelines, Best practices for outsourcing SW development projects, BHMI, http://www.bhmi.com/pdf/Outsourcing%20Guidelines.pdf [accessed 5th June 2014]