Overview

This document is designed to accompany the Data Dictionary Worksheet for new customers. It provides an explanation how to fill out the worksheet and provides context about the underlying data model used in Bridge. The worksheet is an Excel document with various worksheets, each worksheet has example data filled that should be replaced with the real information. Post-go-live changes to these data elements and definitions can be made through the Service Tools application that ships with each installation.

Dictionaries

External Systems

Each clinical system that is directly sending data or has data elements sent in via another system should be defined in this tab. The system name and site(s) combination must be unique.

Some configurations will have as few as two total systems (an EMR and SSO, for instance), but in practice there can be over a dozen for complex, multi-institutional configurations.

Exactly one of these systems with a role of SSO will be used to specify the identifier/login mappings used in the User Mappings.

Site Classes

Site classes are a description of the medical service location of a patient for an encounter or admission. There are several properties flagged which are mandatory for applications to behave correctly: Trauma, ED, and Type. Trauma and ED are boolean flags for classes of admissions that are considered trauma center (various national and local definitions exist) or emergency department, respectively. Type is equivalent to hospital status of inpatient or outpatient, per CMS guidelines

Each site class is unique per External System and single physical location (synonymous to a facility code), called a site in the terminology of Bridge. These site definitions cascade into almost every level of the data model, including resources, and exams.

For certain optional financial modeling functionality, knowing the CMS place of service code, as well as the GPCI information is required. This is optional information that can be added later in Service Tools, but when there are numerous site classes it is faster and easier to get them configured in advance.

User Mappings

While Bridge applications are designed to use enterprise authentication for user/role mappings and authentication, being able to correlate this data with richer metadata about clinical roles, sub-specialty, etc. is something that many enterprise directories do not currently offer. With this in mind, the underlying data model used in the platform is designed to capture and maintain rich metadata about the users.

This tab contains the common data elements used to build a dictionary to enable rich application functionality. Not all columns are required, nor do they make sense for all users (e.g. the post-graduate year is only useful for someone in a resident clinical role).

Similarly, all columns after the PGY definitions are examples of clinical systems that will be feeding data to Bridge, directly or indirectly. These systems are further enumerated in External System tab. The scheme is that each system has identifiers for users, such as unique ID or a username, that will appear in messages that the platform receives. Filling out these columns (per the examples) allows the data to be properly correlated.

It is important to note that some of this data may or may not be available in the enterprise directory that Bridge is configured to authenticate against. Please consult with your integrator to develop the proper strategy to capture and maintain such data. In the US, a providers NPI is strongly suggested as an attribute to include for as many users as possible, as the existence of an external NPI directory makes it easier to verify identities and match users between systems.

Procedure Mappings

Bridge requires procedure mappings to accommodate applications that use specialty mappings, CPT-based logic, RVU-based logic, or similar designs. In the US, some organizations use a 1:1 mapping between a procedure code and a CPT code, other sites have 1:many mapping; the data model can accommodate both approaches concurrently and will automatically calculate the appropriate pro RVU. For customers outside of the US, the RVU values for procedures can be set directly. Each procedure code must be unique per External System.

Volume Countable, Reportable, and Valid flags exist to inform applications if a particular procedure should count toward exam/CPT volume counts, is reportable by a physician, and is currently valid, respectively. This prevents cluttering worklists with invalid data and keeps report counts consistent. Subspecialty mappings should be consistent with the specialties defined in the User Mappings. Average Duration (min) is used by applications that provide prospective scheduling views, and the various *_fee columns for finance, respectively.

Resource Mappings

In the Bridge data model, resources are uniquely named, per External System and map 1:1 to a physical imaging modality (or pool of interchangeable modalities such as portable X-Ray or ultrasound units). Exams are expected to be performed on a single resource and the classification of exam modality is mapped based by resource (not procedure type). Each resource is expected to reside at only one physical site.

System Statuses

Exam statuses are typically workflow-specific and may vary in name between site and clinical system, even if referring to a common idea. This dictionary allows these statuses to be defined, per External System and also mapped to SIIM's SWIM normalized naming conventions. Applications built on Bridge use the normalized SWIM workflow lexicon to allow site-independent workflow to be consistent, so it is highly suggested to map as many statuses as possible to the SWIM lexicon.