This specification relates generally to systems and processes for building and executing a medical algorithm.
An example test instrument is configured to generate parameters based on assays performed on a test sample. For example, a viscoelastic test instrument may be configured to receive a test sample, such as whole blood or a component or derivative thereof, and to perform one or more assays to generate one or more parameters based, for example, on clotting that occurs in the test sample. The one or more parameters may be analyzed to detect a pathology (e.g., low fibrin contribution to clot firmness), to diagnose a condition of the patient (e.g., hyperfibrinogenemia), and/or to suggest a treatment for the condition (e.g., cryoprecipitate transfusion).
In an example, one or more non-transitory machine-readable storage media store instructions that are executable by one or more processing devices to perform a method that includes: outputting a user interface configured to receive inputs to use in a medical algorithm; configuring the medical algorithm based on the inputs; and outputting a display. The display includes a representation of the medical algorithm. The representation presents operations to be executed by the medical algorithm. The representation relates the operations to one or more notifications triggered based on the operations. The one or more non-transitory machine-readable storage media may include one or more of the following features, either alone or in combination.
The inputs may include one or more parameters, one or more predefined values, one or more operators, and the one or more notifications. The operations may include one or more rules. A rule may be configured to evaluate a test result value for one of the parameters against one of the predefined values based on one of the operators. The notifications may correspond to the operations.
The one or more parameters may include one or more of the following: a parameter associated with viscoelastic testing, a parameter associated with blood gas testing, a parameter associated with platelet function testing, a parameter associated with coagulation testing, or a parameter associated with activated clotting time (ACT) testing. The medical algorithm may be for use with a patient. The inputs may include information about at least one of (i) whether the patient is bleeding or has non-bleeding, thrombosis, (ii) a clinical setting, (iii) a stage of surgery the patient is undergoing, (iv) a medical condition of the patient, (v) a body weight of the patient, (vi) an age of the patient, (vii) a sex of the patient, (viii) a medical diagnosis for the patient, or (ix) a treatment that the patient has undergone or is undergoing.
The operations may include one or more groups. A group may include one or more steps. The group may be executable independently of others of the groups.
The operations may include multiple groups. Each group may include multiple steps. Within a group among the multiple groups, the steps may be executable sequentially. Steps in a group among the multiple groups may be executable independently of steps in other groups among the multiple groups.
The display may include an element that is selectable to verify the medical algorithm. The element may be configured to cause output of the instruction.
The inputs may include parameters, predefined values, and operators. The method may include receiving, from the display, an instruction corresponding to an action to take with respect to the medical algorithm. The operations may include rules configured to evaluate test result values for parameters against respective predefined values based on respective operators. The action may include verifying the medial algorithm and, in response to the instruction, the method performed by the one or more processing devices may include outputting a second user interface configured to receive mock or prior test result values for the parameters. The method performed by the one or more processing devices may include: executing the medical algorithm using the mock or prior test result values received via the second user interface; and outputting a report representing one or more results produced by executing the medical algorithm using the or prior mock test result values. The report may include one or more of the rules, one or more test result values received via the second user interface for the one or more rules, and at least one of: (i) a time associated with execution of the one or more rules, (ii) a notification triggered by execution of the one or more rules, or (iii) an alert triggered by execution of the one or more rules, the alert being indicative of one or more test result values satisfying the one or more rules.
In an example, one or more non-transitory machine-readable storage media store instructions that are executable by one or more processing devices to perform a method that includes: receiving test result values for parameters associated with one or more assays; and executing a medical algorithm using the test result values. The medical algorithm includes rules configured to evaluate the test result values. The medical algorithm includes groups including one or more steps, with each step including one or more of the rules. Executing the medical algorithm includes: when a group is identified during execution of the medical algorithm, executing the group independently of other groups in the medical algorithm; when a series of steps is identified in a group during execution of the medical algorithm, executing the steps in the series in a sequence in which the steps are arranged in the series; and outputting a report representing results produced by executing the medical algorithm. The report includes the rules, values based on test result values associated with corresponding rules, and at least one of: (i) a time associated with execution of the rules, (ii) a notification triggered by execution of the one or more rules, or (iii) an alert triggered by execution one or more of the rules. The alert is indicative of one or more test result values satisfying the one or more rules. The one or more non-transitory machine-readable storage media may include one or more of the following features, either alone or in combination.
The values based on the test result values may include at least one of (i) a test result value, (ii) a maximum value that is less than a corresponding test result value, or (iii) a minimum value that is greater than a corresponding test result value. The test result values may be received from a viscoelastic testing system. The test result values may be received in metadata of one or more images or received from an optical character recognition of the one or more images. The method may be performed by the one or more processing devices may include displaying the report together with the one or more images. At least one of the images may include a reaction curve that shows an elasticity over time when a blood clot forms or dissolves. A test result values for a parameter may include (i) a final value for the parameter or (ii) a value for the parameter that is non-final. The medical algorithm may be for use with a patient. The method performed by the one or more processing devices may include receiving information about at least one of (i) whether the patient is bleeding, (ii) a type of surgery that the patient is undergoing, (iii) a stage of the surgery, or (iv) a medical condition of the patient. The medical algorithm may be executed based on the information.
An example system includes one or more test instruments configured to produce test result values for parameters associated with one or more assays; and one or more processing devices in communication with the one or more test instruments. The one or more processing devices are configured to execute instructions to perform operations that include: receiving the test result values from the one or more test instruments; and executing a medical algorithm using the test result values. The medical algorithm may include rules configured to evaluate the test result values. The medical algorithm may include groups including one or more steps, with each step including one or more of the rules. Executing the medical algorithm includes: when a group is identified during execution of the medical algorithm, executing the group independently of other groups in the medical algorithm; when a series of steps is identified in a group during execution of the medical algorithm, executing the steps in the series in a sequence in which the steps are arranged in the series; and outputting a report representing results produced by executing the medical algorithm. The report may include the rules, values based on test result values associated with corresponding rules, and at least one of: (i) a time associated with execution of the rules, (ii) a notification triggered by execution of the one or more rules, or (iii) an alert triggered by execution one or more of the rules The alert is indicative of one or more test result values satisfying the one or more rules.
The one or more processing devices may be external to the one or more test instruments. The one or more processing devices may be internal to one or more of the test instruments.
At least part of the devices, systems, and processes described in this specification may be executed on, or controlled by, executing on one or more processing devices instructions that are stored on one or more non-transitory machine-readable storage media. Examples of non-transitory machine-readable storage media include read-only memory, an optical disk drive, memory disk drive, and random access memory (RAM). At least part of the devices, systems, and processes described in this specification may be implemented or controlled using a computing system comprised of one or more processing devices and memory storing instructions that are executable by the one or more processing devices to perform various control operations. The devices, systems, and processes described in this specification may be configured, for example, through design, construction, formulation, arrangement, placement, programming, operation, activation, deactivation, and/or control.
Two or more of the features described in this specification, including in this summary section, may be combined to form implementations not specifically described in this specification.
The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims.
Like reference numerals indicate like elements.
Described herein are systems and processes for generating user interfaces that enable a user to provide information for one or more medical algorithms and notifications therefor, and for automatically generating and executing the medical algorithm based on the information using test result values.
The medical algorithm(s) include executable operations to analyze the test result values. The test result values may be for one or more parameters obtained by performing one or more assays on one or more test samples. The medical algorithm may be built by organizing the executable operations into groups, steps, and rules.
Examples of types of the parameters may include, but are not limited to, one or more parameters associated with viscoelastic testing, one or more parameters associated with blood gas testing, one or more parameters associated with platelet function testing, one or more parameters associated with coagulation testing, and/or one or more parameters associated with activated clotting time (ACT) testing.
Test result values for the parameters may be obtained by performing one or more assays on one or more test instruments. Examples of viscoelastic test instruments that may perform one or more assays to generate test result values for the parameters include, but are not limited to, the ROTEM® sigma system or the ROTEM® delta system by Werfen®, the TEG® 6s and ClotPro® system by Haemonetics®, and the QUANTRA® system by HemoSonics®. Examples of the parameters for which test result values may be generated by these example viscoelastic test instruments include, but are not limited to, the following clot initiation parameters, clot kinetic parameters, clot firmness parameters, and clot lysis parameters.
For ROTEM® and CloPro®, CT refers to clotting time; CFT refers to clot formation time, the alpha angle refers to the angle tangent to the clotting curve at a two millimeter (mm) amplitude point, A5 refers to clot firmness amplitude five minutes after CT; A10 refers to clot firmness amplitude ten minutes after CT; A20 refers to clot firmness twenty minutes after CT; MCF refers to maximum clot firmness; ML refers to maximum lysis; LI30 refers to a lysis index thirty minutes after CT; LI45 refers to a lysis index 45 minutes after CT; LI60 refers to a lysis index 60 minutes after CT; LOT refers to lysis onset time; and LT refers to lysis time.
For TEG®, CT refers to clotting time, R-time refers to reaction time; K-time refers to kinetic time, the alpha angle refers to the speed of fibrin accumulation and polymerization and is closely related to K-time; A5 refers to clot firmness amplitude five minutes after CT; A10 refers to clot firmness amplitude ten minutes after CT; MA refers to maximum amplitude; ML refers to maximum lysis; LY30 refers to lysis 30 minutes after MA; and LY60 refers to lysis 60 minutes after MA.
For Quantra®, CT refers to clotting time without heparinase; CTH refers to clotting time with heparinase, CTR refers to clotting time ratio; CS refers to clot stiffness; PCS refers to platelet contribution to clot stiffness; FCS refers to fibrinogen contribution to clot stiffness; and CSL refers to clot stability to lysis.
The parameters may be obtained using an activated clotting time (ACT) test performed on the GEM® Hemochron™ 100 system.
Standard coagulation tests may include D-dimer tests, prothrombin time (PT) tests, international normalized ratio (INR) blood tests, activated partial thromboplastin clotting time (aPTT) tests, thrombin time (TT) tests, diluted thrombin time (dTT) tests, calibrated direct oral anticoagulants (DOAC) tests, platelet function tests, and platelet count tests. The parameters may be obtained from one or more of these tests.
Platelet function tests may include an aspirin test and a P2Y12 reactions units (PRU) test performed on the VerifyNow™ system. Platelet function tests may include ROTEM® platelet tests, multiplate tests, TEG® platelet mapping tests, and platelet function analyzer (PFA) 100/200 tests. The parameters may be obtained from one or more of these tests.
The parameters may include other variables such as patient temperature and trauma scores such as ABC trauma scores or trauma-associated severe hemorrhage trauma scores. The parameters may identify a clinical condition of a patient, such as bleeding, non-bleeding, or thrombosis, and a clinical setting, such as cardiovascular surgery, trauma, orthopedic surgery, liver surgery, transplantation, or obstetrics.
The parameters may be obtained from a blood gas testing. Examples of parameters from a blood gas testing system, such as the GEM© Premier 500 blood gas testing system, that may be used may include, but are not limited to, BE(B) (base excess), BE(ecf) (extracellular base excess), tHb(c) (total hemoglobin), Ca++ (7.4) (ionized calcium with a pH of 7.4), AG (anion gap) P/F ratio (pressure of oxygen in arterial blood (PaO2) to the fraction of inspiratory oxygen concentration (FiO2)), pAO2 (partial pressure of oxygen), CaO2 (arterial oxygen content), CvO2 (central venous oxygen saturation), p50 (hemoglobin-O2 affinity), O2cap (arterial blood gas), sO2(c) (oxygen saturation), O2ct (oxygen content), HCO3—std (amount of bicarbonate in blood in a form of carbon dioxide), TCO2 (total blood CO2) HCO3—(c) (bicarbonate, a measure of acid-base balance), A-aDO2 (alveolar-arterial oxygen gradient), paO2/pAO2 (partial pressure of oxygen divided by partial pressure of carbon dioxide, RI (resistive index, an ultrasound parameter), CcO2 (capillary oxygen content), a-vDO2 (arteriovenous difference of oxygen content), Qsp/Qt (est) (intrapulmonary shunting estimated), Qsp/Qt (intrapulmonary shunting), and Hct(c) (hematocrit).
Examples of other parameters that may be used are listed in U.S. Patent Publication No. 2016/0161510 titled “Blood Testing System Result Interpreter Interface and Methods”, the contents of which are incorporated herein by reference.
An example rule in the medical algorithm includes an operation to evaluate a test result value for a parameter from an assay against a single predefined value or to evaluate a value that is based on multiple test result values for combinations of multiple parameters against a single predefined value. The evaluation may be performed using a mathematical operator, such as “=”, “>”, “<”, “>”, “≤”, and so forth
An example step in the medical algorithm includes a single rule, or multiple rules related by a conjunction, such as “AND” or “OR”, that direct(s) an outcome, referred to as a notification, such as a summary, a diagnosis, and/or a treatment option. The notification may be displayed along with an alert. An alert indicates that the rules in the step were satisfied, as described in more detail below.
An example group in the medical algorithm includes a single step or a sequence of multiple steps that may be executed independently of one, more than one, or all other groups in the medical algorithm. For example, a medical professional may determine that certain steps are required to provide diagnosis and/or treatment options for a particular condition, and that those steps must be performed in a certain, predetermined order and associated with specific clinical conditions and specific clinical settings. Accordingly, those steps are assigned by the algorithm creator to a single group and, when executed within that group, are executed in sequence. Independent execution may include that at least part of the steps in two or more groups execute at the same time. Independent execution may include that at least part of the steps in two or more groups execute within the same time period, but not necessarily at the same time.
Treatment options, in particular, may only make sense in combination with specific clinical condition, such as bleeding or thrombosis, and/or specific clinical settings, such as cardiovascular surgery, trauma, orthopedic surgery, liver surgery, transplantation, or obstetrics. Accordingly, parameters relating to the clinical conditions and clinical settings may also be incorporated into the medical algorithm.
By executing each group independently from other groups in the medical algorithm, groups that receive parameters that require less time for evaluation can be executed sooner than groups that receive parameters that require more time for evaluation. The medical algorithm may provide results from groups as the groups complete execution. In some instances, one or more parameters that be assessed more quickly (which can be organized in a first group) by the medical algorithm, which can predict a condition that is later confirmed by other parameters (which are grouped in a second group). For example, the clotting time (CT) and 5 min clot firmness parameter (A5) (e.g., in a first group) occur before parameters like the lysis index at 30 min (LI30) (e.g., in a second group) that predict delayed fibrinolysis. This may be important because delayed treatment may not be effective. For example, tranexamic acid only has a benefit within about three hours of the bleeding onset. Since unavoidable delays of transporting a patient and testing occur, there may be little time to react. It can be better to prophylactically administer the drug in response to analysis of parameters in the first group, rather than waiting for all other groups to be analyzed.
In this example, setup area 11 contains a name field 15, a description field 16, and a reference field 17. Name field 15 receives an input from a user to name the medical algorithm. The name may be based on the clinical setting in which the medical algorithm is used, e.g., cardiovascular surgery, trauma, orthopedic surgery, liver surgery, transplantation, or obstetrics. Any textual moniker may be used. In this example, the generic name “Algorithm” is used. In some implementations, name field 15 may be configured to accept one or more images that identify the algorithm. Description field 16 receives, from a user, an explanation of the function of the medical algorithm. In this example, description field 16 is configured to accept text. In some implementations, description field 16 may be configured to accept images or other content used to describe the algorithm. An example of the other content may be a uniform resource locator (URL) that may link to a page describing the medical algorithm. Reference field 17 receives, from a user, information about reference materials relating to the algorithm, such as books, scholarly articles, medical journals, scientific publications, or the like providing background or other information relating to the algorithm. In addition to text, reference field 17 may configured to accept URLs, images, or other content. Information may be received into the fields from a user or from another computer program, for example.
In some implementations, name field 15, description field 16, and reference field 17 may have character or size limitations. For example, name field 15 may be limited to tens of characters, whereas description field 16 and reference field 17 may be limited to hundreds or thousands of characters. In some implementations, there are no limitations on the number of characters or the size of the content in these three fields.
In a particular non-limiting example, the medical algorithm may be a medical algorithm to diagnose or to treat liver disease. In this example, “Liver Algorithm” may be included in name field 15. Description field 16 may be a description of the type of liver disease that the “Liver Algorithm” is intended to diagnose or to treat, such as liver surgery, liver transplantation, or other bleeding situations in patients with chronic liver disease (e.g., gastrointestinal bleeding). Reference field 17 may include a list of books, articles, or journals containing information about the liver disease.
In some implementations, part of the algorithm setup may include the user entering patient information such as, but not limited to, a clinical setting such as type of surgery that the patient is undergoing or other medical treatment that the patient is undergoing, whether the patient is bleeding or has non-bleeding thrombosis, a stage of surgery, a medical condition of the patient, body weight of the patient, age of the patient, sex of the patient, a medical diagnosis for the patient, and/or a treatment that the patient has undergone or is undergoing. This patient information is associated with the medical algorithm built using UI 10. The association can be made, for example, by a medical professional. For patients having those the characteristics or conditions contained in the patient information, the medical algorithm may be retrieved from a library of one or more of medical algorithms using a computer system.
The patient information may be entered by a user or programmatically into a UI. In some implementations, the patient information is extracted from an image (e.g., a scanned form or a screenshot) using optical character recognition software (OCR), and the extracted information is entered into the UI. The UI may be accessed via a button, such as optional button 13 in setup area 11 or elsewhere, or through a pull-down menu or other control (not shown) associated with, but not contained on, UI 10.
Referring back to
Button 19 (Add Group) is for adding a group to the medical algorithm. Referring to
An example definition box allows a user to define a step in the group and one or more rules for the step. As shown in
The columns include assay and parameter 21a column that allows the user to specify which parameter (P) values are to be evaluated by a rule and the assays (A) from which the parameter values have been obtained; column 21b allows the user to specify benchmarks/predefined values (e.g., AA, BB) against which the parameter values from column 21a are evaluated, operator 21c column allows the user to specify mathematical operators (e.g., “=”, “<”, “>”, “≥”, “≤”) for the type of evaluation of the parameter values against the benchmarks/predefined values, conjunctions 21d column allows the user to specify conjunctions (e.g., “AND” or “OR”) that indicate a relationship among the rules in a single step to produce an outcome, and notification 21e column allows the user to specify a notification such as a treatment and/or a diagnosis to be output in the event that the step is satisfied. In this example, content for assay and parameter column, the operator column, and the conjunctions column may be selected by the user using drop-down menus, whereas content for the value column and the notification column may be typed into their respective fields by the user. In some implementations, content for the assay and parameter column, the operator column, and the conjunctions column may be typed into their respective fields by the user.
The notification, or outcome, can include a summary, a diagnosis and/or a treatment option. The summary can include any comment that provides information related to the evaluation of the step or steps in a group. For example, the summary can describe what an analysis is showing, for example, “prolonged clotting time”. The diagnosis could be hyperfibrinolysis and the treatment option can be tranexamic acid. One or more of the diagnoses and treatment options can be included in the notification. Specific examples are provided below.
Referring to
To add the next rule to definition box 21, the user selects button 22 (Add Rule). Referring also to
In this example, the step defined by definition box 21 includes first rule A1P1<(AA)mm, where P1 is the parameter, A1 is the assay that determined the parameter, and (AA) is the predefined value in millimeters (mm) against which A1P1 is evaluated, here whether A1P1 is less than AA. In this example, the step defined by definition box 21 includes second rule A1P2≥(BB) %, where P2 is the parameter, A1 is the assay that determined the parameter, and (BB) is the predefined value in percent against which A1P2 is evaluated, here whether A1P2 is greater than or equal to BB. The two rules are related by the “OR” conjunction, meaning that if either rule is satisfied, the medical algorithm will display an alert along with the treatment and/or diagnosis #1 from notification 27 field. If neither rule is satisfied, the notification may be displayed but not triggered with an alert.
Referring also to
The relationships among the parameters, operators, predefined values, conjunctions, and notifications in definitions box 29 follows the same pattern as those for definitions box 21. In this example, the step defined by definition box 29 includes rule A3P3>(CC) s, where P3 is the parameter, A3 is the assay that determined the parameter, and (CC) is the predefined value in second(s) against which A3P3 is evaluated, here whether A3P3 is greater than (CC). In this example, the step defined by definition box 29 includes rule A2P3/A3P3<(DD), where A2P3/A3P3 is a combination of parameters, A2 and A3 are the different assays that determined different values of parameter P, and (DD) is the predefined value against which A2P3/A3P3 is evaluated, here whether A2P3/A3P3 is less than (DD). The two rules are related by the AND conjunction, meaning that both rules must be satisfied for the medical algorithm to display an alert along with the treatment and/or diagnosis #2 from notification 31 field. If either rule is not satisfied, the notification may be displayed but not triggered with an alert.
Referring also to
The relationships among the parameters, operators, predefined values, conjunctions and notifications in definitions box 32 follows the same pattern as those for definitions boxes 21 and 29. In this example, the step defined by definition box 32 includes rule A1P1<(EE) mm, where P1 is the parameter, A1 is the assay that determined the parameter, and (EE) is the predefined value in millimeters against which A4P1 is evaluated, here whether A4P1 is less than (EE). In this example, the step defined by definition box 32 includes rule A4P1<(FF) mm, where P1 is the parameter, A4 is the assay that determined the parameter, and (FF) is the predefined value against which A4P1 is evaluated, here whether A4P1 is less than (FF). The two rules are related by the AND conjunction, meaning that both rules must be satisfied for the medical algorithm to display an alert along the treatment and/or diagnosis #3 from notification 34 field. If either rule is not satisfied, the notification may be displayed but not triggered with an alert.
Referring also to
The relationships among the parameters, operators, predefined values, conjunctions and notification in definitions box 35 follows the same pattern as those for definitions boxes 21, 29, and 32. In this example, the third step defined by definition box 35 includes rule A1P1< (EE) mm, where P1 is the parameter, A1 is the assay that determined the parameter, and (EE) is the predefined value in millimeters against which A1P1 is evaluated, here whether A1P1 is less than (EE). In this example, the third step defined by definition box 35 also includes rule A4P1> (FF) mm, where P1 is the parameter, A4 is the assay that determined the parameter, and (FF) is the predefined value against which A4P1 is evaluated, here whether A4P1 is greater than or equal to (FF). The two rules are related by the AND conjunction, meaning that both rules must be satisfied for the medical algorithm to display an alert and the treatment and/or diagnosis #3 from notification 34 field. If either rule is not satisfied, the notification may be displayed but not triggered with an alert.
Additional steps and/or groups may be added in the editor area above. UI 10 may generate and display scroll bar 36 to allow a user to navigate to different definition boxes. Furthermore, although the example steps shown in
Referring to
In some implementations, UI 10 automatically updates display area whenever any content defining the medical algorithm is provided in a definitions box. Thus, in such examples, display area is populated as soon as content is added to editor area 12. In some implementations, UI 10 may display graphical content in display area 14 as each new group is added. In some implementations, UI 10 may display graphical content in display area 14 as each new step is added. In some implementations, UI 10 may display graphical content in display area 14 as each new rule is added. Button 39 is for saving a draft of the medical algorithm to memory. For example, user selection of button 39 also causes UI 10 to save a current version of the medical algorithm in memory, from which it may be retrieved and revised later.
Button 40 is for saving the current version of the medical algorithm in memory as a version and for verifying that version. Verification is described below.
In this example implementation, display area 14 displays the content of step 21x which is defined by definitions box 21, the content of step 29x which is defined by definitions box 29, the content of step 32x which is defined by definitions box 32, and the content of step 35x which is defined by definitions box 35. Display area 14 also displays step 41, which is defined by a definition box that is not visible in the editor area 12, but which may be viewed using scroll bar 36.
Display area 14 identifies individual groups and also which steps are in which groups. In this example, this is implemented by frames such as frames 44 and 45, around steps in different groups. However, steps in different groups may be identified by lines, spacing, markings, text, or other indicia.
Display area 14 identified a notification that is to be displayed in response to executing a step by arrow and YES 46, as shown with respect to step 21x. Display area 14 indicates the sequence in which steps in a group are executed using arrows, such as arrow 47.
In an example implementation, the parameters, assays, predefined values, and notifications shown in the portion of the medical algorithm displayed in display area 14 of
For step 21x/group 48: P1 may be the “A5” clot firmness parameter obtained from the ROTEM® sigma system or the ROTEM® delta system by Werfen®; A1 may be the EXTEM assay performed on the ROTEM® sigma or the ROTEM® delta systems by Werfen®, where EXTEM tests the extrinsic pathway, uses tissue factor as an activator, and provides information about the time it takes for a test sample to clot; (AA) may be 35 mm; P2 may be the “ML” parameters obtained from the ROTEM® sigma system or the ROTEM® delta system by Werfen®; (BB) may be ≥15%; and treatment and/or diagnosis #1 may include a pathology of “clot instability”, a diagnosis of hyperfibrinolysis, and/or a treatment of “tranexamic acid with a dose of 25 mg/kg as a single bolus”, meaning 25 milligrams (mg) per kilogram (kg) of a patient's body weight is to be administered in a single dose.
For step 29x/group 50: P3 may be the “CT” parameter obtained from the ROTEM® sigma system or the ROTEM® delta system by Werfen®; A2 may be the INTEM assay performed on the ROTEM® sigma system or the ROTEM® delta system by Werfen®, where INTEM tests the intrinsic pathway, uses phospholipid and ellagic acid as activators, and measures how long it takes blood to form a clot; (CC) may be 240s; A3 may be the HEPTEM assay performed on the ROTEM® sigma or the ROTEM® delta systems by Werfen®, where HEPTEM is similar to INTEM but uses lyophilized heparinase to neutralize heparin, and reports a result that uncovers any coagulopathy that may coexist alongside heparinization; (DD) may be ≥1.25; and treatment and/or diagnosis #2 may include a pathology of “increased INTEM/HEPTEM CT-ratio due to heparin”, a diagnosis of heparin effect, and/or a treatment of “protamine with a dose of 15-50 mg (2.5-5 ml) per 80 kg body weight and reassess ACT and INTEM/HEPTEM after the therapeutic intervention”.
For step 32x/group 50: P1 may be as defined above; A1 may be as defined above; EE may be 30 mm; A4 may be the FIBTEM assay performed on the ROTEM® sigma system or the ROTEM® delta system by Werfen®, where the FIBTEM assay is used to monitor the blood coagulation process of citrated whole blood samples after activating the extrinsic pathway, blocking platelet contribution to clot firmness, and eliminating a heparin-like effect; FF may be ≤9 mm; and treatment and/or diagnosis #3 may include a pathology of low fibrin contribution to clot firmness, a diagnosis of hyperfibrinogenemia, and/or a treatment of “Cryoprecipitate or Fibrinogen Concentrate administration with a target of A5 FIBTEM≥12 mm.
For step 35x/group 50: P1 may be as defined above; A1 may be as defined above; EE may be as defined above; A4 may be as defined above; FF may be as defined above; and treatment and/or diagnosis #4 may include a pathology of “low platelet contribution due to clot firmness, a diagnosis of “thrombocytopenia” and/or a treatment of “Platelet concentrate transfusion with a dose of 1-2 pooled or apheresis platelet concentrates in an adult patient”.
For step 41/group 50: P3 may be as defined above; A1 may be as defined above; (GG) may be 80s; and treatment and/or diagnosis 5 may include a pathology of “prolonged extrinsic clotting time, a diagnosis of reduced thrombin generation by the extrinsic pathway, and/or a treatment of “PCC 15-25 IU/kg bw or FFP 10-15 mL/kg bw”, where PCC (prothrombin complex concentrate) and FPP (fresh frozen plasma) are treatments.
Referring to
To generate algorithm verification box 51, software that generates UI 10 extracts parameters from the medical algorithm defined by the definition boxes in editor area 12. For example, those parameters may correspond to the parameters from the assay and parameter fields of the definitions boxes, and may be retrieved from memory. The parameters are listed in a column 57 along with corresponding fields 59 for entering a value of each of those parameters, with units for that parameter displayed alongside each field. The values may be entered by a user or by a computer program, including an optical character recognition program that extracts the values from an image. Also displayed are a list of acceptable ranges 60 for a corresponding parameter. The acceptable ranges may be defined by a medical professional and may specify ranges of the parameter that are considered normal or that do not require intervention. Values outside of those ranges cannot be entered into the corresponding field in some implementations. If a value outside of an acceptable range is entered into a corresponding field, the UI may display an error message (not shown) when verification is initiated via button 54. The user may then enter a value within the acceptable range to proceed with verification.
The values entered into fields 59 may be mock test result values, meaning that the values are provided for verification purposes, and may not be actual test result values generated by a test system. In some implementations, the values may be from prior tests that are used for verification purposes only. In an example, the parameters (P) and assays (A) are as defined above. Examples of mock test result values and corresponding ranges for this example may be as follows: for A4P1 the mock test result value may be 5 and the range may be 2-33; for A1P3 the mock test result value may be 50 and the range may be 45-172; for A1P1 the mock test result value may be 44 and the range may be 13-87; for A1P2 the mock test result value may be 55 and the range may be 0-100; for A2P3 the mock test result value may be 200 and the range may be 123-365; and for A3P2 the mock test result value may be 200 and the range may be 122-376. Other mock test result values and ranges may be used instead of these.
Upon user selection of button 54 to initiate verification, the medical algorithm is executed using the mock test values and the results of that execution are displayed by UI 10. For example, referring to
Report 63 is displayed adjacent to the representation of the medical algorithm in display area 14. Report 63 shows the result of execution of the medical algorithm using the mock test result values input into algorithm verification box 51. In this example, report 63 identifies the name 65 of the medical algorithm; displays steps such as 21x, 29x of the medical algorithm graphically in expandable and collapsible boxes, such as boxes 66, along with the treatment and/or diagnosis for the corresponding step and, if applicable, an alert 79 if a condition of the corresponding step has been satisfied (indicating that the treatment and/or diagnosis associated with the corresponding step should be applied), the time 69 that a corresponding step was completed, and values 62 that were analyzed the corresponding steps. The boxes may be expanded or collapsed by clicking anywhere in a box. Drop-down arrows, such as arrow 77, are used as visual indicators to indicate whether a box has been expanded or collapsed.
In the example of
Process 80 includes generating data for, and outputting, (80a) UIs configured to receive inputs such as parameters, predefined values, operators, notifications, clinical information, and patient information that are used to build the medical algorithm. Examples of the UIs output by process 80 includes UI 9 to receive patient information and UI 10 containing setup area 11, editor area 12, and display area 14. The configuration of the UIs, such as the number of definitions boxes may be based on user input. For example, as the user adds more groups and/or steps to the medical algorithm, additional definition boxes may be added in which the user may input information from which to build the medical algorithm.
Process 80 receives (80b), from the UIs output in operation 80a, inputs including the patient information and clinical information described herein. The inputs may include, as described above, parameter values to be evaluated by a rule and the assays from which the parameter values have been obtained, benchmarks/predefined values against which the parameter values are evaluated, mathematical operators for a type of evaluation of the parameter values against the benchmarks/predefined values, conjunctions indicating a relationship among rules in a single step to produce a notification, and notifications, such as a treatment and/or a diagnosis to be output by the medical algorithm and highlighted if the medical algorithm generates an alert.
Process 80 configures (80c) the medical algorithm based on the inputs, notifications, and patient information received in operation 80b. For example, process 80 arranges the parameters values, the mathematical operators, the benchmarks/predefined values, the conjunctions, and the notifications to produce the rules, steps, and/or groups described herein, and generates executable instructions to implement those, steps, and/or groups as part of a computer program. For example, referring to notification box 21 (see, e.g.,
Process 80 generates data for, and outputs, (80d) a graphical display or textual representation of the medical algorithm and corresponding notifications, such as the medical algorithm and corresponding notifications shown in display area 14 of
Process 80 receives (80e), in response to user input on UI 10, an instruction corresponding to an action to take with respect to the medical algorithm defined by UI 10. Examples of actions that may be taken include, but are not limited to, verifying the medical algorithm, storing the medical algorithm in memory, or editing the medical algorithm.
In an example, the medical algorithm may be verified (80f). Operations to verify the medical algorithm are optional in process 80, as indicated by the dashed arrow 81 preceding operation 80f. To verify the medical algorithm in this example, a user selects button 40 (
Following input of the mock or prior test results values, the user selects verify algorithm button 54 of
Actual verification may be performed manually by the user based on the report. For example, the user determines whether the notifications and alerts, in the report make sense for the medical algorithm that the user intended to build. If the user determines that the notifications and alerts, in the report make sense, the user may select button 83 (Approve), in response to which process 80 stores an indication that the medical algorithm has been approved following verification. The indication may be stored in association with the medical algorithm or in a table or the like listing medical algorithms built according to process 80. If the user determines that the notifications and alerts, in the report do not make sense, the user may select button 82 to cancel the current verification, which may result in re-display editor area 12 (
Process 80 may be used to build, and to store in computer memory, multiple medical algorithms. The multiple medical algorithms may constitute a library of medical algorithms. In some implementations, different medical algorithms in the library may be associated with different patient or clinical information. For example, some medical algorithms may be usable for men, some medical algorithms may be used for women; some medical algorithms may be for a particular type of surgery that a patient is having such as liver surgery; some medical algorithms may be used if a patient is bleeding, and so forth. Medical algorithms from the library may be retrieved for execution using patient information and/or clinical information as described herein. In some implementations, the notifications in an algorithm can include a recommendation to use one or more additional algorithms.
Process 85 receives (85a) patient information such as that described with respect to UI 9. For example, the patient information may be input into a user interface by a user or otherwise provided by a user or a computer program. In some implementations, the patient information is extracted from an image such as a scanned form or a screen shot using an optical character recognition algorithm.
Process 85 receives (85b) test result values, such as those described above. The test result values may be received from memory or a test system, examples of which include, but are not limited to, those described herein. The test result values may be result(s) of one or more assays performed on the test system. In some implementations, process 85 receives, from the test system, one or more images which may containing metadata. The image(s) may show reaction curves for the one or more assays, which show elasticity over time when a blood clot forms or dissolves. The metadata in an image includes the test result values for the assay that produced the reaction curve in the image. Process 85 extracts the metadata from these image(s). In some implementations, the test result values may be provided to process 85 manually—for example, by a user—or the test result values may be provided to process 85 through electronic communication between the control system executing process 85 and the test system. In some implementations, the images include one or more test result values which are not included in the metadata. In these instances, the test data can be extracted using optical character recognition algorithms. In some implementations, a graph or other image may be analyzed by an algorithm to extract one or more test result values.
Some test result values may be provided in their final form for evaluation by the medical algorithm. For example, test result values for the ROTEM® A10, and A20 parameters (and potentially others) are provided in their final form since intermediary values of such parameters may not be helpful to determine treatment and/or diagnosis using the medical algorithm. Some test result values may be provided in their non-final form for evaluation by a medical algorithm. For example, test result values for the ROTEM® ML parameter (and potentially others) may be provided in their non-final form, since intermediary values of such parameters may be helpful for treatment and/or diagnosis using the medical algorithm.
Process 85 presents a recommended medical algorithm based on the patient and/or clinical information. For example, if the patient and/or clinical information indicates that the patient is a woman undergoing a liver transplant and is bleeding, process 85 may present (85b) a recommended medical algorithm that is associated with such information to a user for selection along with a description thereof, such as the clinical setting in which the medical algorithm may be used and the types of patients for which the medical algorithm may be used. The user may the elect to select the medical algorithm for execution.
Process 85 receives (85c) a selection of medical algorithm to execute based on the received (85a) patient and/or clinical information. After receiving selection (85c) of the medical algorithm, process 85 executes (85e) the medical algorithm using the received test result values. When executing (85d) the medical algorithm, process 85 identifies (86a) groups in the medical algorithm. The groups may be identified based on information identifying each group added to the medical algorithm in response to selecting button 19 (Add Group) when building the medical algorithm. For example, frames 44 or 45 (
Process 85 executes (86b) each group in the medical algorithm independently of other groups in the medical algorithm. In other words, process 85 executes (86b) the steps and rules in a given group independently of the steps and rules in other groups. Independent execution may include parallel execution, where at least part of the steps and rules in a given group are executed concurrently with execution of at least part of the steps and rules in in one or more other groups of the medical algorithm. For example, referring to
To execute (86b) each group, process 85 identifies (87a) steps in the group. The steps may be identified based on information identifying each step that may be incorporated into the medical algorithm in response to selecting button 20 (Add Step) (e.g.,
Process 85 executes steps in each group in a sequence in which the steps are arranged in the group. For example, if a group contains only one step, that one step is executed. If a group contains a series of steps, process 85 executes the steps in the series in the sequence in which the steps are arranged in the series. For example, in group 50 (
In some implementations, when a rule in a step indicates that a value is less than or equal to a predefined value, then the rule continues to be evaluated until a test result value is finalized. For example, if the conditions of a step are not satisfied, then a rule in the step can be evaluated repeatedly while the value is updated. For example, ML keeps growing for the duration of the algorithm so if a rule is testing whether >15%, then just because the ML is currently 10% does not mean that the rule has completed its evaluation. In this example, the medical algorithm continues to evaluate the step until the user ends the algorithm or ML exceeds 15%.
In some implementations, after a step has been executed, that step will not be executed again unless (i) new data is received or (ii) the step is executing using test result values that need not be finalized, such as ROTEM® ML test result values.
Process 85 obtains (87c) the step test result based on execution of the step. In this example, the obtained step test result includes a treatment and/or diagnosis, such as treatments and/or diagnosis #1 to #5 of
Process 85 determines (87d) whether one or more additional step(s) remain in a group. This may be determined based on the information identifying each step incorporated into the medical algorithm in response to selecting button 20 (Add Step) when building the medical algorithm, as described above. If an additional step remains in the group, process 85 executes (87e) the next step in the group in sequence. For example, referring to
Process 85 generates data for, and outputs (87f), a group test result, which includes the step test results for each step in a current group. The groups test results are incorporated into a report output by process 85, as described below.
Process 85 determines (86c) if all groups have been executed. This determination (86c) includes whether all steps and rules in each group have continued executing. If all groups have not been executed, process 85 continues executing the groups; otherwise, group execution ends (86d).
Process 85 generates data for, and outputs, (85f) a report showing results of the medical algorithm. The report may have a format that is similar to the format of report 63 shown in algorithm verification area 52 of
In example report 90, steps 104 did not generate alerts and, therefore, are colored or shaded differently than steps 101 and 103. Steps 101 and 103 generated alerts. The alerts generated by steps 101 and 103 are a result of test result values satisfying the condition or conditions required by the corresponding step. Step 102 also generated an alert, which is indicated by triangle 109. However, the alert generated by step 102 is different from that generated by steps 101 and 103. More specifically, in some jurisdictions, government agencies limit the test result values that can be reported by the system. In this example, report 90 indicates that test result value for step 102 is “>Ms”, where “Ms” is the maximum test result value that the corresponding test system is approved by the government agency to report. In some implementations a minimum value that is less than an actual test result value may be used if that is required by a government agency. In this case, the medical algorithm outputs an alert 109 and a notification 110, which may indicate that the test result value cannot be used because it is outside of an approved reportable range. In report 90, step 102 may be colored or shaded differently than steps 101, 103 (which produced alerts for other reasons) to indicate why that alert was provided. Generating and outputting an alert of this type is an optional feature and need not be included in all reports in all jurisdictions.
In the example of
In some implementations, the report is displayed together with the one or more images (described above) from which the test results values to be evaluated by the medical algorithm were obtained. For example, process 85 may retrieve these images from memory and display them with the report.
Report 120 has a format, and contains information, similar to report 90 of
In the example of
In the example of
Each image may identify an assay, such as assay 140, that produced the reaction curve included in the image. Each image may identify parameters, such as parameters 141, that were determined by the corresponding assay. Values and acceptable ranges of values for corresponding parameters are also displayed. For example, for parameters 141, values and ranges 142 are displayed. In an example implementation, the parameters P1, P2, and P3, and assays A1, A2, A3 and A4 may be the same as the examples described with respect display area 14 of
Control system 152 includes machine-readable memory 154 storing instructions 155 that are executable by one or more processing devices 156 to execute processes 80 and 85 and, in some implementations, to control operation of test instrument 151. All or part of the control system may be implemented on a computing system that is external to test instrument 151. All or part of the control system may be internal to test instrument 151. All or part of the control system may be distributed across one or more computing systems and/or the test instrument. Communications between external portions of the control system and the test instrument are represented by dashed line 158.
At least part of the systems and processes described in this specification and their various modifications may be executed or controlled at least in part by one or more computers such as control system 152 using one or more computer programs tangibly embodied in one or more information carriers, such as in one or more non-transitory machine-readable storage media. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, part, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a network.
Actions associated with executing the processes or controlling the test system described herein can be performed by one or more programmable processors executing one or more computer programs to control or to perform all or some of the operations described herein. All or part of the test systems and processes can be executed or controlled by special purpose logic circuitry, such as, an FPGA (field programmable gate array) and/or an ASIC (application-specific integrated circuit) or embedded microprocessor(s) localized to the instrument hardware.
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only storage area or a random-access storage area or both. Elements of a computer include one or more processors for executing instructions and one or more storage area devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from, or transfer data to, or both, one or more machine-readable storage media, such as mass storage devices for storing data, such as magnetic, magneto-optical disks, or optical disks. Non-transitory machine-readable storage media suitable for embodying computer program instructions and data include all forms of non-volatile storage area, including by way of example, semiconductor storage area devices, such as EPROM (erasable programmable read-only memory), EEPROM (electrically erasable programmable read-only memory), and flash storage area devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD-ROM (compact disc read-only memory) and DVD-ROM (digital versatile disc read-only memory).
Elements of different implementations described may be combined to form other implementations not specifically set forth previously. Elements may be left out of the systems described previously without adversely affecting their operation or the operation of the system in general. Furthermore, various separate elements may be combined into one or more individual elements to perform the functions described in this specification.
Other implementations not specifically described in this specification are also within the scope of the following claims.