Managing Reference Lists & System Settings

This chapter reviews the management of reference lists and other important system-level settings that affect the way incoming data from source systems is handled and displayed in the Commure Pro system. All of these functions are found on the System Management tab:

• ADT Visit Types: Indicate the various types of visits that can be created manually, as well as those that are interfaced from your source system, map those interfaced visit types to Commure Pro visit types, and possibly establish a default service site for each (see ADT Visit Types)
• Date Range Filters: Configure the various options that are available in the time-based filters list that let users choose the amount of patient data to display in the Patient Data Display area (see Date Range Filters).
• Export/Import of System Settings: For test environments only, import or export settings from the Institution, Department, or User tabs (see Export and Import of System Settings).
• Handheld Devices: View and edit details about provisioned handheld devices (see Handheld Devices).
• Mobile InterApp: Configure the parameters necessary to allow interapp communication between the Commure Pro Apple application, and other Apple applications (see Configuring InterApp Communication for Apple Devices).
• Reference Lists: Maintain lists of values, or code sets, that are used to keep track of various types of information (see Reference Lists)

• Relationships: Specify how users’ patient lists are populated based on provider-patient relationships (see Relationships)
• Commure Pro Visit Types: Set the parameters to use for each type of visit in the Commure Pro system. For example, determine which visit types should be included in the schedule; whether a visit type should appear in various reports of missing charges; and which visit type should appear as the “current” visit on providers’ patient lists (see Commure Pro Visit Types).
• PQRS Measures: Manage the PQRS measures for your organization, by editing the descriptions, questions, or answers for each measure. (see PQRS Measures).
• Purge Criteria: Define when various submissions and session logs are purged from the Commure Pro Application Server (see Purge Criteria).
• Vitals Edit: Rename, determine the sort order, or map vitals information that displays for each patient (see Vitals Edit).

​

Reference Lists

Reference lists are lists of values, or code sets, that help you keep track of various types of information. In order to use the Reference Lists option, the setting below must be enabled for the administrator. Only your Commure Pro representative can turn this feature on for a user. Admin - User - User Permissions - Level 0/1: Can Edit Code Sets (Reference Lists) To access the Reference Lists option:

1. Click the Admin tab, followed by the System Management tab.
2. Click the Reference Lists option.

You can page quickly through the codes sets (left pane) by clicking on either the Previous or Next buttons, or any of the numbered pages in between. Information that is typically captured in a reference list includes the following:

• Values for custom code set transaction headers, such as Injury Type, to be used in Charge Capture.
• Insurance data coming across the ADT feed, and the alias used to link it to code edits in the Charge Capture application.
• Sets of patient demographic information, such as medical services, coming across the ADT feed that should be tracked. Whether making additions or edits to reference lists, it is recommended that you purge your caches (including session and mobilizer cache) whenever you make any reference list changes. No server re-start is necessary when making modifications to reference list definitions. For more information, see Clear Web & Session Caches and Purge Mobilizer Cache.

​

Adding Entries to a Reference List

To add a new entry to a reference list:

1. On the Reference Lists screen, select the code set that you want to update. Its row, including the list name and System Identifier that the Commure Pro system uses for it, becomes highlighted.
2. Click the New Entry button. A new row is added to the bottom of the list of values.
3. Enter the following information for the new list item:
   • Name
   • System Identifier
   • Context
4. Click Save.

​

Editing Entries in a Reference List

To edit an existing code set:

1. On the Reference Lists screen, select the code set that you want to update. Its row, including the list name and the abbreviation that the Commure Pro system recognizes for it, becomes highlighted.
2. In the work area on the right side of the Reference Lists screen, edit the name, abbreviation, or context of the desired entry, observing the existing formatting and rules for that entry.
3. If you want to add an alias for the entry, click Edit in the Aliases column for that entry.
   1. In the Edit Aliases for <entry> dialog, click the Add Alias button.
   2. Enter an Alias and an Authority for the entry. Note that the aliases on this list are sorted alphabetically by default. Authority specifies the sending system (in other words, the source of the data). There can be several inbound interfaces coming from multiple sources.
   3. To delete an alias, click the X symbol to the right of it.
   4. Click OK to confirm your changes and dismiss the Edit Aliases dialog.
4. If you want to change the sort order of the list entries, click the Reorder icon that displays to the right of the New Entry button. The Reorder window displays the list as it is currently organized. Select an entry from the list and use the UP and DOWN buttons to change this entry’s positioning relative to the other list entries. Alternatively, you can use to TOP and BOTTOM buttons to move any list entry to the start or end of the list.

Continue selecting and moving entries using these four buttons until you arrive at the list order you want, then click the Ok button.

5. In the Reference Lists screen, click Save to save your edits. Or click Cancel Changes to revert your changes, then Yes to confirm that you want to cancel your edits and revert all changes.

​

Creating a Reference List

You can create a reference list (code set) which you can then access as a picklist when creating charge headers (see Add/Edit Charge Headers). To create a reference list:

1. Click the Add Reference List button. A dialog opens prompting you to name the reference list.
2. Type a name for your list, then click OK. The new name is added to the existing collection of reference lists.
3. Now you can treat it just like one of the existing reference lists. Follow the instructions for Adding Entries to a Reference List or Editing Entries in a Reference List

​

Deleting a Reference List

To delete a user-created reference list:

1. Click to highlight the list.
2. Click Delete Reference List.

​

Completed Status Reference List

The Completed Status reference list should be used in cases where the backend Laboratory Results system uses more than four statuses to indicate whether the processing of the laboratory result is finished. If your system uses four or less statuses, you can choose to instead map panel completion status using the Map Panel Completed Status option, found on the Institution tab, under Lab Results Settings (see Mapping Completion Status). However, if there is any possibility of the number of statuses increasing, it may be wise to use this option, as it allows for growth. Do not map completion statuses in both options; map them in either the Map Panel Completed Status option or in this Completed Status reference list. Some common examples of lab completion statuses are Pending, Preliminary, Unknown, and Final. These examples are listed in order from the least complete to the most complete status. In the Commure Pro system, a given panel can have one or more components, and each component within a panel has its own completion status associated with it. Many of the lab results displays on both the Physician Portal and on handheld devices show summarized information for the panel as a whole. In these cases, the system must determine the overall completion status for the panel. To do so, the system reviews each of the individual component statuses in the panel, and selects the “least complete” status as the panel’s overall completion status. In this option, you must prioritize the completion statuses from your backend Lab Results system, so that the overall completion status for a panel can be determined. Generally, the entries for Completed Status are automatically created when the interface to your backend Lab Results system is implemented. All you need do is edit the entry for each backend status, and modify the Name and numeric Sort Order (priority). For example, if your backend system uses five statuses, assign each status a sort order of 1 to 5, with 1 being used for the least complete status, and 5 being used for the most complete status. The fields for each status should be completed as follows: Name Enter the label you wish to be displayed to users in the various Commure Pro lab results display options. System Identifier This is the identifier for the status from your backend system; you should not make any changes to this field unless you have reason to believe it is incorrect. Sort Order: Enter the priority of the status, as described above. If you do not assign a Sort Order to a status, it is automatically assigned one of 0 (zero), which would be considered the “least complete” status. This might happen, for example, if a new status were implemented in your backend system, and you did not use this option to prioritize it

​

Service Site Types Reference List

The Service Site Types reference list comprises a list of all the types of sites where services can be provided to patients (service sites are also known as places of service). Keep in mind, these are general categories of service sites, not actual physical locations. There are four default service site types:Other, Inpatient, Outpatient, and Office. You can add more service site types if your organizations needs them. Using the Service Sites property on the Institution tab (under Charge Capture settings), you can then list the charge service sites from which you want users to select when entering charges. Each charge service site maps to a service site type from this reference list. You can keep a simple one-to-one relationship between charge service sites and service site types, or you can map several charge service sites to a single service site type. For example, North Inpatient and South Inpatient may be two different charge service sites, and therefore may be available as two separate choices when entering a charge, but you can map both of them to the single service site type Inpatient. Please refer to Configure Service Sites for more information. The Commure Pro system is pre-configured with several default service site types in the Service Site Types reference list, each of which has a numeric system identifier. For the default service site types of Other, Inpatient, Outpatient, Office, and Observation, the numeric identifiers are 0, 1, 2, 3, or 4, respectively. (These are the values that are typically sent over the interface). If your organization has enabled the standard Visit - Place of Service code edits, those code edits correspond to these numeric system identifiers. When a user enters a charge, they select a charge service site. The charge service site is mapped to a service site type as describe above. The Visit - Place of Service code edit then fires based on the numeric system identifier for the service site type associated with the charge transaction. However, if desired or necessary for the interface to your billing system, you can change the system identifiers for the default service sites to alpha values (such as IP for Inpatient). If you do so, be sure to deactivate the associated standard code edit (which uses the numeric identifier) and create a new custom code edit so that the new alpha identifier is associated with it. You can also add new service sites with either numeric or alpha values, and create custom code edits for them.

​

Source Reference List

If your organization plans to implement the Health Information Exchange (HIE) option so that users can view the sources from which clinical data are derived, you will need to configure the Source reference list. This reference list contains all sources from which data is derived, including system sources for dictionaries (such as drug databases) as well as sources of patient clinical data (such as outside hospitals). There two settings below allow users to filter clinical data by the source (hospital) from which it was derived: Admin - User - HIE - Filter on Source (Web) Admin - User - HIE - Filter on Source (Handheld) You can use the Context field to designate which sources from this reference list should appear in the users’ Source filter list. To include a source in the filter list, enter “HIE” or “hie” in the Context field. Typically, you would set the Context to “HIE” for all hospitals/organizations from which you derive patient clinical data, and also for the “MANUALLYADDED” entry, since this is the source that is used for problems (diagnoses) that are entered directly in the Commure Pro system. You should leave the Context field blank for system sources such as drug databases. To add “HIE” or “hie” as the context for a source:

1. Select Admin > System Management > Reference Lists.
2. Select the Source reference list. A list of sources appears on the right pane.
3. Enter “HIE” or “hie” in the Context field for all sources that you want to appear in the Source filter list.
4. Select Save to save your changes.

​

Date Range Filters

You can use the Date Range Filters option to configure the various choices that are included in the Timeframe drop-down list that lets users select the amount of patient data to display in the Patient Data Display area, as shown below. You can also configure a default value for the Timeframe.

1. Select Admin > System Management > Date Range Filters.
2. Configure the following options for each timeframe filter:
   • Include in Portal—Determines whether to include or exclude each option from the time-based filter list.
   • Default Value in Portal—Determines which option to display to users in the drop-down list by default. (You should select only a single option from this list.)
   • Sort Order—You can create a custom sort order by specifying sort order precedence in a numeric sequence, starting by entering the value 0 next to the option to display first in the list, 1 next to the option to display next, 2 for the 3rd item to display, and so on, until you specify a custom sort order for all options that have been configured to be included in the time-based filters list. Note that all list entries set to the value 0 retain their order as shown on the Date Range Filters pane, and display of these items takes precedence over the items configured with the numeric sequence 1, 2, 3, etc. For example, you might configure the system to display all the time-based filters except those that are older than one year in the past, with a default value of “Last 30 Days.” A site might choose to configure their system in this way if they perform a purge of all data that exceeds one year in the past. Here, users will see the selection “Last 30 Days” in the drop-down menu when they first visit the portal. You could then configure the sort order of items on the list to start with the option “Last 24 Hours”, followed by “Last 72 Hours”, and so on through the list items that specify 0 as the sort order. The top four entries in the list shown below will display at the end of the list, starting with “Most Recent 5 Visits” and ending with “Most Recent Visit.”

​

Relationships

In the Commure Pro system, a provider must have a relationship with a patient visit in order for that patient to appear on the provider’s patient list. For example, a provider might have a consulting relationship, or he might be the admitting, attending, or scheduled provider for the visit. The Relationships option allows administrators to specify how users’ patient lists should be populated based on those relationships, as well as whether or not users can manually remove visits with specific relationships. For an in-depth discussion of how the Relationships option can be used to do control these actions, please refer to Relationships Management. This section of the user documentation simply discusses the mechanics of the Relationships option itself. To access the Relationships option:

1. Click the Admin tab, followed by the System Management tab.
2. Click the Relationships option.
   • A list of all relationships appears on the right side of the screen.
3. Make your changes:
   • To set or unset any of the three flags for a relationship (ADT Autopopulate, Declarable, Removable), simply click the checkbox(es) that you want to change.
   • To change the sort order for one or more relationships, edit the number in the Sort Order column. The sort order affects the order in which the given relationship appears in the Relationship drop-down list when a user manually adds, sends, or gets a patient. A value of 0 means that it appears at the top of the drop-down list, a value of 1 appears in the second position, and so on. If there are several relationship types with the same sort order number assigned, they appear in random order at that position (e.g., several relationships with a sort order of 1 will all appear in random order after the relationship that was assigned a sort order of 0).
4. When you are done making your changes, click the Save button to save them. Or click the Cancel button to exit this option without saving your changes.

​

Commure Pro Visit Types

You can use the Commure Pro Visit Types option to set the parameters to use for each type of visit in the Commure Pro system. For example, you can determine which visit types should be included on the Schedule tab; whether a visit type should appear in various reports of missing charges; and which visit type should appear as the “current” visit on providers’ patient lists. There are two sets of default Commure Pro Visit Types that can be pre-loaded into the system as a starting point. You may modify these to suit your needs, or create additional visit types. The default visit types are: Commure Pro Visit Types appear in several places in the web interface:

• On the standard Patient Data Display, in the Visit summary list, in the Type column (the Patient Data Display is visible on the Patient List tab, or after clicking the Details button
• On the Patient Search tab, in the criteria section, as the Visit Type drop-down list (enabling you to search for visits of a specific type)
• On the Patient Search tab, in the results section, as the Type column (enabling you to view the visit type for each visit listed in the search results)
• On the Patient Search tab, after searching for a patient or visit and possibly selecting one, when clicking on the Add Visit button (enabling you to select the type of visit that you want to manually add)
• On the Patient Search tab, after searching for a patient or visit and finding no matches, the system displays a list of visit types (enabling you to manually register a patient and add a visit for them all in one step) Please note that the ADT visit types and Commure Pro visit types are interrelated. Each ADT visit type must be mapped to one Commure Pro visit type. Several ADT visit types can be mapped to the same Commure Pro visit type. If you want users to be able to manually register patients using a particular Commure Pro Visit Type, an ADT Visit type that has MANUALREG as a source must be mapped to that Commure Pro Visit type. Please refer to ADT Visit Types for more information on mapping visit types.

​

Adding or Editing Commure Pro Visit Types

As a general rule, it is recommended that you purge your caches whenever you make any changes to Commure Pro visit types. When editing existing visit types, you should purge both session cache and mobilizer cache. When adding new visit types, you only need to purge session cache, as purge of mobilizer cache occurs automatically when you add new Commure Pro visit type. For more information, see Clear Web & Session Caches and Purge Mobilizer Cache. In both cases, you should re-start the dispatcher after completing the process of adding or editing Commure Pro visit types. For more information, consult your Commure Pro representative. To enter a new Commure Pro visit type, follow these steps:

1. Click the Admin tab, followed by the System Management tab.
2. Click the Commure Pro Visit Types option.
3. Click the Add Commure Pro Visit Type button.
4. Enter the appropriate information for the new visit type in each of the attribute fields. Each field is described in the section entitled Defining the Attributes of Commure Pro Visit Types.
5. Click the Save button. Please be aware that the save process can take a few minutes, because the mobilizer cache is cleared behind the scenes as the new Commure Pro Visit Type is added.
6. After adding a new Commure Pro visit type, you must run Recalculate InFacility and restart the dispatcher (see Run InFacility Calculation). To edit an existing Commure Pro visit type, follow these steps:
7. Select Commure Pro Visit Types on the System Management tab.
8. Click on the Commure Pro visit type that you want to edit from the list in the left pane. The attributes of the selected Commure Pro visit type are displayed in the right pane.
9. Click the Edit button, located at the bottom of the right pane.
10. Enter or modify any attribute (except System Identifier) for the selected Commure Pro visit type. Each field is described in the section entitled Defining the Attributes of Commure Pro Visit Types.
11. Click the Save button to save your changes, or click the Cancel button to exit without saving.
12. After editing a Commure Pro visit type, you must run Recalculate InFacility and restart the dispatcher (see Run InFacility Calculation).

​

Deactivating or Reactivating Commure Pro Visit Types

You can deactivate a Commure Pro visit type if you no longer want it to be used. When you do so, any existing patient visits of that type must be transferred to a different Commure Pro visit type. To deactivate a Commure Pro visit type, follow these steps:

1. Select Commure Pro Visit Types on the System Management tab.
2. Click on the Commure Pro visit type that you want to deactivate from the list in the left pane. The attributes of the selected Commure Pro visit type are displayed in the right pane.
3. Click the Deactivate button, located at the bottom of the right pane. The following message appears: “Are you sure you want to deactivate the selected Commure Pro Visit Type?”
4. Click Yes to continue, or click No to exit without deactivating. The Move Visits and Map ADT Visit Types dialog appears.
5. All existing patient visits of this type must be transferred to a different Commure Pro visit type. In the Select Default Target field, select the new Commure Pro visit type to which you want to transfer the existing visits.
6. If any ADT visit types are mapped to this Commure Pro visit type, you must now select a different Commure Pro visit type to which they will be mapped. For each ADT visit type listed, select a visit type in the New Commure Pro Visit Type column. (See ADT Visit Types for more information on mapping.)
7. Click the Move button to deactivate the visit type and move its associated visits, or click the Cancel button to exit without making any changes. If you deactivate a Commure Pro visit type in error, you can reactivate it. However, this does not restore the visits that had been transferred to a new visit type when you deactivated the visit type. Those visits remain set as the new visit type. Activating a deactivated visit type simply enables it for use with new visits.
8. Select Commure Pro Visit Types on the System Management tab.
9. Click on the deactivated Commure Pro visit type that you want to reactivate. The attributes of the selected Commure Pro visit type are displayed in the right pane.
10. Click the Activate button, located at the bottom of the right pane. The following message appears: “Are you sure you want to activate the selected Commure Pro Visit Type? Note, this will not restore old visit types to existing visits.”
11. Click Yes to continue, or click No to exit without reactivating.

​

Setting a Default Commure Pro Visit Type

In the Commure Pro Visit Types option, you can specify one visit type as the default Commure Pro visit type. The values of the parameters on the default Commure Pro visit type are then used as the default values, or starting values, each time you create a new Commure Pro visit type. This feature allows you to quickly create several Commure Pro visit types with similar attributes (although you can still change the value of any parameter as needed for a specific visit type). Another reason for setting a default Commure Pro visit type relates to the mapping of ADT visit types to Commure Pro visit types. In a Commure Pro with Commure Pro Repository™ configuration, if the system receives an interface message for a visit type that is not listed in the ADT Visit Types option, it creates an ADT visit type automatically. Since every ADT visit type must be mapped to a Commure Pro visit type, you should set a default Commure Pro visit type to use in this event. Any auto-created ADT visit types are then automatically mapped to the default Commure Pro visit type. To set a default Commure Pro visit type, click the Flag icon next to the visit type that you want to set as the default. When prompted with the message “Are you sure you want to change the default visit type to [Commure Pro visit type system identifier],” click the Yes button. You will note that the flag changes from gray to red, indicating that it is now the default Commure Pro visit type.

​

Defining the Attributes of Commure Pro Visit Types

Each Commure Pro Visit Type can have the attributes listed below assigned to it. All attributes that contain “Charge Capture” in their label are applicable to only the Desktop Charge Capture and Mobile Charge Capture applications. The section entitled Sample Commure Pro Visit Types contains examples of some commonly used visit types and how the attributes might be set. Name Enter a descriptive name for this Commure Pro visit type, such as Inpatient Visit or Outpatient Appointment. This is a required field. System Identifier Enter an internal system identifier for this visit type. It is not visible to users anywhere except in this option. The system identifier must be unique (cannot be used for more than one Commure Pro visit type), and Commure Pro recommends that you limit it to one word (can be the same word as the Name). This is a required field. Use the following four fields to define a time frame for acceptable dates of service for the visit type, based on the start and/or end date of the visit. These settings affect the Charge Capture and NoteWriter processes on the web and Apple platforms. (Charge Capture, NoteWriter): Activate Date (Web, Android, Apple) To set a starting point for a date of service when entering charges or creating a note for this visit type, select the type of date on which the starting point should be based. You can base it on an admission date or a scheduled date. If there should be no limitations, leave this field blank. For example, for an inpatient visit, you would most likely set this field to Admit. (Charge Capture, NoteWriter): Activate Days (Web, Android, Apple) If you selected either Admit or Scheduled in the Charge Capture: Activate Date field, enter the number of days before the selected date, that should be considered as the earliest acceptable date of service for this visit type. Continuing the inpatient visit example above, you might set the activate days to 0, indicating that the earliest acceptable date of service is the admit date. If you set it to -1, then the earliest acceptable date of service would be the day before admission. The value must be between -30 and 0. (Charge Capture, NoteWriter): Deactivate Date (Web, Android, Apple) To set an end point for a date of service when entering charges or creating a note for this visit type, select the type of date on which the end point should be based. You can base it on a discharge date or a scheduled date. If there should be no limitations, leave this field blank. For example, for an inpatient visit, you would most likely set this field to Discharge. (Charge Capture, NoteWriter): Deactivate Days (Web, Android, Apple) If you selected either Discharge or Scheduled in the Charge Capture, NoteWriter: Deactivate Date field, enter the number of days after the Deactivate Date, that should be considered as the latest acceptable date of service for this visit type. Using an inpatient visit as an example, you might set Deactivate Days to 0, indicating that the latest acceptable date of service is the day of discharge (specifically, until 23:59 on the discharge day). If you set it to 1, the latest acceptable date of service would be the day after discharge. The value must be between -30 and 5000. In the case of NoteWriter, Deactivate Days may be used in conjunction with the following user preference: Admin - User - NoteWriter - # of Days Beyond Visit End to Allow Add/Edit Note This user-level preference defines the number of days after a visit is deactivated that a provider can create or edit a note. This is useful in cases where a provider needs to write a note or edit a draft note, but the patient has been discharged and now the visit is unavailable. In this scenario, the provider’s timeframe for writing or editing a note for that visit can be extended using this user preference. Let’s look at an example where we are writing a note for a patient who was discharged on January 28. If the Deactivate Days setting is 2 (meaning the visit is available for notes 2 days after the visit is deactivated), then a provider could create a note for the visit until January 30. However, if the Deactivate Days setting is 0, then the visit will be unavailable for notes after January 28 (the discharge date). In this example, an Administrator could extend the timeframe for that provider using this user preference. In the case of Charge Capture, the activate and deactivate fields are used in conjunction with the following two settings: Admin - Institution - Charge Capture - Check Validity of Service Date This institution-level setting determines whether the date of service allowed on a charge transaction should be limited based on the parameters you have defined in the charge capture activate and deactivate fields for the visit type. If Check Validity of Service Date is set to Yes, then the service date entered on a charge transaction must be within the visit type’s defined parameters. If it is not within the parameters, the user is not able to save the charge as a completed transaction. They must either change the service date to be within the acceptable date range, or save the charge transaction as a draft. If Check Validity of Service Date is set to No, then the service date a user enters on a charge transaction is limited by only the user-level setting listed next. Admin - User - Charge Capture - Allow Setting Service Date “n” Days before Today This user-level setting limits how far back a Level 3 user can back-date a charge. Let’s look at an example where today’s date is January 30, and we are entering a charge for a patient that was admitted on January 1 and discharged on January 28. Assuming charge capture activate and deactivate fields are set to allow service dates only between the admit and the discharge date of the visit, and Check Validity of Service Date is set to Yes, then a given user could only enter service dates of January 1 through January 28. If a particular user had their Allow Setting Service Date “n” Days Before Today field set to 5, then the earliest service date that user could enter would be January 25 (five days prior to today, January 30), and the latest service date they could enter would be January 28 (the discharge date). Charge Capture: Allow Multi-Day Copy and Add (Web, Apple) This setting determines whether users are able to apply the charges they are entering on the Charge Transaction screen to multiple service dates, when entering charges against visits of this type.

• When this setting is checked, the user is able to enter multiple dates or date ranges on charge transactions entered against visits of this type. The service dates can be consecutive, or not, as appropriate for the charges they are entering. Upon saving, the application checks to ensure that the selected dates or date ranges fall within billable window that is configured for the visit. Please note that the user must also have the following setting in their user profile set to Yes:

Admin - User - Charge Capture - Enable Multi-Day Charge Entry

• When this setting is not checked, the user is able to enter only a single service date on charge transactions entered against visits of this type.

Charge Capture: Check Per Day (Web) This setting determines whether a charge status should be calculated for only the first day of the visit, or for multiple days. The charge status information is shown in a variety of displays including the following: The default value is enabled (checked).

• In Desktop Charge Capture, on the Patient Charge Status sub-tab (located under the Charges tab), it shows charge status for visits in the context of the user’s patient list. When the Charge Capture: Check Per Day field is left unchecked, the visit is represented as a single button. When the field is checked, the visit is represented by multiple buttons (one for each day of the visit), from the visit start date to the visit end date. If there is no end date associated with the visit (no discharge date), the buttons or icons continue through today’s date. Users can see the charge status for each day of the visit, and if charges have not been entered for a particular visit day, they can click on the button to enter them.

• In Desktop Charge Capture, when Show Visits is checked in the Charges display option; it shows the charge status for visits, in the context of a single patient’s list of visits. When the Charge Capture: Check Per Day field is left unchecked, the visit is represented by a single row. When the field is checked, the visit is represented by multiple rows (one for each day of the visit), from the visit start date to the visit end date. If there is no end date associated with the visit (no discharge date), the rows continue through today’s date. If no charges have yet been entered for a particular day, users can click an Add link to enter them.

• If your organization has implemented the Commure Pro-Cerner Charge Capture app, then your users can click a link in the Cerner® application to access the Commure Pro Charge Transaction screen in order to create or edit a charge. When using this feature, diagnoses from the Cerner visit can be automatically defaulted into the Selected Codes section of the Charge Transaction screen.
  • When the Charge Capture: Check Per Day property is checked, the visit is considered a “multi-day” visit. If defaulting is enable for the user for multi-day visits, then there is specific logic that determines which diagnoses from the Cerner visit should be automatically defaulted into the Selected Codes section.
  • When the Charge Capture: Check Per Day property is left unchecked, the visit is considered a “single-day” visit. If defaulting is enable for the user for single-day visits, then the app simply defaults all diagnoses from the Cerner visit into the Selected Codes section. Please note that this is only one of several settings necessary to configure the Commure Pro-Cerner Charge Capture app. See Configuring the Commure Pro-Cerner Charge Capture App for complete instructions and for more information on the diagnosis defaulting logic.

In the case of an inpatient visit, most likely you would check the Charge Capture: Check Per Day property, so that each day of the visit is shown in the various displays and so that it is considered a “multi-day” visit. For a typical outpatient appointment, most likely you would not check the Charge Capture: Check Per Day property, resulting in only one visit day (the appointment date) being shown in displays, and the visit being considered a “single-day” visit. Charge Capture: Date of Service Default (Web) Indicate whether a date of service should be defaulted when creating or copying charges for this type of visit, and if so, what the default should be. When creating a new charge, this default is used only if the user clicks a general Add Charge button/option that does not concretely identify a specific visit date. Your choices are:

• None: nothing should default in the Date of Service field. (This is the default setting.)
• Today: today’s date should default in the Date of Service field.
• Visit Start: the start date for the visit should default in the Date of Service field. For visit types that have an admit date (such as inpatient visits), the admit date is defaulted. For visit types that have only a scheduled date (such as outpatient appointments), the scheduled date is defaulted.

Admin - User - Charge Capture - Default to Today for Service Date (Inpatient Only) Charge Capture: IMO Primary Diagnosis Checking: Visit Mapping (Web, Android, Apple) Each diagnosis in the IMO database has a flag that indicates whether the diagnosis is not recommended to be listed as the primary diagnosis for the charge transaction. The flags are based on visit type and indicate whether the diagnosis is not recommended as the primary diagnosis on inpatient visits, outpatient visits, or all visits. The Commure Pro application shows a warning message to the user when such a diagnosis is used in the primary position, if appropriate for the type of visit. With this setting, you must specify how the application should treat this type of visit, when determining whether or not to show a warning message to the user. Your choices are:

• All: (the default) Show a warning for all diagnoses that have a flag indicating that they are not recommended to be in the primary position. Diagnoses flagged in the IMO database as not recommended in the primary position for inpatient visits, outpatient visits, or all visits, will display a warning message to the user. This is the default setting, so that if you have not yet configured this option, a warning message will be shown to users for all diagnoses that have a non-primary flag.
• Inpatient: Treat this visit type as an Inpatient type of visit with respect to diagnoses not recommended to be primary. Diagnoses flagged in the IMO database as not recommended in the primary position for inpatient visits or all visits, will display a warning message to the user.
• Outpatient: Treat this visit type as an Outpatient type of visit with respect to diagnoses not recommended to be primary. Diagnoses flagged in the IMO database as not recommended in the primary position for outpatient visits or all visits, will display a warning message to the user.
• None: Treat this visit type as neither inpatient nor outpatient. Only those diagnoses flagged in the IMO database as not recommended in the primary position for all visits, will display a warning message to the user. You might select this option for a visit type that is neither inpatient nor outpatient, such as “Pre-Registration.” When a user selects a non-primary diagnosis as the primary diagnosis for a charge transaction, and the visit type is configured to display a warning (based on the settings above), a Red Exclamation icon is displayed next to the diagnosis. The user may hover their cursor over the exclamation mark to see the following message: “Please ensure that your primary diagnosis reflects the reason for your encounter. If no other diagnosis exists, continue with this selection.”

Charge Capture: Include Appt in Missing Charge Filter (handheld only) (Apple) This setting is no longer supported as of Commure Pro version 8.2.0. On handheld devices running Mobile Charge Capture, the Patient List tab can be configured to display a filter (called the Missing Charge Filter) that selects only those visits from the user’s short patient list that have not yet had any charges posted against them (by any provider). This functionality works only with visit types that have a scheduled date associated them, such as might be the case with an outpatient visit. Check this box if visits of this type should be selected by the Missing Charge Filter. Charge Capture: Include in Patient Charge Status (Web, Android, Apple) There are several displays that indicate whether or not charges have been posted against each day of a given visit. All of these display options show the patient’s “charge status” as it relates to their visits. If a particular visit day does not yet have charges entered, all of these options provide mechanisms for providers to easily enter charges directly from the display.

• In Desktop Charge Capture:
  • The Patient Charge Status sub-tab (located under the Charges tab).
  • The Charges display option, when Show Visits is checked.
• In Mobile Charge Capture:
  • In the Patient List module, when Charge Capture Status is displayed in the right-hand column.
  • In the Charge Capture module main view. Check this box if you want visits if this type to be included in the above displays, so that users can see the charge status for the visit, and potentially enter charges. This setting works in conjunction with the Charge Capture: Check Per Day setting.

For typical outpatient and inpatient visits, most likely you would check this field, so that they would be included in the above displays. However, you might leave this field unchecked for emergency room or pre-registration visits, depending on whether you wanted them listed in these displays that are commonly used by providers. Charge Capture: Include Not Coded in Worklist/Search/Schedule (Web) The Worklist and Search tabs in the Desktop Charge Capture application are used to review visits with various charge statuses. The Schedule tab is used to view the daily schedule of visit types that have a Scheduled Date (typically outpatient visits). If a visit has not yet had any charges entered against it, it is called a “not coded” visit. Check this box if visits of this type that are “not coded” should be included on the Worklist, Search, and Schedule tabs. The default value is disabled (un-checked). Charge Capture: Name for Not Coded Filter on Worklist/Search/Schedule (Web) This field appears only if the Charge Capture: Include Not Coded in Worklist/Search/Schedule field is checked, and is a required field in that instance. When not coded visits of this type appear on the Worklist and Search tabs, you can use a filter to selectively view those not coded visits. Enter the name that you would like to use for the filter that appears on the Worklist and Search tabs. Whatever you enter here is always preceded by the words “Not Coded.” For example, if you enter “Outpatient” in this field, the filter label will be “Not Coded Outpatient.” On the Schedule tab, there is no filter for the not coded visits. However, every not coded visit is displayed with a charge status of “Not Coded.” Whatever you enter here is added as a suffix to the charge status for the not coded visits (of this type) on the Schedule tab, such as “Not Coded Outpatient.” Be careful not to use the same value for this setting for different visit types. Charge Capture: Notify on Add Charge if Existing Transaction for Visit/Date (Web) This setting determines whether the user will see a warning message when they attempt to create a new charge transaction for a visit date that already has an existing charge transaction, when entering charges against visits of this type. You may want to enable this setting in billing scenarios where multiple users all enter their charges on a single transaction (as is often the case when Custom Charge Capture Screens are implemented).

• When this setting is checked, and a transaction already exists for the visit date (for visits of this type), the application then checks the setting below in the user’s profile: Admin - User - Charge Capture - Prompt to Edit Transaction if Visit/Date is Coded
  • If set to Yes, prompt to create new or edit, and the current user has the appropriate permissions to edit the existing transaction, then the user is warned that another transaction for this date already exists and is offered choices to either edit the existing transaction or create a new one. When confirming whether the existing transaction may be edited by the current user, all of the standard editing rules are applied, briefly summarized here:
    • The user must be able to view the existing transaction, based on the settings below: Admin - User - Charge Capture - Set Patient List Charge View Access
  Admin - User - Charge Capture - Set Charge Desktop View Access
  • If the existing transaction was created by a different user, the setting below must be set to Yes: Admin - User - User Permissions - Level 2 / 3: Can Edit Other Users’ Charges
  • If the existing transaction is in the Outbox, the setting below must be set to Yes: Admin - User - Charge Capture - Allow User to Edit Charges in Outbox
  • Today’s date cannot exceed the number of day specified in the setting below: Admin - User - Charge Capture - Allow Editing a Charge “n” Days after Visit End
  • If set to No, create new, or if the current user does not have the appropriate permissions to edit the existing transaction, the user is not warned of the existing transaction and always creates a new one.
• When this setting is not checked, and a transaction already exists for the visit date (for visits of this type), the user is never warned that a transaction exists, and always creates a new one (regardless of how their user profile is configured).

Charge Capture: Remove Visit from Schedule and Charge Reports With a Single Charge (Web) Use this setting to indicate at what point visits of this type that are not coded (have no charges entered) should be removed from the Schedule, Worklist, Search, Missing Charges, and Charge-Note Reconciliation tabs. The default value is enabled (checked). For visits on the Worklist, Search, Missing Charges, and Charge-Note Reconciliation tabs:

• If this setting is checked: Initially, visits of this type will appear with an Add Charge link on the above tabs for all providers who have a relationship to the visit. When any provider enters a charge transaction for the visit (with their name as the billing provider), the visit no longer appears with an Add Charge link on these tabs for all providers who have a relationship to the visit. Instead, it appears as a coded visit (with a link to the entered charges).
• If this setting is not checked: Initially, visits of this type will appear with an Add Charge link on the above tabs for all providers who have a relationship to the visit. The visit remains with an Add Charge link on the above tabs until each provider enters a charge transaction for that visit (with their name as the billing provider). If any provider enters a charge with their name as the billing provider, the Add Charge link continues to display for the other provider(s) who have a relationship to the visit, in addition to a link for the entered charge (for the first provider). An example of when you might configure the parameter in this manner is when you have co-surgeries with multiple scheduled providers. By leaving this option unchecked, each surgeon will be able to easily enter his or her own charge(s).

For visits on the Schedule tab:

• If this setting is checked: Initially, visits of this type will appear with a Not Coded link on the Schedule of providers who are the scheduled provider for the visit. When any provider enters a charge transaction for the visit (with a billing provider who either is or is not the scheduled provider), the visit no longer appears with a Not Coded link on the Schedule of the provider who is listed as the scheduled provider for the visit. Instead, it appears as a coded visit (with a link to the entered charges).
• If this setting is not checked: Initially, visits of this type will appear with a Not Coded link on the Schedule of providers who are the scheduled provider for the visit. The visit remains with a Not Coded link until that provider enters a charge transaction for that visit (with their name as the billing provider). If a different provider enters a charge with their name as the billing provider, the Not Coded link continues to display for the scheduled provider, in addition to a link for the entered charge (for the other provider).

Charge Capture: Update Charge Diagnoses When Editing Charge in Cerner App If your organization has implemented the Commure Pro-Cerner Charge Capture app, then your users can click a link in the Cerner® application to access the Commure Pro Charge Transaction screen in order to create or edit a charge. When editing an existing charge, this setting determines whether the diagnoses listed in the Selected Codes section of the Charge Transaction screen are replaced with the current list of diagnoses associated with the visit in Cerner. This can be helpful when multiple providers are involved in entering the charge, and there is a time lag between when the charge is initially created by one person, and later edited by another person (and additional diagnoses are entered during that time lag). However, if a charge is edited days into an Inpatient stay, the current diagnosis list in Cerner may not reflect the appropriate diagnoses for the service date of the charge. Therefore, it is recommended that this setting be enabled only for visits that last a single day, such as Outpatient or Day Surgery. This setting does not affect how diagnoses are handled when creating a new charge transaction.

• Yes: When editing an existing charge, the diagnosis codes currently associated with the visit in Cerner completely replace the set of diagnoses that were previously entered in the Selected Codes section on the charge transaction.

• No: When editing an existing charge, the diagnoses that were previously entered in the Selected Codes section on the Charge transaction remain unchanged. Please note that this is only one of several settings necessary to configure the Commure Pro-Cerner Charge Capture app, see Configuring the Commure Pro-Cerner Charge Capture App for complete instructions.

CPOE Deactivate Days (Web, Android, Apple) This setting controls how long after the current visit end date that visits of a specified type remain available for order entry. On the web application, the Patient List tab displays the user’s patient list. This list contains basic information about the patient, such as name and age, and also shows information about the patient’s current visit. Similarly, on the handheld, the Patient List module displays the location of the patient’s current visit. In cases where a patient has more than one recent visit, the system must determine which visit should be displayed in these options as the patient’s current visit. Each organization can define which visit is selected for the displays. Let’s take a look at an example. Let’s say a patient is currently admitted in the hospital, and also has an upcoming outpatient appointment scheduled for tomorrow. Some organizations might want to display the upcoming outpatient appointment on provider’s list, while other organizations might want to display the current inpatient visit. The following four fields allow you to determine which visit is selected, by ranking this visit type in relation to the other visit types defined for your organization: Current Visit: Start Date (Web, Android, Apple) For this visit type, select the date that should considered the visit’s start date. Your choices are Admit, Scheduled, or Discharge. Current Visit: End Date (Web, Android, Apple) For this visit type, select the date that should considered the visit’s end date. Your choices are Admit, Scheduled, or Discharge. Current Visit: Relative Ranking (Web, Android, Apple) This is used to determine what visit to auto-select when adding an order in CPOE. Enter a numeric value to rank this visit in relation to all of the other visit types defined by your organization. A rank of 1 is the highest possible rank. Using the first example above, if this were the outpatient visit type, and you wanted it to be selected over the inpatient visit type, you would give it a rank of 1. The inpatient visit would be given a rank of 2 or lower. You may assign the same rank to more than one visit type, if they are equally important. Current Visit: Exclude if no relationship (Web, Android, Apple) Check this box if you want visits of this type to never be selected as the current visit if the user does not have a relationship to it. For example, if you never want an Outpatient Visit to be selected as the current visit if the user does not have a relationship to it, you would check this box. How does the current visit calculation work? Based on the four settings above, all of the patient’s visits are reviewed. First, the provider’s relationship to the visits are examined. If the Current Visit: Exclude if no relationship field is set to Yes for any of the visit types on the list, and the provider does not have a relationship to a visit, it is automatically excluded as the current visit. Next, the dates of the visits are considered and the closest one to today is chosen, with past dates chosen over future dates. If there is more than one visit tied for the closest visit, then the Current Visit: Relative Ranking of the visit type is used to determine which should have priority. Finally if the provider has a relationship to one and not another, the one with which they have a relationship is chosen. If after all this, there are still two or more visits that are tied (for example, two visits with the provider on the same day), the one that was received first by the system is chosen. Current Visit: Auto-select visit (Add Charge, Add Note) (Web) This field determines whether visits of this type can be auto-selected by the system, when a user selects either “Write Note” or “Add Charge” from the Actions drop-down menu. Your choices are:

• Always: Select this option if you want all visits of this type to be considered for auto-selection.
• Only With Relationship: Select this option if visits of this type should be auto-selected only in cases where the user who is entering the charge or note has a relationship to the visit.
• Never: Select this option if you never want visits of this type to be auto-selected.

The auto-select option takes effect only if:

• the visit type allows it (determined via this option) and
• if the setting below is set to Yes for the user who is entering the charge or note: Admin - User - Patient List - Auto-select visit during “Add” Activities How does the auto-select feature work? When a patient has more than one visit, the system must first determine which visits are “eligible for selection” by the user who is attempting to enter the charge. Whether or not a visit eligible is based on the following two settings in the user’s profile. Admin - User - Charge Capture - Allow Editing a Charge “n” Days after Visit End This setting determines how many days past the visit’s end date (typically, the discharge date or scheduled date), that a Level 3 user may enter or edit charges. Let’s look at an example where this field is set to 5. For visits that have admit and discharge dates, only visits that are currently still admitted, or that have been discharged within the last 5 days, would be considered eligible. Or for visits with a scheduled date, only those visits with a scheduled date within the last 5 days would be eligible.

Admin - User - Charge Capture - Allow User to Add Charges for Future Dates (Web Only) For most users, future visits are not considered “eligible for selection.” However, when this preference is set to Yes, it allows a user to enter charges in advance of the visit’s admit or scheduled date. For example, a billing administrator might pre-enter the charges for a surgery that is scheduled for the next day. Once the system has determined which visits are eligible for selection, it then determines if it should auto-select visits, based on the user’s Auto-Select Visit During “Add” Activities setting. If it is set to No, it just displays a list of the eligible visits. If it is set to Yes, it attempts to auto-select a visit from the list of eligible visits.

• If there is only one eligible visit, it is selected.
• If there is more than one eligible visit, the system next determines which visit types in the list can be auto-selected.
  • Visit types that have Always are considered for auto-selection.
  • Visit types that have Only With Relationship are considered for auto-selection if the user has a relationship to the visit. If the user does not have a relationship, it is not selected.
  • Visit types that have Never are never considered for auto-selection.
• From the remaining visits that are potential candidates for auto-selection, the system now selects the visit that it considers to be the “current visit.” See How does the current visit calculation work?.

Display Discharged in Location (Web) Check this box if you want the word “Discharged” to display in addition to the last known location (facility/room/unit), once the patient has been discharged. This parameter is only applicable if the visit type has a discharge date associated with it. Enable CPOE (Web, Android, Apple) Determines whether visits of the selected type are included among the visits available to the CPOE application. Handheld Label (Android, Apple) Enter a short name for this Commure Pro visit type (Commure Pro recommends limiting it to five characters or less). This abbreviation is used when displaying the Commure Pro visit type on a handheld device. The handheld label is visible in the Charge Capture module, as an abbreviation that precedes the visit date information. Include all visit dates in PLv2 Time-Based Criteria (Web) Check this box if you want all standard visit date options (Admit, Scheduled, and Discharge) to be available as Time-Based Criteria when creating or editing a patient list. This overrides the default of using the Start Date and End Date that is selected for each Visit Type. When disabled, only the Start Date and End Dates specified for each Visit Type are displayed as Time-Based Criteria. Include in Schedule (Web) Check this box if you want visits of this type to appear on the Schedule tab (this tab is available only in Desktop Charge Capture). Only visits that have a scheduled date associated with them can be displayed on the Schedule tab. InFacility Type Visit (Web, Android, Apple) Determines whether the selected visit type qualifies as an InFacility visit. This assignment is used to determine visit eligibility. Under the standard rules for determining visit eligibility, visits that are within 30 days of the calendar date of the patient encounter are selected to display on the Patient List, provided these visits belong to a qualifying Commure Pro visit type (one that has been defined as an ‘InFacility’ visit type). The following four settings determine when this visit type should be added or removed from the patient list cache, which is used to improve performance when loading patient lists, as well as other activities involving patient lists. PLv1 Short List: Add Date & PLv2: Add to Cache (Web, Android, Apple) Select the date that should be used as the basis for determining when to add this visit type to the patient list cache for PLv2 users. Your choices are Admit and Scheduled. For example, for an inpatient visit type, you would most likely base it on the Admit date, while for an outpatient visit type, you might base it on the Scheduled date. PLv1 Short List: Add Days & PLv2 Add to Cache (Web, Android, Apple) Enter the number of days, relative to the PLv1 Short List: Add Date & PLv2 Add to Cache, that a visit of this type should be added to the patient list cache for PLv2 users. A zero indicates it should be added on the PLv1 Short List: Add Date & PLv2 Add to Cache, while a negative number indicates it should be added this number of days before the PLv1 Short List: Add Date & PLv2 Add to Cache. Continuing the example above, if you were defining an inpatient visit type, and your PLv1 Short List: Add Date & PLv2 Add to Cache were set to Admit, you might enter -3 here. This would result in inpatient visits being added to the patient list cache 3 days prior to their Admit date. The value must be between -30 and 0. PLv1 Short List: Remove Date & PLv2 Remove from Cache (Web, Android, Apple) Select the date that should be used as the basis for determining when to remove this visit type from the patient list cache for PLv2 users. Your choices are Admit, Scheduled, Discharge, or Never. For example, for an inpatient visit type, you would most likely base it on the Discharge date, while for an outpatient visit type, you might base it on the Scheduled date. If you do not want the visit type to ever be removed from the patient list cache, select Never. You might set the field to Never for a Recurring Visit, such as might be used in the case of dialysis patients. PLv1 Short List: Remove Days & PLv2 Remove from Cache (Web, Android, Apple) Enter the number of days, relative to the PLv1 Short List: Remove Date & PLv2 Remove from Cache, that a visit of this type should be removed from the patient list cache for PLv2 users. The value must be between -1 and 500. Continuing the example above, if you were defining an inpatient visit type, and your PLv1 Short List: Remove Date & PLv2 Remove from Cache, were set to Discharge, you might enter:

• A value of -1: This results in removal at the moment of discharge.
• A value of 0: This results in removal at the end of the day, on the day of discharge.
• A value of 1: This results in removal at the end of the day, 1 day after discharge.
• A value of 5: This results in removal at the end of the day, 5 days after discharge.

Visit Detail Display Type (Web) This setting determines how this visit type is displayed on the Visits display option, and also determines the manual registration screen that is used when this visit type is manually registered. Select the Visit Detail Display Type that best suits the needs for this visit type. Your choices are: Inpatient, Outpatient, Pre-Reg, and Recurring. Each Visit Detail Display Type is described below. However, please note that the descriptions below do not contain an exhaustive list of fields on the displays or manual registration screens; they simply point out the fields that differ between each type. If necessary, the manual registration screens can be customized to suit your organization’s needs.

• Inpatient: This display is based on the assumption that an admit date, and eventually a discharge date, are associated with the visit type.
  • The summary portion of the Visits display option shows the admit date/time and discharge date/time in the Arrival and Discharge columns, respectively. The Provider column displays the attending provider.
  • The detail portion of the Visits display shows the Arrival Date, Discharge Date, Admitting Diagnosis, Length of Stay, Discharge Diagnosis, and Discharge Disposition.
  • The manual registration screen contains fields for Admit Date/Time, Discharge Date/Time, Admitting Diagnosis, Discharge Diagnosis, Discharge Disposition, Admitting MD, and Attending MD (as well as several other provider fields).
• Pre-Reg: This display type is based on the assumption that an admit date, and possibly a discharge date, are associated with the visit type.
  • The summary portion of the Visits display option shows the admit date and discharge date (if available) in the Arrival and Discharge columns, respectively. The Provider column displays the attending provider.
  • The detail portion of the Visits display shows the Arrival Date, Discharge Date (if available), and the Admitting Diagnosis.
  • The manual registration screen contains fields for Admit Date/Time, Discharge Date/Time, Admitting Diagnosis, Admitting MD, and Attending MD (as well as several other provider fields).
• Outpatient: This display type is based on the assumption that the visit lasts only one day, and has only a scheduled date.
  • The summary portion of the Visits display option shows the scheduled date/time in the Arrival column and nothing in the Discharge column. The Provider column displays the scheduled provider (if available, otherwise the attending provider is displayed instead).
  • The detail portion of the Visits display shows the Appointment Date/Time and the Reason for Visit.
  • The manual registration screen contains fields for Appointment Date/Time, Reason for Visit, and Scheduled MD (as well as several other provider fields).
• Recurring: This display type is based on the assumption that the visit has a start date, but possibly no end date, and although the visit can occur on multiple days, those specific dates are unknown.
  • The summary portion of the Visits display option shows the start date and end date (if available) in the Arrival and Discharge columns, respectively. The Provider column displays the scheduled provider (if available, otherwise the attending provider is displayed instead).
  • The detail portion of the Visits display shows the Start Date, End Date (if available), and Reason for Visit
  • The manual registration screen contains fields for Start Date/Time, End Date/Time, Reason for Visit, and Scheduled MD (as well as several other provider fields). Several of the following settings are visible in only a Direct Integration to MEDITECH® with Downtime Solution configuration. These settings all contain the word “Bridge” in their label, and they affect how far into the past and future that information should be retrieved from the MEDITECH system, for each visit type. Information is retrieved from the MEDITECH system via the Commure Pro-MEDITECH Bridge™, which is an interface of data from MEDITECH to the Commure Pro Repository™.

Bridge: Poll Ahead Days (Web, Android, Apple) Enter the maximum number of days forward that the Bridge should look for visits of this type, to pull into the Commure Pro system. Visits that are further in the future are not stored or displayed in the Commure Pro system. The value must be between 0 and 60. Bridge Poll Back Days (Web, Android, Apple) Enter the maximum number of days backward that the Bridge should look for visits of this type, to pull into the Commure Pro system. The value must be between 0 and 731. This preference is meaningful only the first time the Bridge is run. Subsequently, it will poll for the number of days since the Bridge last ran. Bridge: Visit Start Date (Web, Android, Apple) Select the date that the Bridge should use as the basis for determining the beginning of the visit, when polling MEDITECH for clinical data. Your choices are Admit and Scheduled. For example, for an inpatient visit type, you would most likely base it on Admit date, while for an outpatient visit type you might base it on Scheduled date. Bridge: Visit End Date (Web, Android, Apple) Select the date that the Bridge should use as the basis for determining the end of the visit, when polling MEDITECH for clinical data. Your choices are Admit, Discharge, and Scheduled. For example, for an inpatient visit type, you would most likely base it on Discharge date, while for an outpatient visit type you might base it on Scheduled date. NoteWriter: Date of Service Default (Web, Apple) Use this setting to determine the method to be used to obtain the date to display on a provider’s progress notes. You can configure this setting to use the current date and time as the default value to display on the note (“Today”), or you can configure the setting to use the de-activate date for the specified visit type as set in the Charge Capture application (“Visit End”). When no de-activate date is specified, the system defaults to the current date and time. Override Default Location Display (Web, Android, Apple) By default, when visits are included in a display, the location (facility/room/unit) is also displayed. If this visit type does not have a location associated with it, such as might be the case for an outpatient visit or a recurring visit, check this box to override the default display. In its place, a substitute label is displayed. When you check this box, an additional field appears: enter the substitute label that you want to use in this field.

​

Sample Commure Pro Visit Types

The table below illustrates the default settings that are associated with each visit type when they are initially installed at a client site. Please note that these are only default settings, and if necessary, you can change the attributes based on your own organization’s needs and requirements. You can also create additional visit types, if needed.

​

ADT Visit Types

The ADT Visit Types option lets you define the various visit types that are interfaced from your source system or that can be manually registered directly in the Commure Pro system, and map each one to a visit type from the Commure Pro Visit Type list. Before attempting to add or edit entries in this option, you should first create all the standard visit types that might occur at your organization in the Commure Pro Visit Types option (see Commure Pro Visit Types). You can then use the ADT Visit Types option to indicate the following:

• The visit types that are interfaced from your source system
• The visit types that you want to allow users to manually register directly in the Commure Pro system If the Commure Pro system receives an interface message for a visit type that is not listed in the ADT Visit Types option, it creates a new ADT visit type automatically. The mapping of the new ADT visit type to a Commure Pro visit type is handled as follows:
• In a Direct Integration to MEDITECH® with Downtime Solution configuration, the new ADT visit type is mapped automatically, based on the type of visit that it receives from MEDITECH.

• In a Commure Pro with Commure Pro Repository™ configuration, you should set a default Commure Pro visit type to use in this event. All new ADT visit types are them automatically mapped to the default Commure Pro visit type. Please refer to Setting a Default Commure Pro Visit Type for instructions. This option also allows you to select default charge service sites in order to indicate where each type of visit is most likely to occur. Please refer to Configure Service Sites for more information on setting service site defaults for charge entry.

The table below illustrates some common ADT visit types that you might create: In the example above, we see that two ADT visit types are used for manual registration (Walk-in Outpatient and Emergency Room), while three are interfaced from the source hospital system (Emergency Room, Outpatient, and Inpatient). We also see that in some cases more than one ADT visit type is mapped to a single Commure Pro visit type (for example, both Walk-in Outpatient and Outpatient ADT visit types are mapped to the same Outpatient Commure Pro visit type). In another example, you could map multiple ADT visit types with a source of MANUALREG to a single Commure Pro visit type, like this: In this example, when a user performs a manual registration, they see one choice for the type of visit to add (Outpatient). However, once the manual registration screen is displayed, the user can then select the specific ADT visit type of Walk-in Outpatient or Outpatient Rehab Clinic. ADT Visit Types appear in the following options:

• On the standard Patient Data Display, when using the Visits display option, in the Visit Detail area for a particular visit (the Patient Data Display is visible on the Patient List tab or after clicking the Details button )
• On manual registration screens, when editing or manually adding a visit, the ADT visit type field may be available (registration screens are customized by organization, so the field may not be visible at all sites) To enter a new ADT visit type, follow these steps:

1. Click the Admin tab, followed by the System Management tab.
2. Click the ADT Visit Types option.
3. Click the Add ADT Visit Type button.
4. Enter the following information:
   • Name: Enter a descriptive name for this ADT visit type, such as Walk-in Outpatient, or Emergency Room. This is a required field.
   • Abbreviated Name: Enter a short name for this ADT visit type. This abbreviation is used when displaying the ADT visit type in various options throughout the application (see an itemization of displays at the end of this section). This is a required field.
   • Map to Commure Pro Visit Type: Map this ADT visit type to an entry from the Commure Pro Visit Type list by selecting a Commure Pro visit type from the drop-down list. We might map the Walk-in Outpatient ADT visit type to the Outpatient Commure Pro visit type. This is a required field.
   • Default Service Site: If desired, select a charge service site where this ADT visit type is most likely to take place. The Service Site charge header can be configured to automatically select your choice here as the service site whenever a user enters a charge for this ADT visit type. For example we might select the charge service site of Walk-in Clinic as the default service site for the Walk-in Outpatient ADT visit type. This field is not required. Please refer to Configure Service Sites for more information.
   • Source: Select the source system in which this ADT visit type is created. Your options are SYSTEMNAME (where SYSTEMNAME refers to the source information system from which visits of this type are interfaced) or MANUALREG (to be able to manually register visits of this type). This is a required field.

5. Click the Save button.

​

Managing Provider Roles

The option for managing provider roles has been designed to standardize the nomenclature involving references to the role of provider.

​

Handheld Devices

The Handheld Devices option allows you to view details about, edit, delete, retrieve logs remotely, and clear data remotely on provisioned Apple devices.

​

Viewing Details about a Device

To review the details of a provisioned handheld device, follow these steps:

1. Select the Admin > System Management > Handheld Devices.
2. Search for a user that has an associated handheld device by entering any portion of their first name, last name, or username in the Search field at the top of the screen, and then pressing Enter on your keyboard or clicking Refresh. A list of users with associated handheld devices is displayed, with columns for Device Name and User Name.
3. Click on any row in the results list to display the information below for that device. Only a few fields can be edited (as noted below).
   • Device ID: Indicates the unique internal ID for this device.
   • Device Type: Indicates operating system of the device (iOS™ or Android™).
   • Application: Indicates the application (Mobile Clinical Results) that has been selected for the device.
   • Name (editable field): Identifies the unique device name that is assigned when a device is provisioned. This consists of the user’s username plus a unique number. See Renaming a Device for more information.
   • Department: This field is deprecated and never shows a value.
   • User: Indicates the username of the user.
   • Horizontal Resolution: Indicates the width in pixels of the device screen.
   • Vertical Resolution: Indicates the height in pixels of the device screen.
   • Has Cell: Indicates that the device has cellular phone service. Not currently implemented.
   • Has Keyboard: Indicates that the device has a keyboard.
   • Has Touchscreen: Indicates that the device has a touchscreen.
   • Has Virtual Keyboard: Indicates that the virtual keyboard preference is enabled.
   • Has Wifi: Indicates that the device has WiFi access.
   • Last Sync: Indicates the date and time of the last sync from the server to the device.
   • Last Submission: Indicates the date and time of the last data submission from the device to the server.
   • The following four fields are editable and are used to retrieve the logs from an Apple user’s device if they are experiencing issues. See Retrieving Logs Remotely from a Device for more information and instructions.
     • Collect Logs
     • Logs Start Date
     • Logs End Date
     • Notify User Email

​

Renaming a Device

Each device has both an internal ID (Device ID) and an external name (Name). The Device ID never changes, and is used to identify the device during syncing. The Name is used in reporting functions, such as Device Sessions Reports and Submission Status Reports help you identify each device. You might change a device’s Name, if for example, the name assigned during provisioning was not specific enough. To change a device’s name:

1. Select the Admin > System Management > Handheld Devices.
2. Search for the user whose device you want to rename by entering any portion of their first name, last name, or username in the Search field at the top of the screen, and then pressing Enter on your keyboard or clicking Refresh. A list of users with associated handheld devices is displayed, with columns for Device Name and User Name.
3. Find the device you want to rename, and click on the row for that device.
4. Click the Edit button. The Edit Device screen appears.
5. Enter a new name in the Name field.
6. Click Save to save your change, or click Cancel to exit without saving.

​

Deleting a Device

Deleting a device in the Handheld Devices option prevents it from continuing to sync. Why would you want to do this?

• If you have locked a user to a single device (based on the setting below) and the user has acquired a different device that they would like to use instead, you must delete the old device in this option before you can provision the new device for that user. Admin - User - Device - Lock User to Device
• If a device has been lost, you might delete it to ensure that it does not continue to sync. However, a better safeguard would be to clear the data from the device in order to protect patient confidentiality. See Clearing Data Remotely from a Device.

To delete a device:

1. Select the Admin > System Management > Handheld Devices.
2. Search for the user whose device you want to delete by entering any portion of their first name, last name, or username in the Search field at the top of the screen, and then pressing Enter on your keyboard or clicking Refresh. A list of users with associated handheld devices is displayed, with columns for Device Name and User Name.
3. Find the device that you want to delete and click on the row for that device.
4. Click the Delete button. The following message appears: “Are you sure you want to delete the selected device?”
5. Click Yes to delete the device, or click No to cancel the deletion.

​

Retrieving Logs Remotely from a Device

If a user is experiencing issues with the Commure Pro application on their handheld device, Commure Pro support staff might ask you to submit the device’s logs. Both Android and Apple users can submit the logs themselves using an option in Settings within the Commure Pro mobile application (see the Commure Pro on Apple help or the Commure Pro on Android help). Or, for Apple devices only, or an administrator can retrieve the logs remotely using a function in the Handheld Devices option.

1. Select the Admin > System Management > Handheld Devices.
2. Search for the user whose device logs you want to retrieve by entering any portion of their first name, last name, or username in the Search field at the top of the screen, and then pressing Enter on your keyboard or clicking Refresh. A list of users with associated handheld devices is displayed, with columns for Device Name and User Name.
3. Find the device for which you want to retrieve logs and click on the row for that device.
4. Click the Edit button. The Edit Device screen is displayed.
5. Complete the following fields:
   • Collect Logs: Set this to Yes to retrieve the logs from the device. The next time the device syncs, the logs are submitted to the server and then this field is automatically reset to No (and the three fields below are also cleared).
   • Logs Start Date: (Optional) If you leave the Logs Start Date blank, then logs are submitted from the first date/time that they are available on the device. Or, if you enter a date and time, only those logs with a date/time on or after the entered value are submitted. When you select a start date, the time defaults to 00:00, which is the beginning of the day for that date.
   • Logs End Date: (Optional) If you leave the Logs End Date blank, then logs are submitted up through the last date/time that they are available on the device. Or, if you enter a date and time, only those logs with a date/time on or before the entered value are submitted. When you select an end date, the time defaults to 23:59, which is the end of the day for that date.
   • Notify User Email: (Optional) If you enter a valid email address, then once the logs are submitted, an e-mail notification is sent to that address. The e-mail lists the device ID, the selected date range for the logs, and the submission ID that can be used to locate the logs on the Admin > Tracking/Reporting > Submission Status tab. For example: “The requested logs for Device Name: Commure Pro QA iPhone 6S for the currently logged in User: JONES, ALAN from 2018-10-08 12:00:00.0 through 2018-10-10 11:59:00.0 are now available and can be found in the Submission Status tab under Tracking/Reporting in Commure Pro admin tools. The Submission ID for the requested logs is 83429.”

If you do not enter an e-mail address, the logs are still submitted at the next sync, but you are not notified when it occurs.

6. Click Save to submit your request. The next time the device syncs, the logs are submitted to the server and an e-mail notification is sent to the requester (if an email address was entered).
7. To view the logs, go to Admin > Tracking/Reporting > Submission Status and enter the Submission ID listed in the e-mail message into the Submission ID criteria field. See Filtering Submission Records for more information.

​

Clearing Data Remotely from a Device

Clearing data from a device removes all user and patient data from the device, with the exception of the Commure Pro application itself. Why would you want to clear data from the device?

• If you want to assign the device to a new user, you must clear the data from the device first, and then provision it for the new user.
  • If you have the device in hand, you can clear the data using the Clear Data button on the device itself, and then immediately provision it for the new user. For instructions, see Commure Pro on Apple help or the Commure Pro on Android help.
  • If you do not have the device in hand, you can clear the data remotely using the Handheld Devices option (available for Apple devices only). The new user or department manager can then log in and provision the device on their own.
• If the device has been lost or stolen, you should clear the data so that patient confidentiality is not compromised. If an unauthorized person finds the device after it has been cleared, they would have to know the user’s password in order to log in, re-provision the device, and view patient data (unlikely).
  • Since you would not have the device in hand, you can clear the data remotely using the Handheld Devices option (available for Apple devices only).
• Please note that if an employee who owns their own device is terminated, the best procedure is to delete their LDAP or Commure Pro user account, which also has the effect of clearing data the next time that user attempts to log into the Commure Pro application. If you just clear data instead of deleting their account, they could simply log in and reprovision the device again, thereby regaining access to patient data. To clear data remotely from a device:

1. Select the Admin > System Management > Handheld Devices.
2. Search for the user for which you want to clear device data by entering any portion of their first name, last name, or username in the Search field at the top of the screen, and then pressing Enter on your keyboard or clicking Refresh. A list of users with associated handheld devices is displayed, with columns for Device Name and User Name.
3. Find the device for which you want to clear data and click on the row for that device.
4. Click the Clear Device button. The following message appears: “Are you sure you want to clear data for Device [device name]? Clearing data will require re-configuring the device for the new user.”
5. Click Yes to clear the device, or click No to cancel. If you select Yes, the message “Device Deactivated: Pending Sync” appears in the device details on the right side if the screen.

The data is cleared from the device the next time it contacts the server. The device contacts the server when a manual or automatic sync is initiated, or when a user logs in, submits data such as a charge, or performs a search (such as searching for a patient). Once the device has been cleared, the message changes to “Device Deactivated: mm/dd/yy hh:mm”

​

Configuring InterApp Communication for Apple Devices

Your organization can use inter-app communication to create a direct link from the Commure Pro Apple® application to a third party Apple application, or vice versa, so that providers or nurses can easily navigate between the two. These integrations can be configured in a variety of manners depending on their context and usage. For example, when moving from the Commure Pro application to another application, the integration might use a new left-swipe or menu option from the Patient List module, or a new menu item under the Notifications button. Or when moving in the other direction, the integration might consist of a “Commure Pro” button in the other application. When a user selects the integration option, the target application is a launched and the user is automatically logged into that application so that they do not have to enter their username and password. In addition, the patient they were accessing in the starting application can be passed to the target application, so that when it opens, that patient is already selected for them. In order for this type of integration to work, an entry must be configured in the Mobile InterApp option, which includes defining a shared secret (the instructions for this are listed below). In addition, there may be other settings that require configuration on the Institution, Department, or User level. Please note that additional work is also required by the Commure Pro development team, in conjunction with cooperation from the other application vendor, in order fully implement this type of integration. See Configuring Apple Users to Launch Other Applications from the Commure Pro Application, or Vice Versa for more information about setting up specific integrations. To configure an entry in the Mobile Interapp option, follow these steps:

1. Select Admin > System Management > Mobile Interapp.
2. Click the Create New button.
3. Complete the following fields:
   • App Bundle ID (required): Enter the application bundle ID for the other application; the vendor should be able to provide you with this information.
   • Shared Secret (required): Enter a shared secret token so that data such as username or patient MRN can be passed securely from the other application to the Commure Pro application. This token must be agreed upon between Commure Pro and the other vendor.
   • Description: Enter a description for the other mobile application, such as “Application ABC.”
4. Click Save.

​

Purge Criteria

The Purge Criteria option allows you to define when device session logs and submission records for the Mobile Clinical Results, Mobile Charge Capture, and NoteWriter applications are purged from the Commure Pro Application Server. The Device Session and Submission Record Purge Criteria screen displays a list of all device session logs and submission record types. The Name column lists the internal name for the item, while the Description column lists a more descriptive name. The Description is also the same name that is used in the Tracking/Reporting option. See Device Session Types for an explanation of the different device session types, and Submission Record Types for a explanation of the different submission record types. The purge criteria date range is between 1 and 365 days. For device session logs, you can define the number of days to keep both successful and failed logs before they are purged. For submission records, you can define the number of days to keep a record (whether failed or successful) before it is purged. Any given Application Update or Submission device session log can contain one or more submission records. As a result, these types of device session logs are not purged until the purge criteria has been met for every one of the submission records contained within them. For example, if the purge settings were defined as: The effect of those settings would be as follows, in the examples below: To view or change the purge criteria for submission records or session logs, follow these steps.

1. Select the Admin tab followed by the System Management tab.
2. Select the Purge Criteria option.
3. Select a submission record or session log from the list. The current purge criteria are displayed on the right side of the screen.
4. Click the Edit button to change the purge criteria for the currently selected item. The Edit Purge Type window opens and displays the purge criteria fields. Device session logs have two fields:
   • Number of days to keep successful session logs of this type (default of 60 days)
   • Number of days to keep failed session logs of this type (default of 90 days) Submission records have only one field:
   • Number of days to keep submissions of this type (default of 60 days)
5. In the purge criteria fields, enter the number of days (between 1 and 365) to keep the session log or submission record.
6. Click Save to save your changes, or Cancel to close the window without saving your changes.

​

Vitals Edit

The Vitals Edit option allows you to rename, change the sort order, and map together vital signs components that are displayed for each patient for the Physician Portal and Mobile Clinical Results applications. To make changes to the list of available vital signs components, follow these steps:

1. Select the Admin tab, followed by the System Management tab.
2. Select the Vitals Edit option. The Vitals Administration screen appears.

The following is a list of possible vital signs components that may be available to sort, rename, or map together:

• Pulse Rate (HR): The rate at which the patient’s heart is beating, usually in beats per minute.
• Respiratory Rate (RR): The rate at which the patient is breathing, usually in breaths per minute.
• Blood Pressure (SBP and DBP): The pressure(s) at which blood flows through the peripheral vascular system. Systolic and diastolic pressures may be reported separately or as a composite measurement (for example, 120/80), usually in mmHg.
• Temperature (Temp): The patient’s temperature as obtained from a given anatomical location (such as, oral, axillary, ear, or rectal), reported in Fahrenheit or Celsius.
• Weight: The weight of a patient measured, usually in kilograms.
• O2 Sat by Pulse: The oxygen saturation (SaO2) level of the patient’s blood as determined by a pulse oximeter, usually reported in percent (%).
• Finger Stick Blood Glucose (FSBG): The glucose level of a patient’s blood determined by a finger stick test.

​

Mapping Systolic and Diastolic Blood Pressure as a Composite

To map together the systolic and diastolic blood pressures as a composite measurement, so that they display together as a single measurement in the Vitals display option (for example, 120/80), follow these steps:

1. Go to Admin > System Management > Vitals Edit.
2. Click and hold the DBP component row and then drag it on top of the SBP component row so it highlights.
3. Release the DBP component row. The DBP and SBP component rows are combined and are displayed as a single composite row, followed by two child rows for SDB and DBP. Each row has its own Sort Order.
4. Set the Sort Order value for the composite row equal to its location in the overall list of vital signs. For example, if you want SBP/DBP to appear sixth in the vitals list, set the Sort Order for the composite row to “6.”
5. Set the Sort Order value for the child SBP component to “1” and the child DBP component to “2.” This ensures that the SBP value appears before the DBP value in the composite measurement.
6. Click the Resort/Rename button.
7. Click the Refresh button to display the changes to the Vitals display of the patients.

​

Mapping Vital Signs to CDS Categories

In the CPOE application, certain Clinical Decision Support (CDS) rules are based on the value of a given vital sign. For example, when ordering a cardiac medication, a CDS alert might be triggered if the patient’s blood pressure is within a certain range. In order for this type of alert to function, vital signs must be mapped to categories, so that the CDS engine can find the correct vital sign to check when executing the alert. The vital sign categories themselves are stored in the Vitals Category reference list. At initial implementation, the Vitals Category reference list is pre-loaded with a standard list of categories as a starting point. Clients should not make changes to this list; Commure Pro staff will make any necessary adjustments. To map vital signs to vital sign categories:

1. Go to Admin > System Management > Vitals Edit.
2. For the vital sign that you want to map, click in the Vital Category column.
3. Select a category from the drop-down list. For vital signs that have been mapped together as a composite (such as might be the case for systolic and diastolic blood pressure), select one category for the entire composite. If you are unsure which category to use for a particular vital sign, contact your Commure Pro representative for assistance.
4. Repeat the Step 2 through Step 3 for each vital sign.
5. Click the Resort/Rename button to save your changes.
6. Click the Refresh button to display your changes.

​

Renaming a Vital Sign for the Vitals Display

To rename a vital sign component for the Vitals display option, follow these steps:

1. Go to Admin > System Management > Vitals Edit.
2. Click in the Vital Name box or Abbreviation box that you want to change.
3. Change the appropriate name or abbreviation.
4. Click the Resort/Rename button.
5. Click the Refresh button to display the changes to the Vitals display of the patients.

​

Changing the Order of Vitals Signs for the Vitals Display

To change the order of the vital signs components in the Vitals display option, follow these steps:

1. Go to Admin > System Management > Vitals Edit.
2. Click in the Sort Order box and change to desired order of each component.
3. Click the Resort/Rename button.
4. Click the Refresh button to display the changes to the Vitals display of the patients.

​

PQRS Measures

The PQRS Measures option allows you to manage PQRS measures for your organization. Your Commure Pro representative uses this tool to activate and deactivate measures as determined by your organization. Level 1 administrators use the PQRS Measures tool to edit descriptions for any active measures, as well as each measure’s associated questions and answers. For more detailed information on how to customize these descriptions, see Customizing Quality Measures.

​

PQRS Measures Import

The PQRS Measures Import option is used to import PQRS measures to your Commure Pro system. Once implemented, your Commure Pro representative will upload annually when CMS makes available the newly published PQRS measures list. For more detailed information, see Importing Quality Measures.

​

Export and Import of System Settings

Two settings are provided on the Institution tab for export and import of system data. This functionality provides an easy way to perform a direct comparison between the preference settings of two sites, such as between a test environment and a live production environment. This functionality is provided for test environments only, and can also be used during upgrade to keep track of all system data. Do not perform export and import of system settings in a production environment, or without the assistance of your Commure Pro representative. This functionality is provided to enable Level 0 and Level 1 administrators to export the following types of data to an Excel file that can be imported to another system:

• Institution settings
• Department settings
• User settings
• Code Edit settings (These are the settings that enable or disable each type of code edit, which are configured via Admin > Institution > Charge Capture > Code Edits.)

This functionality also supports export of several additional types of reports that are useful as reference information, but which cannot be imported to another system. These reports include:

• Charge Header reports (for institutions and users)
• Sign-Out task definitions and macros (for institutions)
• System Management Reports, including data about relationships and visit types (both Commure Pro and ADT) For more information about export of system data, contact your Commure Pro representative.