Cases: Data Elements

Sections: Overview | Notes


Overview

In Pathagility WorkPath, a case is a flexible organizational object that combines and presents various data elements that taken together represent a specific medical interaction for a specific patient. A medical interaction begins when a procedure, item, or test is conducted/used (this is typically the earliest specimen collection date, which is often the same date that the case is accessioned on) and ends when the interaction is finalized (this is typically when the case is signed, unless it is later canceled or amended). In terms of the interaction, delivery of finalized results is a post-interaction administrative function (this is typically when the case is released and usually in the form of distribution rules delivering an end-clinician report).

Some data elements are fields inherently tied to a case (e.g., accession ID, added on/by), and others are independent entities with sub-elements of their own that are associated with zero-to-many cases (e.g., patient, physicians, facilities). Not all cases will necessarily have the same set of data elements since some casetypes have different baseline data frameworks, but here are some of the key data elements that most (if not all) cases will have for a typical customer:

  • Accession ID: A case always has a single accession ID which represents the primary identifier used to refer to a case. While this ID is not unique from a system-enforcement standpoint, it is effectively unique from a customer usage standpoint (unless a customer explicitly decides to bypass warnings and duplicate an existing accession ID). While each case can only have a single accession ID, secondary identifiers (e.g., Encounter ID, Order Number) are available if needed.
  • Patient: A case must be associated with a single patient. However, a case can also have various designated relationships (e.g., Family, Redraw/Recollect, Reflex Testing) with zero-to-many other cases.
  • Physicians: A case can be associated with zero-to-many physicians which represent both the ordering physician and any referring or associate physicians that will continue to interact with the patient or require access to results. Of those physicians, one is always designated as primary for the case (by default, the first physician entered when accessioning a case).
  • Facilities: A case can be associated with zero-to-many facilities which represent the locations where various aspects of the medical interaction have occurred. Of those facilities, one is always designated as primary for the case (by default, the first facility entered when accessioning a case).
  • Diagnosis Codes: A case can be associated with zero-to-many diagnoses which represent a physician’s assessment of the aggregate set of results-related data for a case (which can include include multiple results from multiple tests from multiple panels). These diagnoses apply to the case as a whole and are not directly tied to individual panel orders or test results. The list of available diagnoses is based on the official ICD-10 data provided by the CDC.
  • Queues: A case can be associated with zero-to-many queues which represent customer-created workflow processes and/or organizational categories.
  • Batches: A case can be associated with zero-to-many batches which represent specimen groups that are processed together and associated with custom-configured instrument plates.
  • Specimens: A case must be associated with one-to-many specimens. (A multimodal casetype can be configured such that specimens are disabled and therefore not required.)
  • Medications: A case can be associated with zero-to-many medications which represent any medication regimen the patient is adhering to as well as any relevant off-regimen medications being taken at the time of the medical interaction. The initial list of available medications can be customized per basetype and is typically integrated with a customer workbook.
  • 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, and each panel can contain special interface-related information. (Some casetypes do not use panels at all or are custom-built around a tightly-focused testing modality that inherently assumes the same pseudo-panel for every case.)
  • Tests: A case can be associated with zero-to-many tests which represent the resultable (e.g., measurements, interpretations) entity in the system. A test can be associated with zero-to-many panels. Results can only be added to a case if the relevant test has been added to the case, and a test can only be added to a case if an associated panel has been ordered for the case.

↑ top


Notes

  • A medical interaction that involves multiple specimens taken and/or multiple panels ordered and/or a panel with multiple tests receiving results across multiple days is generally represented by a single case, but customers can choose to split such complex interactions out into separate cases if they need to organize interactions on more specific levels (such as individual specimen, panel, test, etc.).
  • See also: Cases: Status and Lifecycle

↑ top

0