Orchestrated personalized therapy systems and methods

Abstract

Apparatuses, systems, methods, and computer program products are disclosed for orchestrating personalized therapy order management including managing therapy workflows.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 291,062, filed on December 17, 2021, and incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates to systems, methods, apparatus, and computer program products for orchestrating personalized medical therapy orders. Background Art

[0004] Personalized medicine is a medical treatment model that provides medical decisions, practices, therapies, interventions and / or products specifically tailored to individual patients based on the predicted responses or disease risks of individuals.Immunotherapy is a rapidly emerging form of personalized medicine for the treatment and prevention of diseases.For example, immunotherapy includes modifying the biomaterial (e.g., immune cells) of the patient's own modified form, and reintroducing the modified biomaterial into the patient to induce and / or supplement the patient's immune response to fight the disease.For example, CAR T-cell therapy is a cancer treatment that involves extracting T-cells from the patient's blood and modifying the cell surface to include chimeric antigen receptors that promote the production of chemicals that attack tumor cells.These and other personalized methods allow customized therapies to be provided based on calculated predictions of how treatment may be most effective for a particular patient.

[0005] While these treatments have revolutionized disease treatment, a complex set of processes must occur in order to process, generate, and deliver the therapeutic agents that are ultimately administered to patients. The personalized medicine supply chain is fraught with logistics challenges, scheduling challenges, stakeholder coordination challenges, monitoring and tracking challenges, and other related issues that impede the ability to achieve personalized medicine at a large or global scale. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Many aspects of the present disclosure may be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale. Instead, emphasis is placed on clearly illustrating the principles of the present disclosure. The drawings should not be considered to limit the present disclosure to the specific embodiments depicted, but are for explanation and understanding only.

[0007] Figure 1 A diagram of an environment for supply chain management of personalized therapies is shown, including an enterprise software platform for orchestrated personalized therapy order management configured in accordance with the present technology to facilitate data transactions between computing devices of external systems.

[0008] Figure 2A and Figure 2BA diagram illustrating an example process in a supply chain for implementing personalized therapy is shown.

[0009] Figure 3 Shown is a depiction of Figure 1 Schematic diagram of an example implementation of an application program interface API set for an enterprise software platform.

[0010] Figure 4A and Figure 4B A diagram illustrating an example user interface associated with an API for managing patient data transactions configured in accordance with the present technology.

[0011] Figure 5 A diagram illustrating an example implementation for executing an API for managing subscription data transactions configured in accordance with the present technology is shown.

[0012] Figure 6 The diagram shows the Figure 1 An illustration of an example data transaction managed by an example implementation of an API of an enterprise software platform.

[0013] Figure 7 Shown is the Figure 1 Illustration of a method by which an enterprise software platform of an enterprise creates a treatment workflow based on an order request submitted by an external system.

[0014] Figure 8 A block diagram of an example embodiment of a computer device is shown. DETAILED DESCRIPTION

[0015] The present disclosure relates to systems, methods, devices, and computer program products for orchestrated personalized therapy order management, particularly in managing therapy workflows. For example, in the specific implementations described below, the disclosed technology for orchestrated personalized therapy order management includes a dedicated application programming interface for an enterprise software platform, which is primarily described in the context of personalized medicine therapy (CAR T cell therapy). However, it should be understood that the disclosed technology can be used for various other cell and gene therapies, personalized medicine therapies, and various other medical or non-medical systems. In addition, those skilled in the relevant art will understand that (i) the technology can have other applications besides Figures 1 to 8 Additional specific implementations other than the specific implementations illustrated in the figure, and (ii) the technology can be used without the following reference Figures 1 to 8 A number of details of specific implementations are described in the context of practice.

[0016] Overview

[0017] Advanced therapies, especially personalized therapies, have driven a paradigm shift in medical supply chain management. Rather than coordinating several components for large quantities of "one-size-fits-all" therapies, such as vaccines, priority medicines, etc., drug manufacturers and healthcare professionals must now manage a highly complex supply chain of personalized components to produce personalized therapies in very small batches (sometimes as small as one therapy per patient) and in increasing volumes.

[0018] Currently, the supply chain for personalized therapies (such as CAR T cell therapies) is distributed in a way that is built around patients and donors, but must also consider the activities and constraints associated with other supply chain stakeholders, particularly (i) manufacturers of biological materials, (ii) shippers of materials, and (iii) healthcare providers (HCPs) and their settings, including hospitals, laboratories, and clinics. Therefore, the supply chain is a highly complex structure that requires visibility, tracking, and management (in real time) of each supply chain stakeholder. For example, in order to ensure the safety of the final personalized therapy product throughout the product life cycle from "vein to vein" (i.e., from the earliest events (such as extraction of biological materials from patients for the creation of personalized therapies) to the final events (such as delivery of personalized therapies for the treatment of patients' diseases or conditions)), there are obstacles to accurately and efficiently accounting for the material identity chain (COI) and the chain of custody (COC).

[0019] During the “vein-to-vein” lifecycle of developing and deploying personalized therapies, there are dozens, if not hundreds, of stakeholder handoffs that must be enabled, tracked, and recorded for each patient product. Each product journey (i.e., the handoff of one or more materials from one stakeholder or process to another) is likely to be highly variable and susceptible to schedule changes and unexpected events that could interrupt the supply chain flow and, thereby, disrupt the personalized therapy for patients. For example, it is currently difficult to match the starting material acquisition process with manufacturing capabilities so that precious cellular materials are not lost and manufacturing capacity is utilized and not overbooked or overextended. Moreover, when disruptions occur in the supply chain, the supply chain must be able to adapt to the unexpected; however, the ability to reschedule events with real-time transparency and visibility from a single source is not possible without integrated tools with connected data flows and orchestration (especially orchestration of the entire supply chain from order to treatment, including logistics).

[0020] A method for addressing these and other challenges to meet the needs of personalized medicine is a cloud-based personalized medicine software platform technology developed by Vineti, the assignee of this technology. Vineti's platform technology is an aPaaS (application platform as a service), which is a custom-made enterprise software service that provides a public technical foundation that meets the needs of each individual client through end-user administrator configuration (rather than by creating an independent custom build). Various aspects of platform technology are disclosed in U.S. Patent Application Publication No. US2020 / 0177386 and U.S. Patent Application Publication No. US2021 / 0280287, which are incorporated herein by reference as a whole. For example, an exemplary cloud-based platform technology performs a series of operations related to digital communications and transactions to coordinate events that occur in the personalized medicine supply chain, such as but not limited to biological material extraction, material and / or kit delivery, material and / or kit tracking, automatic express scheduling, intermediate and final product preparation, capacity and resource management, etc. Ordering and scheduling. In some aspects, the cloud-based platform technology is configured to facilitate interactions between a personalized medicine system and one or more nodes of a blockchain configured to store event data and identification data corresponding to transactions occurring along a personalized medicine supply chain.

[0021] Traditionally, drug manufacturers or HCPs use custom software to manage their roles in general medical practice. However, as personalized medicine continues to develop, custom software architectures have become unable to promote personalized medicine treatment practices and address (let alone meet) the needs of supply chain stakeholders. As such, enterprise software has become a more practical model for building a personalized medicine supply chain. The above platform technology is an example of an enterprise software platform developed for personalized medicine management.

[0022] Generally speaking, enterprise software is a collection of computer programs that have common applications (e.g., business or commerce-centric applications), modeling tools for managing how an organization works, and development tools for building applications unique to an organization. In order to improve the productivity and effectiveness of an enterprise through software-based support functionality and network-based support functionality, enterprise software is architected to solve large-scale problems across "enterprises" (e.g., multiple stakeholders in a community), rather than personalized or single-entity problems. In this way, the unique characteristics of each end user of enterprise software are difficult to create and manage. In contrast, custom software is software developed specifically for a specific or personalized organization or user, that is, custom software is designed to meet the specific, personalized preferences and expectations of customers.

[0023] For enterprise software and custom software systems, data interconnectivity between different software programs or computers can be addressed by using application programming interfaces. An application programming interface (API) is a software interface that provides connectivity between computer programs (software applications) on the same or different computers. Generally speaking, APIs are usually composed of different parts, such as subroutines, methods, requests, or endpoints, which act as tools or services that can be called for use. The specification of the API specification defines these calls, but APIs are usually designed to hide the internal details of how the system works while exposing parts of the system that are useful or necessary for making subsequent changes. For example, an API for file input / output may publish a function that copies a file from one location to another without exposing any information about the file system operations behind the scenes.

[0024] However, data communications between computers in enterprise software platforms are becoming increasingly complex. For example, information within an enterprise software platform is constantly exchanged as databases, cloud applications, and endpoints and clients around the world increase in real-time demand information. These complexities are even more severe when trying to integrate an enterprise software platform with another enterprise software or custom software platform, which can be even more complex for supply chain management software platforms (e.g., especially those dedicated to personalized therapy management), where the health and lives of stakeholders may depend on the timing and seamless orchestration of every point and transition in the supply chain.

[0025] For example, analysts in the healthcare industry generally point to supply chain complexity as a key limiting factor in advancing personalized therapies, particularly cancer treatments. Complexity results in extremely high costs of goods sold and hesitation in the use of certain cancer therapies, such as CAR T-cell therapies, in addition to the loss of patients at the end of life and during the treatment journey. Therefore, while the basic medicine behind cell and gene therapies continues to make rapid and significant progress, the utilization and specific implementation of new therapies in treating patients is increasingly lagging behind in a broad sense. In addition, the global pandemic caused by the spread of COVID-19 has further exacerbated the complexity of personalized therapy management, for example, one-third of cell therapy companies reported delayed production or complete suspension of operations in 2020, and 50% of cell gene therapy companies reported reduced contact with HCPs, clinical sites, and patients. Therefore, if the promise of these therapies is to be realized and benefit patients around the world, then the expansion of the production and delivery of high-value, deeply personalized products and personalized cancer vaccines (such as autologous and allogeneic cell and gene therapies, and personalized cancer vaccines) needs to be significantly more streamlined and standardized.

[0026] The present technology provides systems, methods, devices, and computer program products for orchestrated personalized therapy order management, particularly in managing treatment workflows. In an example embodiment, the disclosed technology provides personalized therapy workflow management, including patient management, order management, and scheduling management, with a track and trace solution that facilitates patient initiation while (i) synchronizing order event data with integrated systems, (ii) minimizing the protected health information (PHI) footprint across the information technology (IT) ecosystem, and (iii) simplifying the multi-portal healthcare provider experience.

[0027] Further advantages of the disclosed technology include direct import of patient data from external systems, which is expected to eliminate high-risk errors in incorrectly capturing critical patient data and simplify the order creation process. Using the disclosed technology, order management can be managed entirely outside of the track and trace orchestration system, while synchronizing order data, patient data, and scheduling data entirely via the system's sophisticated APIs. In addition, personalized therapy order management can be directly embedded in external systems (such as electronic health record (EHR) portals and customer relationship management (CRM) portals) to provide full life cycle order management, including creation, scheduling, submission, approval, and rescheduling in a seamless single portal experience.

[0028] Personalized therapy treatment workflow management system

[0029] Figure 1 A diagram of an environment 10 for supply chain management of personalized therapies is shown, wherein an enterprise software platform 100 for orchestrated personalized therapy order management configured in accordance with the present technology can facilitate data transactions between computing devices of one or more external systems 150 for the development and treatment of patients using personalized therapy treatment products and processes. The enterprise software platform for orchestrated personalized therapy order management may be referred to herein as "enterprise software platform 100" or simply "platform 100."

[0030] The environment 10 includes one or more server computer devices 12 and one or more server and / or client computer devices 14 associated with the enterprise software platform 100 and associated with the external system 150. One or more server computer devices 12 and / or one or more client computer devices 14 can generate, plan, track, monitor and store data associated with the transaction process of the personalized therapy supply chain, including events associated with the ordering, manufacturing, delivery and treatment of cell therapy and gene therapy for patients. In some embodiments, the enterprise software platform 100 includes one or more databases 16, which are configured to store, organize and manage large data sets. Similarly, for some embodiments (not shown), the external system 150 may include one or more databases 16. In a specific implementation, for example, the computer devices 12, 14 and database 16 of the enterprise software platform 100 and the computer devices 12, 14 (and database 16) of the external system 150 can communicate in the environment 10 via a network 120 (e.g., such as the Internet).

[0031] The computer devices 12, 14 of the enterprise software platform 100 can perform a series of operations related to data corresponding to supply chain events, including but not limited to point-of-care collection (e.g., collection of samples that meet threshold quality standard requirements), tracking supply chain events (e.g., as involved in manufacturing personalized therapies for patients), optimizing resource utilization (e.g., fulfilling manufacturing orders), security and compliance (e.g., ensuring data quality, data validation, and data encryption mechanisms are implemented), ordering and scheduling events (e.g., scheduling of sample collection, manufacturing, medical management, etc., as well as scheduling couriers, raw material deliveries, tracking kits and materials and raw materials, etc.), reporting tasks (e.g., reporting quality findings, compliance activities, identity chain information, custody chain information, etc.) and / or facilitating system integration (e.g., data integration, data modification, insight into procurement, etc.).

[0032] like Figure 1 As shown in the example of , the enterprise software platform 100 can communicate data with different external systems associated with supply chain orchestration, including but not limited to a healthcare facility system 152, a manufacturing facility system 154, and / or a logistics facility system 156. Each of these example external systems 152, 154, and 156 may include one or more server computer devices 12 and one or more client computer devices 14; and the external system 150 may include a single or multiple healthcare facility systems 152, a single or multiple manufacturing facility systems 154, and / or a single or multiple logistics facility systems 156 that communicate data with the enterprise software platform 100 within the environment 10.

[0033] The enterprise software platform 100 may include multiple software modules to orchestrate personalized therapy treatments between multiple stakeholders in the personalized therapy treatment supply chain. In some examples, multiple software modules that can be operated on the computer devices 12, 16 and / or 14 of the enterprise software platform 100 include a supply chain management module, an identity chain and a chain of custody module, a system integration module, and an analysis module. Some example embodiments and specific implementations of these modules of the enterprise software platform 100 are described in U.S. Patent Application Publication No. US2020 / 0177386 (which has been previously incorporated herein by reference), for example, about a supply chain optimization module 110, a supervision and identification module 130, a system integration module 140, and an analysis module 150. The enterprise software platform 100 may include variants of these modules and / or other modules. Some other example embodiments and specific implementations of the modules of the enterprise software platform 100 are described in U.S. Patent Application Publication No. US 2021 / 0280287 (which has been previously incorporated herein by reference).

[0034] As will be discussed further below, the enterprise software platform 100 provides a set of APIs 110 to facilitate data transactions for personalized medicine therapy orders, which can alleviate various challenges at various points along the personalized medicine supply chain, such as logistics challenges, scheduling challenges, stakeholder coordination challenges, monitoring and tracking challenges, and other related issues. A key advantage of a specific implementation of the disclosed technology is that the set of APIs 110 can create and maintain a unique, robust chain of identity (COI) for the ordered personalized therapy, regardless of the multiple stakeholders and different external systems 150 that may be within the environment 10.

[0035] In personalized therapies, safety and efficacy rely on the right patient receiving the right treatment. The process of tracking and matching materials in the supply chain is driven by the COI, which is a permanent, transparent association of a patient and / or donor’s unique identifier with their tissue and / or cells from order through collection, manufacturing, administration, and post-treatment monitoring. Pairing the COI with the COC, a permanent data capture of the tracking and handling information of the therapy at every step, provides a truly traceable, trusted process.

[0036] Figure 2AA diagram illustrating an example process for implementing personalized therapy is shown, for example, depicting various stakeholders and / or transactions across the "vein to vein" to therapy cycle in the supply chain. For example, when designing personalized therapy products and procedures for patients (event 1), various parallel and sequential actions must be started to implement the personalized therapy process (event 2) to coordinate the logistics of personalized therapy. For example, the patient registers and agrees to the personalized therapy prescribed by the HCP (event 3), after which registration, ordering and scheduling (event 4) are started. For example, scheduling can set the date of key events, such as extracting biological materials from patients (event 5), providing biological materials to personalized therapy product manufacturers to create transportation logistics of products (event 7) (event 6), providing transportation logistics of personalized therapy products to treatment facilities (event 9) (event 8) and long-term patient monitoring (event 10) to ensure the effectiveness of personalized therapy in treating patients' diseases or conditions.

[0037] Figure 2B A diagram illustrating another example process for implementing personalized therapy is shown. Figure 2B The diagram illustrates the events leading up to the realization of personalized therapy, including product research, design and development (Project A), product trial design and initiation (Project B), and process and logistics design and initiation (Project C). Figure 2B The diagram also illustrates the Figure 2A A modified sequence of events in the personalized medicine process.

[0038] At a basic level, Chain of Identity is enabled through the COI Identifier (COI ID), a set of numbers and / or characters that is the primary “ID marker” for each patient, and key materials associated with their product. The COI ID must link the therapy to the intended patient and protect patient privacy. The COI ID is used at multiple points along the patient journey, from medical records to medication labels during the process.

[0039] Table 1 (shown below) illustrates an example embodiment of a single COI ID that includes a core identifier (CoreID), a treatment identifier (TreatmentID), and a sample identifier (SampleID). In this example embodiment, the CoreID includes a nine-character code that begins with a three-letter company identifier that is unique to the company / sponsor, followed by a six-digit core patient ID that is unique to all product trips for the patient. In this example, the Treatment ID includes a five-character code following the CoreID (which may optionally include a dash "-" character), beginning with a three-letter product identifier that is unique to the product or therapy, followed by a two-digit order identifier that indicates a specific treatment order cycle. Finally, in this example, the Sample ID includes a six-character code following the Sample ID (which may optionally include a dash "-" character), beginning with a two-letter process identifier that indicates a process type and / or sample grouping, followed by a two-digit run identifier that indicates a specific session / run of the process type, and followed by a two-digit project identifier that indicates the project number generated in the session / run.

[0040] Table 1

[0041]

[0042] Table 2 (shown below) illustrates another example embodiment of the COI ID structure, including a product identifier for a treatment ID, a core patient ID for a core ID, a procedure identifier (unique to a particular treatment associated with an order cycle), and a check digit. In this example embodiment, the COI ID includes the product identifier, the core patient ID, the procedure identifier, and the check digit in order, and separated by periods, dots, or other characters to indicate separation. The product identifier includes a three-character code based on 36 characters, namely 0-9 and AZ; the core patient ID includes a six-character code based on 36 characters; the procedure identifier includes a three-character code of hexadecimal characters; and the check digit includes a single decimal character. Table 2 illustrates the structure of this example of a COI ID, where the COI ID is: PRD.PAT.123.E45.9.

[0043] Table 2

[0044] Example :

[0045] PRD.PAT123.E45.9

[0046]

[0047] API for personalized therapy treatment workflow management system

[0048] For personalized therapy, there are various stakeholders who want to create patient orders and patient schedules for personalized therapy in their own external systems, and then send patient data, order data and / or schedule data to the enterprise software platform 100 for management by the enterprise software platform 100, and then manage through the entire supply chain. Although it may be ideal to create a single software system that each stakeholder entity will use to unify the format of data input, formatting, processing, communication and storage, such a single system is unrealistic in the current healthcare provider, pharmaceutical and biologics development and material logistics environment. Instead, most stakeholders have developed their own internal software systems to meet their own needs and do not want to risk breaking to change (let alone replace) the system they rely on. Currently, most personalized therapy supply chain stakeholders want to continue to use their own customized systems and data formats within the supply chain. Therefore, in order for the enterprise software platform 100 for orchestrated personalized therapy order management to successfully manage the orchestration of the supply chain and seamlessly facilitate data transactions between stakeholders, the enterprise software platform 100 must provide a software interface specifically tailored to the needs of the personalized therapy supply chain.

[0049] In various specific implementations, the enterprise software platform 100 provides an application platform as a service (APaaS) that bridges the gap between all the complex processes involved in the manufacture of personalized therapies (including COI, COC, ordering, material acquisition, manufacturing, express logistics, and capacity management) until the patient receives the personalized therapy. The API 110 of the enterprise software platform 100 enables authorized third-party applications and computers to programmatically input and / or retrieve patient and treatment data, including permission data about patients (patient data), permission data about personalized therapy products and / or processing orders (order data), and permission data about the scheduling of events for developing and treating patients using personalized therapies (scheduling data). The API 110 of the enterprise software platform 100 is configured to be universally applicable to various custom applications that can be built on different platform frameworks, so that the API 110 provides a standard data set that can work with the data objects and relationships of the enterprise software platform 100.

[0050] One aspect of the API 110 is authentication. The enterprise software platform 100 requires authentication of external systems (and users) for any system interconnectivity and data communications. For example, the API 110 of the enterprise software platform 100 may require an access token associated only with the platform 100 to make an authorized request. In order to integrate with the enterprise software platform 100, the external system must register and configure the external software application (e.g., at the time of request and review) using the client credentials provided by the enterprise software platform 100. The enterprise software platform 100 will generate and provide a client ID and secret for each sandbox and live environment in a secure manner. Once set up, the software application of the external system can exchange these credentials for an access token, which can then be included in the request header to authorize the API call of the external system. Once the access token is granted, the external software application should include the access token in the header of the request to the API 110 of the enterprise software platform 100 to obtain authorization.

[0051] In an example implementation of authentication, the authentication server of enterprise software platform 100 will process the access token request by validating the provided client ID and secret and returning an access token in the response upon successful validation. In some implementations, for example, the access token may expire after a predetermined period of time (e.g., a number of seconds) after the token is obtained. For example, an access token with an expiration field value of 300 will expire within 300 seconds after the response is generated. Upon expiration, the external software application may obtain a new access token using the same process.

[0052] In some embodiments of the set of APIs 110 of the enterprise software platform 100, the set of APIs 110 allows third-party applications and computers to perform queries and mutations using GraphQL. GraphQL is a query language that allows a caller to request a precise set of fields of a data object to be returned in a response body from the enterprise software platform 100. GraphQL may also provide users of the enterprise software platform 100 with the flexibility to query a subset of data from the APIs of the set of APIs 110, e.g., in contrast to returning only predefined large data sets and / or fields (as is the case with current query languages ​​REST). This feature of the API 110 may provide greater query flexibility and less over-fetching than conventional REST-based APIs.

[0053] Another key aspect of the API 110 is data type identification. The API 110 set of the enterprise software platform 100 handles the calling and tracking of all external IDs, such as patient medical record numbers managed by entities of the external system 150 (e.g., such as the healthcare facility system 152). In order to integrate external and third-party systems with the enterprise software platform 100, the external identifiers currently in use are mapped to internal identifiers used within the enterprise software platform 100 using a resource identifier data structure (also referred to as a "resource identifier"). A resource identifier is a wrapper that allows objects that have been referenced within an internal application using the same identifier to be referenced within the enterprise software platform 100. Each internal component of the enterprise software platform 100 can use a resource identifier to call different types of IDs. For example, this allows internal IDs of the enterprise software platform 100 to be added to the system without having to change existing request data. When defining a resource identifier, the identifier type parameter defines the type of the identifier, such as a medical record number, a patient ID, or a site ID, and the identifier type parameter provides the identifier itself.

[0054] Figure 3 A diagram is shown depicting an example embodiment of a set of APIs 110 for enterprise software platform 100. Set of APIs 110 includes at least three separate APIs that control data transactions between various entities of external systems 150 through enterprise software platform 100: patient API 311, ordering API 313, and scheduling API 315.

[0055] The patient API 311 interfaces between the enterprise software platform 100 and the external system 150 to enable the creation of patients and update the details of existing patients in the platform 100. In some specific implementations, for example, the patient API 311 can be used in an ordering workflow managed by the enterprise software platform 100 to add new patients from the external system 150 and update details about patients, such as date of birth, gender, and weight of existing patients. In the enterprise software platform 100, a patient data object describes a patient (organizes patient data), including a patient ID, patient details, and an associated ordering organization. However, a patient is typically identified by a unique ID provided by a client of the external system 150 (e.g., any or multiple HCP clients); and the patient API 311 parses the data from the external system 150 to identify the unique ID of the external system 150 and links the unique ID to a unique identifier (and patient data) within the enterprise software platform 100. In a specific implementation, for example, after a patient has been added to the enterprise software platform 100 with the patient data requested by the external system organization, an order may be created for the patient using the external system 150 via the ordering API 313 .

[0056] In some implementations of the patient API 311, for example, the patient API 311 may be configured to require only a patient ID from the external system 150, and thus no patient details or ordering agency are required. In implementations where the patient details are provided by the external system 150, the patient API 311 may set parameters associated with the patient details to be linked to the patient ID, including but not limited to the patient's birthday, name, biological sex and / or identified sex, custom health data (such as weight, height, etc.), and / or contact information (such as email address, phone number, etc.). In addition, the patient API 311 is configured to receive partial information associated with a patient to update an existing patient.

[0057] In some implementations of patient API 311, for example, patient API 311 may be configured to request a patient ID and associated ordering organization (site) information from external system 150. In such implementations, for example, this provides a layer of security protection so that users not affiliated with the ordering organization may be restricted from viewing information about the patient, i.e., other entities of external system 150 may only be able to view information about the order corresponding to the patient ID, without any ability to view information about the patient.

[0058] The ordering API 313 interfaces between the enterprise software platform 100 and external systems 150 to allow creation and cancellation of orders in the supply chain. In the enterprise software platform 100, an order data object describes a treatment order for a personalized therapy, which may include patient data, product (therapy) data, and supply chain milestone data (e.g., such as contact information associated with a milestone, a site, location and / or region associated with a milestone, an activity associated with a milestone, a date / time associated with reaching a milestone, etc.).

[0059] Based at least on the ordering API 313, the enterprise software platform 100 is able to solve the complex technical challenge of enabling the correct, desired workflow to be selected by the customer when an order request is submitted to the platform 100. For example, external users (e.g., users of the healthcare facility system 152, users of the manufacturing facility system 154, and users of the logistics facility system 156) typically have many ordering workflows, which may depend on the location, type of therapy, quality requirements, different locations, etc., and the customer may have dozens of different ordering workflows for users (such as ordering nurses) to choose from. To illustrate, in some specific implementations, for example, when the ordering nurse creates an order for a personalized therapy for a patient, the ordering nurse is presented with a list of workflows to be pre-selected on a user interface, where these workflows are typically widely differentiated, for example, with different events or event parameters. An example of differentiation is the inclusion of a cryopreservation site within the personalized therapy treatment workflow: Do the materials of the personalized therapy product go directly to the manufacturing site, or do they stay at the cryopreservation site for a period of time and are cryogenically frozen before entering the manufacturing site? Because there are a large number of workflows, there is a large amount of information that some stakeholders cannot access. However, if the API is only designed to transfer data between computing systems, it is impossible to protect the information of certain stakeholders. The subscription API 313 addresses these issues and overcomes technical challenges to automatically select one or more workflows that are best suited for the particular user based on the information received by the enterprise software platform 100 from the external system 150 via the subscription API 313.

[0060] In some embodiments, for example, the ordering API 313 is configured to automate workflow selection for actions in the personalized therapy development and treatment supply chain by utilizing criteria, referred to as workflow variants, which can be configured by a user of the external system 150 (e.g., on the external system 150 user interface) to include attributes of the personalized therapy development and treatment process to select the most appropriate workflow (stored by the enterprise software platform 100). In some specific implementations, for example, the workflow variants may include a limited number of options, where an administrative user of the external system 150 may pre-select certain variables from a list so that the enterprise software platform 100 can build the largest number of workflow permutations from the selected variables. The ordering API 313 may manage the data format of the possible workflow options for subsequent presentation (display) on the user interface of the external system 150 so that the end user can select the desired, available attributes of an effective workflow. For example, for a workflow variant related to cryopreservation of materials in the personalized therapy supply chain, the administrative user may be prompted to select between local or centralized cryopreservation and local or centralized label printing of the materials. If the administrative user selects local cryopreservation and local or central printing for a material, the enterprise software platform 100 may create two workflows for the ordering API 313 (e.g., convertible from strings) to implement during personalized therapy development and treatment supply chain management by that end user: "Cryopreservation":"Local","Print":"Local" and "Cryopreservation":"Local","Print":"Central".

[0061] In a specific implementation for creating an order, for example, the ordering API 313 enqueues the order created from the external system 150 to be managed by the enterprise software platform 100 for personalized therapy for the patient. Once enqueued, the client software application will receive success and / or error notifications, which in some examples include asynchronously providing notifications via HTTP POST to a pre-configured webhook endpoint provided to the enterprise software platform 100. For example, a successful response indicates that the order has been successfully enqueued for creation and contains a transaction ID that can be used to associate subsequent success / error notifications with the original order creation request to which they belong.

[0062] In some embodiments of the ordering API 313, for example, the ordering API 313 can be configured as an asynchronous API that responds to requests using event notifications sent to a webhook. For example, in a specific implementation using GraphQL, a GraphQL response to a request to the ordering API 313 contains a transaction UUID that can be used to associate the ordering API request with the event notification response. The transaction UUID is a unique identifier associated with a specific API request sent to an API of the API 110 set (e.g., the ordering API 313), which can be used to distinguish multiple API requests sent to the ordering API 313 at different times. This transaction UUID can be configured to be displayed in the event notification payload.

[0063] In a specific implementation for canceling an order, for example, ordering API 313 may enqueue a request to cancel an existing order from external system 150 for execution by enterprise software platform 100. Once enqueued, the client software application will receive success and / or error notifications, which in some examples include asynchronously providing notifications via HTTP POST to a preconfigured webhook endpoint provided to enterprise software platform 100. For example, a successful response indicates that the cancellation request was successfully enqueued and contains a transaction ID that can be used to associate subsequent success / error notifications with the original cancellation request to which they belong.

[0064] The scheduling API 315 interfaces between the enterprise software platform 100 and the external system 150 to enable the creation, update, and receipt of milestone dates from clients of the external system 150 via scheduling requests. In the enterprise software platform 100, a schedule object represents an order timeline and is associated with an order created via the ordering API 313. In some embodiments of the scheduling API 315, for example, the scheduling API 315 may use either an order object or a treatment object to reference an order or treatment for a patient, but not both.

[0065] In some implementations of the scheduling API 315, the scheduling request may include a change to the original timeline that was requested without approval (e.g., a pending request). In an example implementation, when ordering and manufacturing capabilities are managed in different systems external to the enterprise software platform 100 (i.e., external systems 150), for example, the scheduling API 315 may accept acquisition and manufacturing dates, then recalculate remaining milestone dates, and create subsequent shipments for the order based on the workflow configuration.

[0066] Milestones are points in time when specific events occur. Each treatment workflow is configured with a set of milestones that are used to calculate the patient's treatment timeline from collection to infusion. The enterprise software platform 100 can associate milestones with shipping segments and stations (e.g., allocations). The enterprise software platform 100 can then perform calculations based on the duration between each milestone to create an accurate timeline (schedule) for the treatment.

[0067] Further details of the patient API 311, ordering API 313, and scheduling API 315 are discussed below.

[0068] Patient API

[0069] In some clinical and commercial settings of the example enterprise software platform 100, the system that generates patient data is external to the platform 100, such as a healthcare facility system 152. Clinical environments and scenarios refer to therapies that are undergoing clinical trials and / or have not yet been approved by regulatory agencies (such as the U.S. Food and Drug Administration (FDA)), for example, where the manufacturing process of the therapy may still be variable as the therapy developer learns more about its effects. Business environments and scenarios refer to therapies that have been approved by regulatory agencies for one or more indications, for example, have been proven to treat the indications and have relatively standardized manufacturing processes. For example, in a healthcare facility system 152 or other external system, patient data can be obtained from paper charts or EHRs and manually entered into their patient service system via a "swivel chair" method (e.g., the most common portal). The swivel chair method or interface is a system for computer input and interaction that requires a user to move between multiple user interfaces to enter and / or process data. Although this way of creating patient data (patient intake) may be inefficient, patient intake is a key point of clinical and business management in personalized medicine because it is the first step to ensure that the right patient gets the right treatment. For example, in a clinical setting, patient data is typically entered into a patient services system during the patient recruitment phase. If the patient passes the eligibility criteria during the trial screening phase, they are enrolled and their COI continues. For example, in a commercial setting, patients who enter a patient services system are placed for treatment; and there may be no requirement to capture patient data upstream of the ordering. The differences between each of the various external patient data management platforms and the aforementioned differences in such platforms in clinical and commercial settings require a method to obtain, consolidate, and reconcile patient data in a unified format.

[0070] The disclosed patient API 311 is configured to automatically receive patient records from various external platforms and push patient data in such patient records to the enterprise software platform 100, for example, allowing HCPs and case managers who manage patients via the patient service system to enter patient data into their existing systems external to the enterprise software platform 100, while also preventing the need for duplicate data entry and reducing the probability of human error. This lowers the barrier to entry into the enterprise software platform 100 to order treatment.

[0071] The patient API 311 can be designed for a variety of use cases. For example, the patient API 311 can batch create and update patients during the specific implementation of the enterprise software platform 100. After the specific implementation stage is completed, the external system can send a list of patients to the enterprise software platform 100 for creation, so that after successful creation, the subscribing user can see the list of patients on the list. The subscribing user can then create an order for the patient, and the patient information page will be pre-populated based on the patient data provided via the patient API 311.

[0072] In some implementations, the patient API 311 may be configured to manage data transactions between the enterprise software platform 100 and the external system 150, the data transaction including a patient identifier (ID), and (optionally) a site identifier associated with a subscribing organization, and (optionally) patient data including the patient's name, birthday, biological sex and / or identified gender, and / or contact information (such as an email address, phone number, etc.), and / or custom health data (such as weight, height, etc.). These data may be string data of the patient API 311. The patient API 311 may include patient or site identifier attributes, which may be objects or arrays of objects of the patient API 311.

[0073] In some embodiments of the patient API 311, the only field required to create a patient is a resource identifier, which represents one or more identifiers associated with the patient (e.g., medical record number, hospital ID). In this way, the patient API 311 can provide maximum flexibility for patient management users in external systems, for example, because all information about a patient may not be known when it is added to the system. For example, these details can be added later via a patient update.

[0074] By default, the Patient API 311 requires that patient identifiers are unique. For example, if a user attempts to create a patient with the same identifier as an existing patient, the request will fail. In this case, the user should update the existing patient with the new details. This prevents users from creating duplicate patients.

[0075] Figure 4A and Figure 4B 1 shows a diagram of user interfaces associated with the patient API 311 that may be displayed on a client computer device 14 of an external system 150, such as a healthcare facility system 152. Figure 4A , the example user interface illustrates a patient list of therapy orders, and the user interface allows the listed patient to be selected by the patient's name and patient ID, and displays the order status, therapy status, and site status of the listed patient. The example user interface allows the client user to enter a new patient, for example, by selecting a "new patient" button. The example user interface provides a graphical data input and display interface, behind which the patient API 311 manages the data transfer between the client computer device 14 and the computing device of the enterprise software platform 100. Next, refer to Figure 4B , the example user interface illustrates another data input and display interface that can be generated by the patient API 311 to manage patient data updates (eg, in a patient information section) and therapy specific information.

[0076] Ordering API

[0077] Currently, most clinical and commercial therapy developers use their own patient service systems as a single access point for patient reception, order creation, and order tracking. Clinical and commercial therapies typically have different sets of patient service systems associated with them. Generally speaking, these entities have to rely on multiple patient service systems to manage the supply chain, such as web-based portals for patient recruitment and registration, interactive web response systems (IWRS) and interactive voice response systems (IVRS) for randomization and allocation, and / or clinical trial management systems (CTMS) for treatment journey tracking. These external systems lack a simplified supply chain management approach at each node of the supply chain, which may cause interruptions in the ordering and scheduling of the therapy for personalized therapies.

[0078] The ordering API 313 of the enterprise software platform 100 provides standard integration to facilitate a unified experience with little or no duplication of data input between multiple external systems. Using the API 110, the enterprise software platform 100 is configured to initiate and "own" the identity chain process, for example by: passing all required order-level data to the enterprise software platform 100 via the ordering API 313 to generate a COI and start the product journey in the platform 100; providing users with the ability to create and modify schedules via the scheduling API 315 for back-end orchestration of event scheduling in the supply chain; and providing users with the ability to reschedule shipment segments via a user interface, which may include a user interface generated by the enterprise software platform 100, allowing users to access and utilize the front-end supply chain orchestration features of the platform 100.

[0079] The ordering API 313 facilitates order management integration (OMI) to allow a user to create an approved order in the enterprise software platform 100, where the user is using the user interface (UI) of the external system. The ordering API 313 can be configured as an asynchronous mode API. In some implementations, for example, after a patient is created in the external system 150 (e.g., sent to the enterprise software platform 100 via the patient API 311), the user can continue to complete his / her workflow to provide all required data to the platform 100 to create and schedule an order via the ordering API 313. In some implementations, for example, after the workflow has been completed, the order is sent to the enterprise software platform 100; in other words, the ordering API 313 allows the enterprise software platform 100 to receive an approved and ready order.

[0080] In some implementations, the ordering API 313 may be configured to manage data transactions between the enterprise software platform 100 and the external system 150 for creating and managing orders, wherein the data of the ordering API 313 includes (i) patient references, (ii) resource identifier data, (iii) product data, (iv) ordering institution (site) data, (v) regional data associated with the product or treatment (e.g., United States, Europe, etc.), (vi) ordering capability data (e.g., functional capabilities of the site, such as collection capabilities to obtain samples from patients), (vii) milestone data, and / or (viii) configurable workflow standards. In some implementations of the ordering API 313, the resource identifier data and the milestone data are configured as an array of objects, wherein the resource identifier data includes one or more resource identifiers (e.g., strings) associated with the order, and wherein the milestone data may include site data, capability data, dates, and other data associated with milestones of the order. In some implementations, for example, the data of the ordering API 313 may also include product indication data, such as a data string identifying one or more diseases or conditions that the product is designed (and approved) to treat. In some implementations suitable for clinical scenarios, for example, the data of the ordering API 313 may also include study data, such as a data string identifying a study number for a therapy used in a clinical trial. The data of the ordering API 313 management transaction is associated with a field in the API 313 that is used to look up the corresponding execution context of the order.

[0081] In some specific implementations, for example, a user may have additional attributes required to further filter the list of possible execution contexts for an order. Examples of additional attributes may include cryopreservation locations. For example, cryopreservation may be performed at a plasmapheresis site, a satellite laboratory, or a manufacturing site. Cryopreservation depends on supply chain optimization factors within the customer. In order to take into account this further level of filtering required, a set of configurable workflow standards (also referred to as workflow variants) may be sent via the Ordering API 313 along with a request to create an order. Depending on the selected business process, each customer may have a different set of standards. This set of configurable workflow standards is used as input to the process of determining which execution context within the initial subset maps to the product itinerary required for the order.

[0082] Figure 5 A diagram of an example implementation of a method 500 for executing an ordering operation performed by an ordering API 313 is shown. At process 510 of method 500, the ordering API manages input 512 and workflow criteria or variants 514, which can be entered by a user, for example, on a user interface generated by an external system 150 that interfaces with the ordering API or on a user interface associated with the enterprise software platform 100. The input 512 may include product data, indication data, regional data, ordering agency (site) data, ordering capacity data, and / or milestone data. The workflow variant 514 may include multiple distinguishing factors of a customer's product journey that are not considered by product, indication, or regional data. In various implementations, the workflow variant 514 may be configured as a data object; and in some implementations, for example, the workflow variant 514 may be configured with an accompanying matching string decision tree that will be executed in sequence.

[0083] For process 510, after entering all ordering and scheduling details in the external system 150, the user will submit the information for the ordering API 313 to transform and provide to the enterprise software platform 100. At process 520 of method 500, the input 512 is processed by the ordering API 313 to produce a formatted output of the input data from the external system 150. In addition, at process 520, the workflow variant 514 is processed by the ordering API 313 to produce an output 524 of data as a string. For example, in some embodiments of method 500, the workflow variant 514 can be configured within process 520 using an accompanying matching string decision tree 522 to produce the output 524 as a matching string. At process 530 of method 500, the ordering API 313 selects an execution context based on the output data 526 from the input 512 and the output data 524 from the workflow variant 514. For example, at process 530, the ordering API 313 produces an output data set 538 that can be read and processed by the enterprise software platform 100. At process 540 of method 500 , the ordering API 313 passes the output data set 538 to the enterprise software 540 .

[0084] In some implementations, additional processes in the order operation may be included. For example, some customers may have additional ordering steps between the personalized therapy ordering nurse and the supply chain management (enterprise software platform 100), such as reimbursement activities. The ordering API 313 is designed to provide flexibility such as incorporating customer desired steps into the order for this or other use cases.

[0085] In some embodiments, for example, ordering API 313 is configured as an asynchronous API, for example, where the system will simply receive a GraphQL response with a transaction UUID. Ordering API 313 can be set to listen for event notifications (e.g., via a webhook), to which enterprise software platform 100 can send success or failure event notifications with an associated transaction UUID for correlation.

[0086] In an example implementation of method 500 for performing order creation, a request to create an order sent to enterprise software platform 100 may cause enterprise software platform 100 to create the required data model, select product itineraries, schedule the order, approve the order, and initiate the collection process at process 540. In some implementations, the order may be automatically approved and downstream operations may be automatically performed by enterprise software platform 100.

[0087] In an example implementation of method 500 for performing order cancellation, at process 510, the user is also able to cancel the order from their external system 150 via the ordering API 313. As an example use case, in the event that a patient has an adverse event or no longer desires treatment, an order for a prescribed personalized therapy will need to be canceled. As another example use case, a cancellation may occur when an order needs to be rescheduled to follow a different product itinerary than originally scheduled. In some implementations, method 500 may be implemented to update the order fields to support an updated execution context for the modified / rescheduled command; while in other implementations, for example, method 500 may be implemented to cancel the current order and create a new order with the rescheduling information. In this case, an order cancellation event notification may be generated by the enterprise software platform 100 and delivered to the external system 150 via the ordering API 313 and / or delivered to the external system 150 by another communication method so that the system 150 is aware of the cancellation.

[0088] Scheduling API

[0089] In some implementations, the scheduling API 315 can be configured to manage data transactions between the enterprise software platform 100 and the external system 150 that include order references (e.g., including an associated identifier for the order), patient IDs, treatment references (e.g., including an associated identifier for the order), and / or milestone data that includes a name associated with the milestone, data / time associated with when the milestone occurs, and / or a milestone site or location.

[0090] The scheduling API 315 creates or updates a schedule for a treatment order when a user of the client computer device 14 of the external system 150 executes a scheduling call, e.g., inputs a schedule creation or update command or data input via a user interface designed to interact with the scheduling API 315. The scheduling API 315 will check if the treatment has been checked out; and if so, will update the treatment using the parameters provided in the scheduling call, and if not, will create a schedule for the treatment using the parameters provided in the scheduling call. The scheduling call allows the user to update one or more milestones of the treatment as needed.

[0091] As an illustrative example, a patient is created via the patient API 311, and then an order is created via the ordering API 313, where a treatment is scheduled via the scheduling API 315. One week later, the patient needs to reschedule their collection time. The HCP user can generate a scheduling call at the client computer device 14 of the healthcare facility system 152 to pass only the changed milestones, such as a different treatment date, and the scheduling API 315 will manage the data transaction with the scheduler module of the enterprise software platform 100 to recalculate the treatment schedule accordingly. For example, the response to the scheduling API 315 can return information about all milestones, even if only one milestone is defined or changed in the request.

[0092] In some implementations, for example, the scheduling API 315 may create a pending schedule for a treatment that, unless confirmed, will not affect the timeline of events for stakeholders. For example, if a user of a client computer device 14 of a healthcare facility system 152 (e.g., a nurse) creates an order and selects the most convenient date for a patient to undergo plasmapheresis, but based on the internal processes of the healthcare facility system 152, the date needs to be reviewed by case management, then the endpoint may notify the scheduling API 315 to manage the creation of a pending schedule that may be confirmed or rejected. In such cases, unless the pending schedule is confirmed, the changes will not affect the treatment timeline. For example, if a case manager of the healthcare facility system 152 discovers a pending schedule request from an apheresis nurse, and during the review finds that updating the request will not introduce issues related to patient safety, then the case manager may confirm the pending schedule and will apply all changes, wherein the scheduling API 315 will facilitate the creation of a new timeline accordingly. On the other hand, for example, if the case manager discovers a pending scheduling request from apheresis nurse and upon review discovers that there are some limitations or risks to patient safety, the case manager may reject the pending schedule via input to the scheduling API 315, which will not confirm the pending timeline and therefore not affect the original treatment timeline.

[0093] Figure 6 A diagram illustrating data transactions 600 managed by the API 110 set of the enterprise software platform 100 based on data provided by the external system 150 is shown. Figure 6In the example implementation shown, a user using the user interface of the external system 150 enters data for the following actions: an action 610 for creating a patient 610, an action 620 for creating an order (for personalized therapy treatment) and scheduling an event (for personalized therapy treatment), an action 630 for editing patient details, an action 540 for rescheduling (one or more events or aspects of the scheduled personalized therapy treatment), and an action 650 for canceling an order. For example, in some implementations, some of the data transactions 600 are implemented using the API 110 set because certain data transactions such as patient editing, order rescheduling, and / or order cancellation are not necessary for a particular personalized patient treatment.

[0094] In action 610, the external system 150 creates a request to create a patient, the request including a patient ID (and optionally patient details) associated with the external system 150. The patient API 311 receives and processes the request with input data, and produces output that can be processed by the enterprise software platform 100 to produce one or more actions. In response to the request for action 610 (provided by the patient API 311), the enterprise software platform 100 may create a patient in the data system (e.g., database 16) of the platform 100, including creating a platform patient ID for the platform 100, which is mapped to the patient ID associated with the external system 150. The patient API 311 may transmit a response to the external system 150, for example, providing data including the platform patient ID.

[0095] In action 620, the external system 150 creates a request for creating a personalized therapy treatment order and scheduling a personalized therapy treatment event, wherein the request includes a patient ID, therapy data, order site data, region data, and milestone data (and optional custom data (standards), such as frozen storage) associated with the external system 150. The ordering API 313 receives and processes the request with input data (and workflow variation information) and generates output that can be processed by the enterprise software platform 100 to generate one or more actions. In response to the request for action 620 (provided by the ordering API 313), the enterprise software platform 100 can create a treatment order and identity chain (COI) in the data system of the platform 100 (e.g., database 16), which includes order data, therapy data, the patient's COI, and a pending timeline. An example of the created COI identifier is shown in Table 2. Similarly, the enterprise software platform 100 can select a product itinerary and create an approved order status identifier. The ordering API 313 can transmit a response to the external system 150, such as providing data including the COI.

[0096] In action 630, the external system 150 creates a request for editing patient details, which may include, for example, adding or modifying patient data such as patient name, birthday, contact information, etc. The patient API 311 receives and processes the request with input data and produces output that can be processed by the enterprise software platform 100 to produce one or more actions. In response to the request for action 630 (provided by the patient API 311), the enterprise software platform 100 may input the data in the created patient associated with the platform patient ID into the data system (e.g., database 16) of the platform 100. For example, in some implementations, as part of a data transaction implemented by the patient API 311 after receiving a request from the external system 150, the patient API 311 may query the enterprise software platform 100 using the patient ID to obtain the platform patient ID from the patient record stored on the data system of the platform 100, which the patient API 311 may use to interface with various services within the platform 100 to update the patient data. As an example, the platform 100 may format the patient data based on the platform patient ID to conform to the constraints and / or requirements associated with the particular patient entry. The patient API 311 may transmit a response to the external system 150, such as providing data including updated patient details.

[0097] In action 640, the external system 150 creates a request for rescheduling the personalized therapy treatment, wherein the request includes the (updated) milestone data. The scheduling API 315 receives and processes the request with the updated milestone data and generates an output that can be processed by the enterprise software platform 100 to generate one or more actions. In response to the request for action 640 (provided by the scheduling API 315), the enterprise software platform 100 can create a timeline of events in the personalized therapy treatment schedule that changes the data system (e.g., database 16) of the platform 100, for example, to create a modified timeline. The scheduling API 315 can transmit a response to the external system 150, for example, providing data including the updated schedule data.

[0098] In action 650, the external system 150 creates a request for canceling an order for a personalized therapy treatment, wherein the request includes a patient ID and / or COI. The ordering API 313 and the scheduling API 315 receive and process the request with the patient ID and / or COI, and generate corresponding outputs that can be processed by the enterprise software platform 100 to generate one or more actions. In response to the request for action 650 (provided by the ordering API 313 and / or the scheduling API 315), the enterprise software platform 100 can create shipments, schedules, and treatment cancellations in the data system (e.g., database 16) of the platform 100. For example, in some specific implementations of action 650, the ordering API 313 queries the order for which cancellation has been requested and verifies that it is in a state that can be canceled; then, the ordering API 313 sends a request to the workflow engine to cancel all ongoing processes (e.g., sample collection, manufacturing, and / or delivery-treatment infusion). In addition, the ordering API 313 can attach a "cancel" flag to the backend model, and can send a request to the scheduling API 315 to cancel the scheduling and shipment of the order. In such a specific implementation, the scheduling API 315 requests the internal shipping service to cancel all shipments for the order. The ordering API 313 can transmit a response to the external system 150, such as providing a notification of the order cancellation.

[0099] Figure 7A diagram of an example implementation of a method 700 for creating a treatment workflow based on an order request submitted by an external system 150 by an enterprise software platform 100 is shown. The method 700 includes a process 710 for a user (e.g., an ordering nurse using a client computing device 14 of a healthcare facility system 152) to submit an order request for a personalized therapy treatment for a patient. The method 700 includes a process 720 of processing the order request by an API 313 (e.g., an ordering API 110) to provide order details (e.g., data from an order request structured for the enterprise software platform 100) to the enterprise software platform 100. The method 700 includes a process 730 of creating an order at the enterprise software platform 100 based on the received order details. The method 700 includes a process 730 of receiving approval data by, for example, the API 110 and processing approval of the order to provide order approval to the enterprise software platform 100. For example, in some implementations, the platform 100 may create an order at process 730 without the order being approved, wherein the order is created but the method 700 cannot continue to process the unapproved order until an approval is received; for example, in such implementations, the created but unapproved order may be queued and await approval. Upon receiving and processing the approval at process 740, the method 700 includes a process 750 of executing the order at the enterprise software platform. In some embodiments of process 750, process 750 includes: a process 752 for creating a data layer object for data associated with the personalized therapy treatment; a process 754 for creating a schedule for the personalized therapy; a process 756 for processing order approval; and a process 758 for creating one or more supply chain processes (e.g., such as a collection process, a manufacturing process, a delivery process, etc.) for the personalized therapy. The method 700 includes a process 760 for generating event data for the created order at the enterprise software platform 100. The method 700 includes a process 770 of providing the created order data that can be displayed on the user interface. In a specific implementation of process 770, a display device (e.g., client computer device 14 of enterprise software platform 100 and / or client computer device 14 of external system 150) receives the created order data and presents a user interface to be displayed. In some specific implementations of process 770, client computer device 14 of external system 150 may receive displayable data corresponding to the created order data via API 110 that processes the created order data to structure the created order data that may be presented by external system 150 for display on the user interface.

[0100] Example computing device

[0101] Figure 8 Shows Figure 11 is a block diagram of an example embodiment of computer devices 12 and 14 in an environment 10 of FIG. In various implementations, computing devices 12, 14 may include server computing devices, desktop or laptop computing devices, mobile computing devices such as smart phones, tablets, smart watches or other wearable devices, and other suitable types of computing devices. Figure 8As shown, computer devices 12, 14 include a data processing unit and an optional display unit and / or a wireless communication unit. For example, computer devices 12, 14 can be implemented as client computers. Moreover, for example, computer devices 12, 14 can be implemented as server computers. The data processing unit of computer devices 12, 14 includes one or more processors operable to process data, one or more memories communicating with the processor to store data, and an input / output unit (I / O) that connects the processor and / or memory to other software or hardware modules, units or devices of computer devices 12, 14 or external devices. For example, the one or more processors may include a central processing unit (CPU), a graphics processing unit (GPU), a microcontroller unit (MCU) or other processors. For example, the one or more memories may include and store processor executable code, which, when executed by the processor, configures the data processing unit to perform various operations, such as receiving information, commands and / or data, processing information and data, and transmitting or providing information / data to another device. In some specific implementations, the data processing unit can transmit raw data or processed data to a computer system or communication network (referred to as a "cloud") that can be accessed via the Internet, which includes one or more remote computing processing devices (e.g., servers in the cloud). In order to support the various functions of the data processing unit, the one or more memories can store information and data, such as instructions, software, values, images, and other data processed or referenced by the processor. For example, various types of random access memory (RAM) devices, read-only memory (ROM) devices, flash memory devices, and other suitable storage media can be used to implement the storage function of one or more memories. In some embodiments of computer devices 12 and 14, for example, computer devices 12, 14 may optionally include a wireless communication unit 19, which can communicate data with the data processing unit via I / O. The I / O of the data processing unit can enable the data processing unit to be interfaced so as to utilize various types of wired or wireless interfaces compatible with typical data communication standards. For example, the I / O can be used for the data processing unit to communicate with other devices via a wireless transmitter / receiver (Tx / Rx) unit. The typical data communication standards include, but are not limited to, Bluetooth, Bluetooth Low Energy (BLE), Zigbee, IEEE 802.11, wireless local area network (WLAN), wireless personal area network (WPAN), wireless wide area network (WWAN), WiMAX, IEEE 802.16 (Worldwide Interoperability for Microwave Access (WiMAX)), 3G / 4G / LTE / 5G cellular communication methods, NFC (Near Field Communication) and parallel interfaces.The I / O of the data processing unit may also interface with other external interfaces, data storage sources, and / or visual or audio display devices, etc., to retrieve and transfer data and information that may be processed by the processor, stored in the memory unit, or presented on the output unit of the computer device 12, 14 or an external device. In some embodiments of the computer devices 12 and 14, for example, the computer devices 12, 14 may optionally include a display unit 17, which communicates data with the data processing unit, for example via the I / O, to provide a visual display, an audio display, and / or other sensory display of a user interface of a software application program according to the disclosed technology. In some examples, the display unit 17 may include various types of screen displays, speakers, or printing interfaces, such as, but not limited to, light emitting diode (LED), or liquid crystal display (LCD) monitors or screens, cathode ray tubes (CRT) as visual displays; audio signal transducer devices as audio displays; and / or toner, liquid inkjet, solid ink, dye sublimation, inkless (e.g., thermal or UV) printing devices, etc.

[0102] The specific implementation of the subject matter and functional operations described in this patent document can be implemented in various systems, digital electronic circuit systems, or in computer software, firmware or hardware (including the structures disclosed in this specification and their structural equivalents), or in a combination of one or more thereof. The specific implementation of the subject matter described in this specification can be implemented as one or more computer program products, that is, one or more modules of computer program instructions encoded on a tangible and non-transitory computer-readable medium, so as to be executed by a data processing device or to control the operation of the data processing device. The computer-readable storage medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a material composition that performs a machine-readable propagation signal, or a combination of one or more of them. The term "data processing unit" or "data processing device" covers all devices, equipment and machines for processing data, including programmable processors, computers, or multiple processors or computers by way of example. In addition to hardware, the device may also include code that creates an execution environment for the computer program in question, for example, code that constitutes a processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[0103] A computer program (also referred to as a program, software, software application, script, or code) may be written in any form of programming language, including compiled or interpreted languages; and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files storing one or more modules, subroutines, or code portions). A computer program may be deployed to execute on one computer or on multiple computers located at one site or distributed over multiple sites and interconnected by a communications network.

[0104] The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. These processes and logic flows can also be performed by a dedicated logic circuit system (e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit)), and the device can also be implemented as the dedicated logic circuit system.

[0105] By way of example, processors suitable for executing computer programs include both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally speaking, the processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally speaking, a computer will also include one or more mass storage devices (e.g., magnetic disks, magneto-optical disks, or optical disks) for storing data or be operably coupled to the one or more mass storage devices to receive data from it or transfer data to it or both. However, a computer does not have to have such devices. Computer-readable media suitable for storing computer program instructions and data include: all forms of non-volatile memory, media, and memory devices, including, by way of example, semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices. The processor and memory may be supplemented by or incorporated in a dedicated logic circuit system.

[0106] Example

[0107] Several aspects of the present technology are described in the following embodiments. Although several aspects of the present technology are described in the embodiments for systems, computer-readable media, and methods, in other embodiments, any of these aspects of the present technology may be similarly described in the embodiments for any of the systems, computer-readable media, and methods.

[0108] 1. An enterprise software platform for orchestrating personalized therapy development and / or treatment orders in a supply chain, the enterprise software platform comprising:

[0109] one or more processors; and

[0110] one or more storage devices coupled to the one or more processors and configured to store instructions that, when executed by the one or more processors, cause the enterprise software platform to perform operations comprising:

[0111] transmitting data to and receiving data from one or more remote computing devices operating software systems external to the enterprise software platform,

[0112] Wherein the data transmitted to and received from the one or more remote computing devices is passed through a set of application programming interfaces (APIs), the API set including a patient API for managing data transactions associated with patient data, an ordering API for managing data transactions associated with personalized therapy treatment order data, and a scheduling API for managing data transactions associated with personalized therapy treatment scheduling data.

[0113] 2. The enterprise software platform of embodiment 1, wherein the patient API is configured to structure the patient data from a first data structure associated with the external software system into a second data structure that can be read and processed by the enterprise software platform.

[0114] 3. An enterprise software platform according to embodiment 1 or 2, wherein the patient API is configured to facilitate creation of a new patient data record in the enterprise software platform, the new patient data record including a platform patient identifier (ID), the platform patient ID corresponding to an external system patient ID included in the patient data.

[0115] 4. The enterprise software platform of any one of embodiments 1 to 3, wherein the patient data received from the external system includes the external system patient ID, ordering agency information associated with the external software system, and patient information.

[0116] 5. The enterprise software platform of embodiment 4, wherein the enterprise software platform is configured to restrict access to the patient information to users who do not have the ordering institution information of the external software system.

[0117] 6. An enterprise software platform according to any one of embodiments 1 to 5, wherein the ordering API is configured to structure the personalized therapy treatment order data from a third data structure associated with the external software system into a fourth data structure that can be read and processed by the enterprise software platform.

[0118] 7. An enterprise software platform according to embodiment 6, wherein the ordering API is configured to create, modify and / or cancel the personalized therapy development and / or treatment orders in the supply chain in the ordering data in the enterprise software platform, wherein the ordering data includes one or more of the following: (i) patient reference; (ii) product information; (iii) ordering agency information associated with the external software system; (iv) regional information associated with the location of the product or the treatment; (v) indication data; (vi) milestone data; and (vii) configurable workflow criteria that can be configured by a user of the external software system.

[0119] 8. An enterprise software platform according to embodiment 7, wherein the ordering API is configured to automatically select a workflow for actions in the supply chain from a plurality of workflows stored by the enterprise software platform by utilizing the configurable workflow criteria to include attributes of the personalized therapy development or treatment order to select the most appropriate workflow from the plurality of workflows.

[0120] 9. An enterprise software platform according to any one of embodiments 1 to 8, wherein the scheduling API is configured to structure the scheduling data from a fifth data structure associated with the external software system into a sixth data structure that can be read and processed by the enterprise software platform.

[0121] 10. The enterprise software platform of embodiment 9, wherein the scheduling API is configured to create, update, or cancel a milestone schedule for the personalized therapy development and / or treatment orders in the supply chain.

[0122] 11. The enterprise software platform of embodiment 10, wherein the scheduling data includes an order reference, an external system patient ID, a treatment reference, and / or milestone data.

[0123] 12. A method for orchestrating personalized therapy development and / or treatment orders in a supply chain, the method comprising:

[0124] transmitting data from the server to and receiving data from one or more remote computing devices operating software systems external to the enterprise software platform,

[0125] wherein the data transmitted to and received from the one or more remote computing devices is passed through an application programming interface (API) set, the API set comprising:

[0126] a patient API that manages data transactions associated with patient data,

[0127] an ordering API that manages data transactions associated with personalized therapy treatment order data, and

[0128] A scheduling API for managing data transactions associated with personalized therapy treatment scheduling data.

[0129] 13. A method according to embodiment 12, wherein the patient API is configured to facilitate creation of a new patient data record in the enterprise software platform, the new patient data record including a platform patient identifier (ID), the platform patient ID corresponding to an external system patient ID included in the patient data.

[0130] 14. The method according to Example 12 or Example 13, wherein the patient data received from the external system includes the external system patient ID, ordering agency information associated with the external software system, and patient information.

[0131] 15. The method of embodiment 14, wherein the enterprise software platform is configured to restrict access to the patient information to users who do not have the ordering institution information of the external software system.

[0132] 16. A method according to any one of embodiments 12 to 15, wherein the ordering API is configured to structure the personalized therapy treatment order data from a third data structure associated with the external software system into a fourth data structure that can be read and processed by the enterprise software platform.

[0133] 17. The method of any one of embodiments 12 to 16, wherein:

[0134] The ordering API is configured to create, modify and / or cancel the personalized therapy development and / or treatment order in the supply chain in the ordering data in the enterprise software platform; and

[0135] The ordering data includes one or more of: (i) a patient reference; (ii) product information; (iii) ordering agency information associated with the external software system; (iv) regional information associated with the location of the product or treatment; (v) indication data; (vi) milestone data; and (vii) configurable workflow criteria that can be configured by a user of the external software system.

[0136] 18. A method according to any one of embodiments 12 to 17, wherein the ordering API is configured to automatically select a workflow for actions in the supply chain from a plurality of workflows stored by the enterprise software platform by utilizing the configurable workflow criteria to include attributes of the personalized therapy development or treatment order to select the most appropriate workflow from the plurality of workflows.

[0137] 19. The method of any one of embodiments 12 to 18, wherein:

[0138] The scheduling data includes an order reference, an external system patient ID, a treatment reference, and / or milestone data; and

[0139] The scheduling API is configured to create, update, or cancel a milestone schedule for the personalized therapy development and / or treatment orders in the supply chain.

[0140] 20. A non-transitory computer readable medium having stored thereon instructions that, when executed by one or more processors of a computing system, cause the computing system to perform operations for orchestrating personalized therapy development and / or treatment orders in a supply chain, the operations comprising:

[0141] transmitting data to and receiving data from one or more remote computing devices operating a software system external to the enterprise software platform, wherein the data transmitted to and received from the one or more remote computing devices is passed through a set of application programming interfaces (APIs), the API set including a patient API for managing data transactions associated with patient data, an ordering API for managing data transactions associated with personalized therapy treatment order data, and a scheduling API for managing data transactions associated with personalized therapy treatment scheduling data.

[0142] in conclusion

[0143] According to the foregoing, it should be understood that the specific embodiments of the present technology have been described herein for the purpose of illustration, but the well-known structure and function are not shown or described in detail to avoid unnecessary confusion in the description of the embodiments of the present technology. To the extent that any material incorporated herein by reference conflicts with the present disclosure, the present disclosure shall prevail. Where the context permits, singular or plural terms may also include plural or singular terms, respectively. Moreover, unless the word "or" is explicitly limited to only mean a single item excluded from other items when referring to a list of two or more items, otherwise the use of "or" in such lists will be interpreted as including any single item in (a) the list, all items in (b) the list, or any combination of items in (c) the list. As used herein, the phrase "and / or" as in "A and / or B" refers to a single A, a single B, and both A and B. Where the context permits, a singular or plural term may also include a plural or singular term, respectively. In addition, the terms “comprising,” “including,” “having,” and “with” are used throughout the text to mean including at least the stated features, such that any greater number of the same features and / or additional types of other features are not excluded.

[0144] In addition, as used herein, the term "substantially" refers to the complete or almost complete scope or degree of an action, feature, characteristic, state, structure, project or result. For example, an object that is "substantially" closed will mean that the object is completely or almost completely closed. In some cases, the degree of accuracy that can allow deviation from absolute completeness may depend on the specific context. However, in general, complete proximity will make it possible to have an overall result that is absolutely completely and completely identical with that obtained. As used herein, the purpose of "substantially" is to be equally applicable to refer to the complete or almost complete absence of an action, feature, attribute, state, structure, project or result when used in a negative sense.

[0145] The above detailed description of the embodiments of the present technology is not intended to be exhaustive or to limit the present technology to the specific forms disclosed above. Although the specific embodiments and embodiments of the present technology are described above for illustrative purposes, various modifications within the scope of the present technology are possible as will be appreciated by those skilled in the relevant art. For example, although the steps are presented in a given order, alternative embodiments may perform the steps in a different order. As another example, the various components of the present technology may be further divided into subcomponents, and / or the various components and / or functions of the present technology may be combined and / or integrated. In addition, although the advantages associated with certain embodiments of the present technology have been described in the context of these embodiments, other embodiments may also exhibit such advantages, and not all embodiments must exhibit such advantages to fall within the scope of the present technology.

[0146] It should also be noted that other embodiments besides those disclosed herein are also within the scope of the present technology. For example, embodiments of the present technology may have different configurations, components, and / or processes in addition to the configurations, components, and / or processes shown or described herein. Moreover, it will be understood by those of ordinary skill in the art that these and other embodiments may not have several of the configurations, components, and / or processes shown or described herein without departing from the present technology. Therefore, the present disclosure and associated technology may cover other embodiments not explicitly shown or described herein.

Claims

1. An enterprise software platform for orchestrating personalized therapy development and / or treatment orders in a supply chain, the enterprise software platform comprising: one or more processors; and one or more storage devices coupled to the one or more processors and configured to store instructions that, when executed by the one or more processors, cause the enterprise software platform to perform operations comprising: transmitting data to and receiving data from one or more remote computing devices operating software systems external to the enterprise software platform, Wherein the data transmitted to and received from the one or more remote computing devices is passed through a set of application programming interfaces (APIs), the API set including a patient API for managing data transactions associated with patient data, an ordering API for managing data transactions associated with personalized therapy treatment order data, and a scheduling API for managing data transactions associated with personalized therapy treatment scheduling data.

2. The enterprise software platform of claim 1, wherein the patient API is configured to structure the patient data from a first data structure associated with the external software system into a second data structure that can be read and processed by the enterprise software platform.

3. The enterprise software platform of claim 2, wherein the patient API is configured to facilitate creation of a new patient data record in the enterprise software platform, the new patient data record comprising a platform patient identifier (ID), the platform patient ID corresponding to an external system patient ID included in the patient data.

4. The enterprise software platform of claim 1, wherein the patient data received from the external system comprises the external system patient ID, ordering institution information associated with the external software system, and patient information.

5. The enterprise software platform of claim 4, wherein the enterprise software platform is configured to restrict access to the patient information to users who do not have a subscription institution information for the external software system.

6. The enterprise software platform of claim 1 , wherein the ordering API is configured to structure the personalized therapy treatment order data from a third data structure associated with the external software system into a fourth data structure that can be read and processed by the enterprise software platform.

7. An enterprise software platform according to claim 6, wherein the ordering API is configured to create, modify and / or cancel the personalized therapy development and / or treatment orders in the supply chain in the ordering data in the enterprise software platform, wherein the ordering data includes one or more of the following: (i) patient reference; (ii) product information; (iii) ordering agency information associated with the external software system; (iv) regional information associated with the location of the product or the treatment; (v) indication data; (vi) milestone data; and (vii) configurable workflow criteria that can be configured by a user of the external software system.

8. The enterprise software platform of claim 7, wherein the ordering API is configured to automatically select a workflow for actions in the supply chain among a plurality of workflows stored by the enterprise software platform by utilizing the configurable workflow criteria to include attributes of the personalized therapy development or treatment order to select a most appropriate workflow from the plurality of workflows.

9. The enterprise software platform of claim 1, wherein the scheduling API is configured to structure the scheduling data from a fifth data structure associated with the external software system into a sixth data structure that can be read and processed by the enterprise software platform.

10. The enterprise software platform of claim 9, wherein the scheduling API is configured to create, update, or cancel a milestone schedule for the personalized therapy development and / or treatment order in the supply chain.

11. The enterprise software platform of claim 10, wherein the scheduling data includes an order reference, an external system patient ID, a treatment reference, and / or milestone data.

12. A method for orchestrating personalized therapy development and / or treatment orders in a supply chain, the method comprising: transmitting data from the server to and receiving data from one or more remote computing devices operating software systems external to the enterprise software platform, wherein the data transmitted to and received from the one or more remote computing devices is passed through an application programming interface (API) set, the API set comprising: a patient API that manages data transactions associated with patient data, an ordering API that manages data transactions associated with personalized therapy treatment order data, and A scheduling API for managing data transactions associated with personalized therapy treatment scheduling data.

13. The method of claim 12, wherein the patient API is configured to facilitate creation of a new patient data record in the enterprise software platform, the new patient data record comprising a platform patient identification (ID), the platform patient ID corresponding to an external system patient ID included in the patient data.

14. The method of claim 12, wherein the patient data received from the external system includes the external system patient ID, ordering agency information associated with the external software system, and patient information.

15. The method of claim 14, wherein the enterprise software platform is configured to restrict access to the patient information to users who do not possess a subscribing institution information for the external software system.

16. The method of claim 12, wherein the ordering API is configured to structure the personalized therapy treatment order data from a third data structure associated with the external software system into a fourth data structure that can be read and processed by the enterprise software platform.

17. The method of claim 12, wherein: The ordering API is configured to create, modify and / or cancel the personalized therapy development and / or treatment order in the supply chain in the ordering data in the enterprise software platform; and The ordering data includes one or more of: (i) a patient reference; (ii) product information; (iii) ordering agency information associated with the external software system; (iv) regional information associated with the location of the product or treatment; (v) indication data; (vi) milestone data; and (vii) configurable workflow criteria that can be configured by a user of the external software system.

18. The method of claim 12, wherein the ordering API is configured to automatically select a workflow for actions in the supply chain among a plurality of workflows stored by the enterprise software platform by utilizing the configurable workflow criteria to include attributes of the personalized therapy development or treatment order to select a most appropriate workflow from the plurality of workflows.

19. The method of claim 12, wherein: The scheduling data includes an order reference, an external system patient ID, a treatment reference, and / or milestone data; and The scheduling API is configured to create, update and / or cancel a milestone schedule for the personalized therapy development and / or treatment orders in the supply chain.

20. A non-transitory computer readable medium having stored thereon instructions that, when executed by one or more processors of a computing system, cause the computing system to perform operations for orchestrating personalized therapy development and / or treatment orders in a supply chain, the operations comprising: transmitting data to and receiving data from one or more remote computing devices operating a software system external to the enterprise software platform, wherein the data transmitted to and received from the one or more remote computing devices is passed through a set of application programming interfaces (APIs), the API set including a patient API for managing data transactions associated with patient data, an ordering API for managing data transactions associated with personalized therapy treatment order data, and a scheduling API for managing data transactions associated with personalized therapy treatment scheduling data.

Images