The concept of adverse childhood experiences (ACEs) has been recognized for quite some time but was first formally studied in the CDC-Kaiser landmark study [1], which uncovered the strong connection between ACEs and the development of risk factors for different negative health outcomes that threaten the well-being of populations throughout their life course. Social determinants of health (SDoH) are measurable indicators of social conditions in which a patient is embedded. Individuals who experience a more negative burden of these factors within their neighborhood are at higher risk of negative health outcomes [2-4]. There is an entire body of research focused on studying the links between ACEs and SDoH and health outcomes, but few intelligent tools are available to assist in the real-time screening of patients and to assess the connection between ACEs and SDoH, which could help to guide patients and families to available resources (eg, health care providers, government, and nongovernment agencies). Other recent works have focused on developing question-answering (QA) systems for training nursing practitioners on how to answer patient inquiries [5].

Recommendation systems and digital assistants often require machine learning (ML), artificial intelligence (AI), and natural language processing capabilities to effectively connect and harvest the vast amounts of generated data. They also need to store, retrieve, and learn from past interactions and experiences with users. Traditionally, recommendation systems have relied on classic ML techniques that often cannot provide a full scientific understanding of the inner workings of the underlying models. For AI to mimic human intelligence, it needs to incorporate one of the most important classes of information people use to make predictions and decisions: context. Although a standard AI algorithm can learn useful rules from a training set, it also tends to learn other unnecessary, nongeneralizable rules, which may lead to a lack of consistency, transparency, and generalizability. Explainable AI is an emerging approach for promoting credibility, accountability, and trust in mission-critical areas such as medicine by combining ML techniques with explanatory techniques that explicitly show why a recommendation is made. One way to achieve this is by considering formal ontologies as an integral part of the learning process, providing the necessary contextual knowledge about a phenomenon. AI and ML become more trustworthy when underpinned by contextual information provided by ontological platforms. Ontologies can be represented through a graph structure. When computations are performed over graph-structured data, they can make generalizations related to structure rather than data since they support relational reasoning and combinatorial generalization [6]. Moreover, when AI apps are based on contextually aware and dynamic backends, they become easier to train with minimal maintenance. A knowledge graph [7] can serve as a dynamic backend that stores data in a certain domain as entities and relationships using a graph model, which abides by an ontology. Several studies have incorporated graph technologies into ML models applied to biomedical informatics problems [8-11].

We here propose the Semantic Platform for Adverse Childhood Experiences Surveillance (SPACES), an intelligent recommendation system that employs ML techniques to help in screening patients and allocating or discovering relevant resources. The novelty in the approach lies in its ability to use the contextual knowledge collected about the user, and infer new knowledge to support subsequent QA and resource allocations during intake assessment sessions in (near) real time. Moreover, our proposed system intends to build rapport with patients by generating personalized questions during interviews while minimizing the amount of information that needs to be collected directly from the patient.

In our previous work [12-14], we developed the Adverse Childhood Experiences Ontology (ACESO) that captures knowledge on ACEs, SDoH, health outcomes, and interventions. Both expressive and light versions of the ontology can be freely downloaded via BioPortal [15]. The ontology defines concept and property hierarchies, and encodes causal epidemiological knowledge as axioms. We also developed a repository termed Urban Population Health Observatory (UPHO), which provides metrics based on several socioeconomic and environmental data at the neighborhood level that can be linked to health outcomes. Figure 1 demonstrates the multiple layers, from data to the app, that are required for building a knowledge-based explainable and interpretable model.

We aimed to develop a knowledge-driven evidence-based recommendation system and a digital assistant to facilitate mental health surveillance. We first present our methodology along with the general architecture of the proposed recommendation system. We then demonstrate the feasibility and usability of our approach through multiple use case scenarios and offer recommendations for further development.

The idea behind the SPACES platform is to monitor the causes of ACEs and SDoH, and their impacts on health. This platform is based on the ACESO to provide the contextual knowledge needed to facilitate intelligent exploratory and explanatory analysis. Through this framework, decision makers can (1) identify risk factors, (2) integrate and validate ACEs and SDoH exposure at individual and population levels, (3) and detect high-risk groups. The idea for implementing the recommendation system for surveillance of ACEs was motivated by a study conducted under the Family Resilience Initiative (FRI) at Le Bonheur Children’s Hospital (Memphis, Tennessee) that serves families with children during regular child visits in the clinic. Our use case scenarios to demonstrate the main components and features that constitute the SPACES framework were inspired by client examples and typical issues (Textbox 1), and the follow-up activities (Textbox 2) reported in the FRI reports.

The main components of the SPACES framework are illustrated in Figure 2. A detailed explanation of each component is provided below.

To implement the conversation agent, we used the Google DialogFlow framework [17] and defined the following constructs.

The SDoH surveillance service is triggered whenever an SDoH-related entity type is introduced in the user’s conversation with the QA agent. To achieve this, the surveillance uses the ACESO to infer whether a detected entity type (eg, being_exposed_to_lead-based_paint) is a subtype of the more generic SDoH type as well as the causal knowledge (eg, lead-based_paint causes asthma). This service also invokes the UPHO service endpoint to obtain metrics (eg, blight prevalence, walkability score) based on the current user’s neighborhood.

This service keeps track of all possible questions that can be asked during the ACEs assessment process [18]. It is triggered each time an ACE-related entity type is introduced in the user’s conversation with the agent. It gets invoked by the recommendation service to retrieve only the questions relating to the ACEs concepts provided by the agent. The QA agent keeps track of how many ACEs questions were reported as positive, and provides those to the ACEs surveillance service, which uses the knowledge stored in the ACESO about ACEs score classification and rules for calculating them. It then sends the resulting score to the recommendation service, which seeks insights from external knowledge (eg, research publications [18]) to formulate a diagnosis based on the question: “given an ACEs score of X and symptoms S1,…Sn, what are the likely negative outcomes to screen for?”

To make real-time recommendations, this service instantly captures new resource interests, ACEs, and SDoH-associated risk factors detected in the user’s current conversation and uses them to incrementally refine a personalized knowledge graph. At each stage in the conversation, the QA agent passes detected entity types and contextual parameter values to the recommendation service. Entity types help the service determine entry points on the knowledge graph, and contextual parameters help refine the queries further to obtain a more personalized version of the graph (Figure 6). Once the personalized graph is generated, the service supplies the QA agent with two types of recommendations: the next question to ask and a resource to suggest.

We used Neo4j graph technology [19] for generating and enriching the graph. Before populating the graph with real-time data, we loaded ACEs, SDoH, and health outcome concepts from the ontology into a graph and persist them. We used the NeoSemantics framework [19] to import the Resource Description Framework (RDF)-based data model schemas of the ontology as a metagraph into a Neo4j graph. The resulting property graph inherits the modeling limitations of the RDF, including the lack of support for attributes on relationships. Therefore, we enriched and fixed the raw graph after loading it in Neo4j. To populate the graph, the service starts with a dummy node that represents the current user (Figure 6) and then incrementally adds the following node types.

Domain concept nodes correspond to entity types detected by the QA agent (eg, race, age, zip code, symptom). Entity type nodes could be either (a) risk factors such as “housing_circumstance,” “food_issue,” and “household_issue,” or (b) common sense knowledge such as school age and domain concepts in the given context (eg, age is a school age and lead-based paint is a toxicant).

Value nodes are populated with real-time values either (a) from contextual parameters obtained from the QA agent (eg, “38103,” “night terror”), (b) calculated based on the ontological axioms (eg, ACEs score of 4), or (c) retrieved from the UPHO (eg, 80% blight prevalence).

Recommendation nodes are question nodes and resource nodes. Question nodes represent follow-up questions suggested for the QA agent. The answers to these questions coming from the QA agent can further refine the graph. The suggested question nodes are solicited from a pool of questions kept by the ACEs surveillance service. Resource nodes (eg, referrals, housing options, school information, doctors, clinics) are resources suggested for the QA agent to provide to the user. These resources are suggested based on the user’s demographic profile (eg, the food banks within a small radius from their zip code). Resource nodes are pulled from a pool of existing resources or by invoking external backend APIs. In addition to the nodes pulled from contextual parameters, the graph shows nodes that are added based on knowledge inferred through axioms (dashed arrows in Figure 6) and concept hierarchies (solid arrows in Figure 6).

The analytics component utilizes the conversation history recorded by the DialogFlow logging API, including (1) timestamps, number of interactions (within a conversation) for all user sessions, and percentage of mismatches if any; (2) a visual summary of the conversation flow with percentages for each detected intent as well as the conversational paths that users have taken when interacting with an agent; (3) popularity per intent by showing the number of sessions in which the intent was matched as well as the number of times the intent was used (total from all sessions); (4) percentage of sessions in which a user exited the conversation in the specified intent compared to the total number of sessions in which this same intent was matched; and (5) average response time to user requests.

The aggregated results from all user conversations provide policymakers with insights about population health. Analyzing such data can help in designing interventions and preventive measures based on the most prevalent risk factors in certain regions. It can also assist the framework users by providing recommendations on how to direct future conversations. For example, it can look into smaller communities within geographic areas or perform collaborative filtering based on similarities in user behavior, or detect similar communities on the conversation graph. For example, if a user that belongs to a certain age or ethnicity group shows a certain pattern/route during the case assessment conversation procedure, then the QA agent may suggest the same route for the next user with similar criteria.

The significance of the proposed approach lies in its ability to provide recommendations to the QA agent with the least effort from both the user and the health care practitioner. It aims to maximize knowledge about the patient without having to delve into all of the questions that are often asked in ACEs and SDoH intake assessments. It also provides the ability to explain why a certain question or resource was suggested.

Preliminary rapid prototyping of the recommender system allowed for early verification of the functionalities through the multiple case scenarios described in this paper. We anticipate rapid feedback from end users on various features during an iterative development process, and finally establish a comprehensive usability and user experience test. We have evaluated the SPACES semantic framework and its underlying ontology automatically using description logic reasoners such as Fact++ [20] to ensure the consistency and satisfiability of the ontology and semantic model. We also used inputs from our collaborating domain experts to assess the soundness and completeness of the ontology by examining how well it has been aligned with the required criteria defined in our domain and scope. Furthermore, we evaluated the usability of ACESO based on its functionality and capability to respond and answer the target queries. Finally, further work is underway to develop and conduct a series of formal evaluation practices for a comprehensive assessment of the accuracy, usability, coverage, confidence, trustability, as well as adaptivity and scalability of the recommender system [21]. Moreover, we will assess the utility and impact of the system on the surveillance of ACEs to generate a timely response and intervention, ultimately informing public health planning and policymaking.

The proposed approach might face some limitations. One limitation is in providing an overall guiding architecture to support transfer ability between health domains. Several of the QA platforms (eg, Google DialogFlow and IBM Watson) read rules on how to answer questions from backend sources (eg, HTML FAQ files, Plaintext files). These sources can help load the questions into the QA agent. They also require training the agent with concepts that may appear in the QA text. The ontology in our case helps load the concepts automatically, which is separate from the QA platform implementation itself. Each domain will have its own concepts that can be encoded in a separate ontology, and we can either develop new ontologies or reuse existing ones.

Another limitation is that the recommendation system has access to only population-wide data, where the population’s characteristics might be different than the characteristics of the individuals living in that population or neighborhood. However, for specific users and specific use cases, it needs access to individual data. For instance, a pediatrician trying to decide whether a child is suffering from ACEs will need to have access to the child’s health history and other relevant information but should not be allowed to access information about the parent’s finances or criminal history (outside of what is publicly available). Moreover, a local judge will want to have access to the criminal history of the family members if they want to decide whether the child should be removed from their parents to ensure their safety, but they should not be able to access any of their medical records. Thinking about how to control mediated access to sensitive information will be a key part of the development of the recommendation system. We are currently working on integrating the recommendation system into a personalized health library [22].

The adoption of recommendation systems may be hindered by a poor user-interface design or poor integration into clinical workflows. Human factors engineering can improve efficiency, reduce errors, increase technology adoption, and reduce the early abandonment of systems. This paper lacks an objective evaluation of how health care practitioners will benefit from the explanations or how the quality of those explanations would be assessed. We plan to use an iterative user-centered design and formative evaluation by conducting predevelopment focus groups, which might reveal issues related to manual data entry from target users and the time spent reviewing generated knowledge from providers. Ongoing research on this project will also involve implementing an optimization algorithm of the recommendations. We will also consider technically evaluating the system for precision and performance.

All updates in the underlying ontologies and semantic structure will be managed through our previously implemented framework [23, 24]. As for the target audience, the system is intended for a variety of users depending on the domain, including social workers, health care providers (eg, nurses, physicians), and caregivers (child-parent). The digital assistant or QA agent is the part intended and available for end users (eg, caregivers). It is a simulation of the conversations that occur between health care providers or social workers and caregivers as they discuss their case. The text exchanged through the chat is used in the backend for both enhancing the QA agent and refining the personal knowledge graph of the current user. The visual graphs and underlying reasoning are intended for AI explainability, which is critical for health care providers to make decisions. In particular, the analytics part is intended for monitoring and research purposes, and therefore is more appropriate for health professionals and policymakers.

Finally, we discuss the implications for policy and practice. We believe that early intervention is the best way to prevent the progression of negative health outcomes to their end stage, and that well-designed early detection systems can aid clinicians by generating knowledge that can be aligned with clinical workflows. Thus, systems tailored toward such interventions by utilizing knowledge about self-reported or detected SDoH and ACEs would be most useful. Through the framework, decision makers can (1) identify risk factors, (2) integrate and validate ACEs and SDoH exposure at individual and population levels, and (3) detect high-risk groups. The analytics component could be most useful for policymakers for this purpose and is intended for monitoring and research purposes.

In this study, we leveraged explainable AI to present a proof-of-concept prototype for a knowledge-driven evidence-based recommendation system to improve the surveillance of ACEs. The proposed approach will enhance the health care practitioner’s ability to provide explanations for the decisions that they make. Further development and official evaluation are underway to include a privacy layer through a personal health library and to conduct a clinical trial for formally assessing both the usability and usefulness of the implementation.