MEDICAL ITEM RESUPPLY ENGINE AND ENGAGEMENT CONTROLLER

Techniques for improved resupply for medical items are provided. An event relating to resupply of one or more medical items for a patient is identified. The resupply requires approval from a physician. Resupply of the one or more medical items is automatically initiated, based on receiving an electronic indication of approval for the resupply from the physician. The indication of approval is received from an electronic healthcare system for the physician based on an automatically generated request for approval sent to the electronic healthcare system for the physician using an application programming interface (API). An electronic notification of the initiated resupply is transmitted to an electronic system associated with the patient. The one or more medical items are used to treat the patient. The electronic system associated with the patient is compatible with the electronic notification.

INTRODUCTION

Aspects of the present disclosure relate to patient medical care, and more specifically, to improved resupply for medical items, and improved engagement with patients and care providers.

Many medical patients have consumable medical items that must be resupplied. This can include items which must be prescribed by a physician, including a variety of home medical equipment (HME) (e.g., partially reusable or disposable HME) and prescription medications. The patients must be periodically resupplied with these consumable items. But this is a very challenging process, typically requiring manual intervention from a care provider to the patient. This results in poor patient outcomes, because difficulty in resupply can result in patients prematurely ending the associated medical treatment. It also results in increased expenses for patients, health insurers, and care providers and entities.

SUMMARY

Embodiments include a computer-implemented method. The method includes identifying an event relating to resupply of one or more medical items for a patient. The resupply requires approval from a physician. The method further includes automatically initiating resupply of the one or more medical items, based on receiving an electronic indication of approval for the resupply from the physician. The indication of approval is received from an electronic healthcare system for the physician based on an automatically generated request for approval sent to the electronic healthcare system for the physician using an application programming interface (API). The method further includes transmitting an electronic notification of the initiated resupply to an electronic system associated with the patient. The one or more medical items are used to treat the patient, and the electronic system associated with the patient is compatible with the electronic notification.

Embodiments further include an apparatus including a memory and a hardware processor communicatively coupled to the memory, the hardware processor configured to perform operations. The operations include identifying an event relating to resupply of one or more medical items for a patient. The resupply requires approval from a physician. The operations further include automatically initiating resupply of the one or more medical items, based on receiving an electronic indication of approval for the resupply from the physician. The indication of approval is received from an electronic healthcare system for the physician based on an automatically generated request for approval sent to the electronic healthcare system for the physician using an application programming interface (API). The operations further include transmitting an electronic notification of the initiated resupply to an electronic system associated with the patient. The one or more medical items are used to treat the patient, and the electronic system associated with the patient is compatible with the electronic notification.

Embodiments further include a non-transitory computer-readable medium including instructions that, when executed by a processor, cause the processor to perform operations. The operations include identifying an event relating to resupply of one or more medical items for a patient. The resupply requires approval from a physician. The operations further include automatically initiating resupply of the one or more medical items, based on receiving an electronic indication of approval for the resupply from the physician. The indication of approval is received from an electronic healthcare system for the physician based on an automatically generated request for approval sent to the electronic healthcare system for the physician using an application programming interface (API). The operations further include transmitting an electronic notification of the initiated resupply to an electronic system associated with the patient. The one or more medical items are used to treat the patient, and the electronic system associated with the patient is compatible with the electronic notification.

DETAILED DESCRIPTION

Aspects of the present disclosure provide apparatuses, methods, processing systems, and computer-readable mediums for improved medical resupply. As discussed above, resupply of consumable or disposable medical items, particularly prescription medical items, is very challenging. Existing systems require significant manual intervention from patients, physicians, and other care providers, which results in poor patient outcomes and significant inefficiencies.

One or more techniques disclosed herein relate to automated medical resupply, using a resupply engine, and patient and physician engagement systems. In an embodiment, a need for resupply for a patient can be automatically identified. For example policy rules (e.g., insurance policy rules, medical care policy rules, and any other suitable policy rules) and historical resupply order data can be used to identify when a patient is due for resupply. A resupply engine can then automatically trigger a resupply event to initiate the resupply. This can be done with no patient interaction, or with very limited patient interaction (e.g., with a simple approval request to the patient). Alternatively, or in addition, a patient can directly initiate resupply. For example, a patient can use a suitable user interface to request automatic resupply.

In an embodiment, this resupply event requires approval from a physician (e.g., it requires prescription items). In existing systems, this approval would be manually provided to the physician (e.g., through manual identification of the physician and transmission of a facsimile of the request to the physician). This is both extremely inefficient, because of the required manual intervention, and prone to failure, because a physician may not receive the facsimile or may not respond to the facsimile.

One or more techniques described herein automate the physician interaction to fulfill a resupply request (e.g., to eliminate, or significantly reduce, required human intervention). For example, a dynamic document can be generated from the resupply request. An approving physician can be automatically identified, and the dynamic document can be automatically transmitted to the physician. The physician can then use seamless electronic document signature tools to approve (or reject), the resupply request. If the request is approved it can be automatically fulfilled, without any additional intervention. Further, if the request is not approved the patient can automatically be provided with a notification of the failure and an indication of the reason for the failure.

In an embodiment, one or more of these techniques both significantly improve treatment of patients and provide technical improvements to existing electronic health systems. For example, the piecemeal and complex nature of existing systems can result in patients failing to timely request resupply, and in physicians failing to timely approve resupply requests. This can lead to patients running out of consumable medical items, forcing patients to discontinue treatment. Discontinuing treatment for the patients can worsen patient health outcomes and harm patient treatment. One or more techniques disclosed herein improve patient health outcomes by automating resupply requests, allowing for seamless physician approval of resupply requests, and automating fulfilment of approved resupply requests.

Further, one or more techniques disclosed herein provide for prophylactic treatment of patients. By identifying patients that are due for an upcoming resupply, and seamlessly fulfilling the resupply, these techniques can prophylactically avoid patients discontinuing treatment. This can keep patients engaged in treatment longer, improving their health outcomes. Further, alerting patients of an upcoming resupply can prompt patients that might otherwise be at risk of discontinuing treatment, to continue treatment. Automatically triggering, and fulfilling, resupply requests can both make it easier for patients positively engaged in treatment to continue treatment, and encourage patients at risk of discontinuing treatment to continue treatment (e.g., because necessary supplies are automatically identified and provided).

Further, existing electronic health systems do not provide for end to end engagement from a patient to a physician, for resupply. These systems can require computationally complex, and inefficient, analysis to communicate with patients and physicians across incompatible systems. For example, a patient may manually initiate a resupply request in an electronic system, but the system may not be able to contact the physician or complete the request (e.g., because of incompatibilities across the system). This results in wasted computational resources for the unfulfilled request, and potential failure by the system to complete the request. One or more techniques disclosed herein allow for seamless interaction from a patient to a physician and a resupply engine, reducing computational waste and reducing system failure. For example, one or more techniques disclosed herein provide improvements to electronic healthcare systems by verifying the compatibility of relevant electronic healthcare systems (e.g., patient related and physician related systems) and proceeding with automating resupply requests only for compatible systems.

FIG.1depicts a computing environment100for an automated medical resupply engine and engagement controller, according to one embodiment. In an embodiment the computing environment100includes a patient engagement layer110. The patient engagement layer110facilitates engagement with a patient (e.g., through electronic transmissions, telephone calls, and any other suitable techniques) for automated medical resupply. This is discussed further with regard toFIGS.10-11, below.

For example, the patient engagement layer110can facilitate transmitting electronic messages (e.g., short message service (SMS) messages, multimedia messaging service messages (MMS), e-mail messages, or any other suitable electronic messages) to a patient, and receiving electronic messages from a patient, to facilitate automated medical resupply. This is merely one example. In an embodiment, the patient engagement layer110interacts with one or more third party systems112, a patient interface114(e.g., an electronic interface to communicate with a patient), and any other suitable components.

In an embodiment, the patient engagement layer110communicates with a control layer150including an engagement controller130and a resupply engine140. For example, the engagement controller130can control patient engagement to facilitate automated medical resupply. The engagement controller130is discussed further, below, with regard toFIG.2. In an embodiment, the patient engagement layer110communicates with the engagement controller130using a suitable communication network, including the Internet, a wide area network, a local area network, or a cellular network, and uses any suitable wired or wireless communication technique (e.g., WiFi or cellular communication).

In an embodiment the computing environment100further includes a physician engagement layer120. The physician engagement layer120facilitates engagement with a physician (e.g., through electronic transmissions to an electronic healthcare system, telephone calls, and any other suitable techniques) for automated medical resupply. This is discussed further with regard toFIGS.3-9, below.

For example, the physician engagement layer120can facilitate automated medical resupply of prescription items by creating necessary dynamic documents, and presenting the documents to physicians for review and electronic signature. This is merely one example. In an embodiment, the physician engagement layer120interacts with one or more third party systems122, a prescription management system124(e.g., an electronic prescription management system), and any other suitable components.

In an embodiment, the physician engagement layer120communicates with the engagement controller130. For example, the engagement controller130can control physician engagement to facilitate automated medical resupply. In an embodiment, the physician engagement layer120communicates with the engagement controller130using a suitable communication network, including the Internet, a wide area network, a local area network, or a cellular network, and uses any suitable wired or wireless communication technique (e.g., WiFi or cellular communication).

In an embodiment, the engagement controller130interacts with the resupply engine140. For example, the resupply engine140can interact with the engagement controller130to generate resupply events and facilitate resupply. This can include facilitating all suitable aspects of resupply, including ordering, shipping, billing, and any other suitable tasks. For example, the engagement controller130can control interactions with the patient engagement layer110and physician engagement layer120to initiate, and complete, resupply orders using the resupply engine140. These are merely examples, and the engagement controller130and resupply engine140can respectively perform any suitable tasks or combinations of tasks. For example, the engagement controller130and resupply engine140can be combined together to control both engagement (e.g., with patients and physicians) and resupply. As another example, the resupply engine140can interact directly with the patient engagement layer110and the physician engagement layer120(e.g., without the engagement controller130).

In an embodiment, the engagement controller130can identify how to contact a particular patient or physician through queries to the patient engagement layer110and physician engagement layer120. For example, a patient engagement layer110can relate to multiple different healthcare entities with a large number of patients. The engagement controller130can determine how to contact a particular patient by querying each electronic healthcare system associated with the patient engagement layer (e.g., using a suitable identifier or identifiers associated with the patient), and receiving a response from the electronic healthcare system related to the patient (e.g., the patient's insurer, healthcare provider, or any other suitable healthcare entity). In an embodiment, the engagement controller130can determine whether the electronic healthcare system related to the patient engagement layer110is compatible with the control layer150(e.g., with the engagement controller130, the resupply engine140, or both). The engagement controller130can decline to interact further with an incompatible patient engagement layer110. An electronic healthcare system that does not recognize the requested patient will not respond, or will respond with an indication that the patient is not recognized. An electronic healthcare system that recognizes the patient will respond with an indication that the patient is successfully recognized. The engagement controller130can use that successful response to determine how to engage with the patient in the future.

Similarly, the engagement controller130can determine how to contact a particular physician by querying each electronic healthcare system associated with the physician engagement layer (e.g., using a suitable identifier or identifiers associated with the physician, including a national provider identifier (NPI)), and receiving a response from the electronic healthcare system related to the physician (e.g., a healthcare entity where the physician works). In an embodiment, the engagement controller130can determine whether the electronic healthcare system related to the physician engagement layer120is compatible with the control layer150(e.g., with the engagement controller130, the resupply engine140, or both). The engagement controller130can decline to interact further with an incompatible physician engagement layer120. In an embodiment, an electronic healthcare system that does not recognize the requested physician will not respond, or will respond with an indication that the physician is not recognized. An electronic healthcare system that recognizes the physician will respond with an indication that the physician is successfully recognized. The engagement controller130can use that successful response to determine how to engage with the physician in the future.

In an embodiment, the engagement controller130interacts with a single patient engagement layer110and a single physician engagement layer120(e.g., each associated with multiple healthcare entities). Alternatively, or in addition, the engagement controller130can interact with multiple patient engagement layers110(e.g., each associated with a particular healthcare entity or small number of healthcare entities), multiple physician engagement layers120(e.g., each associated with a particular healthcare entity or small number of healthcare entities), or both. In this example, the engagement controller130can query multiple patient engagement layers110and multiple physician engagement layers120, as appropriate, to determine how to contact the respective patient and physician.

In an embodiment the patient engagement layer110, the physician engagement layer120, the engagement controller130, and the resupply engine140, can be implemented using any suitable combination of physical compute systems, cloud compute nodes and storage locations, or any other suitable implementation. For example, the patient engagement layer110, the physician engagement layer120, the engagement controller130, and the resupply engine140could each be implemented using a respective server or cluster of servers. As another example, the patient engagement layer110, the physician engagement layer120, the engagement controller130, and the resupply engine140can be implemented using a combination of compute nodes and storage locations in a suitable cloud environment. For example, one or more of the components of the patient engagement layer110, the physician engagement layer120, the engagement controller130, and the resupply engine140can be implemented using a public cloud, a private cloud, a hybrid cloud, or any other suitable implementation.

FIG.2depicts a block diagram for an engagement controller130and a resupply engine140to interact with an automated resupply engine, according to one embodiment. The engagement controller130includes a processor202, a memory210, and network components220. The memory210may take the form of any non-transitory computer-readable medium. The processor202generally retrieves and executes programming instructions stored in the memory210. The processor202is representative of a single central processing unit (CPU), multiple CPUs, a single CPU having multiple processing cores, graphics processing units (GPUs) having multiple execution paths, and the like.

The network components220include the components necessary for the engagement controller130to interface with a suitable communication network (e.g., a communication network interconnecting various components of the computing environment100illustrated inFIG.1, or interconnecting the computing environment100with other computing systems). For example, the network components220can include wired, WiFi, or cellular network interface components and associated software. Although the memory210is shown as a single entity, the memory210may include one or more memory devices having blocks of memory associated with physical addresses, such as random access memory (RAM), read only memory (ROM), flash memory, or other types of volatile and/or non-volatile memory.

The memory210generally includes program code for performing various functions related to use of the engagement controller130. The program code is generally described as various functional “applications” or “modules” within the memory210, although alternate implementations may have different functions and/or combinations of functions. Within the memory210, the engagement service212facilitates patient and physician engagement for automated medical resupply (e.g., using the patient engagement layer110and physician engagement layer120illustrated inFIG.1). This is discussed further, below, with regard toFIGS.3-9.

The resupply engine140includes a processor252, a memory260, and network components270. The memory260may take the form of any non-transitory computer-readable medium. The processor252generally retrieves and executes programming instructions stored in the memory260. The processor252is representative of a single central processing unit (CPU), multiple CPUs, a single CPU having multiple processing cores, graphics processing units (GPUs) having multiple execution paths, and the like.

The network components270include the components necessary for the resupply engine140to interface with a suitable communication network (e.g., a communication network interconnecting various components of the computing environment100illustrated inFIG.1, or interconnecting the computing environment100with other computing systems). For example, the network components270can include wired, WiFi, or cellular network interface components and associated software. Although the memory260is shown as a single entity, the memory260may include one or more memory devices having blocks of memory associated with physical addresses, such as random access memory (RAM), read only memory (ROM), flash memory, or other types of volatile and/or non-volatile memory.

The memory260generally includes program code for performing various functions related to use of the resupply engine140. The program code is generally described as various functional “applications” or “modules” within the memory260, although alternate implementations may have different functions and/or combinations of functions. Within the memory260, the resupply engine140facilitates automated medical resupply. This is discussed further, below, with regard toFIGS.3-8.

While the engagement controller130and resupply engine140are each illustrated as a single entity, in an embodiment, the various components can be implemented using any suitable combination of physical compute systems, cloud compute nodes and storage locations, or any other suitable implementation. For example, the engagement controller130, the resupply engine140, or both, could be implemented using a server or cluster of servers. As another example, the engagement controller130, the resupply engine140, or both, can be implemented using a combination of compute nodes and storage locations in a suitable cloud environment. For example, one or more of the components of the engagement controller130, the resupply engine140, or both, can be implemented using a public cloud, a private cloud, a hybrid cloud, or any other suitable implementation.

AlthoughFIG.2depicts the engagement service212and the resupply service262as being separately located in respective memories210and260, that representation is also merely provided as an illustration for clarity. More generally, the engagement controller130, the resupply engine140, or both, may include one or more computing platforms, such as computer servers for example, which may be co-located, or may form an interactively linked but distributed system, such as a cloud-based system, for instance. As a result, the processors202and252, and the memories210and260, may correspond to distributed processor and memory resources within the computing environment100. Thus, it is to be understood that any, or all, of the engagement service212and the resupply service may be stored together, or remotely from one another, within the distributed memory resources of the computing environment100.

FIG.3is a flowchart300illustrating an automated medical resupply engine, according to one embodiment. At block302a resupply service (e.g., the resupply service262illustrated inFIG.2) receives a resupply event. For example, the resupply service can receive an event describing an upcoming resupply for a patient. In an embodiment, the resupply event is generated by a resupply engine (e.g., the resupply engine140illustrated inFIGS.1-2) or by another suitable software system. For example, the resupply engine can track necessary resupplies for patients, and can trigger events, as necessary, to initiate a resupply. In this example, the resupply engine can analyze policy rules (e.g., insurance policy rules, medical care policy rules, and any other suitable policy rules) to identify the appropriate time to trigger a resupply event. In an embodiment the resupply engine can further review prior resupply orders (e.g., for a given patient, category of patients, or group of patients) to identify the appropriate time to trigger a resupply event. The resupply engine can review prior orders instead of, or in addition to, reviewing policy rules.

Alternatively, or in addition, the resupply event is generated by an engagement service (e.g., the engagement service212illustrated inFIG.2). For example, a patient can initiate an electronic message from a patient computing device (e.g., as part of the patient engagement layer110) describing a resupply order. The engagement service can generate a resupply event from this message and provide the resupply event to the resupply engine. This message can be initiated by a patient, can come in response to a prompt or reminder to the patient (e.g., an SMS message or another electronic message reminding the patient to resupply HME), or can come from any other source.

In an embodiment, the resupply order includes identifying information used to fulfill the order. For example, the resupply order can include a referral ID or any other suitable identifier. The resupply service, or another suitable service, can use the referral ID to identify the resupply request. For example, the resupply service can query an electronic repository (e.g., an electronic database, cloud storage repository, or any other suitable electronic repository) using the referral ID. This is merely an example, and the resupply order can include any suitable identifying information.

At block304, the resupply service (or another suitable service) determines whether dynamic documents are needed. For example, the resupply service can determine that the resupply order relates to a prescription item. The resupply service can generate a dynamic electronic document that contains information about the patient, the approving physician, and the resupply event (e.g., the resupply request). The engagement service can then provide this electronic document to the physician, and can facilitate having the physician sign the document to fulfill the resupply request.

If the resupply service determines that a dynamic document is needed, the flow proceeds to block306. At block306, the resupply service creates the dynamic document. For example, as discussed above, the resupply service can generate a dynamic electronic document that contains information about the patient, the approving physician, and the resupply event (e.g., the resupply request). The dynamic electronic document can further include a document identifier (e.g., a unique identifier within the engagement and resupply system). This is discussed further, below, with regard toFIGS.4-6.

At block308the resupply service determines whether a signature is needed. For example, as discussed above, the resupply order may relate to a prescription item that requires a physician signature. If it does, the flow proceeds to block310.

At block310, the engagement service collects the electronic signature. For example, the engagement system can provide the dynamic document created at block306to a physician engagement layer (e.g., the physician engagement layer120illustrated inFIG.1) and can request a signature. The physician engagement layer can collect the signature. Further, as discussed above in relation toFIG.1, the engagement service can determine whether the physician engagement layer is compatible with the engagement service. In an embodiment, the engagement service proceeds to collect the electronic signature only if the physician engagement service is compatible. Collecting the electronic signature is discussed further, below, with regard toFIGS.7-9.

At block312, the engagement service determines whether the signature collection was a success. For example, the physician engagement layer can determine that the signature was successful or unsuccessful, and can provide an electronic message notifying the engagement service. This is discussed further, below, with regard toFIGS.8A-C.

If collecting the electronic signature is successful, the flow proceeds to block314. At block314the resupply service processes the resupply. For example, the resupply service can complete the order (e.g., using a suitable logistics system), can handle billing and payment, and can request delivery to the patient.

At block316, the engagement service notifies the patient. For example, the engagement service can use the patient engagement layer to notify the patient that the resupply order was processed successfully, using a suitable electronic message. Further, as discussed above in relation toFIG.1, the engagement service can determine whether the patient engagement layer is compatible with the engagement service. In an embodiment, the engagement service proceeds to notify the patient only if the patient engagement service is compatible.

Returning to block312, if the electronic signature is not successful, the flow proceeds to block318. At block318the engagement service notifies the physician that the signature was not successful. For example, the engagement service can transmit an electronic message to the physician indicating that the signature was not successful. This is merely an example, and the engagement service can use a telephone call or any other notification. In an embodiment, the physician notification requests that the physician complete the necessary signatures and documentation to complete the resupply. Further, at block316the engagement service can notify the patient that the resupply was not successful (e.g., because of the signature failure). This is discussed further with regard toFIG.8C, below.

FIG.4is a flowchart400illustrating dynamic document creation for an automated medical resupply engine, according to one embodiment. In an embodiment,FIG.4relates to block306illustrated inFIG.3. At block402a resupply service (e.g., the resupply service262illustrated inFIG.2) identifies the approving physician. For example, as discussed above, in an embodiment the dynamic document is created to facilitate review of a prescription by an approving physician. The resupply service can use a referral ID, or any other suitable identifier associated with the resupply request, to identify the approving physician. For example, the resupply service can look up the approving physician in a suitable electronic repository (e.g., an electronic database) using the referral ID. As another example, the resupply service can use a third party prescription system (e.g., using a suitable API) to identify the approving physician. These are merely examples, and the resupply service can use any suitable technique.

Further, in an embodiment, an engagement service (e.g., the engagement service212illustrated inFIG.2) determines how to contact the physician by identifying an electronic healthcare system with which the physician is associated. For example, as discussed above in relation toFIG.1, the engagement service can query multiple electronic healthcare systems using a suitable identifier associated with the physician (e.g., an NPI) to identify which electronic healthcare system is currently associated with the physician. This is discussed further, below, with regard toFIG.5. Further, as discussed above in relation toFIG.1, the engagement service can determine whether the electronic healthcare system with which the physician is associated is compatible with the engagement service. In an embodiment, the engagement service only if the electronic healthcare system with which the physician is associated is compatible.

At block404the resupply service creates the dynamic document. For example, the resupply service can create a document identifying the patient, the approving physician, and the resupply event (e.g., the resupply request). This is discussed further, below, with regard toFIG.6. As another example, the resupply service can provide the patient, approving physician, and resupply event information to an engagement service (e.g., the engagement service212illustrated inFIG.2) and the engagement service can create the document.

At block406the resupply service returns a document identifier. In an embodiment, the resupply service (or other suitable service) creates a document identify associated with the dynamically created document. This document identifier can be unique within the resupply engine (e.g., within the resupply engine140illustrated inFIGS.1-2) and the engagement controller (e.g., within the engagement controller130illustrated inFIGS.1-2) and can be used to uniquely identify the newly created document. The resupply service can return the document identifier to the entity requesting creation of the document (e.g., the engagement controller).

FIG.5illustrates identifying an approving physician for dynamic document creation for an automated medical resupply engine, according to one embodiment. In an embodiment,FIG.5corresponds with block402discussed above in relation toFIG.4. A resupply engine140(e.g., the resupply service262illustrated inFIG.2) transmits a physician contact request502to an engagement controller130(e.g., the engagement service212illustrated inFIG.2). For example, the resupply engine140can include an identifier for the physician (e.g., an NPI), an identifier for a healthcare entity with which the physician is associated (if available), and any other suitable information in the physician contact request502

In an embodiment, the engagement controller transmits an API request504to a physician engagement layer120. In one embodiment, the engagement controller identifies a healthcare entity with which the physician is associated (e.g., among a number of available healthcare entities) using a healthcare entity identifier provided by the resupply engine140. Alternatively, or in addition, as discussed above in relation toFIG.1the engagement controller identifies a healthcare entity with which the physician is associated by transmitting queries to each potential electronic healthcare system and waiting for a success response from one of the electronic healthcare systems. Further, as discussed above in relation toFIG.1, the engagement service can determine whether the physician engagement layer is compatible with the engagement service. In an embodiment, the engagement service proceeds to collect the electronic signature only if the physician engagement service is compatible.

In an embodiment, the physician engagement layer120responds to the API request504with physician information506. For example, the physician information506can include information relating to the physician, including an identifier for a location at which the physician can be contacted. In an embodiment, a given physician can practice at multiple locations, and the physician information506can identify all the available locations.

In an embodiment, the engagement controller130receives the physician information506, and transmits an update physician record508message to update a physician record510. For example, the engagement controller130can update a physician record510stored in a repository accessible to the engagement controller130, the resupply engine140, or both, to reflect the physician information506. In an embodiment the physician record510can be stored in a local storage location, or a remote storage location, including a suitable cloud storage location. Further, the physician record510can be stored in a suitable electronic database (e.g., a relational database or a graph database) or any other suitable repository.

Further, in an embodiment, the engagement controller130can update an enrolled status for the physician in the physician record510, to indicate that the physician is accessible (e.g., for electronic signature). In an embodiment, the engagement service can also determine whether the physician is currently active. For example, the engagement service can identify a last signature date for a given physician. If the last signature date is sufficiently recent (e.g., occurred within a threshold period in the past), the physician is considered active. If the last signature date is not sufficiently recent (e.g., occurred outside of a threshold period in the past), the physician is considered likely inactive and the enrolled status is not updated.

FIG.6further illustrates dynamic document creation for an automated medical resupply engine, according to one embodiment. In an embodiment,FIG.6provides additional description for creating a dynamic document, as discussed above in relation to block306illustrated inFIG.3and inFIG.4. A resupply engine140transmits a document request602to an engagement controller130. As discussed above, in an embodiment the document request602includes identifying information for the patient, the approving physician, and resupply event (e.g., the resupply request).

The engagement controller130transmits an API call604to a physician engagement layer120. For example, the engagement controller130can make a call to the API at https://server.api.com/path/api/resupply/documents with information for a customer (e.g., a healthcare entity facilitating resupply), a patient (e.g., the patient being resupplied), a document (e.g., the document being created), and a physician (e.g., the approving physician). These are merely examples, and the API call604can include any suitable information (e.g., diagnosis codes, length of service information, product information, or any other suitable information).

The physician engagement layer120can use the API call604to create an electronic document606, suitable for a physician to review and sign (if appropriate) to fulfil a prescription. As discussed above, in one embodiment the physician engagement layer creates the document using information from the engagement controller130, resupply engine140, or both. Alternatively, or in addition, the engagement controller130creates the document, or the resupply engine140creates the document.

FIG.7illustrates an electronic signature API for an automated medical resupply engine, according to one embodiment. In an embodiment,FIG.7illustrates API calls from an engagement controller130to a physician engagement layer120.FIGS.8A-C, discussed further below, illustrates API calls from the physician engagement layer120to the engagement controller130.

A resupply engine140transmits a document signature request702to an engagement controller130. In an embodiment the document signature request702is an example of a document request502, illustrated inFIG.5. The document signature request702includes identifying information for the patient, the approving physician, and resupply event (e.g., the resupply request).

In an embodiment, the engagement controller130responds to the document signature request702by issuing a create electronic document API call704to the physician engagement layer120, and a request document signature API call706. For example, the create electronic document API call704can correspond to the API call604illustrated inFIG.6. The create electronic document API call704can include information for a customer (e.g., a healthcare entity facilitating resupply), a patient (e.g., the patient being resupplied), a document (e.g., the document being created), and a physician (e.g., the approving physician). Further, in an embodiment, the physician engagement layer120responds to the create electronic document API call704with an identifier for the newly created document (e.g., a unique identifier).

In an embodiment, the request document signature API call706notifies the physician engagement layer120that a document (e.g., the document created with the API call704) is available for review and signature for a physician. In an embodiment, the request document signature API call706includes the document ID (e.g., the unique document ID) returned in response to the API call704. The physician engagement layer120can use the document ID to identify the document for signature by a physician.

FIGS.8A-Cfurther illustrate an electronic signature API for an automated medical resupply engine, according to one embodiment. Starting withFIG.8A, in an embodiment, the physician engagement layer120makes a provide document and information API call802to the engagement controller130. The provide document and information API call802provides a copy of the signed document (e.g., a PDF copy of the signed document) for the engagement controller130to store in an electronic repository, assuming the signature request (e.g., the request document signature API call706illustrated inFIG.7). In an embodiment, the provide document and information API call802further provides data elements describing the signed document. This allows the engagement controller130, the resupply engine140, or both, to identify the characteristics of the signed document without parsing a PDF document. The engagement controller130, the resupply engine140, or both, can use the provided data elements to complete the resupply, and can notify the patient that the resupply was successful.

In an embodiment, portions of a document signature can be approved while other portions are not approved. For example, a request document signature API call706, as illustrated inFIG.7, can include multiple elements requiring approval. The provide document and information API call802(or another suitable API call as illustrated inFIGS.8B-C) can indicate approval for some elements and no approval for other elements. The engagement controller130, the resupply engine140, or both, can then use that partial approval to complete the approved aspects of the resupply, and notify the patient of the status.

Turning toFIG.8B, in an embodiment the physician engagement layer120can further make an update document API call822to the engagement controller130. The update document API call822can update a document previously stored in a repository associated with the engagement controller130(e.g., stored using the API call802). For example, the update document API call822can notify the engagement controller that a document has been signed, or can update any other suitable aspect of the a document (e.g., a stored document).

Moving toFIG.8C, in an embodiment the physician engagement layer120can further make an update document signature request API call842to the engagement controller130. For example, the update document signature request API call842can be used to indicate that the physician engagement layer120has rejected a signature request, or a portion of a signature request. For example, a physician may reject a prescription request. The update document signature request API call842can be used to indicate this rejection, so that the engagement controller can notify the patient. As another example, an error may occur in the document signature request (e.g., the document cannot be found or cannot be created correctly, the physician cannot be found, the physician system does not support electronic signatures, or any other suitable error). The update document signature request API call842can be used to indicate the error.

In an embodiment, the update document signature request API call842can indicate a reason for the rejection or error. For example, the physician could indicate that the relevant patient is not in that physician's care, could indicate that the patient must be examined before the request can be approved, or can indicate any other suitable reason. In an embodiment, the engagement controller130can provide this information to a patient engagement layer (e.g., the patient engagement layer110illustrated inFIG.1), and the patient engagement layer can use the reason for failure to provide appropriate notification to the patient.

In an embodiment, the update document signature request API call842can indicate the error using a suitable code or pre-determined value. Alternatively, the update document signature request API call842can return a textual indication of the reason for failure (e.g., a textual explanation provided by the physician). In an embodiment, the engagement controller130can parse this textual indication to identify the cause of the failure. For example, the engagement controller130can use a suitable machine learning (ML) model to perform natural language processing (NLP) on the textual indication. The engagement controller130can use NLP to identify the meaning of the textual indication, and to provide appropriate engagement with the patient (e.g., a suitable indication of the reason for failure).

FIG.9illustrates requesting a care provider signature for an automated medical resupply engine, according to one embodiment. In an embodiment,FIG.9further illustrates the flow discussed above with regard toFIGS.7-8C. A resupply engine140transmits a document signature request902to an engagement controller130. In an embodiment the document signature request902corresponds to the document signature request602illustrated inFIG.6, and includes identifying information for the patient, the approving physician, and resupply event (e.g., the resupply request).

The engagement controller130transmits an API call904to a physician engagement layer120. For example, the API call904can correspond to the create electronic document API call704illustrated in relation toFIG.7. The engagement controller130can make a call to the API at https://server.api.com/path/api/resupply/documents with information for a customer (e.g., a healthcare entity facilitating resupply), a patient (e.g., the patient being resupplied), a document (e.g., the document being created), and a physician (e.g., the approving physician), requesting that the physician engagement layer120creates the document. As noted above, this is merely an example, and the engagement controller130, resupply engine140, or both, can create the document.

In an embodiment, the API call904further corresponds to the request document signature API call706illustrated inFIG.7. The API call904notifies the physician engagement layer120that the created document is available for review and signature for a physician. In an embodiment, the API call904includes the document ID (e.g., the unique document ID) returned in response to the API call704. The physician engagement layer120can use the document ID to identify the document for signature by a physician.

In an embodiment, the physician engagement layer120responds with a response906. The response906includes an identifier for the signature request (e.g., a unique identifier), and a system identifier. In an embodiment, the response906further includes a status.

FIG.10illustrates patient engagement for an automated medical resupply engine, according to one embodiment. In an embodiment, a patient engagement layer1010(e.g., the patient engagement layer110illustrated inFIG.1) relates to a patient1012. The patient1012makes a request1014to a patient device1016. In an embodiment, the patient device1016can be any suitable electronic or computing device, including a smartphone, a tablet, a laptop computer, a desktop computer, a wearable device, a medical device, an Internet of Things (IoT) device, or any other suitable device. In an embodiment, the request1014is a resupply request, and the patient device1016includes a suitable user interface reflecting the request. The patient1012can use the user interface to initiate the request1014, to cancel the request1014, to modify the request1014, to monitor the status of the request1014, or for any other suitable use.

In an embodiment, the patient device1016transmits a resupply order1018to a control layer1050(e.g., the control layer150illustrated inFIG.1). For example, the patient device1016can transmit a resupply order1018to an engagement controller1030(e.g., the engagement controller130illustrated inFIG.1). As discussed above in relation to block302illustrated inFIG.3, the engagement controller1030can receive this resupply order1018as a resupply event and can use the resupply order1018to trigger a resupply. The control layer1050is discussed further, below, with regard toFIG.11.

In an embodiment, the control layer150provides a status update1020to the patient engagement layer1010, which hits a notification endpoint1022. For example, the engagement controller1030, a resupply engine1040(e.g., the resupply engine140illustrated inFIG.1), or both, can provide the status update1020to the patient engagement layer1010. In an embodiment, the status update is1020is provided to the patient1012through the user interface of the patient device1016. For example, the patient device1016can provide a message (e.g., an SMS message, MMS message, or any other suitable electronic message) or indication reflecting the status. This is merely an example, and the status update1020can be provided to the patient1012in any suitable fashion (e.g., a voice message or telephone call, a message on another electronic device, or using any other suitable technique).

In an embodiment, the status update1020is merely one example of engagement from the control layer1050(e.g., from the engagement controller1030) to the patient engagement layer1010. For example, the engagement controller1030could also provide notification to the patient1012, using the patient engagement layer, to suggest that the patient initiate a resupply order. As another example, the engagement controller1030could also provide notification to the patient1012, using the patient engagement layer, when the patient may be at risk for prematurely discontinuing treatment, and a resupply could keep the patient engaged in treatment for longer.

In an embodiment, the engagement controller1030can initiate engagement with the patient engagement layer1010using a wide variety of patient data. This can include patient demographic data, patient contact information, patient payment details (e.g., credit card details), patient insurance details, social determinants of health (SDoH) data, medical device data, prior or pending resupply order data (e.g., for the subject patient, other patients, or both), and any other suitable data. In an embodiment, the engagement controller1030can use any aspect of this data to determine when to initiate patient engagement, and to assist in completing patient engagement (e.g., identifying how to contact the patient). In an embodiment, the engagement controller1030can determine whether the electronic healthcare system related to the patient engagement layer1010is compatible with the control layer1050(e.g., with the engagement controller1030, the resupply engine1040, or both). The engagement controller1030can decline to interact further with an incompatible patient engagement layer1010.

FIG.11further illustrates patient engagement for an automated medical resupply engine, according to one embodiment. In an embodiment,FIG.11corresponds withFIG.10and provides additional detail relating to the control layer1050. For example, as discussed above in relation toFIG.10, a resupply event can be initiated by a resupply order1018from a patient1012. Alternatively, a resupply engine1040, an ePrescription system1102, or both, can initiate a resupply event.

In an embodiment, the resupply engine1040can access referral data1142. The resupply engine1040can process the referral at block1112, and can use configuration data1114to generate a patient sales order1116. The ePrescription system1102can use referral data1104to process a referral at block1112. In an embodiment, processing the referral at block1112further serves to notify the resupply engine1040and provide a referral ID, and to generate a resupply event. For example, as discussed above in relation to block302illustrated inFIG.3, a resupply event can be generated by the resupply engine1040based on analyzing policy rules, reviewing prior resupply orders, or analyzing any other suitable information. The resupply engine1040can generate this resupply event at block1132. In an embodiment, the resupply event1132can be used to generate a resupply request1134, which can result in a success indication1136(assuming the resupply request1134is successful).

Additional Considerations