PCORI Methodology Standards: Academic Curriculum Patient-Centered Outcomes Research Institute. All Rights Reserved.

Transcription

1 PCORI Methodology Standards: Academic Curriculum 2016 Patient-Centered Outcomes Research Institute. All Rights Reserved.

2 Module 5: Architecture for Data Networks Category 7: Data Networks as Research-Facilitating Structures Prepared by Hadi Kharrazi, MD, PhD Dan Ford, MD, MPH Presented by Hadi Kharrazi, MD, PhD

3 Data Network Methodology Standards Mapping With Content DN-1 (requirements for the design and features of data networks) is discussed in Modules 3, 4, 5, 6, and 7 A. Data Integration Strategy Module 4 B. Risk Assessment Strategy Module 6 C. Identity Management and Authentication of Individual Researchers Module 6 D. Intellectual Property Policies Module 7 E. Standardized Terminology Encoding of Data Content Module 4 F. Metadata Annotation of Data Content Module 4 G. Common Data Model Module 5 DN-2 (selection and use of data networks) is discussed in Modules 8 and 9 4

4 Data Networks Architectures: Basics Most networks begin with basic components: A system for data sharing, Governance practices and policies for data use, and A shared strategy for integrating data from multiple sources Source: Ohno-Machado, L., et al. (2012). Standards in the Use of Collaborative or Distributed Data Networks in Patient Centered Outcomes Research. Available at: Accessed August 27,

5 Data Networks Architectures: Basics These criteria can effectively be met with unsophisticated technical methods such as IRB [institutional review board] managed governance, encrypted or SFTP [secure file transfer protocol] for data sharing, and manual, incremental management of data models for each additional analytic purpose. However, at the minimum, these methods should adhere to security and data protection practices that are reusable. In the realm of security, data access should be controlled with an authentication process; for example an intermediate storage should not result in transfer of data ownership (as it does with services such as Gmail or Dropbox); and the storage medium should not be vulnerable to theft or loss (as in media mailed via the U.S. Postal Service). Source: Ohno-Machado, L., et al. (2012). Standards in the Use of Collaborative or Distributed Data Networks in Patient Centered Outcomes Research. Available at: Accessed August 27,

6 Data Networks Architectures: Minimum Requirements Systems for data integration that facilitate reuse of data models and transformation programs are more likely to survive multiple studies. Projects that merely meet these minimum requirements rarely result in published evidence or even public discussion describing architecture. Minimum requirement of data network architecture: key architectural features of networks that have successfully advanced from these minimum requirements into systems supporting multiple multi-site, multidomain studies with a common framework. Source: Ohno-Machado, L., et al. (2012). Standards in the Use of Collaborative or Distributed Data Networks in Patient Centered Outcomes Research. Available at: Accessed August 27,

7 Common Models The consensus architectural recommendation and practice is a variation of a distributed architectural paradigm, in which local control is retained, while workflow and access are coordinated via a central hub Even some past successful research data networks have adopted the distributed model over the recent years Within the distributed model, workflow for data integration included two preferred approaches: 1. Pretransformation of source data to a common data model 2. Dynamic transformation of source data to a conceptual domain model via published transformation logic This approach is more transparent, enabling data consumers to access transformation methods used in each source and facilitating discovery and reuse of similar transformation code across the network Source: Ohno-Machado, L., et al. (2012). Standards in the Use of Collaborative or Distributed Data Networks in Patient Centered Outcomes Research. Available at: Accessed August 27,

8 Common Models a network working toward a framework for data sharing can meet minimum legal and technical standards with simple technology and data storage practices as a first step toward a scalable architecture These minimal networks often include both centralized and distributed paradigms with some features of cloud-based approaches, [but] the distributed approach has been most recommended in the literature Within a distributed architecture, query distribution to each data partner is most easily managed centrally, and data integration may be accomplished either with stored transformations performed during query execution steps or by storing data locally in a pretransformed format Recommended security practices involved role-based access control with built-in auditing procedures and a defense in depth strategy Source: Ohno-Machado, L., et al. (2012). Standards in the Use of Collaborative or Distributed Data Networks in Patient Centered Outcomes Research. Available at: Accessed August 27,

9 Architectural Paradigm: Distributed/Federated Systems Maintaining Local Nodes for Data Partners Description Examples The ultimate endpoint of materials promoting distributed approaches is to implement a grid-based system, with hardware and software for collaboration maintained by each node At a minimum, each data partner in a given distributed research network is required to adopt common practices for data extraction and transfer A hub-and-spoke design with a centrally hosted portal/gateway (as opposed to peer-to-peer design) Mini-Sentinel, FURTHeR, DARTNet/SAFTINet, BIRN, and cabig Patient-centeredness Re-identification or pre-identification is feasible under local control, which enables identification of patients for collection of patient-reported outcomes (PROs) 9

10 Architectural Paradigm: Central Repository Description Data partners transfer data from local systems to a central repository Examples All-payer claims databases, registries, and the Regenstrief Model Patient-centeredness Collection of and linkage to PROs more challenging 10

11 Architectural Paradigm: Cloud Description Resources (data and processes) remain locally controlled and administered but are stored on remote servers maintained by third parties Key features include automatic scaling of computation and data needs Examples SCANNER and Mini-Sentinel partially use the cloud Patient-centeredness Not explored yet 11

12 Architectural Paradigm EHR 1 PRO EHR 2 Registries EHR 3 Claims Federated Inconsistent Architecture (Noninteroperable) 12

13 Architectural Paradigm EHR 1 PRO EHR 2 MPI Registries EHR 3 Claims Federated Consistent Architecture (Interoperable) 13

14 Architectural Paradigm EHRs PROs Claims Data Repository Registries Imaging LABs Centralized Architecture 14

15 Architectural Paradigm EHRs PROs Claims Cloud Data Repository Registries Imaging LABs Cloud Architecture 15

16 Architectural Paradigm EHRs PROs EHRs Data Repository Claims Claims MPI Registries LABs Imaging LABs Hybrid Architecture 16

17 Query Execution Paradigm: Query Distribution / Data Request Process Description Examples More information Patient-centeredness Challenges Raw data should be stored locally, with queries distributed to data holders and responses transferred to analytic loci Mini-Sentinel publish-and-subscribe model in which data holders are notified of waiting queries DARTnet all queries run locally and simultaneously S&I Query Health Technology Working Group Options for pull mechanism may increase security and protection of patient privacy by enabling review by a data manager before execution and transfer However, such asynchronous approaches may also limit opportunities for getting feedback to and from patients, if that is a desirable outcome There are risks associated with improper local execution of queries, misinterpretation of results, and underdocumentation of sources of bias 17

18 Query Execution Paradigm ONC Query Health Uses PopMedNet framework for distributed queries and integrates in i2b2 ONC Data Access Framework (DAF) (HL7 FHIR) Defines standard APIs on how to access encounter documentation (e.g., discharge summary, history and physical, CCD) and discrete data elements (e.g., demographics, medications) ONC Structured Data Capture (SDC) will develop and validate a standards-based data architecture so that a structured set of data can be accessed from EHRs [electronic health records] and be stored for merger with comparable data for other relevant purposes 18

19 Data Integration Paradigm: Strategy Description Examples Patient-centeredness Challenges Some common model for the research domain of interest must be adopted so that data sources can be harmonized Distributed networks include two approaches: N/A 1. Pretransformation of data into a static and standardized storage structure 2. Publishing of transformation logic from each source into the common model that can be executed at the time of data extraction from the source Maintenance and management of transformation services by the network requires additional overhead 19

20 Security Paradigm: Strategy Description Examples Patient-centeredness Challenges Defense-in-depth standards provide tight security control and auditing, including role-based person-level (rather than institution-level) access control for data elements and resources The easiest way to accomplish security control is via a single network hub or gateway (e.g., Public Key Infrastructure Security Exchanges, IPrestricted access to data nodes from portal, password-protected HTTPS access to gateway portal) DARTNet the overall security model adopts a defense-in-depth strategy developed by the University of Minnesota for the epcrn Portal BIRN Globus-based security solutions, authorizations, and credentials management N/A Usual tradeoffs between security and usability exist For complex queries and analyses that use locally hosted software (e.g., SAS), concerns about running programs were raised 20

21 Data Integration Versus Network Transfer Models The two dimensions, data integration strategy and network transfer model, tend to impact other elements of design (e.g., how data is accessed and transferred) Data integration strategies: Ad hoc the norm in most multisite studies and has minimal impact on practice workflow for infrequently executed queries Adoption of common data model (CDM) relies on each site to maintain data in a CDM and requires upfront investment in a transformation process and workflow, but alleviates redundant transformation processes if several queries are repeated On-the-fly transformation requires management of transformation logic but allows data to remain in their native format at the source Network transfer models: Include models such as ad hoc data transfer, centralized repository, and federated models 21

22 Increasing implementation barrier Data Integration Versus Network Transfer Models Increasing implementation barrier Data integration strategy Ad-hoc ETL for individual projects and no CDM CDM for storage and query federation (data are pretransformed) On-the-fly transformation with common conceptual models for queries Data access / network transfer model Ad hoc data transfer Centralized repository Federated with remote access with local storage emerge and some other collaborative research networks HMORN VDW OMOP National registries (Pinnacle, T1DX); monolithic systems (VHA, KP); all-payer claims databases (CMS); Regenstrief model Mini-Sentinel, DARTNet, SHRINE/i2b2, cabig (multi-cdm) FURTHeR, BIRN 22

23 Common Data Model: PCORnet CDM The PCORnet data model is freely available for use. An open-source license will be selected by PCORI. The PCORnet Distributed Research Network (DRN) and its infrastructure, including the Common Data Model (CDM), is overseen and guided by the PCORnet Data Standards, Security, and Network Infrastructure (DSSNI) Task Force. The PCORnet CDM is based on the Mini-Sentinel Common Data Model (MSCDM) and has been informed by other distributed initiatives such as the HMO Research Network, the Vaccine Safety Datalink, various AHRQ Distributed Research Network projects, and the ONC Standards & Interoperability Framework Query Health Initiative. The PCORnet CDM is positioned within healthcare standard terminologies (including ICD, SNOMED, CPT, HCPCS, and LOINC) to enable interoperability with and responsiveness to evolving data standards. Source: PCORnet. Common Data Model (CDM) Specification, Version 3.0. Available at: Common-Data-Model-v3dot0-RELEASE.pdf. Accessed September 2, More info: 23

24 Common Data Model: PCORnet CDM Source: PCORnet Common Data Model (CDM). Available at: Accessed September 2, PCORnet Common Data Model is licensed under a Creative Commons Attribution 4.0 International License ( More info: 24

25 Common Data Model: PCORnet CDM Demographics Enrollment Dispensing Death Vitals Conditions Encounters Diagnosis Procedures Lab results Prescribing Source: PCORnet. Common Data Model (CDM) Specification, Version 3.0. Available at: Common-Data-Model-v3dot0-RELEASE.pdf. Accessed September 2,

26 Common Data Model: PCORnet CDM Source: PCORnet. Common Data Model (CDM) Specification, Version 3.0. Available at: Common-Data-Model-v3dot0-RELEASE.pdf. Accessed September 2,

27 Common Data Model: Observational Medical Outcomes Partnership (OMOP) OMOP has demonstrated the feasibility of establishing a common infrastructure to accommodate observational data of different types (both claims and EHRs) The purpose of OMOP s CDM is to standardize the format and content of the observational data, so standardized applications, tools and methods can be applied to them Source: Accessed September 2,

28 Common Data Model: Observational Medical Outcomes Partnership (OMOP) Source: OMOP CDM Version 4.0. Available at: name=cdm%20specification%20v4.0. All material is licensed under the Apache License Version 2.0, making it available to the public as Open Source with minimal restrictions ( More info: OMOP CDM v4 28

29 Common Data Model: Observational Medical Outcomes Partnership (OMOP) Source: OMOP CDM Version 4.0. Available at: name=cdm%20specification%20v4.0. All material is licensed under the Apache License Version 2.0, making it available to the public as Open Source with minimal restrictions ( OMOP CDM v4 Entity Relationship Diagram More info: 29

30 Common Data Model: Analysis Data Model (ADaM) ADaM CDM is managed by CDISC and specifies the fundamental principles and standards to follow in the creation of analysis datasets and associated metadata ADaM supports efficient generation, replication, and review of analysis results The design of analysis datasets is generally driven by the scientific and medical objectives of the clinical trial A fundamental principle is that the structure and content of the analysis datasets must support clear, unambiguous communication of the scientific and statistical aspects of the trial More info: 30

31 Common Data Model: Analysis Data Model (ADaM) Source: CDISC Analysis Data Model Version 2.1. Available at: pplication/pdf/analysis_data_model_v2.1.pdf. Accessed September 2, More info: Analysis Data Flow Diagram 31

32 Common Data Model: BRIDG The Biomedical Research Integrated Domain Group (BRIDG) Model is a collaborative effort engaging stakeholders from the CDISC, the HL7 BRIDG Work Group, NCI, and FDA. The goal of the BRIDG Model is to produce a shared view of the dynamic and static semantics for the domain of basic, pre-clinical, clinical, and translational research and its associated regulatory artifacts. This domain of interest is further defined as: The data, organization, resources, rules, and processes involved in the formal assessment of the utility, impact, or other pharmacological, physiological, or psychological effects of a drug, procedure, process, subject characteristic, biologic, cosmetic, food or device on a human, animal, or other subject or substance plus all associated regulatory artifacts required for or derived from this effort, including data specifically associated with post-marketing adverse event reporting Source: BRIDG. Available at: Accessed September 2,

33 Common Data Model: BRIDG BRIDG 4.0 is a major release for the project The scope of the BRIDG model has now changed to encompass the larger translational research domain It is no longer limited to just representing the clinical research domain Source: BRIDG 4.0 Domain Analysis Model. Available at: Accessed September 2,

34 Common Data Model: BRIDG UML-Based BRIDG Model Source: BRIDG 4.0 Domain Analysis Model. Available at: 4.0_html/index.htm. Accessed September 2,

35 Common Data Model: Virtual Data Warehouse (VDW) HMORN s Virtual Data Warehouse (VDW) facilitates research that brings together EHR data across multiple health systems Image: HCSRN. Data Resources. Available at: Accessed September 2, More info: 35

36 Common Data Model: Virtual Data Warehouse (VDW) Source: Ross, T. R., Ng, D., Brown, J. S., et al. (2014). The HMO Research Network Virtual Data Warehouse: A Public Data Model to Support Collaboration. egems, 2(1). This work is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License. HMORN Virtual Data Warehouse Entity-Relationship Diagram 36

37 Additional Resources Electronic Data Methods Annotated Bibliography Standards & Interoperability website Standards in the Use of Collaborative or Distributed Data Networks in PCOR Research.pdf 37