Multimodal Workbook

Johnny Mayall  user  July 14, 2022, 6:43 p.m.

Sections: Overview | Panels | Tests | Parameters

Overview

The multimodal casetype empowers customers to define the interpretation of raw instrument data at extremely granular levels, giving them the means and flexibility necessary to construct highly detailed reports from their instrument data. The associated workbook file must be saved as the 'Excel 97-2003 Workbook (*.xls)' type so that the processes which consume the workbook (and therefore create and configure the entire specifically-delineated multimodal structure) can retain broad-ranging compatibility and accessibility with a wide variety of customers. The workbook contains three sheets that drive a customer's multimodal experience:

1. Panels: Panels are the orderable object in the system which can be associated with zero-to-many tests and zero-to-many procedure codes.
2. Tests: Tests are the resultable object in the system which can be associated with zero-to-many results and zero-to-many parameters. A test cannot be associated with a case to receive results unless a panel associated with that test has been ordered for that case.
3. Parameters: Parameters are the calculable object in the system which can automatically derive interpretations based on numeric or range measurements.

↑ top

Panels

A case must be associated with one-to-many panels which represent the orderable entity in the system. A panel can be associated with zero-to-many tests and zero-to-many procedure codes, act as a conditional trigger to order add-on panels, and can contain special interface-related or reporting information. Panels are primarily used to organize available test offerings in the manner that they are ordered by physicians, labs, and clinics. When a panel is added to a case, the procedure codes and enabled tests associated with that panel become associated with the case. If a panel is removed from a case, the case will no longer be associated with the procedure codes and tests directly associated with that panel. It's important to keep in mind that while procedure codes for individual tests can be important in determining cumulative procedure codes for multi-test panels, the only procedure codes stored in the system are at panel-level. Different types of panels are often referred to in abbreviated form based on how they are configured and used.

• MTP: multi-test panel (contains multiple direct test components)
• STP: single-test panel (contains a single direct test component)
• AMP: add-on multi-test panel (contains multiple direct test components & orders add-on panels)
• ASP: add-on single-test panel (contains a single direct test component & orders add-on panels)
• AOP: add-on only panel (contains no direct test components & orders add-on panels; sometimes referred to as a 'super panel')
• BRP: billing/reporting panel (contains no direct test components & is instead associated with a set of procedure codes and/or designated values that are typically used in conjunction with a third-party interface or custom business reporting; sometimes referred to as an 'instructional/informational panel')

Note: In the context of our system, we use 'panel' as a generic term independent of any CMS-identified billable panels with strictly defined components. Some customers are more accustomed to using different terms (e.g., profile, assay, order), but the contextual goal of any of these terms is to refer to a collection of components (typically tests) that can be ordered via a single entity.

Here's a field-by-field breakdown:​

• UUID: This is a system-generated unique key and should not be altered. If you are adding a new panel, leave this field blank. If you are editing an existing panel, leave this field as-is.
• Name: This is the required name of the panel as it will show in the UI and on reports. Enabled panels with duplicate names are not inherently problematic if they are associated with different casetypes, but they can lead to serious problems and confusion if accessible via the same casetype.
• Procedure Codes: This is an optional field where any billing-related procedure codes, counts, and modifiers would be entered using this format: {code}|{count}|{modifier}. Code and count are required; modifier (and its preceding pipe delimiter) is optional, with multiple modifiers for the same code being comma-delimited. Multiple distinct codes are delimited by three consecutive semicolons (;;;). There should be no spaces in the data for this field. Examples:
  1. 82040|1|90
  2. 84155|3
  3. 82306|1;;;83690|1|TC,90;;;78014|2
• Enabled: Active panels are set to TRUE and can be ordered. Retired/superseded panels are set to FALSE and can no longer be ordered. (Panels do not get deleted since that would lead to a cascade of broken associations and negatively impact historical reporting.)
• Moniker: This is a required customer-generated alphanumeric identifier that must be unique and often includes internal organization elements (e.g., department abbreviations).
• Code: This is an optional field for customers who require an additional customer-generated alphanumeric ID (unique or otherwise), typically used for billing or organizational purposes.
• External ID: This is an optional field for customers who have a third-party interface via Pathagility when that third party is unable to use the panel's moniker.
• Casetypes: This required field lists the identifier of the casetypes that this panel should be associated with. Multiple casetype identifiers are delimited by three consecutive semicolons (;;;). There should be no spaces in the data for this field.
• Description: This is an optional field that can be used to provide a lengthier set of supplemental information for the panel; this can be used in business reporting or be set up to display on the end-clinician report.
• Additional Panel Iff: This optional field allows for the automated ordering of additional other panels based on specified case-related criteria.

↑ top

Tests

Tests are primarily used to represent individual test procedures performed and to store associated results (e.g., raw instrument output, measurements, conditional calls, interpretations, flags, manual observations). A secondary use for tests is to consider discrete results from other tests acting as subcomponents and then determine an aggregate result.

Here's a field-by-field breakdown:​

• UUID: This is a system-generated unique key and should not be altered. If you are adding a new test, leave this field blank. If you are editing an existing test, leave this field as-is.
• Name: This is the required name of the test as it will show in the UI and on reports. Enabled tests with duplicate names are not inherently problematic if they are associated with different panels, but they can lead to serious problems and confusion if accessible via the same panel.
• Enabled: Active tests are set to TRUE. Retired/superseded tests are set to FALSE. (Tests do not get deleted since that would lead to a cascade of broken associations and negatively impact historical reporting.)
• Type: This required selection determines which result choices are available by default as well as how the test interacts with parameters. Currently available types include:
  • Quantitative: These tests are intended to receive numeric or range measurements and interact with associated parameters to automatically derive interpretations. The default result choices available to this test type are:
    • Normal [NRML]
    • Abnormal [ABNRML]
    • Critical Abnormal [CRTABN]
    • Normal Range - No Flag [NRNF]
    • Normal Range - Low Flag [NRLF]
    • Normal Range - High Flag [NRHF]
    • Alert Range - Low Flag [ARLF]
    • Alert Range - High Flag [ARHF]
    • Inconclusive [INC]
    • Invalid [INV]
    • Quantity not Sufficient - QNS [QNS]
    • Test not Performed - TNP [TNP]
    • Test Performed, not Resulted - TPNR [TPNR]
  • Semi-Quantitative: These tests are intended to receive numeric or range measurements and interact with associated parameters to automatically derive interpretations. The default result choices available to this test type are:
    • Normal [NRML]
    • Abnormal [ABNRML]
    • Critical Abnormal [CRTABN]
    • Detected [DTCTD]
    • Not Detected [NDTCTD]
    • Reactive [RCTV]
    • Non-Reactive [NRCTV]
    • Positive [POS]
    • Presumptive Positive [PPOS]
    • Weak Positive [WPOS]
    • Negative [NEG]
    • Presumptive Negative [PNEG]
    • Equivocal [EQU]
    • Indeterminate [IND]
    • Inconclusive [INC]
    • Invalid [INV]
    • Quantity not Sufficient - QNS [QNS]
    • Test not Performed - TNP [TNP]
    • Test Performed, not Resulted - TPNR [TPNR]
  • Manual_Entry: These tests are intended to receive alphanumeric values and do not interact with parameters to automatically derive interpretations, which must instead be explicitly entered/selected. In addition to the selectable options above, a freeform result can be entered for a manual entry test. The default result choices available to this test type are:
    • Positive
    • Negative
    • Indeterminate
    • Quantity not Sufficient - QNS
    • Test not Performed - TNP
    • Test Performed, not Resulted - TPNR
• Parameters: This is the exact name (as per the Parameters sheet) of any parameters this test is associated with. Multiple parameter names are delimited by three consecutive semicolons (;;;). There should be no spaces in the data for this field.
• Panels: This is the exact name (as per the Panels sheet) of any panels this test is associated with. If a test is enabled and a panel listed here is ordered for a case, the test will be associated with that case and be able to have measurements and results set. Multiple panel names are delimited by three consecutive semicolons (;;;). There should be no spaces in the data for this field.
• Identifier: This is a required customer-generated unique alphanumeric identifier that must be unique and often includes internal organization elements (e.g., department abbreviations). If you intend to upload instrument results for consumption by a Pathagility data processor, this identifier is used to match up the correct results with the correct tests.
• Alias/Abbreviation: This is an optional field that can be used to provide an alternate human-friendly name or abbreviation of the test.
• Code: This is an optional field for customers who require an additional customer-generated alphanumeric ID (unique or otherwise), typically used for billing or organizational purposes.
• External ID: This is an optional field for customers who have an interface with a third party via Pathagility when that third party is unable to use the test's identifier.
• Substance: This is an optional field that can be used to designate the substance being measured by this test.
• Categories: This is an optional field that allows customers to organize (and label) their tests in the UI and on reports.
• Classes: This is an optional field that is a subsection of Categories that allows customers to further organize (and label) their tests in the UI and on reports.
• Units: This is an optional field that allows a default measurement unit value (e.g., g/dL, fL, %, 10^3 cells/uL) to be set if that value will be consistent whenever the test procedure is performed.
• Method: This is an optional field that can be used to note the method used when the test procedure is performed.
• Description: This is an optional field that can be used to provide a lengthier set of supplemental information for the test; this can be used in business reporting or be set up to display on the end-clinician report.
• Measurement Iff; Result Iff; Flag Iff; Call Iff: These optional fields allows for automated assignment or alteration of their values based on specified test-related criteria. These can be used independently from or in conjunction with parameters.
• Additional Panel Iff: This optional field allows for the automated ordering of additional panels based on specified test-related criteria.
• Post Interpretation Methods: This optional field allows for invoking a custom-developed method for situations that cannot be handled via parameters and/or the various Iff fields.

↑ top

Parameters

Parameters are primarily used to streamline the process of obtaining final results by comparing predetermined mathematical criteria to numeric or range measurements in order to automatically derive interpretations. This streamlining goal is two-fold: reduce potential operator error and reduce the amount of time necessary to obtain final results. This primary use is only available for associated quantitative and semi-quantitative tests. A secondary use for parameters is to display one or more of the parameter's values (e.g., Range Description) as static text for manual entry tests in business reporting or on the end-clinician report; this secondary use will not lead to automatically derived interpretations. A single test can be associated with zero-to-many parameters, and a single parameter can be used by zero-to-many tests. It's important to remember that a parameter represents a set of matching/comparison criteria that can be used by multiple tests and is not inherently tied to any individual test.

Here's a field-by-field breakdown, with certain fields broken out by grouping:​

• UUID: This is a system-generated unique key and should not be altered. If you are adding a new parameter, leave this field blank. If you are editing an existing parameter, leave this field as-is.
• Name: This is the required name of the parameter as it will show in the UI and on reports. Parameters with duplicate names are not allowed.
• Patient Range Values: These optional fields enable a parameter to be selectively applied only to patients matching a certain age range and/or gender. The Range Low, Range High, and Gender fields should be left blank for parameters intended to be applied to all patients.
  • Patient Age Range Units: The age unit (Years, Months, or Days) to be used with the Range Low and Range High.
  • Patient Age Range Low: Minimum age (integer value using the selected units) a patient must be for this parameter to be applied.
  • Patient Age Range High: Maximum age (integer value using the selected units) a patient may be for this parameter to be applied.
  • Patient Gender: The gender (Female or Male) a patient must be for this parameter to be applied.
• Normal Range Values: These fields enable a quantitative or semi-quantitative test to automatically derive interpretations and display related data on the end-clinician report. For quantitative or semi-quantitative tests, these fields are required; if any of these three values are missing or incorrectly formatted, the parameter is incomplete and will not work as intended. Low and High values must be numeric (decimal format with precision up to 10^-3). In many situations, 'Normal Range' is also referred to as 'Reference Range'.
  • Range Low: Minimum numeric value a measurement must be to qualify as being inside the range.
  • Range High: Maximum numeric value a measurement may be to qualify as being inside the range.
  • Range Description: An alphanumeric description of the normal range, dependent on known boundaries are their relationships and typically represented in one of these formats:
    • Normal: 18 - 49 mg/dL
    • Normal: >= 25 10^3 cells/uL
    • Normal: < 150 fL
    • Negative: < 16.0 pg | Positive: >= 16.0 pg
    • Non-Reactive: < 1 S/CO | Reactive: >= 1 S/CO
• Alert Range Values: These optional values behave similarly to normal range values, except they can add an additional alert range layer below the normal range low and/or above the normal range high. Alert ranges can only be used with quantitative tests.
  • Alert Range Low: Minimum numeric value a measurement must be to qualify as being inside the range.
  • Alert Range High: Maximum numeric value a measurement may be to qualify as being inside the range.
  • Alert Range Description: An alphanumeric description of the alert range, dependent on known boundaries are their relationships and typically represented in one of these formats:
    • Alert Low: < 3.5 mg/dL | Alert High: > 12.3 mg/dL
    • Alert High: > 275 mmol/L
    • Alert Low: < 42.08 %
• Description: This is an optional field that can be used to provide a lengthier set of supplemental information for the parameter; this can be used in business reporting or be set up to display on the end-clinician report.

Parameter Validity & Selection: When a panel is ordered for a case and that case goes through a save cycle, the system creates a results entry for every enabled test currently associated with that panel. In addition to results-specific fields (e.g., Measurement, Call, Flag, Result, Instrument ID), this entry includes information about the test as it relates to other case data. If the test is associated with a valid parameter, information for that parameter will also get added to the results entry. A parameter is only considered valid for a particular results entry if the patient's demographic data falls within any patient range values set for the parameter. If a test is associated with multiple parameters (such as a parameter that has different configurations based on patient age and/or gender), the system will attempt to select a single valid parameter based on the first match it finds in this order: both age and gender, age only, gender only, parameter name (ascending ASCII order). If no valid parameter is found, no parameter values will be applied to the results entry.

Parameter Application & Interpretation: If a measurement gets added (without a corresponding flag/call being explicitly set) to a results entry for a quantitative or semi-quantitative test with a valid parameter and the case goes through an interpretation loop, the system automatically attempts to derive an interpretation. The interpretation is determined by making a mathematical comparison of the measurement against the parameter's normal range low and high values (and alert range low and high values, if the test is quantitative) if those values have been set.

• Quantitative Comparison Match with Flag Value
  • Measurement < Alert Range Low: Alert Range - Low Flag
  • Alert Range Low <= Measurement < Range Low: Normal Range - Low Flag
  • Range Low <= Measurement <= Range High: Normal Range - No Flag
  • Range High < Measurement <= Alert Range High: Normal Range - High Flag
  • Measurement > Alert Range High: Alert Range - High Flag
• Semi-Quantitative Comparison Match with Call Value
  • Measurement < Range Low: Negative
  • Range Low <= Measurement <= Range High: Indeterminate
  • Range High < Measurement: Positive

Since this is a mathematical comparison, a parameter can only successfully derive an interpretation if the measurement and the various range low and high values are numeric; this is why 'Measurement' and 'Units' are separate fields. If a specific range value is not set for a parameter, it's corresponding interpretation cannot be derived (e.g., if a parameter associated with a semi-quantitative test has a Range Low value but no Range High value, only Negative or Indeterminate interpretations can be derived). These automatically derived flag/call interpretations are set to the default values noted above, but these values can be altered for specific tests via the use of Flag Iff and Call Iff entries.

↑ top