mobile medical managementengr.uconn.edu/~steve/cse4939w/teamgfinalspec.docx · web viewpha operates...

Mobile Medical Management

October 1st September 17

2012 Group G:Wei Lin, Che Chu, Brittany DePoi, Matthew Swircenski, Jose Rodriquez

Design Specifications

1 | Mobile Medical Management

ContentsIntroduction (Wei Lin & Brittany DePoi) ......................................................................................................2

Operating Environment (Che Chu) ..............................................................................................................4

Interfaces (Brittany DePoi) ..........................................................................................................................6

Patient Interfaces: ...................................................................................................................................7

Health Care Provider Interfaces: ............................................................................................................10

Information (M. Swircenski) ......................................................................................................................11

Performance (Wei Lin) ...............................................................................................................................13

Security (J.R) ..............................................................................................................................................13

Glossary (Everyone) ...................................................................................................................................15

Introduction (Wei Lin & Brittany DePoi) ......................................................................................................2

Operating Environment (Che Chu) ..............................................................................................................4

Interfaces (Wei Lin, Che Chu & Brittany DePoi) ...........................................................................................4

Patient Interfaces ....................................................................................................................................4

1. Main Screen .................................................................................................................................5

2. Profile ..........................................................................................................................................6

3. Medication Center .......................................................................................................................7

4. Diseases Center ...........................................................................................................................7

Health Care Provider Interfaces ...............................................................................................................8

Information (M. Swircenski) ........................................................................................................................9

System Operation (Brittany DePoi) ..............................................................................................................9

General Operation ...................................................................................................................................9

Performance (Wei Lin) ...............................................................................................................................10

Security (J.R) ..............................................................................................................................................10

Glossary (J.R) .............................................................................................................................................11

Overall – a good first attempt …

For the next iteration, I need to hav everyone with a clearly identified section; I do grades on each student by section and on the entire team for the spec. I didn’t really need Sys Op for this version and I have suggested including it elsewhere. With those changes, if Brittany takes charge of interfaces, then everyone has a section. Also – everyone was supposed to contribute glossary entries.


For information, you need to really rethink this – MSHV is limited to storing PHR related data. We are trying to track data that patients enter about their diseases with multiple values given per day. They are ways to extend the MSHV APIs, but it might be better putting this into a separate database to allow the decision support diease algorithms to be execute on a common data soucre and not have information pulled from MSHV.

Contact Prof. Wang re. the data to be collected on the four diseases and also the amount of data and the algorithms; do some research yourselves on the data for dieases that is relevant to collect and store.

From Prof. Wang:

here are my comments about what data would be collected and how to analyze them. please let me know if anything else is needed:

using insulin-dependent diabtestes as an example, we need to collect the following data daily as ‘diabetest diary’: 1) Diets (carbohydrates); 2) Exercises; 3) Con-occuring medicatrions; 4) Glucose levels; 5) Insulin doses from insulin pumps.

To decide how much insulin a person with diabetes would need to inject, an algorithm with the inputs of current glucose level, amount of carbohydrates to be eaten in the next meal, amount of Exercise planned in the next 4-6 hours and a personal diabtestes index will be developed. For example, we can use MATLAB to find a proper mathematics model and the structure of the neural network from data and implement the algorithm. The algorithm will be first trained based on the inforamtion collected in the ‘diabetes diary’.


Introduction (Wei Lin & Brittany DePoi)

The Personal Health AssisstantAssistant (PHA) Mobile Medical Management Application is a mobile application for both iOS and Android devices that allows the individual users to manage different aspects of their health, with a focus on managing medications. It PHA (avoid using It at start of sentence) also gives the doctors and healthcare providers the ability to use access patient health recordsthese medications and other data which the patient providesauthorizes to the provdierprovider. The goal of the project is to expand PHA to include data about disease management including diabetes, obesity, asthma, and chronic heart failure. This data can include diet, exercise, blood sugar levels, BP, pulse, etc. The data entry capability by patients will be augmented with the ability to deliver to This allows the healthcare providers to give advance warning of potential threats in patient health by using advanced algorithms to detect potential health threats. The application will include four major functionalities and interfaces to manage for the four diseases: diabetes, obesity, asthma, and chronic heart failure. The application is also capable of helping patients to manage their medication intake and alert the patient to take certain medication.

PHA will be extended with a disease managemenmanagement component This application is developed using the Titanium operating environmenplatformt. This allows the application to be easily translated between the iOS and Android operating systems, and even web access. The application also incorporates Microsoft’s HealthVault database personal health record (PHR) to keep track of and interact with the personal health records. HealthVault allows the application to store sensitive health records in a secure database where the healthcare provider and the patient can only see what is allowed by the patient. Other open source EMR systems can also be incorporated such as Open mHealth, openEHR, and the SMART Framework. The figure below isTo illustrate, Figure 1 contains a conceptual diagram of the mobile medical applicationsPHA components and their basic interactions.

Explain the figure somewhat … probably show a mobile device and not a laptop. There are icons on my SW Arch PPT on web page.


Figure 1: System Overview of PHA and planned Extensions.

The Mobile Medical Management Application is an event driven application with three major components. The first is the collection of patient user interfaces on the patient’s personal mobile device. These interfaces capture patient information for a specific disease. Depending on the current health of the patient, the patient will have the option of downloading interfaces specifically for diabetes, heart disease, asthma or obesity. This information is then uploaded and saved to the Microsoft HealthVault database, where security is optimized using preexisting features. The healthcare provider can then access this information through the Internet, run optional diagnostics on the information and provide the patient with feedback. In addition, the heath care provider can also request additional information through an optional custom interface. This feedback can then be viewed by the patient, thus linking communication and care from the patient and the provider on a daily basis and helping to better manage disease.

A more specific use case diagram of PHA iis shown belowin Figure 2 illustrating the main possible actions of both the patient and the health care provider. The patient has a profile designated by his or her personal Microsoft HealthVault account. By signing in through this account, the patient will have the options, through the PHA Mobile Medical Management Application to record daily activity, use the disease center to monitor specific health concerns, and use the medication center to track and record medication and nutritional supplements. n. On the other end, the health care provider will have his or her own profile and will be able to view the patient information, analyze information recorded by the patient, provide feedback and request additional information.


Figure 2: Use Case Diagram for PHA Patient and Provider Users.

Operating Environment (Che Chu & Brittany DePoi) PHA operates on the specific user’s mobile device (smartphone or tablet). The device must support either Apple’s iOS mobile operating system or Android OS. Depending on Titanium SDK version support, development for both devices will be limited but will expand to most versions used on the market. We use a medical data platform developed by Microsoft called HealthVault to store the patient’s personal health condition and medical records, and then let the authorized healthcare providers access these data through their mobile device. The application indirectly communications with the HealthVault server using JSON, a text-based open standard


for data exchange. Both patient-end and provider-end applications run in the same operating environment illustrated in Figure 3.

The operating environment includes a MS HealthVault Middle-Layer Server that acts as a communication medium between Microsoft HealthVault, PHA, and other platforms or applications such as Harvard’s SMART EMR. The Middle-Layer Server is setup and managed on Uconn campus. This server receives data input from PHA and converts the data into JSON. The server then uploads or updates the information on MS HealthVault through ASP.NET API which can then be used to generate a CCR compliant document in XML format. We will apply data security and authentication to the XML format such as encryption and digital signature.


Considering the constant need to access data on HealthVault, the Middle-Layer Server also link to a MySQL database that acts as a second repository for immediate access. Access policy control and account system will be implemented on the server. The server receives a query from PHA and then its access policy decides whether to authorize the access to a filtered or an unmodified medical data, or to reject the request according to the login information, the user’s account type (a patient or a healthcare provider), and the list of providers authorized to retrieve health records. The server will check if the data is updated each time when the PHA requests data. In a scenario which the patient updates his/her measurement on HealthVault directly using a computer, the server checks if there is inconsistency between the measurement value in PHA MySQL database and the one in HealthVault when the user switch back PHA to check the measurement. Reversely, the data will always be update by our Middle-Layer Server when a user modifies it on HealthVault through PHA. Hence, data on both sides are ensured to be updated and consistent.

Figure 3: Operating Environment

The Mobile Medical Management ApplicationPHA operates on the specific user’s smartphonemobile device (smartphone or tablet). The phone device must support either Apple’s iOS or Google’s Android OS. Depending on Titanium’s SDK version support, development for both devices will be limited but will expand to most versions used on the market. The software architecture for PHA is shown in Figure 3. (Cite figs in text) We use a medical data platform developed by Microsoft called HealthVault to store the patient’s personal health condition and let healthcare providers access these data through their smartphone. The application communicates with the HealthVault server using JSON, a text-


based open standard for data exchange. Microsoft's Model View Controller (MVC) will be used to assist in JASON calls with the server. Both patient-end and provider-end applications run in the same operating environment mentioned aboveshown in Figure 3.

The MMMA PHA? account system is managed by our dedicated server setup on Uconn campus. The account server stores the account information of the user but does not manage any data storage. All the personal health and medical records will be stored on Microsoft HealthVault database and the user will have to use their Microsoft HealthVault account to log in. To open the figure –right click mouse, presentation object, open, and it starts PPT.

The overall architecture of the two mobile applications is given in Figure 7, 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 an ASP.Net API which can then be used to generate a CCR compliant document in XML. The MSHV Middle-Layer Server (center of Figure 7) acts as the contained solution of policy access, information, decision, and

HealthVault Repository

Mobile Devices Web Application

Patient Health Care Provider

Patient Side Technologies: Titanium, JSON, HealthVault API

Health Care Provider Side Technologies: JSON, HealthVault API ,html, Ajax, PHP

Figure 4: Software Architecture Diagram of the SystemPHA.


enforcement points . To store the relations between the authorized list of providers and their respective patients, the Middle-Layer Server uses MySQL [28]. 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.

Interfaces (Wei Lin, Che Chu & Brittany DePoi)The Mobile Medical Management Application (MMMA)PHA (good consistent use of

MMMA – but we call it PHA) is intended to let users to record their health condition on their smartphonemobile device (let’s try to be general). Some of the users are elderly people. Therefore, the interfaces are designed to be intuitive and graphical. Mock-ups of the interface are shown in the next section.in figures throughout the section; they are organized the presentation by the different categories of screens: LIST THEmPatient Information, Medication Center, Disease Center, Daily Activity and settings.

Patient Interfaces:

The patient has many options to conveniently manage health information regarding a chronic disease, as we denote in the use case diagram of Figure 4X. This is done by having daily reminders for organized entry and storage of personal health monitoring information on the patient’s personal medical device. Default interface options are available for diabetes, asthma, heart disease and obesity, along with additional options to be defined tahat the patent might want to record and/or upload. Similarly, if the health care provider would like some additional information other than the standard default, there is functionality for the health care provider to make specific requests.

The patient interfaces make use of user input, as well as the inherent capabilities of the mobile device. The mobile devices, in all cases, are can be used as a pedometer and accelerometer to track and monitor patient activity; the project will examine the way this information can be collected, either in a set period (e.g., during a walk) or throughout the day. This option is available to those that simply have the parent patient application and do not wish to track a certain disease. Another feature we take advantage of is the mobile device’s camera combined with Microsoft HealthVault’s image upload option. This way the patient can upload any relevant pictures or images of documents to the health care provider. The images are not uploaded the same way as the disease information, but are uploaded to the standard HealthVault storage using the API.


In terms of the specific diseases, certain interfaces are shared to remove any redundant information and ease patient use and time. All of the data gathered from the interfaces are combined to a single submission and sent over the wireless or cellular network to HealthVault as a JSON object.

From HealthVault, the patient will be able to access the analyzed and stored data to see trends and any comments made by the health care provider. This also requires an interface. However, unlike the others described above, this one does not interact with the other interfaces that acquire information and send it to HealthVault. Instead, it accesses HealthVault to display the information. Basic analysis, such as tables and trends, will occur once the data is retrieved on the mobile application. For example, the algorithm used to analyze the diabetics glucose and exercise information will provide feedback about how much insulin to consume. Also, any exercise tracking will be displayed to the patient in a table so that he or she can track exercise progress. Other quantitative data such as peek flow for athsma or weight for obesity can be displayed in a comparative way, again to provide informative, easy to understand feedback. I am not sure what you mean? Our iphone apps let a patient run a graph – I am not sure the android does as yet.

There will be another component (servierserver side) of the proposed system to handle disease specific analysis. Advanced analysis, such as graphs and algorithms (e.g. diabetes algorithm), will occur when the health care provider access the information. In this way, the interaction between HealthVault and the patient user end remain very basic, simply receiving a request and either storing or relaying a JSON object. The patient use case diagram below details the patient and interface interactions.


Figure 5: Use Case Diagram of Patient Options

Main Screen

The current conceptualization of the PHA with its current and to be include features include a The main screena series of screens as shown in Figure 5 that will have 5 options corresponding to each of the possible patient actions: Profile, Medication Center, Disease Center, Daily Activity, and Settings. We examine each of these options in turn.


Note: We have another paper that has PHA screenshots embedded in a PPT (see below). You can reuse this and embed as many screen samples into one figure and then connect them with a flow and refer to them. Again, right click, presentation object, open. If you change the page setup size (margins) you can a bunch of shots.

Figure 6: Application Main Screen


The first screen (upper left in Figure 5), ProfileThis option allows the user to enter their personal information, such as name, age, gender, profile picture, and Windows Live ID account. Since Microsoft HealthVault allows the user to sign up using a Facebook account, we have included an option that allows the user to link their Facebook account and HealthVault database. Users who don’t have either account can create a Windows Live ID in this section or in a separate browser...

The bottom half of the screen also shows the medicines that user is currently taking.

Figure 8: Patient Profile Screen

[1.] The MeciationMediation Center (shown in the upper middle of Figure 5) Medication Center

Figure 7: PHA Screen Shots -- Patient Version


This option keeps track of the medicines the user is currently taking and gives information on medication. The medications are categorized in the disease the medicines are related to. When a user selects a medicine from the drop-down menu, related information to this medicine is displayed, such as the last time the user has taken the medicine, recommended daily intake, and instructions on medication.

Figure 9: Medication Center Screen

Diseases Center

The Disease Center (shown in the XXXlower left of Figur e 5) (make changes throughout the rest of the section) is the place forfor a patient to manage and keep track of their condition. It, gives patient data which is related to the disease the patient wishes to track. It also, and generates diagrams and graphs to allow the patient to see a progression in their health.


Figure 10: Disease Center Screen

[2.] Daily Activity MAKE SIMILAR CHANGES – PUT INTO ONE FIGURE>

The Daily Activity Screen (shown in the lower middle of Figure 5) screen lets the patient enter in daily information. This includes their diet, medication intake, exercise, and other data related to the specific diseases (daily measurements). The data entered is then uploaded to Microsoft HealthVault using an openEHR.

Figure 11: Daily Activity Screen

Settings

Finally the settings This option let users modify their personal info, alerts setting, reminder, sync calendar, backup data, and privacy settings.


Health Care Provider Interfaces:The provider app allows the healthcare provider to review medication information and

daily measurement input from their patients. It would also alert the healthcare provider of any potential threats to the health of the patient based on the data provided by the patient. This interface will allow the health care provider to take the following actions: view the patient information, analyze information recorded by the patient, provide feedback and request additional information.

Figure 12: Health Care Provider Actions


From a healthcare provider’s perspective, he/she has the option to specify requested information in addition to the default options on the user interface end. Mainly, the healthcare provider interface provides means to view and analyze the data and give patient feedback. This is not done through direct communication with the patient, but again through HealthVault using JSON objects. The health care provider end holds the functionality for advanced analysis.

Information (M. Swircenski)The purpose of the PHA is to facilitate information transfer between the patient and the

healthcare provider. Thus, information is an important consideration. There are many types of information used by the PHA application, divided into four groups: Daily Activity, HealthVault Information, Profile Information, and Application Settings.

Daily Activity: This is information entered by the patient recording their daily activities. This includes disease progress, diet and exercise, and their medication usage. The information is stored in JSON objects locally, and transmitted to the HealthVault database. The length of time each type of data is stored locally is controllable in the settings; the defaults are two weeks.

Disease Progress:This is information entered by the patient recording the daily progress of their disease(s). This data can analyzed locally to create charts and graphs displaying a visual representation of how the disease is progressing. The analysis is only stored temporarily, either until another analysis is run or the mobile device needs to reclaim the space. The user can, however, choose to save an analysis so that is stored permanently until the user decides to delete it.

Diet & Exercise:This is information entered by the patient recording their daily diet and exercise.

Medication Usage: This is information entered by the patient tracking their daily medication.

HealthVault Information:This is information used to interact with the HealthVault database. This includes information used to connect to the HV service, information regarding the identity of the application (and thus what data it can access), and session authentication.

Connection information:This information is used to communicate with HV. It is hard-coded into the application and not changeable by the user, and consists of URLs and/or IP addresses.

Application Identity:


This information is used to identify the application. It is created automatically when the application is first started and connects to HV. The Patient chooses which applications are allowed to access their records. This information is kept permanently.

Session Authentication Token:This is information regarding an authenticated connection to the HV service. It is obtained by sending the application credentials to the HV service. Afterwards, the application only needs to use the authentication token to communicate with the service. The information lasts until HV tells PHA that the session has expired, at which point PHA repeats the above and gets a new session token.

Profile Information:This is information storing information about the patient and their healthcare provider(s). It consists of strings and numbers. The information is stored permanently until changed by the user.

Patient Profile:This information is taken from the Patient’s HV account information.

Healthcare Provider Profile:This information is input by the patient for the purpose of easily tracking permissions granted.

Application Settings:This is information regarding various local application settings and preferences. It is stored permanently, and can be changed by the user.

See overall comment- I think you really need to rethink this – the decision support algorithms to analyze the data need to work on an available data set. If we somehow store this is MSHV, it may be problematic to extract the info. You should start an email discussion with Prof. Wang about this and what data needs to be stored and how it is analyzed. That will impact the overall architecture and approach as well.

For the info section and as a team you need to work on the appropriate data to collect for chronic diseases. Do some web checking and when you have some data, shoot an email to both Prof Wnag and I. This section really needs some thought – I am not familiar with the algorithms that Prof Wang has expertise, so we need to touch base with her.

The purpose of the Mobile Medical Management ApplicationPHA is to facilitate information transfer between the patient and the healthcare provider. Thus, information is an important consideration.


When the patient enters daily information (e.g. diet, physical activity, changes in condition), the application packages it in a JSON object and sends it to HealthVault. The data is only stored locally temporarily. From HealthVault, it can be accessed by the healthcare provider, who can then add comments and analyze the data.

The information generated by the healthcare provider can then be downloaded back to the patient’s device, where the patient can then review it and see how they are doing. This information is also stored temporarily, until either new information is downloaded or the device needs to clear up room for other applications.

System Operation (Brittany DePoi)

General OperationThe Mobile Medical Management Application is an event driven application with three

major components. The first is the collection of patient user interfaces on the patient’s personal mobile device. These interfaces capture patient information for a specific disease. Depending on the current health of the patient, the patient will have the option of downloading interfaces specifically for diabetes, heart disease, asthma or obesity. This information is then uploaded and saved to the Microsoft HealthVault database, where security is optimized using preexisting features. The healthcare provider can then access this information through the Internet, run optional diagnostics on the information and provide the patient with feedback. In addition, the heathcare provider can also request additional information through an optional custom interface. This is all good material for the intro.

Performance (Wei Lin)The front end of the PHA system will be run using a smartphone mobile device. This kind of system offers many new technologies that can be integrated into the PHA application such as pedometers and accelerometers that can be used to collect movement data. This can be useful for collecting data for the daily activity screen such as entering data for workouts, or using the camera to take BP and pulse. The multi-touch gestures can also be integrated into the user interface to increase productivity for the user. However, the mobile system can also have challenges to consider. First, there are dozens of different smartphones out on the consumer market and every device has different hardware and software. The PHA application has to be able to detect the different hardware with different capabilities and functionalities. For example, some devices might not support multi-touch gestures so the system has to be able to adjust according to what hardware is the user using. The software is also a performance issue. The two main operating systems on the market are iOS and Android. Each of these also has different versions with different capabilities and performance. The application has to be able to perform basic tasks based on which version of which operating system it’s using. By using the Titanium platform, two sets of native source code for iOS and Android can be generated from one set of Titanium source code.


The performance of the system in the back-end is also important in order for the application to run smoothly. First, the system has to be able upload and download data efficiently through Microsoft HealthVault. An intermediate MySQL database can also be used to diversify traffic, which can be used store temporary data before being pushed to Microsoft HealthVault. Another performance factor to be considered is the limitations of using cellular network for uploading and downloading data from databases. Cellular network speeds can be difficult to predict according to the location of the user and it is usually slower than the current Wi-Fi technology. The system should also detect what kind of data speed is the current device getting before downloading and uploading new data onto the device. To limit the use of cellular connections, the application should also be able to store some data if there’s no network connection.

This application should overall be able to support older technology as well as newer generation models because this application is geared towards lower income consumers that might not be able to afford the newest and best technologies.

This is a good start – but you need to link to other sections that mention using pedometer and accelerometer to collect movement data, and other data that the user inputs. Can the mobile device do both at the same time? Are the same movement devices in phones as in tablets. What is the volume of info collected (you need to figure out what info you want). If we have a treadmill that can give us BP and pulse, how would we capture that. In a mobile device, the performance of the hardware is limited in terms of power and memory. Since the application is going to be run on a cellular network with slower upload and download speed then a standard Wi-Fi connection, retrieving and updating patient data has to be fast. The application also has to be designed in a way that would allow it to run smoothly in all aspects with minimal wait time for the patient and the healthcare provider. The Titanium platform is able generate native code for iOS and Android which can enhance performance. By using Microsoft HealthVault, uploading and downloading data from the database should also be sufficient in terms of speed.

The application should be geared towards the lower end mobile systems with limited performance. For android systems, the application would be able to run on older generations of android. The application would support android 2.2 (API 8) and up. For iOS systems, the application would also support lower end systems from iOS 5.0 and up. The application would also be able to run on different types of devices with different screen sizes and resolutions. Network connection will be a big factor is the design of the system. Most of the expected user will be using a 3G cellular network with limited downloading and uploading speeds. A lot of this is very general and could apply to almost any app – you need to get more specific and think about functionities. The back end of the application would be able to handle the daily operation for multiple users uploading new data through Microsoft HealthVault using the daily activity interface. By using Microsoft HealthVault, uploading and downloading from the database should be sufficiently fast. This may not be true – we may not want to store the data on diseases into MSHV – it may be in a separate MySQL database.

Security (J.R)


The aim is to store and access personal medical information for both the patient and provider without any possible security threat while following HIPAA guidelines. Communications using XML schemas, namely JSON, will therefore interact with open medical records such as MSHV and openEHR to properly enforce privacy rules which are of utmost importance. Personal Health Assistant (PHA) has two separate applications, one intended towards the patients and the other towards the providers. The patients will be able to manage their PHR and share this information with their provider’s application while enforcing the patient security policy.

The patient oriented application will be able to store information in MSHV and give the provider special permissions to decide if they can edit or view certain information. Depending on these permissions, the provider will have limited access to the patient’s information. If the patient has multiple providers, the patient application will have the ability to give different permissions to each provider.

The application will be designed with access control in mind based on the roles the users play. Certain users will have access to certain parts of the XML schemas that contain all the information and therefore ‘roles’ will be created or passed on between users. In order to achieve this, there is a security framework in place that provides customizable access to XML elements by generating XCAML security policies and enforcing security at the runtime level on XML instances to ensure data is delivered securely. PHA also uses a central server to generate reports and retrieve information from MSHV using a series of JSON API calls and XML HealthVault API.

User security policies can be as important and their personal information. They also need to be retrieved each time a call is made to the server. Hence users policies are created with their account and stored along with the PHR. The policies are filtered through first before any information is sent to the providers. Hence, the security is achieved by removing the information which should not be visible to the provider before it is sent. MSHV service allows for more than one log in system. The user can use Windows Live ID, Facebook ID credentials, or identifiers from certain providers. This can be done directly with HealthVault’s website and the PHA app connects to this information to grant or deny access though MSHV’s API. The service will also be tied to personal information such a name, date of birth, email, address, etc.

A lot of the user permission will be handled in the back-end. However the user also needs to have a clear and easy way to set these security policies. This is done by adding a permissions page with clear options for each provider the patient is tied to. The patient can easily see all the information currently shared and check or uncheck view and edit boxes to change the permissions. Patients have all the access to MSHV at all times and can therefore change the levels of access for Custodian Access (providers), which include:

Read the record Change the record


Delete the record

Grant and revoke to others any level of access to the record.


You have to look at a system view… what does MSHV provide? When a user enters a new med on the PHA app or enters their BP, etc., is that med being transferred via JSON calls over a secure (https) channel? What about data coming back in terms of analysis to patients and providers? How does that need to be protected? The aim is to have accessible information for both the patient and provider without any possible threat to private information while following HIPAA guidelines. Communications to outside sources are encrypted using JSON encryption to meet these standards. Patient and providers have a registration process where usernames and passwords are used to access their respective information.

Information stored in HealthVault is mainly read only and is not allowed to be edited by the patient. This isn’t true – someone can log on to HV directly and make a change. People enter new meds – those need a write. Plus all of the new disease data needs to be stored somewhere. Therefore, only read access is required to communicate with the server. Providers however are able to edit patient information as they need to. Any calendar events are stored locally on the device’s local database, which is also encrypted.

The Microsoft HealthVault service allows for either Windows Live ID, Facebook sign-in credentials, or Identifiers from certain providers. The service will also be tied to personal information such as name, date of birth, email, address, etc. How is this PII (personal identifiable information) protected? Depending on which features are used, emergency profiles information is also required.

The levels of access that can be shared with service users (patients vs providers) include:

Actually, patents have all access to MSHV at all times to do whatever they want.

- View-only access (time-limited access)

- Vied and modify access (time-limited access)

- Custodian Access (no time limit)

A custodian (in this case the Providers) can:

This will be constrained and authorized by the user.

- Read the record.

- Change the record

- Delete the record


- Grant and revoke to others any level of access to the record. (this feature would only be available to system admins)

Glossary (J.REveryone)HealthVault: Microsoft HealthVault is a platform from Microsoft to store and maintain health and fitness information

openEHR: An open standard specification in health informatics that describes the management and storage, retrieval and exchange of health data in electronic health records (EHRs).

JSON: (an acronym for JavaScript Object Notation) A lightweight text-based open standard designed for human-readable data interchange.

Android (Operating System): A Linux-based operating system for mobile devices developed by Google.

iOS: An operating system developed by Apple Inc. that is used on all of their mobile devices.Interfaces: A way for the user to interact with the software/application.

Software Development Kit (SDK): Set of development tools that allows for the creation of applications for a specified system/environment.

Titanium Mobile SDK: Development tool that uses mobile operating system API’s to create native applications that perform and behave just like they were written natively.

Database: A structured set of data that can be organized, stored and accessed in various ways.

HIPAA: The Health Insurance Portability and Accountability Act, which protects the privacy of individually identifiable health information.

ASP.NET: a web application framework developed by Microsoft to allow programmers to build dynamic websites, web applications, and web services. It is a successor to Microsoft’s Active Server Pages (ASP).

API: Application Programming Interface is a specification used as an interface by software to communicate with different components.

CCR: The Continuity of Care Record is a specification for a subset of patient information that encapsulates current and the most relevant facts about a patient’s health condition.

XML: extensible Markup language is a markup language that defines a set of rules for encoding


documents in a format that is human-readable. XML files are often used as a mean to exchange data with various software platforms.

MySQL: MySQL is an open source relational database management system developed by Oracle (formerly Sun) and is popularly used in web applications.

mobile medical managementengr.uconn.edu/~steve/cse4939w/teamgfinalspec.docx · web viewpha operates...

Documents