Case Study: DigiHealth Medical Services

Background

1.

The RTGM stakeholders are the ones who would be connected directly with the RTGM systems. The outcomes of the system would also be defining outcomes in the lives of the stakeholders. The main stakeholders are the patients and the caregivers who make use of the systems for the benefit of the health of the patients. Doctors are the one who would be transferring the information into the devices for the care givers and the persons who would be updating the database in the systems are also associated directly with the systems. The main list of stakeholders includes:

• Patients (users of the monitoring device and of the phone application)
• Doctors (users of the information transmitted)
• Other hospital medical staff (those who enter patient medical information on phone app)
• Medical equipment engineers (developers of the mobile monitoring equipment)
• Technical staff (developers of the central server system, and the database)
• Project team members (developers of the actual phone app itself)

The patients the most important stakeholders of the system. They are ones who would be affected directly with the system and hence, they are the ones who are to be included in defining the requirements of the system.

The RTGM should be interacting with medical professionals as they would be able to provide an input to the system after a thorough analysis of the data in the system. In addition to this, the inputs from the other medical professionals can be used up very effectively by the physicians.

2.

Requirements gathering are very much essential as this helps in ensuring that the system developed is efficient and capable of meeting the needs of the customers (Silva, 2019). Requirement gathering is referred to the process that helps in collecting the essential requirements that will be efficient for meeting the needs of the stakeholders. The steps that are associated with requirement gathering understand the main requirement, eliminating the errors, identifying the corner cases and creating a definition of completed. Requirement gathering must be carried out for analyzing the resources effectively (Chanin et al. 2019). The main benefits that are offered with requirement gathering are that it offers fewer defects while delivering products, reduces the project chaos and high level of satisfaction towards the stakeholder (Ghanghro et al. 2018). In these requirements are gathered from the stakeholders so that it can be implemented within the product for managing the services. The RGTM device will be designed in such a way that it offers better way for managing the data sets (Ghanghro et al. 2018). At present the designed system works efficiently with Apple iPhones. However, the system fails to provide better facility while used with the android phones (Chanin et al. 2019). There are wide number of requirement gathering techniques that help in collecting property information related to a system or a business function. The different types of requirement gathering techniques are brainstorming, interview, observation, and questionnaire. The selected technique for the purpose of gathering the data for the system is questionnaire (Ghanghro et al. 2018). The main reason behind selecting questionnaire technique for gathering the requirement is that it helps in carrying out the analyses regarding a system within time and under the budget. This helps in gathering data of wrong use amount of people within limited time period (Chanin et al. 2019). Therefore, it can be stated that questionnaire is the best tool for evaluating the performance of the RTGM system. The RTGM system is designed for offering better services towards the customers.

Stakeholders and Requirements Gathering

Below are the set of questionnaire that is developed for understanding the components associated with the RGTM system.

Q1. What features are needed for implementing the RTGM in the android phones?

Q2. How health will be improved with the use of RTGM devices?

Q3. How much time will be needed for developing the RTGM device for the android system?

Q4. What operating system will be included in the Android system?

Q5. What features will be offered towards the patients?

3.

Functional requirements are referred to the features that will offer with the use of a product. It is important to determine the functional requirements efficiently so that it can offer a better way of identifying the requirements. With the use of functional requirement analysis, it becomes easy to define the expected system behavior (Eckhardt, Vogelsang and Fernanadez 2016). Therefore, it is important to determine the functional requirement associated with every system so that the customers can understand the accessibility features that will be offered towards them (Shah et al. 2018). It is essential to identify the functional requirements associated with the Real-Time Glucose Monitoring device (RTGM) so that it becomes easy to understand the features that will be offered towards the users. The implemented system is capable of providing better facility towards the patients (Wadwa et al. 2018) The below list describes the primary functional requirements associated with the system.

• The user needs to login within the monitoring devices so that they can get a real-time about the glucose level in their body.
• The user must provide the personal details within the application so that it becomes easy to understand the health condition of the patient (Wadwa et al. 2018).
• Patients will be capable of viewing the current glucose level within their body
• Patients will be able to view the history and trends associated with the glucose levels in their body
• Patients will receive alert related to high or low glucose level in their body
• The medical personnel will set alert threshold
• Medical personnel will be capable of communicating with patient through the use of these applications
• Medical personnel will be capable of viewing the patient history for providing them proper treatment
• The patients will be capable of setting up alerts based on beta glucose the floor will be deter mind (Wadwa et al. 2018).
• Patients will be capable of requesting for emergency help in case of sudden glucose fall
• Patients will set alert regarding their appointments with the doctors
• Patient can generate monthly health record about the glucose level with the use of this system
• Patients will be capable of setting alarm for taking medicines

5.

No the parameters for the measurement should not be same for every patient. The alerts are to be scheduled manually by the doctors and additionally, each of the schedule for the alert is to be set up as per the requirement of the patient (Wadwa et al. 2018). In fact, a measurement which can be low for patient can be high for another. However, the measurement system would be same for the each of the patients (Gia et al. 2017). The readings and the measurement criteria are same for all the devices.

The measurement and alert reading might vary over a particular time period as the health condition of a person is ever changing. Hence, the medical history of the person would also change accordingly (Zhou et al. 2018). Therefore, the doctor is also required to regulate the alerts as per the requirements. The functional requirement of the doctor setting up the alert system identifies that.

The change in the health condition of the patient would not have much implication on the functional requirements as the system would be developed with the possibilities of the changes in mind.

Questionnaire

6.

Non-functional requirements are referred to the quality attributes that are associated with the system. It is important to determine the non-functional requirements associated with the system so that it becomes easy to identify the overall performance related to the system (Eckhardt, Vogelsang and Fernanadez 2016). It is essential for a system analyst to determine the non-functional requirements so that it becomes easy to understand the key features that will be offered with the use of the application (Eckhardt, Vogelsang and Fernanadez 2016). The non-functional requirements that are offered with real-time glucose monitoring system are discussed below:

• Secured: the real-time glucose monitoring system will offer secure encrypted communication towards the patients and will ensure that all the data are stored efficiently. This will offer high security towards the data sets and will ensure that proper control is offered towards the users.
• Accuracy: The real-time glucose monitoring system has the ability to collect accurate data for providing better facility towards the patients.  Once the data are collected accurately then it becomes easy to evaluate the performance of the system (Edelman et al. 2018). The accuracy within the data is much needed as this helps in ensuring that proper services are offered towards the users.
• Accessibility: This system is designed with the easy interface so that every patient can access the system without any issue. Great accessibility will help in providing better service towards the users.
• Flexibility: the developed system is flexible so that it can be used through both android as well as the iOS interface. The system will be designed with the proper flexibility so that every user can have proper access to the data sets.
• Efficient: the system will be capable of producing efficient data after evaluating the past records of the patients. Therefore, it can be stated that with the use of real time glucose monitoring system it will become easy to determine the overall glucose level within the patients.
• Physical attributes: the designed system will be in wearable format with stylish color and comfortable and durable design. This will be easily accessible by the users and will be capable of generating proper results towards the patients.
• Integrity: With the use of glucose monitoring app it will become easy to offer better integrity towards the users as this will ensure that all the essential data are maintained privately within the system.
• Transparency: The designed system will be capable of providing better support towards the system. Huge transparency will be offered so that it becomes easy to manage the overall performance of the system. The transparency will be maintained within the system so that proper services can be offered towards the patients.

7.

The managers of Digi heath should note that the RTGM system currently does not work well with the android system and hence, it becomes difficult for the organization to allocate devices to the patients who does not have a Iphone. Hence, this is one of the major drawbacks of the system. The system should be able to integrate with the android devices in the release as per the planning by the organization (Hienemann et al. 2018). Hence, the managers are required to hire some android developers, along with some experts having skills for handling the database using sqlLite. Additionally, the database platforms are required to be integrated with the main cloud storage system storing all the data for the organization (Pettus and Edelman 2017). This would mean that user can have proper access to the data sets.

1.

The DFD corresponding to the Use case diagram has been provide below:

The event table corresponding to the use case diagram has been provided below:

Event	Trigger	Source	Activity	Response	Destination
View alert	Alert	System	Check the alert	Respond to alert	Doctor
Conditions	Set condition	Doctor	Alert to patient	Respond to alert	System
Patient Message	Check history	Doctor	Send Message to patient	Wait for patient	Patient
Respond to alert	Alert	Doctor	Response	Alert doctor	System
View alert	Alert	System	Check the alert	Respond to alert	Patient
Respond to alert	Alert	Patient	Response	Alert doctor	System
Doctor response	Message Alert	System	View/Hear from doctor	Send message to doctor	Patient
View History	Check online	System	View History	Check history	Patient
Annotate History	Check online	Patient	Annotate history	Store data	System
Doctor Message	Send message	Patient	Send message to doctor	Wait for doctor	Doctor
Patient response	Message Alert	System	View/Hear from patient	Send message to patient	Doctor

2.

View History:

Send Message to the doctor:

Send Message to patient:

3.

References

Chanin, R., Pompermaier, L., Sales, A. and Prikladnicki, R., 2019, May. Collaborative practices for software requirements gathering in software startups. In 2019 IEEE/ACM 12th International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE) (pp. 31-32). IEEE.

Eckhardt, J., Vogelsang, A. and Fernández, D.M., 2016, May. Are” non-functional” requirements really non-functional? an investigation of non-functional requirements in practice. In Proceedings of the 38th International Conference on Software Engineering (pp. 832-842).

Edelman, S.V., Argento, N.B., Pettus, J. and Hirsch, I.B., 2018. Clinical implications of real-time and intermittently scanned continuous glucose monitoring. Diabetes Care, 41(11), pp.2265-2274.

Ghanghro, S.A., Tunio, M.H., Lal, V. and Soomro, M.R., 2018. Ontology Based Requirements Gathering Elcitation Techniques. International Journal of Computer Science & Emerging Technologies, 2(1), pp.14-18.

Gia, T.N., Ali, M., Dhaou, I.B., Rahmani, A.M., Westerlund, T., Liljeberg, P. and Tenhunen, H., 2017. IoT-based continuous glucose monitoring system: A feasibility study. Procedia Computer Science, 109, pp.327-334.

Heinemann, L., Freckmann, G., Ehrmann, D., Faber-Heinemann, G., Guerra, S., Waldenmaier, D. and Hermanns, N., 2018. Real-time continuous glucose monitoring in adults with type 1 diabetes and impaired hypoglycaemia awareness or severe hypoglycaemia treated with multiple daily insulin injections (HypoDE): a multicentre, randomised controlled trial. The Lancet, 391(10128), pp.1367-1377.

Pettus, J. and Edelman, S.V., 2017. Recommendations for using real-time continuous glucose monitoring (rtCGM) data for insulin adjustments in type 1 diabetes. Journal of diabetes science and technology, 11(1), pp.138-147.

Shah, V.N., Laffel, L.M., Wadwa, R.P. and Garg, S.K., 2018. Performance of a factory-calibrated real-time continuous glucose monitoring system utilizing an automated sensor applicator. Diabetes technology & therapeutics, 20(6), pp.428-433.

Silva, P.A., 2019. The sailboat exercise as a method for user understanding and requirements gathering. Adjunct Proceedings INTERACT.

Wadwa, R.P., Laffel, L.M., Shah, V.N. and Garg, S.K., 2018. Accuracy of a factory-calibrated, real-time continuous glucose monitoring system during 10 days of use in youth and adults with diabetes. Diabetes technology & therapeutics, 20(6), pp.395-402.

Zhou, J., Zhang, S., Li, L., Wang, Y., Lu, W., Sheng, C., Li, Y., Bao, Y. and Jia, W., 2018. Performance of a new real?time continuous glucose monitoring system: A multicenter pilot study. Journal of diabetes investigation, 9(2), pp.286-293.