Value-based modeling for mobile health application development

Introduction

In this paper is presented part of an ongoing, systematic effort to develop mobile applications for healthcare systems. The focus of the effort described herein regards the employment of value-based modeling for app design development. The conceptual foundation of such an effort is design science, which has been described as the scientific study and creation of artifacts built to solve problems (1). It can be said that the goal is not to build a particular tool to solve a particular problem, but to understand the problem and the available methods of solving it in such a way to advance the state of the art. In the pursuit of design science, the artifacts developed may include methods and models.

For this endeavor, the project team has focused on modeling. This is so because in the field of electronic commercial services, which includes mobile applications, the production of requirement specifications and conceptual models are accepted means of development (2). Furthermore, model building can facilitate communication with stakeholders, allow for semi-automated analysis, and can be used to avoid some of the pitfalls of natural language (3). The use of natural language for requirement specification is accompanied by known risks such as ambiguity, contradiction, overspecification, the inclusion of irrelevant information, and the omission of valuable information (4).

Many research strategies exist to perform investigations. As the development of mobile applications for healthcare delivery necessarily involves multiple disciplines, the project team began the project with an examination of the history and development of domain-diverse research (5). The approach decided upon for the project can be described by the term “convergence”.

Convergence has been defined by the National Research Council (NRC) as an “approach to problem solving that integrates expertise from life sciences with physical, mathematical, and computational sciences, medicine, and engineering to form comprehensive synthetic frameworks that merge areas of knowledge from multiple fields to address specific challenges” (6). To state the matter another way, convergence is a problem-solving approach that focuses on integrating the life sciences and medicine on the one hand, with the physical sciences and engineering on the other. To be specific, the instant project involves an effort to combine medicine with engineering.

During the second phase of the project, attention was turned toward the problem-domain of healthcare. An investigation was made into the development of case management in the United States as a tool for effective healthcare delivery (7). Case management has been defined as the coordination of disparate services for the benefit of an individual (8). The existence of three factors drive the need for formal, coordinated assistance. First, the task requires specialized knowledge. Second, vetting is needed to choose among several service providers. Third, navigation of difficult, idiosyncratic processes is required to access services (7).

A process model and an information-channel model were developed for a case management system operating in the field of drug addiction recovery (7). These models integrated different engineering perspectives regarding process, information, and systems. The models described the process of case management, tracked communication through the system based on information theory, and partially deconstructed the system using Conant’s Method. One of the results of this work was a determined need for the continual updating of the client’s condition to a centralized database with access for every actor in the system (7). The practical application of such a recommendation has legal, technical, and tradition-based challenges, but the benefits of such were highlighted by the models.

For the instant or third phase of the project, the research team endeavored to do two things. First, apply value-based modeling to a straightforward mobile health app design. Second, use the insights provided by the model to improve the design. The method of value-based modeling will be discussed first.

This paper reports development of a value-based model using PArchitect software. This was not an interventional study, and no data were generated, thus the paper was not written according to defined reporting guidelines.

Methods

Value-based modeling represents actors who are exchanging with each other things of economic value. The actors are often customers and service suppliers. The things of value are often service outcomes and money (9). Value-based modeling is a business modeling technique, often used for commercial service development. However, it is proposed herein that the use of the term “service outcomes” lends the technique to the application of health treatment outcomes.

In value-based modeling, the terms “value objects” and “value propositions” are used to denote what is being offered and what is being requested in return. Describing the state of the actors in relation to these value propositions is the focus of value-based modeling. In contrast, process-based modeling focuses on the tasks whereby the value objects are provisioned (9). These two complementary approaches may be considered to be the what and how of the situation under investigation, respectively.

For example, a process model of an internet merchant sale will describe the sequence of tasks required for the customer to receive a product or service and for the merchant to receive remuneration. This approach does not account for the value to the consumer, such as customer satisfaction, fulfillment of a need, or resolution of a problem. Neither does the approach account for the value to the merchant, such as profitability. In other words, the process model does not answer the question: was the transaction worth it?

A value model, on the other hand, describes the value flow. The focus is on how value objects are offered, accepted, and exchanged in a network. The sequence of the tasks performed to make a transfer is not represented in a value model. Neither is the physical movement of value objects. Instead, the elements that are required for the transfer to take place, the “dependencies”, are represented (9). Process models may be used to improve the operation and sequence of tasks required to exchange objects of value. Value models can be used to improve the net value of the exchange.

The elements of a value model can be quantified. This may include, but are not limited to actors, exchanges, transaction costs, resources expended, pricing, time, consumer needs, events, messages, and cash flow. Such elements have clear worth for determining whether the effort results in a net gain for the actors.

Several approaches and tools for value-based modeling exist. These include e³ value (10), Resource Event Agent (11), Business Model Canvas (12), and PArchitect (13). The project team chose PArchitect for the instant project. PArchitect is a software modeling tool that grew out of a project with the Brazilian Aerospace Agency for the analysis of highly complex operations (14).

PArchitect has its own terminology with which the operator must become acquainted. The main components of the PArchitect system are called transitions, values, and infrastructures. In the terminology of PArchitect, “transitions” are decision-making events. However, it appears that transitions simply represent the points of exchange of value goods. PArchitect subdivides the previously discussed concept of value into the values of “input”, “output”, and “reference”. This allows for the representation of any change had to the state of the value object by means of the exchange. In the e³ value method, by contrast, possession and ownership are the only state-changes recognized (15). Finally, in PArchitect the resources required to make exchanges happen are referred to as “infrastructure”. In sum, PArchitect allows for the representation of items of concern for a value model that are not present in other tools.

A funding proposal supplied the opportunity to put value-based modeling into practice. This was a proposal to the government of Saudi Arabia to develop a mobile application system for the improvement of access to health services (16). The initial idea for the proposal was simple: the client would self-monitor a health condition and report the results to a medical service provider by means of internet transmission.

Stated another way, the proposal was to develop a customizable procedure to identify, collect, and analyze individual health data variables using smartphone technology for data capture, cloud computing for data storage and analytical processing, as well as a user dashboard to access information to support patient care. The essential components were straightforward: client, digital mobile device, digital software application, health monitoring device, internet access, cloud-based data base system, big data analytics subsystem, machine learning subsystem, medical services provider, data-summarizing dashboard, and process management tool.

For this proposal, case management was not a factor. Even so, the project team planned to apply the lessons learned from the process and information modeling done on case management. The team then decided to perform value-based modeling on the proposed system to facilitate app development. The results of this modeling exercise and the lessons learned therefrom are presented below. Because this effort involved modeling and not implementation, no statistical analysis was performed.

Statistical analysis

Because this effort involved modeling and not implementation, no statistical analysis was performed.

Results

By use of the PArchitect modeling tool, a model of the proposed digital application software system was generated. It should be noted that models in PArchitect are organized in a tree structure. In this section, the model will be presented from the top of the tree down through the layers. First is presented the highest level of representation for the system. In Figure 1 can be seen the characteristic way in which PArchitect represents systems.

Figure 1 Highest level representation of mobile app system.

The state of the initial value is stored in the left-most object. In a value-based model, any suitable value may be selected for tracking. Here, a value associated with the client has been chosen, that being the client’s relation to a health condition. The initial client value is “unsatisfactorily managed health condition”. The center object, an oval, is the only transition here and represents the health monitoring system in its entirety. This is where all value exchanges will occur that will affect the initial client value.

When the client terminates all use of the app, the final value will be stored in the right-most object, labeled “Final Client Value”. This value is described as, “independent management of health condition”. This status would mean that the client has exited the plan of care against recommendation or has reached a health status in which the monitoring system is no longer recommended.

As will be shown, many value exchanges, or transitions, will be tracked in the model. In some instances, several different values will be tracked. Yet all the values, and all changes to values, will converge to the final value.

The objects at the top of Figure 1 are, from left to right, a reference and an infrastructure. A reference represents that set of instructions for how a transition should occur. An infrastructure represents an item needed to facilitate an event. A detailed understanding of these objects is not necessary here.

In Figure 2 is shown the structure of the health management system itself. The project team identified the four main transitions of the system as follows: IoT (Internet of Things) Enterprise System, IoT Information Center, Health Monitoring, and Health Assessment. Each one of the value transitions was modeled, or decompressed, to provide greater detail. In some cases, the resulting models were themselves decompressed further.

Figure 2 Decompressed model of health management system. IoT, Internet of Things.

IoT Enterprise System represents that set of digital components responsible for facilitating users’ access to the system. IoT Information Center represents that set of components responsible for collecting, categorizing, and cleaning incoming data. It also represents components necessary for the system to access cloud services. Health Monitoring represents the activity of the client pushing self-monitored health data to the system. Health Assessment represents the treatment provider reviewing the client’s data and pushing any changes to the plan of care to the client.

Note that there are two values exiting the Heath Assessment transition: Final Client Value and Returning Health. As previously stated, the final client value is the status client will attain when leaving the system. Where, however, the client will continue to use the system, the tracked value will return to the IoT Information Center for processing, and the cycle of monitoring and assessment will continue.

In Figure 3 is shown a decompressed version of the IoT Enterprise System first presented in Figure 2. This model represents the activity of users accessing the system. Five transitions were identified: Access Control, Secure Gateway, IoT Cloud Services, IT (information technology), and Login.

Figure 3 Decompressed model of IoT enterprise system transition. IT, information technology; IoT, Internet of Things.

Access Control represents a method of preventing unauthorized users and devices from accessing a private network. Secure Gateway represents a method of connecting protected resources to cloud resources. IoT Cloud Services represents the activities of cloud computing. IT represents the activities of network maintenance and upgrades, firewalls, security, interface analysis, operating system maintenance, server maintenance, and software deployment. Login represents the activity of a user accessing the system. This transition was decompressed and modeled, as will be presented supra. Access Control represents the system component responsible for authentication and verification such that no unauthorized users or devices can gain access.

The Login transition, originally presented in Figure 3, was decompressed and modeled. The project team determined that Login required six transitions: Invalid Login, Valid Login, Successful Login, Login System, and User Settings Display. This model is presented below as Figure 4.

Figure 4 Decompressed model of login transition.

Returning to the overview presented in Figure 1, the next major transition of interest is IoT Information Center. This transition was decompressed and modeled. Here, the project team identified four transitions: Data Synchronization, Anomaly Behavior Analysis, Classification, and Data Structure. The IoT Information Center model is presented below as Figure 5.

Figure 5 Decompressed model of IoT information center transition.

Data Synchronization represents a method of organizing and accessing data. Anomaly Behavior Analysis represents the component responsible for analyzing, correcting, validating, or rejecting data input to the system. This transition was decomposed and modeled. It will be presented supra. Classification represents a method of categorizing data according to data set requirements. Data Structure represents the component responsible for the systematic formatting, managing, storing, and retrieving of data.

The Anomaly Behavior Analysis transition, originally presented in Figure 5, was decompressed and modeled. Within this transition, the project team identified three needed transitions: Database, Data Mining, and Decision Making. The Anomaly Behavior Analysis model is presented below as Figure 6.

Figure 6 Decompressed model of anomaly behavior analysis transition. IoT, Internet of Things.

Database represents the activity of collecting all patient data in the database. Data Mining represents the activity of extracting data from the database. Decision Making represents the machine learning component of the system.

Returning attention to Figure 1, the next major transition modeled was Health Monitoring. The transitions shown within Health Monitoring are examples of different health measurements that a client might make and report. Three metrics were modeled and represented as transitions: Blood Pressure, Blood Sugar, and Weight. The Health Monitoring model is presented below as Figure 7.

Figure 7 Decompressed model of health monitoring transition.

In Figure 7 can be seen the way in which the value being tracked is split into sub-values. Any number of health conditions could be tracked. Thereafter, the values will converge to exit the transition enroute to the next one. During the Health Monitoring transition, the client will employ a health monitoring device and self-report the results to the app system. If the device is internet-connected and has been synchronized with the app, the pushing of data can be automated. If the device is not internet-connected, the client will have to manually enter the data into the app system.

Returning to Figure 1, the final transition modeled was Health Assessment. The project team identified that two transitions were needed here: Manual Decision System and Health Improvement Decision. The Health Assessment Model is presented below as Figure 8.

Figure 8 Decompressed model of health assessment transition.

In Figure 8 is represented the way in which actions are taken on client-reported health data. Here, the treatment provider reviews, on a dashboard-type display, a summary of the client’s self-reported data. The treatment provider will decide whether or not to alter the plan of care. If the decision is not to make a change, the treatment provider will have a second decision to make: whether to continue or terminate the client in the system. If the client will continue, client value will exit the transition via Returning Health value, and the cycle of monitoring and assessment will go on. If the client will not continue, client value will exit the transition via the Final Client Value, and will thereafter exit the entire system. If upon review the treatment provider decides that a change to the plan of care is warranted, the treatment provider will manually enter that change into the app system. The revised plan will then be pushed to the client via the app system.

Not shown in Figure 8 is the involvement of the Anomaly Behavior Analysis component, which was represented in Figure 5 infra. The detection of corrupted data from the client’s monitoring device or errors in manual entry must be dealt with before the health data is presented to the treatment provider.

Discussion

When the project team modeled the case management system, the results reflected the modeling tools used. Process modeling emphasized the importance of efficient task completion. Information modeling emphasized the importance of efficient and reliable communication. Modeling of the Saudi app system followed this trend: value modeling emphasized the importance of effective value exchanges.

The results revealed a limitation on the value exchange of medical services. This was related to the constraints of time, cost, and responsibility. Such a situation can be illustrated through descriptions of the two major methods of healthcare services delivery: one-to-one and one-to-many.

In the one-to-one treatment event, the treatment provider interacts with the patient in an individual-focused meeting. During the event, the treatment provider gathers health condition information from the patient. Laboratory or other objective data may be captured in addition to the patient’s subjective report and self-assessment. The information gathered will be the basis for an assessment, and the assessment will be used to create or modify the plan of care.

There may be significant time gaps between treatment events. As a result, the number of data packets collected from the patient will be limited by the number of treatment events. An illustration of this would be a patient who visits the doctor once every 6 months. During those visits, the patient’s blood pressure is measured. In this case, the doctor has only two blood pressure measurements per year from which to make an assessment, suggest a plan of care, and make an adjustment to treatment. It is proposed that a more informed image of the patient’s healthcare condition could be achieved by increasing the number of data packets received.

One method to do this would be to increase the frequency of appointments. This, however, may be constrained by several factors including cost, insurance coverage, the patient’s ability to travel to appointments, and the medical care provider’s time availability. Another method to increase the transmission of patient information would be to facilitate self-reporting by the patient between treatment events.

This might occur in two ways. First, the patient could use some traditional method to manually self-report. The patient could take her own blood pressure, for example, then call the doctor’s office to report the results. Second, the patient could use a digital monitoring device that would automatically perform the reporting task. The act of self-monitoring could itself be automated. An illustration of this would be a cell phone app that counts the user’s footsteps.

This is a straightforward and sensible view of how digital tools and communication can improve healthcare delivery. However, there are constraints to the actionability of the resulting volume of data. These are time and money. Assuming an idealized situation in which a patient can continuously stream relevant heath data to a healthcare provider, it is probable that the provider will not have the time or the ability to bill for reviewing this data and making a response.

A different situation is presented for the one-to-many treatment event. Yet constraints to the value exchange still exist. Here, the treatment provider interacts with a group of patients simultaneously. During the event, the treatment provider administers treatment and gathers data from the patients. The treatment provider can use the information gathered to adjust how treatment is being provided to the group.

One advantage of one-to-many delivery is time. It will cost less time for the treatment provider to meet with a group compared with a series of individual meetings. Consequently, a patient may have more encounters with a treatment provider in a one-to-many setting than in a one-to-one setting.

Even so, assessments may suffer in the category of one-to-many treatment. This may occur because, from the operations standpoint, it may not be a job duty focus to perform individual assessments of clients’ needs. Instead, job requirements may focus on delivery, reporting of results, and patient satisfaction.

A comparison may be made from this to education. The situation of an instructor lecturing to a classroom full of students appears to be a time efficient manner for the delivery educational material. Yet the instructor will be hard-pressed to perform individualized assessments of each student’s needs, or to make recommendations for adjustments. It is certain that managing a group requires a different skill than managing a one-to-one exchange. Classroom instruction job duties will likely focus on delivery, reporting of results, and student satisfaction.

The use of a tutor may be the result of this constraint on the value exchange. The tutor performs a one-to-one service whereby the loss of value is addressed. Again, just as with the one-to-one medical provider situation, the constraints are time and money.

The value-based model of the proposed healthcare app highlighted the constraints to value exchanges and made the above analysis possible. The project team responded to this by proposing an improvement to the design. The improvement consists in developing an automated decision-making subsystem within the machine learning component of the app system. The rules of the decision-making would be based on protocols established by the treatment provider.

The proposed healthcare app system would transmit and process the patient’s self-reported data. It was proposed that there is a category of assessments that can be performed based on this data. These assessments could be automated, based upon protocols established by the treatment provider. These automated assessments would lead to adjustments to the plan of care, which would also be done according to established protocols. An expected clinical impact of such a practice model is improved management of chronic conditions that require frequent treatment protocol adjustments to avoid exacerbation into acute phases. While improved health status from improved treatment management is a desirable clinical outcome, there should be associated financial benefits as well for the patient and for the health system, as acute care costs exceed chronic care costs at both levels.

The adjustments made based on the app model would be within a smaller range than those that the treatment provider might prescribe during a one-to-one treatment event. Anything falling out of that range would require direct healthcare provider intervention. However, such between-visit, micro adjustments would represent a more agile response to the patient’s changing needs. Further, the application of the lessons learned from value-based modeling suggest a response to the challenges of access to services. The improved design is presented below as Figure 9.

Figure 9 Decompressed model of health assessment transition with automation.

In Figure 9, it is shown that the client’s self-reported health data enters the transition and proceeds to the Classification transition. Here, a determination is made as to whether the data reported falls within the range set by the treatment provider. The Classification Reference provides this set of instructions to the transition. If the health data falls within the range, then a protocol set by the treatment provider will be triggered. The value will travel to the Automated Decision System. Here, the Health Monitoring Reference will provide instructions as to how the decision should be made. It may be that the health data reported requires no change to the plan of care, or it may be that some change is called-for. In the case of the later instance, a change to the plan of care is pushed to the client via the app. As with the operation of the Manual Decision System, the value that leaves the Automated Decision System will travel to the Health Decision System transition. There, the decision will be made as to whether the client will remain in the health monitoring system or leave it.

Proposed future work includes building a software-focused architectural model, building a prototype, and field-testing the prototype.

Acknowledgments

The authors would like to thank Donna Slovensky and Murat M. Tanik for their contributions to the Saudi proposal discussed herein as well as the construction of this article. This article refers to prior work done and presented at the SDPS 2017 World Conference, and the IEEE SoutheastCon 2021 conference.

Funding: None.

Footnote

Provenance and Peer Review: This article was commissioned by the Guest Editors (Donna J. Slovensky and Donna M. Malvey) for the series “mHealth: Innovations on the Periphery” published in mHealth. The article has undergone external peer review.

Data Sharing Statement: Available at https://mhealth.amegroups.com/article/view/10.21037/mhealth-21-32/dss

Peer Review File: Available at https://mhealth.amegroups.com/article/view/10.21037/mhealth-21-32/prf

Conflicts of Interest: All authors have completed the ICMJE uniform disclosure form (available at https://mhealth.amegroups.com/article/view/10.21037/mhealth-21-32/coif). The series “mHealth: Innovations on the Periphery” was commissioned by the editorial office without any funding or sponsorship. The authors have no other conflicts of interest to declare.

Ethical Statement: The authors are accountable for all aspects of the work in ensuring that questions related to the accuracy or integrity of any part of the work are appropriately investigated and resolved.

Open Access Statement: This is an Open Access article distributed in accordance with the Creative Commons Attribution-NonCommercial-NoDerivs 4.0 International License (CC BY-NC-ND 4.0), which permits the non-commercial replication and distribution of the article with the strict proviso that no changes or edits are made and the original work is properly cited (including links to both the formal publication through the relevant DOI and the license). See: https://creativecommons.org/licenses/by-nc-nd/4.0/.

References

1. Hevner A, March S, Park J, et al. Design science in information systems research. MIS Quarterly 2004;28:75-105. [Crossref]
2. Mylopoulos J, Borgida A, Jarke M, et al. Telos: Representing knowledge about information systems. ACM Trans Inf Syst 1990;8:325-62. [Crossref]
3. Weigers K. Software requirements. Redmond, WA: Microsoft Press, 1999.
4. Meyer B. On formalism in specifications. IEEE Software 1985;2:6-26. [Crossref]
5. Lipscomb M. On the nature of convergence engineering. Taichung, Taiwan: SDPS 2019 World Conference, 2019:29-36.
6. National Research Council. Convergence: Facilitating transdisciplinary integration of life sciences, physical sciences, engineering, and beyond. Washington, DC: The National Academies Press, 2014.
7. Lipscomb M, Alharthi A, Alhefdi M, et al. Information-based modeling of a case management health care system. IEEE Southeast Con 2021. doi: 10.1109/SoutheastCon45413.2021.9401857.10.1109/SoutheastCon45413.2021.9401857
8. Intagliata J. Improving the quality of community care for the chronically mentally disabled: The role of case management. Schizophrenia Bulletin 1982;8:655-674. [Crossref] [PubMed]
9. Felicia H, Jaap G. Value-based process model design. Business & Information Systems Engineering 2019;61:163-80. [Crossref]
10. Gordijn J, Akkerans H. Designing and evaluating e-business models. IEEE Intell Syst 2001;16:11-7. [Crossref]
11. Geerts G, McCarthy W. An accounting object infrastructure for knowledge-based enterprise models. IEEE Intell Syst 1999;14:89-94. [Crossref]
12. Osterwalder A, Pigneur Y. Business model generation: A handbook for visionaries, game changers, and challengers. Hoboken, NJ: Alexander Osterwalder & Yves Pigneur, 2010.
13. Alshehri H, Alharthi A, Tanik M. P3TECH, review of a process capturing technology. Taiwan: SDPS 2019 World Conference Taichung, 2019:87-90.
14. Gattaz C, Neto J, Catharino M, et al. A dynamic relationship framework for innovation: Implications for the Brazilian aerospace strategy operations. Journal of Integrated Design & Process Science 2006;10:17-31.
15. Weigand H, Johannesson P, Andersson B, et al. Value modeling and the transformation from value model to process model. In: Doumeingts G, Müller J, Morel G, et al. (eds). Enterprise interoperability: New challenges and approaches. Heidelberg: Springer, 2007.
16. Prince Faisal Bin Fahad Award for Sports Research. 2021. Available online: https://www.pfra.sa/en?httproute=True