Mobile App

Domain Analysis

Key Domain Concepts

• Patient - A placeholder which represents the patient. The patient has an assigned id number which in no way relates back to the person, but simply serves to note the current user of the application. This serves only for anonymous data collection.

• Symptom - A symptom that manifests in the patient due to the condition. Each symptom has a name, a description, an image, and an icon.

• Treatment - A means of treating the condition. Each treatment has a known set of advantages and disadvantages, a title, an icon, an image, and a description.

• Cause - A cause of the condition. Each cause has a title, an icon, an image, and a description of the cause.

• CauseGroup - A grouping of potential causes of the condition. Each cause group has a title and a collection of related causes.

• OtherNeed - This represents other patient needs and is used in the decision making process. It focuses on questions to the patient and the gathering of additional information they may not have considered relevant until now.

• Condition - This represents the overarching mental health issue with which the patient is currently focusing the decision making process on.

• ConditionLoader - This class loads a condition and related assets into the app at runtime. This includes loading all the underlying components such as the condition, its cause groups, treatments, other needs info, and symptoms. Each of these components are provided with their text and image assets as well.

• Settings - A dataholder representing the current settings of the application. This can include whether patient data is collected, whether usage data is collected, and how often such data is uploaded.

UI Sketches

Package Creation Tool

Concept

Content packages provide the ability to configure the app to handle multiple mental health (or perhaps general health) issues. The following diagram depicts this concept in action.

Basically, there are two primary components: (i) The App and (ii) The Cloud (or internet, if you prefer). The app is basically subdivided into two main components (rounded rectangles) the User Interface (UI) which displays data and collects data to/from the user. This concept and its design is embodied in the above UI mockup. The second main component is the underlying domain model. These are the actual programming constructs which hold the data and maintain the relationships between this data while the app is running. The domain model stores this information in a database (the cylinder) local to the app (hence the arrow pointing from the domain model rounded rectangle to the cylinder). Additionally, to populate the information that is displayed and stored by the domain model while the app is running, are a set of what we will call "content packages." These content packages contain all the information to configure the app to a specific mental health issue and allow patients and providers to effectively communicate and guide decision making. On the device many such content packages can be stored (thus, the folder with a collection of cubes).

So the question is, what does the cloud have anything to do with this? This is an excellent question. The answer is that over time as many patients use the tool, their usage data (not their personal data) can be collected from the mobile devices and aggregated into a secure database controlled by the Shared Mental Health Research Group. This is depicted by the gray arrow from the app cylinder to the cloud cylinder. Additionally, as more Content Packages are developed, they can be downloaded (via an update component of the app) to the mobile device, as they become available.

Content Package Structure

Content packages have the basic structure shown in the following image. The files and folders comprising the structure are compressed using an algorithm like the zip or bzip compression algorithms and can then be sent across the internet or a USB cable to the mobile devices.

Because, we are assuming that non-programmers would be the lead creators of these packages, and would probably not have the technical knowledge to put this together by hand, we suggest the development of a tool to suit this purpose.

UI Sketch

The following UI Sketch is the initial sketch of a tool that would facilitate the development of a content package for this app.

Content Data Structures

app_data.yml

app:
  condition:
    name: "Depression"
    primary_color: #ffffff
    secondary_color: #f0f0f0
  welcome:
    text: "...."
    bg_image: app_images/bg.png
  about:
    text: "...."
    logo: app_images/about_logo.png
  decide_inst:
    text: "...."
    bg_image: app_images/decide_bg.png
  understand:
    text: "...."
    intro_bg_image: app_images/und_intro_bg.png
    other_sideline: app_images/other_sideline.png
  thankyou:
    text: "..."
    bg_image: app_images/thankyou_bg.png

causes/data.yml

causes:
  group:
    name: "name"
    cause:
      title: "title"
      short_title: "short"
      description: ""
      icon: "images/group01/icons/xxx.png"
      display_image: "images/group01/display/xxx.png"
    cause:
      title: "title2"
      short_title: "short2"
      description: ""
      icon: "images/group01/icons/yyy.png"
      display_image: "images/group01/display/yyy.png"

symptoms/data.yml

symptoms:
  symptom:
    title: ""
    short_title: ""
    description: ""
    icon: "images/icons/xxxx.png"
    display_image: "images/display/xxxx.png"

treatments/data.yml

treatments:
  treatment:
    title: ""
    short_title: ""
    description: ""
    icon: "images/icons/yyyy.png"
    display_images: "images/display/yyyy.png"

other_needs/data.yml

other_needs:
  need:
    name: ""
    question:
      text: ""
      type: yesno
    ifyes:
      text: ""