ConnectSx Key Terms and Concepts
Section: General |
Defined |
Dashboard |
The landing page of vTrakr and Console apps. This contains quick links, analytics about sales, inventory and cases, pending transfers, pending POs, and a quick reference lookup feature. |
Navigation bar |
Located along the bottom of the page for vTrakr, and the left of the page for the Console, the navigation bar allows the user to access the different domains of the platform: dashboard, inventory, events, reports, or account information. A secondary nvaigation bar appears below some screens in the console navigation bar such as "Inventory" with further navigation options. |
Sales Order (Formerly referred to as the Device Usage Ticket (DUT)) |
The sales order is the document that accounts for all (billable) devices used or sold in a case. This can be printed or emailed to the relevant individuals or accounts (ex. Hospital billing department, manufacturer finance department). The Sales Order is produced as an outcome of a scheduled case (or other event type) being performed and device use recorded. Afterwhich it is used to generate other billing documents by the provider and manufacturer (Purchase order and invoice). The sales order can always be reviewed, revised, or reprinted from the Event Detail screen for that event. |
Section: Event |
Events are the main way that inventory is consumed in Beacon. This means surgical cases, inventory adjustments, stocking orders, sample orders, etc. all would be types of Events where inventory is removed, consumed, or decremented from your account. Some Events may be billed for, some may not. Surgical cases are the most common type of Event and so you may observe us using the terms Event and Case interchangeably. So if you're confused, remember that Case = Event in most contexts. |
Name |
What the user will call the case to esily find and manage it in their records. This is a subjective name and can be any alphanumeric name. It is recommended that the customer determine a naming convention for Event Name to be used with all users and Events in order to keep consistency across user data. |
Procedure |
The primary clinical name of the procedure being performed in a case. These records are stored in the directory so they may be selected easily by drop-down menu during case/event creation. |
Facility |
The facility where the surgical case/event will be performed. These records are stored in the directory so they may be selected easily by drop-down menu during case/event creation. You may store multiple Facility points of contact in the Facility record (the primary billing contact will be auto-populated when emailing billing documents). You may also import contract pricing for a Facility which will auto-populate when events are performed at that Facility. Facility access must be autorized for each user in the Users section before a user can select that Facility in an Event. Facility, in Beacon, is another term for your Hospitals, ASCs, customers, etc. A Facility is where cases are performed and inventory is sold. |
Physician |
The primary physician associated with a case/Event record. These records are stored in the directory so they may be selected easily by drop-down menu during case/event creation. Store physician contact information, directory associations, and comments in the Physician record. Update: With the April 2022 release, multiple physicians may be assigned. |
Manufacturer |
The manufacturer(s) with inventory being used in the case. These records are stored in the directory so they may be selected easily by drop-down menu during case/event creation. Select all manufacturers that will have inventory used in the Event. |
Case |
The name of a surgical case, a type of Event Record in ConnectSx where inventory use or sales are recorded. The case also records the relevant data such as facility, physician, procedure, time, date, etc. This can appear in a device's detail page if it is associated with that case. This can also appear in the case schedule and case detail pages. Surgical cases are the most common type of Event and so you may observe us using the terms Event and Case interchangeably. So if you're confused, remember that Case = Event in most contexts. |
Event (or Case) Record |
The record created by scheduling a case. This record holds all case details and allows the user to add inventory that was used, add the case to a calendar, or request inventory from the distributor/manufacturer for use in the case. It can also store photos or notes. And houses the device usage ticket and purchase order number. Events are the main way that inventory is consumed in Beacon. This means surgical cases, inventory adjustments, stocking orders, sample orders, etc. all would be types of Events where inventory is removed, consumed, or decremented from your account. Some Events may be billed for, some may not. Surgical cases are the most common type of Event and so you may observe us using the terms Event and Case interchangeably. So if you're confused, remember that Case = Event in most contexts. |
Open (Event Status) |
An open case is a case that has been scheduled not been closed yet, which means it has not been reviewed, signed, or had a PO number recorded. The next status is Closed and is applied when the case is submitted for billing and the sales order is generated and shared. |
Closed (Event Status) |
A closed case is a case that has been performed and device use/Sales have been recorded. Following the Event, the record was reviewed, signed for, and closed. The Purchase Order number has not yet been added. After the case has been closed, the sales order is available for download and sharing. The next status is Completed and is applied when the PO number is added. |
Completed (Event Status) |
A Completed case is a closed case that has had the purchase order added to it.Once the PO has been added, the invoice is available for download and sharing. The next step is paying commissions and receiving payment from the provider, resulting in a status of Paid. |
Paid (Event Status) |
After an even has been completed, after payment has been received and commissions have been paid, the Case may be given the status of Paid. This is the final status in the Event workflow |
Mark Used Inventory |
This is where a user may record sales and other device usage information, which will update the status of the item (ex. Used, implanted, damaged, etc.), as well as adding the item to the Sales Order if it is billable. While primarily done in vTrakr by the sales user, This can also be done in the Console by admins and other roles. If an item is marked single-use it will be consumed from the User's inventory when the Event is closed, if it is marked as reusable it will be returned to the User's custody when the Event is closed. |
Add purchase order |
the final step of the case workflow for the sales user, the user will input the purchase order number received from the provider. This will change the status of the case from "Closed" to "Complete". While primarily done in vTrakr by the sales user, This can also be done in the Console by admins and other roles, or if the sales order was emailed to the facility a facility representative can click a link to add the PO # directly. |
Add to Calendar |
Function which allows a user to add a scheduled case record to their personal calendars on their devices. |
Anonymous Patient ID |
Allows the user to store information such as Patient name, record ID, date of birth, and a picture of the patient sticker. This information must be protected according to HIPAA standards, so we recommend only using this field to enter the Anonymous patient ID. |
Case Notes |
Any notes about the case, preparation or outcomes, surgeon preferences, etc. which will be stored in the case record. |
Stocking Order (event type) |
An event type for when inventory is sold to a Facility directly without an Event being scheduled. First the Stocking Order is completed, billed for, and the inventory becomes "Facility Stock". Then, at a later date the user may process Cases using the Facility stock to record its use in cases, without billing for it again. |
Sample (event type) |
You might use the Sample Event type when a piece of your inventory is given to a sales prospect for promotional or marketing reasons or perhaps if a device was used in a demonstration and is no longer sellable. |
Loan (event type) |
Loan can be used if an item or container is loaned to a provider or other sales rep. This will create a record that the inventory is loaned out. |
Damage (event type) |
If inventory is damaged and must be removed from your stock use this Event Type. |
Return (Event type) |
If Inventory needs to be returned to a vendor/supplier/manufacturer whether or not they are connected with your ConnectSx account, use this Event type. |
Subscription (event type) |
If your products are sold as a subscription to a provider this Event type can help you keep track. |
Trial (event type) |
If the product is part of a clinical trial, this event type will allow for the capture of critical data required in those activities. |
Other (event type) |
Use this Event type for any activity not covered by one of our other designations. If you have Event types you think should be added, drop us a line – we’re interested! |
Event ID # |
This is a unique identifier used to distinguish one event from another. Starting at 1 this counts up as you schedule more Events. |
Representative |
This is the user assigned to the Event - whether they scheduled it or not - typically this is the Sales Rep who will be present for the surgical case. They are the "owner" of the event and their details will appear on the billing documents. Additionally, the inventory available to be used the Event will correspond to the inventory in the custody or the representative selected or that the representative has access to (in distributorships with shared inventory). The representative assigned to the event also determines who earns commission on that Event - consider this when assigning Representatives. The organization may be selected as the representative in an event, but consider if there are sales reps who should be earning commission on the event. |
Device Labels |
You may upload images of device labels or stickers for inventory that was used in the event. |
Patient Sticker |
You may upload images of the patient sticker from the Event. |
Associated Containers |
Record which containers are being used in the event. This record will be stored in the Event details. If an item is used from a container that has not been assigned to the event, the container will be assigned automatically. |
Create Request |
You may create an inventory request from the Event detail screen. This will link the request to the Event so the manufacturer can see in context what the inventory being requested is for. |
Create Request from Recipe |
You may create an inventory request from the Event detail screen. This will link the request to the Event so the manufacturer can see in context what the inventory being requested is for. With this option though you may use a Request Recipe from the recipe's section, which allows you to save templates for commonly requested inventory to save time and effort when requesting inventory. |
Cancel Event |
You may cancel an event, which will change its Event status to "Cancelled". The details of the event will still be viewable under cancelled events, but any inventory assigned to that Event will be returned to their original custodians. |
Submit for Billing |
This is the action taken afer inventory has been marked on an Event. The representative will review the inventory, check event details, and collect signatures. Submitting the Event for billing changes the Event Status to "Closed" and makes the sales order available for sharing or download. |
Request Replenishment |
After an Event is Closed you may make a replenishment request. The workflow is the same as a typical request, but the inventory consumed in the Event is automatically added to the request, saving time in requesting restock. |
Sales Order Form |
The sales order is generated after the event is Closed and can be downloaded as a PDF or emailed from the platform. If sharing via email, the email address that auto-populates in the recipient field is fromt the primary billing contact in the Facility directory record. After the sales order is shared, the PO# must be added to the Event to bring the Event to a status of "complete" |
Generate Invoice |
After the PO# has been added, the invoice is available. The invoice can be downloaded as a PDF, downloaded as a .CSV, or shared via email. If sharing via email, the email address that auto-populates in the recipient field is fromt the primary billing contact in the Facility directory record. After the invoice is shared, payment is received and commissions are paid, the Event may be marked with a "Paid" status. |
Reopening an Event |
Once an event has been Closed, many details may not be edited. To make revisions to an Event, you may "Reopen" it. After revisions have been made, the Event must be closed and completed again as normal. |
Billable Total |
This figure, displayed in the Devices Used tab of a closed Event, reflects the total that will be on the sales order that you will bill to the Facility. This includes items sold and additional cost adjustments. This is not the number that commissions are calculated off of, however - Commissions do not take into account Additional Cost Adjustement line items. |
Additional Cost Adjustments |
These are additional ad-hoc charges you may add to an Event to be added to the sales order and counted in the billable total. The additional cost adjustments are not considered sales and will not show up in sales reporting or commission reporting. |
Item Status |
Items sold in a case should be given statuses reflective of their use, such as used, implanted, damaged, etc. If an item must be removed from an Event, change its status to "unused" and save the Event (if the event was already closed, it must be reopened). |
Invoice Paid |
Box checked when the Facility has paid the invoice and your org has received payment. Checking this and Commission paid will allow you to assign the Event status of Paid. |
Commission Paid |
Box checked when your organization has paid commission to the assigned representative. Checking this and Invoice Paid will allow you to assign the Event status of paid. |
Section: Inventory |
|
Manufacturer |
The entity creating and selling the device in question. If your organization is purchasing inventory from another manufacturer, but your Org name/info should appear on the sales order and invoice, the inventory should be created under your Organization as the manufacturer. |
Product |
The product line the device is associated with. This can also be thought of as brand name, or however you would like to manage your product categories. There are many ways you could organize your proudct catalog. For instance, you might opt to create a few general product lines (ex. Bone Screws, Shoulder Anchors, etc.), you could have one product line per brand name, or you could create product lines by size (3.5mm Bone Screws, 4.5mm Bone Screws, 5.5mm Bone Screws, etc.). |
Name |
The description of the device used in marketing and sales, so the deivce can be easily found and managed in the users inventory and event records. This should be an accessible name, but contain enough detail to ensure it can be distinguished from all other devices. Individual devices, by catalog number, are associated with Product Lines. |
Catalog Number |
Sometimes also known as Reference Number, Item number, or Produt Number. This number is used by the manufacturer to identify a device and is one of the primary ways of identifying/selecting an item in ConnectSx. It is used in ordering, billing, post-market surveillance, etc. Catalog numbers roll up to the product line. Items with the same catalog number can be further differentiated by lot number, expiration date, etc. |
Deactivate |
Option in device detail screen to deactivate a device, this is the closest equivalent to inventory deletion in ConnectSx. The device will not show in inventory searches unless the user selects the "Show Inactive" filter. The history and associated information of an inactive device can always be looked up and reviewed, but inactive items cannot be made "active" again. |
Inactive |
device status referring to devices that have been deactivated manually or already used in a previous case. The only way inventoy can become active again is to reopen the Event they were used in and change their status to "unused". |
Status |
Indicates if this device has been used, implanted, damaged, etc. Inventory items that have not been used have the status of "unused". |
Container |
A container is a type of inventory that holds other devices. This is the "Parent" item that houses your device or inventory. For instance, a surgical tray containing a group of devices, or a product's package that may have a different reference number than the item(s) held within. A container has a catalog number that identifies what it is and must be unique to differentiate the container from other contianers. |
Billable |
If a device can be billed for, i.e. it has a sale price, it should also have a billable status of "yes" or "billable". Commonly implants and biologics are considered billable, while surgical instruments are not since they are reused. If an item is marked billable, it will be added with a price to the Sales Order and charged for when it is marked as used in a case. |
Price |
This is the list price of the device. This price is overridden in an Event when the Facility has contract pricing loaded. |
Inventory |
These are medical devices or surgical trays (devices and containers), inventory is usually used to refer to devices plural, such as a body of inventory. |
Inventory Request |
(1). This is a request from the sales rep or distributor to their manufacturer organization to provide devices or inventory, often for a specific upcoming case. The organization admins will determine the inventory need and either fulfill completely, partially fulfill, or decline the request. Fulfillment of a request will result in a pending inventory transfer that the requester will need to accept in order to transfer custody of the inventory. (2). In other less-frequent cases, a manufacturer may make an inventory request of their external production facilities or 3rd party manufacturers, similar to a Purchase Order to purchase new product. Then, inventory receipt can be tracked and the inventory may be created as the inventory is received - however, the inventory will have to be created with the 3rd party as the manufacturer. If when the inventory is being sold, the billing documents should list the Organization as the seller, then it should be created under the Org. Manufacturer by import or manual creation. |
Transfers |
A record of a transfer of inventory custody from one user to another. Can be initiated ad-hoc or by fulfilling an inventory request. |
Pending Transfers |
An inventory transfer that has not yet been completed. Will need to be accepted or declined by the receiving user. |
Accepted Transfer |
A transfer that was accepted, completed, and the inventory has been transferred to the receiving user's custody. |
Declined Transfer |
A transfer that was rejected by the receiving user. A declined transfer requires the user to provide a reason for rejecting the transfer. A declined transfer is then given a HOLD Status which must be confirmed by the manufacturer before the inventory is returned to its original custody. |
Transfer HOLD |
When a transfer is declined it is given a HOLD status which must be confirmed by the manufacturer before the inventory is returned to its original custody. This allows for shipping time to pass and inventory to be checked in person before the inventory is put back into stock. |
Tags |
Tags are user defined search terms that can be created or deleted at will and are added to inventory items. They are fully searchable. Tags can be used to represent stages of a process, statuses that are not already available in the system, nick names, etc. Tags are a very flexible tool that can help you achieve goals in the system. |
Basic Search (Search field) |
Search field that allows you to search for inventory based on the reference number/catalog number, version/model, lot, or Tags |
Scan Barcode Button |
Allows a user to scan a barcode in order to search for a device, the device must exist in GUDID and the barcode data must be stored in ConnectSx. Additional options become available once a device is selected, like shipment status, sterilization status, or access support. |
Status |
Device's usage status: used, unused, implanted, in/out, damaged, missing, Facility Stock, other |
Type |
inventory type: device or container |
Expiration |
the expiration date of the device, if it has one. Notificaitons are sent when devices are nearing expiration. |
Only show devices without... |
This search filter allows you to easily search for items that do not have a UDI, Lot #, Container, or Event associated. |
Show Inactive (search field) |
search field allowing you to filter for devices that have been deactivated (equivalent of deleted) or already used in a previous case. |
Exclude all inventory involved in pending transfers |
This filter will only display inventory that is available for use or transfer and is not currently associated with a pending Transfer or transfer hold. |
Bill of Materials |
A list record of items (by catalog #) that belong in a given type of container, like a template or recipe. For instance, for all containers that match the Bill of Materials "Configuration A" they must contain devices "X, Y, and Z". These Bill of Materials are then assigned to containers and are used to determine Par Levels, Overstocks, and Shortages for said containers. A container only containing devices X and Z would display a shortage. |
Par Level |
Set in the catalog, this is how many of an item you want to maintain in your inventory, such as a safety stock level. You can run the par level report to see which items are near or below their par levels. Admins will receive notifications when an item falls below par. |
UDI (Unique Device Identifier) |
The UDI is a unique number regulated by the FDA, assigned to all devices (eventually) to allow their identification and ensure traceability from the manufacturer to the patient. It is comprised of two different identifiers: the first is the Device Identifier (DI) which is refers to the catalog number level (example - items with the same catalog number will have the same DI), and the Production Identifier (PI) which is on the lot number level (Example - items with the same catalog number but different lot numbers will have different PIs, and thus different UDIs despite them sharing a DI). When UDI is loaded for a device then its barcode can be scanned to pull up the device using the UDI. The UDI is parsed in the device detail screen and the contained information is populated, such as lot #, serial #, or expiration date. If these fields are included in the UDI they should not be mapped as additional columns in the import, they will be derived from the UDI when it is parsed. |
Device Identifier (DI) |
The device identifier is the first portion of the UDI and refers to all items from the same manufacturer that have the same catalog number. |
Production Identifier (PI) |
The production identifier identifies information about how and when the device was produced including, but not limited to: lot number, serial number, manufacture date, expiration date, etc. So, devices that share a DI may not share the same PI if they were produced at different times, and thus their UDIs will be different. ConnectSx does not store PI in its own field, but does store information related to the PI (Lot number, expiration date, serial number, etc.). Information that does not yet have a field in ConnectSx can be entered as Tags. |
Lot Number |
An identifying number assigned to a batch of goods, typically from the same production run, to identify when and how they were produced. Lot number should be recorded at the point of use to help identify it on the patient record. The Lot number is typically included in the PI portion of the UDI. The lot number may be mapped on inventory import, but if a UDI is loaded the system will parse the UDI to populate the lot number field. |
Serial number |
A unique identifying number assigned to a device to differentiate it from other products that may share the same catalog number or lot number. A serial number is unique to that individual unit. The serial number may be mapped on inventory import, but if a UDI is loaded the system will parse the UDI to populate the lot number field. |
Location |
The physical location of a device or tray, tied geographically using Google's API. An item must still have custody (as always), but this data point helps keep track of where the item is physically, such as if it was left at a hospital or a warehouse. Even though the custodian is responsible for the inventory, it is understood that it is stored at a particular location. |
Consignment Status |
Statuses assigned based on who has the device at a given time: posession, consigned, loaned, other. Often paired with a location, this can describe how a device or container is loaned out or consigned to a hospital even though it is considered in a sales rep's custody. |
Posession (Status) |
Consignment status indicating a device or container is in the custodian's posession. Inventory is always held in a user's custody (meaning ultimately they are accountable for it), but this status indicates whether it has been stored, loaned, consigned, etc. or if it is physically in the user's possession. If no consignment status is assigned a device is typically considered to be in the custodian's possession. |
Consigned (Status) |
Consignment status indicating a device or container is consigned to another entity's custody for an extended period of time. Inventory is always held in a user's custody (meaning ultimately they are accountable for it), but this status indicates whether it has been stored or consigned, etc. or if it is physically in the user's possession. |
Loaned (Status) |
Consignment status indicating a device or container is loaned to another entity for a short period of time, often carrying penalties for late return of product. Inventory is always held in a user's custody (meaning ultimately they are accountable for it), but this status indicates whether it has been stored, loaned, consigned, etc. or if it is physically in the user's possession. If an item is loaned out it may be assigned a due back date to ensure it is returned in a timely manner. |
Due Back Date |
This is a due back date you can set after you transfer inventory to the field, such as a loaner tray. This will notify a user as the due back date approaches to remind them to return it. A Due back date is reset or cleared after the item or container is transferred. |
Fulfill Inventory Request |
The ability/function of a manufacturer or admin user to fulfill an inventory request, from their sales or distributor users, using their existing body of inventory. Requests may be fulfilled completely, partially fullfilled, or declined. When a request is partially fulfilled the admin may return to it at a later date to complete its fulfillment. |
Deactivate |
The deacivate button/status triggers the inventory to become inactive. It is no longer able to be marked as used or any other status, and can no longer be transferred or interacted with. For all intents and purposes it becomes a static record. It can be searched for by filtering for inactive items. Items that are deactivated manually may not be reactivated, they would have to be rectreated to undo this deactivation. |
Import (Navigation Heading) |
This section of the console allows the user to import inventory data via spreadsheet, mapping specific column headings from that spreadsheet to specific inventory data fields in ConnectSx. |
Products (Navigation Heading) |
The products section of the console is where you may add and modify product line data. Every inventory item needs a product line, and the product line guides how inventory is requested in the field. |
Transfers (Navigation Heading) |
This is where transfers of inventory custody are initiated and managed. The transfers section of the console shows all open and past inventory transfers. Action can be taken from this section to initiate a transfer or to accept/decline a transfer. |
Requests (Navigation Heading) |
This is where Admins may go to view incoming inventory requests and fulfill them. The requests section of the console shows all open and past inventory requests. Action can be taken from this section to decline an inventory request or fulfill an inventory request. Admins may also create external inventory requests, meant to function like a PO to order inventory from their suppliers. |
Catalog (Navigation Heading) |
The catalog reflects each item that is included in your inventory at a catalog number level. It houses base item information for each catalog number and is tied to the product line. Similar to a lightweight Item Master. |
|
|
Directory |
|
Physician |
The physicians that will be performing cases where products will be sold. Create these records in the directory so they can be selected from drop-down menus when creating a case. Enter contact information and associated facilities, procedures, products, and comments. |
Facility |
The facilties, hospitals or ASCs, where cases will be performed and products will be sold. Create these records in the directory so they can be selected from drop-down menus when creating a case. Enter point of contact information and billing contact information as well as contract pricing. Facility, in Beacon, is another term for your Hospitals, ASCs, customers, etc. A Facility is where cases are performed and inventory is sold. |
Billing Contact |
The first billing contact entered for a facility is the contact that will auto-populate when you go to share a sales order or invoice via email. Be sure to pay attention to which contact or email address you are sending to - you are able to select from all of the contacts added to a given Facility using the drop down menu. |
Contract Price |
The pricing negotiated for certain faciltities. These prices will be loaded, by catalog number, to a faciltity record in a .CSV file. Contract pricing overides the base/list price on a sales order when that item is used in an Event with that Facility and is not editable by Sales Users. This pricing must be updated/edited in the facility directory record by Admins. |
Procedure |
The procedures that will be associated with each case. Create these records in the directory so they can be selected from drop-down menus when creating a case. |
Manufacturer |
The manufacturers who produce and provide sellable product. A Manufacturer using ConnectSx will often only have one (themselves) and will be represented by the Organization. Other organizations, such as distributors, may have many manufacturers in their directory. |
Facility Par Levels |
This feature is not fully functional yet, but will allow you to establish par levels for inventory at a given Facility. |
|
|
USERS |
|
Invitations |
Email invitations sent by the manufacturer or admin to link users with their account |
Add User |
You may add a user without sending them an invitation. When it is time for them to claim their account they can click on the "Forgot Password" link on the signin page of the console to send them an email allowing them to reset their password. |
Sales User |
A sales user primarily uses vTrakr and is able to create events, transfer inventory, request inventory, and manage inventory that is in their custody. Sales users may belong to distributorships and may (depending on the settings) share access to inventory in the custody of that distributor. |
Admin |
An Admin primarily uses the Console and is able to edit/manage all cases, inventory, users, recipes, and directory records associated with their organization. |
Distributor |
A distributor user uses the console and vTrakr and while they may create cases and make sales, they share certain similarities with Admin users. A distributor can take action on all cases and inventory in their custody or in the custody of their associated sales users. |
Operations User |
(Not currently active - under development) An Operations user is focused on managing inventory and the movement of inventory to support the caseload. They can add/edit directory record, can add inventory, can modify inventory, can transfer inventory, request inventory, fulfilli nventory, modify cases, etc. However, they cannot edit user accounts or modify organization settings. |
Finance User |
(Not currently active - under development) The finance user is focused on billing and shares certain permissions with that of an admin. A finance user may edit price information, add POs to a case, retrieve billing documents, read COG and Par level info, and can mark an event as Paid. |