Chat with us, powered by LiveChat Miami Dade College Incident Response Plan Mobile Security Paper - Uni Pal


We are now working on Phase 5 report. Revise your Word document to meet meet the requirements detailed below. (I have attached the phase 4 report for you to continue based from that).
Phase 5: loT Product Development Group Project 
Phase 5: Security
Continue working on your Word document in the Collaboration area (Just Continue in a separate word document, I will read and add to the current document). Phase V requirements are detailed below.
Your Phase V report should be structured in a manner similar to this:
??Include your Phases 1 through 4, with any revisions needed, followed by Phase 5 additions (I will do this this)
??Start by identifying all possible vulnerabilities at any part of your product. Put them in a risk matrix.
??For each vulnerability in your risk matrix, address its description, detection, deterrence, and mitigation/prevention:
Describe how it could occur, what damage it would create, referring to the likelihood and severity as indicated by where in the matrix you placed it.
o Describe the controls you will put in place to protect
against or mitigate the damages.
??Develop an incident response plan to be used in the event of compromise. Select one vulnerability and customize your IRP to address this vulnerability. Include this IP as Appendix A of your report. Sample template is provided for you to customize.
For this project you will utilize the template as a format and headers for this project. You will only be doing sections 1,3,17 based on the phase 4 report and the product we have been creating. (I have highlighted the only section you will be creating based on template/ example. (I have highlighted the portion you need to complete in the template provided below).phase 4.docx
6/28/23, 9:53 PM
phase 4.docx
Team 1: David Salmeron, Josue Camejo, Manuel Hernandez, Melanie Maestre, Michael Soto,
Theodore Atis
Professor Dr. Charlyne Walker
CNT4182: Mobile & IoT Cybersecurity
June 23, 2023
Project Hosp.ID.ality
The “” product will help Healthcare workers and staff be able to quickly authenticate
their identity and gain the necessary access whether physical or access to a digital whiteboard. By
utilizing Near-field Communication (NFC) technology, the users would tap the readers/integrated
technology in the respective rooms and make updates where necessary.
Enhance patient safety by providing real-time tracking, ensuring that patients are in their assigned
rooms or designated areas. This minimizes the risk of patient wandering or getting lost, allowing
for timely interventions, and reducing the chances of accidents or adverse events. Secondly, it
improves efficiency and workflow by enabling healthcare staff to quickly locate patients, saving
valuable time, and streamlining care delivery. Visiting medical personnel can efficiently locate
patients they need to attend to, optimizing their schedules and ensuring timely consultations or
treatments. Additionally, designated family members can have peace of mind knowing the
whereabouts of their loved ones and can plan their visits accordingly.
The mobile IoT device improves patient safety, enhances operational efficiency, and provides
convenience to all stakeholders involved in patient care.
In hospitals around the country, the use of Radio-Frequency Identification (RFID) technology has
been implemented to keep track of numerous things. From tracking medications and supplies to
personnel that are entering the facilities. There is a concern of security and integrity since
anybody who can gain physical access to the facility can become a serious threat. Some more
potential benefits from having more data to process would be insight on employee
efficiency/performance. Scanning the wristband and updating the whiteboard would also help
keep track of inventory and where it is being distributed amongst the Healthcare networks. By
service providers (i.e., doctors, nurses, doctor’s assistants, etc.) utilizing this technology, there
would be improved security and risk mitigation as opposed to using a whiteboard with no security
past the main entrance of these facilities. Through the hardening of these systems, there could
Page 1 of 16
phase 4.docx
6/28/23, 9:53 PM
past the main entrance of these facilities. Through the hardening of these systems, there could
possibly be less financial burdens incurred from disputes like injury torts and negligence lawsuits.
Stakeholders & Features
Primary Users
Hospital Staff: This product would be used extensively by hospital staff, including nurses,
doctors, and administrators. They would utilize the device and associated software to monitor
patient locations, ensure patients are in their assigned rooms when needed, and efficiently
allocate resources based on real-time information. Administrators, managers, and supervisors
within the hospital can utilize the tracking data for operational purposes. They can analyze patient
flow patterns, identify bottlenecks, and make informed decisions to improve efficiency and
resource allocation within the hospital.
Visiting Medical Personnel: Doctors, therapists, specialists, and other visiting medical personnel
who provide care and treatment to patients in the hospital would also benefit from this product.
They can easily locate patients they need to see, track their movements for timely interventions,
and optimize their time management.
Designated Family Members: Families of the patients play a vital role in their care and wellbeing. Providing designated family members with access to the tracking information can help
alleviate their concerns and keep them informed about the patient’s location, especially during
procedures, tests, or therapy sessions.
Secondary Users
Hospital Security Personnel: Security personnel can benefit from the tracking information to
enhance the safety and security of patients, staff, and hospital premises by monitoring patient
movements and identifying any unusual activities or security breaches.
Law Enforcement: Law enforcement agencies may occasionally interact with hospitals in specific
situations, such as investigations or emergency responses, their involvement in patient location
tracking would be limited and subjected to legal and privacy considerations.
Interpreter/ Translator: In the context of patient location tracking, interpreters may utilize the
device and associated software to locate patients they are assigned to assist. By having access to
real-time patient location information, interpreters can efficiently navigate the hospital facility and
reach the patients they need to support, ensuring timely and effective interpretation services.
Insurance Claim Adjusters: In some cases, insurance companies may require information about
the location and movements of patients in hospitals to assess insurance claims or verify the
validity of treatments or procedures. Claim adjusters may utilize the device and associated data to
validate the accuracy of the information provided by the policyholder or the hospital.
Paramedics: Ambulance paramedics can highly benefit from having this sense it can track the
vital signs from the ambulance to the hospital. This can work not just for the paramedics, but also
for the law enforcement who are escorting the individual to the hospital to check on the vital signs
and what changes have occurred since the time he or she has been in the ambulance.
Page 2 of 16
phase 4.docx
6/28/23, 9:53 PM
Real-Time Location Tracking: The device would provide real-time tracking of patient locations
within the hospital premises, allowing users to monitor their movements and whereabouts. This
would be a layer 5 application as the tracking would be a third-party cloud software working with
the product(s).
IPS (Indoor Positioning System): The device would utilize IPS technology, such as Bluetooth
Low Energy (BLE), Wi-Fi, or Ultra-Wideband (UWB). This would allow for accurate tracking. Also,
this feature operates on the Layer 3 section of the IoT stack as it has to do with communication
between devices or better known as connectivity. (BOTH backend and Customer-based
Patient Identification: The device could incorporate patient identification features, such as
unique identifiers or barcode scanning, to ensure accurate association of location data specific to
patients. This would have to do with Layer 1 as the device would have communicating hardware
to identify itself and the users’ credentials saved to the wristband. (BOTH backend and Customerbased requirement).
Mobile Connectivity: The device would have connectivity options such as Bluetooth or cellular
connectivity to transmit location data to a central server or cloud-based system in real-time.
Implementing this feature would be situated on Layer 3 as it is communication between devices
and/or servers. (BOTH backend and Customer-based requirement).
User-Friendly Interface: The device may have a simple and intuitive user interface, such as an
LCD screen or LED indicators, to display location information or provide feedback to the user.
Layer 1 would have to do with this feature as the physical hardware like an interface or even LED
indicator would be additional hardware added to the device. (Customer-based requirement)
Data collection: Reporting errors will stream to the Cloud. Errors such as connectivity errors, and
unrecognized inputs will be collected as analytics information and sent to the Cloud. This is
considered a Layer 4 feature.
Remote Updates: Embedding software within the IoT device to ensure remote updates can
initiate through cloud communication is considered a Layer 2 feature.
Data Encryption and Security: Patient location data transmitted or stored by the device should
be encrypted to ensure data security and privacy, complying with healthcare data regulations and
protocols. This would suit Layer 3 since it has to do with encryption within communication
protocols that are nested within Layer 3. (BOTH backend and customer-based requirement)
Page 3 of 16
phase 4.docx
6/28/23, 9:53 PM
Data Flow
The device will pass data from the hardware layer up the stack to ensure patient identification
(barcode scanning, unique ID codes) are signaled up to the cloud platform, and cloud applications
for logging. Remote updates would travel down the IoT layers from the Cloud Application Layer to
the Device Software Layer, as the update would initiate from an automated cloud server and could
become an enabled manual process in the device application. The data passed through the stack
is encrypted. The diagram below details the user requirement data flow chart.
Page 4 of 16
phase 4.docx
6/28/23, 9:53 PM
is encrypted. The diagram below details the user requirement data flow chart.
The feature or functionality that requires or is enhanced by the data element is the “Real-Time
Location Tracking” feature. This feature relies on the data element of patient location information
to provide real-time tracking of patients within the hospital premises. By monitoring their
movements and whereabouts, it enables healthcare staff, visiting medical personnel, designated
family members, and other stakeholders to efficiently locate patients, ensure they are in their
assigned rooms, and optimize care delivery. This real-time tracking data is crucial for achieving
Page 5 of 16
phase 4.docx
6/28/23, 9:53 PM
assigned rooms, and optimize care delivery. This real-time tracking data is crucial for achieving
the goals of enhancing patient safety, improving efficiency, and streamlining care delivery.
The data will be collected and processed on the device. The device will have the capability to
report errors, such as connectivity errors and unrecognized inputs, which will be collected as
analytics information and sent to the cloud. This indicates that data processing will occur on the
device to identify and report such errors.
Additionally, features like patient identification and user-friendly interface indicate that the device
will process and utilize patient-specific data for identification purposes and display relevant
information to users. It’s important to note that while some data processing will occur on the
device, there will also be data transmission and processing occurring on cloud-based systems or
servers. Features like remote updates, data encryption, and security indicate that certain data
processing tasks, such as software updates and encryption of patient location data, will be
performed in the cloud or backend systems associated with the device.
Inputted Data
The required input data for the system will be supplied by the following stakeholders:
Hospital Staff:
Hospital staff, including nurses, physicians, and administrators, will play a crucial role in supplying
input data. They will be responsible for updating patient locations and making necessary updates
through the device’s interface. Their motivation to supply the data arises from the need to
enhance patient safety, improve workflow efficiency, and allocate resources effectively within the
Visiting Medical Personnel:
Visiting medical personnel, such as physicians, therapists, and specialists, who provide care and
treatment to patients in the hospital, will also need to supply input data. They will utilize the system
Page 6 of 16
phase 4.docx
6/28/23, 9:53 PM
treatment to patients in the hospital, will also need to supply input data. They will utilize the system
to locate specific patients they need to see and track their movements for timely interventions.
Their motivation to supply data stems from the desire to optimize their time management, ensure
timely consultations or treatments, and contribute to efficient care delivery.
Designated Family Members:
Designated family members of patients will have access to tracking information about their loved
ones. While they may not directly supply input data, their motivation to ensure that data is supplied
lies in having peace of mind and being informed about the whereabouts of the patient. This
information allows them to plan their visits accordingly and feel reassured about the patient’s
location during procedures, tests, or therapy sessions.
It’s important to note that other stakeholders, such as hospital security personnel, law
enforcement, interpreters/translators, insurance claim adjusters, and paramedics, may have
limited involvement in supplying input data for patient location tracking. Their motivation would
vary based on their specific roles and responsibilities within the healthcare ecosystem.
Through the hospital staff updating these systems through the interface in a timely manner, it
would be indicative of employee efficiency. Through an increased throughput on employee
efficiency there could be possible incentives like bonuses, raised wages, etc. for employees that
are continuously improving.
Access to Data/Privileges
Hospital Staff: Hospital staff, including physicians, nurses, and administrators, can have access
to real-time tracking of patient data. The goal is to monitor patient movement, optimize resource
allocation, and improve operational efficiency in hospitals.
Security Personnel: Hospital security personnel may have access to track patient data and other
security activities. Its purpose is to ensure the safety of patients, staff and hospital facilities by
monitoring patient movements and detecting suspicious activity or breaches of security.
Administrators and Managers: Hospital administrators and managers can have access to track
patient data historically. The goal is to analyze patient flow patterns, identify bottlenecks, and
make decisions based on historical data to improve operational efficiency and resource allocation.
Designated Family Members: The displayed patient’s family can be granted access to track realtime patient data. The goal is to provide information to the family about the patient’s location,
especially while a procedure, test, or therapy session is taking place.
Law Enforcement (where appropriate): Law enforcement may have limited access to patient
data in certain situations, such as in a crime investigation or emergency response. Their access
will be subject to applicable legal and privacy considerations.
Analytics can be performed either at the edge, in the cloud, or both, depending on your specific
needs and circumstances. Here is an explanation and justification for each choice:
Analytics on the Edge:
Page 7 of 16
phase 4.docx
6/28/23, 9:53 PM
Analytics on the Edge:
Low Latency: By performing analytics at the edge, data can be processed and analyzed right
where it came from without sending it to the cloud first. This reduces time latency, which is
important for applications that require fast response times, such as in critical situations or real-time
decision making.
Security and Privacy: In some cases, sensitive data may be better processed and analyzed at the
edge to maintain security and privacy. By reducing the transfer of data to the cloud, the risk of
exploitation or security breaches can be reduced.
Dependence on Internet Connection: Analytics at the edge allows data processing to occur locally,
not requiring a stable internet connection. This is useful in environments with limited networks or
in remote locations.
Analytics in the Cloud:
Scalability and Capacity: Cloud computing provides unlimited computing resources and high
scalability. Analytics in the cloud enable processing of complex and large data at high speed and
can manage large volumes of data with ease.
Collaboration and Access: Analytics in the cloud enables easy access and collaboration
between different users or departments. Data can be accessed from multiple locations, facilitating
team collaboration and consistent data access.
Combination of Analytics on Edge and Cloud:
Hybrid Approach: This option combines the advantages of analytics at the edge and in the cloud.
Data can be processed and analyzed at the edge for real-time decisions, while data that is more
complex or requires deeper analysis can be sent to the cloud for more sophisticated, end-to-end
Cost Savings: By adopting a hybrid approach, cloud usage can be optimized by selecting data to
be processed in the cloud, reducing data transfer costs and using cloud resources efficiently.
The choice between analytics at the edge, in the cloud, or both depends on application
requirements, response speed required, desired complexity of analytics, data security, and
resource availability. A hybrid approach can provide flexibility and balance between response
speed, capacity, and cost savings.
Predictive Analytics
The user will be able to identify his or her heart rate as well as information regarding blood
pressure, sugar level, and heart rate. It will also state the user’s name just with an ID number
which will make it easier for faculty to identify the user as well as which nurse they are assigned
to. The wristband will also notify the user when it’s time for them to take their medication so that
they can notify the nurse. It will achieve this counting down to the last time the user took their
medication. One last thing that the user can benefit from is the use of messages since the wrist
band allows them to send and receive messages from the user’s family if the user has it paired up
Page 8 of 16
phase 4.docx
6/28/23, 9:53 PM
band allows them to send and receive messages from the user’s family if the user has it paired up
with their phone.
Who should have access to the data (both real-time and historical) and why?
The user should have access to their own real-time data, and historical data at their request to
ensure accurate reporting, and to comply with standards. Identity access managers and
administrators should have access to the data to ensure the deprovisioning and provisioning of
user access is facilitated. Employed health personnel with the need to know should have access
to the real-time and historical data of the patient’s location information for clinical documentation.
Sensor devices (Adafruit Industries 360 NFC/RFID Transponders):
Below is some information on the sensors and equipment that is being proposed for this project.
The AdaFruit Industries 360 is a small
quarter-sized chip that has 1 KB of non-volatile storage; it has built in encryption. It communicates
to a maximum of 2” which can minimize listening to frequencies. It functions by utilizing most
NFC/RFID reading/writing software. This sensor would be the cost-effective device hardware
utilized in the wristbands to communicate with the mobile applications that would integrate all of
the information being updated.
Gateway devices (IGN500 Ignition MQTT Edge Gateway | OnLogic)
Cisco describes a gateway device as “a device [or node] that connects disparate networks by
translating communications from one protocol to another.” It is becoming commonplace to utilize
routers as gateway devices, albeit their original devices were separate. According to Cisco’s webpage comparing routers with gateway devices, SOHO (small office home offices) now use Wi-Fi
routers as both “router (delivering data) and a gateway (translating it so destination devices can
use it).” The basic function of a network gateway device includes NICs, I/O, and specialized
software to enable translation of network protocols. Gateways may also have additional software
for functions, remote adjustments, and deployment controls. Gateway devices operate on the
network layer, and can operate on all seven layers of the OSI model. The gateway devices can
also be used as firewalls to scan and filter data, and for other security purposes. The gateway
device for this project is the Ignition MQTT Edge Gateway which translates the MQTT protocol for
IoT devices.
The MQTT broker can communicate to the Azure instances via port 8883 via TCP protocol. In
such cases where physical devices are installed as gateway devices, or for firewall purposes, the
installation should remain local to the hospital. To remain compliant with HIPAA (Health Insurance
Portability and Accountability Act), firewalls/routers within health services should enable logging
relevant with patient data. The physical gateways should essentially operate similarly to routers,
and the software to monitor the gateways should enable communication, and monitoring, and
provide overview into MQTT protocol transmission.
Page 9 of 16
phase 4.docx
6/28/23, 9:53 PM
provide overview into MQTT protocol transmission.
Another useful tool to implement is the MQTT broker cloud service that offers monitoring, and
oversight into the network data. (EMQX Cloud: Fully Managed MQTT Service for IoT)
Communication protocols used for interconnectivity
For device to device and cloud communication, the following protocols would be used. Message
Queuing Telemetry Transport (MQTT) to broadcast message updates to the MQTT-Broker which
will in turn communicate with the Microsoft Azure instances. DICOM, also known as Digital
Imaging and Communications in Medicine, can be used for transmitting, storing, and sharing
medical images and related information. FHIR also known as Fast Healthcare Interoperability
Resources is used for exchanging healthcare data. It uses web-based APIs and supports a wide
range of data types, making it suitable for exchange of data between different healthcare systems.
Rather than relying on local servers we utilize the cloud to provide efficient connection as well as
more workload and layers of security. It also works well with syncing data like storage. Unlike local
storage that can only be accessed from office areas and cloud storage from the device can be
accessed anywhere.
Cloud services platform
The services utilized for this project would be Microsoft Azure’s enterprise grade tools. Azure
provides various services for IoT applications, including Azure IoT Hub, IoT Edge, Event Hubs,
Functions, Cosmos DB, and Azure Blob Storage. Azure IoT Hub enables secure devices
connectivity and communication, while Azure IoT Edge allows for edge computing Capabilities:
Azure Event Hubs can handle high-throughput ingestion of telemetry data from the IoT devices.
Azure Functions can be used to execute serverless code for data processing or triggering actions
based on incoming data. Azure Cosmos DB can serve as a globally distributed and scalable
database for storing patient location information. Azure Blob Storage can be utilized for storing
and retrieving data files, such as device firmware or patient records.
We believe that Microsoft Azure can provide a robust and scalable infrastructure for our product. It
offers comprehensive IoT integration, real-time data processing, storage options, serverless
computing, etc. This enables our team to build a powerful and intelligent solution to enhance
patient care and optimize hospital operations.
Analytic software
Page 10 of 16
phase 4.docx
6/28/23, 9:53 PM
The analytical software to be utilized also comes from Microsoft’s cloud services. Azure Stream
Analytics can be used to perform real-time analytics on the streaming data generated by the IoT
device. It allows implementation of SQL-like queries to the data stream. This enables the ability to
filter, aggregate, and analyze the data in real-time. In addition, Power BI can be also implemented.
Power BI by Microsoft is an intelligence tool that can be used to create interactive dashboards and
reports. It can connect to various data sources, including Azure services. It can provide
visualization like charts, graphs to represent the analyzed data.
The analytics that would be provided to the employees would be information like patient location
(room number, floor number), patient information like allergies, vitals, etc. For the family members
in the same room that are curious about information about their family member they would be able
to see a form that shows what they have scheduled on a digital board integrated with Microsoft
Power BI showcasing the minimal user view of the information. Below is a representation on how
the different stakeholders/end users would be categorized and their level of privileged access.
Hospital Staff
The hospital staff, which includes doctors, nurses, administrators, and support personnel. Would
interact with the systems to access real-time data, receive notifications, and utilize the analytics to
improve patient care, operational efficiency, and resource management. For instance, doctors and
nurses can monitor patient vital signs, track patient locations, receive alerts, and access predictive
analytics to make informed medical decisions. Administrators can use the system to analyze
resource utilization, occupancy rates, and other key metrics for optimizing hospital operations.
Visiting Medical Personnel
Visiting medical personnel like surgeons, physicians, therapists, would be able to see information
like patient vitals, room number, floor number, and would be pinged the updates on patient
condition like if they have been administered anesthetics or specific conditions relative to the
visiting medical professional’s needs.
Law Enforcement
Law enforcement officials that would need the information of a patient would be able to see
information on the patient’s room and floor number.
Insurance Claim Adjusters
Insurance Claim Adjusters would be able to see the minimal patient information just like Law
enforcement and be shown patient room and floor number.
Page 11 of 16
phase 4.docx
6/28/23, 9:53 PM
enforcement and be shown patient room and floor number.
Paramedics would also see this information such as the patient’s vitals, blood pressure, calcium
level and overall health. The information would also be updated to the hospital once the patient
has arrived.
Mobile device software
Azure App Service: Azure App Service will allow us to host our mobile backend as a service
(MBaaS) in the cloud. We will create RESTful APIs or deploy server-side logic using Azure
Functions or Azure Logic Apps. The mobile software will then communicate with the backend APIs
to send or retrieve data, perform business logic, or trigger specific actions.
Azure Mobile Apps: We will use Azure Mobile Apps platform-as-a-service (PaaS) to provide a
scalable backend for mobile app development. It will provide features like authentication, push
notifications, offline data sync, and data storage. Our Mobile software can interact with Azure
Mobile Apps to authenticate users, store and retrieve data, and leverage other backend
Azure Notification Hubs: To send push notifications from our mobile software, Azure Notification
Hubs will be used. It will provide a scalable and cross-platform push notification infrastructure. Our
mobile software can communicate with Azure Notification Hubs to register devices, send targeted
notifications, and handle push notification responses.
Azure API Management: Azure API Management will create, secure, and manage APIs that can
be consumed by our mobile software. It will provide features like API versioning, security, rate
limiting, and analytics. Our mobile software will communicate with Azure API Management to
discover and consume APIs securely and efficiently.
Azure Event Grid: Azure Event Grid will enable event-based communication between different
Azure services and external systems. Our mobile software will publish events to Azure Event Grid
and will configure various event handlers to process those events in real-time or trigger
downstream actions.
Azure Service Bus: Azure Service Bus will be used as a messaging service that will enable
reliable communication between different components and systems. Our mobile software will
communicate with Azure Service Bus to send and receive messages, enabling asynchronous
communication patterns and decoupling of components. Communication and transfer of data
within the device software is based on cloud networking protocol. The device’s development
Page 12 of 16
phase 4.docx
6/28/23, 9:53 PM
within the device software is based on cloud networking protocol. The device’s development
software will enhance network-wide information transfer between primary and secondary users.
Mobile OS and supported form factors
Apple’s iOS, and Android systems will be the main supported mobile operating systems. They will
be supported throughout the entirety of the lifecycle of the Hosp.ID.ality because they are the two
largest operating systems on the market. The form factors in consideration are phones. For
security reasons, the use of tables or their related software could bring about potential security
vulnerabilities. Utilizing company phone devices to update database information would prove an
effective way to mitigate employees accidentally utilizing personal property and potentially
introducing malware.
For customers interested in the Hosp.ID.ality technology, there would be a one-time fee for
the wristbands, and initial set up/integration of the cloud technologies. By implementing a
licensing or perpetual model, customers will be able to use our product indefinitely for an
upfront fee. Additional charges may apply for updates, maintenance, or support. After
everything has been set up, there will be a total of three free lifetime service calls. Beyond
the three complimentary calls, there would be a higher monthly fee that would provide 24/7
around the clock service calls.
Product demos will be used to demonstrate the value of our product to potential customers.
Interactive demonstrations or trials will be conducted to showcase the key features and
benefits of Hosp.ID.ality. This allows the customers to experience its value firsthand and
understand how it can address their specific needs.
The ways that the product’s value can be shown to potential customers without statistics
from other customers, would be to conduct research and compare it against the run-time
compilation of other systems that are used. Most commonly these groups that handle
database management are understaffed since most of the funding is used for healthcare
workers, equipment, and medical supplies. Reducing oversight and providing a 5 year cost
breakdown analysis of the average savings provided utilizing our systems and the efficiency
would be a great way to show potential customers the benefits and value of Hosp.ID.ality.
The end users (hospital staff, authorities, security, etc.) would not not be subject to any fees.
We will implement customer organization charges where the pricing structure will vary based
on the frequency of charges incurred by customer organizations. This could be on a
monthly, quarterly or yearly basis, or linked to specific usage milestones.
Time-Based Monetization
Initial setup such as software installation to company devices, and system integration would
require a one time fee. Remote software maintenance during normal business hours would
Page 13 of 16
phase 4.docx
6/28/23, 9:53 PM
require a one time fee. Remote software maintenance during normal business hours would
be charged per use, as clients should have personnel capable of conducting said updates.
Physical software maintenance during normal business hours would be charged per use, as
clients should have personnel capable of conducting said updates. Both of these
maintenance services include security and bug patches free of charge.
Remote support during normal business hours would be based under a monthly subscription
fee. Same goes for On-Site Support, during normal business hours. Any support or
maintenance required outside of normal business operating hours will be charged on a per
use basis.
Production Costs
Device costs
NFC readers, writers, NFC wristbands vary in the marketplace price ranges. Desco Industries
provides a wristband at a cost effective price for $1.14/unit. Other custom made NFC wristbands
require custom quote requests.
Service Costs
The potential costs of this service include costs for hosting data in cloud servers and will also
include the costs for the mobile Platform as a Service, and the EMQX MQTT broker software.
Cost Breakdown of Hardware/Software
Cost of hardware
Cost of software
devices (IGN500
Ignition MQTT Edge
Gateway | OnLogic)
$3.99 (per hour)
devices (Adafruit
Industries 360
Azure Blob
$0.15 (per hour)
(Desco Industries
$0.40(per wristband)
(Serverless tier)
Page 14 of 16
phase 4.docx
6/28/23, 9:53 PM
Two-Year Projection Breakdown for Hypothetical Customers.
Price Chart
Annual Premium
Standard Annual
support 24 hr
-Not Included-
-Not Included-
Basic customer
support during
business hours
(8am-4pm EST)
4,999 or less
8,000 users or
Each additional
2,000 users after
8,000 users
$2,000 per 2,000
Total Cost
Application Program Interface (API’s)
Azure Storage API will store and retrieve data in a scalable and secure manner. Azure Active
Directory (Azure AD) API will provide authentication and authorization services, enabling secure
access control to our product. It will allow Hosp.ID.ality to manage identities, roles, and
permissions. Azure Resource Manager API will enable programmatic management of Azure
resources. It will allow Hosp.ID.ality to automate the provisioning, deployment, and management
of its infrastructure.
Although existing APIs will be used, development of custom APIs will be needed to meet specific
requirements such as integration with third-party services. This will give Hosp.ID.ality the ability to
facilitate seamless integration with external systems or services, allowing data exchange or
triggering specific actions. Implementation of real-time data streaming is also a much needed
requirement to enable real-time data streaming between Hosp.ID.ality and other components or
applications, ensuring timely and efficient communication. The development of an analytical and
reporting API will need to be developed to provide access to analytical data or generate reports
based on the data captured by Hosp.ID.ality, allowing users to gain insights and make informed
decisions. Our custom built APIs will be open source to encourage collaboration, community
contributions, and foster a developer ecosystem around Hosp.ID.ality.
There are a number of existing Application Program Interfaces (API’s) that can be
integrated into the system based on the customers’ needs. API’s function as a bridge between the
Page 15 of 16
phase 4.docx
6/28/23, 9:53 PM
integrated into the system based on the customers’ needs. API’s function as a bridge between the
software application and the database. Microsoft has an API Management system that helps build
these interfaces based on the users needs. Microsoft also provides inside of the management
system the ability to be able to monitor, secure, and manage all facets of the API’s. In the event
the customer would like a less customized and more cost effective solution, International Business
Machines (IBM) has a great API that integrates databases into cloud environments to better
communicate with the cloud instances we would install for the customers. IBM’s cloud database
API (Version 5) functions through a REST API and is able to be written in three modern languages
that are commonly used; Node.js, Go(lang), and Python.
Page 16 of 16

Purchase answer to see full

error: Content is protected !!