Solutions – 

Provider Data Repository (PDR)

Provider Data Repository (PDR)

The PDR is a SQL Server relational database designed to hold Provider Data in a hierarchical and historical manner.  The architecture of the PDR incorporates concepts that aid in achieving the highest level of data integrity and accuracy possible, while also making the system extremely responsive.

Within CCAH, the PDR would act as the central “hub” of all Provider Data. 
Data within the PDR would be maintained by a custom Provider Data Interface (PDI) that controls all the data validation and logic to ensure data is kept at the highest precision possible.  All data sources of Provider Data (both internal and external) would first come into the PDR System before it is ever used in other related systems.  In turn, data from other related systems can be integrated with the PDR to create a more seamless view of data.

A key aspect of the PDR
A key aspect of the PDR is that all data is being maintained in a manner that provides for full historical tracking and audit capabilities.
As data is received from external sources it is first validated in a “Staging” process and associated with system IDs that track its origin.  Only data that passes all Staging logic is allowed to be used as “Production” data within the System.

Other significant concepts utilized within the PRD are:

  • Truly becomes the “Single Source of Truth” for all Provider Data
  • A centralized Address structure verifies the validity of address information while also GeoCoding each address for use with interactive maps and distance search capabilities. This can also be used for reporting and geographical analysis of specialties and provider coverage.
  • Data is stored in a hierarchical manner that supports interactions with directories, billing, claims, network research and more.
  • Acts as the data source for other systems using Provider Data.  Only validated and confirmed data is sent to these systems.  Data is also optimized and formatted to best interact with each system and only the data needed by each system to perform its dedicated processes are sent.  Each of these related systems can then be the focal point for the processes they were intended for… and not have to contain extraneous data.
  • Acts as the data receiver for other systems using Provider Data.  There are times when viewing data from these other systems may be easier to interpret when mixed with PDR data.  Also, by importing some data from related systems to the PDR, data changes can be tracked historically.
  • The PDR can act as the data source for online services including: Provider Directory, Provider Portal, PCP Selection via a Member Portal, Provider Data Attestation, Provider Incentives and performance reporting.

Centecore welcomes the opportunity to work with your business to ensure your Data Warehouse is built to provide the strong data foundation that will allow you to grow and flourish now… and in the future.

Introducing Data Spans

Within the architecture of the PDR, any data that can change by a date period is recorded in Spans.  Simply put, a Span is a specific configuration of data that is used from a starting date to an end date.  The PDR includes many instances of Spans and allows a user to report and/or view data as it was configured on any specific date.

The illustration demonstrates how data for a Provider could be stored in seven (7) different Spans.  A new Span is created when even one (1) data element within the data for that Span changes.  When reporting is needed to know all the details about a Provider on a specific date, it is easy to drill down though the multiple spans to know exactly what data pertained to that Provider at that time.

Just imagine this pattern occurring for more Spans, for every Provider and for every hierarchical level of provider data (i.e. Groups, Sites, etc.) and you realize the power that Spans can provide when reviewing Provider Data.

Data Hierarchy

Data and Spans withing the PDR are structured to support and maintain Provider Data in a hierarchical pattern. If higher levels of this hierarchy are not needed, the pattern will continue to work with the lower levels. 

The illustration below provides visual representation of how data and spans are used at each hierachical level and how each level can interact with its predecessors.

 

 

What we’re saying is …Ok maybe it’s sorcery
but you can let us wave a wand and your data pops out of the hat!

%

Probability We Can Solve Your Problem