GTUM42EKM Systems Development Individual Coursework 1

Systems Development Individual Coursework 1

Guidelines and background to the assessment

Hand in date

TBA Assessment type

Case Study

Requirement capturing and specification for a patient information system for mental health care

1.    Introduction

This coursework requires students to produce a requirement document for the Patient information system.

2.     Scenario

A patient information system to support mental health care is a medical information system that maintains information about patients suffering from mental health problems and the treatments that they have received.

Most mental health patients do not require dedicated hospital treatment but need to attend specialist clinics regularly where they can meet a doctor who has detailed knowledge of their problems.

The MHC-PMS (Mental Health Care-Patient Management System) is an information system that is intended for use in clinics.

It makes use of a centralized database of patient information but has also been designed to run on a PC, so that it may be accessed and used from sites that do not have secure network connectivity.

When the local systems have secure network access, they use patient information in the database but they can download and use local copies of patient records when they are disconnected.

The system is not a complete medical records system so does not maintain information about other medical conditions. However, it may interact and exchange data with other clinical information systems.

The MHC-PMS has two overall goals:

  1. To generate management information that allows health service managers to assess performance against local and government targets.
  2. To provide medical staff with timely information to support the treatment of patients.

The nature of mental health problems is such that patients are often disorganized so may miss appointments, deliberately or accidentally lose prescriptions and medication, forget instructions, and make unreasonable demands on medical staff.

They may drop in on clinics unexpectedly. In a minority of cases, they may be a danger to themselves or to other people. They may regularly change address or may be homeless on a long-term or short-term basis. Where patients are

dangerous, they may need to be ‘sectioned’—confined to a secure hospital for treatment and observation. Users of the system include clinical staff such as doctors, nurses, and health visitors (nurses who visit people at home to check on their treatment).

Nonmedical users include receptionists who make appointments, medical records staff who maintain the records system, and administrative staff who generate reports.

The system is used to record information about patients (name, address, age, next of kin, etc.), consultations (date, doctor seen, subjective impressions of the patient, etc.), conditions, and treatments. Reports are generated at regular intervals for medical staff and health authority managers.

Typically, reports for medical staff focus on information about individual patients whereas management reports are anonymized and are concerned with conditions, costs of treatment, etc.

The key features of the system are:

  1. Individual care management Clinicians can create records for patients, edit the information in the system, view patient history, etc. The system supports data summaries so that doctors who have not previously met a patient can quickly learn about the key problems and treatments that have been
  1. Patient monitoring The system regularly monitors the records of patients that are involved in treatment and issues warnings if possible problems are detected. Therefore, a warning may be issued if a patient has not seen a doctor for some time. One of the most important elements of the monitoring system is to keep track of patients who have been sectioned and to ensure that the legally required checks are carried out at the right
  1. Administrative reporting The system generates monthly management reports showing the number of patients treated at each clinic, the number of patients who have entered and left the care system, the number of patients sectioned, the drugs prescribed and their costs, etc. Two different laws affect the system. These are laws on data protection that govern the confidentiality of personal information and mental health laws that govern the compulsory detention of patients deemed to be a danger to themselves or others. Mental health is unique in this respect as it is the only medical speciality that can recommend the detention of patients against their will. This is subject to very strict legislative safeguards. One of the aims of the MHC-PMS is to ensure that staff always act by the law and that their decisions are recorded for judicial review if necessary. As in all medical systems, privacy is a critical system requirement. It is essential that patient information is confidential and is never disclosed to anyone apart from authorized medical staff and the patient. Some mental illnesses cause patients to become suicidal or a danger to other people. Wherever possible, the system should warn medical staff about potentially suicidal or dangerous patients. The system’s overall design has to consider privacy and safety requirements. The system must be available when needed. Otherwise, safety may be compromised, and it may be impossible to prescribe the correct medication to patients. There is a potential conflict here—privacy is most straightforward to maintain when only a single copy of the system data exists. However, multiple copies of the data should be kept to ensure availability in the event of server failure or when disconnected from a network.

3.    Your task

Your task is to develop a requirement document for the patient information system per the following points

Identify key stakeholders

Identify at least four (6) stakeholders and indicate how each stakeholder will benefit from the system.

 

Specify requirements

From the stakeholders identified above, specify their requirements for the patient information system five (5) each according to the following categories: functional requirements, non-functional requirements, and usability requirements.

Catalogue use-cases

Identify and describe a representative set of perhaps 6-8 use cases for the system.

Keep the use cases high-level. They are about the main interactions between actors external to the system and the system itself; they should not be concerned with all the details of user interface interactions.

For three of the use cases, produce a step-by-step breakdown of the interaction between actor and system, as discussed in lecture 12.

Draw Use-case diagram

For each use case identified in 3.3 above, draw its corresponding use case diagram using the appropriate case tool. Your diagram should indicate the following, if any: actor, use cases, system boundary, generalization, include and extends.

4.    Marking Scheme

Assessment based on the following

  • 10% Stakeholders and their interests (3.1)
  • 30% Requirement specification (3.2)
  • 30% Use cases descriptions (3.3)
  • 30% Use case diagram (3.4)

How to pass this Module

To pass this assessment task, you need to achieve a minimum grade of 40%:

  • ensure that you have fully met all the learning outcomes and tasks as detailed in this “Assessment Task” brief
  • submit all the work required by the given deadline

Before you submit your work, we strongly recommend you check to ensure you have answered all the questions and met all the learning outcomes.

How to submit your assessment

Please submit your assessment via dropbox at the Graduate School’s academic support office on the submission date

For penalties for plagiarism, please refer to GTUC Regulations.

Important University assessment rules for you to note

You need to submit your assessment task on the submission date stated above. If you do not submit your assessment task by the submission date and have not requested and received an approved extension or deferral, you will fail the Module. Any extension or deferral request must have been approved before the submission deadline.

Ark Allocation guidelines to students:

< 40% 40% – 49% 50% – 59% 60% – 69% ≥70%
The submission is mainly incomplete and weak throughout. The submission is mostly complete but has more weaknesses than strengths. The submission is generally strong but has a few notable weaknesses. The submission is consistently strong, with only minor weaknesses. The submission is exceptional showing mastery at the level of study.