Inspiration
In context of smart city, we experience a smart healthcare web based application. we need a dedicated smart city architecture, where attainment of different types of environmental data from various sources like IoT, WSN, Radio Frequency Identifier (FRID), distributed data repositories, and information shared are stored in a standard format. The proposed healthcare system also provides improved record management, emergency response (ER), easy access to the healthcare systems (appointments, referrals, filling prescriptions, follow-ups, access to online advisory resources etc.) and help with cost reduction. This service based cloud based infrastructure in support of smart cities provides tremendous opportunities for the government of KSA in 2030 vision to utilize for foreign investment attractions.
What it does
The following are use cases for this project works (for illustration please see the figure).
Hospitals and Medical Clinics: The proposed infrastructure will provide many tools that make hospitals and medical clinics able to manage the patient care through different phases including record management, transfers, procedures, prescriptions etc. Hospices: The infrastructure will help hospices to provide medium term care for the patients who are transferred from hospitals to these facilities. The hospices can use tools provided by infrastructure to manage patient care including record managements, doctor visits, prescriptions. Assisted living houses (ALH): The infrastructure will help ALHs to provide long term care for the patients who are transferred from hospitals/hospices to these facilities. The ALHs can use tools provided by infrastructure to manage patient care including record managements, nurse managements, prescriptions. Ambulances and other Air Ambulances: They can use the infrastructure to manage the emergencies during transfer of critical patient to the hospitals and specialized facilities. In the hospital management model, a patient can move on an emergency basis with its whole medical setup from one branch of a hospital to the more specialized branch of the same hospital. Patient houses: Patient can be monitored in their houses and ALHs remotely using tools provided by this infrastructure. Due to the increasing number of aging demographic group, we consider this case so that a patient can be monitored continuously from the patient’s houses.
How we built it
Tracking layer and Information Gathering:
This layer aims to monitor and observe health information that are captured by smart device. It has one component called Observer that detects continuously and concurrently the data about the health information (e.g. temperature, hart rate, sugar blood, blood pressure). The tracking data collected by the observer component is stored in the
event repository. The event repository consists of tables that contain the information about Patient information.
The main functionality of the observer component in this layer is to detect and collect any possible data about current health information. The task of this component is to keep track of the changes in the detected states of the current health information frequently over the time, and send a sequence of states to the event repository.
Runtime Validation layer:
In this layer, our system will determine whether or not the current health information satisfies normal reading by validating these reading at the runtime. This process is a fundamental part in our approach which is the ability to capture the current health information of the patient.
1) Event Recogniser : Is used to collect an event from the state information stored in the event repository by the Observer in the previous layer. An event (i.e. a snapshot of states that reflect the current health information of a particular patient) is recognised according to the normal reading attributes of a disease. The recognised events are then sent to the Checker components.
2) Checker : The the normal reading attributes of a disease and the events in the current health information state of the patient are required inputs for the Checker. Checker determines whether or not the current health information of patient satisfies the normal reading attributes of a disease. The current health information is captured from a sequence of events sent by the Event Recogniser. The Checker should deal with history-based events that, in some cases, are based on other previous events. Finally, the Checker sends feedback to the Action component in the instance that a patient is in state which up normal of the ideal disease attributes.
Action layer:
In this layer, there is one component which is interfaced with the HeathCare system. This component is called Action component. Action component acts on patient state that unmated the normal reading attributes of a disease which is determined by the Checker. Also, the Action component will evaluate the obtained feedback from the Checker and then specifies what type of action should be taken against the patient (e.g. notification messages, awareness messages or sent assisting message to the paramedic describing the current state of a patient) to prevent potential problems that can affect patient’s health case.
Challenges we ran into
Case-I: Mobility of the IoT sensor nodes will be handled by the appropriate gateway node, without the
involvement of the localized mobility anchor. This, the simplest mobility scenario, arises frequently in
hospital management: a patient can move within the personal area network of the hospital for different
purposes such as exercise and fresh air.
Case-II: Mobility will be handled by the appropriate gateway with a minimal initiative from the localized
mobility anchor. The initial coordination will be performed by the localized mobility anchor. The gateway
will oversee the remaining procedures. Here a patient can move from one personal area network to
another personal area network in the hospital.
Case-III: Here mobility is inter-domain, using the public cloud environment. In this model, a patient can
move on an emergency basis from one personal area network of a hospital to a personal area network of
another hospital.
Case-IV: A patient can move on an emergency basis with its whole setup from one network area
to different network area.
Case-V: Due to the increasing number of aging demographic group, we consider this case so that a
patient can be monitor continuously from the patient’s personal environment.
Accomplishments that we're proud of
The project value.
What we learned
Find group members. Brain storming. Teamwork.
What's next for p-050SmartHealthCare
Winning. Completing. Boasting.
Log in or sign up for Devpost to join the conversation.