This document will serve as a living Software Requirement Document for Lavendale Healthcare.

Company Mission Statement

<aside> 💉 Reshaping blood donations for the digital world.

</aside>

User Requirements

Examined Problems Stories

Patient

• No way to measure symptoms.
• Need to be able to have status seen only by verified parties on a need to know basis.
• No platform for consolidated call to action.
• No way to give blood for payment or donation in a digital solution.

Healthcare provider

• No Patient Management System for blood donors.
  • Having to relay on walk in's and new donors.
• Currently blood donation platforms don't integrate within current Electric Heath Record system.
• Point of care is limited to the hospital location.

Donor

• Call to action is diluted in a simple overarching pressure to donate blood causing inaction.
• Unable to see how actions taken impacts the community
• No way to see where ones specific blood/plasma properties are directly needed.

Proposed Solution Stories

Patient

• Will be able to look for blood donor with the same blood as the patient
• Be able to post blood type needed
• Be able to see current supply of blood available for different blood-types within the application and healthcare providers if available
• Be able to monitor symptoms of the Covid-19

Donor

• Will be a recovering patient
• Will have antibodies within the blood and is symptom free
• Willing to give blood
• Willing to be found to give blood

Healthcare provider

• Be able to monitor patients Covid-19 symptoms
• Be able to make request for blood on behalf of a currently monitored patient
• Be able to see the patient in map view
• Be able to have the data given to them by the mobile application integrated within their Electric Health Record system

Ubiquitous requirements

These are a mixture of functional and non functional requirements of the system which while not being able to be tested in every requirement must meet an reasonable standard for the stated requirement.

<aside> ✅ HIPPA Compliance

</aside>

<aside> 🔒 Secure: protecting that data from access by unauthorized entities

</aside>

<aside> ❣️ Able to be trusted: assuring the identity of others entities with which they share data

</aside>

<aside> 👁️‍🗨️ Private: sharing data only with patient permission

</aside>

<aside> 😄 Intuitive: Able to maneuver the application with relative easily

</aside>

<aside> 💬 Interoperability: Enables better communication between healthcare providers and individuals

</aside>

Event-driven requirements

These are functional requirements and will be used as testable attributes for verifying if specifications have been meet. These are discrete checkpoints to work for.

Patient

Donor

Healthcare provider

<aside> ❓ Event: Individual is sick

</aside>

System will respond by:

• Sharing their status on the system by authorized users
• Allow them to track their symptoms
• Visualize amount of blood currently available
• Provide a path to become a donor is accessible

<aside> ❓ Event: Individual wants to donate blood

</aside>

System will respond by:

• Sharing their status with the whole system
• Allow them to be contacted by healthcare providers to arrange blood donation solutions
• Allow them to schedule appointments at blood donation clinics
• When a patient recovers
  • Our System will make the donor side of the application available to the user

<aside> ❓ Event: Healthcare Provider needs to obtain blood for a Patient

</aside>

System will respond by:

• Provide them with local donor options
• Allow them to schedule appointments
  • Allow them to reschedule appointments
• Allow them to contact patients directly for coordination
• When the healthcare provider needs audited forms of all interactions based in the system
  • The System will be able to produce it in a pdf format for the healthcare provider