Clinical Registry Extraction and Data Submission (CREDS) IG

1a. Project Name Clinical Registry Extraction and Data Submission (CREDS) IG 1b. Project ID 1720 1c. Is Your Project an Investigative Project (aka PSS-Lite)? No 1d. Is your Project Artifact being Reaffirmed or proceeding to Normative directly after being either Informative or STU? No 1e. Today's Date 1f. Name of standard being reaffirmed 1g. Project Artifact Information 1h. ISO/IEC Standard to Adopt 1i. Does the standard include excerpted text from one or more ISO, IEC or ISO/IEC standards, but is not an identical or modified adoption? 1j. Unit of Measure 2a. Primary/Sponsor WG Clinical Interoperability Council 2b. Co-Sponsor WG Public Health 2c. Co-Sponsor Level of Involvement Request formal content review prior to ballotRequest periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.) 2c. Co-Sponsor Update Periods Monthly 2d. Project Facilitator Dave Pyke, Russ Leftwich 2e. Other Interested Parties (and roles) Biomedical Research and Regulation (Interested Party) Orders and Observations Public Health 2f. Modeling Facilitator Keith Boone 2g. Publishing Facilitator Keith Boone 2h. Vocabulary Facilitator 2i. Domain Expert Representative James Tcheng, Ganesan Srinivasan 2j. Business Requirements Analyst Nick Ramsing 2k. Conformance Facilitator Dave Pyke 2l. Other Facilitators 2m. Implementers ACC (American College of Cardiology) CRISP Audacious Inquiry 3a. Project Scope The purpose of this Implementation Guide is to simplify the efforts of healthcare provider organizations to collect the data needed to submit to registries, by making it easier for registries to supply healthcare providers with the information that providers need to prepare a registry submission. This guide profiles how a registry says what needs to be sent, and how a healthcare provider organization can use that to automate the collection and formatting the data into a submission, conforming to registry or FHIR implementation guide defined profiles and protocols. This guide will describe the steps to: • Define the data needed in a registry submission, relying on existing FHIR resources, profiles, and implementation guides • Describe how this data can be collected and organized through FHIR APIs • Transform the collected data into content suitable for a registry submission • Use applicable FHIR operations defined in existing FHIR Implementation Guides to submit the content • Coordinate with other systems to validate and refine registry submissions, as necessary. This project proposal addresses the need to provide a common way to describe data collection and submission requirements for disease registries that enables a disease registry to: 1. Describe the data they wish to collect. 2. Define the constraints on the submission to indicate how data should be submitted. 3. Identifying the trigger events that might indicate a submission is needed. And a healthcare provider organization to: 1. Identify sources of data that might appear within a disease registry submission. 2. Support processes to automatically extract data from information systems. 3. Support processes to transform extracted data into appropriate formats for a registry submission. Within this project, we expect to reference and reuse existing content available from Common Clinical Registry Framework (CCRF), US Core, Cancer Registry IG, MedMorph, mCode, Breast Imaging, eCR, et cetera, where applicable to demonstrate how systems implementing this IG can support those efforts. This project will not be profiling clinical data associated with patients, rather it would be reusing applicable profiles to support that in registry exchange. This FHIR implementation guide will use the US Core profiles. If this FHIR implementation guide is unable to use a US Core profile, we will follow the Cross Group Projects WG's variance request process, and provide the US Realm Steering Committee an approved rationale for deviation in the implementation guide where applicable. Attachments 3b. Project Need Healthcare providers have challenges collecting all the data from all the possible data sources to populate registry submissions. Some of this data is in the provider’s EHR system, some may be in departmental or specialty solutions, some may be available from other facilities, some may exist in EMS Run reports, some may be available through regional or national health information exchanges. Data does not flow easily from all-of these different sources into registry submission records supported by an EHR or other registry submission system. The sources of this data are often not directly integrated into registry submission applications. It takes a lot of effort for healthcare provider organizations to configure their EHR or registry submission application to collect and communicate data needed by a disease registry. As a result, disease registries are challenged to get healthcare provider organization to submit data to them in the expected formats with the necessary data quality. Existing IGs such as MedMorph and the Women's Health CRN provide a framework for submissions. This guide will extend MedMorph to explore novel ways to automatically extract data for registry submission not covered in MedMorph and eCR. This project proposal addresses the need to provide a common way to describe data collection and submission requirements for disease registries that enables: A disease registry to: 1. Describe the data they wish to collect. 2. Define the constraints on the submission to indicate how data should should be submitted. 3. Identifying the trigger events that might indicate a submission is needed. A healthcare provider organization to: 1. Identify sources of data that might appear within a disease registry submission. 2. Support processes to automatically extract data from information systems. 3. Support processes to transform extracted data into appropriate formats for a registry submission. 3c. Security Risk No 3d. External Drivers ONC LEAP Grant 3e. Objectives/Deliverables and Target Dates September 2021 HL7 Connectathon January 2022 HL7 Connectathon January 2022 STU Ballot May 2022 STU Publication 3f. Common Names / Keywords / Aliases: CREDS 3g. Lineage CCRF 3h. Project Dependencies USCore FHIR Implementation Guide 3i. HL7-Managed Project Document Repository URL: https://confluence.hl7.org/display/CIC/CREDS+Document+Repository 3j. Backwards Compatibility No 3k. Additional Backwards Compatibility Information (if applicable) 3l. Using Current V3 Data Types? N/A 3l. Reason for not using current V3 data types? 3m. External Vocabularies 3n. List of Vocabularies 3o. Earliest prior release and/or version to which the compatibility applies 4a. Products FHIR Implementation Guide 4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to? R4 4c. FHIR Profiles Version 4d. Please define your New Product Definition 4d. Please define your New Product Family 5a. Project Intent Implementation Guide (IG) will be created/modified 5a. White Paper Type 5a. Is the project adopting/endorsing an externally developed IG? No 5a. Externally developed IG is to be (select one) 5a. Specify external organization 5a. Revising Current Standard Info 5b. Project Ballot Type STU to Normative 5c. Additional Ballot Info 5d. Joint Copyright No 5e. I understand I must submit a Joint Copyright Letter of Agreement to the TSC in order for the PSS to receive TSC approval. no 6a. External Project Collaboration 6b. Content Already Developed 6c. Content externally developed? No 6d. List Developers of Externally Developed Content 6e. Is this a hosted (externally funded) project? No 6f. Stakeholders Other 6f. Other Stakeholders Disease Registries 6g. Vendors EHR, PHR, Health Care IT, Clinical Decision Support Systems, Lab, HIS 6g. Other Vendors 6h. Providers Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health) 6h. Other Providers 6i. Realm U.S. Realm Specific 7d. US Realm Approval Date Jun 15, 2021 7a. Management Group(s) to Review PSS FHIR 7b. Sponsoring WG Approval Date Mar 25, 2021 7c. Co-Sponsor Approval Date May 06, 2021 7c. Co-Sponsor 2 Approval Date 7c. Co-Sponsor 3 Approval Date 7c. Co-Sponsor 4 Approval Date 7c. Co-Sponsor 5 Approval Date 7c. Co-Sponsor 6 Approval Date 7c. Co-Sponsor 7 Approval Date 7c. Co-Sponsor 8 Approval Date 7c. Co-Sponsor 9 Approval Date 7c. Co-Sponsor 10 Approval Date 7e. CDA MG Approval Date 7f. FMG Approval Date Jun 23, 2021 7g. V2 MG Approval Date 7h. Architecture Review Board Approval Date 7i. Steering Division Approval Date 7j. TSC Approval Date Jul 12, 2021