Code generator for accessing various health record systems

Abstract

A technology is disclosed that enables a user with little to 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 a portion of a health record. The technology may include actions such as 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 configuration fields associated with the first resource based on the first set of characteristics; presenting the configuration fields associated with the first resource; receiving configuration values ​​for the configuration fields; and making API calls to extract data associated with the first resource and generating code to present the data associated with the first resource according to the configuration values.

Description

Technical Field

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

Background Art

[0002] Background of the Invention An application is typically executable in association with a computer program or routine and includes a large amount of code configured to perform various actions and operations. As is well known, an application can provide access to and management operations for a database or can generate and play media. An application can operate as a stand-alone function or can operate in cooperation with additional applications. An application can be executed on hardware such as a desktop computer, a tablet, and a phone via a virtual processor and / or a distributed processor.

Summary of the Invention

Problems to be Solved by the Invention

[0003] Once started, an application can display or cause a user interface, such as a graphical user interface (GUI), locally or remotely to present information to local or remote users, and can receive input from the user via the GUI based on the user's interaction with the presented information. User input can indicate actions to be performed, such as storing information in a database or retrieving information from a database. The database may include electronic health records (EHRs) stored at a healthcare provider facility by the facility's electronic health record (EHR) system. A healthcare provider facility may include, for example, a clinic or a hospital. However, the types of access, such as the types of information and the options for processing the information in the database, are usually limited or suboptimal to the user's needs.

[0004] Embodiments of the Disclosure are shown in the accompanying drawings for illustrative purposes only, not as limitations. Whenever the Disclosure refers to “one” or “single” embodiment of the Disclosure, this does not necessarily mean the same embodiment of the Disclosure, but rather means at least one. [Brief explanation of the drawing]

[0005] [Figure 1A] This figure shows the operating environment according to one or more embodiments of the present disclosure. [Figure 1B] This figure shows the operating environment according to one or more embodiments of the present disclosure. [Figure 2] This figure shows an exemplary set of operations that enable a user to build a custom application for accessing user-selected information associated with records in one or more EHR systems, according to one or more embodiments of the present disclosure. [Figure 3A]This figure shows an exemplary user interface for directing and receiving information from a user device, with regard to user preferences for building a custom application configured to access, process, and present data associated with one or more healthcare provider facilities or EHR systems. [Figure 3B] This figure shows an exemplary user interface for directing and receiving information from a user device, with regard to user preferences for building a custom application configured to access, process, and present data associated with one or more healthcare provider facilities or EHR systems. [Figure 3C] This figure shows an exemplary user interface for directing and receiving information from a user device, with regard to user preferences for building a custom application configured to access, process, and present data associated with one or more healthcare provider facilities or EHR systems. [Figure 3D] This figure shows an example display that might appear on a user's device while a custom application is running. [Figure 4] This is a block diagram including a computer system according to one or more embodiments of the present disclosure. [Modes for carrying out the invention]

[0006] Detailed explanation In the following description, for the sake of clarity, numerous specific details are provided to ensure a full understanding of the disclosure. One or more embodiments of the disclosure can be implemented without these specific details. Features described in one embodiment of the disclosure can be combined with features described in a different embodiment of the disclosure. In some examples, known structures and devices are described with reference to block diagrams to avoid unnecessarily obscuring the invention. 1.Overview 2. Electronic health record system 3. Data Extraction System 4. App builder for accessing various health record systems 5. Exemplary Embodiments 6. Computer networks and cloud networks 7. Microservices Applications 8. Hardware Overview 9. Miscellaneous rules, extensions

[0007] 1.Overview

[0008] 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 containing candidate data extraction targets and receive corresponding user input. For example, the system accepts, as user input via the interface, a selection of an EHR system and a selection of resources defined by the selected EHR system from which data will be extracted. The system can further accept user input containing configuration values ​​for configuring resource extraction and / or presenting extracted data corresponding to the resources. Based on the user input, the system generates and executes code that incorporates application programming interface (API) calls with corresponding parameters to extract data from the EHR system. The display of the extracted data may include information about the user-selected resource / field.

[0009] One or more embodiments customize and build a software application configured to extract, process, and display information associated with an EHR for users with little or no coding experience. The system customizes and builds the software application based on user input that defines the data to be extracted and / or attributes for the presentation of the extracted data.

[0010] One or more embodiments of the Disclosure described herein and / or claimed herein may not be included in this summary section.

[0011] 2. Electronic health record system

[0012] Different healthcare providers typically use and maintain their own distinct Electronic Health Record (EHR) systems. The data associated with an EHR system may include information within the patient's medical records. This data is usually stored in a non-standardized format compared to data stored in other EHR systems associated with other healthcare providers. Furthermore, each EHR system may be associated with a corresponding Application Programming Interface (API) that differs from the APIs for other EHR systems. An application configured to extract data based on the data format and API of a particular EHR system may not be able to extract data from other EHR systems. Alternatively, or in addition, an application may not have access to sufficient information from other EHR systems. Therefore, it may be necessary to generate different applications and / or different sets of code to access data from different, respective EHR systems.

[0013] In light of these issues, healthcare providers continue to demand improved tools that include the ability to extract data from heterogeneous sources, such as different EHR systems. Combined datasets from heterogeneous sources can be useful for healthcare providers to provide continuous care to individuals across multiple healthcare facilities. For example, a healthcare provider may want to view five blood test parameters for an individual associated with a patient medical record in a graphical format. However, applications may allow the display of different numbers or types of blood test parameters associated with a patient. Thus, healthcare providers may be prevented from displaying data or information associated with data that corresponds to the data that the healthcare provider considers most important for the intended use of the data by the healthcare provider. Furthermore, interoperability is usually lacking with respect to the ability of applications to access different patient medical records at different healthcare facilities, as different EHR systems inevitably use different standards or formats for their patient medical record data.

[0014] 3. Data Extraction System

[0015] FIG. 1A shows an example of an operating environment suitable for implementation of an embodiment of the present disclosure. An exemplary computing system includes a combination of hardware elements and software elements for compiling and executing an implementation of an application builder 106. The application builder 106 is executable, for example, on a computing system, a user device 102, or an EHR system 108 to create a custom application. For example, a custom application executable on a computing system, a user device 102, or an EHR system 108 is enabled to access data stored according to individualized user-specified criteria selected during creation of the custom application. In an exemplary embodiment of the present disclosure shown in FIG. 1A, the operating environment 100 enables construction and execution of such custom applications by elements of the operating environment 100 that include a user device 102 communicatively coupled via networking means (e.g., network 104) to an application builder 106 and one or more healthcare provider facilities or patient medical record databases, such as EHR systems 108 and EHR systems 110.

[0016] The operating environment 100 shown includes a communication coupling through network 104 between a user device 102 capable of implementing a clinician user interface and one or more of EHR systems 108 and EHR systems 110. It is further contemplated that some embodiments of the user device 102 may be communicatively coupled directly to, for example, EHR system 108, EHR system 110, or application builder 106.

[0017] Embodiments of user device 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 set of applications. User device 102 may include a physical device that runs either or both an application or a virtual machine. Examples of user device 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 converters (NATs), hardware load balancers, and mainframes. Further examples of user device 102 may include televisions, content receivers, set-top boxes, printers, mobile handsets, smartphones, personal digital assistants (PDAs), wireless receivers and / or transmitters, base stations or access points, communication management devices, controllers, and / or client devices. In a typical embodiment described herein, user device 102 includes a web-based application or a set of applications that can be used to build custom applications and manage other user services provided by embodiments of this disclosure.

[0018] The operating environment 100 according to the present disclosure may have other arrangements that are not necessarily described herein or specified in the examples, but are recognizable to those skilled in the art as possible modifications or extensions. Other arrangements and elements (e.g., machines, user interfaces, functions, order of functions, and groupings of functions) can be used in addition to, or instead of, those shown or described, and some elements can be omitted entirely. Further, many of the elements described herein can be implemented as discrete or distributed components or modules, or in cooperation with (e.g., internally to) other components or modules, and as functional entities that can be implemented in any suitable combination and location. 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, the various functions can be performed by a processor that executes instructions stored in memory. Further, any number of the components shown in FIG. 1A can be used as part of, or in communication with, the operating environment 100 within the scope of the present disclosure. Each can be implemented via a single device, or multiple devices cooperating in a distributed environment. Additionally, other components not shown can be included within the operating environment 100. <> <>

[0019] <> In the illustrated embodiment of the present disclosure, the user device 102 is communicatively coupled via the network 104 to each of an authentication server 112, a Fast Healthcare Interoperability Resources (FHIR) device, e.g., a FHIR server 114, an application / index module 116 that can correspond to a custom application to be created, and an application launcher 118. Additionally, as made apparent in FIG. 1A, the application builder 106 can be communicatively coupled to, or include, a data repository 120, which will be described below with reference to FIG. 1B. <> <>

[0020] <> 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, corporate-wide computer networks, intranets, and the Internet. In exemplary implementations of this disclosure, such networks include the Internet and / or cellular networks, among a variety of possible public and / or private networks. According to one embodiment, any one of user device 102, application builder 106, EHR system 108, EHR system 110, authentication server 112, FHIR server 114, application / index module 116, and application launcher 118 may communicate with any other of user device 102, application builder 106, EHR system 108, EHR system 110, authentication server 112, FHIR server 114, application / index module 116, application launcher 118, and / or data repository 120, for example, via application builder 106.

[0021] The application builder 106 can be included in or associated with a computing system such as a computing system corresponding to the computer system 400 (Figure 4), which can be configured as a server communicably coupled (e.g., via the application builder 106) to user devices 102, EHR systems 108 and 110, authentication servers 112 and 114, application / index modules 116, application launchers 118, and / or data repositories 120 via a network 104. The computing system includes one or more processors capable of receiving and appropriately processing instructions, and can be embodied as a single computing device or multiple computing devices communicably coupled to one another. In one embodiment, processing actions performed by the computing system are distributed to 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 a desktop computer, laptop, tablet, cloud computing device, distributed computing architecture, ultra-mobile PC, or mobile phone. In some embodiments, the computing system includes an adaptive multi-agent operating system, but it will be understood that the computing system may take the form of an adaptive single-agent system or a non-agent system. The computing system may include, or may operate in conjunction with, a distributed computing system, a distributed or centralized computing system, and / or a virtual computing system.

[0022] Embodiments of the computing system include a set of modules or components, such as a computer software stack. The set of modules or components can facilitate the creation of custom applications that can communicate with one or more EHR systems 108 and 110 in accordance with industry-known or publicly available standards or protocols. One or more of the authentication server 112, FHIR server 114, application / index module 116, application launcher 118, and / or data repository 120 can operate to enable the creation of custom applications via the application builder 106 that are configured to operate or provide functionality in accordance with the above standards, protocols, and interoperability standards indicated or required by Substitutable Healthcare Applications, Reusable Technology (SMART), FHIR, and / or SMART on FHIR. Furthermore, the authentication server 112, FHIR server 114, application / index module 116, application launcher 118, and / or data repository 120 can operate in conjunction with or in relation to a custom application that can operate with or provide compliant functionality with one or more of the authentication server 112, FHIR server 114, application / index module 116, and / or application launcher 118, or can operate to build such a custom application. The application / index module 116 may be associated with or contain an address or code associated with the custom application.

[0023] In the embodiments shown, a set, such as a stack, is included in or under the control of the application builder 106 as a component or module stack, and operates, for example, as a distributed system on the virtualization layer of a 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, computer configuration module 126, authentication engine 128, and code generator 130. In some embodiments, one or more of the user interface layout module 122, resource / parameter selection module 124, computer configuration module 126, authentication engine 128, and code generator 130 may include individual components or components embodied as part of or within other components of the application builder 106 and / or operating environment 100. For example, one or more, or parts of one or more, of the user interface layout module 122, resource / parameter selection module 124, computer configuration module 126, authentication engine 128, and code generator 130 may be implemented on a user device 102. Similarly, one or more parts or all of the user interface layout module 122, resource / parameter selection module 124, computer configuration module 126, authentication engine 128, or code generator 130 may perform functions for two or more other components or modules referenced in the description of the operating environment 100.

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

[0025] The execution of the application builder 106 can be initiated based on signals such as inputs received from a user device 102 operated by a healthcare provider. The application builder 106 develops / creates custom applications with little to no coding required by the healthcare provider or user. The custom application accesses specific information requested by the healthcare provider, namely information or data fields in patient medical records at a healthcare provider facility or a specific EHR system, for example, EHR system 108. The custom application further accesses specific user-selected information or data fields in patient medical records at another healthcare provider facility or a specific EHR system, for example, EHR system 110.

[0026] The application builder 106 can receive inputs related to access, configuration, and / or execution via the network 104 to create a custom application. Inputs may include signals from a user device 102 under the user's control, which interacts with a user interface presented via the application builder 106. Inputs to the application builder 106 can be received during the creation of the custom application. As described herein, once created, a custom application can access data stored in one or more of a specific healthcare provider facility or a specific EHR system. Stored data can be accessed according to the interoperability standards described above, as well as according to user identification resources and resource parameters specified based on the inputs to the application builder 106. For example, SMART can standardize the process by which a custom application can access a specific data store and extract clinical information from the data store. The data store can be implemented by a healthcare provider facility and / or in a specific EHR system. When used herein, SMART on FHIR can define workflows that a custom application can use to securely request access to data and subsequently receive and use that data. Furthermore, SMART on FHIR, as described and referenced herein, can provide custom applications with a standard, general-purpose API for accessing electronic health information (EHI) in, for example, a specific data store.

[0027] The operating environment 100 may include any number of EHR systems, such as EHR system 108 and EHR system 110. The EHR systems referred to herein include, or may be associated with, hospital EHR systems, outpatient clinic EHR systems, health planning EHR systems, or home monitor / patient monitor EHR systems, all of which are communicably coupled to network 104. In embodiments of this disclosure, the EHR systems may include medical information exchange (HIE), patient portals, government databases, pharmacy databases, or any other systems capable of recording, storing, receiving, transmitting, etc., any health-related data.

[0028] Content available within an EHR system may include records of treatment events, medication history, diagnoses, problems, allergies, demographic attributes, episode note summaries (SOEN), Clinical Document Architecture (CDA) documents, laboratory test or results, time and data information, images, clinical notes, appointment notes, emergency contact information, any type of clinical documentation, and any other health-related data about an individual, or any combination thereof. Different EHR systems can be heterogeneous sources, in other words, they can be associated with different entities. For example, EHR system 108 may be associated with a hospital in Pennsylvania, while EHR system 110 may be associated with a pharmacy in Florida that is unrelated to source EHR system 110. Different EHR systems, being heterogeneous sources that contain and operate under different entities, can utilize different standards or formats, such as JavaScript Object Notation (JSON), Extensible Markup Language (XML), YAML Ain't Markup Language (YAML), Health Level 7 (HL7), and Consolidated Clinical Document Architecture (CCDA). Furthermore, although an EHR system is described herein as a single source (e.g., a single database), any EHR system may include multiple data stores, each associated with one or many different entities. Those skilled in the art will understand that an EHR system can take various forms, be represented as multiple components, and communicate with any number of other sources.

[0029] Embodiments of an EHR system may include a data store for health records, a computer or server to facilitate the storage and retrieval of health records, and a firewall, for example, a separate firewall associated with each EHR system. Furthermore, in some embodiments of this disclosure, the EHR system may be implemented as a cloud-based platform or distributed across multiple physical locations. In some embodiments of this disclosure, the EHR system includes a recording system for storing real-time or near-real-time patient information, such as information associated with wearables, bedside, or home patient monitors.

[0030] It is further conceivable that embodiments of the EHR system may use different clinical ontologs, nomenclature, vocabulary, or coding schemes for clinical information or clinical terminology. For example, the EHR of EHR system 108 may be associated with one hospital system using a certain nomenclature, while the EHR of EHR system 110 may be associated with another hospital system using a different nomenclature. Similarly, EHR system 108, which may be local to the caregiver, patient, or clinician on user device 102, may use one clinical nomenclature, while EHR system 110, which may be remote to the caregiver, patient, or clinician on user device 102, may use a different nomenclature. Furthermore, in some embodiments, EHR system 108 and EHR system 110 are associated with two or more distinct medical entities using two or more different nomenclatures. Figure 1A shows several exemplary EHR systems, but in some embodiments, only one EHR system may be used, or alternatively, a clinician user interface may be relied upon for storing or retrieving patient record information in a single data store, data repository 120, and / or distributed locations.

[0031] Moving on to Figure 1B, the data repository 120 according to one or more embodiments of the present disclosure includes any type of storage unit and / or device (e.g., a file system, a database, a collection of tables, or any other storage mechanism) for storing data relating to a clinic, hospital, or healthcare provider associated with a clinic or hospital, such as patient data. Furthermore, the data repository 120 may include multiple different storage units and / or devices, which may or may not be of the same type, and may or may not be located in the same physical location. Furthermore, the data repository 120 may be implemented by or run on a computing system (e.g., including an application builder 106). Alternatively, or in addition, the data repository 120 may be implemented or run on a system separate from the application builder 106. In certain embodiments, the data repository 120 is populated by or accesses information from various sources and / or systems.

[0032] As shown in Figure 1B, the 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 field data 142, configuration value data 144, code data 146, for example, code associated with API calls or the construction of custom applications, and machine learning (ML) model data 148. As used herein, EHR data 132 may refer to a collection of organized health information of a patient or population electronically stored in a digital format. EHR data 132 may include data associated with an EHR system, or data used in connection with an EHR system, for example, data created, described, or accessed, and EHR data includes the EHR. As used herein, resource data 134 may include categories or descriptions of medical data. Resource data may include broad terms within or describing medical data, including patients, test results, and observations. Resource data 134 may include data used to define or describe data elements, constraints on data elements, and relationships between data elements, which together can constitute an interchangeable electronic patient health record. When used herein, metadata 136 may include data that provides information about other data, for example, data that describes other data and provides information about other data. Metadata 136 can be used to provide structured types of references to other data that enable sorting of other data and identification of attributes related to other data.

[0033] When used herein, historical data 138 may include data collected about past events or circumstances relating to a particular subject, such as an event or resource. For example, historical data may include data collected in connection with previous executions of application builder 106. When used herein, resource parameter data 140 may include data relating to the details, type, and use of a resource, such as data describing them. For example, according to the HL7 standard, the resource parameters of the "patient" resource may include "profiles" and "extensions". In another example, the resource parameters of the "patient" resource may include read access permissions for that resource in a selected EHR system and / or write access permissions for that resource in a selected EHR system. When used herein, configuration field data 142 and configuration value data 144 may relate to a user interface that enables user selection and user configuration of user-selected resource parameters, for example, for use in a custom application. For example, configuration field data 142 and configuration value data 144 can be used to enable user selection and user configuration input for defining one or more user selection resources, as described in relation to the following operations 210-212 and user interfaces 310-330. When used herein, code data 146 may include information used to create or develop the code described herein, or it may include the code itself.

[0034] Information stored in or by the data repository 120 can be structured. Structured data may include, for example, spreadsheets. Information does not have to be structured. Unstructured data may include, for example, conversation text or social media posts. Furthermore, the data repository 120 can store or access information including, contained in, or related to variables associated with patient status or recommendations, recommendations or other knowledge bases, and recommendation rules or other rules. Furthermore, the data repository 120 can store or access information including, contained in, or related to recommendation data, recommendation update statistics, operational data, related rule bases, agent libraries, solvers, solver libraries, computer-available instructions, patient-derived data, and healthcare provider information. Examples of operational data that resides in, is accessible by, or can be written to the data repository 120 include events, frequent item sets (e.g., "X often occurs with Y"), and item set index information. The data repository 120 is assumed to be capable of storing any information that can be stored in a computer storage device or system, such as user-generated data, computer-usable instructions, software applications, or other information. The information stored in the data repository 120 can be implemented across any component, module, or element within the operating environment 100. In the shown embodiments, for clarity and explanatory purposes, this information is shown and described as being stored or residing in relation to the data repository 120.

[0035] In a typical embodiment, the data repository 120 collaborates with the application builder 106 to enable the creation of custom applications by the application builder 106, for example. For example, information including one or more of the following can be written to or read from the data repository in connection with the above collaboration: EHR data 132, resource data 134, metadata 136, history data 138, resource parameter data 140, configuration field data 142, configuration value data 144, or code data 146. The data repository 120 can collaborate with one or more custom applications after creation, for example, in connection with the execution of actions by one or more custom applications. For example, information including one or more of the following can be written to or read from the data repository in connection with collaboration with custom applications: EHR data 132, resource data 134, metadata 136, resource parameter data 140, configuration value data 144, and code data 146.

[0036] In some embodiments, the data repository 120 can collaborate with other components (for example, directly or through one or more of the application builder 106 or custom applications) to enable the creation of custom applications or in connection with the execution of actions by custom applications. For example, other components may include any of the authentication server 112, the FHIR server 114, the application / index module 116, or the application launcher 118. For example, information including one or more of the metadata 136, historical data 138, resource parameter data 140, code data 146, and ML model data 148 can be written to or read from the data repository 120 in connection with collaboration with other components. When used in this paragraph and the paragraphs above, collaboration with or by the data repository 120 may include retrieving or enabling access to data, creating or enabling the creation of data, and writing or enabling the writing of data in or by the data repository 120. In a certain embodiment, the data repository 120 is populated with information from various sources and / or systems.

[0037] An exemplary operating environment 100 may include, for example, a clinician interface on a user device 102, configured to facilitate communication with one or more of the EHR systems 108, 110, and application builder 106 via a user device 102 operated by the user. Therefore, embodiments of the user device 102 may take the form of a user interface, such as a clinician interface, operated by a client computing device, such as a mobile communication device or smartphone computing device, or by a software application or set of applications on the user device 102. In one embodiment of this disclosure, the software application includes PowerChart® software from Cerner Corporation. 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 reception of information from the user or healthcare provider about a particular patient or set of patients on which data sets are processed and / or displayed, as well as access to the application builder 106, for example, via the EHR system 108 or EHR system 110. In some embodiments of this disclosure, the user device 102 facilitates the reception of instructions from a clinician to a patient, for example, based on or related to the processing of a dataset. For example, the user device 102 may display user-relevant results indicating that a given patient may or is suffering from a particular condition.

[0038] In one or more embodiments of this disclosure, the operating environment 100 may include more or fewer components than those shown in Figure 1A, which may be local or remote to one another and may be implemented in software and / or hardware. Each component may be distributed across multiple applications and / or machines, and multiple components may be combined into one application and / or machine. The operation described for one component may instead be performed by another component. Further embodiments and / or examples of this disclosure relating to computer networks are described below in Section 6 entitled “Computer Networks and Cloud Networks”. The application builder 106 includes or facilitates a stack for providing the functionality of the application builder 106, and such functionality includes or is associated with application (app) developers, e.g., SMART FHIR application developers. One or more of the user interface layout module 122, resource / parameter selection module 124, computer configuration module 126, authentication engine 128, and code generator 130 may be implemented in a system within the operating environment 100 separate from the computing system.

[0039] 3. App builder for accessing various health record systems

[0040] Referring to the elements described above in Figure 1A, the application builder 106 can create and utilize custom applications, such as SMART FHIR applications, with little to no coding required by clinicians and non-technical hospital staff. According to certain aspects of this disclosure, each custom application built via unique / specific user input to the application builder 106 can mitigate burnout by enabling healthcare providers to have a contextualized and sustained clinical view in conjunction with one or more EHR systems and by reducing the need to search for relevant information across diverse EHR systems in various healthcare provider facilities.

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

[0042] One embodiment of Application Builder 106 may include a software application, a set of applications, a software agent, a program, a module, a component, an application, a routine, a function, or a computer execution service, and / or may be implemented using a Belief-Want-Intention (BDI) software model. Embodiments of Application Builder 106 may reside on one or more servers in the computing system and / or cloud described above, or may 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 other computing devices.

[0043] In response to the execution of the application builder 106 by the user device 102 based on user input to the user device 102, the application builder 106 can identify a specific healthcare provider facility or a specific EHR system associated with a healthcare provider facility that the custom application being created can interact with. Identification can be based on default values ​​or settings, settings corresponding to previous use of the application builder 106, data associated with the user on the user device 102, or information somehow related to the current execution of the application builder 106 by the user device 102. For example, the application builder 106 can initiate the display of a user interface, such as a GUI, on the user device 102, and to enable user input, the user interface can present elements such as icons, such as buttons or thumbnail images, text, symbols, other items or images, diagrams, patterns, or dropdown menus. These elements can be configured to allow input into data fields, for example via a user device 102, or to be analyzed or otherwise processed by the application builder 106 and / or a custom application created by the application builder 106, and to be selected from data items associated with or stored in a database, such as a data store in an EHR system.

[0044] Figure 2 shows an exemplary set of actions performed by the application builder 106 to create a custom application with little or no coding by any user, according to one or more embodiments of the present disclosure. In one or more embodiments of the present disclosure, all or part of one or more actions may be performed by the corresponding hardware and / or software configured to perform the actions, for example, that hardware and / or software. One or more actions shown in Figure 2 may be modified, rearranged, or omitted entirely. Therefore, a particular sequence of actions shown in Figure 2 should not be construed as limiting the scope of one or more embodiments of the present disclosure.

[0045] In one or more embodiments, the system, for example, an application builder 106, receives user input to select a specific healthcare provider facility or a specific EHR system from which data will be extracted by the custom application being created (operation 202). In the embodiments shown in the Disclosure, the application builder 106 initiates a display on the user device 102 inviting the user to enter a selection of a specific healthcare provider facility or EHR system associated with (e.g., linked to, recognized, or otherwise communicating with) the custom application being created. In certain embodiments of the Disclosure, the application builder 106 may receive each of the user selections of healthcare provider facilities and / or EHR systems from which data will be extracted (or modified or added to) by the custom application.

[0046] An application that enables device access to information stored in EHR system 108 may not be able to enable device access to 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 properties between EHR systems. The application builder 106 can receive each of the user selections of healthcare provider facilities and / or EHR systems from which data is extracted (or modified or added) by the custom application, and can receive one or more additional user selections of one or more additional healthcare provider facilities and / or EHR systems from which data is extracted (or modified or added) by the custom application.

[0047] The user interface may present a first menu of elements to be displayed before receiving user input to select a specific healthcare provider facility or a specific EHR system for data extraction, for example, to be associated with the custom application being created. In response to the selection, for example, via a selection from a dropdown list associated with the first menu, the user interface may begin displaying an additional menu of additional elements to be displayed, identified based on the selection by the processor running the application builder 106, for example, the processor in the user device 102. In the example shown, the additional menu is associated with the information selected by the user via the first menu.

[0048] Therefore, the application builder 106 can receive user input to select multiple healthcare provider facilities or EHR systems that can be accessed by the custom application (operation 202). In overview, data in multiple healthcare provider facilities or EHR systems is typically stored in various formats, rather than in a standardized format. Traditionally, because each EHR system differs in its resources (i.e., patient medical record data), the format of those resources, etc., there is often no simple way to extract data from multiple EHR systems, for example, to retrieve it for processing. Embodiments of this disclosure recognize and take advantage of the expectation that in the near future all EHR systems will be required to implement / publish APIs that enable data extraction based on the FHIR standard published by Health Level Seven International, the standards development organization that also published the HL7 standard. This means that data extracted from various EHR systems using the corresponding API will be mapped to fields defined by the HL7 FHIR standard. For a given healthcare provider facility, such as a hospital, the local EHR system may not necessarily contain data for all fields corresponding to the EHR in the patient medical records at the healthcare provider facility. However, the data actually contained in the patient medical records at the healthcare provider facility can be mapped to fields in the HL7 FHIR standard. The HL7 FHIR standard currently supports 145 resource types, typically in XML, JSON, or the Concise Resource Description Framework (RDF) triple language format.

[0049] Based on each selected healthcare provider facility or EHR system, the application builder 106 begins determining the resources available for use by the custom application to be created (operation 204). The resources available for use by the custom application to be created typically vary based on the specific healthcare provider facility or EHR system. In the example shown, the resources available for use can be identified by analyzing metadata, e.g., attributes, based on the FHIR standard, corresponding to the selected healthcare provider facility or EHR system. This metadata can describe specific resources available for use by the custom application to be created, according to the HL7 FHIR standard. Here, each resource available in the selected healthcare provider facility or EHR system may correspond to a packet of information usable for data exchange or storage that satisfies most use cases in the clinical environment of the selected healthcare provider facility or EHR system.

[0050] In exemplary embodiments of this disclosure, a resource "user" is identified as an available resource by analysis of metadata corresponding to a selected healthcare provider facility or EHR system. The resource "user" or "practitioner" may refer to a person directly or indirectly involved in the provisioning of healthcare or healthcare-related services as part of their formal responsibility, for example, in accordance with HL7. This resource is used to attribute activities and responsibilities associated with individuals who may engage in work including physicians, dentists, pharmacists, physician assistants, nurses, scribes, midwives, dietitians, therapists, optometrists, emergency medical technicians, medical technologists, laboratory scientists, prosthodontists, radiographers, social workers, professional home caregivers, official volunteers, receptionists handling patient registration, or IT personnel performing the merging or separation of patient records. A practitioner or user may perform 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 it may be necessary to have a single resource, such as a practitioner, that holds multiple roles. This resource is not intended for individuals who do not have formal responsibility, such as those caring for friends or relatives. Such individuals may be described by alternative resources, such as the "related person" resource, to the extent that they perform some action or are referenced by another resource. Concepts not included in the HL7 definition of the resource can be found in the HL7 definition or reference resource parameters, such as "patient's contact."

[0051] Analysis of metadata corresponding to selected healthcare provider facilities or EHR systems can also identify the "patient" resource as available. The "patient" resource may, for example, cover demographic and administrative data about patients at healthcare provider facilities receiving care, according to HL7. This resource describes a wide range of patient health-related activities, including therapeutic activities, psychiatric treatment, social services, pregnancy management, nursing and assisted living, nutrition services, and tracking of individual health and exercise data. The data in this resource focuses on "who" information about the patient, and its attributes focus on demographic information necessary to support administrative, financial, and logistical procedures. It should be noted that patient medical records are generally created and maintained by each organization providing care to the patient; therefore, patients receiving care from multiple healthcare providers or at multiple healthcare provider facilities may have their information in multiple patient resources. Concepts not included in the HL7 definition of the "patient" resource, such as race, ethnicity, organ donor status, and nationality in the current example, can be found in related resources or in HL7 defined resource parameters such as "profiles" or "extensions" used with or associated with the "patient" resource.

[0052] Continuing with operation 204, based on the resources determined by the metadata analysis, the application builder 106 can present the determined resources to the user for review, modification, or selection. For example, the application builder 106 can initiate the display of the determined resources as part of a second menu, or through a user interface associated therewith, for the user to review, modify, or select. For example, the second menu may include a dropdown menu that displays elements corresponding to all or some of the resources determined to be available in the selected healthcare provider facility or EHR system, for the user to select.

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

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

[0055] Based on the user's selection from a subset of resources, and / or the selection of a healthcare provider facility or EHR system, the application builder 106 may present the user with an additional menu containing additional resources that were determined to be available in the selected healthcare provider facility or EHR system but were not presented in the second menu. For example, if the subgroup of resources presented in the second menu includes three resources—patient, test results, and insurance claims—and only the first of these three resources is selected, an additional menu may be presented. The additional menu may include three resources—pharmacotherapy, workflow, and finance—each related to "patient" and selectable via input to the user interface (e.g., via input from a user device 102 operated by the user), based on the user's selection of "patient." Thus, the application builder 106 may present resources determined to be available iteratively, sequentially, or in other multi-menu formats, and / or the application builder 106 may receive selections for resource presentations iteratively, sequentially, or in other multi-menu response formats.

[0056] Based on menu selections made via additional menus, second menus, and / or first menus, and / or based on an analysis of metadata associated with the menu selections, the application builder 106 may present one or more additional menus via the user interface to present further resources that have been determined to be available for, for example, a custom application being created. These additional menus may present resources that have been determined to be one or more subcategories of the resources selected via the second menu or additional menus, or more specific resources relating to them. For example, an additional menu may present additional resources that have been determined to be available for a selected healthcare provider facility or EHR system but were not presented in the second menu or additional menus.

[0057] In an exemplary embodiment, resources corresponding to one or more of more generalized categories, such as patients, test results, and insurance claims, determined from among others by metadata analysis, are presented in a second menu, followed by the presentation of additional resources by the application builder 106, for example, in an additional menu, where the additional resources are also determined by analyzing metadata based on selected healthcare provider facilities or EHR systems. Each of the resources in the additional menu may further, or alternatively, be determined by analyzing metadata associated with one or more of the resources selected by the user via the second menu.

[0058] In exemplary embodiments of this disclosure, including additional menus or other menus, based on a resource "patient" selected by the user via a second menu and optionally metadata associated with the "patient" resource, the additional menu may present one or more resources for user selection from groups including clinical, diagnostics, medications, workflow, or financial, for example, in accordance with the HL7 standard. Furthermore, based on a resource "clinical" selected by the user via a second menu and optionally metadata associated with the "clinical" resource, the additional menu may present one or more resources for user selection from groups including allergyintolerance, condition (problem), procedure, familymemberhistory, careplan, goal, careteam, clinicalimpression, adverseevent, detectedissue, and riskassessment. Furthermore, based on the "diagnostics" resource selected by the user via the second menu, and optionally the metadata associated with the "diagnostics" resource, an additional menu may present one or more resources for the user to select from a group including, for example, observation, report, specimen, imagingstudy, genomics, specimen, and imagingstudy, in accordance with the HL7 standard.

[0059] Furthermore, based on the "medications" resource selected by the user via the second menu, and optionally based on the metadata associated with the "medications" resource, the application builder 106 can present the user with an additional menu containing one or more resources from a group including medication, request, dispense, administration, statement, and immunization, for example, in accordance with the HL7 standard. Also, based on the "workflow" resource selected by the user via the second menu, and optionally based on the metadata associated with the "workflow" resource, the additional menu can present the user with one or more resources from a group including introduction, task, appointment, schedule, referral, and plandefinition, for example, in accordance with the HL7 standard. In addition, based on the "financial" resource selected by the user via the second menu, and optionally the metadata associated with the "financial" resource, an additional menu may present one or more resources for the user to select from a group including, for example, claim, account, invoice, chargeitem, coverage, eligibility, request, response, and explanationofbenefit, in accordance with the HL7 standard.

[0060] In operation 208, based on one or more resource selections received, for example in operation 206, the application builder 106 identifies configurable resource parameters corresponding to each of the one or more received resource selections. For example, the application builder 106 analyzes metadata corresponding to each received resource selection to identify one or more configurable resource parameters corresponding to the selected resource. For example, a third menu may include a dropdown menu for user selection that displays elements corresponding to the configurable resource parameters available for the selected "patient" resource. The configurable resource parameters for "patient" may include, for example, one or more selections of read access to data in the selected healthcare provider facility or EHR system corresponding to the HL7 FHIR resource "patient", and / or write access to data in the selected healthcare provider facility or EHR system corresponding to the HL7 FHIR resource "patient".

[0061] In one embodiment, the application builder 106 presents the user with one or more configuration fields that provide corresponding choices for configuring a configurable resource parameter (operation 210). These one or more configuration fields may enable selections for configuring actions that can be performed by or in connection with the execution of the custom application being created. These actions may include one or more extractions, modifications, or presentations of one or more selected resources. The actions may be associated with the extraction, modification, and / or presentation of data associated with (a) a selected healthcare provider facility or EHR system, (b) a resource selected via a second menu, an additional menu, or any other menu, and / or (c) details or options regarding the implementation of the configurable resource parameter identified in operation 208. In exemplary embodiments of this disclosure, for each configurable resource parameter identified in operation 208, the application builder 106 presents a third or more menus relating to the configuration of actions that the custom application can perform on the selected resource or information associated with the selected resource. The third menu can display 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 allow information input, via a user interface (for example, via a user device 102 operated by the user).

[0062] The application builder 106 receives one or more inputs, e.g., selections, of configuration values ​​corresponding to configurable resource parameters presented by the application builder 106 in a third menu of configurable resource parameters (operation 212). Resource parameters include parameters determined based on the application builder 106 analyzing metadata corresponding to each received resource selection to identify one or more configurable resource parameters corresponding to the selected resource. For example, the application builder 106 receives inputs, e.g., specifying, that indicate the configuration values ​​of configurable resource parameters presented by the application builder 106 in the third menu of resources, through user interaction with a third menu displayed via the user interface.

[0063] Based on the configuration values, the application builder 106 generates code (operation 214) to extract, modify, or present data associated with or from (i) selected healthcare provider facilities and / or (ii) selected EHR systems. For example, code may be generated that enables a custom application to perform an operation including extracting, modifying, or presenting data associated with one or more selected healthcare provider facilities or EHR systems, and the resources are selected via a second menu, an additional menu, or yet another menu. Alternatively or in addition, code may be generated that enables a custom application to perform an operation related to configuration values ​​selected via a third menu, and / or configurable resource parameters and / or details or options regarding the implementation of the configuration values. For example, all or subsets of the first, second, additional, yet another, and third menus, or any part thereof, can be presented in various combinations, simultaneously or at different times, and / or in different arrangements, formats, or orders. In some embodiments, the application builder 106 sends a link to the user device 102 or another device associated with the creation of the new custom application, which identifies the web address of the newly created custom application, for example, by a Uniform Resource Locator (URL).

[0064] As described above, the application builder 106 may include or provide functionality for application (app) developers, such as SMART FHIR application developers, to create custom applications. The code generated by the application builder 106, for example, to access, modify, and / or develop, can create or facilitate the creation of one or more custom applications or parts of one or more custom applications. In an embodiment, during the creation of a custom application, the application builder 106 may automatically generate code corresponding to necessary FHIR calls based on the HL7 FHIR standard, for example, to enable data fetching / extraction during the execution of the custom application. For example, based on a selection made via input from a user device 102, the exemplary code generator 130 shown generates API calls, such as FHIR-based calls, necessary to extract / retrieve and process user-selected data displayed during subsequent execution of the custom application. Thus, the embodiment of this example can leverage mapping to FHIR concepts as needed or instructed.

[0065] Technologies and systems for generating code that can facilitate the creation of custom applications, such as accessing, modifying, and / or developing code, may be based on known technologies or applications related to code generation, or modifications or extensions thereof. For example, technologies and systems for generating code to create custom applications (e.g., code to perform EHR data extraction, modification, and presentation as described herein with reference to operations 216-218) may correspond to those used in or referenced in connection with the Oracle Application Express (APEX) platform provided by Oracle Corporation in Redwood Shores, California. Other technologies and systems for generating code to create custom applications may correspond to known concepts and technologies in the art, including, for example, those used in or referenced in connection with U.S. Patent No. 9,373,094 and the SMART on FHIR platform (smarthealthit.org) provided by the Computational Health Informatics Program of Boston Children's Hospital in Boston, Massachusetts, all of which are incorporated herein by reference. The code generated by the application developer 106 can configure the custom application to perform actions associated with defining certain clinical information representations of extracted data or related data in various ways, tables, summaries, and subsummaries, according to individual, for example, specific needs or goals associated with user input received by the application builder 106 during the creation of the custom application.

[0066] The code used by the application builder to construct a custom application can be stored, for example, in the data repository 120, within or associated with one or more libraries of reusable resources, components, source files, and / or GUI controls (such as a drag-and-drop GUI builder). For example, source files that can be created, modified, stored, and retrieved may include files containing program instructions, source code, source data, or essential data (e.g., as a starting point for a processing system). In one example, a set of code is predefined for each EHR system, and in operation 202, for example, the set of code is selected based on the selected EHR system. The set of code may include API calls as described herein. One or more of the computing system, user device 102, EHR system 108, or other components may store the code associated with resource selection as variables, which, after creation, are used by the custom application as parameters for API calls. Furthermore, one or more of the computing system, user device 102, EHR system 108, or other components can, after creation, generate code that incorporates authentication keys to enable a custom application to access, for example, a healthcare provider facility or the EHR system.

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

[0068] In one or more embodiments, as described herein, one or more of the computing system, user device 102, EHR system 108, or other components present the extracted data and, optionally, the processed data associated with the extracted data (operation 218). In addition or alternatively, in certain embodiments, one or more of the computing system, user device 102, EHR system 108, or other components may present at least a portion of the extracted data or information indicating the extracted data, and further may 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 other components may present one or both of the extracted data and / or 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).

[0069] Presentation, for example, a display operation, can be performed under the control of or in connection with a custom application being executed. In certain embodiments, a presentation operation may be initiated or executed in or by one or more of the computing system, user device 102, EHR system 108, or other components, and may present at least a portion of the extracted data or information indicating the extracted data. Alternatively or in addition, a presentation operation may present at least a portion of the processed data or information indicating the processed data. For example, a presentation operation may display data retrieved from or associated with a selected healthcare provider facility or EHR system, for example, data extracted from one or both of EHR system 108 and EHR system 110.

[0070] In exemplary embodiments, a presentation operation corresponding to, for example, operation 218, can display content according to user-selected parameters such as the number of pages, rows, and columns, as shown and described, for example, in relation to the exemplary display 340 in Figure 3D. In the exemplary display 340, user input to the application developer 106 defines a field (0,0) for the custom application to present data from selected healthcare provider facilities or EHR systems during execution, which has been extracted and processed according to a user-defined "Fibrosis-4" computer, as defined, for example, via the user interface 330 in Figure 3C.

[0071] The presentation behavior in an exemplary embodiment may further include, for example, user-defined fields (0,1), (1,0), and (1,1) configured to present data (extracted and processed from a selected healthcare provider facility or EHR system) according to additional user-defined computers: “Observation | VITAL SIGN (BMI)”, “MedicationRequest”, and “Observation | LAB (Creatnine)”, respectively. In addition or alternatively, other computers (e.g., routines), objects, or other processes defined or acquired elsewhere (e.g., via a user device 102 operated by the user) may be presented during the execution of the custom application. As an example, other routines, objects, or processes may include, for example, those corresponding to any application available to the user or that can be made available to the user for use during the creation of the custom application. Such routines may include items or objects included in or related to the Content of this Disclosure, such as algorithms, applications, BDI software models, components, components embodied as part of or within other components, computer execution services, elements, functional entities, functions, ML algorithms, modules, behaviors, processes, hardware, firmware, and / or software, as well as processes, programs, routines, agents, and supervised or unsupervised components.

[0072] In one or more embodiments of the present disclosure, for example, an ML algorithm based on or corresponding to ML model data 148 in a data repository 120 may be included in or accessible, for example via a user interface 330, in a specific custom application being developed (created) by an application builder 106. For example, the ML algorithm can iterate, for example, using a set of training data, to learn a target model f that best maps a set of input variables to output variables. For example, such an ML algorithm in an embodiment may be configured to generate and / or train an emergency care or emergency room model during the execution of the custom application. For example, the training data stored with the ML model data 148 in the data repository 120 may include datasets and associated labels as well as codes associated with them. These datasets can then be associated with the input variables of the target model f, and the associated labels can be associated with the output variables of the target model f during the execution of the custom application.

[0073] The training data can be updated during the execution of the custom application, for example, based on feedback regarding the accuracy of the current target model f. For example, the updated training data, stored in the data repository 120 along with the ML model data 148, can be fed back to the ML algorithm during the execution of the custom application, thereby updating 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 maximum number of results can be determined by the target model f as matches to the labels of the training data. Furthermore, according to aspects of this disclosure, for example, the generated code corresponding to the target model f configured to best fit the training data dataset to the labels of the training data can be applied to the training data dataset to identify a desired dataset. Different target models can be generated based on different ML algorithms and / or different sets of training data.

[0074] As described herein, 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, learning vector quantization, support vector machines, bagging and random forests, boosting, backpropagation, and / or clustering.

[0075] Figure 3D shows an exemplary display 340 presented to the user on, for example, a user device 102 during the execution of a custom application created by the application builder 106 based on (using) user interfaces 310, 320, and 330. This display is based on a user-customized computer, e.g., "Fibrosis-4," defined via user interface 320 and configured to allow processing using both user-selected extracted data and user-defined formulas corresponding to the "Fibrosis-4" computer during the execution of the custom application. For example, display 340 includes a user-defined plot defined via user interfaces 320 and 330 and illustrates sample processing by the custom application of information, e.g., data extracted from one or both of EHR systems 108 and 110, based on the user-defined "Fibrosis-4" computer and operations 202-212. In an exemplary embodiment, the "Fibrosis-4" computer is constructed, for example, via a user interface 320 to execute the mathematical expression "(Age * AST) / (Platelets * √ (ALT) )" via code generated by the application builder 106, for example, in operation 214.

[0076] Some embodiments of these methods facilitate decision-making by dynamically displaying user-related patient information during the execution of a custom application (e.g., created via input from a user device 102 controlled by the user). User-related patient information may represent, relate to, extract from, or derive 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) to (iii), or (v) other items such as information indicating the patient's condition or indicating a recommendation for treatment for the patient. The electronic models, electronic adaptive agents, and / or electronic models including electronic adaptive agents described above may be used to determine user-related patient information by, for example, implementing techniques known to those skilled in the art in the relevant technical field, including data processing, data synthesis, and data learning techniques. For example, during the execution of a custom application, a clinician interface generated on the user device 102 can facilitate access to and reception of information about a particular patient or set of patients, reception of information such as patient information, selections, queries, commands, or actions, and display of results, recommendations, or instructions. In some embodiments, the clinician interface facilitates the reception of instructions from the clinician / user to the patient based on the results. In some embodiments, the clinician interface includes a GUI configured to facilitate clinical decision support, and / or provide diagnostic or update services such as creating, evaluating, or modifying content tables used in state programs, predictive models, libraries, and / or agents related to health status programs, for example, under or in connection with the operation of a custom application as described herein. The GUI can be configured to facilitate human confirmation of computer-derived decisions such as actions, recommendations, diagnoses, linkages, or other such services.

[0077] In embodiments of this disclosure, for example, the EHR system 108 can be FHIR compliant as described above and can be configured to map to one or more patient medical records associated with a specific hospital or patient medical records associated with an HIE platform and related to immune status. In some embodiments, retrieval by a custom application from EHR system resources corresponding to patient data artifacts associated with at least one patient record in the EHR system can be performed via any one or more of the models or adaptive agents described above, such as applying ML and / or AI models to the information. As described above, the operations described herein may include the execution of a machine learning model, which 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. Furthermore, as described above, operations performed during the execution of the custom application may include presenting information associated with the patient data artifacts to obtain treatment guidance.

[0078] User-related information can correspond to the treatment session context, such as the caregiver's role or area of ​​expertise (e.g., cardiologist, urologist, social worker, etc.), or to the treatment venue, such as a research hospital, walk-in clinic, or emergency room, or to one or more conditions or clinical decision support events associated with the patient. Therefore, in some embodiments, user-related information that may be presented through the execution of a particular custom application may vary, change flexibly, or differ based on the choices made by a particular user during the execution of the application builder 106 while the particular custom application is being created by that particular user, and based on the context of a particular execution of that particular custom application. For example, the execution of a custom application created for a cardiologist treating a heart attack patient in an emergency care or emergency room setting may, according to the custom application created for the cardiologist and according to the execution of the cardiologist's custom application, trigger the presentation of certain types of patient information, such as the patient's vital signs, medications, and previous heart disease diagnoses. On the other hand, the execution of another custom application created for endocrinologists treating diabetic patients in research hospitals may trigger data presentations in accordance with other custom applications relevant to the endocrinologist's specific needs, and in accordance with specific executions of other custom applications by the endocrinologist. For example, the execution of other custom applications may trigger data presentations from, for example, one or both of EHR systems 108 and 110, in relation to (and in addition to) (and thus extended to) patient compliance with clinical studies in which the patient is enrolled and prescribed condition management regimens.

[0079] In some embodiments of this disclosure, a software routine or software agent, such as an electronic model, an electronic adaptive agent, and / or an electronic model including an electronic adaptive agent, facilitates any one or more parts or all of any one or more of operations 202-214, such as the automatic addition of information or user options to any of the user interfaces 310-330. In exemplary embodiments, a software agent or software routine may, for example, automatically populate or configure displayed menus, displayed fields, or add text boxes (or drop-down menus) for additional information input (or selection), based on previous use of the application builder 106 and / or an identity associated with the user or user device. In some embodiments of this disclosure, an "autocomplete" field may be presented in relation to one or more of the user interfaces 310-330, providing feedback to the user indicating, for example, whether all information for a particular user interface has been provided by the user (YES), or whether there are fields where information is missing or incorrectly presented by the user (e.g., a field requiring only "Y" or "N" has a number or character other than "V / N" entered).

[0080] 4. Exemplary Embodiments

[0081] Detailed examples are provided below for clarity. The components and / or operations described below should be understood as one specific example 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 of the claims.

[0082] Currently, when clinicians using EHRs wish to obtain a SMART-based software application for specific workflows associated with their clinician, users often have no choice but to make a request to their EHR system provider and expect it to be built or built in a timely manner. The process involved in fulfilling this request is extremely time-consuming, requires various resources, creates integration difficulties, and can add considerable cost to the user's expected workflow. This disclosure enables non-developers (clinicians) to define clinical information representations in various formats, tables, summaries, and subsummaries through custom applications, according to the user's individual, for example, unique needs or goals.

[0083] This disclosure enables a user to create and store a library of reusable resources, components, and GUI controls (such as a drag-and-drop GUI builder) in, for example, a data repository 120. For example, one or more of the computing system, user device 102, EHR system 108, or other components (e.g., related to either or both of the application builder 106 or the data repository 120) can generate code for a custom application (e.g., substantially, entirely, or partially) by developing functions, routines, or specific API calls based on functions, routines, or API calls stored in the data repository 120. In some embodiments, one or more of the computing system, user device 102, EHR system 108, or other components can generate code for a custom application partially or entirely by retrieving (and / or referencing) functions, routines, or specific API calls stored in the data repository 120. During the deployment of a custom application, an embodiment of the application builder 106 automatically generates code corresponding to necessary FHIR calls based on the HL7 FHIR standard, for example, to enable data fetching during the execution of the custom application. Based on selections made by the user, the code generator 130 of the disclosure generates API calls, such as FHIR calls, necessary to retrieve and process user-selected data displayed during subsequent executions of the custom application. Thus, embodiments of the disclosure leverage mappings to FHIR concepts for instructions or as needed.

[0084] A brief reference to Figures 3A to 3C illustrates exemplary user interfaces for receiving information from a user regarding the operation, access, and parameter settings to be used by the custom application being developed. In particular, the figures illustrate exemplary user interfaces for receiving user input and selections, for example via a user device 102, which specify the preferences and details to be included in the functions and capabilities of the custom application being developed by the application builder 106. The information entered into the application builder through the user interface (which may include, for example, one or more of the first, second, additional, yet other, and third menus, or any part thereof) enables the user to create the custom application with little or no coding by that user, and the custom application, after creation, is configured to access, process, and present data related to one or more specific healthcare provider facilities or specific EHR systems.

[0085] Figure 3A shows an exemplary user interface 310 that may be presented following a selection of a specific healthcare provider facility or EHR system (e.g., via a user device 102 operated by the user), and includes displayed options available to the user for selecting resources and resource parameters for the custom application to be created. Based on the selection of a specific healthcare provider facility or EHR system received, for example in operation 202, and based on the analysis of metadata associated with the specific healthcare provider facility or EHR system to determine resources that may be available for the custom application after creation, for example in operation 204, the application builder 106 may determine that resources, including "User" and "Patient" resources corresponding to those shown at the top of the user interface 310, may be presented. The user interface 310 can be thought of as including or corresponding to a combination of a second menu (see the operation immediately preceding operation 206 in Figure 2) and a third menu (see operation 210) presented in a single display, or it may be presented alternately in two consecutive displays, for example, in response to and based on metadata determined by the application builder 106 to be associated with the selected healthcare provider facility or EHR system.

[0086] In the illustrated embodiments of this disclosure, separate selection options (e.g., checkboxes) for the “User” and “Patient” resources are not shown. Embodiments of this disclosure may present the user interface 310 as an additional menu (discussed above) following the presentation of a second menu (discussed above) that leads to the user selection of the “User” and “Patient” resources. In other embodiments of this disclosure, the default settings of the application builder 106 cause the presentation of the “User” and “Patient” resources as automatically selected resources in the initial user interface corresponding to, for example, a second menu (see the operation immediately preceding operation 206 in Figure 2) and a third menu (as in operation 210), based on two resources determined to be available for the selected healthcare provider facility or EHR system.

[0087] Figure 3B shows another exemplary user interface 320 that may be presented following one or more selections (e.g., via a user device 102 operated by the user) of a particular healthcare provider facility or EHR system. User interface 320 presents user options (e.g., via a user device 102 operated by the user) that are available for selecting elements including “resource type” and “resource parameters”. The selection of a resource type from the resource type dropdown menu of the resource type to be selected (e.g., based on the application builder 106 analyzing metadata as discussed herein) causes the application builder 106 to populate a resource parameter dropdown menu with specific resource parameters related to the selected resource type, at least based on the metadata associated with the selected resource type. Furthermore, the "Operator Selection" button and "Formula" field of the user interface 320 allow the user to associate selected resource types and resource parameters (e.g., collectively referred to as "operators") with a formula (e.g., based on the selected "operator") for the execution and presentation of the custom application, such as display, based on available data (in the selected healthcare provider facility or EHR system) corresponding to the selected resource and related information, including parameter values.

[0088] As shown in Figure 3B, the user names the current formula being constructed, e.g., the calculator, "Fibrosis-4," based on the input of title characters, e.g., by typing, into the "Naming" or "Calculator Name" field located at the top of the user interface 320. The user interface 320 is configured to facilitate the user's definition of one or more user-customized calculators, e.g., the "Fibrosis-4" calculator, by defining specific formulas for each user-customized calculator, e.g., the association of variables performed by the formulas. The displayed exemplary calculator is configured to allow processing by a later-created custom application of information based on data extracted during the execution of the custom application from one or more healthcare provider facilities or EHR systems, e.g., EHR system 108 and EHR system 110, selected, e.g., in operation 202. In an exemplary embodiment, the formula for the computer under development, which is in the process of being defined as shown, is displayed in the "Fibrosis-4 Computer Formula" window as "('Age * AST) / (')", and the formula becomes available for use in the execution of a custom application based on the code generated by the application builder 106.

[0089] Figure 3C shows an exemplary user interface 330 configured to allow the user to select display or configuration options to be used by a custom application later created during execution to present data obtained from or associated with a selected healthcare provider facility or EHR system, for example, data extracted from one or both of EHR systems 108 and 110. In the exemplary description, the user selects 1 page for “Number of pages,” and further selects 2 rows and 2 columns for “Number of rows” and “Number of columns.” As shown in the exemplary configuration of user interface 330, the user defines a field (0,0) for the custom application to present data from the selected healthcare provider facility or EHR system, extracted and processed according to the “Fibrosis-4” computer, as defined, for example, via user interface 320, during execution.

[0090] According to the illustrated embodiment, additional computers such as “Observation | VITAL SIGN (BMI)”, “MedicationRequest”, and “Observation | LAB (Creatinine)” are defined to be presented by the custom application during execution, for example, based on the user interacting with user interfaces 320 and 330. The additional computers “Observation | VITAL SIGN (BMI)”, “MedicationRequest”, and “Observation | LAB (Creatinine)” are presented by the custom application during execution to fields (0,1), (1,0), and (1,1), respectively. In addition or alternatively, other computers (e.g., routines), objects, or other processes defined or obtained elsewhere (e.g., via user device 102 operated by the user) may be selected or incorporated by the user creating the custom application for use during the execution of the custom application. For example, other routines, objects, or processes may include, for example, those corresponding to any application available to the user, or deemed useful for the user's intended purpose in creating a custom application, or that can be made available to the user for use by a custom application. Such routines may include items or objects described herein such as algorithms, applications, BDI software models, components, components embodied as part of or within other components, computer execution services, elements, functional entities, functions, ML algorithms, modules, behaviors, processes, hardware, firmware, and / or software, as well as processes, programs, routines, agents, and supervised or unsupervised components.

[0091] 5. Computer networks and cloud networks

[0092] In one or more embodiments, a computer network provides connectivity between sets of nodes. These nodes may be local and / or remote to one another. The nodes are connected by a set of links. Examples of links include coaxial cables, uninsulated twisted cables, copper cables, optical fibers, and virtual links.

[0093] A subset of nodes implements computer networks. Examples of such nodes include switches, routers, firewalls, and network address translators (NATs). Another subset of nodes utilizes computer networks. Such nodes (also called "hosts") can run client processes and / or server processes. For example, a client process started on user device 102 makes requests for computing services (such as a specific application, e.g., application builder 106, running a custom application, and / or storing a specific amount of data). A server process responds by performing the requested service and / or returning the corresponding data.

[0094] A computer network can be a physical network containing 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. In addition or alternatively, a physical node can be a general-purpose machine configured to run various virtual machines and / or various applications, each performing its respective function. A physical link is a physical medium connecting two or more physical nodes. Examples of links include coaxial cables, uninsulated twisted cables, copper cables, and optical fibers.

[0095] A computer network can be an overlay network. 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 each node in the underlying network. Therefore, each node in an overlay network is associated with both an overlay address (for addressing the overlay node) and an underlay address (for addressing the underlay node that implements the overlay node). Overlay nodes can be digital devices and / or software processes (such as virtual machines, specific application instances, or threads). Links connecting overlay nodes are implemented as tunnels through the underlying network. The overlay nodes at both ends of the tunnel treat the underlying multi-hop path between these overlay nodes as a single logical link. Tunneling is performed through encapsulation and deencapsulation.

[0096] In embodiments of the disclosure, the client may be local and / or remote to the computer network. The client may access the computer network via a private network or other computer network such as the Internet. The client may communicate requests to the computer network using a communication protocol such as the Hypertext Transfer Protocol (HTTP). Requests are communicated through an interface such as a client interface (such as a web browser), a program interface, or an API.

[0097] In embodiments of this disclosure, a computer network provides connectivity between clients and network resources. Network resources include hardware and / or software configured to run 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 requests and / or clients on an on-demand basis. Network resources allocated to each request and / or client may be scaled up or down based, for example, (a) computing services requested by a particular client, (b) aggregated computing services requested by a particular tenant, and / or (c) aggregated computing services requested to the computer network. Such a computer network may also be referred to as a “cloud network”.

[0098] In embodiments of this disclosure, a service provider provides a cloud network to one or more end users. Various service models, including, but not limited to, Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS), can be implemented by the cloud network. In SaaS, the service provider provides end users with the ability to use the service provider's applications running on network resources. In PaaS, the service provider provides end users with 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 provides end users with the ability to provision processing, storage, network, and other basic computing resources provided by the network resources. Any application, including an operating system, can be deployed on the network resources.

[0099] In embodiments of this disclosure, various deployment models, including but not limited to private clouds, public clouds, and hybrid clouds, can be implemented by the computer network. In a private cloud, network resources are provisioned for exclusive use by a specific group of one or more entities (wherein used herein, the term “entity” refers to a company, organization, person, or other entity). Network resources may be local and / or remote to the premises of a particular group of entities. In a public cloud, cloud resources are provisioned for multiple entities that are independent of each other (also referred to as “tenants” or “customers”). The computer network and its network resources are accessed by clients corresponding to different tenants. Such a computer network may be referred to as a “multitenant computer network”. Several tenants may use the same particular network resources at different times and / or at the same time. Network resources may be local and / or remote to the tenant’s premises. In a hybrid cloud, the computer network comprises a private cloud and a public cloud. Interfaces between the private cloud and the public cloud enable data and application portability. Data stored in the private cloud and data stored in the public cloud can be exchanged through these interfaces. Applications running in a private cloud and applications running in a public cloud may have dependencies on each other. Calls from an application in the private cloud to an application in the public cloud (and vice versa) may be made through an interface.

[0100] In embodiments of this disclosure, tenants in a multi-tenant computer network are independent of each other. For example, the business or operations of one tenant may be separate from the business or operations 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 implement the different network requirements requested by different tenants.

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

[0102] 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 the tenant ID. A tenant is permitted access to a particular network resource only if the tenant and the particular network resource are associated with the same tenant ID.

[0103] In embodiments of this disclosure, each tenant is associated with a tenant ID. Each application implemented by the computer network is tagged with the tenant ID. In addition, or alternatively, each data structure and / or dataset stored by the computer network is tagged with the tenant ID. A tenant is granted access to a particular application, data structure, and / or dataset only if the tenant and the particular application, data structure, and / or dataset are associated with the same tenant ID.

[0104] As an example, each database implemented by a multi-tenant computer network may be tagged with a tenant ID. Only tenants associated with the corresponding tenant ID can access the data in a particular database. As another example, each entry in a database implemented by a multi-tenant computer network may be tagged with a tenant ID. Only tenants associated with the corresponding tenant ID can access the data in a particular entry. However, the database may be shared by multiple tenants.

[0105] In embodiments of this disclosure, the subscription list indicates which tenants have authentication to access which applications. For each application, a list of tenant IDs of tenants authenticated to access the application is stored. A tenant is permitted to access a particular application only if their tenant ID is included in the subscription list corresponding to that application.

[0106] In embodiments of this disclosure, network resources (such as digital devices, virtual machines, application instances, and threads) corresponding to different tenants are isolated in tenant-specific overlay networks maintained by a multi-tenant computer network. For example, packets from any source device in a tenant overlay network can only be sent to other devices within the same tenant overlay network. Encapsulation tunnels are used to prevent transmission from any source device on one tenant overlay network to any device in another tenant overlay network. Specifically, packets received from a source device are encapsulated within an external packet. The external 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 tenant overlay network). The other encapsulation tunnel endpoint decapsulates the external packet to retrieve the original packet sent by the source device. The original packet is then sent from the other encapsulation tunnel endpoint to the destination device in the same specific overlay network.

[0107] 6. Microservices Applications

[0108] According to one or more embodiments, the techniques described herein are implemented in a microservices architecture. In this context, a microservice refers to software logic having endpoints that are designed to be independently deployable and can be logically coupled to other microservices to build various applications. Applications built with microservices are designed as a single fixed unit and differ from monolithic applications, which generally contain a single logical executable file. With microservices applications, different microservices can be deployed independently as separate executable files. Microservices can communicate via API endpoints using hypertext transfer protocol (HTTP) messages and / or according to other communication protocols. Microservices may be managed and updated separately, may be written in different languages, and may run independently of other microservices.

[0109] Microservices provide flexibility in managing and building applications. Different applications can be built by connecting different sets of microservices without changing the source code of the microservices. Thus, microservices function as logical building blocks that can be deployed in various ways to build different applications. Microservices can provide monitoring services that notify a microservice manager (such as If-This-Then-That (IFTTT), Zapier, or Oracle Self-Service Automation (OSSA)) when a trigger event occurs from a set of trigger events exposed to the microservice manager. Alternatively, or in addition, microservices exposed to an application can provide action services that perform actions in the application based on data received from the microservice manager (controllable and configurable via the microservice manager by passing values, thereby connecting the actions to data passed from other triggers and / or other actions within the microservice manager). Microservice triggers and / or actions can be linked together to form a recipe of actions that occur in any different applications that are unaware of, control, or depend on each other. Managed applications can be authenticated using, for example, an application certificate provided by the user to the microservices manager, or plugged into the microservices manager, without requiring re-authentication each time they are used, either alone or in combination with other applications.

[0110] trigger

[0111] According to one or more embodiments, the techniques described above can be encapsulated in a microservice. In other words, a microservice can, based on the techniques described above, trigger notifications (to a microservice manager for optional use by other plugged-in applications referred to herein as “target” microservices) and / or be presented as a GUI block and connected to one or more other microservices. A user can connect the output of one microservice to the input of another microservice using a pointed arrow or any other GUI element, thereby enabling a computing system or application builder 106 to perform verification tests to ensure that the outputs and inputs are compatible, for example, by checking data types or size limitations.

[0112] Trigger conditions can include absolute or relative thresholds for values, and / or absolute or relative thresholds for the amount or duration of data to be analyzed, so that a trigger is generated on the microservice manager whenever a plugged-in microservice application detects that a threshold has been exceeded. For example, when a microservice application detects that a value has exceeded a trigger threshold, the user can request a trigger on the microservice manager.

[0113] In one embodiment of the present disclosure, a trigger may, upon satisfaction, output data for consumption by a target microservice. In another embodiment of the present disclosure, upon satisfaction, a trigger may output a binary value indicating that the trigger has been satisfied, or the name of the field or other contextual information that satisfied the trigger condition. In addition, or alternatively, a target microservice may connect to one or more other microservices, thereby triggering alerts to those other microservices. The other microservices may then perform response actions based on the techniques described above, including but not limited to deploying additional resources, adjusting system configurations, and / or generating GUIs.

[0114] action

[0115] In one or more embodiments, a plugged-in microservice application can expose actions to a microservice manager. The exposed actions can receive data, or the ID of a data object or data location that moves data into a data cloud, as input.

[0116] In one or more embodiments, a published action may receive as input a request to increase or decrease an existing alert threshold. The input may identify an existing in-application alert threshold and specify whether to increase, decrease, or delete that threshold. In addition, or alternatively, the input may request the microservice application to create a new in-application alert threshold. In-application alerts can trigger alerts to users while they are logged into the application, or they can trigger alerts to users using default or user-selected alert mechanisms available within the microservice application itself, rather than through other applications plugged into the microservice manager.

[0117] In one or more embodiments, a microservice application can generate and provide output based on inputs that identify, locate, or provide historical data, or inputs that define the breadth or range of a requested output. When triggered, the action causes the microservice application to provide, store, or display the output, for example, as a data model or as aggregated data describing a data model.

[0118] 7. Hardware Overview

[0119] According to one embodiment of the present disclosure, the techniques described herein are implemented by one or more dedicated computing devices. These dedicated computing devices may be wired together to perform these techniques, or may include (i) one or more application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or network processing units (NPUs) digital electronic devices permanently programmed to perform these techniques, or (ii) one or more general-purpose hardware processors programmed to perform these techniques in accordance with program instructions in firmware, memory, other storage, or a combination thereof. Such dedicated computing devices may also combine custom hardwired logic, ASICs, FPGAs, or NPUs with custom programming to perform these techniques. Dedicated computing devices may be desktop computer systems, portable computer systems, handheld devices, networking devices, or any other devices incorporating hardwired logic and / or programmable logic to implement these techniques.

[0120] For example, Figure 4 is a block diagram showing a computer system 400 that can implement an embodiment of the present disclosure. The computer system 400 comprises a bus 402 or other communication mechanism for communicating 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.

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

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

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

[0124] The computer system 400 can implement the techniques described herein using customized hardwired logic, one or more ASICs or FPGAs, firmware and / or programmable logic, which, when combined with the computer system, make the computer system 400 a dedicated machine or programmable to make it a dedicated machine. According to one embodiment of the disclosure, the techniques described herein are executed by the computer system 400 in response to the processor 404 executing one or more sequences of one or more instructions contained in the main memory 406. Such instructions may be read into the main memory 406 from another storage medium, such as a storage device 410. The execution of the sequence of instructions contained in the main memory 406 causes the processor 404 to perform the process operations described herein. In alternative embodiments of the disclosure, hardwired circuits may be used instead of or in combination with software instructions.

[0125] The term “storage medium” as used herein refers to any non-temporary medium that stores data and / or instructions that cause a machine to operate in a particular manner. Such storage mediums may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical or magnetic disks such as storage device 410. Volatile media include dynamic memory such as main memory 406. Common forms of storage mediums include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tapes, or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media having a perforated pattern, RAM, PROMs, EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or cartridges, associative memory (CAM), and tertiary associative memory (TCAM).

[0126] A storage medium is different from a transmission medium, but may be used together with a transmission medium. The transmission medium is involved in the transfer of information between storage mediums. For example, the transmission medium includes coaxial cables, copper wires, and optical fibers, including wires with a bus 402. The transmission medium may also take the form of sound waves or light waves, such as those generated during radio communication and infrared data communication.

[0127] Various forms of media may be involved in transporting one or more sequences of one or more instructions to the processor 404 for execution. For example, the instructions may initially be transported on a magnetic 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 the computer system 400 may receive the data over the telephone line and convert the data into an infrared signal using an infrared transmitter. An infrared detector may receive the data transported by the infrared signal, and appropriate circuitry may place the data on the bus 402. The bus 402 transports the data to the main memory 406, from which the processor 404 retrieves and executes the instructions. The instructions received by the main memory 406 may optionally be stored on the storage device 410 before or after execution by the processor 404.

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

[0129] A network link 420 typically provides data communication to other data devices through one or more networks. For example, a network link 420 can provide connectivity to a host computer 424 or to data equipment operated by an Internet service provider (ISP) 426 via a local network 422. The ISP 426 then provides data communication services through a global packet data communication network now commonly referred to as the “Internet” 428. Both the local network 422 and the Internet 428 use electrical, electromagnetic, or optical signals to carry digital data streams. Signals traversing various networks, and signals on the network link 420 through the communication interface 418, carry digital data to and from the computer system 400 and are exemplary forms of transmission media.

[0130] The computer system 400 can send messages and receive data, including program code, through the network, network link 420, and communication interface 418. In the example of the internet, server 430 can send requested code for an application program through the internet 428, ISP 426, local network 422, and communication interface 418.

[0131] The received code may be executed by the processor 404 upon receipt, and / or stored in the storage device 410 or other non-volatile storage device for later execution.

[0132] 8. Miscellaneous rules, extensions

[0133] Unless otherwise defined, all terms (including technical and scientific terms) are to be given their ordinary and customary meanings to an ordinary person of the art, and are not limited to any special or customized meanings unless expressly defined herein.

[0134] This application includes references to specific trademarks. While the use of trademarks is permitted in a patent application, the proprietary nature of the marks should be respected, and all efforts should be made to prevent their use in a manner that could adversely affect their validity as trademarks.

[0135] Embodiments relate to a system comprising one or more devices, each including a hardware processor and configured to perform any of the operations described herein and / or any of the operations enumerated in any of the appended claims.

[0136] In embodiments of the present disclosure, a non-temporary 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 operations enumerated in any of the claims.

[0137] Any combination of features and functions described herein may be used in accordance with one or more embodiments of this disclosure. The embodiments of this disclosure have been described above with respect to numerous specific details that may vary from embodiment to embodiment. Therefore, the specification and drawings should be considered illustrative rather than restrictive. The sole and exclusive indication of the scope of this disclosure, and what the applicants intend to be the scope of this disclosure, is the literal and equivalent scope of any set of claims derived from this application, in any specific form derived from such claims, including any subsequent modifications.

Claims

1. A non-temporary computer-readable medium containing instructions, wherein, when executed by one or more hardware processors, the instructions cause an operation to be performed, and the operation is: Receiving a selection of a first resource as defined by a first electronic health record (EHR) system, Analyzing metadata associated with the first resource to identify a first set of characteristics corresponding to the first resource, Based on the first set of characteristics, one or more configuration fields associated with the first resource are identified, To present the one or more configuration fields associated with the first resource, Receiving one or more configuration values ​​for one or more of the aforementioned configuration fields, A computer-readable medium comprising: (a) making an application programming interface (API) call to extract data associated with the first resource according to one or more configuration values; and (b) generating code to present the data associated with the first resource.

2. Prior to receiving the selection, the first EHR system is analyzed to identify a plurality of resources associated with the first EHR system. The computer-readable medium according to claim 1, wherein the plurality of resources are associated with an FHIR standard, include the first resource, and are presented as a candidate set of resources for user selection.

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

4. The computer-readable medium according to claim 3, wherein executing the code causes the system to retrieve from the EHR system a resource corresponding to a patient data artifact associated with at least one patient record in the EHR system.

5. The computer-readable medium according to claim 4, wherein the operation further includes presenting information associated with a patient data artifact in order to obtain treatment guidelines.

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

7. The computer-readable medium according to claim 1, wherein the EHR system is FHIR compliant and configured to map to one or more patient medical records associated with a specific hospital, or patient medical records associated with an HIE platform and related to immune status.

8. The computer-readable medium according to claim 1, wherein the operation further comprises running a machine learning model, the machine learning model being trained to identify a candidate set of resources for user selection.

9. The one or more configuration fields are associated with a user scope, and the user scope includes multiple resources associated with a corresponding set of selectable scopes. The computer-readable medium according to claim 1, wherein at least one of the plurality of selectable scopes is associated with a selectable read access permission field and a selectable write access permission field.

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

11. The computer-readable medium according to claim 1, wherein the one or more configuration fields are associated with a plurality of patient scope fields, each patient scope field is associated with a resource of the EHR which can be configured by user selection to one or more of read access enabled, read access disabled, write access enabled, or write access disabled.

12. The selection of the first resource indicates the resource type, In response to the selection of the first resource, the metadata associated with the first resource is analyzed to identify a first set of characteristics and to identify one or more configuration fields. The computer-readable medium according to claim 1, wherein the presentation of one or more configuration fields includes presenting a plurality of selectable resource parameter fields, a user-definable number of instances data field, a display format type field, and a data display location field.

13. The computer-readable medium according to claim 12, wherein the selection of the first resource indicates an Observation resource type, and the plurality of selectable resource parameter fields are included in a dropdown menu comprising the following selectable fields: VITAL SIGN (BMI), VITAL SIGN (Blood Pressure), LAB (Creatinine), and LAB (Hemoglobin).

14. The selection of the first resource is based on a dropdown menu that includes Patient resource type, Observation resource type, Procedure resource type, and MedicationRequest resource type. The computer-readable medium according to claim 1, wherein, in response to the selection of the Observation resource type, a plurality of selectable resource parameter fields associated with the Observation resource type are presented.

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

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

17. A system comprising means for performing the operation described in any one of claims 1 to 14.

Images