Code generator for accessing different health recording systems

Abstract

Techniques are disclosed for enabling a user with little or no coding experience to build and configure a user-customized software application configured to extract, process and display information associated with a user-selected health record or portion of a health record. The techniques may include, for example, receiving a selection of a first resource defined by a first EHR system, analyzing metadata associated with the first resource to identify a first set of characteristics corresponding to the first resource, identifying a configuration bar associated with the first resource based on the first set of characteristics, in one embodiment, a configuration bar associated with a first resource is presented, a configuration value for the configuration bar is received, and code for executing an API call to extract data associated with the first resource according to the configuration value and for presenting the data associated with the first resource is generated.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to computer-implemented techniques for accessing information stored in health records. In particular, the present disclosure relates to an application that is constructed and customized to extract, process, and display information associated with a user-selected health record. BACKGROUND

[0002] Applications generally include a large amount of code that can be executed in association with a computer program or routine and that is configured to perform various actions and operations. As is well known, applications can provide access to and management operations on databases or can generate and play media. Applications can operate as standalone functions or in conjunction with additional applications. Applications can be executed on hardware, such as desktop computers, tablets, and telephones, via virtual processors and / or distributed processors.

[0003] An application, once initiated, can display or cause to be displayed a user interface, such as a graphical user interface (GUI), locally or remotely, for presenting information to a local or remote user and can receive input from the user via the GUI based on the user’s interaction with the presented information. The input from the user can indicate an operation to be performed, such as storing information into or retrieving information from a database. The database can contain an electronic health record (HER) system stored at a healthcare provider facility’s EHR. The healthcare provider facility can include, for example, a clinic or a hospital. However, the types of access (e.g., types of information) and options for processing information in the database are often limited with respect to the user’s needs or are not optimal. BRIEF DESCRIPTION OF DRAWINGS

[0004] Embodiments of the present disclosure are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings. It should be noted that references to “an” or “one” embodiment of this disclosure in the present disclosure are not necessarily to the same embodiment and do not necessarily refer to the same aspect. In the appended figures:

[0005] FIG. 1A and FIG. 1B illustrates an operating environment in accordance with one or more embodiments of the present disclosure;

[0006] FIG. 2 illustrates an example set of operations for enabling a user to construct a custom application to access user-selected information associated with records of one or more EHR systems in accordance with one or more embodiments of the present disclosure;

[0007] FIGS. 3A-3CExample user interfaces for directing and receiving information related to user preferences from a user device are depicted for building custom applications configured to access, process, and present data associated with one or more healthcare provider facilities or EHR systems;

[0008] FIG. 3D Example displays presented on a user device during execution of a custom application are depicted; and

[0009] FIG. 4 A block diagram is illustrated that includes a computer system in accordance with one or more embodiments of the present disclosure. DETAILED DESCRIPTION

[0010] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. One or more embodiments of the present disclosure can be practiced without these specific details. Features described in one embodiment of the present disclosure can be combined with features described in another embodiment of the present disclosure. In some examples, well-known structures and devices are described with reference to a block diagram form in order to avoid unnecessarily obscuring the present invention.

[0011] 1. OVERALL SUMMARY

[0012] 2. ELECTRONIC HEALTH RECORD SYSTEM

[0013] 3. DATA EXTRACTION SYSTEM

[0014] 4. APP BUILDER FOR ACCESSING DIFFERENT HEALTH RECORD SYSTEMS

[0015] 5. EXAMPLE EMBODIMENTS

[0016] 6. COMPUTER NETWORK AND CLOUD NETWORK

[0017] 7. MICROSERVICES APPLICATION

[0018] 8. HARDWARE OVERVIEW

[0019] 9. MISCELLANEOUS; EXTENSIONS

[0020] 1. OVERALL SUMMARY

[0021] One or more embodiments generate code for extracting and presenting data associated with resources defined by an electronic health record (EHR) system. The system can present an interface with candidate data extraction targets and receive corresponding user input. As an example, the system accepts, via the interface, as user input a selection of an EHR system(s) and a selection of resources defined by the selected EHR system(s) for which to extract data. The system can also accept user input including configuration values for configuring extraction of the resources and / or presentation of extracted data corresponding to the resources. Based on the user input, the system generates and executes code incorporating application programming interface (API) calls and corresponding parameters to extract data from the EHR system(s). Display of the extracted data can include information for the resources / columns selected by the user.

[0022] One or more embodiments customize and build software applications configured to extract, process, and display information associated with EHRs for users with little or no coding experience. The system customizes and builds the software applications based on user input defining data to extract and / or defining properties of presentation of the extracted data.

[0023] One or more embodiments of the disclosure described in this specification and / or

[0024] 2. Electronic Health Record System

[0025] Different medical health provider facilities typically use and maintain different respective EHR systems. Data associated with an EHR system can include information within a patient’s medical record of the EHR system. This data is typically stored in a non-standardized format relative to data stored in other EHR systems associated with other medical health provider facilities. Additionally, each EHR system can be associated with a corresponding application programming interface (API) that is different from the API for other EHR systems. An application configured to extract data based on the data format and API of a particular EHR system can not be able to extract data from other EHR systems. Alternatively or additionally, the application can not have access to sufficient information from other EHR systems. Accordingly, different applications and / or different sets of code can need to be generated to access data from different respective EHR systems.

[0026] Given these issues, healthcare providers are continuously seeking improved tools that include functionality for extracting data from disparate sources, such as different EHR systems. Combined datasets from disparate sources can be useful for healthcare providers offering continuous care to individuals across multiple healthcare provider facilities. For example, a healthcare provider might want to view five blood test parameters of an individual associated with a patient's medical record graphically. However, applications may allow viewing different numbers or types of blood test parameters associated with a patient. Therefore, healthcare providers may be prevented from viewing data or information associated with data that corresponds to the data that the healthcare provider deems most important for the intended use of the data by the healthcare provider. Furthermore, because different EHR systems inevitably use different standards or formats for their patient medical record data, interoperability regarding the ability of applications to access different patient medical records at different healthcare providers is often insufficient.

[0027] 3. Data Extraction System

[0028] FIG. 1A An example of an operating environment suitable for practicing embodiments of this disclosure is illustrated. The example computing system includes a combination of hardware and software elements for compiling and running implementations of application builder 106. Application builder 106 may execute on, for example, a computing system, user device 102, or EHR system 108 to create custom applications. This enables custom applications, which may execute on, for example, the computing system, user device 102, or EHR system 108, to access stored data according to personalized, user-specified criteria selected during the creation of the custom application. FIG. 1A In the example embodiment of this disclosure shown, operating environment 100 enables the construction and execution of such a custom application using elements of operating environment 100, which includes user device 102 that is communicatively coupled to application builder 106 and one or more healthcare provider facilities or patient medical record databases (such as EHR system 108 and EHR system 110) via networking means (e.g., network 104).

[0029] The depicted operating environment 100 includes a user device 102 capable of implementing a clinician user interface, which is communicatively coupled via a network 104 to one or more of EHR systems 108 and 110. Additionally, some embodiments of the user device 102 are contemplated to be directly communicatively coupled to, for example, EHR system 108, EHR system 110, or application builder 106.

[0030] Embodiments of user equipment 102 may take the form of a mobile communication device or client computer that includes a user interface operated by a software application or a collection of applications. User equipment 102 may include a physical device that executes any one or both of an application or a virtual machine. Examples of user equipment 102 include computers, tablets, laptops, desktops, netbooks, smartwatches, wearable smart devices, fitness trackers, servers, web servers, network policy servers, proxy servers, general-purpose machines, function-specific hardware devices, hardware routers, hardware switches, hardware firewalls, hardware network address translators (NAT), hardware load balancers, and mainframes. Further examples of user equipment 102 may include televisions, content receivers, set-top boxes, printers, mobile phones, smartphones, personal digital assistants (PDAs), wireless receivers and / or transmitters, base stations or access points, communication management devices, controllers, and / or client devices. In the typical embodiments described herein, user equipment 102 includes web-based applications or a collection of applications that can be used to build custom applications and manage other user services provided by embodiments of this disclosure.

[0031] The operating environment 100 according to this disclosure may have other arrangements, which are not necessarily described herein or illustrated in the examples, but will be considered by those skilled in the art as possible modifications or extensions. Other arrangements and elements (e.g., machines, user interfaces, functions, sequences, and groupings of functions) may be used in addition to or instead of the arrangements and elements shown or described, and some elements may be omitted entirely. Furthermore, many of the elements described herein are functional entities that can be implemented as discrete or distributed components or modules or combined with other components or modules (e.g., internally therein), and implemented in any suitable combination and location. The various functions described herein as being performed by one or more components or modules can be performed by hardware, firmware, and / or software. For example, various functions can be performed by a processor executing instructions stored in memory. Moreover, within the scope of this disclosure, FIG. 1A Any number of components shown may be used as part of or communicate with the operating environment 100. Each component may be implemented via a single device or multiple devices cooperating in a distributed environment. Furthermore, other components not shown may be included within the operating environment 100.

[0032] In the embodiments shown in this disclosure, user equipment 102 is communicatively coupled via network 104 to each of the following: authorization server 112, Fast Healthcare Interoperability Resource (FHIR) device (such as FHIR server 114), application / index module 116 which can correspond to a custom application to be created, and application launcher 118. Furthermore, as FIG. 1A As shown, application builder 106 may be communicatively coupled to or include the following references.FIG. 1B The data storage library 120 is described.

[0033] Network 104 may include, but is not limited to, one or more local area networks (LANs) and / or wide area networks (WANs). Such networking environments are common in clinics, hospitals, offices, enterprise computer networks, intranets, and the Internet. In exemplary embodiments of this disclosure, such networks include the Internet and / or cellular networks, as well as any of a variety of possible public and / or private networks. According to embodiments, any one of user equipment 102, application builder 106, EHR system 108, EHR system 110, authorization server 112, FHIR server 114, application / indexing module 116, and application launcher 118 may communicate with, for example, any other of user equipment 102, application builder 106, EHR system 108, EHR system 110, authorization server 112, FHIR server 114, application / indexing module 116, application launcher 118, and / or data repository 120, for example via application builder 106.

[0034] Application builder 106 may be included in computing systems (such as computer system 400). FIG. 4 The computing system is configured to be communicatively coupled to or associated with a user device 102, an EHR system 108, an EHR system 110, an authorization server 112, an FHIR server 114, an application / indexing module 116, an application launcher 118, and / or a data repository 120 (e.g., via an application builder 106) via network 104. The computing system includes one or more processors operable to receive and process instructions accordingly, and can be implemented as a single computing device or multiple computing devices communicatively coupled to each other. In one embodiment, the processing actions performed by the computing system are distributed across multiple locations, such as one or more local clients and one or more remote servers. In one embodiment, the computing system includes one or more computing devices, such as desktop computers, laptop computers, tablets, cloud computing devices, distributed computing architectures, super mobile PCs, or mobile phones. In some embodiments, the computing system includes an adaptive multi-agent operating system; however, it will be appreciated that the computing system may also take the form of an adaptive single-agent system or an agentless system. The computing system may include or operate in association with a distributed computing system, a distributed or centralized computing system, and / or a virtual computing system.

[0035] Implementations of the computing system include a collection of modules or components, such as a computer software stack. This collection of modules or components can facilitate the creation of custom applications capable of communicating with one or more of EHR systems 108 and 110 according to industry-known or published standards or protocols. One or more of the following—authorization server 112, FHIR server 114, application / index module 116, application initiator 118, and / or data repository 120—may be operable to enable the creation of custom applications via application builder 106, which are configured to operate or provide functionality in accordance with the aforementioned standards, protocols, and interoperability standards (such as those that can be provided by alternative medical applications, reusable technology (SMART), FHIR, and / or SMART indications or requirements on the FHIR). Additionally, the license server 112, FHIR server 114, application / index module 116, application launcher 118, and / or data repository 120 may operate in conjunction with one or more of the license server 112, FHIR server 114, application / index module 116, and / or application launcher 118, or may be operable to construct a custom application that can operate with or provide functionality compatible with one or more of the license server 112, FHIR server 114, application / index module 116, and / or application launcher 118. The application / index module 116 may be associated with, or include, addresses or code associated with the custom application.

[0036] In the illustrated embodiment, the collection (e.g., a stack) is included in or controlled by the application builder 106 as a component or module stack, for example, operating as a distributed system on the virtualization layer of the computing system. The stack may include, but is not limited to, one or more of the application user interface layout module 122, resource / parameter selection module 124, calculator-configuration module 126, licensing engine 128, and code generator 130. In some embodiments, one or more of the user interface layout module 122, resource / parameter selection module 124, calculator-configuration module 126, licensing engine 128, and code generator 130 may include distinctly different components, or may include components that are part of or within other components of the application builder 106 and / or operating environment 100. For example, one or more, or a portion of, the user interface layout module 122, resource / parameter selection module 124, calculator-configuration module 126, licensing engine 128, and code generator 130 may be implemented in the user device 102. Similarly, one or more of the following components or modules may perform the functions of two or more of the other components or modules referenced in the description of the operating environment 100: user interface layout module 122, resource / parameter selection module 124, calculator-configuration module 126, licensing engine 128, or code generator 130.

[0037] Embodiments of the user interface layout module 122, resource / parameter selection module 124, calculator-configuration module 126, licensing engine 128, and code generator 130 include one or more data repositories of the information described herein. Additionally, each of the user interface layout module 122, resource / parameter selection module 124, calculator-configuration module 126, licensing engine 128, and code generator 130 may also include one or more processors or associated with them for performing the various functions described herein. In some embodiments, the user interface layout module 122, resource / parameter selection module 124, calculator-configuration module 126, licensing engine 128, or code generator 130 may be implemented as a cloud-based platform or may be distributed across multiple physical locations.

[0038] The execution of Application Builder 106 can be initiated based on signals such as input received from user device 102 operated by a healthcare provider. Application Builder 106 develops / creates custom applications with minimal code writing or extension required by the healthcare provider or user. Custom applications access specific information sought by the healthcare provider, information at a healthcare provider facility or a specific EHR system (such as EHR system 108), or data fields of a patient's medical records. Custom applications also access specific information selected by the user at another healthcare provider facility or a specific EHR system (such as EHR system 110).

[0039] Application Builder 106 can receive, access, configure, and / or execute inputs associated with Application Builder 106 via Network 104 to create a custom application. Inputs may include signals from User Device 102 controlled by a user interacting with a user interface presented via Application Builder 106 at User Device 102. One or more inputs to Application Builder 106 may be received during the creation of the custom application. As described herein, once created, the custom application can access data stored at one or more locations within a specific healthcare provider facility or a specific EHR system. The stored data can be accessed according to the interoperability standards mentioned above and according to user-identified resources and resource parameters specified based on the inputs from Application Builder 106. For example, SMART can standardize the processes by which a custom application can access a specific data repository and extract clinical information from the data repository. The data repository may be implemented by a healthcare provider facility and / or within a specific EHR system. As used herein, SMART on an FHIR can define a workflow that a custom application can use to securely request access to data, then receive and use that data. Furthermore, as described and referenced in this article, SMART on FHIR can provide a standard, general API for custom applications to access, for example, electronic health information (EHI) at a specific data repository.

[0040] Operating environment 100 may include any number of EHR systems, such as EHR system 108 and EHR system 110. EHR systems as mentioned herein may include hospital EHR systems, outpatient EHR systems, health plan EHR systems, or home monitor / patient monitor EHR systems communicatively coupled to network 104, or associated with them. In embodiments of this disclosure, EHR systems may include Health Information Exchange (HIE), patient portals, government databases, pharmacy databases, or any other system capable of storing, receiving, transmitting, etc., records or any health-related data.

[0041] Content available within an EHR system can include records of individual treatment events, medication history, diagnoses, problems, allergies, demographic attributes, Seizure Record Summary (SOEN), Clinical Documentation Architecture (CDA) documents, laboratory tests or results, time and data information, images, clinical records, appointment records, emergency contact information, any kind of clinical documentation, and any other health-related data, or any combination thereof. Different EHR systems can be distinctly different sources, or in other words, can be associated with different entities. For example, EHR system 108 could be associated with a hospital in Pennsylvania, while EHR system 110 could be associated with a pharmacy in Florida that is not associated with the source EHR system 110. Because EHR systems are distinctly different sources contained within and operated by different entities, different EHR systems can utilize different standards or formats, such as JavaScript Object Notation (JSON), Extensible Markup Language (XML), YAML Markup Language (YAML), Health Level 7 (HL7), and Cascaded Clinical Documentation Architecture (CCDA). Furthermore, while this document describes an EHR system as a single source (e.g., a single database), any EHR system may each include multiple data repositories, each associated with one or more different entities. Those skilled in the art will understand that an EHR system can take many forms, be represented as multiple components, and communicate with any number of other sources.

[0042] Implementations of an EHR system may include a data repository for health records, computers or servers facilitating the storage and retrieval of health records, and firewalls (e.g., a separate firewall associated with each EHR system). Furthermore, in some embodiments of this disclosure, one or more EHR systems may be implemented as a cloud-based platform or may be distributed across multiple physical locations. In some embodiments of this disclosure, one or more EHR systems include a recording system for storing real-time or near-real-time patient information, such as information associated with wearable, bedside, or home patient monitors.

[0043] Further, it is anticipated that embodiments of the EHR system will use distinctly different clinical ontologies, nomenclatures, vocabularies, or encoding schemes for clinical information or terminology. For example, the EHR of EHR system 108 may belong to a hospital system using a different nomenclature. Meanwhile, the EHR of EHR system 110 may belong to another hospital system using a different nomenclature. Similarly, EHR system 108, located locally relative to caregivers, patients, or clinicians on user device 102, may use one clinical nomenclature, while EHR system 110, located remotely relative to caregivers, patients, or clinicians on user device 102, may use a different nomenclature. Additionally, in some embodiments, EHR system 108 and EHR system 110 may belong to two or more separate healthcare entities using two or more distinct nomenclatures. Although FIG. 1A Several example EHR systems are described, but it is anticipated that some embodiments may employ only one EHR system, or alternatively, may rely on a clinician user interface for storing or retrieving patient record information in a single data repository, in data storage 120, and / or at distributed locations.

[0044] Go to FIG. 1B Data repository 120 according to one or more embodiments of this disclosure includes any type of storage unit and / or device (e.g., file system, database, collection of tables, or any other storage facility) for storing data, such as patient data, related to a clinic, hospital, or healthcare provider associated with the clinic or hospital. Additionally, data repository 120 may include multiple different storage units and / or devices; these multiple different storage units and / or devices may or may not be of the same type or located in the same physical location. Furthermore, data repository 120 may be implemented or executed by a computing system (e.g., a system that includes application builder 106). Alternatively, or additionally, data repository 120 may be implemented or executed on a system separate from application builder 106. In some embodiments, data repository 120 is populated with, or accesses information from, various sources and / or systems.

[0045] like FIG. 1BAs shown, data repository 120 can store or access data such as: EHR data 132, resource data 134, metadata 136, historical data 138, resource parameter data 140, configuration bar data 142, configuration value data 144, code data 146 (e.g., code associated with API calls or building custom applications), and machine learning (ML) model data 148. As used herein, EHR data 132 can refer to a systematic collection of patient or population health information stored electronically in digital format. EHR data 132 can include data associated with or used in conjunction with an EHR system (e.g., created, written, or accessed); EHR data includes multiple EHRs. As used herein, resource data 134 can include categories of healthcare data or categories describing healthcare data. Resource data can include broad terms in or describing healthcare data, including: patients, laboratory results, and observations. Resource data 134 can include data used to define or describe data elements, constraints on data elements, and relationships between data elements that can collectively constitute an exchangeable electronic patient health record. As used herein, metadata 136 may include data that provides information about other data, such as data that describes and gives information about said other data. Metadata 136 can be used to provide structured references to other data, enabling the sorting and identification of attributes associated with other data.

[0046] As used herein, historical data 138 may include collected data on past events or circumstances relating to a specific topic (e.g., an event or resource). For example, historical data may include data collected in relation to one or more previous executions of application builder 106. As used herein, resource parameter data 140 may include data relating to, for example, the description, details, type, and purpose of a resource. For example, resource parameters for a “patient” resource may include “profile” and “extensions” according to the HL7 standard. In another example, resource parameters for a “patient” resource may include read-access permissions for the resource at a selected EHR system and / or write-access permissions for the resource at a selected EHR system. As used herein, configuration bar data 142 and configuration value data 144 may be associated with a user interface for enabling user selection and user configuration of user-selected resource parameters, for example, for use in a custom application. For example, configuration bar data 142 and configuration value data 144 may be used to enable user selection and user configuration input to define one or more user-selected resources, as described below in conjunction with operations 210-212 and user interface 310-user interface 330. As used herein, code data 146 may include information for creating or developing code as described herein, and may include the code itself.

[0047] Information stored in or by data store 120 can be structured. Structured data may include, for example, spreadsheets. Information can also be unstructured. Unstructured data may include, for example, conversational text or social media posts. Additionally, data store 120 can store or access information including, or related to, variables associated with, patient symptoms or recommendations, recommendation or other knowledge bases, and recommendation rules or other rules. Furthermore, data store 120 can store or access information including, or related to, recommendation data, recommendation update statistics, operational data, association rule bases, agent bases, solvers, solver libraries, computer-usable instructions, patient-derived data, and healthcare provider information. Examples of operational data residing in, accessible by, or writable in data store 120 include events, frequent item sets (such as, for example, "X often occurs with Y"), and item set index information. Data store 120 is intended to store any information that can be stored in a computer storage device or system, such as user-derived data, computer-usable instructions, software applications, or other information. Information stored in data repository 120 can be implemented across any component, module, or element within operating environment 100. In the illustrated embodiment, for clarity and explanation, this information is shown and described as being stored or resided in association with data repository 120.

[0048] In a typical embodiment, data repository 120 collaborates with application builder 106, for example, enabling application builder 106 to create custom applications. For example, in conjunction with the aforementioned collaboration, information including one or more of EHR data 132, resource data 134, metadata 136, historical data 138, resource parameter data 140, configuration bar data 142, configuration value data 144, or code data 146 can be written to or read from the data repository. Data repository 120 can also collaborate with one or more custom applications after creation, for example, in conjunction with performing operations on one or more custom applications. For example, in conjunction with (one or more) custom applications, information including one or more of EHR data 132, resource data 134, metadata 136, resource parameter data 140, configuration value data 144, and code data 146 can be written to or read from the data repository.

[0049] In some embodiments, data repository 120 may collaborate with other components (e.g., directly or via application builder 106 or one or more of a custom application), for example, to enable the creation of a custom application or to perform operations with a custom application. Other components may include, for example, any one of authorization server 112, FHIR server 114, application / index module 116, or application launcher 118. As an example, collaboration with other components may write to or read from data repository 120 information including one or more of metadata 136, historical data 138, resource parameter data 140, code data 146, and ML model data 148. Collaboration with or by data repository 120, as used in this and previous paragraphs, may include: retrieving or enabling access to data, creating or enabling the creation of data, and writing or enabling data to be written at or by data repository 120. In some embodiments, data repository 120 is populated with information from various sources and / or systems.

[0050] Example operating environment 100 may include, for example, a clinician interface at user device 102, configured to facilitate communication between a user and one or more of EHR systems 108, EHR system 110, and application builder 106 via user-operated user device 102. Therefore, embodiments of user device 102 may take the form of a user interface (e.g., a clinician interface) operated by a software application or collection of applications on a client computing device (e.g., user device 102, such as a mobile communication device or a smartphone computing device). In one embodiment of this disclosure, the software application includes one manufactured by Cerner Corporation. Software. In one embodiment of this disclosure, the software application includes a web-based application or applet. The software application or applet may facilitate access to and receipt of information from a user or healthcare provider (e.g., via EHR system 108 or EHR system 110) regarding a specific patient or set of patients to whom processing and / or display of a dataset is to be performed, and access to application builder 106. In some embodiments of this disclosure, user device 102 facilitates receipt of patient orders from a clinician, such as those based on or associated with dataset processing. For example, user device 102 may display results associated with the user, indicating that a given patient may have or will have a specific condition.

[0051] In one or more embodiments of this disclosure, to recall, the operating environment 100 may include more than FIG. 1AThe components shown may be more or fewer than other components, implemented in software and / or hardware, either locally or remotely. Each component may be distributed across multiple applications and / or machines, and multiple components may be combined into one application and / or machine. Operations described with respect to one component may be performed alternatively by another component. Additional embodiments and / or examples related to computer networks are described in Section 6, hereinafter entitled “Computer Networks and Cloud Networks.” Application Builder 106 includes or facilitates a stack of functionality that provides Application Builder 106, including functionality for application (app) developers (e.g., SMART FHIR application developers) or those associated with them. One or more of the following—User Interface Layout Module 122, Resource / Parameter Selection Module 124, Calculator-Configuration Module 126, Licensing Engine 128, and Code Generator 130—may be implemented in a system separate from the computing system within the operating environment 100.

[0052] 3. Application builder for accessing different health record systems

[0053] refer to FIG. 1A Using the elements described above, Application Builder 106 can create and fully utilize custom applications (e.g., SMART FHIR applications) with little or no coding required from clinicians and non-technical hospital staff. According to a specific aspect of this disclosure, each custom application built via unique / specific user input to Application Builder 106 can reduce burnout by allowing healthcare providers to work with one or more EHR systems to have a contextualized, persistent clinical view and reducing the need to search for information across a wide variety of EHR systems across various healthcare provider facilities.

[0054] To create a custom application according to embodiments of this disclosure, the execution of the application builder 106 is initiated, for example, by a signal from user device 102 or another component including or accessing the application builder 106 and a display, such as via network 104. According to some embodiments, the application builder 106 may be downloaded to, for example, user device 102 for execution, or may be remotely executed by user device 102 via network 104. Alternatively, in some embodiments, a device including, for example, the application builder 106 and a display may access the application builder 106 in a more direct manner. In embodiments, the application builder 106 is a web-based application or applet.

[0055] Implementations of application builder 106 may include software applications, collections of applications, software agents, programs, modules, components, applications, routines, functions, or computer-executed services, and / or may be implemented using a Belief-Wish-Intent (BDI) software model. Implementations of application builder 106 may reside on the aforementioned computing system and / or on one or more servers in the cloud, or be distributed between the cloud and client computing devices (such as personal computers, laptops, smartphones, tablets, mobile computing devices, front-end terminals communicating with back-end computing systems, or one or more other computing devices).

[0056] In response to user device 102 executing application builder 106 based on user input to user device 102, application builder 106 may identify a specific healthcare provider facility or a specific EHR system associated with a healthcare provider facility to which the custom application to be created can interact. This identification may be based on default values ​​or settings, settings corresponding to previous uses of application builder 106, data associated with the user at user device 102, or information otherwise associated with the current execution of application builder 106 by user device 102. For example, application builder 106 may initiate the display of a user interface (e.g., a GUI) on user device 102, and to enable user input, the user interface may present elements such as icons (e.g., buttons or thumbnail images), text, symbols, other items or images, graphics, patterns, or drop-down menus. These elements can be configured to allow input (e.g., via user device 102) into data fields or selections within data items (e.g., associated with or stored in a database such as a data repository at an EHR system) for analysis or other processing by application builder 106 and / or custom applications created by application builder 106.

[0057] FIG. 2 The illustrations depict a set of example operations performed by application builder 106 to create custom applications according to one or more embodiments of the present disclosure, requiring little or no user-written code. In one or more embodiments of the present disclosure, all or part of one or more operations may correspond to (e.g., be performed by) hardware and / or software configured to perform operations. FIG. 2 One or more operations shown can be modified, rearranged, or omitted entirely. Accordingly, FIG. 2 The specific order of operations shown should not be construed as limiting the scope of one or more embodiments of this disclosure.

[0058] In one or more embodiments, the system (e.g., application builder 106) receives user input for selecting a specific healthcare provider facility or specific EHR system from which a custom application to be created will extract data (operation 202). In the illustrated embodiments of this disclosure, application builder 106 initiates a display on user device 102, inviting the user to enter a selection of a specific healthcare provider facility or EHR system to be associated with (e.g., linked, identified, or otherwise communicated with) the custom application to be created. In some embodiments of this disclosure, application builder 106 may receive each user selection of a healthcare provider facility and / or EHR system from which the custom application will extract (or modify or add) data.

[0059] An application that enables a device to access information stored in EHR system 108 may fail to enable the device to access information stored in EHR system 110. The inability of an application to provide access to EHR system 110 may be an undesirable consequence of differences in format or other characteristics between EHR systems. Application Builder 106 may receive each user selection for healthcare provider facilities and / or EHR systems from which a custom application will extract (or modify or add) data, and may receive one or more additional user selections for one or more additional healthcare provider facilities and / or EHR systems from which a custom application will extract (or modify or add) data.

[0060] Before receiving user input selecting a specific healthcare provider facility or specific EHR system to associate with the custom application to be created (e.g., for data extraction), the user interface may present a first menu of displayed elements. In response to one or more selections (e.g., via selections from one or more dropdown lists associated with the first menu), the user interface may initiate the display of an additional menu of additional display elements recognized by the processor executing application builder 106 (e.g., at user device 102) based on the selections. In the illustrated example, the additional menus are associated with information selected by the user via the first menu.

[0061] Therefore, user input can be received by application builder 106 to select multiple healthcare provider facilities or EHR systems accessible to the custom application (operation 202). Recall that data at multiple healthcare provider facilities or EHR systems is often stored in various formats, rather than a standardized format. Generally, there is often no easy way to pull data from multiple EHR systems (e.g., retrieve data for processing) because each EHR system differs in its resources (i.e., patient medical record data), the formats of those resources, and so on. Embodiments of this disclosure recognize and take full advantage of the expectation that all EHR systems will soon be required to implement / release APIs that allow data extraction based on the FHIR standard issued by the standards development organization Health LevelSeven International (which also publishes the HL7 standard). This means that data extracted from various EHR systems using their corresponding APIs will be mapped to columns defined by the HL7 FHIR standard. For a given healthcare provider facility (e.g., a hospital), its on-site EHR system may not necessarily include data for all columns corresponding to the patient medical records (e.g., EHRs) at that healthcare provider facility; however, the data present in the patient medical records at that healthcare provider facility can be mapped to columns in the HL7 FHIR standard. The HL7 FHIR standard currently supports 145 resource types and is typically in a three-language format: XML, JSON, or the Concise Resource Description Framework (RDF).

[0062] Based on each selected healthcare provider facility or EHR system, application builder 106 initiates the determination of resources available for use in the custom application to be created (operation 204). Resources available for use in the custom application to be created will typically vary based on the specific healthcare provider facility or EHR system. In the illustrated example, available resources can be identified, for example, by analyzing metadata (e.g., attributes) corresponding to the selected healthcare provider facility or EHR system based on FHIR standards. This metadata can describe the specific resources available for use in the custom application to be created according to the HL7 FHIR standards. Here, each resource available at the selected healthcare provider facility or EHR system can correspond to a group of information that can be used to exchange or store data that satisfies most use cases in the clinical settings of the selected healthcare provider facility or EHR system.

[0063] In the example embodiments of this disclosure, analyzing metadata corresponding to a selected healthcare provider facility or EHR system identifies a resource "user" as an available resource. For example, according to HL7, a resource "user" or "practitioner" may encompass a person who is directly or indirectly involved in the provision of healthcare or healthcare-related services as part of his or her formal duties. This resource is used for attribution to activities and duties associated with individuals who may perform professions such as: physicians, dentists, pharmacists, physician assistants, nurses, scribes, midwives, dietitians, therapists, optometrists, nursing staff, medical technicians, laboratory scientists, prosthetic technicians, radiographers, social workers, professional home caregivers, official volunteers, receptionists handling patient registrations, or IT personnel merging or demerging patient records. Practitioners or users may play different roles within the same or different organizations or healthcare provider facilities. Depending on jurisdiction and practice, it may be necessary to maintain a specific resource for each such role, or to have a single resource with multiple roles (e.g., practitioner). Resources are not for individuals without formal responsibilities, such as caregiver friends or relatives; such individuals can be described by alternative resources, such as “related persons” resources, in terms of the extent to which they perform an action or are referenced by another resource. Concepts not included in the HL7 definition of a resource can be found in the HL7 definition or the resource parameters referenced, such as “patient’s contact person”.

[0064] Analyzing the metadata corresponding to the selected healthcare provider facility or EHR system can also identify the resource "Patient" as available. For example, according to the HL7 standard, the resource "Patient" can encompass demographic and administrative data of patients receiving care at a healthcare provider facility. The resource describes a wide range of patient health-related activities, including treatment activities, psychiatric care, social services, prenatal care, nursing and assisted living, dietary services, and tracking of personal health and exercise data. The data in this resource covers information about the "who" of the patient: its attributes focus on demographic information necessary to support administrative, financial, and logistical procedures. Note that patient medical records are generally created and maintained by each organization providing care to the patient; therefore, a patient receiving care from multiple healthcare providers or at multiple healthcare provider facilities may have his or her information present in multiple patient resources. Concepts not included in the HL7 definition of a "Patient" resource (such as race, ethnicity, organ donor identity, nationality in the current example) can be found in the associated resource or HL7-defined resource parameters (such as "profiles" or "extensions" used with or associated with the "Patient" resource).

[0065] Continuing with step 204, based on the resources identified through metadata analysis, application builder 106 can present the identified resources to the user for review, modification, or selection. For example, application builder 106 can initiate the display of the identified resources via a user interface that is part of or associated with a second menu for the user to review, modify, or select. For example, the second menu may include dropdown menus that display elements corresponding to all or some of the resources identified as available at the selected healthcare provider facility or EHR system for the user to select.

[0066] In one embodiment, application builder 106 receives one or more selections of resources presented by application builder 106 in a second menu of resources (these selections are determined based on analysis of metadata corresponding to the selected healthcare provider facility or EHR system) (operation 206). For example, application builder 106 receives selections of resources presented by application builder 106 in the second menu of resources via user interaction with a user interface.

[0067] Note that the current HL7 FHIR standard supports 145 resource types, and the list in the second menu can display subgroups of all resources identified as available for user selection. In an example embodiment of this disclosure, the resources(s) presented in the second menu correspond to a subset(s) of more general resources identified, for example, based on metadata from the total set of resources determined by application builder 106 at operation 204 as available at the selected healthcare provider facility or EHR system. The subset of resources may include one or more of practitioners (or users), patients, administrators, organizations, locations, coverage, and invoices. In embodiments of this disclosure, operation 206 includes application builder 106 receiving a selection from the subset of resources (presented by application builder 106 in the second menu of resources) via user interaction with the user interface.

[0068] Based on the user's selection from a subset of resources, and / or based on the selection of one or more healthcare provider facilities or EHR systems, application builder 106 can present the user with an additional menu containing additional resources identified as available for the selected healthcare provider facility or EHR system but not presented in the second menu. In the example, the subgroup of resources presented in the second menu includes three resources: Patient, Laboratory Results, and Insurance Claims, and the additional menu can be presented when only the first of these three resources is selected. This additional menu can also include three resources based on the user's selection of "Patient": Medication, Workflow, and Finance, each of which is related to "Patient" and can be selected via input to the user interface (e.g., input from user device 102 operated by the user). Therefore, application builder 106 can present the identified available resources in an iterative, sequential, or other multi-menu manner, and / or application builder 106 can receive selections for resource presentation in an iterative, sequential, or other multi-menu response manner.

[0069] One or more additional menus may be presented by the application builder 106 using a user interface to present additional resources, such as resources determined to be available for the custom application to be created based on menu selections made via an additional menu, a second menu, and / or a first menu, and / or based on analysis of metadata associated with the menu selections. These additional menus may present resources that are determined to be subclasses of one or more resources selected via a second menu or an additional menu, or resources that are more specific than one or more resources selected via a second menu or an additional menu. For example, additional menus may present additional resources that are determined to be available for the selected healthcare provider facility or EHR system but are not presented in the second menu or an additional menu.

[0070] In an example embodiment, resources corresponding to more generalized categories (such as patients, laboratory results, and one or more insurance claims, particularly determined by analyzing metadata) are presented in a second menu, and then additional resources are presented by the application builder 106, for example, in an additional menu, where the additional resources are also determined by analyzing metadata based on the selected healthcare provider facility or EHR system. Each resource in the additional menu may also be determined by analyzing metadata associated with one or more resources selected by the user via the second menu.

[0071] In example embodiments of this disclosure that include supplementary menus or additional menus, based on the resource "Patient" selected by the user via a second menu and optionally based on metadata associated with the "Patient" resource, the supplementary menu may present one or more resources for the user to select, for example, according to the HL7 standard, these one or more resources may come from the group including: clinical, diagnostic, pharmaceutical, workflow, or financial. Furthermore, based on the resource "Clinical" selected by the user via the second menu and optionally based on metadata associated with the "Clinical" resource, the supplementary menu may present one or more resources for the user to select, for example, according to the HL7 standard. These one or more resources may be selected from the group including: allergies / intolerances, symptoms (problems), procedures, family medical history, care plans, goals, care teams, clinical impressions, adverse events, detected problems, and risk assessments. Additionally, based on the resource "Diagnostics" selected by the user via the second menu and optionally based on metadata associated with the "Diagnostics" resource, the supplementary menu may present one or more resources for the user to select, for example, according to the HL7 standard, these one or more resources may come from the group including: observation, reports, specimens, imaging studies, genomics, and specimen and imaging studies.

[0072] Additionally, the resource "Medications" selected by the user via the second menu can cause the application builder 106 to present an additional menu to the user, for example, based on the selection of the "Medications" resource and optionally based on the metadata associated with the "Medications" resource. This menu, according to the HL7 standard, includes one or more resources from the following groups: Medications, Requests, Dispensing, Administration, Declarations, and Immunizations. Furthermore, based on the resource "Workflow" selected by the user via the second menu and optionally based on the metadata associated with the "Workflow" resource, the additional menu can present one or more resources from the following groups for the user to choose from, for example, according to the HL7 standard, these groups include: Introductions, Tasks, Appointments, Schedules, Referrals, and Plan Definitions. Moreover, based on the resource "Finance" selected by the user via the second menu and optionally based on the metadata associated with the "Finance" resource, the additional menu can present one or more resources from the following groups for the user to choose from, for example, according to the HL7 standard, these groups include: Claims, Accounts, Invoices, Items of Charge, Coverage, Eligibility, Requests, Responses, and Benefit Explanations.

[0073] At operation 208, based on the selection of one or more resources received at, for example, operation 206, application builder 106 identifies configurable resource parameters corresponding to each of the received selections of one or more resources. For example, application builder 106 analyzes metadata corresponding to each received resource selection to identify one or more corresponding configurable resource parameters for the selected resource. For example, a third menu may include a dropdown menu displaying elements corresponding to the configurable resource parameters available for the selected “Patient” resource for user selection. For example, the configurable resource parameters(s) for “Patient” may include one or more selections of read-access and / or write-access of data corresponding to the HL7FHIR resource “Patient” at the selected healthcare provider facility or EHR system.

[0074] In an embodiment, application builder 106 presents one or more configuration panes to provide users with corresponding selections for configuring configurable resource parameters (operation 210). These one or more configuration panes enable the selection of configuration operations that can be performed by or associated with the execution of the custom application to be created. Operations may include retrieving, modifying, or presenting one or more of the selected resources. Operations may be associated with retrieving, modifying, or presenting data related to: (a) the selected healthcare provider facility or EHR system; (b) the resource selected via any of a second menu, supplementary menu, or additional menu; and / or (c) details or options regarding the implementation of the configurable resource parameters identified in operation 208. In an example embodiment of this disclosure, for each configurable resource parameter identified in operation 208, application builder 106 presents one or more third menus, which are associated with configuration operations that can be performed by the custom application on or related to the selected resource. One or more third menus may display configuration options via a user interface, such as configuration options in the form of one or more third menus, such as one or more drop-down menus and one or more input text boxes that enable information input (e.g., via user device 102 operated by the user).

[0075] Application Builder 106 receives one or more inputs, such as selections (operation 212), corresponding to configuration values ​​of configurable resource parameters presented in a third menu of configurable resource parameters. Resource parameters include parameters determined by Application Builder 106 based on analysis of the received metadata corresponding to each resource selection to identify the corresponding one or more configurable resource parameters of the selected resource. For example, Application Builder 106 receives inputs indicating (e.g., specifying) configuration values ​​of configurable resource parameters presented in the third menu of resources via user interaction with a third menu displayed via a user interface.

[0076] Based on configuration values, application builder 106 generates code for retrieving, modifying, or presenting data associated with or derived from: (i) the selected healthcare provider facility and / or (ii) one or more selected EHR systems (operation 214). For example, code may be generated to enable the custom application to perform operations including retrieving, modifying, or presenting data associated with one or more selected healthcare provider facilities or EHR systems, and resources selected via a second menu, supplementary menu, or additional menu. Alternatively or additionally, code may be generated to enable the custom application to perform operations associated with configuration values ​​selected via a third menu and / or details or options regarding the implementation of configurable resource parameters and / or configuration values. All menus or subsets thereof (e.g., first menu, second menu, supplementary menu, additional menu, and third menu) or any part thereof may be presented in various combinations, simultaneously or at different times and / or in different arrangements, forms, or orders. In some embodiments, application builder 106 sends a link to user device 102 or to another device associated with creating a new custom application, the link identifying the URL of the newly created custom application, for example, by means of a Uniform Resource Locator (URL).

[0077] As described above, application builder 106 can provide functionality for app developers (e.g., SMART FHIR app developers) or those associated with them to create custom apps. Code generated by application builder 106 (e.g., accessing, modifying, and / or developing) can create or facilitate the creation of one or more custom apps or portions thereof. In embodiments, during the creation of one or more custom apps, application builder 106 can automatically generate code corresponding to required FHIR calls (e.g., based on the HL7 FHIR standard) to acquire / extract data during execution of the custom app. For example, based on selections made via input (e.g., from user device 102), code generator 130 in the illustrated example generates the required API calls (e.g., FHIR-based calls) to extract / retrieve and process user-selected data for display during subsequent execution of the custom app. Therefore, embodiments of this example can utilize a mapping to the FHIR concept as indicated or required.

[0078] Technologies and systems used to generate (e.g., access, modify, and / or develop) code that can facilitate the creation of custom applications may be based on, for example, known technologies or applications related to code generation, or modifications or extensions thereof. For example, technologies and systems used to generate code (e.g., for performing the extraction, modification, and presentation of EHR data as described in references 216-218 herein) to create custom applications may correspond to technologies and systems used in conjunction with or referenced in the Oracle Application Express (APEX) platform provided by Oracle Corporation, Redwood Shores, California. Other technologies and systems used to generate code to create custom applications may correspond to concepts and technologies known in the art, such as those in U.S. Patent No. 9,373,094 and the SMART platform on FHIR provided by the Computational Health Informatics Project at Boston Children's Hospital, Boston, Massachusetts. smarthealthit.org The concepts and techniques used or referenced in combination are all incorporated herein. The code generated by application developer 106 can configure a custom application to implement certain clinical information representations or operations associated with (e.g., defining) or related to data extracted in various ways (tables, summaries, and subsummaries) based on individual (e.g., unique) needs or objectives received by application builder 106 during the creation of the custom application.

[0079] The code used by the application builder to construct custom applications can be stored in or associated with one or more libraries, components, source files, and / or GUI controls (such as drag-and-drop GUI builders) of reusable resources, such as data repository 120. For example, source files that can be created, modified, stored, and retrieved may include files containing (e.g., as a starting point for processing the system) program instructions, source code, raw data, or basic data. In the example, a set of predefined codes is provided for each EHR system, and this set of codes is selected based on the chosen EHR system, for example, at operation 202. The set of codes may include API calls as described herein. One or more of the computing system, user device 102, EHR system 108, or another component may store the code associated with resource selection as variables, which the custom application uses as parameters for API calls once created. Additionally, one or more of the computing system, user device 102, EHR system 108, or another component may generate code combined with an authentication key to enable the custom application to access, for example, a healthcare provider facility or EHR system once created.

[0080] In one or more embodiments, the system executes code to extract data from a selected EHR system (operation 216). Additionally or alternatively, in some embodiments, the system executes code to extract and process data from a selected healthcare provider facility or EHR system. The execution of the code can be initiated by a signal indicating the opening (e.g., execution) of the custom application described herein. This signal may be received at or from a healthcare provider facility (e.g., from the healthcare provider's EHR system) or may be received from another location (e.g., at or from one or more of a computing system, user device 102, EHR system 108, or another component). For example, the signal may be generated in response to a double-click action performed via a pointing device on an image, icon, button, or text associated with (e.g., representing) the custom application. Based on user input received by the application builder 106 during the creation of the custom application, the custom application initiates operations such as API calls utilizing corresponding parameters during or associated with the execution of the generated code to extract data, for example, from one or more EHR systems. The API calls may correspond to standards or protocols associated with, for example, a SMART FHIR application. For example, see the SMART on the FHIR platform cited above. smarthealthit.org ).

[0081] In one or more embodiments, one or more of the computing system, user device 102, EHR system 108, or another component described herein present extracted data and optionally processed data associated with the extracted data (operation 218). Additionally or alternatively, in some embodiments, one or more of the computing system, user device 102, EHR system 108, or another component may present at least a portion of the extracted data or information indicating the extracted data, and may also present at least a portion of the processed data or information indicating the processed data. One or more of the computing system, user device 102, EHR system 108, or another component may present one or both of the extracted data and processed data in a default or user-selected display format or style (e.g., based on previous use by the user or device, historical data 138, ML model data 148, and one or more of ML, AI model data, neural network data, and adaptive agents).

[0082] Presentation (e.g., display) operations may be performed under or in conjunction with the control of a custom application being executed. In some embodiments, the presentation operation may be initiated or performed, or be initiated or performed by, one or more of a computing system, user device 102, EHR system 108, or another component, and may present at least a portion of the extracted data or information indicating the extracted data. Alternatively or additionally, the presentation operation may present at least a portion of processed data or information indicating the processed data. For example, the presentation operation may display data retrieved from or otherwise associated with a selected healthcare provider facility or EHR system, such as data extracted from one or both of EHR systems 108 and 110.

[0083] In an example embodiment, for instance, the presentation operation corresponding to operation 218 can display content based on user-selected parameters (such as page number, row number, and column number), for example, in combination with... FIG. 3D Example display 340 is shown and described. In example display 340, one or more user input fields (0,0) are defined for application developer 106 to present data from a selected healthcare provider facility or EHR system during execution by a custom application. This data is extracted and processed according to a user-defined "Fibrosis-4" calculator, for example, via... FIG. 3C The user interface is defined in 330.

[0084] The presentation operations in the example embodiments may also include user-defined columns (0,1), (1,0), and (1,1), configured to present data (extracted and processed from a selected healthcare provider facility or EHR system) based on, for example, user-defined additional calculators: “Observation | Vital Signs (BMI)”, “Medication Request”, and “Observation | Laboratory (Cretin)”, respectively. Additionally or alternatively, during the execution of a custom application, other calculators (e.g., routines), objects, or other defined processes (e.g., via user-operated user device 102) or acquired elsewhere may be presented. As an example, other routines, objects, or processes may correspond to (e.g., include) any application available to the user or that the user can use during the creation of the custom application. Such routines may include items or objects included or associated with the contents of this disclosure, such as algorithms, applications, BDI software models, components, components implemented as part of or contained within other components, computer-executed services, elements, functional entities, functions, ML algorithms, modules, operations, processes, processes corresponding to hardware, firmware, and / or software, programs, routines, agents, and supervised or unsupervised components.

[0085] In one or more embodiments of this disclosure, ML algorithms (e.g., based on or corresponding to ML model data 148 at data store 120) may be included in or made accessible to application builder 106 (e.g., via user interface 330) within a specific custom application being developed (created) by application builder 106. For example, an ML algorithm may be iteratively used to learn a target model f that optimally maps a set of input variables to output variables, for example, using a set of training data. For example, such an ML algorithm in the embodiments may be configured to generate / train an emergency care or emergency room model during the execution of a custom application. For example, training data stored at data store 120 along with ML model data 148 may include datasets and associated labels and associated codes. These datasets may then be associated with the input variables of the target model f, while the associated labels are associated with the output variables of the target model f during the execution of the custom application.

[0086] Training data can be updated, for example, during the execution of a custom application based on feedback regarding the accuracy of the current target model f. The updated training data (e.g., stored in data store 120 along with ML model data 148) can be fed back into the ML algorithm during the execution of the custom application, which in turn updates the target model f. The target model f can be applied to the training data dataset during the execution of the custom application, and the target model f can determine the maximum number of results matching the labels of the training data. Additionally, according to one aspect of this disclosure, the generated code corresponding to the target model f (e.g., configured to provide a best fit between the training data dataset and the labels of the training data) can be applied to the dataset corresponding to the training data to identify the desired dataset. Different target models can be generated based on different ML algorithms and / or different sets of training data.

[0087] As described in this paper, each ML algorithm may include supervised and / or unsupervised components. Various types of algorithms can be used, such as linear regression, logistic regression, linear discriminant analysis, classification and regression trees, Naive Bayes, k-nearest neighbors, learned vector quantization, support vector machines, bagging and random forests, boosting, backpropagation, and / or clustering.

[0088] FIG. 3D The illustration shows a sample display 340 presented to a user on user device 102 during the execution of a custom application created by application builder 106, for example, based on user interfaces 310, 320, and 330. This display is based on a user-customized calculator (e.g., “Fibrosis-4”), defined via user interface 320 and configured to allow processing of both user-selected extracted data and user-defined formulas corresponding to the “Fibrosis-4” calculator during the execution of the custom application. For example, display 340 includes user-defined charts, such as those defined via user interfaces 320 and 330, illustrating sample processing of information (e.g., data extracted from one or both of EHR systems 108 and 110) based on the user-defined “Fibrosis-4” calculator and operations 202-212. In an example embodiment, the “Fibrosis-4” calculator has been constructed, for example, via user interface 320 to implement the formula “(age*AST) / (platelets*√(ALT))” via code generated by application builder 106 (e.g., at operation 214).

[0089] Some embodiments of these methods facilitate decision-making by dynamically displaying user-relevant patient information during the execution of a custom application (e.g., created under user control via input from user device 102). User-relevant patient information may indicate, be related to, be extracted from, or be derived from one or more of the following: (i) EHR system 108, (ii) EHR system 110, (iii) data repository 120, (iv) other information, concepts, or knowledge derived from (i)-(iii), or (v) other items, such as information indicating patient symptoms or treatment recommendations. The electronic models, electronic adaptive agents, and / or electronic models including electronic adaptive agents described above can be used, for example, by means of techniques known to those skilled in the art (including data processing, data synthesis, and data learning techniques) to determine user-relevant patient information. For example, a clinician interface generated at user device 102 during the execution of a custom application can facilitate access to and receipt of information about a specific patient or set of patients, receiving information such as patient information, selections, queries, commands, or actions, and displaying results, recommendations, or medical orders. In some embodiments, the clinician interface facilitates the receipt of patient-specific medical orders from clinicians / users based on outcomes. In some embodiments, the clinician interface includes, for example, a GUI associated with or within the operation of a custom application described herein, configured to facilitate clinical decision support and / or provide diagnostic or updating services (such as creating, evaluating, or modifying condition programs, predictive models associated with health status programs, libraries, and / or tables of contents for agents). The GUI may be configured to facilitate human verification of computer-derived determinations, such as actions, recommendations, diagnoses, links, or other such services.

[0090] In embodiments of this disclosure, the EHR system 108 may, for example, conform to the FHIR as described above and be configured to map to one or more patient medical records associated with a specific hospital or with an HIE platform and related to immunization status. In some embodiments, the retrieval of resources corresponding to patient data artifacts associated with at least one patient record in the EHR system by a custom application may be performed via one or more of the models or adaptive agents described above (such as by applying ML and / or AI models to the information). As described above, the operations described herein may include executing a machine learning model, wherein the machine learning model is trained to identify a candidate set of resources for user selection during the execution of the application builder 106 and / or the execution of the custom application. Additionally, as described above, the operations performed during the execution of the custom application may include presenting information associated with the patient data artifact to obtain treatment guidance.

[0091] User-related information can correspond to the context of a treatment session (such as the role or specialty of a caregiver (e.g., cardiologist, urologist, social worker, etc.)) or to the treatment setting (such as a research hospital, walk-in clinic, emergency room, or one or more conditions or clinical decision support events associated with the patient). Accordingly, in some embodiments, the user-related information that can be presented via the execution of a particular custom application will vary, be flexible, or differ based on the choices made by a particular user during the execution of application builder 106 when creating the particular custom application and also based on the context of the particular execution of the particular custom application. For example, executing a custom application created for a cardiologist treating a heart attack patient in an emergency care or emergency room setting may cause specific types of patient information, such as patient vital signs, medications, and previous cardiac diagnoses, to be presented based on the custom application created for the cardiologist and based on the cardiologist's execution of the custom application. On the other hand, executing another custom application created for an endocrinologist treating diabetic patients in a research hospital may cause data to be presented based on another custom application associated with the endocrinologist's specific needs and based on the endocrinologist's specific execution of that other custom application. For example, the execution of this other custom application can enable the presentation of data associated with or as an adjunct to (enhancing) clinical studies in which the patient participates and the patient adheres to prescribed disease management protocols, such as data from one or both of EHR systems 108 and 110.

[0092] In some embodiments of this disclosure, software routines or software agents (e.g., electronic models, electronic adaptive agents, and / or electronic models including electronic adaptive agents) facilitate part or all of any one or more of operations 202-214, such as automatically adding information or user options to any one of user interfaces 310-330. In example embodiments, one or more software agents or software routines may, for example, automatically populate or configure displayed menus, displayed bars, or add text boxes (or drop-down menus) for additional information entry (or selection) based on the prior use of application builder 106 and / or based on the identity associated with the user or user device. In some embodiments of this disclosure, an "autocomplete" bar may be presented in association with one or more of user interfaces 310-330 to provide feedback to the user, such as indicating that either the user has provided all the information for a particular user interface (yes), or indicating that there is missing information or that the user has incorrectly presented a bar (e.g., entering a number or letter other than V / N in a bar that only requires "Y" or "N").

[0093] 4. Example Implementation

[0094] For clarity, detailed examples are described below. The components and / or operations described below should be understood as specific examples that may not be applicable to certain embodiments of this disclosure. Accordingly, the components and / or operations described below should not be construed as limiting the scope of any claim.

[0095] Currently, if clinicians using EHRs desire SMART-based software applications tailored to their specific workflows, they often have no choice but to request such applications from EHR system providers and expect the systems to be built or built promptly. Materializing this request can be extremely time-consuming, resource-intensive, difficult to integrate, and potentially significantly increase the cost of the user's intended workflow. This disclosure allows non-developers (clinicians) to define clinical information representations in various ways (tables, summaries, and sub-summaries) based on the user's individual (e.g., unique) needs or objectives through custom applications.

[0096] This disclosure allows users to create and store libraries of reusable resources, components, and GUI controls (such as drag-and-drop GUI builders) at data store 120, for example. For example, one or more of a computing system, user device 102, EHR system 108, or another component (e.g., associated with application builder 106 or data store 120) can (e.g., substantially, wholly, or partially) generate code for a custom application by developing function, routine, or specific API calls based on function, routine, or API calls stored in data store 120. In some embodiments, one or more of a computing system, user device 102, EHR system 108, or another component can generate code for a custom application, partially or wholly, by retrieving (and / or referencing) function, routine, or specific API calls stored in data store 120. During custom application development, embodiments of application builder 106, for example, automatically generate code corresponding to the required FHIR calls based on the HL7 FHIR standard to enable data acquisition during the execution of the custom application. Based on the user's selections, the code generator 130 of this disclosure generates the necessary API calls (e.g., FHIR calls) to retrieve and process the user-selected data for display during subsequent execution of the custom application. Therefore, embodiments of this disclosure utilize a mapping to the FHIR concept as instructed or required.

[0097] Brief Review FIGS. 3A-3CThe accompanying figure illustrates an example user interface for receiving information from a user regarding the operations, access, and parameter settings to be used in a custom application to be developed. Specifically, the figure depicts an example user interface for receiving, for example, user input and selections via user device 102, specifying preferences and details that will be included in the functionality and capabilities of the custom application being developed by application builder 106. Information input to the application builder via the user interface (e.g., which may include one or more, or any part thereof, a first menu, a second menu, supplementary menus, additional menus, and a third menu) enables the user to create a custom application with little or no user coding required. Once created, the custom application is configured to access, process, and present data associated with one or more specific healthcare provider facilities or specific EHR systems.

[0098] FIG. 3A An example user interface 310 is shown that can be presented after selecting (e.g., via user device 102 operated by the user) a specific healthcare provider facility or EHR system, including displayed options for the user to select resources and resource parameters for a custom application to be created. Based on (e.g., at operation 202) the received selection of a specific healthcare provider facility or EHR system and based on (e.g., at operation 204) analysis of metadata associated with that specific healthcare provider facility or EHR system to determine the resources available once the custom application is created, the application builder 106 can determine that resources including “user” resources and “patient” resources corresponding to the resources shown at the top of the user interface 310 can be presented. The user interface 310 can be viewed as including a second menu (see reference). FIG. 2 A combination or corresponding to the operation prior to operation 206 and the third menu (refer to operation 210), which is presented in a single display or, alternatively, in two consecutive displays, for example, in response to and based on metadata determined by application builder 106 to be associated with the selected healthcare provider facility or EHR system.

[0099] In the embodiments described in this disclosure, separate selection options, such as checkboxes, are not shown for the "User" resource and the "Patient" resource. Embodiments of this disclosure may present the user interface 310 as an additional menu (as discussed above) after presenting the second menu (as discussed above), resulting in the user selecting between the "User" resource and the "Patient" resource. In other embodiments of this disclosure, the default settings of the application builder 106 cause the initial user interface (e.g., with the second menu (refer to...)) to... FIG. 2In the operations preceding operation 206 and the third menu (as in operation 210), the two resources are presented based on the determination that the "user" resource and the "patient" resource are available for the selected healthcare provider facility or EHR system (e.g., as automatically selected resources).

[0100] FIG. 3B Another example user interface 320 is shown that can be presented after selecting (e.g., via user device 102 operated by the user) one or more specific healthcare provider facilities or EHR systems. User interface 320 presents user options (e.g., via user device 102 operated by the user) for selecting elements including “Resource Type” and “Resource Parameters”. Selecting a resource type from the “Resource Type” dropdown menu (e.g., based on metadata analysis by application builder 106, as discussed herein) causes application builder 106 to populate the “Resource Parameters” dropdown menu with specific resource parameters associated with the selected resource type, at least based on metadata associated with the selected resource type. Additionally, the “Select Operator” button and one or more “Formula” bars in user interface 320 allow the user to associate the selected resource type and resource parameters (e.g., collectively referred to as “Operants”) with formulas (e.g., based on the selected “Operator”) for processing and presentation (e.g., display) during execution of a custom application based on available data (in the selected healthcare provider facility or EHR system) corresponding to the selected resource and associated information, including parameter values.

[0101] like FIG. 3B As shown, the user has named the current formula (e.g., calculator) as “Fibrosis-4” based on input (e.g., typing the letters of the title into the “Name” or “Calculator Name” field located at the top of user interface 320). User interface 320 is configured to facilitate the user's definition of one or more user-customized calculators, such as the “Fibrosis-4” calculator, by defining specific formulas for each user-customized calculator (e.g., the association of variables to be implemented by the formula). The example calculator shown is configured to enable information based on data extracted during the execution of a custom application created subsequently, from one or more selected (e.g., at operation 202) healthcare provider facilities or EHR systems (e.g., one or both of EHR system 108 and EHR system 110). In the example embodiment, the formula for the calculator under development, as shown in the process being defined, is displayed as “(age*AST) / ('”) in the “Fibrosis-4 Calculator Formula” window; this formula will be enabled during the execution of a custom application based on code generated by application builder 106.

[0102] FIG. 3C An example user interface 330 is depicted, configured to allow a user to select display or configuration options that will be used by a subsequently created custom application during execution to present data retrieved from or otherwise associated with a selected healthcare provider facility or EHR system, such as data extracted from one or both of EHR systems 108 and 110. In the example illustration, the user has selected one page for “Number of Pages”; the user has also selected two rows and two columns for “Number of Rows” and “Number of Columns”, respectively. As shown in the example configuration of user interface 330, the user has defined a column (0,0) to present data retrieved from the selected healthcare provider facility or EHR system and processed according to the “Fibrosis-4” calculator (e.g., as defined via user interface 320) during execution by the custom application.

[0103] According to the illustrated embodiment, additional calculators such as “Observation | Vital Signs (BMI)”, “Medication Request”, and “Laboratory (Cretin)” are defined to be presented by the custom application during execution, for example, based on user interaction with user interface 320 and user interface 330. The additional calculators, namely “Observation | Vital Signs (BMI)”, “Medication Request”, and “Laboratory (Cretin)”, are presented by the custom application during execution in columns (0,1), (1,0), and (1,1), respectively. Additionally or alternatively, other calculators (e.g., routines), objects, or other processes already defined (e.g., via user device 102 operated by the user) or obtained elsewhere may be selected or combined by the user who created the custom application for use during the execution of the custom application. As an example, other routines, objects, or processes may correspond to (e.g., include) any application that is available to the user (e.g., or considered useful for the intended purpose of the user creating the custom application) or that can be provided by the user for use by the custom application. Such routines may include items or objects described herein, such as algorithms, applications, BDI software models, components, components that are part of or contained within other components, computer-executed services, elements, functional entities, functions, ML algorithms, modules, operations, processes, processes corresponding to hardware, firmware and / or software, programs, routines, agents, and supervised or unsupervised components.

[0104] 5. Computer networks and cloud networks

[0105] In one or more embodiments, a computer network provides connectivity between a set of nodes. Nodes may be local to each other and / or geographically distant. Nodes are connected via a set of links. Examples of links include coaxial cable, unshielded twisted-pair cable, copper cable, fiber optic cable, and virtual links.

[0106] A subset of nodes implements a computer network. Examples of such nodes include switches, routers, firewalls, and Network Address Translation (NAT). Another subset of nodes uses the computer network. Such nodes (also called "hosts") can execute client processes and / or server processes. A client process (e.g., initiated at user device 102) makes requests for computing services (such as the execution of a specific application (e.g., application builder 106, a custom application) and / or the storage of a specific amount of data). A server process responds by performing the requested service and / or returning the corresponding data.

[0107] A computer network can be a physical network, including physical nodes connected by physical links. A physical node is any digital device. A physical node can be a function-specific hardware device, such as a hardware switch, hardware router, hardware firewall, and hardware NAT. Additionally or alternatively, a physical node can be a general-purpose machine configured to run various virtual machines and / or perform various applications that perform corresponding functions. A physical link is the physical medium connecting two or more physical nodes. Examples of links include coaxial cable, unshielded twisted-pair cable, copper cable, and fiber optic cable.

[0108] Computer networks can be overlay networks. An overlay network is a logical network implemented on top of another network (such as a physical network). Each node in an overlay network corresponds to a corresponding node in the underlying network. Therefore, each node in an overlay network is associated with both an overlay address (addressing to the overlay node) and an underlying address (addressing to the underlying node that implements the overlay node). Overlay nodes can be digital devices and / or software processes (such as virtual machines, application-specific instances, or threads). The links connecting overlay nodes are implemented as tunnels through the underlying network. Overlay nodes at either end of the tunnel treat the underlying multi-hop path between them as a single logical link. Tunneling is performed through encapsulation and decapsulation.

[0109] In embodiments of this disclosure, the client may be located locally on or off the computer network. The client may access the computer network via other computer networks, such as a private network or the Internet. The client may use communication protocols, such as Hypertext Transfer Protocol (HTTP), to transmit requests to the computer network. Requests may be transmitted through interfaces such as client interfaces (such as web browsers), program interfaces, or APIs.

[0110] In embodiments of this disclosure, a computer network provides connectivity between clients and network resources. Network resources include hardware and / or software configured to execute server processes. Examples of network resources include processors, data storage devices, virtual machines, containers, and / or software applications. Network resources are shared among multiple clients. Clients independently request computing services from the computer network. Network resources are dynamically allocated to requesting and / or clients on demand. The network resources allocated to each requesting and / or client may be scaled up or down based on, for example, (a) computing services requested by a particular client, (b) aggregated computing services requested by a particular tenant, and / or (c) the requested aggregated computing services of the computer network. Such a computer network may be referred to as a "cloud network."

[0111] In embodiments of this disclosure, a service provider offers a cloud network to one or more end users. The cloud network can implement various service models, including but not limited to Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). In SaaS, the service provider offers end users the ability to use applications running on network resources provided by the service provider. In PaaS, the service provider offers end users the ability to deploy their own applications on network resources. User-deployed applications can be created using programming languages, libraries, services, and tools supported by the service provider. In IaaS, the service provider offers end users the ability to provision processing, storage, networking, and other basic computing resources provided by network resources. Any application, including operating systems, can be deployed on network resources.

[0112] In embodiments of this disclosure, the computer network can implement various deployment models, including but not limited to private cloud, public cloud, and hybrid cloud. In a private cloud, network resources are supplied to a specific group of entities for exclusive use (as used herein, "entity" refers to a business, organization, individual, or other entity). Network resources can be local to or remote from the premises of the specific group of entities. In a public cloud, cloud resources are supplied to multiple entities (also referred to as "tenants" or "customers") that are independent of each other. The computer network and its network resources are accessed by clients corresponding to different tenants. Such a computer network can be referred to as a "multi-tenant computer network." Several tenants can use the same specific network resources at different times and / or simultaneously. Network resources can be local to or remote from the tenant's premises. In a hybrid cloud, the computer network includes both private and public clouds. The interface between the private and public clouds allows for the portability of data and applications. Data stored in the private cloud and data stored in the public cloud can be exchanged through the interface. Applications implemented in the private cloud and applications implemented in the public cloud may be interdependent. You can use an interface to make calls from an application in a private cloud to an application in a public cloud (and vice versa).

[0113] In embodiments of this disclosure, the tenants of a multi-tenant computer network are independent of each other. For example, one tenant's business or operations may be separate from those of another tenant. Different tenants may have different network requirements for the computer network. Examples of network requirements include processing speed, data storage capacity, security requirements, performance requirements, throughput requirements, latency requirements, resilience requirements, quality of service (QoS) requirements, tenant isolation, and / or consistency. The same computer network may need to meet the different network requirements demanded by different tenants.

[0114] In one or more embodiments, in a multi-tenant computer network, tenant isolation is implemented to ensure that applications and / or data from different tenants are not shared with each other. Various tenant isolation methods can be used.

[0115] In embodiments of this disclosure, each tenant is associated with a tenant ID. Each network resource in a multi-tenant computer network is tagged with a tenant ID. A tenant is only allowed access to a specific network resource if the tenant and the specific network resource are associated with the same tenant ID.

[0116] In embodiments of this disclosure, each tenant is associated with a tenant ID. Each application implemented by the computer network is tagged with a tenant ID. Additionally or alternatively, each data structure and / or dataset stored by the computer network is tagged with a tenant ID. A tenant is allowed access to a specific application, data structure, and / or dataset only when the tenant and the specific application, data structure, and / or dataset are associated with the same tenant ID.

[0117] As an example, each database implemented in a multi-tenant computer network can be identified by a tenant ID. Only the tenant associated with the corresponding tenant ID can access the data in a specific database. As another example, each entry in a database implemented in a multi-tenant computer network can be identified by a tenant ID. Only the tenant associated with the corresponding tenant ID can access the data for that specific entry. However, the database can be shared by multiple tenants.

[0118] In embodiments of this disclosure, the subscription list indicates which tenants are authorized to access which applications. For each application, a list of tenant IDs of tenants authorized to access that application is stored. A tenant is only allowed to access a specific application if its tenant ID is included in the subscription list corresponding to that specific application.

[0119] In embodiments of this disclosure, network resources (such as digital devices, virtual machines, application instances, and threads) corresponding to different tenants are isolated to tenant-specific overlay networks maintained by a multi-tenant computer network. As an example, data packets from any source device within a tenant overlay network can be sent only to other devices within the same tenant overlay network. Encapsulation tunneling is used to prevent any transmission from a source device on one tenant overlay network to devices in other tenant overlay networks. Specifically, data packets received from a source device are encapsulated within an outer data packet. The outer data packet is sent from an encapsulation tunnel endpoint (communicating with the source device in the tenant overlay network) to another encapsulation tunnel endpoint (communicating with the destination device in the same tenant overlay network). This other encapsulation tunnel endpoint decapsulates the outer data packet to obtain the original data packet sent by the source device. The original data packet is then sent from this other encapsulation tunnel endpoint to the destination device in the same specific overlay network.

[0120] 6. Microservice Applications

[0121] According to one or more embodiments, the techniques described herein are implemented using a microservices architecture. In this context, a microservice refers to software logic designed to be deployed independently, having endpoints that can be logically coupled to other microservices to build various applications. Applications built using microservices differ significantly from monolithic applications, which are designed as a single, fixed unit and typically consist of a single logical executable. With microservices applications, different microservices can be deployed independently as separate executables. Microservices can communicate via API endpoints using Hypertext Transfer Protocol (HTTP) messages and / or according to other communication protocols. Microservices can be managed and updated separately, written in different languages, and executed independently of other microservices.

[0122] Microservices offer flexibility in managing and building applications. Different applications can be built by connecting different collections of microservices without changing the microservices' source code. Therefore, microservices act as logical building blocks that can be arranged in various ways to build different applications. Microservices can provide monitoring services that notify the microservice manager when trigger events from a set of trigger events exposed to the microservice manager occur (such as If-This-Then-That (IFTTT), Zapier, or Oracle Self-Service Automation (OSSA)). Microservices exposed to an application can alternatively or additionally provide action services that perform actions within the application based on data received from the microservice manager (data passed via values, connecting actions to other triggers, and / or other actions from the microservice manager, which is controllable and configurable by the microservice manager). Microservice triggers and / or actions can be chained together to form recipes for actions that would otherwise be unknown to or have no control or dependency on each other in different applications. These managed applications can be authenticated or inserted into the microservice manager, for example, using application credentials provided by the user to the manager, without requiring re-authentication each time a managed application is used alone or in combination with other applications.

[0123] trigger

[0124] According to one or more embodiments, the above-described techniques can be encapsulated into microservices. In other words, a microservice can trigger notifications based on the above-described techniques (optionally accessible in the microservice manager for use by other inserted applications, referred to herein as the "target" microservice), and / or can be represented as a GUI block and connected to one or more other microservices. Users can use directed arrows or any other GUI element to connect the output of one microservice to the input of another microservice, so that, for example, a computing system or application builder 106 can run verification tests to confirm that the output is compatible with the input, for example, by checking data type or size limitations.

[0125] Triggering conditions can include absolute or relative thresholds for values, and / or absolute or relative thresholds for the amount of data to be analyzed or the duration of data analysis, such that a trigger occurs to the microservice manager whenever an inserted microservice application detects that a threshold has been exceeded. For example, a user can request a trigger from the microservice manager when a microservice application detects that a value has exceeded the trigger threshold.

[0126] In one embodiment of this disclosure, the trigger, when satisfied, can output data for consumption by the target microservice. In another embodiment of this disclosure, the trigger, when satisfied, outputs a binary value indicating that the trigger has been satisfied, or outputs a column name or other contextual information indicating that the triggering condition has been met. Additionally or alternatively, the target microservice can connect to one or more other microservices, enabling alerts to be input to these other microservices. Other microservices can perform response actions based on the techniques described above, including but not limited to deploying additional resources, adjusting system configurations, and / or generating a GUI.

[0127] action

[0128] In one or more embodiments, the inserted microservice application can expose actions to the microservice manager. The exposed actions can receive data, the identifier of a data object, or the location of the data as input, which allows the data to be moved to the data cloud.

[0129] In one or more embodiments, the exposed action can receive a request as input to increase or decrease an existing alert threshold. The input can identify an existing in-application alert threshold and whether to increase, decrease, or delete that threshold. Additionally or alternatively, the input can request the microservice application to create a new in-application alert threshold. In-application alerts can be triggered to the user upon login to the application, or they can use a default or user-selected alerting mechanism available within the microservice application itself, rather than being triggered by another application plugged into the microservice manager.

[0130] In one or more embodiments, a microservice application may generate and provide output based on inputs that identify, locate, or provide historical data and define the degree or scope of the requested output. Actions, when triggered, cause the microservice application to provide, store, or display the output, such as as a data model or as aggregated data describing the data model.

[0131] 7. Hardware Overview

[0132] According to one embodiment of this disclosure, the techniques described herein are implemented by one or more dedicated computing devices. The dedicated computing device may be hardwired to execute the techniques, or may include: (i) a digital electronic device permanently programmed to execute the techniques, such as one or more application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or network processing units (NPUs), or (ii) one or more general-purpose hardware processors programmed to execute the techniques according to program instructions in firmware, memory, other storage devices, or combinations thereof. Such a dedicated computing device may also implement the techniques by combining custom hardwired logic, ASICs, FPGAs, or NPUs with custom programming. The dedicated computing device may be a desktop computer system, a portable computer system, a handheld device, a networking device, or any other device that combines hardwired and / or program logic to implement the techniques.

[0133] For example, FIG. 4 This is a block diagram illustrating a computer system 400 on which embodiments of the present disclosure may be implemented. The computer system 400 includes a bus 402 or other communication mechanism for transmitting information and a hardware processor 404 coupled to the bus 402 for processing information. The hardware processor 404 may be, for example, a general-purpose microprocessor.

[0134] Computer system 400 also includes main memory 406, such as random access memory (RAM) or other dynamic storage devices, coupled to bus 402 for storing information and instructions to be executed by processor 404. Main memory 406 may also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 404. When such instructions are stored in non-transitory storage media accessible to processor 404, such instructions make computer system 400 a dedicated machine customized to perform the operations specified in the instructions.

[0135] The computer system 400 also includes a read-only memory (ROM) 408 or other static storage device coupled to the bus 402 for storing static information and instructions of the processor 404. A storage device 410, such as a disk or optical disk, is provided and coupled to the bus 402 for storing information and instructions.

[0136] Computer system 400 may be coupled to display 412, such as a cathode ray tube (CRT), via bus 402 for displaying information to the computer user. Input device 414, including alphanumeric keys and other keys, is coupled to bus 402 for transmitting information and command selections to processor 404. Another type of user input device is cursor control 416, such as a mouse, trackball, or arrow keys, for transmitting directional information and command selections to processor 404 and for controlling cursor movement on display 412. This input device typically has two degrees of freedom on two axes (e.g., x and y) to allow the device to specify a position in a plane.

[0137] Computer system 400 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic, which, in combination with the computer system, make computer system 400 a special-purpose machine or program the computer system 400 as such. According to one embodiment of this disclosure, the techniques herein are executed by computer system 400 in response to processor 404 executing one or more sequences of one or more instructions contained in main memory 406. These instructions may be read into main memory 406 from another storage medium, such as storage device 410. Execution of the sequence of instructions contained in main memory 406 causes processor 404 to perform the processing operations described herein. In alternative embodiments of this disclosure, hardwired circuitry may be used instead of or in combination with software instructions.

[0138] As used herein, the term "storage medium" refers to any non-transitory medium that stores data and / or instructions that enable a machine to operate in a particular manner. Such storage media can include non-volatile media and / or volatile media. Non-volatile media include, for example, optical discs or magnetic disks, such as storage device 410. Volatile media include dynamic memory, such as main memory 406. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or cassette tapes, content-addressable memory (CAM), and tri-state content-addressable memory (TCAM).

[0139] Storage media are distinct from transmission media but can be used in conjunction with them. Transmission media participate in transferring information between storage media. For example, transmission media include coaxial cables, copper wires, and optical fibers, including wires containing bus 402. Transmission media can also take the form of sound waves or light waves, such as those generated during radio wave and infrared data communication.

[0140] Various forms of media can involve carrying one or more sequences of instructions to processor 404 for execution. For example, the instructions may initially be carried on a disk or solid-state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and transmit them over a telephone line using a modem. A modem local to computer system 400 may receive data over the telephone line and convert the data into an infrared signal using an infrared transmitter. An infrared detector may receive the data carried in the infrared signal, and appropriate circuitry may place the data on bus 402. Bus 402 carries the data to main memory 406, from which processor 404 retrieves and executes the instructions. The instructions received by main memory 406 may optionally be stored on storage device 410 before or after execution by processor 404.

[0141] Computer system 400 also includes a communication interface 418 coupled to bus 402. Communication interface 418 provides bidirectional data communication coupled to network link 420, which is connected to local network 422. For example, communication interface 418 may be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem providing data communication connectivity to a corresponding type of telephone line. As another example, communication interface 418 may be a LAN card providing data communication connectivity to a compatible local area network (LAN). A wireless link may also be implemented. In any such implementation, communication interface 418 transmits and receives electrical, electromagnetic, or optical signals carrying streams of digital data representing various types of information.

[0142] Network link 420 typically provides data communication to other data devices via one or more networks. For example, network link 420 may provide a connection to host computer 424 or to data devices operated by Internet Service Provider (ISP) 426 via local network 422. ISP 426, in turn, provides data communication services via a global packet data communication network now commonly referred to as the "Internet" 428. Both local network 422 and Internet 428 use electrical, electromagnetic, or optical signals that carry digital data streams. Signals through various networks, as well as signals on network link 420 and through communication interface 418, are example forms of transmission media that carry digital data to or from computer system 400.

[0143] Computer system 400 can send messages and receive data, including program code, through one or more networks, network links 420, and communication interfaces 418. In the Internet example, server 430 can transmit requested code for the application through the Internet 428, ISP 426, local network 422, and communication interface 418.

[0144] The received code can be executed by processor 404 when it is received, and / or stored in storage device 410 or other non-volatile storage device for later execution.

[0145] 8. Miscellaneous; Extension

[0146] Unless otherwise defined, all terms (including technical and scientific terms) shall be given their common and conventional meanings as those skilled in the art, and are not limited to their special or customary meanings, unless otherwise expressly defined herein.

[0147] This application includes references to certain trademarks. While the use of trademarks is permitted in a patent application, the exclusivity of the trademark must be respected and every effort must be made to prevent its use in any way that may adversely affect its validity.

[0148] The embodiments are directed to a system having one or more devices, which include a hardware processor and are configured to perform any of the operations described herein and / or any of the following claims.

[0149] In embodiments of this disclosure, the non-transitory computer-readable storage medium includes instructions that, when executed by one or more hardware processors, cause to perform any of the operations described herein and / or any of the claims.

[0150] According to one or more embodiments of this disclosure, any combination of the features and functions described herein may be used. Embodiments of this disclosure have been described in the foregoing specification with reference to numerous specific details that vary depending on the implementation. Therefore, the specification and drawings should be considered illustrative rather than restrictive. The unique and exclusive reference to the scope of this disclosure, and what the applicant intends to define as the scope of this disclosure, is the literal and equivalent scope of the set of claims issued in this application, in the specific form of such claims, including any subsequent corrections.

Claims

1. A non-transitory computer-readable medium comprising instructions that, when executed by one or more hardware processors, cause to perform operations including: Receive selection of a first resource defined by the first electronic health record (EHR) system; Analyze the metadata associated with the first resource to identify a first set of characteristics corresponding to the first resource; The first set of characteristics identifies one or more configuration bars associated with the first resource; Present the one or more configuration tabs associated with the first resource; Receive one or more configuration values ​​for the one or more configuration fields; as well as Generate code for (a) executing application programming interface (API) calls to extract data associated with the first resource based on one or more configuration values ​​and (b) presenting the data associated with the first resource.

2. The computer-readable medium of claim 1, wherein: Prior to receiving the selection, the first EHR system was analyzed to identify multiple resources associated with the first EHR system; and The multiple resources are associated with the FHIR standard, including a first resource, and are presented as a candidate set of resources for the user to choose from.

3. The computer-readable medium of claim 1, wherein the operation further includes executing the code to (a) perform the API call to extract data associated with the first resource and associated with the FHIR protocol and (b) present the data associated with the first resource according to the one or more configuration values.

4. The computer-readable medium of claim 3, wherein executing the code causes retrieval from the EHR system of a resource corresponding to at least one record of a patient in the EHR system.

5. The computer-readable medium of claim 4, wherein operation further includes presenting information associated with the patient data artifact to obtain treatment guidance.

6. The computer-readable medium of claim 5, wherein presenting information includes applying an AI model to the information.

7. The computer-readable medium of claim 1, wherein the EHR system conforms to FHIR and is configured to map to one or more of the following: patient medical records associated with a specific hospital, or patient medical records associated with the HIE platform and related to immunization status.

8. The computer-readable medium of claim 1, further comprising executing a machine learning model trained to identify a candidate set of resources for user selection.

9. The computer-readable medium of claim 1, wherein: The one or more configuration fields are associated with a user scope, which includes multiple resources associated with corresponding multiple selectable scopes; and At least one of the plurality of selectable ranges is associated with a selectable read-access license field and a selectable write-access license field.

10. The computer-readable medium of claim 1, wherein the one or more configuration bars are associated with a plurality of selectable user-scoped bars.

11. The computer-readable medium of claim 1, wherein the one or more configuration columns are associated with a plurality of patient range columns, wherein each patient range column is associated with a resource of the EHR, the resource being configurable by user selection to one or more of read-access enabled, read-access disabled, write-access enabled, or write-access disabled.

12. The computer-readable medium of claim 1, wherein: The selection of the first resource indicates the resource type; In response to the selection of a first resource, the metadata associated with the first resource is analyzed to identify a first set of characteristics and to identify the one or more configuration bars; as well as Presenting the one or more configuration panels includes presenting: multiple selectable resource parameter panels, a user-definable instance count data panel, a display format type panel, and a data display location panel.

13. The computer-readable medium of claim 12, wherein: The selection of the first resource indicates the type of resource to observe, and the multiple selectable resource parameter columns are included in a drop-down menu, which includes the following selectable columns: vital signs (BMI), vital signs (stress), laboratory (creatinine), and laboratory (hemoglobin).

14. The computer-readable medium of claim 1, wherein: The selection of the first resource is based on a drop-down menu, which includes patient resource type, observation resource type, procedure resource type, and medication request resource type; as well as In response to the selection of the observed resource type, several selectable resource parameter fields associated with that observed resource type are presented.

15. A method comprising the operation as described in any one of claims 1-14.

16. A system comprising one or more hardware processors, the system being configured to perform the operations as described in any one of claims 1-14.

17. A system comprising components for performing the operations as described in any one of claims 1-14.

Images