Providing personalized healthcare information and treatment recommendations

Abstract

Various embodiments described herein provide mechanisms for implementing an integrated platform that provides personalized healthcare information and treatment recommendations to patients and caregivers.SOLUTION: The retrieved patient data is used as input to a personalization algorithm that generates specific personalized treatment recommendations and options for the patient. The treatment recommendations and options are displayed to the patient in normal language to facilitate proper understanding. The translation of the treatment options into normal language can be done automatically.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority from U.S. Provisional Application No. 62 / 778,018, filed December 11, 2018, entitled "Integrated Platform for Providing Personalized Health Care Information and Verified Social Network for Patients" (Attorney Docket No. OUT001-PROV), the entire contents of which are incorporated herein by reference.

[0002] This document relates to mechanisms that enable communication between patients and healthcare providers. [Background technology]

[0003] Patients diagnosed with a particular disease often have multiple alternative treatment options from which to choose. However, the number of options offered to patients, and the information about these options, is inconsistent and often depends on the physician and healthcare provider, their geographic location, and / or other factors.

[0004] Various resources exist to provide information about available treatment options for a given disease. However, such existing resources generally do not provide tools that patients and their caregivers can use to automatically obtain treatment options specific to a patient's diagnosis and clinical and treatment history. Rather, the information provided by such resources is typically generally applicable to cases of a given disease and various clinical / treatment histories.

[0005] Additionally, patients and their caregivers often lack the detailed diagnostic information and treatment histories available to doctors or hospitals. Thus, despite a wealth of information about treatments and treatment options, existing resources available to patients and their caregivers often fail to provide the tools to adequately inform patients about their treatment options, much less provide actual options that patients can discuss with their doctors. Such existing resources also often lack the ability to effectively and efficiently receive requests for patient and / or summary data, and further lack the ability to present result information in a manner that facilitates appropriate understanding by patients.

[0006] While some hospital systems have their own patient portals that can be used to display health information to patients, such systems do not provide a mechanism for retrieving and merging health records from different systems and institutions and displaying them to patients in an integrated manner. Moreover, such systems generally do not provide a way to collect data directly from patients and then display it in a summarized format for patients and / or providers. Summary of the Invention

[0007] This document relates to techniques for implementing an integrated platform that provides personalized healthcare information and treatment recommendations to patients and caregivers. The techniques described herein can be implemented alone or in any suitable combination with each other.

[0008] In various embodiments, the automated techniques described herein provide personalized treatment information to patients and their caregivers without the patient having to search for treatment or consult a doctor. According to various embodiments, patient data can be retrieved directly from healthcare systems and automatically analyzed.

[0009] Examples of patient data include, but are not limited to, electronic medical records, genomic information, billing records, geolocation, diagnostic tests, medical benefits, insurance plan information, etc. Such data may be collected from any suitable source, including, for example, active and / or passive trackers such as FitBit devices, smart watches, heart rate monitors, and / or the like. Examples of healthcare systems include, but are not limited to, hospital systems, clinics, payer systems, diagnostic companies, clinical laboratories, etc.

[0010] The retrieved patient data can be used as input to a personalization algorithm that generates specific, personalized treatment recommendations and options for the patient. The treatment recommendations and options are displayed to the patient in common language to facilitate proper understanding. In at least one embodiment, translation of the treatment options into common language can be performed automatically. Treatment recommendations and options include, but are not limited to, approved medications, interventions such as surgery or radiation therapy, and clinical trials.

[0011] In at least one embodiment, the system is implemented as a software platform and mobile application that helps patients and caregivers navigate their treatment options and connect them with available treatment opportunities, including standard treatment options and clinical trials. By providing a personalized, peer-validated, evidence-based experience, the tools described herein not only improve the quality and effectiveness of care, but also enable the delivery of care beyond the clinical setting into the home environment. This improves patient outcomes and accelerates innovation through more comprehensive patient follow-up.

[0012] In at least one embodiment, the patient-centered experience provided by the described system is updated based on feedback from patients, caregivers, and providers, thus ensuring that the system evolves as patient and caregiver needs evolve.

[0013] In at least one embodiment, the system provides functionality for real-time data capture and symptom reporting.

[0014] Specific examples, applications, and variations are described in more detail below. [Brief explanation of the drawings]

[0015] The accompanying drawings, together with the description, illustrate several embodiments. Those skilled in the art will recognize that the specific embodiments shown in the drawings are merely exemplary and are not intended to be limiting in scope. [Figure 1] FIG. 1 is a block diagram illustrating the architecture of a system for providing personalized treatment recommendations to patients, according to one embodiment. [Figure 2] FIG. 1 is a flow diagram illustrating a method for personalizing therapy, according to one embodiment. [Figure 3A] 10A-10C illustrate various example screens of a user interface for a medical record workflow, according to one embodiment. [Figure 3B] 10A-10C illustrate various example screens of a user interface for a medical record workflow, according to one embodiment. [Figure 3C] 10A-10C illustrate various example screens of a user interface for a medical record workflow, according to one embodiment. [Figure 3D] 10A-10C illustrate various example screens of a user interface for a medical record workflow, according to one embodiment. [Figure 3E] 10A-10C illustrate various example screens of a user interface for a medical record workflow, according to one embodiment. [Figure 3F] 10A-10C illustrate various example screens of a user interface for a medical record workflow, according to one embodiment. [Figure 3G] 10A-10C illustrate various example screens of a user interface for a medical record workflow, according to one embodiment. [Figure 3H]10A-10C illustrate various example screens of a user interface for a medical record workflow, according to one embodiment. [Figure 3I] 10A-10C illustrate various example screens of a user interface for a medical record workflow, according to one embodiment. [Figure 4A] 10A-10C illustrate various example diagnostic update screens, according to one embodiment. [Figure 4B] 10A-10C illustrate various example diagnostic update screens, according to one embodiment. [Figure 5A] 10A-10C illustrate various example screens of a treatment pathway user interface, according to one embodiment. [Figure 5B] 10A-10C illustrate various example screens of a treatment pathway user interface, according to one embodiment. [Figure 5C] 10A-10C illustrate various example screens of a treatment pathway user interface, according to one embodiment. [Figure 5D] 10A-10C illustrate various example screens of a treatment pathway user interface, according to one embodiment. [Figure 5E] 10A-10C illustrate various example screens of a treatment pathway user interface, according to one embodiment. [Figure 5F] 10A-10C illustrate various example screens of a treatment pathway user interface, according to one embodiment. [Figure 5G] 10 illustrates a portion of a treatment personalization algorithm that can be used to pre-populate a treatment option screen, according to one embodiment. [Figure 6A] 10A-10C illustrate various example screens of a user interface for a clinical trial workflow including GPS functionality, according to one embodiment. [Figure 6B] 10A-10C illustrate various example screens of a user interface for a clinical trial workflow including GPS functionality, according to one embodiment. [Figure 6C] 10A-10C illustrate various example screens of a user interface for a clinical trial workflow including GPS functionality, according to one embodiment. [Figure 7A] 10 shows an example screen of a user interface for applying an outcome filter to find a treatment, according to one embodiment. [Figure 7B] 10 shows an example screen of a user interface for presenting a visualization of patent outcomes for a particular treatment and receiving a request to informally match with another patient for anonymous communication, according to one embodiment. [Figure 7C] 10 shows an example screen of a user interface for presenting medication-level outcome data, according to one embodiment. [Figure 8] 10A-10C illustrate example screens of a user interface for presenting treatment options categorized by cost and presenting treatment details including personalized patient costs by benefit, according to one embodiment. [Figure 9A] 1 illustrates an example of a personalized treatment algorithm for metastatic breast cancer, according to one embodiment. [Figure 9B] 1 illustrates an example of a personalized treatment algorithm for metastatic breast cancer, according to one embodiment. [Figure 10A-1] 1 illustrates an example algorithm for personalized screening, according to one embodiment. [Figure 10A-2] 1 illustrates an example algorithm for personalized screening, according to one embodiment. [Figure 10A-3] 1 illustrates an example algorithm for personalized screening, according to one embodiment. [Figure 10A-4] 1 illustrates an example algorithm for personalized screening, according to one embodiment. [Figure 10A-5] 1 illustrates an example algorithm for personalized screening, according to one embodiment. [Figure 10B] 1 illustrates an example algorithm for personalized screening, according to one embodiment. [Figure 11] FIG. 1 is a block diagram illustrating an overall schematic architecture of a system for providing personalized treatment recommendations to patients, according to one embodiment. [Figure 12] 1 illustrates an example application of a personalization engine to generate appropriate treatment options for a patient, according to one embodiment. [Figure 13]1 illustrates an example of a patient-reported outcome (PRO) service, according to one embodiment. [Figure 14A] FIG. 1 is a block diagram illustrating an example of app integration into existing electronic health record (EHR) systems and workflows, according to one embodiment. [Figure 14B] FIG. 1 is a block diagram illustrating relationships between Secure Care Plans and other entities, according to one embodiment. [Figure 15] FIG. 1 is a flow diagram illustrating a method for integrating the described system into existing electronic health record (EHR) systems and workflows, according to one embodiment. [Figure 16A] 10A-10C show various example screens of a user interface for patient self-reporting of symptom and quality of life data, according to one embodiment. [Figure 16B] 10A-10C show various example screens of a user interface for patient self-reporting of symptom and quality of life data, according to one embodiment. [Figure 16C] 10A-10C show various example screens of a user interface for patient self-reporting of symptom and quality of life data, according to one embodiment. [Figure 17A] 10A-10C illustrate various example screens of a user interface for completing a patient record outcome questionnaire, according to one embodiment. [Figure 17B] 10A-10C illustrate various example screens of a user interface for completing a patient record outcome questionnaire, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0016] The systems and methods described herein may be applied in many situations in which personalized information and / or recommendations are exchanged between and among patients and various healthcare providers. For purposes of illustration, the description herein is set forth in terms of methods and systems in which such communication occurs via the Internet and / or wireless communication devices, such as smartphones. Those skilled in the art will recognize that the systems and methods described herein may be implemented in a wide variety of other situations and using other hardware and / or software arrangements. Accordingly, the particular approaches described herein are provided for illustrative purposes only.

[0017] System Architecture According to various embodiments, the systems and methods described herein can be implemented in any electronic device or set of interconnected electronic devices, each equipped to receive, store, and present information. Each electronic device can be, for example, a computing device, a desktop computer, a laptop computer, a smartphone, a voice-enabled device, a smart speaker, a server, a tablet computer, smart headphones, an Internet-connected device, and / or the like. As described herein, some devices used in connection with the systems described herein are designated as client devices, which generally are operated by end users. Other devices are designated as servers, which generally perform back-end operations and communicate with client devices (and / or other servers and / or other components) over a communications network such as the Internet. In at least one embodiment, the methods described herein can be implemented in a cloud computing environment using techniques known to those skilled in the art.

[0018] Moreover, those skilled in the art will recognize that the techniques described herein may be implemented in other contexts, and indeed in any suitable device, set of devices, or system capable of interfacing with existing data storage and / or electronic commerce systems. Accordingly, the following description is intended to illustrate various embodiments by way of example, rather than to limit the scope.

[0019] 11 , a block diagram is shown depicting the overall schematic architecture of a system 1100 for providing personalized treatment recommendations to patients, according to one embodiment. Personalization engine 1101 receives input from various sources, including services 1102 and 1105, and generates user output 1110, which may include personalized treatments, clinical trials, news, and / or patient-reported outcomes (PROs). In at least one embodiment, input to personalization engine 1101 can be provided via various application programming interfaces (APIs) 1111. Service 1102 can provide information from user input 1104 collected via an app or other software, and / or information from medical records, claims, and / or the like 1103. Service 1105 can provide information about approved treatments 1106, clinical trials 1107, news 1108, and patient-reported outcomes (PROs) 1109.

[0020] In at least one embodiment, data collected about patients can include patient-generated data, such as patient-reported outcome data, and / or data from sensors, such as FitBit devices, smart watches, heart monitors, and / or the like. In at least one embodiment, such data is used to recognize similarities between patients (e.g., via distance metrics), and these similarities are then used to generate recommendations regarding resources, treatments, and / or the like. Such similarities can also be used to generate suggested social media contacts. The system can then provide mechanisms for enabling anonymous communication, such as via social networks, between patients with similar problems and / or conditions.

[0021] In at least one embodiment, the system is implemented on a platform consisting of a mobile application, an API server, a database, and internal management tools. In at least one embodiment, the platform is a web services architecture built using standard tools such as EC2, PostgreSQL, Node.js, etc. The system can use API integration with many third-party systems, such as Wolters Kluwer Health and NCI, among others.

[0022] In at least one embodiment, all aspects of the system and platform comply with all applicable laws and regulations, including the Health Insurance Portability and Accountability Act of 1996 (HIPAA). The system also provides industry-standard security to ensure data confidentiality. In particular, in at least one embodiment: No data is stored on your mobile device. All cloud services are HIPAA compliant and are operated, for example, by Amazon Web Services (AWS) with Backend-as-a-Service (BaaS). All transmitted data (data in motion) is encrypted. All stored data is encrypted. · Access to identified patient health information is secure and restricted. · All access to identified patient health information is logged. · No patient health information is stored outside of the secure cloud-based platform.

[0023] Referring now to Figure 1, a block diagram is shown depicting an example of a more detailed architecture of a system 100 for providing personalized treatment recommendations to patients, according to one embodiment. Those skilled in the art will recognize that the various components and arrangements of such components as shown in Figure 1 are merely exemplary, and that the techniques described herein can be practiced using other components and / or arrangements. In at least one embodiment, the architecture shown in Figure 1 can implement the functionality shown in the schematic architecture of Figure 11.

[0024] In some embodiments, the systems and methods described herein can be implemented using one or more of the components shown and described herein with respect to FIG. 1 . Such components can be implemented in a cloud computing-based client / server architecture, for example, using Amazon Web Services, an on-demand cloud computing platform available from Amazon.com, Inc. of Seattle, Washington. Accordingly, for illustrative purposes, the systems and methods are described herein in the context of such an architecture. However, those skilled in the art will recognize that the systems and methods can be implemented using other architectures other than a client / server architecture, such as, for example, standalone computing devices or a distributed computing architecture.

[0025] Additionally, the functions and / or method steps described below may be performed by software running on one or more of the various devices and components depicted in Figure 1. This software may, optionally, be multi-function software used to retrieve, store, manipulate, and / or otherwise use data stored on data storage devices 117-122 and / or other components.

[0026] In the context of the description herein, a "user" may be a patient, healthcare provider, assistant, administrator, system administrator, manager, consumer, prospective consumer, customer, and / or any other individual, business, or other group, and may optionally include one or more users. Data storage devices 117-122 may be implemented using any data store or other storage device, which may include any device capable of digital data storage, including any known hardware for non-volatile and / or volatile data storage, and may be implemented using known database techniques. A collection of such data stores may form a "data storage system" accessible by multiple users.

[0027] In the context of the description herein, a "computing device" or "client device" may be any device capable of digital data processing, including, but not limited to, one that can receive any combination of text-based input, touchscreen input, voice-based (speech) input, and / or the like, and further generate any combination of visual output, text-based output, tactile output, and / or audio output (including voice-based (speech) output). As described below, the various hardware components described herein may communicate with one another via any suitable electronic network, which may include wired and / or wireless components.

[0028] In the context of this description, a "server" may be any computing device that performs back-end processing and / or functionality for implementing the techniques described herein. Such a device may communicate with client devices, network components, and / or storage devices, as appropriate, to implement the techniques described herein.

[0029] FIG. 1 depicts various data storage elements 117-122. Those skilled in the art will recognize that these may represent any number of separate storage devices, or their functionality may be combined into one or more physical storage devices. Thus, storage elements 117-122 need not have a one-to-one correspondence with physical storage devices. Storage elements 117-122 may be provided in a single location or in locations separate from one another. Any known data storage technology may be used to implement storage elements 117-122. In various embodiments, storage elements 117-122 may be implemented as databases using any known database technology, or they may be implemented in other ways, or any combination thereof.

[0030] In at least one embodiment, the following data storage elements are provided: Other Content 117, storing any additional content required or used by the system, pre-populated by the Content Ingestion Component 108 and used by the Patient API 114. Clinical Trial and News Content 118, which stores data describing current and / or past clinical trials and / or any related news events, is pre-populated by the Content Ingestion Component 108 and used by the Patient API 114. In at least one embodiment, separate data storage elements may be provided for clinical trials and news content, respectively. Disease and Treatment Content 119, which stores data describing diseases and treatments. Pre-populated by the Content Ingestion Component 108 and used by the Patient API 114. Patient Identifiable Information (PII) 120, patient information including identification information. This may include sensitive and / or confidential data and therefore, in at least one embodiment, it is securely stored and requires appropriate authentication for access in accordance with applicable laws and regulations. It is pre-configured and used by the Patient API 114. De-identified patient health information 121, patient information without identifying information, which can be used for data analysis and / or data insights. Receives input from and interfaces with the Patient API 114. Used by the Data Insights Engine 115 and Data API 116. Data Insights 122, including data insights generated by the Data Insights Engine 115 using data from de-identified patient health information 121. Receives input from and interfaces with the Patient API 114 and the Data Insights Engine 115. Used by the Data API 116. In at least one embodiment, additional data storage elements may also be provided, for example for resources.

[0031] Other components shown in FIG. 1 perform various other functions, such as:

[0032] In at least one embodiment, the content ingestion component 108 searches for relevant content from a variety of content sources 101, which may include any number of public, private, and third-party systems. The component 108 may also communicate with diagnostic-based algorithms 113, described below, to collect content generated by the algorithms 113.

[0033] In at least one embodiment, the retrieved content is normalized and categorized so that it can later be provided only to appropriate audiences by the personalization platform described herein. In at least one embodiment, the content ingestion component 108 stores the content in any number of suitable data storage devices, including, for example, other content store 117, clinical trial and news content store 118, and / or disease and treatment content store 119. In at least one embodiment, the content stored in storage devices 117-119 can be stored using any known database storage technique.

[0034] In at least one embodiment, the patient record capture component 109 collects patient health information from sources such as an electronic health record (EHR) system 102 and / or patient records 103. In at least one embodiment, such collection is performed using appropriate secure data connections to ensure patient confidentiality and comply with applicable laws and regulations. In at least one embodiment, the patient record capture component 109 provides process tools for parsing, annotating, and incorporating the collected health information into the personalization platform described herein. In at least one embodiment, the patient record capture component 109 communicates with a patient application programming interface (API) 114 to enable such functionality.

[0035] In at least one embodiment, diagnosis-based algorithms 113 are provided for treatment, clinical trials, and news. Such algorithms 113 can be executed on any suitable server, cloud computing platform, or other computing component. In at least one embodiment, the algorithms 113 are a collection of rigorously refined and tested processes for individually delivering personalized results to patient-users. In at least one embodiment, the algorithms 113 receive input from the content ingestion component 108 and provide results to a proprietary API 114.

[0036] In at least one embodiment, a patient API 114 is provided to interface with the various components of the system, provide functionality, and ensure that all of the various services and components of the platform work in concert with one another.

[0037] In at least one embodiment, the patient mobile app 110 runs on the device(s) 104 associated with the patient and / or caregiver. The patient mobile app 110 optionally interfaces with the patient API 114 to provide a user-friendly interface that allows the patient and / or caregiver access to tools for creating individual patient profiles. The system then uses these patient profiles to provide specially tailored content and experiences appropriate for the particular user. In at least one embodiment, additional apps may also be provided, such as an app that provides a dashboard for healthcare providers to create, review, and update protocols and other settings. In at least one embodiment, other user-facing technologies and interfaces may be provided in addition to or instead of apps (including the patient mobile app 110), such as, for example, kiosks, computer interfaces, web pages, and / or the like.

[0038] In at least one embodiment, the system includes a patient management portal 111 as an internal tool that enables administrative and operational staff to provide services and support to patient-users in a secure and private manner.

[0039] In at least one embodiment, the system includes a data insights engine 115 as an internal tool that provides analytical access to administrative and operational staff without exposing or compromising the privacy of patient-users.

[0040] In at least one embodiment, the data management portal 112 is a customer-facing tool that enables data customers to perform analytics on datasets to which they subscribe. A "data customer" includes any entity that may be interested in analytics and other insights into the data collected by the system. In at least one embodiment, such data customers can access the data management portal 112 via their own client devices 107. Related reports, charts, and / or interactive applications can be presented by the data management portal 112 on such devices 107.

[0041] In at least one embodiment, the data API 116 provides controlled access to data customers. In at least one embodiment, the data API receives data from various data storage devices, such as de-identified patient health information 121 and data insights 122, and processes such data for presentation via the data management portal 112. In at least one embodiment, the data API 116 allows data customers direct access to the API if they so desire.

[0042] Referring again to Figure 11, in at least one embodiment, the various components depicted therein can be implemented using any combination of the components depicted in Figure 1. For example, the personalization engine 1101 can be implemented in the patient API 114 and the patient mobile app 110. The services 1102, 1105 can retrieve information from the data stores 117-122. The user output 1110 can be provided via the patient mobile app 110.

[0043] In at least one embodiment, the system retrieves and uses information from electronic health records (EHRs) and / or other sources as input to generate personalized information and treatment recommendations.

[0044] Often, different healthcare providers use different medical systems, which in turn use different EHR vendors and workflows. Traditionally, creating direct integration between these various systems can be difficult and costly, and often infeasible given competing business needs and priorities.

[0045] Thus, in at least one embodiment, the patient mobile app 110 is used as a hub that enables data extraction and integration between various EHR systems and workflows. A provider-facing Secure Care Plan (SCP) dashboard is provided, allowing care providers to review and update SCPs across various healthcare systems. In at least one embodiment, the Secure Care Plan can include a Survivorship Care Plan, although in other embodiments, it can incorporate other elements beyond survival.

[0046] In at least one embodiment, the system employs universal open APIs, thereby ensuring rapid proliferation across its various components. To maintain compatibility with most existing EHR systems, the system can use the Substitutable Medical Applications and Reusable Technologies (SMART) platform (SMART on FHIR), which operates on the Fast Healthcare Interoprability Resources (FHIR) API.

[0047] FHIR is a "next generation" interoperability standard developed by HL7, a non-profit ANSI-accredited standards development organization. It incorporates many concepts already familiar to developers in other fields, such as Resources, which represent common healthcare concepts like Medication and Problem, and the simple REST-based APIs popularized by some of the biggest internet companies, including Google, Twitter, and Facebook. All major EHR vendors are collaborating on interpretations and profiling of the FHIR standard through the Argonaut Project.

[0048] SMART adds a layer of security in front of the FHIR interface by utilizing OAuth2 for authentication and authorization and OpenID Connect for user identification. SMART also standardizes the process for negotiating information access and manipulation between clients and servers. It also describes a process by which EHR applications can launch external applications with context storage and provide secure access to data within the EHR. EHR vendors are building support for SMART into their products and deploying the technology to healthcare organizations. Many major EHR companies, as well as other technology companies, have built SMART support into their products. Hundreds of hospitals and health systems offer this functionality.

[0049] In at least one embodiment, the system exchanges data between and among various EHRs and workflows via the SCP. In at least one embodiment, certain individuals may be able to access and edit the SCP, for example, as follows: Physicians, such as primary care physicians, specialists (e.g., oncologists), or advanced care providers at institutions with EHR systems, via a provider dashboard. · Patients or Patient Navigators (PNs) using their credentials via the Patient / PN mobile app.

[0050] In at least one embodiment, the SCP provides date / time stamps and can synchronize with the EHR system(s) of any number of physicians caring for the patient, even if the patient uses different healthcare systems.

[0051] In at least one embodiment, the system integrates into any existing EHR system and workflow using a SMART on FHIR approach. For example, the system can integrate with systems that use EPIC as their EHR vendor. In at least one embodiment, two levels of integration are employed to provide the functionality described herein. Provider level: Connect a provider-controlled SCP dashboard to the EHR, preserve context, and provide secure access to data within the EHR with the ability to: ·Reading diagnostic, treatment, and scheduling information from EHR vendors (e.g., EPIC) required to create and update SCPs ·Writing SCPs and updates to EHR vendors Patient-level: Connect a patient / PN-facing mobile app to an EHR with the following capabilities: - Reading relevant data from patient records ·Writing SCP updates to EHR vendors

[0052] The system ensures full compatibility with existing IT infrastructure, including system interoperability (e.g., with other providers using Cerner or others), cybersecurity, and patient privacy requirements.

[0053] By using a SMART on FHIR approach, the system ensures that subsequent installation in other healthcare systems is streamlined, requiring significantly less resource allocation from the hospital's IT group and simplifying project management. Such an approach standardizes the system's integration into existing architectures and EHR systems, requiring little to no custom development. Another benefit is a consistent user and patient experience across EHR platforms.

[0054] In at least one embodiment, the system is implemented using a web-based architecture employing standard tools such as Node.js and a cloud-based, HIPAA-compliant infrastructure provided by AWS, with appropriate security and privacy protocols employed to further ensure HIPAA compliance and a high level of security.

[0055] In at least one embodiment, the system includes several different apps that integrate with existing EHR systems and existing workflows. These include, for example: A provider dashboard for creating, reviewing, and updating SCPs; A patient / PN mobile app 110 may be included that includes the SCP and additional features to facilitate patient navigation through vital care.

[0056] To ensure maximum value to patients and providers, in at least one embodiment, all apps offered will integrate with all existing EHR systems and workflows.

[0057] Referring now to FIG. 14A, an example 1400 of such integration is shown, according to one embodiment. The top of example 1400 depicts the steps associated with a provider dashboard 1410. In step 1401, a healthcare provider logs into an existing EHR system (e.g., EPIC) and reviews the patient's chart. In step 1402, the provider launches a provider app 1410, which saves the EHR context and creates / updates the SCP. In step 1403, an SCP copy is stored in the EHR system, and the provider can retrieve patient data linked to the SCP via the EHR system and specify automatic notification frequencies and thresholds. Step 1404 shows that the provider always has access to the latest version of the SCP, and summaries are sent to the provider, automatically notifying the provider of any abnormal results.

[0058] The bottom portion of example 1400 depicts the steps associated with the patient app 110. In step 1405, the patient downloads the app 110, creates an account, and activates the SCP functionality. In step 1406, the patient downloads and activates the EHR Patient Portal app, enabling sharing via any suitable platform, such as OpenEpic. In step 1407, information in the SCP is used to personalize the app 110, and data from various functions within the app 110 is used to update the SCP.

[0059] 14B, a block diagram is shown depicting the relationships between the Secure Care Plan 1421 and other entities, according to one embodiment. In at least one embodiment, the SCP 1421 is used as a repository for truth and accuracy. By synchronizing data in the SCP 1421 with other entities that may store and / or use patient information, such as the EHR system 102, the mobile app 110, the primary care physician / nurse 1424, and / or the specialist physician / nurse 1425, the system ensures compatibility with all external systems. This allows the system to avoid the need for two different EHR systems 102 to directly communicate and synchronize with each other.

[0060] Integration Referring now to FIG. 15, there is shown a flow diagram depicting a method 1500 of integrating the described system into existing electronic health record (EHR) systems and workflows, according to one embodiment.

[0061] The method begins at 1501. The required FHIR resources are identified at 1502. EHR data elements are then mapped 1503 to the equivalent FHIR resources.

[0062] In at least one embodiment, steps 1502 and 1503 occur at the beginning of the project and take into account the design of the SCP. For example, the following FHIR resources may be identified and used: Patient (Name, Gender, Date of Birth, Demographics), Practitioner, Medication Order, Medication Statement, Condition, Observation, Diagnostic Report, Procedure, Care Plan, and Goal.

[0063] Next, the system is configured 1504 to be SMART-enabled, and apps (e.g., including the patient mobile app 110 and provider app 1410) are registered 1505 with the Authorization Server. This may involve development using the SMART sandbox and other available data. In at least one embodiment, various approaches can be tested before full deployment. In particular, the patient mobile app 110 can provide test patient data, and the FHIR browser can facilitate review of changes to the data made by the patient mobile app 110. In at least one embodiment, the SMART launcher can be used to configure, test, and demonstrate the mobile app 110 using sample patients in the SMART sandbox.

[0064] Appropriate customizations can then be configured 1506. For example, if the system is configured for use with a specific EHR system 102, such as EPIC, EPIC-specific customizations can be performed. EPIC provides various resources to meet FHIR integration needs. Thus, the system can be configured based on a determination of which resources are most appropriate for a particular application. For example, open.epic provides free resources to support patient-controlled apps (such as app 110) that access the Common Clinical Data Set (CCDS) from the patient's medical record. Epic USCDI over FHIR is adapted for provider-controlled applications and also provides free resources for accessing USCore Data (USCDI) for interoperability. Finally, the Epic App Orchard developer program provides additional resources, including access to additional Epic APIs (FHIR or other) for creating further integrations with EPIC. In at least one embodiment, an EPIC-provided sandbox is used to test and validate the app 110 before deployment to the live system.

[0065] Next, the integration of the system into the EHR system 102 (e.g., EPIC) is finalized 1507. To find the FHIR resources needed for this process, any of several methods can be used, including, for example: EPIC Web Services. The preferred approach is to use EPIC-provided web services to find data elements, where possible, and then expose them through a FHIR interface. The advantage is that these web services handle any necessary auditing and logging with minimal overhead. They are also fast and efficient, pulling data from Chronicles, EPIC's real-time clinical database. Clarity. If there is no web service available for a particular data type, the data can be quickly and easily pulled from Clarity, a relational database that is updated daily with data from production clinical databases. While this may not be ideal for data elements that require real-time accuracy, it can be useful for prototyping FHIR resources. Shadow. When web services are unavailable, the system can use Shadow, a reporting database that is synchronized with Chronicles, EPIC's real-time clinical database. The database can use the Massachusetts General Hospital Utility Multi-Programming System or the Cache database management system, which is based on MUMPS.

[0066] The method then ends at 1599.

[0067] In addition to mapping EHR data elements to the appropriate FHIR resources, a key element for fully integrating workflows is the authentication and authorization process. In at least one embodiment, an integration process such as single sign-on (SSO) is employed so that providers do not need to log in to the SCP dashboard after already logging in to the EHR environment. This integration can be achieved through the standard OAuth 2.0 standard, which may require modifications to the EHR environment so that the EHR generates tokens that the FHIR infrastructure understands and interprets, thereby granting appropriate access to authorized users. In at least one embodiment, a web-based view of a patient's SCP in Hyperspace is integrated using single sign-on and secure SCP invocation in the patient context. This allows healthcare providers, such as physicians or specialists, to interact with a patient's SCP information directly from the SCP system, rather than relying solely on data integrated into EPIC.

[0068] In at least one embodiment, workflow integration is also performed, for example, by integrating the system into provider and patient navigator workflows. For example, the system can determine where the dashboard app 1410 should be available within the clinical workflow app 110 and easily invoke the app 110 or app 1410 within that workflow. Examples include adding a button to the same menu as the EHR's existing care plan functionality. A click or tap opens the SCP dashboard app 1410 for the provider in the same manner as the default care plan app. Additionally, the patient mobile app 110 can be directly integrated into existing software functionality, such as the myChart portal, so that it can be invoked with the activation of a single button without any additional authentication.

[0069] In other embodiments, integration can be performed using other approaches. These include, for example, an HL7 interface, custom flat file extracts from the EHR system 102 such as EPIC, and / or custom document submission feeds to the EHR system 102. If extensive customization is required on the healthcare system side, the system can employ third-party solutions, such as those available from Redox, Inc. of Madison, Wisconsin, which implement an authorization layer at the system level through interactions with the involved businesses. Redox completes the setup process and verifies who is authorized to receive the data. As a result, Redox supports apps regardless of EHR or language and reading and writing ability.

[0070] How to personalize As noted above, the automated techniques described herein provide personalized treatment information to patients and their caregivers without the patient having to search for treatment or consult a doctor. According to various embodiments, patient data can be retrieved directly from healthcare systems, automatically analyzed, and used to present and connect relevant personalized information to patients and their caregivers.

[0071] Referring now to Figure 2, a flow diagram illustrating a therapy personalization method 200 according to one embodiment is shown. In at least one embodiment, the method of Figure 2 can be implemented using a system architecture such as that shown in Figure 1. For example, in at least one embodiment, the method 200 is implemented in components of Figure 1, such as the patient API 114, the patient mobile app 110, and / or the diagnosis-based algorithm component 113. Thus, for illustrative purposes, some of the steps of Figure 2 are described as presenting information and / or collecting information via the patient mobile app 110. However, one skilled in the art will recognize that the method of Figure 2 can be implemented in other systems having different arrangements and / or components.

[0072] In various embodiments, the information can be personalized based on patient information automatically retrieved from approved patient records and / or based on the user's answers to questions, for example, via a questionnaire. In at least one embodiment, personalization is performed by automatically retrieving specific treatments based on patient attributes.

[0073] In at least one embodiment, a user downloads and installs the mobile app 110 before first use. As described in more detail below, upon login, the patient is given two options for entering clinical information about their illness and treatment. The patient can enter the clinical information based on their own knowledge or can sign a patient-directed HIPAA disclosure request to allow access to their medical records. Specific clinical information of interest is then extracted directly from the retrieved medical records.

[0074] The data entered or accessed may include, for example, disease-specific diagnostic and treatment information such as HER-2 and hormone status, for metastatic disease, whether the patient has had surgery, whether the patient has started treatment, and the type of treatment the patient has received.

[0075] As described in more detail below, the system then generates personalized information and / or treatment recommendations based on the provided clinical information. Such personalized information and recommendations may include, for example: The patient's next standard nursing care treatment option, according to appropriate guidelines (e.g., National Comprehensive Cancer Network (NCCN) guidelines), Clinical trials tailored to your condition and preferred location; · Customized news feed, Customized resources, such as transportation assistance, financial assistance, specialized trainers, and / or the like; and / or Information about patients with similar medical histories and preferences and / or who have had particular responses to treatment.

[0076] Patients can also self-report quality of life data and their symptoms. Referring now to Figures 16A-16C, various example screens of a user interface for patients to provide such information are shown, according to one embodiment.

[0077] Screens 1601, 1602, and 1603 provide symptom management tips. Screens 1603 and 1604 display warnings for severe symptoms. Screen 1605 provides a user interface for self-reporting symptoms. Screens 1606 and 1607 provide a display of previously reported symptoms.

[0078] In at least one embodiment, the system can collect patient information from sensors such as those found on wearable devices such as FitBit devices or smartwatches (e.g., Apple Watch available from Apple Inc. of Cupertino, California).

[0079] Additionally, patients can save various treatments, tests, and news, take notes, and record their treatment progress. Finally, in at least one embodiment, the system can prompt the user when information is updated or provide automatic notifications to enter new data and perform surveys.

[0080] The method begins at 201. As a first step, software (e.g., patient mobile app 110) is installed 202 and user account information is collected 203. In at least one embodiment, a user can manually enter the user account information, or such information can be retrieved from any suitable location, such as from patient identification information 120 and / or from other sources.

[0081] In at least one embodiment, prior to such direct retrieval of patient data, the user is given the option 204 to approve access to the patient record or answer medical questions. If the user chooses to approve access to the patient record, the user can sign an electronic consent form directly within the patient mobile app 110. The app 110 then automatically generates a consent form in a format acceptable to a third party that has the requested record(s), which may be, for example, a medical hospital or diagnostic laboratory. This may include collecting 205 user identification information and / or HIPAA record authorization.

[0082] The system then automatically sends a request to the third party along with any other information that may be needed to retrieve the desired information. The request may be sent by any suitable means, such as, for example, email, fax, API integration, etc. This may include sending 206 encrypted user identification information and record authorization to the server. Once the third party responds with the requested information, the data record may be automatically processed and analyzed by the system to extract the desired information according to the steps described below.

[0083] Examples of patient data include, but are not limited to, electronic medical records, genomic information, billing records, geolocation, diagnostic tests, medical benefits, insurance plan information, etc. Examples of healthcare systems that may be sources of requested information include, but are not limited to, hospital systems, clinics, payer systems, diagnostic companies, clinical laboratories, etc.

[0084] If in step 204 the user indicates that they would like to answer medical questions in exchange for granting access, the system collects 207 the user identification information and answers to the medical questions, for example, by prompting and receiving input from the user via the patient mobile app 110. The collected information is then encrypted and transmitted 208 to a server for secure storage.

[0085] The system divides the collected and / or retrieved information into patient-identifying information and de-identified information 209, which may be stored in two separate data storage devices, such as data storage 120 for patient-identifying information and data storage 121 for de-identified patient health information. In at least one embodiment, the information is de-identified by automatically searching for patient identifiers and replacing them with code names.

[0086] In step 110, the system determines whether the user has authorized access to the patient record. If so, the patient record is retrieved 211 and then processed 212 to extract answers to the medical questions.

[0087] The system then supplements 213 any existing medical answers with new medical question answers, such as those collected in step 207.

[0088] The retrieved and / or collected patient information is then used as input to a personalization algorithm that calculates specific treatment options for the patient. In at least one embodiment, this is performed by reducing 214 the set of all possible treatments and treatment pathways to those recommended for the patient that match the answers to the user's medical questions or diagnostic information.

[0089] The system then provides all treatment pathway permutations and associated content to the user 215. This may include displaying treatment options, recommendations, and / or other information via the patient's mobile app 110. In at least one embodiment, the treatment options are displayed in common language to facilitate proper understanding. In at least one embodiment, translation of the treatment options into common language can be performed automatically. This can be done, for example, by looking up the various options in a patient-friendly translation dictionary, thereby translating all medical concepts into simple language that the patient can understand. Treatment options include, but are not limited to, approved medications, interventions such as surgery or radiation therapy, and clinical trials.

[0090] 10A and 10B, an example algorithm 1000 for personalized screening according to one embodiment is shown, including an optional questionnaire 1001 for collecting pedigree data.

[0091] Referring now to Figure 12, an example 1200 of the application of the personalization engine to generate appropriate treatment options for a patient is shown, according to one embodiment. Example 1200 depicts a treatment "tree" coded with treatment options corresponding to organized objects. In at least one embodiment, these treatment options are referenced to build a treatment database, which can be stored in data store 119 or other suitable location. As shown in Figure 12, the treatment tree includes a diagnostic question 1201 that leads to various treatment options 1202.

[0092] In at least one embodiment, the decision trees underlying the personalization engine are adapted from existing healthcare guidelines. In at least one embodiment, these existing guidelines are adapted and converted into one or more algorithms with questions, answers, and options, which are then used by the personalization engine to generate recommendations.

[0093] 13, an example 1300 of input received from a patient-reported outcomes (PRO) service is shown, according to one embodiment. In at least one embodiment, such input may be provided from a third-party PRO service, collected via a questionnaire or by other means. This input may be retrieved via the Data API 116 or automatically by accessing the database 120 and displayed on the Patient App 114 to collect patient data. The resulting output, particularly when integrated with clinical data and other third-party healthcare data, can then be incorporated into the described system for purposes of providing feedback and / or improved recommendations.

[0094] 17A and 17B, various example screens of a user interface for completing a patient record outcome questionnaire are shown, according to one embodiment. Screen 1701 provides an introduction. Screens 1702, 1703, and 1704 prompt the patient for information to be collected. Screen 1705 displays a summary of the responses. Screen 1706 displays confirmation that the questionnaire has been completed and provides a link 1706A to the results.

[0095] In at least one embodiment, information provided by the user or patient in response to a questionnaire can be used to match the patient with other patients with similar symptoms, patient-reported outcomes, and / or problems. In at least one embodiment, the system can automatically and anonymously connect the patient with other patients based on similarities in symptoms, patient-reported outcomes, and / or other factors. Such connections can occur via any suitable mechanism, including text, email, social media, and / or the like. In at least one embodiment, patient demographics, preferences, and / or other factors may also be considered when suggesting matching patients for such communication and connection.

[0096] User Experience The system described herein employs a proprietary personalization engine to implement an integrated mobile platform that brings together all the information needed to manage a patient's care in one place. Using the mobile app 110, patients can easily access peer-reviewed, evidence-based, personalized treatment information, access their health records, find relevant clinical trials available in their area, enter symptom and quality of life data, and be matched with similar patients based on their medical history and personal preferences.

[0097] The described system therefore provides an integrated mobile platform for direct use by patients and patient navigators, as well as a shared provider module, creating a comprehensive longitudinal data platform. The system can also be expanded to include survivorship care navigation to provide up-to-date, personalized, and clinically validated care plans and navigation, as well as complete visibility into a patient's personal clinical information. The system and its platform therefore provide a mechanism for empowering patients to take a greater, more knowledgeable role in their own care by facilitating informed decision-making, physician-patient communication, and care management.

[0098] The integrated methodology provided by the systems described herein enables every individual to make informed decisions about their medical care while making efficient use of scarce navigator and provider resources. Specifically, in various embodiments, the described systems can include any or all of the following advantages over previous systems: Integrating evidence-based clinical guidelines with an unprecedented mobile patient experience: The system integrates NCCN clinical guidelines in patient-friendly language and formats, making them widely accessible and eliminating the need for providers to parse and translate treatment options. · Seamless creation and integration of Secure Care Plans (SCPs): The system can deliver SCPs integrated into the EHR, enabling providers across disconnected healthcare systems to effectively manage patient care. · Automated screening tools: The system can integrate provider-driven, validated risk screening tools to free up valuable provider resources in risk detection settings and streamline risk detection. Personalized Navigation: The system helps individuals access local resources, providing a personalized, geographically aware approach and facilitating navigation, especially in resource-poor settings. This allows patients to connect with clinical trials closest to them, as well as local resources. In at least one embodiment, the integrated GPS functionality of the patient's phone (or other device) is used to identify the patient's location. Based on this information, the patient is presented with resources specific to their geographic location and based on their specific health history and needs, including, for example, patient assistance resources. Dynamic Live Updates: In at least one embodiment, the system uses adaptive algorithms to provide automatic push updates, allowing both users and providers to take informed action, including guideline updates, the latest scientific findings, and / or the like.

[0099] User Interface Example 3A-3I, various example screens of a user interface for a medical record workflow are shown, according to one embodiment.

[0100] 3A, a user enters information to allow access to a patient's medical records. In screen 3001, the user is prompted to either allow access to their medical records by tapping button 3001A, or answer a series of questions about their condition by tapping button 3001B.

[0101] In screen 3002, the user is prompted to select an option that will allow access to their medical record and enter basic information. In at least one embodiment, a cancel button 3002A is provided on screens subsequent to screen 3002. Clicking the cancel button 3002A returns the user to the initial request screen 3001. This continues until the user has finished the medical record flow and reached the home page. In at least one embodiment, a progress bar 3002B indicates the user's progress in any multi-screen process. In at least one embodiment, screen 3002 and subsequent screens with two or more form inputs display a check mark 3002C after the user successfully completes each input.

[0102] In at least one embodiment, a back button 3002D is provided on screens after screen 3002. Clicking back button 3002D returns the user to the previous screen, until the user exits the medical records flow and reaches the home page.

[0103] In screen 3003, the user is prompted to enter their address. In screen 3004, the user is prompted to begin searching for their medical institution.

[0104] 3B shows further details of the process for enabling access to medical records by selecting a medical institution. Again, in screen 3004, the user is prompted to begin a search to find their medical institution. Screen 3006 displays the search results, which the user can tap to select. In at least one embodiment, search results 3006B are displayed as the user typed in field 3006A. Clear button 3006C clears the search input from field 3006A.

[0105] Screen 3007 shows the selected medical institution. The user can tap Next button 3007C to confirm the selection, X 3007B to remove the selection, or field 3007A to start another search.

[0106] 3C shows further details of the process of enabling access to medical records by adding a new medical institution. Screen 3008 shows search results 3006B, but not the desired result, and the user can tap "Done" button 3008A to add the new medical institution. Screen 3009 allows the user to enter information about the new medical institution. The title 3009A of the new medical institution is taken from the text the user previously entered in search input field 3006A of screen 3006. Screen 3010 prompts the user to confirm the new medical institution.

[0107] 3D shows further details of the process for enabling access to medical records. In at least one embodiment, the user accesses screen 3012 by tapping next button 3007C on screen 3007. Screen 3012 prompts the user to enter record number(s) in field(s) 3012A and / or their social security number in field 3012B. In at least one embodiment, when the user completes both fields 3012A and 3012B, the user can clarify their selection by tapping one of checkboxes 3012C. In screen 3013, the user is prompted to sign the form by tapping sign button 3013A to enable access.

[0108] 3E shows further details of the process for enabling access to medical records. Again, in screen 3013, the user is prompted to sign the form by tapping sign button 3013A to enable access. Screen 3015 shows signature area 3015A where the user can sign using their finger. Screen 3016 prompts the user to confirm signature 3016A by tapping submit button 3016B. Screen 3017 prompts the user to create an account by entering an email address in field 3017A and a password in field 3017B and tapping register button 3017C.

[0109] FIG. 3F shows further details of the process for creating an account and submitting a diagnostic questionnaire. Screen 3017 prompts the user to create an account by entering an email address in field 3017A and a password in field 3017B and tapping register button 3017C. In screen 3019, the user is given the option to answer the diagnostic questionnaire. Screen 3020 shows an example screen from such a questionnaire, in which the user is prompted to answer question 3020D. Other questions can be presented using similar or other layouts. Question mark icon 3020C provides access to a drop-down element containing additional information, as described below. Cancel button 3020A cancels the questionnaire. Next button 3020B advances the display to the next question.

[0110] In at least one embodiment, after the user answers a number of questions, the system generates treatment options for the patient; screen 3021 depicts an example of a loading screen that may be displayed while the system's back-end processes generate treatment options. In at least one embodiment, a circular progress bar 3021A is displayed to indicate progress as the back-end system generates treatment options. Screen 3022 is an example of a home screen showing treatments and / or clinical trials being searched.

[0111] 3G shows an example of a user's interaction with a diagnostic questionnaire. In screen 3023B, in response to the user tapping question mark 3020C on screen 3020, additional information about the medication mentioned in the question is shown in drop-down element 3023C.

[0112] FIG. 3H depicts an additional example of a diagnostic questionnaire flow. In screen 3025, the user is assured that their personal and health information will remain safe and secure. Screen 3027 depicts a questionnaire review. The user can click submit button 3027A to submit their answers or click button 3027B to make changes. Clicking button 3027B takes the user to screen 3028, where the user can click any button 3028B to modify previously entered results and / or click submit button 3027A to submit their answers. In at least one embodiment, the user can click any of the answers in screen 3028 to return to that question in the questionnaire flow. The user then continues to answer subsequent questions in the questionnaire again. In at least one embodiment, if the user encounters questions that have already been answered while re-answering the questionnaire, these questions are automatically skipped and not presented to the user, leaving their previous answers. Thus, in at least one embodiment, the user is only presented with questions that they have not previously answered.

[0113] If the user taps submit button 3027A on screen 3027 and has not yet created an account and connected their medical record, screen 3017 is displayed, allowing the user to register, as described above in connection with FIG. 3E. Referring now to FIG. 3I, screen 3031 is depicted, giving the user the opportunity to connect their medical record. The user can tap button 3031A to accept or button 3031B to decline. If the user accepts, they are directed to screen 3002, as described above in connection with FIG. 3A. If the user declines, they are directed to screen 3021, which depicts an example of a loading screen that may be displayed while the system's back-end processes generate treatment options, as described above in connection with FIG. 3F. Next, the user may be directed to screen 3022, as described above in connection with FIG. 3F.

[0114] 4A and 4B, various examples of diagnostic update screens are shown according to one embodiment. In screen 4001, the user can select from several buttons 4001A-4001D to provide additional or modified information, including test results, diagnoses, interventions, treatments, and symptoms. The various buttons 4001A-4001D navigate the user to different screens to view and / or modify information. Button 4001D labeled "More" provides access to screens for automatic and direct personalization of information.

[0115] In screen 4002, the user tapped the Test Results or Diagnosis button 4001A. The user can update the answers to the various questions 4002B and click the Save button 4002C to return to the home page where the changes are saved. Clicking the X button 4002A returns the user to the Update Diagnosis screen 4001 and cancels any changes made.

[0116] In screen 4003, the user tapped the intervention or treatment button 4001B. The user can update answers to various questions 4003A and / or enter further explanation in field 4003B. In at least one embodiment, screen 4003 is preloaded with checkbox selections previously made by the user. The user can click the next button 4003D to proceed to screen 4004 or click the cancel button 4003C to return to the diagnosis update screen 4001 and cancel any changes made.

[0117] In screen 4004, the user taps the Symptoms button 4001C. The user can update the input for any of the symptoms 4004C. The user can click the Save button 4002C to save the changes and return to the home page. Clicking the Cancel button 4003C returns the user to the Diagnostic Updates screen 4001 and cancels any changes made.

[0118] In screen 4005, the user tapped More button 4001D. The user can now enter free text in text box 4005A. Submit button 4005C saves the input and returns the user to the home page. Cancel button 4003C returns the user to diagnostic update screen 4001 and cancels any input.

[0119] Automatic integration of clinical guidelines Many diseases have clinical treatment guidelines intended to help physicians identify treatment options for their patients. These guidelines are often published by provider associations; examples include the National Comprehensive Cancer Network (NCCN) or the American Society of Clinical Oncology (ASCO). Traditionally, guidelines are distributed, for example, in PDF format, for physicians to review and decide on treatment options for their patients.

[0120] In at least one embodiment, the system described herein receives as input a patient's clinical information and outputs treatment options according to established clinical guidelines. In at least one embodiment, a treatment personalization method similar to that depicted in FIG. 2 is used to select the treatment to display.

[0121] In various embodiments, different treatment personalization algorithms may be provided for different diseases. Clinical guidelines are used as input to specify the algorithm to use. Patient clinical information is provided as input to the system. The output is a specific treatment option according to the established guidelines.

[0122] 9A and 9B, examples of treatment personalization algorithms 900A, 900B for metastatic breast cancer are shown. FIG. 9A depicts treatment personalization algorithm 900A when HER2 status is positive, and FIG. 9B depicts treatment personalization algorithm 900B when HER2 status is negative. Patient clinical information is represented as answers to questions 901. Treatment options 902 are provided in response to such answers to questions 901. In at least one embodiment, algorithms such as personalization algorithms 900A, 900B are implemented automatically by the described system according to the method depicted in FIG. 2 or any other suitable method.

[0123] In at least one embodiment, the personalization algorithm determines the shortest path, which is then mapped to the minimum number of questions the algorithm needs to know to solve the case and provide options.

[0124] In at least one embodiment, the system presents a treatment pathway for the patient in a linear format, including various treatment categories. Referring now to Figures 5A-5F, example screens of a user interface for a treatment pathway are shown, according to one embodiment.

[0125] FIG. 5A depicts a screen 5001 showing a treatment pathway 5001A including various treatment steps 5001B, 5001C, and cards 5001D. The user can scroll the screen 5001 as needed to view additional steps that may not be initially visible. In at least one embodiment, each treatment category is depicted with a unique color or other unique visual attribute. A text label 5001F can indicate whether a particular treatment step is optional. In at least one embodiment, if "supportive care" is part of a patient's treatment pathway, it is always placed second in the pathway.

[0126] In at least one embodiment, the user can tap either treatment step 5001B, 5001C to expand it. For example, tapping chemotherapy step 5001B displays screen 5002, which includes card 5002A showing additional details about step 5001B. In this example, card 5002A explains why step 5001B is optional for this patient. As described in more detail below in connection with FIG. 5D , the user can tap view all options button 5002B to view additional options for step 5001B. Tapping chemotherapy step 5001B on screen 5002 collapses card 5002A and returns to screen 5001.

[0127] 5B depicts screen 5003 after the user has scrolled down to reveal card 5001D. Card 5001D depicts a situation in which a particular treatment step may not be determined until the patient progresses through their treatment; until then, multiple alternative treatment steps may be possible. Thus, in this example, card 5001D depicts multiple "to be determined" steps 5003A, 5003B grouped together within treatment pathway 5001A.

[0128] 5C depicts screen 5004, with card 5004A indicating that the first step in a patient's treatment pathway is a group of "to be decided" steps 5004B, 5004C. Card 5004A therefore advises the patient to consult their physician about the treatment options represented in steps 5004B, 5004C. In at least one embodiment, tapping on one of steps 5004B, 5004C in the group activates screen 5004D, which displays summary text describing the treatment option but omits detailed information about the treatment plan.

[0129] 5D depicts screen 5005, which may be displayed in response to a user tapping a See All Options button 5002B on screen 5002. Additional options 5005A for chemotherapy step 5001B are shown, including various regimens 5005E. Screen 5005 may include static text elements 5005B and / or elements 5005C containing text provided by a back-end system. The user can tap a See More button 5005D to display additional treatment options 5006A, as shown in screen 5006. The user can tap a Show Fewer button 5006B to collapse additional treatment options 5006A and return to screen 5005.

[0130] In at least one embodiment, the user can tap one of the plans 5005E to see additional information. FIG. 5E depicts screen 5007, which includes additional information 5007A that may be displayed after the user taps on the AC-T plan 5005E in FIG. 5D. In at least one embodiment, this additional information is pulled from live data from an API, such as Data API 116. The information is automatically reformatted so the user always has access to the most up-to-date information in a live, patient-friendly format.

[0131] 5F, examples of a treatment option screen 5008, a treatment details screen 5009, and a next treatment option screen 5010 are shown. The treatment option screen 5008 shows various treatment options 5008A, 5008B. The user can tap on treatment options 5008A, 5008B to view additional details. In this example, the user taps on treatment option 5008B to view further details 5008C, 5008D, which describe chemotherapy options.

[0132] The user can then tap details 5008C, 5008D to view additional information. Treatment details screen 5009 is an example of a screen that may be displayed when a user taps details 5008C. Additional information 5009A is displayed along with medication descriptions 5009B, 5009C, 5009D. The user can tap any of medication descriptions 5009B, 5009C, 5009D to view more information about a particular medication. The user can tap next treatment option button 5009E to activate next treatment option screen 5010, which contains similar information as shown in screen 5008. Screen 5010 also includes a back button 5010A that returns the display to treatment page 5009.

[0133] In at least one embodiment, this additional information is captured from live data from an API, such as the Data API 116. The information can be automatically reformatted so that the user always has access to the most up-to-date information in a live, patient-friendly format.

[0134] 5G, there is shown a portion of a treatment personalization algorithm 5011 that can be used to pre-populate treatment option screens, such as screens 5008 and 5010, according to one embodiment. As with algorithms 900A, 900B depicted and described above in connection with FIGS. 9A and 9B, the patient's clinical information is represented as answers to questions 901. In response to such responses to questions 901, treatment options 902 are provided. In this example, treatment options 902A of algorithm 5011 pre-populates screen 5008 with information collected using relevant answers received from the user. Similarly, treatment options 902B of algorithm 5011 pre-populates screen 5009 with information collected using relevant answers received from the user.

[0135] Geographic location of clinical trials Clinical trials are often conducted in multiple locations, with various centers administering the trials. Existing systems fail to provide any functionality for automatically matching trials based on clinical data retrieved from healthcare systems and the user's location. Furthermore, existing systems do not provide any way to display a map of trials that match the user's disease and are closest to the patient's location across various clinical trials and various healthcare systems.

[0136] Various embodiments of the described system address these deficiencies. In at least one embodiment, a computer system automatically matches and prioritizes clinical trials based simultaneously on a user's clinical information and location, and the resulting information is displayed on a map. Trials are prioritized based on both clinical information and location, and unique trials are shown on an interactive map or displayed as a list.

[0137] In at least one embodiment, a treatment method similar to that depicted in FIG. 2 is used to select trials to display. The system examines clinical attributes from patient records and / or responses to questions and uses these attributes to conduct a multi-tiered search of clinical trials, which may include inclusion and / or exclusion criteria. In at least one embodiment, the method uses natural language processing to determine which keywords match which portions of the trials. Natural language processing can also be used to analyze medical records and health information, so that the information can be integrated with clinical trials to provide improved personalization.

[0138] In at least one method, clinical trials are pre-classified based on specific disease attributes, and then such attributes are automatically matched with patient attributes to improve personalization.

[0139] In at least one embodiment, the map is generated automatically by looking up location information from a clinical trial repository and rendering it on a map app based on the mobile device's current location. One example of such a clinical trial repository is clinicaltrials.gov, but it can integrate information from many different sources, and new sources can be incorporated at any time as needed.

[0140] 6A-6C, various example screens of a user interface for a clinical trial workflow including GPS functionality are shown, according to one embodiment.

[0141] FIG. 6A depicts screen 6001, in which a user is presented with the option of selecting Treatment 6001B or Clinical Trial 6001A. In screen 6002, the user taps Clinical Trial 6001A and is presented with a list 6002A of Clinical Trials 6002B. In at least one embodiment, GPS information is used to rank and / or filter the clinical trials 6002B within list 6002A. The user can click Most Important button 6002C to have list 6002A ranked according to a relevance algorithm. Nearest button 6002D causes list 6002A to be ranked based on proximity to the user's (or patient's) geographic location, as may be determined based on available GPS information. Type button 6002E displays screen 6003, which includes a dropdown 6003D that allows the user to filter list 6002A based on clinical trial type and / or other criteria; checkboxes 6003A are provided for such criteria. In screen 6003, save button 6003B closes dropdown 6003D, saves the user's selections, and returns to screen 6002. Back button 6003C closes dropdown 6003D and returns to screen 6002 without saving changes. In at least one embodiment, the user can also tap anywhere outside of dropdown 6003D to return to screen 6002 without saving changes.

[0142] In screen 6002, back button 6002G returns to screen 6001. Intro button 6002F causes screen 6004 to be displayed, which contains an introduction to the clinical trial and / or other background information.

[0143] Various explanatory information items are displayed within the clinical trials list 6002A. In at least one embodiment, an indicator 6002H is displayed to indicate clinical trials that have been added since the user last opened the screen 6002. A distance indicator 6002I displays the distance of the clinical trial from the user's current location based on available GPS information.

[0144] FIG. 6B depicts a screen 6005 that provides information about a clinical trial. A user can tap buttons 6005A through 6005E to view different types of information, and in at least one embodiment, such information is pulled live via an API and / or from existing stored databases. Button 6005A activates a screen 6006 that provides general information about the clinical trial. Button 6005B activates a map view 6007 that displays the location of the clinical trial. Button 6005C activates a screen 6008 that lists questions the user may want to ask about the clinical trial. Button 6005D activates a screen 6009 that provides information about eligibility. Button 6005E activates a screen 6010 that allows a user to add notes about the clinical trial.

[0145] FIG. 6C depicts further details of map view 6007, which provides an interactive map 6007A of filtered clinical trial locations. In at least one embodiment, map view 6007 can be activated by tapping location button 6005B on screen 6005. Panel 6007B displays information about the clinical trial location. Open in map button 6007C opens the user's default maps app with the clinical trial location. Phone button 6007D allows the user to call the clinical trial location using their phone. Email button 6007E opens the user's default email app, pre-populated with the clinical trial coordinator's email address along with detailed information about the clinical trial.

[0146] In at least one embodiment, tapping panel 6007B causes map 6007A to center on the location of the clinical trial. In at least one embodiment, the user can swipe panel 6007B left or right to view other locations, and as the user swipes panel 6007B left or right, map 6007A centers on the location of the newly displayed panel.

[0147] Providing and personalizing outcome data In at least one embodiment, the described system allows a patient to identify treatment options and prioritize such options based on one or more user-defined clinical outcome metrics.

[0148] In at least one embodiment, the system uses an algorithm that takes as input factors of the patient, such as: (1) Clinical attributes (based on patient records and / or responses to questions, which may include comorbidities); (2) Age, ·(3) Geography; · (4) medical history (this may include current and past treatments);

[0149] Based on this information, the system defines "distance scores" between various patients. Examples of methods for calculating distance scores include weighted averages of individual parameters such as disease subtype, demographic characteristics, medical history, age, and / or the like. In at least one embodiment, weighting can be determined based on patient preferences. Alternatively, distance scores can be calculated by first identifying scoring variables using principal component analysis and then averaging the values ​​of each variable for each individual patient. Alternatively, other approaches can be used.

[0150] Using the distance threshold, the system searches for outcome data from similar patients and displays such data to the user. This information can then be used to rank treatments. Examples of outcome data include, but are not limited to, clinical outcomes such as disease progression and overall survival, side effects and toxicities such as neutropenia and fatigue, quality of life outcomes such as ability to attend work, sexual health, and impact on weight.

[0151] 7A, an example of a user interface screen 7001 for applying outcome filters to find treatments is shown. A user can select from various filters 7001A to apply and then tap button 7001B to view the results. Screen 7002 displays results 7002B and an indication 7002A of how many filters were applied. Each result 7002B can be opened to view additional information 7002C.

[0152] Referring now to FIG. 7B , an example of a user interface screen 7003 for presenting a visualization of patient outcomes for a particular treatment is shown, including a bar graph 7003B depicting overall survival 7003A and tumor shrinkage statistics. Each bar in graph 7003B represents one patient. In at least one embodiment, a user can tap a bar in graph 7003B to activate screen 7004, which displays additional details 7004A about the patient represented by that bar. In at least one embodiment, a social profile can be anonymously drawn, as shown in screen 7004. In at least one embodiment, a user can tap button 7004B to request to be informally matched with another patient for anonymous communication. For example, a notification and email request can be sent to the appropriate patient, including anonymous information about the patient requesting connection and their treatment progress. Button 7004C can be used to display the user's own symptoms and outcomes.

[0153] Referring now to FIG. 7C, examples of user interface screens 7005, 7006, 7007 for presenting medication-level outcome data are shown, according to one embodiment.

[0154] Determining out-of-pocket costs for treatment Traditionally, doctors, nurses, and other members of the healthcare team often do not know how much patients will have to pay for their treatment, resulting in many patients starting a course of treatment only to be saddled with high medical bills.

[0155] In at least one embodiment, the described system provides information and tools to enable important discussions about treatment costs. Specifically, tools are provided to streamline the calculation of a patient's out-of-pocket costs for treatment. Patient data is retrieved directly from healthcare systems and automatically analyzed. Examples of patient data include, but are not limited to, electronic medical records, genomic information, claims records, medical benefit and health plan structures, geographic location, designated pharmacies, diagnostic tests, and the like. Examples of healthcare systems include, but are not limited to, hospital systems, clinics, payer systems, diagnostic companies, and clinical laboratories. In at least one embodiment, the system, with patient consent, automates the process of automatically retrieving data from providers and insurance information (including benefit expenditure data) from insurance companies. The retrieved data is read and analyzed to determine treatment options. The treatments, along with the treatment data and medical benefit information, are then automatically provided to a cost calculator to determine the out-of-pocket costs for each treatment. Treatment options can then be displayed to the patient along with estimated out-of-pocket costs.

[0156] In at least one embodiment, the system performs cost calculations by looking up the patient's medical benefits (based on the patient's electronic authentication), including details such as out-of-pocket costs and how much of that deductible has already been spent in a given year. Various treatment options are then analyzed, and pharmacy costs are taken into account based on the patient's preferred pharmacy (such as a pharmacy in the patient's neighborhood or one used for previous orders). Out-of-pocket costs are calculated automatically and provided directly to the patient.

[0157] In at least one embodiment, the cost data is determined on an individual basis, taking into account information about how much of a patient's prescription drugs are being used, the patient's benefit plan, their out-of-pocket maximum, and / or the like.

[0158] In at least one embodiment, the treatments are automatically ranked based on calculated out-of-pocket costs, although in other embodiments, other factors may be considered when performing the automatic ranking.

[0159] Referring now to FIG. 8, an example of screen 8001 of a user interface for presenting treatment options categorized by cost and presenting personalized treatment details, including patient costs by benefit, is shown. These may differ from overall costs and may depend on the patient's health insurance plan as well as how much of that plan the patient has already spent. Screen 8002 displays details of the treatment options, including estimated costs. Screen 8003 displays additional details of the user's estimated out-of-pocket costs for the treatment options.

[0160] Informal query of disease-based social networks In at least one embodiment, the described system provides a mechanism for patients to be automatically and informally matched with other patients identified as having similar characteristics and / or diseases, and for such patients to interact with each other in a closed, informal social network. The system enhances patient anonymity.

[0161] In at least one embodiment, a social matching system based on disease attributes and personal preferences is implemented, allowing patients to be informally matched with other patients based on specific diseases, medical history and treatment plans, social, geographic, outcomes, and / or other characteristics, including personal preferences such as age, relationship status, ages of children, and / or the like. User-initiated informal social networks can then be automatically created. In at least one embodiment, patient profiles are automatically verified based on patient data retrieved directly from the healthcare system.

[0162] In at least one embodiment, an anonymization algorithm is provided to allow matching to occur informally before information is revealed. The algorithm removes all patient identifiers from patient profiles (in accordance with HIPAA requirements and / or other local healthcare privacy regulations) and provides patient ID and other attributes. This allows patients to be matched and communicate in an informal, encrypted setting without revealing their identities, while ensuring that various patient profiles are verified based on medical records and / or other third-party verified healthcare information. In another embodiment, patients can remain anonymous within the informal network, so their identities are never revealed.

[0163] As discussed above, the right side of FIG. 7B depicts an example of an anonymous patient social profile, according to one embodiment.

[0164] Those skilled in the art will recognize that the depicted screens, interfaces, and layouts are merely exemplary and that the techniques described herein can be implemented using other arrangements and contexts. Although the depicted screens, interfaces, and layouts are presented in a format primarily for use by patients, the user interface can be adapted for use by other individuals, such as healthcare professionals, administrators, and / or the like.

[0165] The present system and method have been described in particular detail with respect to contemplated embodiments. Those skilled in the art will appreciate that the system and method may be practiced in other embodiments. First, the specific naming of components, terminology capitalization, attributes, data structures, or any other programming or structural aspects are not required or important, and mechanisms and / or functions may differ in name, format, or protocol. Furthermore, the system may be implemented via a combination of hardware and software, entirely within hardware elements, or entirely within software elements. Also, the specific division of functionality among various system components described herein is merely exemplary and not required; functions performed by a single system component may instead be performed by multiple components, and functions performed by multiple components may instead be performed by a single component.

[0166] References herein to "one embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. The appearances of the phrases "in one embodiment" or "in at least one embodiment" in various places in the specification do not necessarily all refer to the same embodiment.

[0167] Various embodiments may include any number of systems and / or methods for performing the techniques described above, either alone or in any combination. Another embodiment includes a computer program product comprising a non-transitory computer-readable storage medium and computer program code encoded on the medium for causing a processor within a computing device or other electronic device to perform the techniques described above.

[0168] Some portions of the above may be presented in terms of algorithms and symbolic representations of operations on data bits within a computing device memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps (instructions) leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It may be convenient, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. Further, without loss of generality, it may be convenient to refer to specific arrangements of steps requiring physical manipulations of physical quantities as modules or code devices.

[0169] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless otherwise indicated, and as will be apparent from the following description, throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "displaying" or "determining" will be understood to refer to the acts and processes of a computer system or similar electronic computing module and / or device that manipulates and transforms data that are represented as physical (electronic) quantities in the computer system's memory or registers or other such information storage, transmission or display devices.

[0170] Certain aspects include process steps and instructions that may be described herein in the form of an algorithm and / or in other terms. It should be noted that the process steps and instructions may be embodied in software, firmware, and / or hardware, and that if embodied in software, may be downloadable to reside on and operate from different platforms used by various operating systems.

[0171] This document also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or may include a general-purpose computing device selectively activated or reconfigured by a computer program stored on the computing device. Such a computer program may be stored on a computer-readable storage medium, such as any type of disk, including, but not limited to, a floppy disk, optical disk, CD-ROM, DVD-ROM, magneto-optical disk, read-only memory (ROM), random-access memory (RAM), EPROM, EEPROM, flash memory, solid-state drive, magnetic or optical card, application-specific integrated circuit (ASIC), or any type of medium suitable for storing electronic instructions, each coupled to a computer system bus. Furthermore, the computing devices referred to herein may include a single processor or may be architectures employing multiple processor designs to increase computing power.

[0172] The algorithms, processes, and / or displays presented herein are not inherently related to any particular computing device, virtualization system, or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will be apparent from the description provided herein. Further, the systems and methods are not described with reference to any particular programming language. It will be understood that a variety of programming languages ​​can be used to implement the teachings described herein, and any references above to specific languages ​​are provided for the purpose of enabling and best mode disclosure.

[0173] Accordingly, various embodiments include software, hardware, and / or other elements, or a combination of any one or more thereof, for controlling a computer system, computing device, or other electronic device. Such electronic devices may include, for example, a processor, input devices (such as a keyboard, mouse, touchpad, trackpad, joystick, trackball, microphone, and / or any combination thereof), output devices (such as a screen, speaker, etc.), memory, long-term storage (such as magnetic storage, optical storage, etc.), and / or network connectivity, according to techniques well known in the art. Such electronic devices may be portable or non-portable. Examples of electronic devices that can be used to implement the described systems and methods include smart speakers, mobile phones, personal digital assistants, smartphones, kiosks, server computers, enterprise computing devices, desktop computers, laptop computers, tablet computers, consumer electronics products, etc. The electronic device may use any operating system such as, but not limited to, Linux, Microsoft Windows available from Microsoft Corporation, Redmond, Washington, Mac OS X available from Apple Inc., Cupertino, California, iOS available from Apple Inc., Cupertino, California, Android available from Google Inc., Mountain View, California, and / or any other operating system adapted for use on the device. In at least one embodiment, the system may be implemented using any suitable computing language, such as, for example, ReactNative.

[0174] While a limited number of embodiments have been described herein, those skilled in the art, having the benefit of the above description, will appreciate that other embodiments may be devised. Furthermore, it should be noted that the language used herein has been chosen primarily for ease of reading and instructional purposes, and may not be chosen to delineate or limit the subject matter. Accordingly, the present disclosure is intended to be illustrative, but not limiting, in scope.

Claims

1. 1. A computer-implemented method for providing personalized healthcare information and treatment recommendations, comprising: collecting, in a hardware processor, medical information relating to the patient; storing the collected medical information in a storage device; retrieving, in said hardware processor, information describing a plurality of treatment options; filtering, in the hardware processor, the treatment options based on the collected medical information to generate a personalized list of treatment options for the patient; and displaying the personalized treatment options on an output device.

2. retrieving information describing the plurality of treatment options and filtering the treatment options is performed at a server; The method of claim 1 , wherein displaying the personalized treatment options comprises transmitting the personalized treatment options to a client device for display.

3. Collecting medical information about patients accessing records containing medical information of said patient; and 10. The method of claim 1, comprising at least one selected from the group consisting of: receiving user input in response to a questionnaire, the user input including the medical information.

4. The method of claim 1 , wherein filtering the treatment options includes determining which treatment options are optimal given the collected medical information.

5. 10. The method of claim 1, wherein filtering the treatment options comprises applying a personalization engine to determine which treatment options are optimal given the collected medical information.

6. 1. A non-transitory computer-readable medium for providing personalized healthcare information and treatment recommendations, which, when executed by a hardware processor, comprises: collecting medical information about the patient; storing the collected medical information in a storage device; retrieving information describing multiple treatment options; filtering the treatment options based on the collected medical information to generate a personalized list of treatment options for the patient; and causing an output device to display the personalized treatment options.

7. retrieving information describing the plurality of treatment options includes causing a server to retrieve information describing the plurality of treatment options; filtering the treatment options includes causing a server to filter the treatment options; The non-transitory computer-readable medium of claim 6 , wherein the output device is in a client device.

8. Collecting medical information about patients accessing records containing medical information of said patient; and 7. The non-transitory computer-readable medium of claim 6, comprising at least one selected from the group consisting of: receiving user input responsive to a questionnaire, the user input including the medical information.

9. 7. The non-transitory computer-readable medium of claim 6, wherein filtering the treatment options comprises determining which treatment options are optimal given the collected medical information.

10. 7. The non-transitory computer-readable medium of claim 6, wherein filtering the treatment options comprises applying a personalization engine to determine which treatment options are optimal given the collected medical information.

11. 1. A system for providing personalized healthcare information and treatment recommendations, comprising: A hardware processor, Collecting medical information about patients; Searching for information that explains multiple treatment options; filtering the treatment options based on the collected medical information to generate a personalized list of treatment options for the patient; and a storage device communicatively coupled to the hardware processor, the storage device configured to store the collected medical information; an output device, communicatively coupled to the hardware processor and configured to display the personalized treatment options.

12. the hardware processor is in a server; The system of claim 11 , wherein the output device is on a client device.

13. further comprising a user input device communicatively coupled to the hardware processor and configured to receive user input in response to a questionnaire, the user input including medical information; The system of claim 11 , wherein collecting medical information about the patient includes receiving the user input in response to the questionnaire.

14. The system of claim 11 , wherein collecting medical information about a patient includes accessing records containing the patient's medical information.

15. The system of claim 11 , wherein filtering the treatment options includes determining which treatment options are optimal given the collected medical information.

16. 12. The system of claim 11, wherein filtering the treatment options includes applying a personalization engine to determine which treatment options are optimal given the collected medical information.

Images