tu/e 1bv10 business requirements document (brd)sjoerdbekkers.com/assets/dobis-report.pdf ·...

TU/e 1BV10 Business Requirements Document (BRD)

E

Business Requirements Document (BRD)

This document is based on a template from Noble Inc. adapted from Appendix B of UML for the IT Business Analyst, 2nd edition (cengage, 2009) by Howard Podeswa, Director of Program Development for Noble Inc.

The template has also been adapted to fit the needs of Course 1BV10 “Design of Business Information Systems” at the Eindhoven University of Technology. For the sake of clarity, some parts were removed, others have been added, and some were rephrased.

Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.

Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.


Business Requirements Document (BRD) Project No.: 2

Production Priority: 1

Target Date: 12 June 2018

Approved by:

Dr. Maryam Razavian, IE&IS

Dr. Baris Ozkan, IE&IS

Dr. Estefanía Serral, IE&IS

Prepared by:

Jeroen de Croock 0965312

R.A.J van der Heijden 1015833

M.P.J. van der Vleuten 1019095

S.G.J. Bekkers 0950370

E.M. van der Pas 0947716

A.H. van de Velde 0995745

Filename: D2_group2.pdf

Version No.: 2.46




1.1

Table of Contents 1 Change Log 4

2 Executive Summary 5

2.1 Background 5

2.2 Objectives 5

2.3 Requirements 5

3 Scope 6

3.1 Use-Case Diagram 7

3.2 Actor Descriptions 8

4 Use Case Descriptions 8

5 Test Case Descriptions 11

6 Conceptual Data Model 14

Appendix A: Conceptual Data Model 16




1 Change Log

Name Time Subject Description

whole group 15-05-2018 3.1 use case diagram made 1st version

Roel & Martijn 22-05-2018 3.1 use case diagram made 2nd version

Roel & Martijn 22-05-2018 3.2 actor description made 1st version

Roel & Martijn 23-05-2018 4 use-case descriptions made 1st version

Roel & Martijn 23-05-2018 3.1 use case diagram made 3rd version

Amber & Jeroen 18-05-2018 5. test cases made 1st version

Amber & Jeroen 21-05-2018 5. test cases made 2nd version

Amber & Jeroen 25-05-2018 5. test cases made 3rd version

Amber & Jeroen 22-05-2018 2.1 background made 1st version

Amber & Jeroen 22-05-2018 2.2 objectives made 1st version

Amber & Jeroen 22-05-2018 2.3 requirements made 1st version

Amber & Jeroen 24-05-2018 2. Executive summary made 2nd version

Sjoerd & Eef 18-05-2018 6. Conceptual model made 1st version

Sjoerd & Eef 22-05-2018 6. Conceptual model made 2nd version + assumptions

Sjoerd & Eef 24-05-2018 6. Conceptual model

Completed 2nd version + assumptions + multiplicities checked

whole group 30-05-2018 7. screen flow diagram made 1st version

Roel 06-06-2018 7. screen flow diagram Made 2nd version

Martijn & Roel 07-06-2018 3.1 use case diagram Made 4th version

Martijn & Roel 07-06-2018 3.2 actor description Made 2nd version

Martijn & Roel 07-06-2018 4 use case descriptions made 2nd version

Sjoerd & Eef 04-06-2018 consultation Stand-up meeting + planning

Sjoerd & Eef & Amber 05-06-2018 8.1 Domain model

translation of conceptual model into domain model




Sjoerd & Eef 06-06-2018 8. Mendix app made the pages with microflows

Sjoerd 06-06-2018 8. Mendix app security

Eef 07-06-2018 8. Mendix app

page and association patient_treatment_treatmentplan_activitytypes

Sjoerd&Eef 08-06-2018 8.Mendix app Finalization of the app pages, microflow, layout

Sjoerd 08-06-2018 8.Mendix app

Implemented the different coordinators with different homepages and updated securty settings

Amber & Jeroen 04-06-2018 2. Executive summary

Processing feedback, made 3rd version

Roel 10-06-2018 7. screen flow diagram made 3rd version screen flow administrative worker

Jeroen 10-06-2018 1. Mendix showcase First and second showcase

Amber 09-06-2018 8.1 Domain model Made 1st version

Jeroen 11-06 7. Mendix showcase Third showcase

Amber 10-06-2018 8.1 Domain model Made 2nd version

Jeroen 07-06-2018 5. Test cases Test cases adjusted by given feedback

Amber 05-06-2018 6. Conceptual data model

Processing feedback, made 3rd version

Jeroen 05-06-2018 All Mid-project spell and syntax check

Amber & Jeroen 11-06-2018 8.1 Domain model Made 3rd version

Sjoerd & Eef 11-06-2018 8. Mendix app Final changes and layout

Sjoerd & Eef & Amber 12-06-2018 8.1 Domain model Made 4th version

Martijn 12-06-2018 8.2 securities Made 1st version




2 Executive Summary

2.1 Background

The implementation of a new information system is being considered by Stichting Geestelijke Gezondheidszorg Eindhoven en de Kempen (GGzE) to cut down on cost. This is because of a decrease in public funding and to challenge increasing competition. GGzE currently has multiple paper based procedures for multiple uses. One of these is for instance the treatment plan of a patient. A solution for this problem will be an Electronic Patient Dossier (EPD) that is able to be expanded with regards to future subsystems.

For this project we have a several stakeholders. These include the board of Stichting Geestelijke Gezondheidszorg Eindhoven en de Kempen, patients, doctors and physicians. In this case we can question the involvement of the patient itself since they are not a user of the system. However, it is their information that is stored within the system. They can’t have a proposition about the user interface, but can remark the system’s privacy regulations for instance. The board of GGzE are high-level stakeholders and need to approve the system as a whole before it can be implemented. The doctors and physician are users of the information system. A stakeholder that doesn’t have a direct influence on the system are the insurance companies. However, if the final system won’t be functioning correctly, the insurance companies can also financially suffer.

2.2 Objectives The goal of this new information system is to handle patient’s data electronically. The new system should include all current processes to improve the managing of patients’ files. By making sure that the level of quality and efficiency increases, the services to patients of the GGzE will also ameliorate. The system will provide substantial profits within a 3 year horizon and the costs of implementing and designing the system will be recouped within 2 years.




2.3 Requirements

The following requirements will be implemented in the system:

Functional:

- The coordinator is able to see and register the results of a screening via the information

system

- The coordinator is able to assign a patient to a doctor via the information system

- The doctor is able to see a list of patients assigned to them via the information system

- The doctor is able to define and update a treatment plan as well as the outcome of

activities via the information system

- The doctor is able to flag overall treatment outcomes in the system via the information

system

- The information system should support outcomes at the entire treatment plan level

- The coordinator and doctors are the only users who are allowed to access and

manipulate clinical patient data within the information system

- Coordinators can only see patient data from patients that are assigned to their care

group via the information system

- Doctors can only see patient data from patients that they give treatment to via the

information system

- Administrative staff can only have access to administrative patient data via the

information system

Non-functional:

- Security: the system should secure the patient’s data

- Reliability: the system should be reliable to its end users

- Privacy: the patient’s data should only be accessible by the people who are allowed to

- Performance: the system should not lag

- Compatibility: the system should be compatible with future subsystems

- Capacity: the system should be able to store as much patient data as needed

- Intiutively: the system should be easy to manage by employees

Because of complexity issues the requirement that new activity types need to be edited dynamically to accommodate for future activity types ,will be out of scope.




3 Scope There are two use cases that are out of scope in the use-case diagram. The managing of the screening is out of scope because this is an activity done by the coordinator. The system is not involved in this and because of that it is out of scope. Also the referral of the patients is out of scope. It is done by a primary caregiver or by the patient itself, with the help of a self-assessment survey. The referral of the patients is out of scope because it happens outside GGzE so also outside of the system.

3.1 Use-Case Diagram

Figure 1 - Use-case diagram




3.2 Actor Descriptions Actor

Role in Use-Cases

Administrative worker

Takes care about all the administrative tasks in the GGZE, is responsible for registering patients in the system. The administrative worker can only access standard patient data, for example: name and telephone number.

Coordinator Is responsible for the screening when the patient comes to the GGZE. After this screening the coordinator assesses whether the patient should receive a treatment or not. This result is also filled in in the system by the coordinator. The coordinator uses these results to match a patient to a care group and a doctor. The coordinator can also query both standard as well as sensitive patient data. During the treatment of a patient, the coordinator has to monitor the treatment progress.

Doctor The doctor is responsible for the treatment plan and the activities. He or she creates a treatment plan in the system that exists out of activities for every patient. When there is no activity at the GGZE that matches the needs of a patient, the doctor can create and add a new activity in the system. The doctor is able to query both sensitive as well as standard patient data.

Employee The employee is a generalisation of all the employees working at the GGZE. An employee is able to query standard patient data.

Physician The physician is a generalisation of the doctors and coordinators at the GGZE. An physician is able to query sensitive patient data.




4 Use Case Descriptions

Use Case Name Query standard patient data

Use Case ID UC1

Description Employee queries standard patient data from the system.

Actors

Employee

Trigger Employee needs standard patient data.

Basic Flow 1. Employee searches for standard patient data of a specific patient in the system. 2. Employee receives standard patient data from the system.

Alternate Flows 2’. Standard patient data list is empty. 3’. Ask administrative worker to add standard patient data. 4’. Employee receives standard patient data.

Error situations

-

Use Case Name Register patient

Use Case ID UC2

Description The patient will be registered in the database which includes being assigned to a care group, using the patient data from the referral.

Actors

Administrative worker

Trigger The patient data from the referral is received.

Basic Flow 1. Patient data is reviewed by administrative employee and care group has been specified by primary caregiver.

2. Patient is assigned and registered to care group.

Alternate Flows 2’. Patient is not yet assigned to care group because primary caregiver was not able to do that 3’. Admin employee gives survey to patient 4’. patient fills in survey 5’. see step 2




Error situations

Use Case Name Process screening result

Use Case ID UC3

Description The coordinator assesses whether the screening result is positive or negative.

Actors

Coordinator

Trigger The coordinator screens the patient.

Basic Flow 1. Coordinator assesses result of screening.

Alternate Flows -

Error situations -

Use Case Name Manage treatment plan

Use Case ID UC4

Description The managing/composition of the treatment plan for a patient.

Actors

Doctor

Trigger A new patient is assigned and the doctor has to add or remove activities to the patient’s treatment or the doctor gets negative feedback on the progress of a treatment plan.

Basic Flow 1. Doctor has a (new) patient assigned to his care group. 2. According to the care group of the patient the activities of the treatment plan are

determined. 3. Doctor will further decides the set of activities that will constitute the treatment

plan. 4. Doctor adds or removes those activities to the standard treatment plan.

Alternate Flows 1’. Patient is assigned to the intensive/forensic care group and has no standard treatment plan. 2’. Doctor creates treatment plan. 3’. Doctor adds activities to the treatment plan.

Error situations

When the doctor makes a mistake, he or she has to adapt the treatment plan until it is right.




Use Case Name Manage standard activities

Use Case ID UC5

Description Evaluation of the progress that the patient makes during the treatment and adapt existing standard activities to meet the requirements of a specific patient. This is different than managing the treatment plan because an individual activity can be changed to adapt it to the needs of the patient.

Actors

Doctor

Trigger Evaluation of the progress results the knowledge that the treatment plan is not optimal.

Basic Flow 1. Evaluation of the progress that the treatment plan makes on the treatment of the patient is done by the doctor.

2. Doctor concludes that the treatment does not fulfils the needs of the patient entirely.

3. The doctor adapts activities to meet the requirements of the patient. 4. Implement adapted activities to the treatment plan.

Alternate Flows 2’. Doctor concludes that no adaption of the treatment plan is needed. 3’. Nothing is changed in the treatment plan.

Error situations

-

Use Case Name Adding new type activities

Use Case ID UC6

Description Create new type of activities and add them to the treatment plan.

Actors

Doctor

Trigger When the existing type of activities cannot be adapted to match the needs of the patient.

Basic Flow 1. No activity that fits the need of the patient exists. 2. The doctor creates new standard activity. 3. The new standard activity is added to the list of standard activities 4. The new standard activity is available to apply to the treatment plan.

Alternate Flows -

Error situations

-




Use Case Name Query sensitive patient data

Use Case ID UC7

Description Physician queries sensitive patient data (for example, treatment plan and doctor) from the system.

Actors

Physician

Trigger Physician needs sensitive patient data.

Basic Flow 1. Physician searches for sensitive patient data of a specific patient in the system. 2. Physician receives sensitive patient data from the system.

Alternate Flows -

Error situations

Sensitive patient data list is empty.

Use Case Name Assign patient to a doctor

Use Case ID UC8

Description The coordinator assigns a patient to a doctor of his or her care group.

Actors

Coordinator

Trigger Patient receives a positive screening result.

Basic Flow 1. Coordinator searches for free doctors. 2. Coordinator assigns patient to a free doctor.

Alternate Flows 2’. No free doctor is available in the system. 3’. Coordinator searches for all the doctors in the care group 4’. Coordinator assigns patient to a doctor with the least amount of patients allocated.

Error situations

-




Use Case Name Monitor treatment outcomes

Use Case ID UC9

Description Monitor the outcomes of a treatment for a specific patient.

Actors

Coordinator

Trigger This is assessed on a standard base every fixed period of time.

Basic Flow 1. Searches sensitive patient information in the system. 2. Reviews the treatment progress of this patient. 3. Gives feedback to doctor

Alternate Flows -

Error situations

-




5 Test Case Descriptions Test Case

Use Case ID

Prerequisite Test Case Scenario Expected Result

TC1

UC1 Patient is registered by the admin staff.

The employee fills in a patient form to search for a specific patient.

The system will show the result of the query so the employee is able to select the patient.

Test Case

Use Case ID


TC2

UC1 Patient is registered by the admin staff.

The employee fills in a patient form to search for a specific patient.

The system will show an empty list of patients since the query data is not correct.

Test Case

Use Case ID


TC3

UC2 The patient’s referral is received by the admin staff.

The administrative worker fills in the registration form to register the patient.

The system gives the admin worker a confirmation that the patient has been registered.

Test Case

Use Case ID


TC4

UC2 The patient’s referral is received by the admin staff.

The administrative worker fills in the registration form to register the patient.

The system gives the admin worker an error that the patient hasn’t been registered.

Test Case

Use Case ID


TC5

UC3 Patient is assigned to

The coordinator assigns the patient to a doctor within their care group.

The system gives a confirmation that the




a care group.

patient is assigned to a doctor of their care group.

Test Case

Use Case ID


TC6

UC3 Patient is assigned to a care group.

The coordinator assigns the patient to a doctor within their care group.

The system will give an error saying that all doctors are at their capacity. The coordinator has to overbook a doctor.

Test Case

Use Case ID


TC7 UC4 The patient is assigned to a doctor.

The doctor decides on the set of activities that the treatment plan consist of.

The system allows the doctor to assign a standard treatment plan to the patient by giving an overview of standard treatment plans the doctor can choose from.

Test Case

Use Case ID


TC8

UC4 The patient is assigned to a doctor.

The doctor decides on the set of activities that the treatment plan consist of.

The system allows the doctor to create a treatment plan from scratch via a form.

Test Case

Use Case ID


TC9

UC4 The patient has no treatment plan.

The doctor wants to manage the patient's treatment plan.

The system allows the doctor to create a treatment plan from scratch via a form.

Test Case

Use Case ID


TC10

UC5 The patient has a treatment plan.

The doctor adds a standard treatment activity to the patient’s treatment plan.

The system allows the doctor to assign a standard treatment plan to the patient by showing a list of standard activities




the doctor can choose from.

Test Case

Use Case ID


TC11

UC6 Doctor wants to use an activity that’s not listed as a standard activity

The doctor creates a new type of activity.

The system will allow the doctor to create a new type of activity via a form.

6 Conceptual Data Model

Figure 2 – Conceptual data model




In the figure above (figure 2) our conceptual data model is shown, as well as in appendix A. The following assumptions have been made:

● We assume not every coordinator has to perform screenings. ● We assume a patient does only belong to a single care group for every moment in time. ● ● There is an association between doctor and activity type because we want it to be

possible for doctors to add new activity types. The multiplicity of this association is on both ends *. Because doctors can work together to add a new activity type and the doctors are possible do add no or several new activity types..

● Further there is a shared aggregation between treatment plan and activity types, because a treatment plan consists of activity types. However, the activity types can also exist on their own.

● The treatment plan can either be a standard treatment plan or a composed one. Standard treatment plans are available for the acute and rehabilitation groups. For the forensic groups, a treatment plan should be made from scratch, therefore a treatments plan for these groups is always composed.

● The treatment of a patient can consist of both a treatment plan and activity types. Itt is also possible that a doctor composes a treatment of only one activity types or only select one treatment plan.

● We assume the process of writing a referral by the primary caregiver for the patient is out of scope, because this is not of interest for the system of the GGzE.

● We assume that the care group is determined by either a survey or the referral. In the case of the referral no entity is needed in the model because the adm. staff can fill in the care group of the patient based on the data of the referral.

● The survey is filled in by the patient and is thus about the patient. But is also associated with the adm. staff because we assume that they will fill in the answers of the patient of the survey in the system.

● We assume that the long term outcome of a treatment is indicated by the fact whether a treatment is successful or not, therefore outcome is an attribute of treatment .




7.User Interface Design

Screen flow administrative staff




Screen flow coordinator




Screen flow doctor




8.Mendix Implementation

8.1 Domain Model

8. Provide arguments why those two are consistent

We will first look at the entities and after that we will look at the associations between

entities.

Entities

‘Screening result’ is in our conceptual data model a separate entity which is connected

to the patient and the coordinator, because the patient will be screened by the

coordinator. The coordinator then fills in yes or no as result of the screening. In Mendix

this can be modelled easier in the domain model. The screening result here is modelled

as a attribute of the patient with an enumeration of yes or no. Hereby the screening

result can be filled in by the coordinator. The benefit is that without the extra entity for

screening result but an extra attribute in the domain model for ‘screening result’, no

extra data grid has to be made to show and make the link between the patient and the

screening result.

The entity ‘care group’, which is an attribute of ‘patient’ in our Mendix model, is

modelled as an enumeration. The enumeration is based on the generalization made in

our conceptual model. In our conceptual model, we have the three different care groups

(‘Acute’, ‘Rehabilitation’ and ‘Forensic’) as subclasses of the superclass ‘caregroup’. In

order to make the handling easier, the domain model of Mendix has the entity

‘caregroup’ not as entity but as attribute of the entities patient, coordinator and doctor.

For the conceptual model it is easier to model caregroup as entity so instead of having

to change an attribute on multiple places, you only had to change the entity once (which

would make sure the associations also changed). In Mendix it is more convenient to

have it as attribute so no extra associations have to be made and thus unnecessary

complexity can be avoided. The model is still consistent, because the patients are in

both cases linked to one of the three earlier mentioned care groups. Besides, the

change to make ‘caregroup’ an attribute, instead of an entity was easily made. All

enumerations, as mentioned in the conceptual data model, were modeled in the

domain model as well, without applying further changes.




Another generalization which is present in the conceptual model is the treatment plan.

In the conceptual model is mentioned that the treatment can have a composed

treatment plan or standard treatment plan. In the domain model this generalization is

not modelled anymore, because in Mendix the treatment plans which are standard are

predefined and saved in de database. The composed treatment plans can still be made

by the doctor itself in de application. Hence, the generalization is not modelled in

Mendix.

The last generatlization of the conceptual model is that a coordinator is a physician. This

is not further modelled in the domain model. In the domain model only coordinator is

modelled. However, all physician which have the userole of coordinator can access the

system as coordinator. This is something which does not have to be modelled in the

domain model but has to be taking care of by the system administration when making

the account for a physician.

While those two generalizations are removed, the generalization of person is kept in our

Mendix domain model. However the attributes of person are stored in each subclass.

We only use person as an entity to make the association with the entity of account. This

association is has no added value for the conceptual model as is only makes is possible

to make XPaths that the user (account) of the system only can see and or edit other

persons which are associated to them.

The following entities are modelled to same in the conceptual model and in the domain

model: survey, activity session, activity type, treatment, medicine and treatment plan.

These entities could be modelled the same way because they all kept the same

attributes in Mendix. So there was no need to change these.

Associations

In general assigning multiplicities in Mendix is different than in an uml class diagram. In

Mendix the choose of multiplicities consist of 1-*, 1-1 or *-*. In our conceptual model

we used the multiplicity 1* several times which does not exist in Mendix. When

transforming our conceptual model to the Mendix domain model all the 1*

multiplicities are changed to a * multiplicity. With change still all possibilities of different

numbers of multiplicities are possible as also indicated with the 1*. But the restriction of

having at least one of the entity is lost. This can be explained by the example of the

association between patient and treatment which contains on both ends the multiplicity

1* in the conceptual model. When the patient is registered it can not have immediately

a treatment, causing that it can not be a restriction to have at least one treatment.




When a treatment is made, it will be attached immediately to the patient so treatment

will always have a patient. The entity treatment can not be made in the database

without connection to a patient. In the remaining cases the loss of the restriction is

solved by putting commitments on attributes.

In our conceptual model a shared aggregation between treatment plan and activity type

is modelled. Mendix does not support association types such as composition or

aggregation. So a normal association had to be used to describe this relation but in the

properties of the association the delete behavior is specified. The option “an object can

only be deleted if it is not associated with any other object(s)” is selected because it is a

shared aggregation. For three other associations we specified the delete behavior in

Mendix. When a patient is deleted, the treatment and the survey of that that patient

will be completely deleted. The last delete behavior that is installed is that when a

treatment is deleted, the treatment plan will also be deleted automatically. These last

three delete behavior are useful for our database to make sure no redundant data is

stored in the database.

The last difference between the Domain model and our conceptual model are two

constraints. The first constraint {The doctor whom the patient is assigned to need to be

assigned to the same caregroup as the patient} which is not present in the domain

model, but is processed in Mendix as an Xpath. As the coordinator who assigns a doctor

to a patient only can see the doctors which are associated to him/her and patients of his

or her caregroup. Because the list of patients is retrieved by the microflow with the

Xpath for example [ReferralCaregroup = 'Rehabilitation'] for the coordinator of the

rehabilitation care group. The other constraint, {If the care group is acute or

rehabilitation than standard treatment plan, if the care group is intensive than

composed treatment plan}, is processed by that the treatment plan has got also the

attribute of caregroup. Such that the predefined/standard treatment plans can be seen

to which care group they belong.

The following associations are the same in both models: medicine and doctor, medicine

and patient, activity session and treatment, treatment and activity type, admn staff and

patient, patient and doctor, activity type and doctor, coordinator and patient, activity

session and activity type.These could be modelled the same way because there were no

constraints or other special forms of associations between these entities.




In Mendix you can assign an owner to an association. This has been done with the

conceptual model in our mind. However, these relations are not visible in our

conceptual model.

To summarize, when converting our conceptual model to a Mendix model we made sure

that no information is lost. Due to Mendix the way Mendix operates we needed to

change, add or delete attributes, entities or associations. However, the main idea

behind the structure and functionalities of both models are the same.

8.2 Security

Define which (security) roles there are in the system and which forms, microflows and

data objects they can access, by filling out the following tables.

Role Description

Administrative Worker Should be able to add patients in the system and define the care group

Coordinator_acute Should be able to add doctors in the system and match patients of his own care group to doctors. The coordinator should also be able to add patients to the system.

Doctor Should be able to compose treatment plans with the help of all kinds of activities. The doctor should also give updates about the progress of a treatment.

Coordinator_forensic Should be able to add doctors in the system and match patients of his own care group to doctors. The coordinator should also be able to add patients to the system.

Coordinator_Rehab Should be able to add doctors in the system and match patients of his own care group to doctors. The coordinator should also be able to add patients to the system.

Patient Should be able to check in the system whether or not he or she should use any medication. And if so which one.




Form Roles

ActivitySession_NewE

dit

Doctor; User

ActivityType_NewEdit

Doctor; User

ActivityType_NewEdit_2

Doctor; User

ActivityType_Select None

Add_ActivityType Doctor; User

Add_Medicine Doctor; User

Add_Treatmentplan Doctor; User

Coordinator_NewEdit

User

Doctor_NewEdit Administrative_Worker

Doctor_NewEdit_Coordinator

Coordinator; User

Doctor_Set_ActivitySessions

Doctor; User

Homepage Administrative_Worker; User

Hompage_Coordinator_Acute

Coordinator_Acute; User

Hompage_Coordinator_Forensic

Coordinator_Forensic; User

Homepage_Coordinator_Rehab

Coordinator_Rehab; User

Homepage_Doctor Doctor; User

Homepage_Patient None

Medicine_NewEdit Doctor; User

Medicine_NewEdit_Doctor

Doctor

Medicine_Select None

MyPatients_Coordinator

Coordinator; User

MyPatients_Doctor Doctor; User

Overview_Treatment_Plan_A_R

None

Patient_NewEdit Administrative_Worker; User

Patient_NewEdit_Coordinator

Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; User

Patient_NewEdit_Doctor

Doctor; User

Patient_NewEdit_Patient

Patient; User

Survey_NewEdit None

TestPatient User

Treatment_NewEdit Doctor; User




Treatment_NewEdit_2

Doctor

TreatmentPlan_NewEdit

Doctor

TreatmentPlan_Select

None

Microflow Roles

AssignDoctorFromPati

ent

Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab

AssignPatientToDoctor


CalculateCareGroup None

CoordinatorDoctor Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab;

Administrative_Worker; Patient CoordinatorPatient_Acute

Coordinator_Acute; Administrative_Worker; Patient

CoordinatorPatient_Forensic

Coordinator_Forensic; Administrative_Worker; Patient

CoordinatorPatient_Rehab

Coordinator_Rehab; Administrative_Worker; Patient

CreateSurvey Administrative_Worker

DeletePatient Administrative_Worker

DoctorMedicine Doctor

DoctorPatient_M Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; Doctor

DoctorPatients Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab

PatientMedicine Doctor; Patient

RemoveDoctor Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab

RemoveMedicine Doctor

RemovePatient Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab

RemovePatientFromDoctor


ShowCareGroup Administrative_Worker

SubmitSurvey Administrative_Worker




Data object Roles

ActivitySession Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; Patient;

Administrative_Worker(can only access but cannot create or delete an activity

session) User; Doctor (can access, create and delete activity sessions)

ActivityType Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; Patient;

Administrative_Worker (can only access but cannot create or delete an activity

type) User; Doctor (can access, create and delete activity types)

AdmStaff Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; Patient; Doctor;

Administrative_Worker ( can only access but cannot create or delete an

AdmStaff) User can access, create and delete an AdmStaff)

Coordinator Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; Patient; Doctor

(can only access but cannot create or delete a Coordinator) User (can access,

create and delete a coordinator)

Doctor Patient; (can only access but cannot create or delete a Doctor)

Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab;

Administrative_Worker; Doctor; User( can access, create and delete a doctor)

Medicine Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab;

Administrative_Worker; Patient; (can only access but cannot create or delete a

medicine) Doctor; User (can access, create and delete a medicine)

Patient Patient; Doctor; Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; (can only access but not create or delete a patient) User; Administrative_Worker (can access, create and delete a patient)

Person User (can access, create and delete a patient)

Survey Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; Patient; Doctor;

(can only access but cannot create or delete a survey) User;

Administrative_Worker (can access, create and delete a survey)

Treatment Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; Patient;

Administrative_Worker (can only access but cannot create or delete a

treatment) User; Doctor (can access, create and delete a treatment)

TreatmentPlan Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; Patient;

Administrative_Worker (can only access but cannot create or delete a

treatmentplan) User; Doctor (can access, create and delete a treatmentplan)




8.3 Top-3 Mendix Showcase

8.3.1 Mendix Showcase 1: …

In our Mendix implementation we made sure that a doctor could add medication and

assign this to patients. This is a surplus since doctors normally didn’t have to specify this.

The microflows associated with this showcase can be seen in figure 1 and 2.

Fig 2.

Fig 1.

As seen in figure 3. doctors are able to

search medication, enter new

medication, edit medication and delete

medication. If a medication has not

been entered into the system, it can of

course also not be linked to a patient.

When adding a new medicine into the

system, the doctor can specify the

name, frequency of use and a

description.

Fig 3.

In the patient tab the doctor is able to

assign medication to a patient. In this

screen (figure 4) the doctor needs to

select the medication and click ‘select’.

Now the medicine has been assigned

to the patient.




fig 4.


The system offers a certain amount of standard activity types for certain care groups.

The forensic group doesn’t have standard activities or standard treatment plans so the

doctor has to create these from scratch. Our system makes it possible for doctors to

create new activity types and assign these to certain patients. Before an activity type

can be added to the treatment plan of a patient it first has to be created. This is done in

the section ‘Manage activity types’ as seen in figure 5.

fig 5.




An activity type consists of a name, standard price, session length, medicine used, an

end date and a frequency. Furthermore, a doctor is able to search, create, edit and

delete activity types. To assign an activity type to a patient’s treatment plan the doctor

first has to search the patient in the system. After that he is able to select the treatment

of the patient and assign the recently created activity type. This form is shown in figure

6.

fig. 6





At last, doctors are able to note a session outcome and an overall treatment outcome.

The treatment outcome can be entered into the system when the treatment of a patient

is selected as shown in figure 7. In this figure also an overview of our custom made

theme for GGzE can be seen.

fig. 7 fig 8.

When creating an activity session the doctor can also note the outcome of that

session(figure 8). In the case that a patient returns to the hospital, the doctor is able to

see at a glance if the previous activities of the patient were successful (figure 9).




Appendix A- User Interfaces

Screen Name and Brief Description

Screenshot of Mendix Form

Login screen – The employee is asked to fill in their username and password to get access to the system.

Error incorrect details – An error says that the username and/or password is incorrect.




Main menu – The administrative employee can choose the functions to see the patients, doctors or coordinators data.

Display patients – A list of all the patients is shown in this screen.

Display patient search form – A form is shown where data about a specific patient can be filled in to find that patient.

Display empty patient list – An empty patient list is found, this means that there are no




patient matching the data that is provided. Display found patients – A list with all the patients that match the search criteria is shown.

Registration form – A screen is shown where new data about a patient can be added of where existing data can be modified.




Display doctors – displays a list of all the doctors.

Display doctor search form - A form is shown where data about a specific doctor can be filled in to find that doctor.

Display empty doctor list – the data that is filled in does not match the data of any doctor,




so an empty doctor list is shown. Display found doctors – all the doctors that match the search criteria are shown in this screen.

Display data of doctor – Displays all the data that is available about a specific doctor.

Display coordinators – displays a list of all the coordinators.




Display coordinator search form - A form is shown where data about a specific coordinator can be filled in to find that coordinator.

Display empty coordinator list – no coordinator is found that matches the search criteria, so no coordinator is shown.

Display found coordinators & their data – displays all the coordinators that match the search criteria and shows the available data of the coordinator.







Error incorrect details – An error says that the username and/or password is incorrect.




Main menu – The employee sees the basic data about patients and doctors.

Display patients – A list of all the patients is shown in this screen.

Patient selected – Shows the list of all the patients with the selected patient marked blue.




Display patient data list – displays the data list from a specific patient, in this screen the data can also be edited.

Display Doctors – Displays a list of all the doctors.

Display new doctor data form – Displays a data form where data from a new doctor can be filled in to add a new doctor.




Doctor selected – displays the list of doctors with the selected doctor marked blue.

Display doctor data form – Displays the data of an existing doctor, in this screen the data can also be edited.




Doctors’ patient selected – The list of patients for a specific doctor is shown and the selected patient is marked blue.







Error – incorrect details – An error says that the username and/or password is incorrect.

Main menu – The employee can choose between the function to see the




patients, the function to see the activity types, treatment plan and medication. Display patients – A list of all the patients is shown in this screen.

Display patient search form – A form is shown where data about a specific patient can be filled in to find all the available data of that patient.

Display empty patient list – An empty patient list is found, this means that there are no patient matching the data that is provided.




Display patient search results – A list with all the patients that match the search criteria is shown.

Display patient data – All the data that is available for a specific patient and his or her treatment plan is shown in this screen.

Patient is selected – The screen with the selected patient marked blue is displayed.




Edit patient data – A screen with the data sheet of the patient is shown and it is possible to edit the data.

Display medication overview – An overview of all the options with regard to the medicines that the patient uses is shown here.

Display medication list - The list with all the medicines that a patient uses is displayed here.




Display medication search form – A search form is displayed in the screen with the medicine list.

Show medication search results – Shows the medicines list that matches the search criteria.

Display empty medication search results list – Shows in the screen that there are no medicines that match the search criteria.

Confirmation delete medicine – Displays a confirmation which asks if the doctor is sure that he or she wants to delete the medicine.




Display treatment overview – displays all the options with regard to the treatments

Display treatments – Displays a list of all treatments for that specific patient.




Display new treatment form – Displays the data sheet that has to be filled in to add a new treatment for the patient.

Selected treatment plan – Displays the a list of all the treatments with the selected treatment marked blue.




Display treatment data – displays the treatment data sheet where the doctor can edit the treatment.

Confirmation delete treatment plan – displays a confirmation if the doctor wants to delete a treatment plan.




Display add treatment plan – displays a form with the data that needs to be filled in to create a new treatment plan.

Treatment selected plan – displays the selected treatment plan marked in blue.




Confirm delete treatment plan – asks for confirmation if the treatment plan needs to be deleted.

Display activity types – displays a list of all the available activity types.

Display add activity type – Displays the screen where an activity type can be added.




Display activity types – Displays a list of all the available activity types.

Show activity type list – Displays the list with all the activity types that are available.

Activity type selected – shows the list of all the activity types with the one that is selected marked in blue.




Display activity type data – displays all the data of an activity and the doctor can edit the data here.

Display activity type search form - Displays a search form where data can be entered to search for a specific activity type.

Display empty activity type search – displays an empty list of activity types, which means that there are no activity types that match the search data.




Display activity type search results – displays all the search results that match the search criteria.

Confirmation delete activity type – shows a confirmation if a doctor wants to delete the activity type.




Show activity type registration form – shows a data form where all the information about an activity type can be added to create a new activity type.

Display list of medicines - displays a list of all the medicines available.

Display medicine data form – displays a data sheet where data about the medicine can be added to create a new medicine in the system.




Display medicine search form – displays a search form where data about a medicine can be filled in to search for a specific medicine.

Display medicine search results – displays a list with all the medicines that match the search criteria.

Medicine selected – displays the list of medicine with the selected medicine marked in blue.




Confirmation delete medicine – asks for confirmation from the doctor that the medicine needs to be deleted.

Display medicine data list – shows all the available data of the medicine and in this screen, that data can be edited.

Display empty medicine search results list – displays an empty list of medicines because there are no medicines that match the search criteria.




Display treatment plans – displays a list of all the treatment plans available.

Display search form – Displays a search form where data about a treatment plan can be entered to find a specific treatment plan in the system.

Treatment plan selected – Displays a list of the treatment plans with the treatment plan that is selected marked blue.




Confirm delete treatment plan - asks for confirmation from the doctor that the treatment plan needs to be deleted.

Display treatment plan data form – displays the data from a treatment plan and in this screen, this data can be edited.




Display new treatment plan form – displays the data form in which data can be added to create a new treatment plan.




Appendix A: Conceptual Data Model



tu/e 1bv10 business requirements document (brd)sjoerdbekkers.com/assets/dobis-report.pdf ·...

Documents