Casetypes and Accession IDs

Sections: Overview | Accession IDs | How-To | Notes | Screenshots


Overview

Casetypes are one of the core building blocks in Pathagility WorkPath, acting as the primary case-level organizing element, providing the baseline data framework, and delineating the structure of system interactions for cases of their type. Every casetype has a common set of informational data elements:

  1. Basetype: The root of every casetype is a predefined basetype. Listed below are the standard types, along with differentiating highlights. (If none of the standard types are a good fit, a new customer-specific basetype can be created as a custom development project.)
    • Generic [GEN]
      • Medications: No
      • Panels: No
      • Report Notes: Yes
      • Results Upload/Processing: No
      • Special: Diagnosis, History, and Microscopic Description fields; Ability to configure custom EAV structures
    • Gynaecologic Cytology [GC]
      • Medications: No
      • Panels: Yes
      • Report Notes: No
      • Results Upload/Processing: No
      • Special: Diagnosis field; Patient History, Pap Results, and Molecular Results sections
    • Multimodal [MM]
      • Medications: Yes (optionally suppressible)
      • Panels: Yes
      • Report Notes: Yes
      • Results Upload/Processing: Yes
      • Special: Testing structures and auto-interpretive logic configured via MM workbook
    • Pharmacogenetic [PGX]
      • Medications: Yes
      • Panels: Yes
      • Report Notes: Yes
      • Results Upload/Processing: Yes
      • Special: Testing structures and auto-interpretive logic configured via PGX workbook; Ability to configure custom EAV structures
    • Toxicology [TOX]
      • Medications: Yes
      • Panels: Yes
      • Report Notes: Yes
      • Results Upload/Processing: Yes
      • Special: Testing structures and auto-interpretive logic configured via TOX workbook
    • Womens Health [WH]
      • Medications: No
      • Panels: Yes
      • Report Notes: No
      • Results Upload/Processing: Yes
      • Special: Ability to configure custom EAV structures
  2. Identifier: This is a unique text identifier for the casetype that is typically used with a workbook or interface. It should be easily machine consumable, and it should not contain spaces.
  3. Moniker: This is the accession ID prefix. It should be easily machine consumable, and it should contain only letters and numbers. (Accession IDs are discussed in more detail in the next section.)
  4. Description: This is a brief user-friendly description of the casetype. This is the casetype data element that Work Flow users will most frequently interact with when creating new cases, performing searches, and pulling reports.
  5. Report Template: Each casetype can be associated with a single end-clinician report template.
  6. Barcode Template: Each casetype can be associated with a single barcode template.
  7. Enabled: A casetype must be enabled for new cases of its type to be accessioned.
  8. Identity Information: Each customer has a single primary set of identity data: name, address, city, state, zip, phone, fax, URL, lab name, lab director, CLIA #, CAP #, and medical director. Each casetype also has its own optional set of identity data (sometimes referred to as overrides), and if any portion of this casetype data is empty (as is often the situation), it inherits the corresponding data from the customer set of data if it exists. This identity data is most often used with custom end-clinician reports and interfaces.

Every casetype also has various properties which determine how cases of this type interact with the system as well as allowing a customer to set default values for various data elements, providing for speedier data entry that is more consistent and reliable. While some properties are always present across all types, other properties are specific to certain basetypes.

↑ top


Accession IDs

There are two methods for creating accession IDs: automatically and manually. The default method for new cases types is to generate them automatically, but the Manually Enter Accession Numbers option can be selected if desired. The chosen method is not a locked-in decision, and a casetype can be reconfigured between methods as needed. Accession IDs (regardless of creation method) are limited to 32 alphanumeric characters.

Manually: These accession IDs are determined in their entirety by the customer. When this method is active, the editable Accession field will be present in the UI when creating or editing a case of this type.

Automatically: These accession IDs are generated by the system when a case is created. When this method is active, the accession ID will be displayed, but the editable Accession field will not be present in the UI when creating or editing a case of this type. Automatically-generated accession IDs have two components that are separated by a dash:

  1. Moniker: This portion is the moniker assigned to the casetype by the customer. Customers with multiple testing modalities, multiple products, a desire to indicate year of specimen collection, and/or multiple sets of end users often reflect this in their casetype monikers (e.g., PGXVers1, PGXVers2, PGXVers1Lab1, PGXVers1Lab2, TOX17, TOX18).
  2. Counter: This portion is zero-padded up to 5 digits if the counter is below 10,000 (e.g., 00999), and the counter is used as-is otherwise (e.g., 2470812). Each casetype has its own counter; the counter for new casetypes typically starts at 0, and the next integer in positive sequence (with a limit in the low billions) is used when a case of that type is created. For example: If a new casetype with a moniker of ‘ABC17′ is created, the counter would start at 0 by default. The first case created of that type would have an accession ID of ABC17-00001, and the counter would then be auto-incremented to 1, leading to the next case of that type having an accession ID of ABC17-00002, and so on.

The moniker for a casetype can be changed as needed; this change will not impact any already existing cases (regardless of their status), and a moniker change does not affect the counter for the casetype. The next case created of this type will use the new moniker while continuing to use the existing counter value. If needed, the counter for a casetype can be reset to 0; this is a separate action that can be performed independently of any moniker change, or the timing of the reset can be coordinated with a moniker change. Resetting the counter for a casetype should be approached with care so that unintentional duplicate accession IDs are not created.

For example: Some customers include the two-digit portion of the year in the monikers of their casetypes, updating those monikers at the beginning of each year. If the last case of this type in 2017 is ABC17-00345, and the moniker is changed to ‘ABC18′ without also resetting the counter, the accession ID of the next case of this type would be ABC18-00346. If the counter is also reset for this casetype immediately after changing its moniker, the accession ID of the next case of this type would be ABC18-00001.

↑ top


How-To

To create a casetype:

  1. Click on the Administration tab.
  2. Click the Casetypes link in the System Management Tools section.
  3. Click the New Casetype button on the right side of the screen.
  4. Enter the Casetype Information.
  5. Click the Save button.

(To set any properties for a newly-created casetype, the casetype will need to be edited.)

To edit a casetype:

  1. Click on the Administration tab.
  2. Click the Casetypes link in the System Management Tools section.
  3. Click the desired casetype in the list.
  4. Click the Edit Casetype button.
  5. Edit the Casetype Information and Casetype Properties.
  6. Click the Save button.

To reset the counter (to zero) for a casetype:

  1. Click on the Administration tab.
  2. Click the Casetypes link in the System Management Tools section.
  3. Click the desired casetype in the list.
  4. Click the Reset Casetype button.
  5. If you are sure that you want to reset the counter for this casetype, click the Yes button.

↑ top


Notes

  • Since many casetype settings are stored at the session level, it’s best to log out and log back in after reconfiguring a casetype.
  • Once a case is signed, it can no longer be edited. As such, the accession ID of a case is finalized at that time.
  • If a case is amended, the newly created amendment will have an accession ID that combines the accession ID of its parent case with a dash and amendment counter added to the end. For example: If ABC18-00065 is amended, the accession ID of the new amendment would be ABC18-00065-1. If ABC18-00065-1 were amended, the accession ID of the new amendment would be ABC18-00065-2.
  • When using the API to create a new case (via POST) of a casetype set up to automatically generate accession IDs, the API can either take advantage of this functionality or set a customer-determined accession ID.
  • When using the API to edit an existing case (via PUT or PATCH), the API can edit the accession ID regardless of the casetype’s settings.

↑ top


Screenshots

Casetypes: Create Casetype
Casetypes: Create Casetype

Casetypes: Casetype Information
Casetypes: Casetype Information

Casetypes: Casetype Properties
Casetypes: Casetype Properties

Casetypes: Options
Casetypes: Options

↑ top

0