Pooling and Exchanging Data: Chapter 15

Questions and Considerations

A. What are the different architectural approaches?

Centralized data warehouse

• Centralized data warehouses store all the data extracted from many different sites that use a given system
• Centralized data warehouses are typically maintained by a coordinating center that ensures that the data are entered into the warehouse and available for use
• Centralized data storage facilitates better data analysis as it allows statisticians to understand which data were collected, which are missing, and to conduct quality checks
• All sites contributing to the centralized warehouse must address legal, regulatory, and proprietary data sharing issues
• Contributing sites need to agree on a standard data interchange format

Federated/distributed data warehouse

• In federated/distributed data warehouses, data are kept in a locally maintained data warehouse at each site
• Data analysis queries can be submitted to the local sites, which run the analysis and respond with summary data
• There are fewer organizational concerns about sharing potentially identifiable patient data, as the local site has control of the data and only reports aggregated results
• Although data is held locally, this approach still requires different sites to agree on mapping of local types and potential values of data to the standard values and formats
• Record linkage to data is more difficult
• It may be difficult or impossible to replicate analyses, since they are conducted at the local level

B. What are the considerations for choosing a common data model?

• Pooled PRO data have little value if there is not a consistent data model and meta-data
• Considerations when selecting or creating a common data model include:
  • Granularity of data and whether person-level analyses are supported
  • De-identification and other limitations of data sets, including bins or categories of data rather than specific values (e.g. age range rather than date of birth)
  • Data specificity (e.g. how de-identification was handled with respect to dates)
  • Clinical domain(s) in the data model
  • Governance of the data model
  • Model use of standard interoperability references

C. What are some examples of data models to choose from?

• There are hundreds of data models to consider
• Here are examples of several popular options
  • PCORnet: Developed by the Patient-Centered Outcomes Research Institute (PCORI). Describes meaning of each data item, and in some instances the context of the collected data
  • Consolidated Clinical Document Architecture (CCDA): A general-purpose XML-based clinical data interchange format. It is commonly available in electronic health records that are certified by the Office of the National Coordinator – Authorized Testing and Certification Body. It is often used to move data from one system to another when the two systems have different internal data models
  • i2b2 – Shared Health Research Informatics Network (SHRINE): An open-source, XML-based network that allows groups to link their aggregated counts of patients meeting selected inclusion and exclusion criteria for demographics and other variables
  • Project-specific ad hoc data models: As opposed to choosing from an existing data model, a new data model can be created that includes only the data required for a specific project