CSE2102 Introduction to Software Engineering Background for Semester Project

Transcription

1 Introduction and Overview: The objective of the project this semester is to provide exposure to a wide range of emerging technologies related to biomedical informatics, focusing on: Personal Health Records (PHR) such as Microsoft HealthVault ( Electronic Medical Records (EMRs) such as the product OpenEMR ( Smartphone applications for using Android (Eclipse) and Titanium Studio (Javascript) with an emphasis on having interactions with PHRs and EMRs to store and retrieve patient health information. The objective this semester is to bring all these technologies together into an integrated environment, with the Smartphones integrated via an emulation/simulation model (which is available in each of the different products development platform). The Robert Wood Johnson Foundation has sponsored Project Health Design which is targeting the use of PHRs to improve patient care ( Specifically: Project HealthDesign stimulates innovation in the development of personal health record (PHR) systems by transforming the concept of PHRs as data collection tools to PHRs as a foundation for action and improved health decision-making. The Round 2 proposal ( focused on whether and how information about patterns of everyday living can be collected and interpreted such that patients can take action and clinicians can integrate new insights into clinical care processes. Such patterns are called Observations of Daily Living (ODL) and focus on information that patients can provide on a daily basis that could assist in their care and treatment of chronic diseases (e.g., congestive heart failure, diabetes, obesity, asthma, osteo-arthritis, etc.) by having this information available for use in individual and summary forms to physicians. The applications that are to be developed for medication and chronic disease management and ODLs are in general very limited in terms of functionality. However, as time permits, we may be able to explore the bound and limits of the technologies, so ODLs such as accelerometers (general movement) or pedometers (walking) which may be possible for some smartphone platforms are also of interest. What are Observations of Daily Living (ODLs)? There are two types of ODLs: passive and active. Passive ODLs, like an accelerometer or pedometer, once enabled, collect data for a pre-determined (or user defined) time period; at the end of the period, the data collected from the passive ODL must be uploaded in an appropriate form to a PHR and/or EMR. Passive ODLs are initiated by a participant, but after activation, there is limited involvement. There are many examples. First, using a pill bottled that sends a time-stamped message to a SmartPhone that the bottle has been opened, and recording all instances of opening the bottle. Second, installing a accelerometer application on a SmartPhone that can passively send information on movement for each participant, which can be set up to occur at a specific time. Active ODLs require specific input from patients, related to a particular chronic disease (or diseases), collecting relevant information on a periodic basis (e.g., daily, twice daily, hourly, weekly, etc.); this information is actively entered by a patient and also uploaded to a PHR and/or EMR. This longitudinal information on a patient s condition can be instrumental as health providers seek to assess their patients over time, seeking to refine treatments, notice potential problems before them require hospitalization, and so on. Active and passive ODLs will be employed to gather information from participants on a scheduled basis (e.g., daily, weekly, etc.). Sample active ODLs include: We anticipate that these measures will include such items as fatigue, pain, functional status and adherence to the management plan for individuals with osteo-arthritis, chronic fatigue, or some other diseases; pulse, blood pressure, and weight, for individuals with heart or blood pressure problems; glucose levels and insulin injected (for each time the glucose is checked), and weight (on a different schedule) for individuals with diabetes; and so on. Note that some of Copyright 2012 University of Connecticut, All rights reserved. S. Demurjian 1

2 these ODLs may be regularly schedule (e.g., the smartphone beeps a reminder), triggered as the result of a contact to the patient (e.g., an automated call or to the smartphone), or initiated by the user. The numerical values are tracked for each individual to capture all of the values entered. In addition, there may be more advanced ODLs that involve the collection of information on medications that are being taken to cope with pain. There are a few possibilities in this regard: using a scanner on a SmartPhone to record the medication when it is being taken by scanning the label; or, using a camera cell phone to take a picture of the medication that can be then uploaded to the web or sent as a text message. Alternatively, a user may be provided with an application that is a series of screens to allow prescription information to be entered, and that information is then synchronized with the PHR and/or EMR. What is the Overview of Semester Project? The purpose of the semester project is to extend and reuse a mobile application for medication and chronic disease management that is intended for both patients and medical providers to interact with one another on: 1. Medications, nutritional supplements, and over the counter medications that a patient utilizes; 2. observations of daily living that actively and passively track the progress and status of patients with chronic diseases or conditions; and 3. chronic disease management capabilities that allow patients to self-track chronic diseases such as diabetes, asthma, congestive heart failure, and obesity. In support of 2 and 3, it will be necessary to track food intake and exercise. The framework and the interactions are represented in Figure 1. Medication/ Supplement Interaction Checker ODL and Chronic Disease Analyzer PHA Provider OpenEMR PHA Patient Medication & Observations of Chronic Disease Daily Living (ODL) Management Apache/Tomcat Web/Application Server MySQL Database Server Personal Health Record (PHR) Microsoft Healtvault Figure 1: Architecture Diagram of the Project this Semester. In Figure 1, the Personal Health Assistant (PHA) application has both patient and provider versions, with implementations in both Andriod (Eclipse) and Javascript (Titanium). These applications interact with Microsoft Healthvault (MSHV - for storing information on medications, allergies, prescriptions, etc., via a JSON interface. In addition, the intent is to also allow access the electronic medical record of a provider using the openemr ( product, via a REST API. In the figure, there are two primary groups of users all with different aims and objectives: Patients: This group of users are seeking a collaborative portal that provides a wide-range of functional 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, to allow patients to manage their own personal health data, particularly for those patients who require chronic disease management. Patients will be able to access and manipulate their PHR (stored in Copyright 2012 University of Connecticut, All rights reserved. S. Demurjian 2

3 MSHV); 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 the patient. This will include the capability to open portions of their PHR to providers that are selected from a list. For each selected provider, the patient can supply specific access (read or read/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 initialize portions of the PHR. This component is targeting the PHR data, its initialization, and its management in terms of permissions (authorization to providers). 2. Prescription Management: As indicated above, patients that visit multiple providers, obtain prescriptions at multiple locations, and couple their use with nutritional supplements, are key candidates for misdiagnosis and adverse events. As a result, the objective is to provide smart phone applications via traveling medication record (TMR) that would track prescriptions, overthe-counter (OTC) medications, supplements, and allergies, as a means to provide a central location that tracks all of this potential interactions and problems. Note that these capabilities are captured in part by the Personal Health Assistant (PHA) mobile application, patient version below. 3. Disease Management: This component has many different capabilities that are structured around 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 observations of daily living (ODLs). Such a component could include: a. the patient entry of medical diagnostic data (e.g., glucose level, peak flow rate, etc.) for management of chronic diseases, coupled with upload/download functionality; b. the tracking of said medical data over time via various multimodal graphical formats; c. secure on-line interactions (mobile device or computer-based) with their provider(s) for disease management (accomplished via the portal or a combination of the portal and another server e.g., relayhealth.org); and, electronic notification (simultaneous handheld and computer-based) when a trend has been identified by the provider that warrants immediate interaction with the patient (initiated by the provider). Note that these capabilities are captured in part by the Personal Health Assistant (PHA) mobile application, patient version below. 4. 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 to track 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 off adverse events and hospitalizations; this could be accomplished, for example, by having the infrastructure include a ODL Analyzer component that can alert the provider when a patient s trend data (e.g., glucose level for diabetes) exceeds some threshold for that patient for some time interval (set by the patient or the software). This essentially provides a means to track patient supplied disease management data, and may result in a number of actions, including contacting the patient to talk or to schedule a face-to-face meeting (patient appointment). This second path also requires easy to use provider user interfaces of multiple types (mobile devices and computer based) to allow notification when the providers are not in their offices; clearly adverse events will not always happen during regular business hours. In addition, this second path will require the permission from an individual patient to open a portion of their personal health record to certain providers. This is a complicated situation; in the event that it is a night or weekend, the covering provider may have neither access nor permission to patient data. 5. Tailored Education Materials: This component should have education materials that have been selected to be tailored to each patient with respect to their need(s) and/or condition(s). This may Copyright 2012 University of Connecticut, All rights reserved. S. Demurjian 3

4 also include a patient-focused education version of the treatment plan as generated from the clinical researcher provider materials. From the perspective of our project this semester, the intent is to provide the infrastructure to support the publishing of such materials for patients and providers, when we are given the materials in the appropriate format. Note that this may also be links to available data services such as FDA Daily Meds (dailymed.nlm.nih.gov) which stores data in XML format ( and has a RESTful API for accessing information ( As another example, FatSecret platform ( has a JavaScript API for accessing nutrition information programmatically ( 6. Security Capabilities: There will also be the ability of a patient to authorize a medical provider to see their information on medications and chronic disease management. As with providers, the user interfaces and interactions for patients will be critical, to facilitate adoption of the technology and continued usage. These are just the initial capabilities for patients; others are possible as the project evolves over the semester. Health Care Providers: This group of users encompasses a wide range of professions, including: primary care physicians, physician assistants, nurse practitioners, education and discharge planning nurses, and so on. This group has one overriding objective, to improve medical treatment for their patients, 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: 1. For certain patients that haphazardly visit different providers (e.g., physicians, community health centers, emergency rooms, etc.) at different times, resulting in different prescriptions obtained in different settings, a traveling medication record (TMR) will be created and maintained again, like ODLs, on various platforms, to allow the medications to be localized in a single repository (PHR MS Health Vault) that are accessible to both patients and providers. 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 nutritional supplements and home remedies that may be taken by the patient, which have the potential to generate medication-supplement interactions. 2. Security Capabilities: There will also be the ability of a provider to see the medications and ODLs of his/her patients that have been authorized by the patient. Note that these capabilities are captured in part by the Personal Health Assistant (PHA) mobile application, provider version (see MedApps.docx on course web page). In summary, any patient interactions via the collaborative portal as given in Figure 1 should integrate with the provider s local electronic medical record (EMR) system and its associated database. This allows the data collected from the portal to be available in one setting (EMR) when the 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. Project Goals and Objectives: The objective of this semester project is to develop a family of smart phone applications in support of : 1. Traveling medication record (TMR) to be able to track basic demographics (name, height, weight, etc.), medications, nutritional supplements, and allergies, with the intent of providing an automated means for various types of interaction and adverse event checking. Copyright 2012 University of Connecticut, All rights reserved. S. Demurjian 4

5 2. Observations of daily living (ODL) to be able to track specific information on chronic diseases that can be maintained in a database, with the ability to provide ODL-specific analyses that are able to inform both the patient and provider in order to head off potential problems. Collectively, as given in Figure 1, these capabilities will be placed into a larger system context to be able to store medications (in a PHR like MSHV) and ODLs (also stored in MSHV), with and end-of-semester goal for automated interaction with a electronic medical record (oepnemr). The idea is to develop smart phone application components that include: For each patient, the ability to enter and track medications and/or nutritional supplements. For each patient, the ability to enter and track allergies and adverse reactions. For each patient, a collection of selectable ODLs that are able to track information on multiple chronic diseases. For each provider, a smart phone application (and perhaps web-based computer application) to be able to analyze medication/supplement interactions and ODLs for each patient. For each pharmacist, a smart phone application (and perhaps web-based computer application) to be able to track and analyze medication/supplement interactions for conflicts and adverse events. The smart phone applications can leverage both iphone and ipad platforms are target environments. Our technology approach will be three-fold: user-centered design and requirements definition for to obtain vital input from patients in regards to ODLs as realized in mobile applications; providing a platform and associated technologies that results in a seamless integration of access by patients and their health care providers to all facets of the system. The PHR will serve as the remote storage repository for active and passive ODLs that are collected from each patient, that is maintained by a third party (MSHV), which dramatically reduces the functionality requirements for our solution, and places the onus on the vendor to support privacy, secure communication, storage, and other requirements. Platforms and Technologies: The platforms and technologies chosen to support the collection and storage of ODLs, are summarized from a software architecture perspective in Figure 1. In tracking ODLs, we must ensure that all of the ODLs are stored to allow historical tracking of this information and facilitate generation of reports or displays to collate information over time. From a technical perspective, MSHV s application programmer interface (APIs) and web services use the continuity of care record standard, CCR implemented in XML Schema ( Chronic Disease Management and Decision Support: This aspect of the project will focus on extending the observation for daily livings (ODLs) of the Andriod application to be able to manage chronic diseases, with diabetes used as an example. The International Diabetes Federation estimated that there were 30 million people with diabetes in It now affects approximately 194 million people worldwide. In just 20 years, the number of people with diabetes increased over six times. The number of people who have diabetes is expected to more than double from its current number within the next 25 years. Beaglehole and Lefèbvre from the World Health Organization and International Diabetes Foundation have announced that the world is facing a growing diabetes epidemic of potentially devastating proportions. Diabetes is a metabolic disorder. The body digests carbohydrates in food that has been eaten and moves the by-product (glucose) into the blood. From circulation of the blood, glucose can be used or stored by any part of the body. Glucose is the body's main energy source and is moved from the blood into cells by insulin. As this is a metabolic problem and people have different metabolic rates, different food intake and exercise styles, the manegement cannot be a one size fits all solution. This current health problem requires an intelligent solution a system Copyright 2012 University of Connecticut, All rights reserved. S. Demurjian 5

6 that is able to record, management the diabetes statistics and learn about how to personalize the decision for diabetes care.most of the available software that tracks the user's blood glucose level, insulin injections, carbohydrates consumed, and other diabetes statistics. Its purpose, however, is to serve as a traditional paper diabetic logbook. There are some systems help users see trends in their blood sugars with various reports and graphs. This again is more a diary (shown in the Figure 2). Figure 2: Screen Shots of Diabetes Mangement. We propose a solution in the combination of management and decision support built on artificial intelligence technologies. The emergence of personal computers into our daily lives in the past 20 years means that this program can be implemented for the first time in history. Even now, most people are not in front of a computer at all times of every day; however, within the past few years, mobile phones have become our minicomputers with ever-increasing memory and processing power. Because most people have mobile phones with them throughout the day, this is an ideal platform for something people will need at any time of the day. In this application, one management system will be developed to record, store the diabetes statistics, the other system, decision support system, will calculate and predicate the optimal dosage for medications (i.e. insulin) in sillico. The overall architecture of the system is shown in Figure 3. Figure 3. Overall Architecture of Decision Support System. Meals Exercises Current glucose level Management System Glucose level 1hr after meal Glucose level 2hr after meal Current Medications Dose of medications Dose of insulin from pumps Decision Support System Copyright 2012 University of Connecticut, All rights reserved. S. Demurjian 6

7 We will utilize our current framework to extend our existing Andriod application (and potentially migrate to the Titanium framework), to design and prototype a set of screens (samples as given in Figure 2 to be defined in greater detail) that are able to track: Glucose log: record glucose readings with time stamps Diet Calories: tracking each meal with calories calculated Exercise Calories: tracking each exercise with calories calculated Medication log: record current medications with dosages This information from these screens will be collected into a repository (either MS Health Vault or our own database or a combination of the two), in order to allow Artificial intelligence algorithms to be written using techniques such as neural networks and fuzzy logic to calculate and predicate the dosages of medications based on the current glucose levels. The output of the decision support system will add the outcomes of the algorithm to list of the suggested decisions. Applications for ODLs: The following is a list of potential ODLs just for everyone to understand the scope of the possibilities for the project this semester: A. Multi-Media Support Repository: It has been found in a number of settings, that people with chronic diseases may be able to cope with their pain, fatigue, etc., through the use of audio clips, video clips, or pictures that mean something too them. For example, for one person it may be pictures and clips of family and loved ones, for another person it may be popular music, for yet another inspirational speeches, and so on. The intent is to develop a Smartphone application that is capable of tracking a repository of audio, video, and pictures, categorized by Topic, Title, and/or Keywords. Each participant can use this repository to cope with their daily living. The system will track a complete historical record for each participant, noting the selections that are being utilized along with their datetime stamp and frequency. There will be the ability to have a favorites list of most frequently used selections, as well as for each participant to upload their own audio/videos for her own use. The intent is to also have a version of this application that could cache selections with the memory of the Smartphone to reduce download times, particularly for those selections chosen most frequently. B. Pedometer or Accelerometer: For either of these applications, you will need to have an actual Smartphone that has motion sensors. The idea would be that these applications would be initiated by a patient to collect information associated with walking (pedometer) or movement (accelerometer) for a fixed period of time. C. Discrete Measurement of Symptom/Condition: Historically, pain scales have been used extensively in medical settings (just do a Google Search on pain scale images). This type of scale can be generalized to collect information related to pain, fatigue, mobility, adherence to medication, and so on. Note that some of these ODLs may be regularly schedule (e.g., the smartphone beeps a reminder), triggered as the result of a contact to the patient (e.g., an automated call or to the smartphone), or initiated by the user. The numerical values are tracked for each individual to capture all of the values entered. This would be a simplistic ODL based on a scale (1 to 10, Good to Bad, etc.) rather than any actual collection of medical/personal data. D. Tracking of Chronic Diseases: This ODL focuses on tracking chronic diseases that require a patient to enter information periodically (daily, multiple-times-daily, weekly, etc.). There are many diseases that fit this category: pulse, blood pressure, and weight, for individuals with heart or blood pressure Copyright 2012 University of Connecticut, All rights reserved. S. Demurjian 7

8 problems; glucose levels and insulin injected (for each time the glucose is checked), and weight (on a different schedule) for individuals with diabetes; peak flow and weight for asthma; calorie intake and eating patterns for individuals that have had gastric bypass; tracking symptoms related to migraine headaches to identify patterns of onset; and so on. You can limit yourself to one of these diseases, or research other conditions that may have information that can be collected via a Smartphone. Note that some of these ODLs may be regularly schedule (e.g., smartphone beeps a reminder), triggered as the result of a contact to the patient (e.g., automated call or to the smartphone), or user initiated. E. Synching Information with PHR/EMR: For this application, you need to consider the information that is stored in a PHR and/or EMR, and develop Smartphone applications that provide a means for patients to enter the information which can then be synchronized with the PHR/EMR. For example, Google Health lets a user maintain his/her prescriptions, but it is not set up to handle nutritional supplements and other home remedies. A smartphone application could be developed to support the data entry of this information, which would then be synchronized into Google Health, and if the user is also a patient with data in the EMR Centricity, a second step would synchronize to this repository using its secure web services. A different application could also be considered to handle side effects and reactions to medications, food, allergens, etc. This application would be textual/web based. F. Scanning/Recognition: For this application, it may be possible to leverage the digital camera in a cell phone to take a picture of a medication and/or nutritional supplement label that can be then uploaded to the web into the PHR or EMR. The idea would be for the patient to be able to create a pictorial representation of medications/supplements, that would also be supplemented with their complete dosing information (size, frequency, etc.). This would involve being able to capture perhaps multiple images from the same medication/supplement and meld them together. Mobile Platforms Android: Android is Google s entry into the mobile computing market as an open source solution that has been adopted by many cell phone providers. Android has a robust development environment ( with a Software Development Kit (SDK - a detailed development guide ( and an ability to integrate with different IDEs, including: Eclipse ( with limited support for other IDEs. To assist in the development process, there is a robust set of available tools ( including an Android Emulator ( and the ability to configure Android Virtual Devices with respect to platform, hardware, etc. ( Titanium: Titanium is a platform independent development platform that allow software engineers to develop hybrid applications in Javascript ( As a result, there is an ability to use a single code base from which Andriod, ios, Blackberry, Windows, and html5 applications can be generated. Titanium is build around a software development kit (SDK) ( The main tool is Studio ( an Eclipse-based IDE. Cross platform applications using Studio achieve between 60-80% code reuse across various OS platforms. Copyright 2012 University of Connecticut, All rights reserved. S. Demurjian 8

9 Market Share of Mobile Platforms: There has been a dramatic change in both the usage and the market shares for mobile computing, and smartphones in particular. As of 2009, assembled from there are five different platforms of SmartPhones. In the US, BlackBerry, iphone, and Windows Mobile phones dominate the market. Table 1: SmartPhone Varieties and Market Share in Platform Symbian BlackBerry iphone Windows Mobile Android World market share 47.10% 19.50% 10.70% 12.40% > 1% # US users 888,535 9,668,977 5,258,254 6,807, ,914 US market share 3.9% 41.9% 22.8% 29.5% 1.9% Development C++ Java Objective C Windows Linux Dev Environment Visual Studio Blackerry/Java Mac OSX Visual Studio Linux Resolution various various 480x320 various various There have been dramatic changes in the market share, as reported on the media on August 7, 2013, shown in Table 2 ( Table 2: SmartPhone Varieties and Market Share in August Finally, the tablet market has also been changing over the last three years, as shown in Table 3. Table 3: Tablet Market Share in Q Copyright 2012 University of Connecticut, All rights reserved. S. Demurjian 9

10 Two Healthcare Applications Over the past few years, we have been developing health care applications for medication management and chronic disease management, and medication reconciliation. The first, a mobile health application, the Personal Health Assistant (PHA), consists of two perspectives for medication management and chronic disease management,. One perspective allows a patient to keep track of their medications, nutritional supplements, allergies, etc., and also authorize that PHI (HL7 CDA, CCR, etc.), which is stored in Microsoft Health Vault MSHV, to his/her specific medical providers at different times. The second perspective allows a provider to select and view the authorized PHI on a patient-by-patient basis as determined by his/her assigned role. The second application, SMARTSync for medication reconciliation, takes patient medications from MSHV and the Harvard SMART Platform Electronic Medical Record (EMR) and from this information is able to generate a summary list of medications/supplements added by patients (in MSHV) with those prescribed by a patient s medical provider. The intent is to generate a color-coded list of potential overmedication, adverse interactions, and adverse reactions for the patient and provider. The remainder of this section begins the case study by presenting the overall architecture of PHA and SMARTSync. Then, PHA and SMARTSync are described, with a focus on their functional capabilities and user interfaces. The overall architecture of the two healthcare applications is given in Figure 4, where the bottom of the figure indicates PHA and SMARTSync. Microsoft HealthVault (MSHV) acts as the data source for both applications, and stores information in a proprietary format which to be exported via a.net API which can then be used to generate a CCR compliant document in XML. To store the relations between the authorized list of providers and their respective patients, the Middle-Layer Server uses MySQL 1. JSON is utilized for the communication of the two applications and the Middle-Layer Server, allowing us to insure a uniform communication with any application (not only PHA) that can be created for users. The communication between the PHA patient version and the Middle-Layer Server is done with unmodified JSON objects, while the communication between the PHA provider version and SMARTSync and the Middle-Layer Server is a combination of unmodified (for the initial request of patients) and filtered (for the resulting data allowed by the policies enforced) JSON. From a technology perspective we utilize: JSON Both Apple s ios and Android 3 have comprehensible JSON libraries. JSON is a human readable universal language of the web and can be used across many platforms. This is why I chose my server to communicate with the mobile clients through this technology. WCF (or Windows Communication Foundation) is a Microsoft technology to pass complex composite object types from the server to the mobile client applications. We have an existing piece of software that does this that can be reused and modified. Microsoft MVC Microsoft s Model View Controller implementation allows the JSON calls to the server much easier to digest by retrieving objects. ASP.NET 4 Microsoft active server pages offer a strong, secure and stable environment to host web applications. 1 MySQL, Copyright 2012 University of Connecticut, All rights reserved. S. Demurjian 10

11 Figure4. Medication/Chronic Disease Management and Reconciliation Applications. MS Health Vault ASP.Net API XML XACML XML-RR Health Vault Middle-Layer Server Harvard SMART EMR SMART Container Rest API RDF XACML RDF-RR JSON JSON JSON Personal Health Assistant (PHA) Patient App Proivder App Medications Allergies Procedures Demographic Medications Allergies Procedures Demographic SMARTSync RxTerms NDF-RT RxNorm Provider List Security Policies Patient List Authorization by Role Personal Health Assistant (PHA) is a mobile application (for Android and ios) that serves as a platform for medication and chronic disease management, and consists of both a patient and a provider version. This allows patients to view and update their personal health record stored in their MSHV account and authorize medical providers to access certain portion of PHI and for providers to obtain the permitted information from their respective patients that they have been authorized to view. Features of the patient version include the ability to edit and view medications, supplements, allergies, and observations of daily living (ODLs with diabetes, asthma, and CHF supported etc.) as well as authorize the delivery of protected health information (PHI) stored in MSHV to his/her specific medical providers. Security settings can be set at a fine granular level, and each provider gets view/update authorizations to the different information components available in PHA. The provider version allows a clinician to select, view and edit the medical information (authorized PHI) of his/her patients as long as there are permitted to do so as dictated by the security set by the user (patient). the authorized PHI on his/her patients by role. Screen shots for the ios PHA are in Figure 5. From left to right the images depict the logon screen, a Copyright 2012 University of Connecticut, All rights reserved. S. Demurjian 11

12 patient s profile, a patient s medications, to the diabetes status input screen for logging blood glucose levels and insulin doses, a graph of blood glucose levels and the provider version of PHA (after logon) where medical providers can view the medical information (and graphs) of their patients who have authorize access. Security settings (not shown) can be set at a fine granular level. Figure 5. PHA Patient Version (1 st five) and Provider (last). To complement these screen shots, Figure 6 illustrate the Andriod PHA Screens. Figure 6: Android Patient and Provider Apps Copyright 2012 University of Connecticut, All rights reserved. S. Demurjian 12

13 Exchange Layer: Custom Middle-Layer Server with a RESTful API The exchange layer in our architecture has two major purposes. The first is the translation of data from HealthVault into JSON, an object notation that end-user applications from the top layer (Figure 4) can easily use. As shown in Figure 7, the data translation component of the exchange server consists of a RESTful service designed and implemented in a hybrid model-view-controller (MVC) paradigm. A controller that handles offline connections, user authentication, and data translation coordinates the model (HealthVault s data model). The view is in turn the exposed web service calls. In order to translate HealthVault object classes into JSON, several mapping relations must be defined. Currently, the defined mappings provide support for the retrieval and push of medications, allergies, procedures, conditions, laboratory tests and results, peak flow, blood pressure, and custom extended objects (e.g. observations of daily living, glucose readings, etc.). Figure 8 shows a sample mapping between medications, allergies and their respective JSON syntax. Figure 7: HealthVault RESTful Exchange Service. Web-Services User Profile Medication List Allergies List Conditions List Lab Tests and Results List Procedure List Observations of Daily Living List HealthVault Offline Connection Person ID HealthVault Record Finder and Access Offline Connection Record ID 8: HealthVault Class JSON Mapping. MSHV Class Member Properties DateDiscontinued (ApproximateDateTime) DateStarted (ApproximateDateTime) Dose (GeneralMeasurement) Frequency (GeneralMeasurement) Name (CodableValue) Note (CommonItemData) Route (CodableValue) Strength (GeneralMeasurement) Medications JSON Structure [{ "Key":"String content", "DateDiscontinued":"String content", "DateStarted":"String content", "Dose":"String content", "Frequency":"String content", "Route":"String content", "Name":"String content", "Note":"String content", "Prescribed":"String content", "Strength":"String content" }].NET JSON Conversion.NET JSON on GET requests JSON.NET on POST requests MSHV Class Allergies JSON Structure Demographic Information Medications Allergies Conditions Lab Tests Procedures Observations of Daily Living (ODLs) Member Properties AllergenCode (CodableValue) AllergenType (CodableValue) FirstObserved (ApproximateDateTime) IsNegated (Nullable) Name (CodableValue) Reaction (CodableValue) Treatment (CodableValue) [{ "Key":"String content", "AllergenCode":"String content", "AllergenType":"String content", "FirstObserved":"String content", "IsNegated": , "Name":"String content", "Reaction":"String content", "Treatment":"String content" }] Copyright 2012 University of Connecticut, All rights reserved. S. Demurjian 13

14 The other major purpose of the exchange layer is the coordination of security definitions, their storage, push and retrieval. Towards this purpose, our middle-layer server contains another separate RESTful API that wraps around a MySQL database (Figure 9). This MySQL database serves to store the general provider information (name, main role) and the mappings between providers and patients with respect to roles. The security preferences of the patients are also stored in this database. The RESTful service that wraps this database is done with PHP utilizing the Slim Framework, which allows us to leave a small code fingerprint with scalability potential. Figure 9: Policy Storage and Retrieval Point RESTful Exchange Service. Data Source Layer: Microsoft HealthVault PHR The last layer of the architecture consists of the data source layer. In our implementation, we leverage MSHV, a personal health record that allows users to store a variety of health information items (not limited to those supported by PHA and the exchange layer). To access MSHV, Microsoft provides a web application (Figure 8) and an SDK for custom application development. Figure 8: HealthVault s Web Application. Copyright 2012 University of Connecticut, All rights reserved. S. Demurjian 14

15 While we utilize MSHV as our data source of choice for implementation, there is no real restriction on what data source can be used, the combination of these, or the type. For example, the data source layer could consists of MSHV, an EMR like OpenEMR 2 or VistA 3 ; and/or, an abstraction architecture like SMART. The benefit of having a multi-layer approach is that it allows developers to plug and play components to any of these and they would still work. SMARTSync Application One approach to medication reconciliation in SMARTSync is to create and preserve a patient s medication list through transfers among locations of care, preventing immediate interactions, and avoiding dosage errors in situations where brand and generic drugs are received or multi-component drugs are used. Significant risks include: overmedication when a provider prescribes a new medication (or one from the same class) or when an interacting medication is prescribed; adverse interactions, the result of conflicts between medications, NSs, and OTCs, which can change effect strength (pharmocodynamic interaction) or serum concentration (pharmacokinetic interaction); and adverse reactions, allergic/other effects, experienced by patients which can result in a patient being wrongly labeled as allergic to a medication, unnecessarily excluding it as a treatment option in the future. To accomplish this, we gather data form MSHV and SMART EMR as shown in Figure 9. Any medical data source (e.g., an EMR, a PHR, etc.) can be turned into a SMART container by exposing the SMART REST API, the SMART Connect API, and RDF/XML data model 4. In the SMART framework, applications are grouped on the SMART dashboard, which offers authentication and a set of basic services based on RDF/SPARQL for accessing the underlying medical data source in the SMART container. SMARTSync is also operated through this user interface component. In addition, SMARTSync communicates with MSHV and takes advantage of the RxNorm, RxTerms, and NDF-RT 5 nomenclature/terminologies for semantic navigation of clinical drugs. The graphical user interface for SMARTSync is designed provide the alert information to the user in a quick and easily recognizable fashion, geared towards simplicity in order to serve a wide range of patients and to be easily portable to mobile devices. The main application screen, as shown in Figure 5, is currently divided in two tabs, visualizing the PHR (MSHV) and the SMART EMR. Patients can switch between the tabs to see the list of medications stored in each record. The Reconcile Medications and the Find Medication Interactions buttons perform on-demand reconciliation and interaction searches. In the MSHV tab, the user is presented with the reconciled list of medications. If any of the entries interact, the severity of interaction is indicated by a yellow (significant interaction) or red (critical interaction) background. Entries for which no interactions are found are displayed with a neutral background color. There are up to three buttons located next to each of the medications, OTCs, and NSs on either tab: View Interactions, Details, and Remove. Since a patient cannot modify the information located in the provider s EMR, the only button visible in this tab is Details. View Interactions presents the user with a listing of crossinteractions between the specified medication (OTC/NS) and any other reconciled entry. Details presents information of the medication ingredients, generic names, and the dates when the user started and stopped taking the medication. Remove, only available in the PHR tab, allows the user to permanently delete the medication from their PHR SMART RDF/XML Data Model, 5 NDF-RT, Copyright 2012 University of Connecticut, All rights reserved. S. Demurjian 15

16 Figure 9. SMARTSync s User Interface. CSE2102 Introduction to Software Engineering Potential Project Foci and Features for the Semester (final list TBD) We seek to add a number of features to our applications, some or all of which may be part of the project depending on the interests of the students: Patient App: Tracking of Medication Usage record each active medication taken daily. Perhaps include reminders to have the application notify (via text message) to take a medication. Integration with an electronic health record openemr ( or the Harvard Smart Platform EMR. Explore tracking of nutritional information for chronic disease management (calories, carbohydrates, etc.) and its incorporation into Application. Incorporate medication reconciliation algorithms (from SmartSync). Create a bar code scanning input method for medications and over the counter nutritional supplements and vitamins so that the user can search andinsert them as part of their medication list. Add a link to FDA Daily Meds so that for each medication the patient can see detailed drug information. Please See Project Assignments for Explicit Requirements Copyright 2012 University of Connecticut, All rights reserved. S. Demurjian 16