JP2022069566A - System and method for providing on-demand real-time patient-specific data analysis computing platform - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a computing platform configured to receive and process an on-demand real-time patient-specific data analysis order.

SOLUTION: A computing platform receives an order, determines feasibility of the order, and then performs desired analysis on the basis of parameters provided within the order. As part of the analysis, the computing platform can investigate one or more data sources to collect data relevant to ordered diagnostic. Once the data is collected, the computing platform can analyze the data according to one or more pre-programmed algorithms. Selection of the algorithm to be applied to a data set can be determined by a type of the ordered on-demand real-time patient-specific data analysis. In some examples, the on-demand real-time patient-specific data analysis can be ordered by using an external ordering user interface.

SELECTED DRAWING: Figure 4

COPYRIGHT: (C)2022,JPO&INPIT

Description

The present disclosure is generally a calculation that can perform on-demand analysis of the available medical and medical data of various sets within an electronic order entry platform and electronic medical recording system through an interface and provide the analysis results in real time through the same interface. Regarding the platform.

Providing high-quality medical services while keeping an eye on the costs associated with medical care has traditionally been the goal of healthcare providers and related businesses. Perform medical diagnosis or other tests to confirm patient-related information in a medical environment where patients visit multiple doctors and providers who can or cannot communicate with each other across a wide geographic area. That is, such tests and medical diagnoses may overlap among the various health care providers visited by the patient and may be performed without the benefit of obtaining information known to other health care providers. Therefore, it can be inefficient.

In addition, the medical scene is becoming more complex and is in conflict with the goal of low cost and high quality medical care. The number of pathologies known to clinicians continues to grow as scientific discoveries provide a deeper understanding of the etiology, genetics, and subdivision of symptoms that were previously poorly understood. Codes that reflect such symptoms in medical record documents are also defined, as illustrated in the transition from the ICD-9 (including approximately 14,000 diagnostic codes) standard to the ICD-10 (including approximately 68,000 diagnostic codes) standard. The details are increasing. The number and types of diagnoses available to clinicians are increasing, as are treatment methods.

In addition to the above-mentioned advances in fine-grainedness and complexity in core medical practices, the business processes, management and legal oversight of the medical perimeter are becoming more complex as well. As the healthcare industry moved from quantity-based to quality-based therapies, measuring quality results also dramatically increased its importance. The ability of a patient to assess the quality of treatment they have received in the past can be crucial not only in making optimal medical decisions, but also in driving cost reductions. However, the data needed to perform these assessments is often stored in miscellaneous places and entities that cannot communicate with each other. In addition, due to the sheer volume of information required for such assessments, the quality of treatment received by the patient and the treatment is the legal standard in "real time" (during the period of direct treatment) by the healthcare provider. It may not be possible to determine if it is in compliance.

No need for a computational platform that aggregates, investigates, and analyzes data from multiple sources to comprehensively and extensively "on-demand" (as needed and requested) comprehensively examine various aspects of a patient's medical history. Or it can help maximize the quality of care while minimizing the inefficient costs associated with duplicate medical tests and lab diagnoses. However, the above aggregations, surveys, and analyzes are often based on large amounts of data scattered across many different sources, making it impossible for healthcare providers to perform such analyzes.

The present disclosure relates to a computerized platform that performs analysis using medical data aggregated and investigated from various third party internal databases.

The platform analyzes the patient's medical data in real time, ordering the most relevant analytical tests from the patient and the healthcare provider on demand and receiving the answers during the actual treatment. Can support the provision of high quality and cost effective treatments.

The figure which shows the exemplary method of performing on-demand real-time patient-specific data analysis (sometimes referred to as "data diagnosis") by the example of this disclosure. FIG. 6 illustrates another exemplary method of performing on-demand real-time patient-specific data analysis according to the examples of the present disclosure. The figure which shows the exemplary method of performing the on-demand real-time patient-specific data analysis by the example of this disclosure. The figure which shows the exemplary computational platform which performs the on-demand real-time patient-specific data analysis by the example of this disclosure. The figure which shows the example message hub by the example of this disclosure. The figure which shows the example order processing architecture by the example of this disclosure. The figure which shows the example clinical analysis engine by the example of this disclosure. The figure which shows the example flowchart design process by the example of this disclosure. The figure which shows the example pdf generator architecture by the example of this disclosure. The figure which shows the example data integration service by the example of this disclosure.

The on-demand real-time patient-specific data analysis, in one case, can be a set of various patient-specific data analyzes that can be individually ordered by the clinician at the time of treatment. In some cases, ordering real-time patient-specific data analysis can search multiple databases to find relevant information for a particular patient, collect patient-related information, and be a doctor or healthcare provider. The process can be initiated, including analyzing the information collected, in search of specific features or patterns that can help provide a higher quality and cost effective patient experience.

An example scenario helps to illustrate the concept of performing real-time patient-specific data analysis. In this example scenario, the patient is taken to the emergency room and unable to provide information due to acute distress, trauma, or unconsciousness. Patients are usually unable to reliably answer medical history-related questions, so the clinician who provides treatment not only diagnoses the medical problem, but also other things that may affect the treatment process prescribed by the clinician. An extensive series of medical tests must be performed to ensure that no exacerbating factors are present. In addition, doctors cannot determine whether the abnormalities found are acute or chronic, or whether previous treatments have had adverse effects such as allergic reactions, which is an ongoing problem. It is difficult to determine the appropriate treatment associated with it. However, if clinicians can order on-demand real-time patient-specific data analysis for their patients, the computing platform will have multiple data sources (ie, databases of other clinicians, historical diagnostic data, drug records, lab records, electronic medicine). Investigate (recorded data, etc.) to collect information about the patient's past history and treatment, analyze the collected information, and cannot respond appropriately or reliably in the emergency room, respond poorly, or become aware of it. Factors or other relevant information that can help the healthcare provider in treating an unknown patient can be determined. In one case, on-demand real-time patient-specific data analysis provides information about the medication the patient has received or is currently receiving, all past lab work performed on the patient, past diagnosis, and past hospitalization history. You can search. All information retrieved by on-demand real-time patient-specific data analysis can be placed in a single database, or in some cases in a miscellaneous database maintained by a third-party healthcare provider. Can be done. The computing platform can examine each of these databases to see if the patient's relevant information for ordering on-demand real-time patient-specific data analysis is stored in a particular database.

Just as a clinician orders a lab test to determine the optimal treatment process for a patient, a clinician orders real-time patient-specific data analysis to investigate and analyze data about a specific patient. It is also possible to initiate a process that teaches the treatment process.

FIG. 1 illustrates an exemplary method of performing on-demand real-time patient-specific data analysis according to the examples of the present disclosure. As shown in FIG. 1, the clinician 102 can initiate an on-demand real-time patient-specific data analysis process using a lab diagnostic order input interface or other order input interface 114. The order entry interface 114 may be, in some examples, an existing computer interface used by lab service providers to order tests at laboratories or by clinicians to order prescription drugs directly from a particular pharmacy. Can be done. By leveraging the existing order entry interface, healthcare providers can have a common interface order both lab diagnostics and on-demand real-time patient-specific data analysis for specific patients being treated within existing workflows. .. In some examples, on-demand real-time patient-specific data analysis can be ordered using a separate interface dedicated to the interface with the on-demand real-time patient-specific data analysis computing platform (discussed later).

Once the clinician 102 initiates on-demand real-time patient-specific data analysis, the process can proceed to step 104 to locate the patient record. At step 104, the order entry system reliably orders tests (ie, on-demand real-time patient-specific data analysis or lab diagnostics) for names, birthdays, ages, and other intended subjects by the clinician or healthcare provider. Attempts can be made to retrieve patient records that contain identifying information that can be done.

Once the patient is identified in step 104, the process can proceed to step 106 where an order for the test can be initiated. In the example of on-demand real-time patient-specific data analysis, at step 108, the healthcare provider can select an on-demand real-time patient-specific data analysis test from the list of available tests.

Types of On-Demand Real-Time Patient-Specific Data Analysis The following description of on-demand real-time patient-specific data analysis is for illustrative purposes only and should be construed as a comprehensive list or limitation of the scope of the on-demand real-time patient-specific data analysis calculation platform. is not.

In one case, the clinician may want to ascertain the quality of treatment the patient has received. In addition, healthcare providers, NCQA / HEDIS®, Medicare Advantage, enable clinicians to assess the quality of treatment for patients, understand their status quo, and improve the quality of their treatment. Assess the quality of treatment based on national treatment criteria such as 5-star rating, URAC rating, state-specific criteria (eg NY QRR rating), private ACA QRS rating, PQRI rating, or other applicable rating. You may want to. In such an example, the healthcare provider orders quality-related on-demand real-time patient-specific data analysis to investigate and analyze data related to the patient's past medical history to determine the quality of treatment received by the patient. , The treatment steps to be taken to guide the patient within applicable treatment standards and can be evaluated.

In another example, a clinician who is hampered by not being able to recognize the broader medical history of a new patient, a patient with multiple illnesses, or a patient who is unable to provide detailed medical history needs more information about the patient's medical history. Or may ask. In the above scenario, the practitioner surveys electronic medical records of various medical organizations for information related to the patient's past clinical diagnosis, prescription drugs, lab results, surgical procedures, etc. Historical data-related on-demand real-time patient-specific data You will want to order the analysis.

In another example, the physician wants to ascertain the patient's medical history and progression, but often limits his or her expertise in recognizing the patient's illness or co-morbidity and the accuracy requirements for risk score coding. In the above scenario, the healthcare provider investigates and analyzes the data to perform a risk score-related data diagnosis that determines the burden and risk score of a specific patient's past, present, and future illness within a relevant risk score model. You can place an order.

In another example, the healthcare provider attempts to avoid duplication of tests, but is responsible for the results of similar tests performed or for patient costs regarding treatment considerations such as prescription compliance, appropriate diagnostic imaging guidelines, and specialist treatment. It is often not possible to recognize how often, how recently, or how the parameters dictated by the institution were obtained. In the above scenario, the healthcare provider can order on-demand real-time patient-specific data analysis related to waste avoidance. Waste Avoidance-related on-demand real-time patient-specific data analysis explores and analyzes patient-related data to find relevant information that identifies potentially unwanted uses and costs associated with patient care coverage guidelines. You can discover cheaper alternatives.

In another example of the type of on-demand real-time patient-specific data analysis, physicians may want to determine the various treatment management resources that a patient is eligible for. However, such tasks can often be difficult because the clinician is often unable to know the country, state, or medical association-specific program that the patient is eligible for. In the above scenario, the clinician can order an accuracy-related on-demand real-time patient-specific data analysis that aggregates, investigates, and analyzes data related to their eligibility for the program and the patient's program.

Returning to the example in Figure 1, once the clinician has selected the type of on-demand real-time patient-specific data analysis he wants to order for the patient, the process can proceed to step 110 to order the diagnosis from an external computing platform. The external computing platform can aggregate and investigate various data sources for relevant information on the ordered data diagnosis, perform analysis of the aggregated and investigated data, build a report of the results, and medicalize the results. Send to the provider. At step 112, the healthcare provider can view the results of the computational platform that received the analysis in real time.

The process of ordering at step 110 and seeing the results at step 112 can include ordering to a computational platform that performs the requested analysis. FIG. 2 shows another exemplary method of performing on-demand real-time patient-specific data analysis according to the examples of the present disclosure. Similar to the method shown in FIG. 1, clinician 202 can order on-demand real-time patient-specific data analysis in step 204. At step 206, the order can be received by the lab information system or other order entry platform. The information system or order entry platform looks at the placed order and determines whether the order is for traditional lab diagnostics, prescription drugs, or other traditional orders, or for on-demand real-time patient-specific data analysis. It can be determined. If the order is determined to be for on-demand real-time patient-specific data analysis, the process proceeds to step 208 and the order is sent to the on-demand real-time patient-specific data analysis service provider (detailed below). At step 210, the on-demand real-time patient-specific data analysis service provider uses a web service to parse the request, aggregate, investigate, and analyze the desired data, and generate the results / reports of the on-demand real-time patient-specific data analysis. can do. At step 212, the result is received and returned to the requesting service provider.

FIG. 3 shows an exemplary function of an on-demand real-time patient-specific data analysis web service according to an example of the present disclosure. The clinician 302 can place an on-demand real-time patient-specific data analysis order in step 304 as described above with reference to FIGS. 1 and 2. On-demand real-time patient-specific data analysis orders can be received on the order entry platform 306. As mentioned above, on-demand real-time patient-specific data analysis can be ordered using the same computing platforms, pharmacies, or other electronic or order entry platforms used by lab service providers. As an example, a healthcare provider using a commercial lab service provider can also order on-demand real-time patient-specific data analysis by adopting the electronic user interface used to order lab services. In another example, a healthcare provider utilizing an electronic medical record system that supports order entry can also employ an electronic user interface to place an order for data diagnostics as well.

As part of the ordering process for on-demand real-time patient-specific data analysis, healthcare providers can include inclusion criteria as part of their order. Inclusion criteria can include the type of analysis or dataset that you want to include in the real-time patient-specific data analysis. As an example, if a physician wants to order quality-related on-demand real-time patient-specific data analysis, the practitioner may want to include specific treatment criteria, such as the Medicare Advantage 5-star rating, for a variety of reasons. .. In this case, the practitioner can employ a user interface that states that Medicare standards should be included in the on-demand real-time patient-specific data analysis.

Also, as part of the ordering process for on-demand real-time patient-specific data analysis, healthcare providers can include exclusion criteria as part of their ordering. Exclusion criteria can include the type of analysis or dataset that you want to exclude from the on-demand real-time patient-specific data analysis. Health care providers can order a general analysis of all available quality assessments, and providers can provide exclusion criteria to select specific programs (such as NCQA or HEDIS) that include a subset of assessments. Yes, or the provider can choose an individual rating.

When ordering a specific on-demand real-time patient-specific data analysis, the practitioner is presented with a hierarchical selection menu, and each layer of the hierarchy depends on the choices the practitioner made with respect to the previous layer. In one example, if the practitioner decides that he wants to perform only the Medicade analysis, he can specify the type of program (ie, adult program, children's program), as well as states such as New York, Florida, and California. In this way, the hierarchical menu can be sent to an on-demand real-time patient-specific data analysis web service to generate a set of inclusion and exclusion criteria to be used by the web service to perform the desired analysis.

In some examples, inclusion and exclusion criteria can be generated by computing platforms / web services. For example, a clinician can order a quality-related diagnosis. Based on the information relevant to a particular patient, the computational platform can generate inclusion and exclusion criteria. For example, if the computational platform also recognizes a particular patient as a Medicare and Medicade patient in New York, the platform is clearly evaluated for dual qualified patients instead of letting the clinician make a decision. Can identify quality criteria. In another example, the clinician is unaware of the different clinical quality standards applicable to the patient. Thus, when a clinician orders a high level of hierarchical on-demand real-time patient-specific data analysis, the computational platform recognizes the applicability of each patient to the relevant quality criteria and applies the appropriate analysis.

In another example, on-demand real-time patient-specific data analysis can be ordered using a standalone user interface that is directly linked to the on-demand real-time patient-specific data analysis calculation platform / web service. In the example of FIG. 3, where the lab service provider user interface is adopted, the order entry platform 306 can receive an on-demand real-time patient-specific data analysis order in step 308. At step 310, the on-demand real-time patient-specific data analysis order can be sent to the on-demand real-time patient-specific data analysis calculation platform / web service prior to processing.

The on-demand real-time patient-specific data analysis calculation platform 316 can receive orders in step 324. Orders generated by healthcare providers include names and other identification information (birthday, social security) to ensure that the computing platform can perform the analysis on patients for whom the healthcare provider has ordered on-demand real-time patient-specific data analysis. It can contain information about the patient being treated, such as numbers, insurance information, etc.). At step 326, a preliminary check is performed and the patient's insurer or other relevant entity, such as an accounting-responsible medical institution, hospital, or risk-sharing institution, is on-demand real-time patient-specific ordered by the healthcare provider. Authorize data analysis and ensure that it covers its costs. If the insurer or other affiliate is determined not to approve the on-demand real-time patient-specific data analysis, the process can proceed to step 322, where the message "untested" can be generated. At step 320, the "uninspected" message can be tuned to the ordering system ordering message format (discussed in detail later) and sent to the ordering system at step 312. Finally, in step 314, an answer can be returned to the healthcare provider indicating that the on-demand real-time patient-specific data analysis was not performed without authorization by the insurance company or other affiliate.

However, if the insurer or other affiliate authorizes on-demand real-time patient-specific data analysis, the process proceeds to step 328 and the computing platform resides within the on-demand real-time patient-specific data analysis web service system for the patient. You can check if there is enough data history to perform the analysis. Such an analysis can be performed by a qualified algorithm. The eligibility algorithm can determine if the system is confident enough to determine the patient's ID and if it is confident that it has enough data to perform the analysis. ..

If the eligibility algorithm determines that the patient is present in the system and has sufficient data history to perform on-demand real-time patient-specific data analysis, the process is performed at steps 330, 332, 338. You can proceed. At step 330, the internal database (or other data storage medium) can be investigated to extract information related to the ordered on-demand real-time patient-specific data analysis.

The internal database can be a database stored locally within the computing platform. Databases are provided by various affiliates and can consist of information that is unidentified and matched over time. As an example, if an insurance company such as Blue Cross Blue Shield (BCBS)® belongs to an on-demand real-time patient-specific data analysis service for patients, BCBS will provide the computing platform with all the data it has about the patient. be able to. The data can be absorbed and stored in a database maintained by the computing platform itself. The dataset can be set up and maintained through a batch or transitional data delivery process.

Thus, when a physician places an order for on-demand real-time patient-specific data analysis, the order is interpreted on behalf of the patient's treatment and for the patient's treatment, and an internal database is investigated and analyzed to identify relevant information for a particular patient. And can be extracted. In doing so, the non-identifying data stored in the internal database can be extracted and re-identified as data belonging to the patient ordering the on-demand real-time patient-specific data analysis.

The internal database can contain multiple datasets, each dataset corresponding to the data provided by a particular organization. In one example, one dataset may belong to a BCBS patient and another dataset may belong to a lab service provider. Thus, when a patient's clinician requests on-demand real-time patient-specific data analysis, the computational platform extracts data from the relevant data set stored in the internal database, depending on the patient's identity and other inclusion and exclusion criteria. The data can be re-identified and, if necessary, the data matched over time based on the patient's ID and combined in one position for analysis. Once the data has been parsed, the data that has been aggregated so that it cannot be identified can be deleted (the first dataset remains intact).

At steps 332 and 338, the computing platform can also inspect data from various external databases provided by third parties. As an example, data stored in an internal database can be retained and stored in a third party database rather than being provided to a computing platform by a healthcare provider or medical organization. Computational platforms can access those databases to investigate patient-related data that requires on-demand real-time patient-specific data analysis, as well as on-demand real-time patient-specific data analysis itself.

Once the data is examined from various databases, at step 334 the computational platform can determine the appropriate analysis process to be adopted and produce the desired result of clinician 302. The creation of algorithms that determine not only which analysis measurements should be adopted, but also how those analyzes should be performed, is further detailed below. At step 336, the computational platform 316 can perform real-time analysis of the data investigated from various data sources using the analytical measurements determined in step 334.

Once the analysis is performed in step 336, the answer package can be created in step 318. The formation of the answer package will be described in more detail later. At step 320, the response package can be sent back to the order entry platform 306 at step 320. The order entry platform 306 can receive the response in step 312 and ship the response package to the healthcare provider in step 314.

FIG. 4 shows an exemplary computational system that performs on-demand real-time patient-specific data analysis according to the examples of the present disclosure. The calculation system of FIG. 4 can include two main components: an external interface unit 402 and an on-demand real-time patient-specific data analysis calculation platform unit 404. The external interface unit 402 of the calculation system 400 can include the components of the calculation system outside the web service as described above. For example, the external interface unit 402 of the computing system 400 can include a clinician 406. FIG. 4 can outline an example of a real-time patient-specific data analysis and calculation platform according to the example of the present disclosure.

As mentioned above, the requester (ie, user) of the on-demand real-time patient-specific data analysis can include a healthcare provider who wishes to order the on-demand real-time patient-specific data analysis of the patient being treated. Clinician 406 can utilize various types of interfaces to order such a diagnosis. In the example of FIG. 4, two interface examples are shown. Requesters for on-demand real-time patient-specific data analysis can utilize the ordering interface 408, which can be the user interface for the lab ordering system or prescription drug ordering system as described above. Lab services such as blood work can be ordered using the ordering interface 408, and on-demand real-time patient-specific data analysis services can be ordered, transmitted, and distributed using the same ordering interface 408 (as described above). You can also.

Clinician 406 can also utilize an electronic medical record interface or other order entry platform 410 to order on-demand real-time patient-specific data analysis. An electronic medical record (EHR) is an electronic version of a patient's medical history maintained by a healthcare provider. In some examples, a healthcare provider can use an EHR to investigate a patient's medical history and order lab work performed on the patient within the same interface. Using this interface 410, clinician 406 can request on-demand real-time patient-specific data analysis in much the same way as laboratory diagnostics or prescription drugs. Similarly, other order entry platforms can be applied to ordering data diagnostics. For example, a medication ordering platform, a radiological examination order entry, other order entry systems, or a platform dedicated to data diagnostic orders.

Once the clinician 406 requests on-demand real-time patient-specific data analysis using interface 408 or 410, the order can be sent to the ordering system 412. As mentioned above, the ordering system 412 is an internal processing and communication system for satisfying orders from external user interfaces as exemplified by 408 and 410. The ordering system can process the order using its own internal process and send an on-demand real-time patient-specific data analysis request to the calculation platform 404 for processing. In this way, the ordering system can be used as a distributor of the on-demand real-time patient-specific data analysis service, while the on-demand real-time patient-specific data analysis calculation platform 404 is the actual on-demand real-time patient-specific data analysis service distributed to the patient. Can be provided.

The computing platform 404 can include a message hub 414. The message hub 414 can serve as an interface between the computing platform 404 and the outside world, such as the ordering system 412. The message hub 414 can add communication capabilities to the computing platform 404 to accept orders and provide stakeholders with reports with the results of on-demand real-time patient-specific data analysis.

FIG. 5 shows an exemplary message hub according to an example of the present disclosure. For illustration purposes, the interface between the message hub 504 and the lab data exchange 402 is also shown. As mentioned above with reference to FIG. 4, the ordering system 412 can serve as an interface between the clinician 406 ordering on-demand real-time patient-specific data analysis and the computational platform 404. Returning to the example of FIG. 5, the ordering system 412 may include a platform data exchange 512. The platform data exchange 512 can provide a web / network interface between the ordering system 412 and the computing platform 404.

Platform data exchange 512 may include web service 514. The web service 514 can initiate and execute communication between the platform data exchange 512 and the on-demand real-time patient-specific data analysis and calculation platform via the web service 504 located within the message hub. In one example, the web service 514 can exchange secure socket layer (SSL) authentication 516 with the web service 504 located within the message hub center from the platform data exchange.

To establish the identity of the on-demand real-time patient-specific data analysis platform to the platform data exchange, SSL authentication can be passed from the message hub of the on-demand real-time patient-specific data analysis calculation platform to the platform data exchange. SSL certification 516 can also be used to open and establish a secure communication socket between the platform data exchange and the message hub center.

Once the order for on-demand real-time patient-specific data analysis is received by the message hub center, it can be sent to the input processor 506. The input processor 506 receives the order and can convert the order into a format readable by a component that performs the actual processing of on-demand real-time patient-specific data analysis. In one example, the computing platform can employ a Health Level 7 (HL7) protocol known to those of skill in the art. The input processor 506 can enter an order for on-demand real-time patient-specific data analysis and convert it to HL7 format for use by the on-demand real-time patient-specific data analysis calculation platform.

Once the received order has been converted to the appropriate format, it can be sent to order processing step 508, which will be described in detail later. The order message can also be sent to a log file database 510 that can store the order received by the system. The log file database 510 can be accessed by the arithmetic intelligence software 520. Computational intelligence software 520 can execute various queries on the log file database 510 to perform various analyzes on the orders received by the computing platform. The types of analysis are, for example, analysis of the type of order received, analysis of an organization or individual ordering on-demand real-time patient-specific data analysis, and when considering orders received by the on-demand real-time patient-specific data analysis calculation platform. Can contain other information that can be collected in.

At step 524, the processed order can be returned to the message hub 500. In some examples, the processed order can be returned in raw (unedited) format, or in some examples it can be sent simultaneously as a pdf file with a report of the results. The order can be received by an output processor 522 capable of converting the raw result data into an HL7 observation result message (ORU) or a pdf file, in another example simply with the pdf received from the order processing step 524. Can be sent to.

In some examples, the output processor can send results in multiple file formats, allowing consumers and / or user-adopted user interfaces for on-demand real-time patient-specific data analysis to choose the desired output format. .. The output file format can be replied to the user via the web service 504 of the message and the result package can be relayed to the web service 514 of the platform data exchange 512.

Returning to FIG. 4, once the order is received and processed by the message hub as described above, the order can be sent to the on-demand real-time patient-specific data analysis order processing system 416. The role of the on-demand real-time patient-specific data analysis order processing system 416 is to coordinate the techniques required to refine the on-demand real-time patient-specific data analysis order.

FIG. 6 shows an exemplary order processing architecture according to the examples of the present disclosure. As mentioned above, the message hub 500 can send the ordering parameters to the ordering processing component 600. The transmission of parameters can be simplified by a web service 602 located within the order processing component 600. The web service 602 can simplify communication with the order processing component 600 in much the same manner as the web service described in connection with the message hub of FIG.

At step 604, the order processing component can initiate a patient search as described above for step 328 in FIG. As part of the patient search, the patient's parameters (ie, name, birthday, or other identifying information) can be queried to the data lake 606. The data lake 606 can represent one or more databases containing patient-related information as described above with reference to FIGS. 1-3. At step 604, the data lake 606 can be queried with the patient's parameters and the data lake can return the location and identifier of the data associated with the patient.

If the order processing component can extract the location and identifier of the data from the data lake based on the patient's parameters, then the patient can be determined to be in the system. However, if the system is unable to extract the location or identifier of the data from the data lake 606, the system can return an error message according to step 322 described with reference to FIG.

As part of the ordering process, the system can check if there is sufficient data to perform on-demand real-time patient-specific data analysis. At step 612, the ordering processing component initiates a search for the data lake 606 using the patient's parameters to determine if there is sufficient data for the patient and convey it to the on-demand real-time patient-specific data analysis. This process is described above with respect to step 328 of FIG. If it is determined that there is insufficient data, the system can return an error message according to step 322 described above with reference to FIG. The data lake can return a Boolean flag (set to 1 or 0) to indicate if there is enough data. The data lake can also return a detail flag (set to one of many indicators) to indicate that the data is inadequate in such cases.

At step 608, the check of affiliates can be initiated as described with reference to step 326 of FIG. You can submit the patient's health insurance parameters to contact the organization map 610. The organization map 610 can be a list of organizations that authorize on-demand real-time patient-specific data analysis. If the patient's medical organization belongs and authorizes on-demand real-time patient-specific data analysis, it can return a Boolean flag indicating that the diagnosis is authoritative. In such cases, a detail flag (set to one of many indicators) indicating approved or unapproved can also be returned. If the diagnosis is not approved, an error message can be sent as described in step 322 of FIG.

If at step 614 all the checks initiated in steps 604, 608, 612 show affirmative results, the process can proceed to a process analysis step that can request analysis results from the clinical analysis engine 616 (discussed further below). At step 614, the ordering parameters are sent to the clinical analysis engine 616 to perform the requested analysis and return the results. The clinical analysis engine will be further described later.

In step 618, once the clinical analysis engine 616 produces the results, the results can be sent to the report generator 620 for conversion to the desired format used by the user. The report generator will be further described later.

Therefore, as described above, the order processing component 600 processes the on-demand real-time patient-specific data analysis order and returns the result to the user, such as data lake 606, affiliate map 610, clinical analysis engine 616, and report generator. Individual components such as 620 can be adjusted.

Returning to FIG. 4, as described above, the on-demand real-time patient-specific data analysis order processing unit 416 can be connected to the clinical analysis engine 418. The clinical analysis engine 418 provides an analysis calculation runtime environment that executes pre-programmed analysis algorithms or data analysis schemes for data storage assets accessible from calculation platforms such as databases stored in the data lake 422. Can be done.

FIG. 7 shows an exemplary clinical analysis engine according to the examples of the present disclosure. The clinical analysis engine can include a configuration management module 704, an analysis service 706, and a computational cluster 708. The configuration management module 704 can play a role in establishing and maintaining consistency between the algorithm generated by the flowchart designer 702 (discussed later) and the data analysis scheme.

The analysis service 706 can perform on-demand real-time patient-specific data analysis by processing the order received from the order processing module 710. The analysis service 706 analyzes the request received from the order processing module 710 and the appropriate data from the data lake 712 is the appropriate algorithm or algorithm to ensure that the on-demand real-time patient-specific data analysis is performed according to the user's specifications. This task can be performed by ensuring that it is analyzed using an algorithm set.

As mentioned above, an on-demand real-time patient-specific data analysis order can initiate one or more data analysis schemes or algorithms performed on a set of data. Algorithms or data analysis schemes can be created by Flowchart Designer 702. The Flowchart Designer 702 can be a platform that allows the programmer to pre-program one or more algorithms and specify how the algorithms analyze the data associated with a particular on-demand real-time patient-specific data analysis. do. In one example, the flowchart designer 702 can serve as a common translator that translates logical considerations into the algorithmic process applied to the data. As mentioned above, each data analysis scheme or algorithm can include a set of inclusion and exclusion criteria. Exclusion and inclusion criteria can be specified by the user and specified by the type of on-demand real-time patient-specific data analysis ordered by the user.

Flowchart designers allow programmers to enter search inclusion and exclusion criteria using easy-to-use syntax, which is then applied to a set of data to perform on-demand real-time patient-specific data analysis. Can be translated / compiled into an algorithmic process that can be done. Upon receiving an order, the analysis service 706 can determine which algorithm or set of algorithms applies to a set of data.

The analysis service 706 can also retrieve and extract patient data from the data lake 712. As mentioned above, the order includes identification information about the patient who ordered the on-demand real-time patient-specific data analysis. Using such information and the inclusion and exclusion criteria provided by the algorithm, the analysis service 706 can extract patient data from the data lake 712. The data lake 712 can include internal and external databases, or other data services as described above.

The analysis service can extract the desired data from the data lake 712 and then execute an algorithm or algorithm determined to be involved in fulfilling the on-demand real-time patient-specific data analysis request. The analysis service 706 can utilize the computational cluster 708 to provide the processing power and speed required to efficiently execute large numbers of algorithms on large data sets. Computational cluster 708 can include one or more servers that provide the processing power needed to execute one or more algorithms. In this way, the analysis service 706 can customize the number of servers used to process data based on the processing needs required for specific data analysis and the user information to be analyzed.

Returning to FIG. 4, the clinical analysis engine 418 can receive orders from the on-demand real-time patient-specific data analysis order processing module 416. The received order can determine which data is investigated and extracted from the data 422 and which algorithm is designed by the flowchart designer 424 used to analyze the extracted data. The Flowchart Designer 424 can serve as an interface between a programmer who wants to create a data analysis scheme and an algorithm initiated upon receipt of a specific on-demand real-time patient-specific data analysis order.

FIG. 8 shows an exemplary flowchart design process according to an example of the present disclosure. The design process shown in Figure 8 creates a pre-programmed algorithm or data analysis scheme that the data analysis and computation platform programmer can perform when a specific on-demand real-time patient-specific data analysis is ordered as described above. Here's how to do it.

User 802 can access the Flowchart Designer Toolset via the Flowchart Designer User Interface 804. The Flowchart Designer Toolset provides a set of easy-to-use tools for designing, developing, and deploying a wide range of medical data analysis algorithm sets suitable for various on-demand real-time patient-specific data analysis, as in the example above. can do. The user interface 804 can be configured to allow users of the toolset to achieve excellent analytical functions without advanced programming experience or training. In other words, the user interface 804 provides a platform that allows the user to provide parsing functionality in an easy-to-use syntax that can then be translated into an esoteric description of the algorithm used by the computing platform for processing. be able to.

The user interface 804 can provide the user with an access function to the flowchart configuration repository 806. The Flowchart Configuration Repository 806 can include several pre-programmed algorithm modules. User 802 not only further prescribes inclusion and exclusion criteria, but also prescribes pre-programmed inclusion and inclusion criteria stored in Repository 806 by defining exclusion and inclusion criteria that can be specified by the user of the on-demand real-time patient-specific data analysis and computation platform. The algorithm module can be customized.

Once the user / programmer 802 creates the algorithm or data analysis scheme, the process proceeds to the configuration management system 808, where the published algorithm stores the various configurations of the algorithm and is within the on-demand real-time patient-specific data analysis and calculation platform. Can be used and deployed in.

Returning to FIG. 4, once the clinical analysis engine performs on-demand real-time patient-specific data analysis, the results of on-demand real-time patient-specific data analysis can be sent to the on-demand real-time patient-specific data analysis order processing module 416. .. The on-demand real-time patient-specific data analysis order processing module 416 can receive the received results and generate a report that is finally available to the user of the on-demand real-time patient-specific data analysis calculation platform 404. In one example, the on-demand real-time patient-specific data analysis order processing module 416 can format the received results according to a pre-defined confirmed template for a specific type of on-demand real-time patient-specific data analysis. You can access the report generation module 426.

FIG. 9 shows an exemplary report generator architecture according to the examples of the present disclosure. As described above with reference to FIG. 4, once the processed on-demand real-time patient-specific data analysis results are received by the order processing module 902, the order processing module may send the results to the report generator module 900. can. The report generator module 900 receives the order result and in module 904 the order result can be applied to a pdf design template or other output format. Module 904 can analyze the results to determine what kind of on-demand real-time patient-specific data analysis is relevant to the results. Based on the determined type, the report generator 900 can access the template repository 906 to generate the final report in various formats.

Template repository 906, in one example, can store multiple report templates, and each report template in the repository can be run by an on-demand real-time patient-specific data analysis and calculation platform for one or more on-demand real-time patients. Related to unique data analysis. Once the type of on-demand real-time patient-specific data analysis performed by the calculation platform and reflected in the results is determined, the order processing module 904 accesses the template repository, extracts the appropriate report template, and receives the results. Can be used to generate a report.

Once the report generator 900 has generated a report, it can be sent back to the order processing module 902 and finally sent to the user of the on-demand real-time patient-specific data analysis and calculation platform. In one example, the report generator component 900 can also send the generated report to the Arithmetic Intelligence Module 908. The Arithmetic Intelligence module can store all the various reports generated and perform report-based analysis to recognize different trends in the data, as described in Module 520 described with reference to FIG. ..

Returning to FIG. 4, in some examples, the compute platform 404 can also include a data integration service module 428. The data integration service module 428 can serve to populate the data in the data lake 422 by processing, modifying and validating the data received from external organizations such as healthcare providers to which it belongs.

FIG. 10 shows an exemplary data integration service according to the example of the present disclosure. The primary role of the data integration service 1000 is to bring data from external organizations into the computing platform. Once the data is captured, the data integration service 1000 can validate, modify, and organize the data so that it is used by a computing platform that performs real-time patient-specific data analysis as described above.

As an example, although it should never be construed as limiting, affiliated organizations 1002 and lab services 1004 are examples of external organizations that can supply data to computational platforms, more specifically the data integration service 1000. Play the role of. Both Lab Service 1004 and Affiliation 1002 can include patient medical data, including, but not limited to, information about the patient's past treatment and other patient-related health-related information.

In one example, as shown in FIG. 10, the data integration service 1000 can take in data from the lab service 1004 and the affiliated organization 1002 via three different input paths. The first route of incorporating data into the data integration service 1000 allows the user to manually upload the data to the web service using the user interface (UI) 1006. The user can manually upload the file to the data integration service 1000 by selecting the file that he wants to send to the computing platform via UI1006.

Instead of, or in addition to, the example above, the data integration service 1000 may use a real-time web-based message service utilizing Message Hub 1008 to receive messages and receive data from external organizations. can. The message hub 1008 can provide a real-time connection between a data provider such as the organization 1002 and the data integration service 1000. Therefore, when the organization 1002 has new data that it wants to send to the real-time patient-specific data analysis calculation platform, instead of waiting for this data to be combined with other data sent to the calculation platform and uploading it as a batch. , The data provider can send each data item individually in real time.

In another example, the data provider and lab service 1004 can use a file transfer protocol (FTP) connection to upload data to the data integration service 1000. The landing zone 1010 can serve as a file storage medium for receiving data via an FTP connection. The file watcher 1012 can monitor the landing zone 1010, upload data from the landing zone to the data management workflow 1014, and initiate the workflow required to capture the data upon receipt (discussed below).

The data management workflow module 1014 can perform various organizational tasks related to the absorption of data received from external organizations such as data providers 1002 and lab services 1004. As an example, the data management workflow manages patient IDs associated with managed internalized data, organizes data into a standardized format that can simplify efficient recall of information, and organizes and standardizes data, data quality. Can include checks.

The data management workflow 1014 can finally organize the data received from the external organization into various data storage media included in the data integration service 1000. The raw data, that is, the shape data when received, can be stored in the raw data storage device 1016. As mentioned above, the received data can be standardized and once standardized, the data can be stored in the standardized data storage file system 1018. Standardization refers to ensuring that internalized data is represented in a shape recognized by the computational platform. As an example of the standardization process, the computing platform requires gender to be represented as male, female, etc., but if an external organization represents gender as M, F, O, the standardization process represents M, F, O as male, Includes translating into women and others.

The data management workflow module 1014 can also initiate a master data management module 1020 that executes one or more algorithms on the data to "master" the data. Data mastering refers to the process by which data belonging to a particular individual can be attributed to that individual in various ways. As an example, mastering data can include recognizing that the data attributed to Edward Smith and Ed Smith belong to the same individual. In the absence of a mastering process, the system may consider Edward Smith and Ed Smith as two separate individuals, leading to misidentification of data during real-time patient-specific data analysis.

As part of the mastering process, the master data management process 1020 provides the data storage device 1022 with a set of mastering IDs and a map mapping multiple methods for identifying an individual in the light of this particular individual's ID. Can be remembered. During real-time patient-specific data analysis, the algorithm can provide a roadmap for the data to access when accessing the mastered ID and map storage device 1022 to perform real-time patient-specific data analysis for a particular individual.

Once the data is mastered, it can be stored in various file storage devices in a way that optimizes the ability of the computing platform to perform data analysis based on the data. As an example, the patient profile data storage device 1024 can store the profile of each patient as part of the system. The computing platform utilizes patient profile data storage device 1024 to determine if a particular patient is present in the system and, in some cases, sufficient specific patient to perform real-time patient-specific data analysis. You can also check if there is data about.

Database 1026 can represent a primary database that stores all patient data. The data that populates database 1026 can be matched to a format that optimizes various data analyzes performed by the computing platform. For security purposes, the data in database 1026 can be de-identified (as described above) and re-identified only if the user of the computing platform has passed various security and authentication procedures.

In another example, the data integration service can also maintain the lab service result data storage device 1028. The lab service result data storage device can contain data received from various lab service providers, which is formatted to match the format in which the computing platform operates to perform real-time patient-specific data analysis.

Although the present disclosure and examples have been described with reference to the accompanying drawings, it should be noted that various changes and modifications are obvious to those of skill in the art. It should be understood that such changes and variations are within the scope of the present disclosure and examples as defined by the claims.

Appendix 1. A method performed by a computer
The message hub of the data analysis system receives a request for analysis of real-time user-specific data of a specific user, and the data analysis system is different from (i) message hub, (ii) order processing component, (iii). Includes user profile, (iv) data lake, (iv) analysis engine, (v) result generator,
The order processing component of the data analysis system determines that a particular user profile associated with a particular user indicates that the real-time user-specific data stored in the data lake is sufficient to perform the requested analysis. That and
In response to the determination that a particular user profile associated with a particular user indicates that the real-time user-specific data stored in the data lake is sufficient to perform the requested analysis, the data analysis system Acquiring real-time user-specific data stored in a real-time data lake by the order processing component, and transactional data retrieval technology that obtains data clauses in real time other than batch processing.
Reidentifying the non-identified data stored in the database as data belonging to a specific user who requested the analysis of real-time user-specific data, and collating the re-identified data based on the specific user's ID.
Performing the requested analysis based on the real-time user-specific data of a specific user obtained by the analysis engine of the data analysis system.
The result generator of the data analysis system generates the result of performing the requested analysis based on the obtained real-time user-specific data of a specific user.
A method in which the message hub of a data analysis system provides the output as the result of performing the requested analysis.

Appendix 2. The method of Appendix 1, wherein retrieving user-specific data stored in a data lake comprises searching a plurality of individual databases to retrieve data clauses associated with a particular user.

Appendix 3. The method of Annex 1, wherein the requested analysis comprises a quality of treatment analysis in which the user has access to the quality of treatment received by the provider.
Appendix 4. The method of Annex 1, wherein the requested analysis comprises an analysis that accesses a possible present or future existence, or expected and imposed guesses, conditions.

Appendix 5. The method of Appendix 1, wherein the requested analysis comprises a waste assessment avoidance system that accesses the use of potentially unnecessary tests.
Appendix 6. The method of Appendix 1, wherein the requested analysis comprises an eligibility analysis that accesses the user eligibility of various programs.

Appendix 7. The method of Annex 1, wherein the requested analysis comprises a risk analysis to access a treatment or cost burden category for a treatment model or payment model.
Appendix 8. The method of Appendix 1, wherein the request is input by a past order entry user interface associated with a service provider.

Appendix 9. The method of Annex 1, wherein the requirement comprises inclusion criteria that identify the unique dataset stored in the data lake to be included in the analysis.
Appendix 10. The method of Annex 1, wherein the requirement comprises exclusion criteria that identify a unique dataset stored in the data lake to be excluded from the analysis.

Appendix 11. The method according to Appendix 1, wherein the acquisition of user-specific data stored in the data lake comprises the acquisition of one or more data clauses, which is the first database of the data analysis system, when requested.

Appendix 12. The method of Appendix 1, wherein the acquisition of user-specific data stored in a data lake comprises the acquisition of one or more data clauses stored in an external data source when requested.

Appendix 13. The data analysis system is the method according to Appendix 1, which is shown in the web service.
Appendix 14. The method of Appendix 1, wherein after receiving the request, the message hub sends secure socket layer (SSL) authentication to the order processing component.

Appendix 15. Using the organization map before determining that a particular user profile associated with a particular user indicates that the real-time user-specific data stored in the data lake is sufficient to perform the requested analysis. , The method according to Appendix 1, which determines that the user is associated with the affiliated organization that authenticates the requested analysis.

Appendix 16. There is sufficient data to determine that a particular user profile associated with a particular user indicates that the real-time user-specific data stored in the data lake is sufficient to perform the requested analysis. The method of Appendix 1, comprising receiving data comprising a Boolean flag indicating that.

Appendix 17. Re-identifying non-identifying data comprises combining the re-identified data in one position for analysis.
The method according to Appendix 1, wherein the re-identified data is deleted so that the re-identified data is not identified after analysis.

Appendix 18. It is a data analysis system
When run by one or more computers, it includes one or more computers and one or more storage devices capable of operating one or more computers to do the following:
The message hub of the data analysis system receives requests to analyze real-time user-specific data for a particular user, and
The order processing component of the data analysis system determines that a particular user profile associated with a particular user indicates that the real-time user-specific data stored in the data lake is sufficient to perform the requested analysis. That and
In response to the determination that a particular user profile associated with a particular user indicates that the real-time user-specific data stored in the data lake is sufficient to perform the requested analysis, the data analysis system Acquiring real-time user-specific data stored in a real-time data lake by the order processing component, and transactional data retrieval technology that obtains data clauses in real time other than batch processing.
Reidentifying the non-identified data stored in the database as data belonging to a specific user who requested the analysis of real-time user-specific data, and collating the re-identified data based on the specific user's ID.
Performing the requested analysis based on the real-time user-specific data of a specific user obtained by the analysis engine of the data analysis system.
The result generator of the data analysis system generates the result of performing the requested analysis based on the obtained real-time user-specific data of a specific user.
A method in which the message hub of a data analysis system provides the output as the result of performing the requested analysis.

Appendix 19. The system of Appendix 18, wherein retrieving user-specific data stored in a data lake comprises searching multiple individual databases to retrieve data clauses associated with a particular user.

Appendix 20. A non-temporary computer-readable storage medium that includes instructions performed by one or more computers and causes one or more computers to perform the following:
The message hub of the data analysis system receives a request for analysis of real-time user-specific data of a specific user, and the data analysis system is different from (i) message hub, (ii) order processing component, (iii). Includes user profile, (iv) data lake, (iv) analysis engine, (v) result generator,
The order processing component of the data analysis system determines that a particular user profile associated with a particular user indicates that the real-time user-specific data stored in the data lake is sufficient to perform the requested analysis. That and
In response to the determination that a particular user profile associated with a particular user indicates that the real-time user-specific data stored in the data lake is sufficient to perform the requested analysis, the data analysis system Acquiring real-time user-specific data stored in a real-time data lake by the order processing component, and transactional data retrieval technology that obtains data clauses in real time other than batch processing.
Reidentifying the non-identified data stored in the database as data belonging to a specific user who requested the analysis of real-time user-specific data, and collating the re-identified data based on the specific user's ID.
Performing the requested analysis based on the real-time user-specific data of a specific user obtained by the analysis engine of the data analysis system.
The result generator of the data analysis system generates the result of performing the requested analysis based on the obtained real-time user-specific data of a specific user.
A method in which the message hub of a data analysis system provides the output as the result of performing the requested analysis.

Claims (1)

The method described in the specification.

Images