The PHIT architectural model is based on the subjective and objective measurement, assessment, and plan note methodology [9] for health status analysis, intervention recommendation, self-help activities, and data presentation, creating a feedback loop of personalized health (Figure 1). All data collection, analysis, and planning are performed locally on the mobile device, rather than via Internet services, with secure local data storage. PHIT has the following primary features:

Research studies are supported using data objects that tag data with information on the study, protocol, participant identification, and other related information to facilitate analysis. Data access is facilitated using a website dashboard allowing the researcher to monitor the state of longitudinal studies and download study data into comma-separated files for easy analysis. Furthermore, 90% of the app configuration is done via extensible markup language (XML) making it easy to change the behavior of the app.

The PHIT architecture allows the researcher to reuse data-collection instruments or create their own instruments. Using XML, each instrument has a series of forms (screens) composed of data-collection entities, which represent a data point the researcher wants to collect. For example, a user history instrument may ask for age, weight, and gender information on the first screen and vital signs such as blood pressure and body temperature on the second. These two screens are considered forms in PHIT, and age, weight, gender, systolic and diastolic measures, and temperature are entities. Entities represent the data the researcher is collecting and have two facets to them, namely, (1) the internal, logic side and (2) the graphical user interface. If the app is configured for data storage, the user’s responses are automatically saved. If desired, a researcher may configure the PHIT app to periodically upload data from the local secure database to a backend server, thereby allowing the researcher to examine the collected data and monitor study progress.

The majority of instruments are data-entry instruments, using familiar entities such as text fields, checkboxes, and selection lists. Many of these implement well-established subjective health screeners and assessment instruments previously administered through paper forms. Others had been developed ad hoc as needed for a particular study, such as the military deployment history instrument for the PHIT for Duty project. These also can be reused, or adapted as needed, to support new studies. PHIT has a library of over 50 such standardized instruments, including the examples in Table 1.

In addition to the standard data entry fields, radio buttons, and checkboxes, other entities provided by PHIT include audio playback, charts, date picker, image display, Likert scale, and specialty entities, such as game-like cognitive tests (eg, reaction time). These can be combined in various ways for building both data-collection and intervention instruments. For example, following several alcohol reduction-related screens, a series of slides can be combined with audio narration for constructing an integrated multimedia alcohol education instrument.

By coding the entire instrument in XML, the question definitions, codebook responses, data validation, skip logic, and overall flow of the instrument are defined in one place, making it easy to adjust as necessary. The XML definition in Textbox 1 drives the first form from the PTSD checklist instrument used in our “Flight Attendant Wellness” app (Figure 2).

Using simple descriptive text, the form is made up of a single entity, named Q1, comprising a question with a series of radio buttons for the responses. The codebook values are defined in the code attribute of the item element and both the user text and the code are stored in the database. When the user selects one of the five radio buttons, a variable is created as instrumentName_entityName (ie, PCL_Q1), and the variable, a string type, is set to the selected code attribute.

Forms are not restricted in the number of entities they can contain. For purposes of this paper, the form example was kept simple. Textbox 2 shows a more complex example showing 4 entities on a form and the use of the vertical and horizontal elements to control user interface layout (Figure 3).

In addition to the instrument and form definitions, business logic is included. There are a number of different events that are triggered during the course of an instrument (Figure 4). Consider again the first form of the Post-Traumatic Stress Disorder Checklist (PCL) instrument. When the user presses the next arrow, the form’s onFormExit code is executed before the next form is displayed. In this case, when the user responds with “Moderately” or higher, the variable PCL_Bcount is incremented by 1.

In Figure 4, the second form (F2) is expanded to highlight the different events. Of particular note are the onValueChanged and onValidate events. The event is first sent to the entity where the data change occurred to provide specific entity-level processing, and then passed up to the form itself where the form can look at all the entities collectively. All scripted logic is written with simple commands (Textbox 3).

Logic within the instrument XML file allows the researcher to decide exactly what validation and skip logic to have, to set initial conditions for instrument variables, and to execute code when the instrument terminates, such as calculating an overall score or saving data to the local secure database. With the instrument completely defined in the XML file, it becomes a reusable object to be shared across apps with the same expected behavior. Other than content used by the instrument, no other dependencies are required.

In addition to form-based data entry, the PHIT platform can also collect objective data from internal device sensors (eg, global positioning system coordinates) and external Bluetooth sensors (eg, heart rate monitor or fitness accelerometer). In the PHIT for Duty study, where individuals with post-traumatic stress are taught mindfulness exercises for stress reduction, the mobile app uses a heart rate monitor during the mindfulness meditation to calculate heart rate variability (HRV) and graphically show whether the user is achieving a more calm state. This is illustrated in the middle-line chart of Figure 5. Notice the rise in the middle graph after the onset of meditation as the user goes from a stressful state to a calm state.

Whenever sensor data are acquired (eg, the heart pulse rate) and processed to produce a derived measurement (eg, the HRV index), the PHIT software allows for saving interim data at each stage of data processing. Such storage facilitates verification of data-processing algorithms and supports both reanalysis and alternative analysis of raw data at a later date without repeating the data-collection activities. This facilitates exploratory analyses of mHealth data for determining optimal processing methodologies without the expense and effort of repeated field studies, saving a considerable amount of both cost and time.

In addition to user-facing instruments, PHIT provides a means for performing background tasks using instruments without a user interface. Some examples are (1) querying the battery state, (2) uploading data, and (3) retrieving the current global positioning system location. These script instruments, because they run in the background, do not have forms or entities but they do have the onInstrumentEnter and onInstrumentExit events for which custom logic can be written. Such tasks can be developed to execute singularly on demand, or execute repeatedly at a specified interval, like every 5 minutes.

Tying it all together, the PHIT platform interprets the instrument definitions and creates the user experience, displaying the appropriate instruments in a task list on the “Home” screen. Attributes of the instrument such as title, description, icon filename, and menu index determine exactly what the user sees and in what order. To reflect a change in state, an XML logic can be written to modify these attributes to highlight changing conditions, alert the user to perform a critical task, or simply change from day to day according to a protocol.

To avoid overwhelming the user with many instruments, instruments can be scheduled. This minimizes burden on the user by cleaning up the user interface and only displaying what is currently relevant. Using the built-in scheduler and the hide and show commands callable from the XML logic, only those tasks appropriate at a certain point in time will be displayed. The PHIT scheduler extends RFC5545, the Internet Calendaring and Scheduling (iCalendar) specification [31], specifically the DTSTART, DTEND, DURATION, and RRULE properties of the VEVENT calendar component. For example, the PHIT scheduler can set an instrument to be scheduled to be on the task list each Friday at 8 am.

PHIT’s iVA is an expert system logic layer where data are analyzed and plans are created in real time on the mobile device. The iVA tailors its analysis so that the help the user receives is personal and timely, with reanalysis occurring as frequently as the researcher wants it to happen (ie, daily, weekly, or monthly) using the PHIT scheduling function. The iVA program modules are used to stratify health assessments (eg, normal, moderate dysfunction) and to prescribe and schedule self-help activities (eg, exercise, meditation, alcohol reduction) according to the evidence-based criteria provided by the mHealth app researcher.

Consider this example in which a person with a sleep disorder is being evaluated using the Pittsburgh Sleep Quality Index (PSQI) instrument. Upon completing the PSQI, the sleep improvement protocol may recommend the following activities whenever the score exceeds a value of 16:

Just like the instrument logic, iVA logic is defined in XML that is organized by domain for easy reuse. Continuing the aforementioned example, the sleep assessment portion of the iVA script is shown in Textbox 4.

Planning is also handled within the iVA logic. Continuing the previous sleep example where the PSQI score is above 16, the iVA sets the iVA_sleepRisk variable based on the PSQI_score and tests that condition as defined by the protocol in Textbox 5.

The PHIT interventions and activities are implemented using the same scripting and script-processing methods as data-collection instruments; the XML constructs are identical. An intervention might display a series of slides, collect heart rate data during a relaxation exercise, or support behavior modification. For example, a series of images can be combined with audio narration to create an alcohol education module that can be reused across different PHIT apps. Interventions are study and protocol specific and with PHIT’s library of reusable interventions (Table 2), many can be easily tweaked to be content specific for specific intervention needs.

The logic written for either instruments or advisor coding is processed by the same logic processor. It supports common programming constructs in a simplified language format. Each logic statement reads like a sentence that ends with a semicolon.

Variables are used to keep track of information in the system, can be accessed globally across XML scripts, and persist until the app terminates. The PHIT naming convention for a variable is <objectName>_<variableName>, which provides a somewhat object-oriented variable naming construct. The PHIT variables are wrapped in “{}” (curly braces) to simplify runtime parsing of the logic code as in Textbox 6.

When processing this example code statement, PHIT looks up the value of ptHx_status, compares it with the string new and if they are equal, sets ptHx_status to the string started. The variable ptHx_status refers to the instrument named ptHx (patient history), and the status entity within the ptHx instrument. As no other instrument, or object, may have the same name, the identity of the global variable is assured.

When a variable is evaluated, an attempt is made to determine whether it is a number, and if so, evaluates it as a number. Otherwise, it is treated as a string. If ptHx_age is set to 1, then if (“{ptHx_age}” <= “2”) becomes if (1 <= 2). The PHIT logic processor is not rigid; it will automatically convert a quoted number to a real number object when the evaluation is performed, allowing the nonprogrammer who is writing this logic to have more flexibility. Boolean variables remain represented as strings, with “true/false” being the default, designated Boolean values.

A variety of programming statements are supported (Table 3), which are sufficient to meet most programming requirements. These statements are supplemented by the PHIT application programming interface (API), a set of global functions to provide scripted access to frequently used processes such as data conversion, database storage, and retrieval, playing sounds for effects and notifications, displaying pop-up messages, and formatting number variables as strings.

To analyze historical trends, the API provides query functions to the local database as the following shows:

Should a particularly complex XML script cause performance problems due to runtime compilation, you may recode the XML script in native code as an API function as “isPSQITrendingDownward.”

Although not common, any native code you write is automatically compiled into your PHIT app when the app is built.