Identification of Important Features in Mobile Health Applications for Surgical Site Infection Surveillance

Abstract

Background:

A landscape analysis of mobile health (mHealth) applications and published literature related to their use in surgical site infection (SSI) detection and surveillance was conducted by the Assessing Surgical Site Infection Surveillance Technologies (ASSIST) investigators.

Methods:

The literature review focused on post-discharge SSI detection or tracking by caregivers or patients using mHealth technology. This report is unique in its review across both commercial and research-based mHealth apps. Apps designed for long-term wound tracking and those focused on care coordination and scheduling were excluded. A structured evaluation framework was used to assess the operational, technical, and policy features of the apps.

Results:

Of the 10 apps evaluated, only two were in full clinical use. A variety of data were captured by the apps including wound photographs (eight apps), wound measurements (three apps), dressing assessments (two apps), physical activity metrics (three apps), medication adherence (three apps) as well as structured surveys, signs, and symptoms. Free-text responses were permitted by at least two apps. The extent of integration with the native electronic health record system was variable.

Conclusion:

The examination of rapidly evolving technologies is challenged by lack of standard evaluative methods, such as those more commonly used in clinical research. This review is unique in its application of a structured evaluation framework across both commercial and research-based mHealth apps.

We conducted a landscape analysis of mobile health (mHealth) applications and published literature related to their use in surgical site infection (SSI) detection and surveillance. This analysis was an integral part of a Health Technology Assessment (HTA) completed by the Assessing Surgical Site Infection Surveillance Technologies (ASSIST) investigators [1]. Technology in this area has advanced quickly, with readily available digital camera phones and photographs of surgical sites routinely available in clinical settings. Nonetheless, the characterization of these systems was lacking with regard to deployment settings, integration with electronic health record systems (EHRs), types of images, incorporation of additional patient-generated health data (PGHD), clinical or research usage, and communication methodology. Extent of usage, efficiency, types of information, and efficacy in the research and clinical context was examined in published literature and through a technical and market review.

Methods

Inclusion criteria

The following key phrases or words were used to perform a scoping search of the published literature centered around post-discharge SSI detection or tracking, by caregivers or patients using mHealth technology: mobile deives/PGHD, post-discharge/post-operative period and wounds/surgical site infections/images.

Exclusion criteria

During the literature search we excluded apps embedded in electronic health record systems (EHRs), workflows that were developed for provider use only, or apps that were designed for chronic wound tracking (e.g., enterocutaneous fistulas or venous stasis ulcers). We also excluded apps intended primarily for care coordination and scheduling.

Search strategy

Literature review

We designed search strategies specific to each database to enable the team to focus on the scholarly articles that were most likely to be relevant to the key questions and also on information from key stakeholders with relevant experience in the field. We developed a core search strategy for use in MEDLINE^®, accessed via PubMed^®, Web of Knowledge, Cochrane Review, and Embase. Relevant medical subject heading terms and text words of key articles of published research were identified either by colleagues with expertise in the field, or through online searches of Health Information and Management Systems Society (HIMSS). Articles were reviewed initially for data quality and level of evidence. This review was then presented to the team and evaluated for relevance, content, quality of data, and level of evidence and a subsequent detailed review was performed. This focused on functionality, workflow, deployment settings, analytic capabilities, data types, SSI identification, SSI evaluation, type of patient-generated health data (PGHD) symptoms, incision photography, and additional ascertained data. Additional data were collected on whether the app collected information on wound size, color, drainage, temperature, erythema, necrosis, separation, and presence of suture.

Technical and market review

Since the avaialability and use of apps for patient monitoring during the post-operative/post-discharge time period is undergoing rapid change, we did not rely solely on publication in peer-reviewed literature but expanded our search to include technical and market scans of apps for post-operative, remote patient monitoring. Apps were identify via informal interviews of ASSIST team and Scientific board colleagues and attendees at the Health Information and Management Systems Society (HIMSS) annual meeting, as well as through online searches for relevant mHealth products. These sources were searched for apps related to patient acquisition of post-operative incision images or other data used by patients or caregivers in the post-discharge setting. All apps were evaluated for usage, integration with EHRs and other apps, and the app platform. Briefs were prepared for each technology. As in the literature review, we excluded apps intended only for provider use, apps used primarily for chronic wound tracking, and apps intended primarily for care coordination.

Evaluation framework

Deployment and use

Product evaluation included an assessment of the deployment settings and operational use of the app. Pilot use was defined as the deployment of an application with established technical infrastructure that has already been through initial testing to a small number of users with a goal of defining best practices, evaluating feasibility, identifying training, workflow, or technical issues, and soliciting feedback prior to large-scale organizational implementation or a larger research study. Pilot deployments typically involved user feedback and both qualitative and quantitative data collection to guide the next stages of product development and deployment. During a pilot program, the rest of the organization used the legacy technology and workflows.

Research use was defined as a clinical trial designed and implemented to evaluate the impact of the technology on meaningful outcomes for patients and providers. Sample outcomes could include clinical outcomes, patient satisfaction, and resource utilization. The specific use case of post-operative surveillance for SSI was of primary interest; details about data types and definitions used to support a clinical diagnosis and/or surveillance case definition were obtained when available. Other outcomes tracked by the app were documented, including clinical or research-related metrics.

Full operational use of a product meant it was used in clinical care by a large number of eligible providers and patients with defined workflows and organizational support. For those products used in a clinical workflow, details about how the app was used in the workflow were obtained, if available.

Technical features

Technical features including the infrastructure, type of data collected, analytic capabilities, and interoperability with the native EHR were evaluated. We sought to understand tools and standards used during the key steps of data flow: capture, transfer, analysis, and review. Available platforms for running the app (iOs, Android, desktop options) were assessed and when the application development approach was known, apps were characterized as native apps (iOs, Android, Windows), hybrid/cross-platform apps, or Web apps. Device-related implementation considerations included policies for device use (bring your own device [BYOD] vs. health-system supplied).

The type of data collected was cataloged. Data types included structured data (standard survey instruments, specific symptoms, or numerical data such as wound size [width and depth], body temperature, weight, pain scale rating), narrative text, contextual data, and images. Symptoms and signs such as a change in skin color (erythema, necrosis), wound drainage, the presence of sutures, wound status (open, closed) could be captured as structured results or narrative text response. Contextual data included additional PGHD or EHR data not specific to SSI but useful for the clinician to gain a better understanding of the patient. Examples include blood glucose results, heart rate, meal times, and use of insulin. If concerns were raised about the volume of data, and the workflow (reviewing results) or technical (storage and analysis) challenges in managing it, these were captured. When images were used, implementation and workflow implications and any technical details such as minimum standards for image quality and analytic capabilities for image analysis were documented.

Key enablers of data transfer and system to system interoperability, analytic capabilities, and tools to facilitate data review were assessed. In assessing data transmission and interoperability, the use of healthcare terminology, data exchange standards, frameworks and protocols such as LOINC, HL7 v2/3 CCDA, FHIR, OAuth2, was evaluated. The specific systems with which an app interacted were cataloged. These included EHRs, research databases (e.g., REDCap), other health information systems, and commercial platforms (e.g., HealthVault, HealthKit, ResearchKit). The workflow functionality and technical features of the user interface for the patient and clinician were evaluated. Capabilities such as directed communications, alerting, and clinical decision support were cataloged.

Analytic capabilities including simple business rules, reporting, data visualization and more advanced analytics such as machine learning and image analysis, were investigated. Business rules could be used to screen for out of range or concerning values. Data delivery included feedback of self-reported data to the patient and the delivery of data to the clinician and health system.

Specific user considerations for the various user types (e.g., patient, provider, healthcare organization) were assessed. Workflow implications and the technical features that supported them were evaluated. The latency of inbound PGHD, alerting to providers and in-context EHRs integration were assessed. Provider types (nurse, medical assistant (MA), physician, other) were cataloged. When possible, the effect on the patient–provider relationship was evaluated. Training resources and patient education were assessed. The perceived utility of PGHD was evaluated.

EHRs integration was identified as a high-priority feature to evaluate. Specifically, EHRs integration (or the lack of integration) and the effect on clinical and research workflows and ultimately user acceptance was evaluated. The need for a separate staging area (database) versus direct integration into the native EHR architecture was considered.

The possible gradations of EHRs integration were identified (Table 1). Techniques and tools addressing privacy, security, and patient safety concerns were captured if available. Methods of user (both patient and provider) authentication, which would ensure that a clinician can trust that the data received is from the patient of interest, were documented when available. We attempted to evaluate mitigation strategies to address vulnerability to security breaches at the device/data collection level and during movement of the data to analytic platforms or the health system clinical information system. Where available, we captured the Food and Drug Administration (FDA) level of risk for the application [2].

Table 1.

Gradations of Electronic Health Record System Integration for mHealth Apps

• No EHRs integration or single sign on. Completely disparate systems.

• A link within the native EHRs launches the external mHealth app and enables single sign-on without any feed of patient information to the app.

• Patient look-up is facilitated by an ADT and scheduling/procedure feed to the app. Basic patient information is auto-populated in the app and PGHD could be viewed in the external PGHD app or Web page, outside the EHRs, whereas EHRs data (labs, MAR) would remain in the EHRs.

• In addition to the above, some subset of EHRs data is viewed in the external PGHD app relevant to the use case and the specific user. A laboratory, medication, or clinical results feed would be required.

• PGHD data has been integrated back into the EHRs likely after some initial analysis and filtering of the data in an external staging area, with a review process and policies in place regarding integration into the EHRs.

• App has been validated by one or more enterprise EHRs vendor.

mHealth = mobile health; EHR = electronic health records; PGHD = patient-generated health data; ADT = admission/discharge/transfer; MAR = medication administration record.

Results

Ten apps were identified for our analysis (Table 2). Most (seven) of the apps were in use in a pilot project or had been deployed only in a research context. We confirmed that only two apps were in full clinical use. Deployment status of the remaining app was unclear (Table 3).

Table 2.

mHealth Apps Evaluated

App name	Company or institution of origin	Year of first deployment
How2Trak	Health Outcomes Worldwide	2013 (iOs V1.0)
How2Trak	Toronto, Calgary, and Nova Scotia, Canada	(Web app predates)
imito	Zurich, Switzerland	2016
mHeals	Colorectal surgery department Weill Cornell Medical School, New York, NY Vimcare Platform	2016
mPOWEr	Department of Surgery, University of Washington, Seattle, WA	2015
QoC Health	QoC Health Toronto, Ontario, Canada	2015
SeamlessMD	SeamlessMD Toronto, Ontario, Canada	2014^*
Theia	Stanford University, Palo Alto, CA	2016
WoundCheck	Wisconsin Institute of Surgical Outcomes Research, Department of Surgery, University of Wisconsin, Madison, WI	2016
WoundSmart	Pocket Professions, Inc.	2012 (iOs V1.0)
Vanderbilt University (app deployed through REDCap)	Department of Surgery, Vanderbilt University, Nashville, TN	2015^*

Approximate.

mHealth = mobile health.

Table 3.

Deployment setting of applications evaluated

	Yes	No	Uncertain
Full clinical deployment	2	7	1
Pilot usage or research use	7	2	1

Total number of apps evaluated = 10.

We confirmed that structured data was captured by all of the apps in the form of: wound measurement (three apps), medication adherence (three apps), physical activity metrics (three apps), dietary intake (two apps), bowel habits, presence of fever, weight, pain scale rating, dressing change assessments (two apps), symptoms, and proprietary surveys. Unstructured data in the form of free text responses were permitted by at least two apps and incision photos were captured by at least eight apps. Activity monitoring was supported by device integration with activity monitors in two apps.

Reliance upon image upload of surgical wounds was a common feature of almost all (eight) apps, with seven apps related specifically to SSI monitoring and surveillance. Two apps had the capability to ascertain additional information related to other outcomes such as opioid use, enhanced recovery, quality of life and other PGHD. One app included video upload capability. U.S. Centers for Disease Control and Prevention (CDC) guidelines for SSI definitions were used in two apps (Table 4).

Table 4.

Outcomes Measured and Data Types Captured by the 10 mHealth Apps Evaluated

	Yes	No	Uncertain
SSI specific outcome measure	7	3	0
Wound measurements	3	1	6
Dressing change assessments	2	0	8
Medication adherence	3	0	7
Physical activity	3	0	7
Symptoms	5	0	5
Surveys	3	0	7
Photos	8	0	2
Dietary intake	2	0	8
Free text permitted	2	1	7
Other PGHD	9	0	1

SSI = surgical site infection; PGHD = patient-generated health data.

Data from these apps was integrated with the native EHR in four apps and remained outside of the EHR in three apps; workflow or EHR integration were unclear in three apps. The exact nature (unidirectional, bidirectional) and the type of data integrated with an EHR was unclear for most of the apps. Validation and testing in multiple EHR environments with approval for integration to multiple vendors was seen in only one app. The use of HL7 FHIR resources was in the marketing materials of at least one product. Android, iOS, or Web-based platforms were the most common; at least one app utilized REDCap (Table 5). Additional user features were available in most apps, in the form of: trends and summaries (seven apps), communication (seven apps), automated alerts (five apps), decision support (four apps), and patient education/resources (three apps) (Table 6).

Table 5.

Platforms and Integration of the Ten mHealth Apps Evaluated

	Yes	No	Uncertain
Data integration with health system EHRs	4	3	3
iOs application	7	0	3
Android application	3	0	7
Web based	3	0	7
ResearchKit or HealthKit integration	2	0	8
Integration with fitness tracker device	2	1	7

EHR, electronic health record.

Table 6.

User Focused Features of the Ten mHealth Apps Evaluated

	Yes	No	Uncertain
Trends and summary reporting	7	0	3
Communication (care team and/or patient)	7	0	3
Automated alerts	5	2	3
Decision support	4	0	6
Patient education/resources	3	0	7

Discussion

In this survey of mHealth apps for SSI surveillance and clinical management, we used a structured evaluation framework to understand the current state of mHealth technologies for a specific use case. We focused our detailed review on mHealth enablers of SSI surveillance, diagnosis, and clinical management and we were able to collect information about ten apps. Apps focused on chronic wounds, dermatologic conditions, and more general applications for patient engagement and care coordination were excluded as were the use of patient portals in an existing health system's EHRs vendor. These apps may share some features of the apps presented here.

Features of the apps may vary based on the intent, or initial driver, of the app. Those developed for a specific type of surgery, clinical condition, or patient population may have a specific feature set geared to the intended use. The frequency of data capture and acceptable latency of data review by the care team and the type of data collected will all be impacted by the intent of the app and the population of patients served. Apps for patients after gastrointestinal or gynecologic surgery may focus more heavily on daily dietary intake and bowel movements than those developed for vascular or orthopedic surgery. Apps intended for use by elderly patients may have user design requirements that lead to a particular set of data elements. Some app features may provide ancillary benefits beyond the specific clinical and surveillance use case of SSI. Patient engagement may bring additional clinical and psychological benefits that extend beyond the management after a surgery. Engagement may increase patient retention for a health system [3].

Integration with the EHRs has been previously highlighted as an important feature to streamline workflows, improve adoption, and reduce errors [4]. For a variety of technical, policy, and economic reasons, current development trends have produced products that often function as stand-alone systems and lack EHRs integration. Integration of third-party solutions in a setting where a large vendor's EHRs is in use requires onsite technical talent, dedicated resources, and collaboration with the EHRs vendor. Apps initially deployed in a research context may de-emphasize EHRs integration and focus on proof of concept while commercial applications may have specific technical and workflow features that enable deployment in varied settings and prioritize EHR integration. We were able to identify one application that had undergone formal testing, validation, and approval by three major EHRs vendors and was available as a vendor partner. This is the extent of our knowledge about the technical, security, and workflow implications. Some applications were geared toward clinical documentation for wounds and allowed for documentation of laboratory results, medications, and past medical history. It was unclear, however, for most of the apps if EHR integration allowed harmonization with the primary EHRs, was certified to serve as an EHRs, or if the apps served as locations for redundant/shadow documentation.

One limitation to our review process was variability in the level of access to these apps. Our access to commercialized apps brought to market differed from our access to apps created for research, implemented in a single health system, and described in the published literature. We did not seek to compare apps but rather describe the current state of functionality. Our survey was conducted over a specific period of time and is not intended to address issues such as degrees of success, sustainability, reimbursement considerations, or marketability. Because this field is evolving quickly with ongoing refinement of existing apps and the development of new apps, the list of apps and their features presented here represents a “biopsy” of sorts of the literature and marketplace for such apps. It is therefore possible that products not currently included in the app review will come to light as the field continues to advance.

As new biometric monitoring technologies become available, applications and clinical workflows will likely evolve to collect, manage and analyze novel data types. So-called smart bandages may supply measurements of pH, oxygenation, temperature, and galvanic skin response. Voice analysis may have a role for patients who have undergone general anesthesia or head and neck surgery. Video analysis may provide additional objective measures of range of motion. The future development of personalized data tracking will only expand the volume, velocity, and variety of data requiring analysis if it is to be useful for PGHD-based remote patient care.

Conclusion

The examination of rapidly evolving technologies is challenged by lack of standard evaluative methods, such as those more commonly used in clinical research. This report is unique in its review across both commercial and research-based mHealth apps. The barrier to full access and the variability of adoption in different settings all contribute to an incomplete, albeit multi-dimensional, picture of mHealth use for SSI detection and monitoring. As the field advances, reviews such as the one described here will provide important milestones for how the technology for remote post-operative monitoring evolves over time.

Footnotes

Acknowledgments

This work was supported by CDC award #200-2016-91803 through the Safety and Healthcare Epidemiology Prevention Research Development (SHEPheRD) Program, which is managed by the Division of Healthcare Quality Promotion. The content is solely the responsibility of the authors and does not represent the official views of the CDC.

Author Disclosure Statement

Dr. Chernetsky Tejedor, Dr. Sharma, Dr. Lavallee and Dr. Lober report no conflicts of interest related to the subject matter.

Dr. Evans discloses participation in an advisory board (Tetraphase).

References

Evans

, Lober

, Lee

, et al. Assessing Surgical Site Infection Surveillance Technologies (ASSIST): Health technology assessment report. May 2019. www.cirg.washington.edu/assistHTAreport (Last accessed June 28, 2019).

Food and Drug Administration. Guidance Document, Mobile Medical Applications. www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM263366.pdf (Last accessed April 2, 2019).

Soroceanu

, Ching

, Abu

, McGuire

. Relationship between preoperative expectations, satisfaction, and functional outcomes in patient undergoing lumbar and cervical spine surgery: A multicenter study. Spine, 2012; 37:E103–108

Nguyen

, Bellucci

, Nguyen

. Electronic health records implementation: An evaluation of information system impact and contingency factors. Int J Med Inform, 2014; 83:779–796.