CSE5095 02 - Biomedical InformaticsTeam Semester Development ProjectDue Dates: Various Milestones for Semester TBDOverview of Team ProjectThe purpose of the team project this semester is to design and prototype a framework and infrastructurethat centers around a collaborative web portal for allowing patients, providers, and pharmacists, to interactwith one another in tracking: 1. medications and their interactions with nutritional supplements; and 2.observations of daily living that actively and passively track the progress and status of patients withchronic diseases or conditions. The framework and the interactions are represented in Figure 1. In the figure, there are three primary groups of users all with different aims and objectives:- Health Care Providers: This group of users encompasses a wide range of professions, including:primary care physicians, physician assistants, nurse practitioners, education and discharge planningnurses, and so on. This group has one overriding objective, to improve medical treatment for theirpatients, particularly for those patients with diseases that require constant and vigilant monitoring(e.g., diabetes, asthma, congestive heart failure, high blood pressure, etc.). To support this activity,there are two paths of interactions for providers in Figure 1: For patients with chronic conditions (e.g., asthma, diabetes, CHF, high blood pressure, etc.),providers are interested in establishing a medium for a secure electronic dialog with them totrack what is referred to as observations of daily living (ODLs), that would include patient-supplied data (e.g., glucose level, BP, peak flow rate, etc.), with the goal of heading offadverse events and hospitalizations; this could be accomplished, for example, by having theinfrastructure include a ODL Analyzer component that can alert the provider when a patient’strend data (e.g., glucose level for diabetes) exceeds some threshold for that patient for sometime interval (set by the patient or the software). This essentially provides a means to trackpatient supplied disease management data, and may result in a number of actions, including1CSE5095 02 - Biomedical InformaticsTeam Semester Development ProjectDue Dates: Various Milestones for Semester TBDcontacting the patient to talk or to schedule a face-to-face meeting (patient appointment). Thissecond path also requires easy to use provider user interfaces of multiple types (mobile devicesand computer based) to allow notification when the providers are not in their offices; clearlyadverse events will not always happen during regular business hours. In addition, this secondpath will require the permission from an individual patient to open a portion of their personalhealth record to certain providers. This is a complicated situation; in the event that it is a nightor weekend, the covering provider may have neither access nor permission to patient data. For certain patients that haphazardly visit different providers (e.g., physicians, communityhealth centers, emergency rooms, etc.) at different times, resulting in different prescriptionsobtained in different settings, a traveling medication record (TMR) will be created andmaintained again, like ODLs, on various platforms, to allow the medications to be localized ina single repository (PHR – Google Health) that are accessible to both providers andpharmacists. The key issue in this case is to identify medication conflicts (e.g., interactions,same drug given multiple time, etc.). In addition, we are also seeking to track nutritionalsupplements and home remedies that may be taken by the patient, which have the potential togenerate medication-supplement interactions. In summary, any patient interactions via the collaborative portal as given in Figure 1 shouldintegrate with the provider’s local electronic medical record (EMR) system and its associateddatabase. This allows the data collected from the portal to be available in one setting (EMR) whenthe patient is in for an office visit. If available, clinical trials organized by discipline and type,would also be useful for providers in their daily interactions with patients. - Patients: This group of users are seeking a collaborative portal that provides a wide-range offunctional components tailored to their needs and integrated with their providers. These include:1. Personal Health Record (PHR): This is the key focal point of the patient aspect of the portal, toallow patients to manage their own personal health data, particularly for those patients whorequire chronic disease management. Patients will be able to access and manipulate their PHR;as shown in Figure 1; this means that a patient would have a PHR on their own local computer(purchased or open source product), or subscribe to a service that provides the PHR to thepatient. This will include the capability to open portions of their PHR to providers that areselected from a list. For each selected provider, the patient can supply specific access (read orread/write) to individual portions of the PHR. There may also need to be a “download”process that allows a subset of patient data from a provider’s EMR to be loaded to initializeportions of the PHR. This component is targeting the PHR data, its initialization, and itsmanagement in terms of permissions (authorization to providers). 2. Prescription Management: As indicated above, patients that visit multiple providers, obtainprescriptions at multiple locations, and couple their use with nutritional supplements, are keycandidates for misdiagnosis and adverse events. As a result, the objective is to provide smartphone applications via traveling medication record (TMR) that would track prescriptions,over-the-counter (OTC) medications, supplements, and allergies, as a means to provide acentral location that tracks all of this potential interactions and problems. 3. Disease Management: This component has many different capabilities that are structuredaround the premise that patients are seeking to manage their chronic disease (e.g., asthma,diabetes, CHF, high blood pressure, etc.) in order to avoid adverse events, referred to as ODLs.Such a component could include: a. the patient entry of medical diagnostic data (e.g., glucose2CSE5095 02 - Biomedical InformaticsTeam Semester Development