Skip to end of metadata
Go to start of metadata




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


Version

23

Modifier

Anne Wizauer

Modify Date

Aug 11, 2021 21:47

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 now proceeding to Normative directly or after being either Informative or STU?

No

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

2i. Domain Expert Representative

James Tcheng, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

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.

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

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Mar 25, 2021

7c. Co-Sponsor Approval Date

May 06, 2021

7d. US Realm Approval Date

Jun 15, 2021

7f. FMG Approval Date

Jun 23, 2021

7j. TSC Approval Date

Jul 12, 2021

Version

22

Modifier

David Pyke

Modify Date

Jun 29, 2021 20:37

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 now proceeding to Normative directly or after being either Informative or STU?

No

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

2i. Domain Expert Representative

James Tcheng, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

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.

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

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Mar 25, 2021

7c. Co-Sponsor Approval Date

May 06, 2021

7d. US Realm Approval Date

Jun 15, 2021

7f. FMG Approval Date

Jun 23, 2021

Version

21

Modifier

Dave Hamill

Modify Date

Jun 29, 2021 20:34

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 now proceeding to Normative directly or after being either Informative or STU?

No

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

2i. Domain Expert Representative

James Tcheng, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

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.

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:

TBA

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Mar 25, 2021

7c. Co-Sponsor Approval Date

May 06, 2021

7d. US Realm Approval Date

Jun 15, 2021

7f. FMG Approval Date

Jun 23, 2021

Version

20

Modifier

David Pyke

Modify Date

Jun 24, 2021 13:51

1a. Project Name

Clinical Registry Extraction and Data Submission (CREDS) IG

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

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

2i. Domain Expert Representative

James Tcheng, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

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.

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:

TBA

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Mar 25, 2021

7c. Co-Sponsor Approval Date

May 06, 2021

7d. US Realm Approval Date

Jun 15, 2021

7f. FMG Approval Date

Jun 23, 2021

Version

19

Modifier

David Pyke

Modify Date

Jun 16, 2021 17:15

1a. Project Name

Clinical Registry Extraction and Data Submission (CREDS) IG

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

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

2i. Domain Expert Representative

James Tcheng, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

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.

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:

TBA

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Mar 25, 2021

7c. Co-Sponsor Approval Date

May 06, 2021

7d. US Realm Approval Date

Jun 15, 2021

Version

18

Modifier

David Pyke

Modify Date

Jun 01, 2021 20:30

1a. Project Name

Clinical Registry Extraction and Data Submission (CREDS) IG

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

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

2i. Domain Expert Representative

James Tcheng, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

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.

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:

TBA

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Mar 25, 2021

7c. Co-Sponsor Approval Date

May 06, 2021

Version

17

Modifier

Keith W. Boone

Modify Date

May 13, 2021 20:41

1a. Project Name

Clinical Registry Extraction and Data Submission (CREDS) IG

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

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.)

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

2i. Domain Expert Representative

James Tcheng, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

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.

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

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

16

Modifier

Laura Heermann-Langford

Modify Date

May 13, 2021 18:43

1a. Project Name

Clinical Registry Extraction and Data Submission (CREDS) IG

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Clinical Interoperability Council

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

2i. Domain Expert Representative

James Tcheng, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

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 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.

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, but do not go into the essential details needed by provider organizations to automatically extract or transform data for submission. This guide will address those needs.

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

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

15

Modifier

Laura Heermann-Langford

Modify Date

May 13, 2021 18:27

1a. Project Name

Clinical Registry Data Extraction and Submission IG

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Clinical Interoperability Council

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

2i. Domain Expert Representative

James Tcheng, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

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 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.

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, but do not go into the essential details needed by provider organizations to automatically extract or transform data for submission. This guide will address those needs.

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

TBD

3h. Project Dependencies

USCore FHIR Implementation Guide

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

14

Modifier

Laura Heermann-Langford

Modify Date

May 13, 2021 18:24

1a. Project Name

Clinical Registry Data Extraction and Submission IG

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Clinical Interoperability Council

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

2i. Domain Expert Representative

James Tcheng, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

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 existing content available from Common Clinical Registry Framework (CCRF), US Core, Cancer Registry IG, MedMorph, mCode, eCR, et cetera, where applicable to demonstrate how systems implementing this IG can support those efforts.

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, but do not go into the essential details needed by provider organizations to automatically extract or transform data for submission. This guide will address those needs.

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

TBD

3h. Project Dependencies

USCore FHIR Implementation Guide

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

13

Modifier

Laura Heermann-Langford

Modify Date

May 13, 2021 18:19

1a. Project Name

Clinical Registry Data Extraction and Submission IG

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Clinical Interoperability Council

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

2i. Domain Expert Representative

James Tcheng, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

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 existing content available from US Core, Cancer Registry IG, MedMorph, mCode, eCR, et cetera, where applicable to demonstrate how systems implementing this IG can support those efforts.

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, but do not go into the essential details needed by provider organizations to automatically extract or transform data for submission. This guide will address those needs.

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

TBD

3h. Project Dependencies

USCore FHIR Implementation Guide

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

12

Modifier

David Pyke

Modify Date

May 11, 2021 19:19

1a. Project Name

Clinical Registry Data Extraction and Submission IG

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Clinical Interoperability Council

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

2i. Domain Expert Representative

James Tcheng, Samit Desai, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

2m. Implementers

ACC
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 existing content available from US Core, Cancer Registry IG, MedMorph, mCode, eCR, et cetera, where applicable to demonstrate how systems implementing this IG can support those efforts.

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, but do not go into the essential details needed by provider organizations to automatically extract or transform data for submission. This guide will address those needs.

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

TBD

3h. Project Dependencies

USCore FHIR Implementation Guide

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

11

Modifier

Keith W. Boone

Modify Date

Apr 29, 2021 20:37

1a. Project Name

Clinical Registry Data Extraction and Submission IG

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Clinical Interoperability Council

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

2i. Domain Expert Representative

James Tcheng, Samit Desai, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

2m. Implementers

ACC
CRISP
Audacious Inquiry

3a. Project Scope

The initial scope of this project is to advance registry infrastructure through modern APIs, specifically FHIR-based APIs. This project seeks to develop a framework for integrating registries into provider workflows by using and further constraining the FHIR standard and Bulk FHIR IG through a new FHIR IG.

This project will function as a as a flexible content extraction IG and build upon the MedMorph project and use CodeX, Women's Health CRN and other Implementation Guides and the CIC Common Clinical Registry Framework (CCRF) as a reference for ways to enhance these efforts.

While this project will build a IG that can be used and expanded upon for multiple registries, the initial use case will focus on the American College of Cariology (ACC) National Cardiovascular Data Registry (NCDR). More specifically, it will look at the CathPCI™ and Chest Pain-MI™ registries, both of which are national in scale and seek to improve the quality of care for patients who suffer a heart attack. These registries are optimal to test and pilot the acquisition of data from EMRs in a scalable, replicable fashion.

The goal of this project is to develop a IG that enables use of existing FHIR Resource profiles for registry submissions without requiring the development new FHIR profiles.

3b. Project Need

Healthcare providers submitting to disease registries have common problems with regard to the collection of data for a registry submission, preparing data for a submission, and submitting the data, but lack a FHIR IG that describes the artifacts that would help them to collect the data for and prepare a submission, and a description of the artifacts that would describe the data collection and submission process. The model in which FHIR profiles or logical models would need to be defined for submission for each disease registry to address its specific needs does not scale when there are hundreds of disease registries.

Existing IGs such as MedMorph and the Women's Health CRN provide a framework for submissions, but do not go into the essential details needed by provider organizations to automatically extract or transform data for submission. This guide will address those needs.

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

TBD

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

10

Modifier

Keith W. Boone

Modify Date

Apr 29, 2021 20:34

1a. Project Name

Clinical Registry Data Extraction and Submission IG

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Clinical Interoperability Council

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

2i. Domain Expert Representative

James Tcheng, Samit Desai, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

2m. Implementers

ACC
CRISP
Audacious Inquiry

3a. Project Scope

The initial scope of this project is to advance registry infrastructure through modern APIs, specifically FHIR-based APIs. This project seeks to develop a framework for integrating registries into provider workflows by using and further constraining the FHIR standard and Bulk FHIR IG through a new FHIR IG.

This project will function as a as a flexible content IG and build upon the MedMorph project and use CodeX, Women's Health CRN and other Implementation Guides and the CIC Common Clinical Registry Framework (CCRF) as a reference for ways to enhance these efforts.

While this project will build a IG that can be used and expanded upon for multiple registries, the initial use case will focus on the American College of Cariology (ACC) National Cardiovascular Data Registry (NCDR). More specifically, it will look at the CathPCI™ and Chest Pain-MI™ registries, both of which are national in scale and seek to improve the quality of care for patients who suffer a heart attack. These registries are optimal to test and pilot the acquisition of data from EMRs in a scalable, replicable fashion.

The goal of this project is to develop a IG that enables use of existing FHIR Resource profiles for registry submissions without requiring the development new FHIR profiles.

3b. Project Need

Healthcare providers submitting to disease registries have common problems with regard to the collection of data for a registry submission, preparing data for a submission, and submitting the data, but lack a FHIR IG that describes the artifacts that would help them to collect the data for and prepare a submission, and a description of the artifacts that would describe the data collection and submission process. The model in which FHIR profiles or logical models would need to be defined for submission for each disease registry to address its specific needs does not scale when there are hundreds of disease registries.

Existing IGs such as MedMorph and the Women's Health CRN provide a framework for submissions, but do not go into the essential details needed by provider organizations to automatically extract or transform data for submission. This guide will address those needs.

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

TBD

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

9

Modifier

Keith W. Boone

Modify Date

Apr 29, 2021 20:32

1a. Project Name

Clinical Registry Extraction and Data Submission IG

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Clinical Interoperability Council

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

2i. Domain Expert Representative

James Tcheng, Samit Desai, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

2m. Implementers

ACC
CRISP
Audacious Inquiry

3a. Project Scope

The initial scope of this project is to advance registry infrastructure through modern APIs, specifically FHIR-based APIs. This project seeks to develop a framework for integrating registries into provider workflows by using and further constraining the FHIR standard and Bulk FHIR IG through a new FHIR IG.

This project will function as a as a flexible content IG and build upon the MedMorph project and use CodeX, Women's Health CRN and other Implementation Guides and the CIC Common Clinical Registry Framework (CCRF) as a reference for ways to enhance these efforts.

While this project will build a IG that can be used and expanded upon for multiple registries, the initial use case will focus on the American College of Cariology (ACC) National Cardiovascular Data Registry (NCDR). More specifically, it will look at the CathPCI™ and Chest Pain-MI™ registries, both of which are national in scale and seek to improve the quality of care for patients who suffer a heart attack. These registries are optimal to test and pilot the acquisition of data from EMRs in a scalable, replicable fashion.

The goal of this project is to develop a IG that enables use of existing FHIR Resource profiles for registry submissions without requiring the development new FHIR profiles.

3b. Project Need

Healthcare providers submitting to disease registries have common problems with regard to the collection of data for a registry submission, preparing data for a submission, and submitting the data, but lack a FHIR IG that describes the artifacts that would help them to collect the data for and prepare a submission, and a description of the artifacts that would describe the data collection and submission process. The model in which FHIR profiles or logical models would need to be defined for submission for each disease registry to address its specific needs does not scale when there are hundreds of disease registries.

Existing IGs such as MedMorph and the Women's Health CRN provide a framework for submissions, but do not go into the essential details needed by provider organizations to automatically extract or transform data for submission. This guide will address those needs.

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

TBD

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

8

Modifier

Keith W. Boone

Modify Date

Apr 29, 2021 20:03

1a. Project Name

Clinical Registry Extraction and Data Submission IG

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Clinical Interoperability Council

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

2i. Domain Expert Representative

James Tcheng, Samit Desai, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

2m. Implementers

ACC
CRISP
Audacious Inquiry

3a. Project Scope

The initial scope of this project is to advance registry infrastructure through modern APIs, specifically FHIR-based APIs. This project seeks to develop a framework for integrating registries into provider workflows by using and further constraining the FHIR standard and Bulk FHIR IG through a new FHIR IG.

This project will build upon the MedMorph project as a flexible content IG and use CodeX, Women's Health CRN and other Implementation Guides and the CIC Common Clinical Registry Framework (CCRF) as a reference for ways to enhance these efforts.

While this project will build a IG that can be used and expanded upon for multiple registries, the initial use case will focus on the American College of Cariology (ACC) National Cardiovascular Data Registry (NCDR). More specifically, it will look at the CathPCI™ and Chest Pain-MI™ registries, both of which are national in scale and seek to improve the quality of care for patients who suffer a heart attack. These registries are optimal to test and pilot the acquisition of data from EMRs in a scalable, replicable fashion.

The goal of this project is to develop a IG that enables use of existing FHIR Resource profiles for registry submissions without requiring the development new FHIR profiles.

3b. Project Need

Healthcare providers submitting to disease registries have common problems with regard to the collection of data for a registry submission, preparing data for a submission, and submitting the data, but lack a FHIR IG that describes the artifacts that would help them to collect the data for and prepare a submission, and a description of the artifacts that would describe the data collection and submission process. The model in which FHIR profiles or logical models would need to be defined for submission for each disease registry to address its specific needs does not scale when there are hundreds of disease registries.

Existing IGs such as MedMorph and the Women's Health CRN provide a framework for submissions, but do not go into the essential details needed by provider organizations to automatically extract or transform data for submission. This guide will address those needs.

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

TBD

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

7

Modifier

Keith W. Boone

Modify Date

Apr 22, 2021 18:48

1a. Project Name

Clinical Registry Data Extraction and Submission IG

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Clinical Interoperability Council

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

2i. Domain Expert Representative

James Tcheng, Samit Desai, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

2m. Implementers

ACC
CRISP
Audacious Inquiry

3a. Project Scope

The initial scope of this project is to advance registry infrastructure through modern APIs, specifically FHIR-based APIs. This project seeks to develop a framework for integrating registries into provider workflows by using and further constraining the FHIR standard and Bulk FHIR IG through a new FHIR IG.

This project will build upon the MedMorph project as a flexible content IG and use CodeX, Women's Health CRN and other Implementation Guides and the CIC Common Clinical Registry Framework (CCRF) as a reference for ways to enhance these efforts.

While this project will build a IG that can be used and expanded upon for multiple registries, the initial use case will focus on the American College of Cariology (ACC) National Cardiovascular Data Registry (NCDR). More specifically, it will look at the CathPCI™ and Chest Pain-MI™ registries, both of which are national in scale and seek to improve the quality of care for patients who suffer a heart attack. These registries are optimal to test and pilot the acquisition of data from EMRs in a scalable, replicable fashion.

The goal of this project is to develop a IG that enables use of existing FHIR Resource profiles for registry submissions without requiring the development new FHIR profiles.

3b. Project Need

Healthcare providers submitting to disease registries have common problems with regard to the collection of data for a registry submission, preparing data for a submission, and submitting the data, but lack a FHIR IG that describes the artifacts that would help them to collect the data for and prepare a submission, and a description of the artifacts that would describe the data collection and submission process. The model in which FHIR profiles or logical models would need to be defined for submission for each disease registry to address its specific needs does not scale when there are hundreds of disease registries.

Existing IGs such as MedMorph and the Women's Health CRN provide a framework for submissions, but do not go into the essential details needed by provider organizations to automatically extract or transform data for submission. This guide will address those needs.

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

TBD

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

6

Modifier

Keith W. Boone

Modify Date

Apr 22, 2021 18:35

1a. Project Name

Clinical Registry Data Extraction and Submission IG

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Clinical Interoperability Council

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

2i. Domain Expert Representative

James Tcheng, Samit Desai, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

2m. Implementers

ACC
CRISP
Audacious Inquiry

3a. Project Scope

The initial scope of this project is to advance registry infrastructure through modern APIs, specifically FHIR-based APIs. This project seeks to develop a framework for integrating registries into provider workflows by using and further constraining the FHIR standard and Bulk FHIR IG through a new FHIR IG.

This project will build upon the MedMorph project as a flexible content IG and use CodeX, Women's Health CRN and other Implementation Guides and the CIC Common Clinical Registry Framework (CCRF) as a reference for ways to enhance these efforts.

While this project will build a IG that can be used and expanded upon for multiple registries, the initial use case will focus on the American College of Cariology (ACC) National Cardiovascular Data Registry (NCDR). More specifically, it will look at the CathPCI™ and Chest Pain-MI™ registries, both of which are national in scale and seek to improve the quality of care for patients who suffer a heart attack. These registries are optimal to test and pilot the acquisition of data from EMRs in a scalable, replicable fashion.


3b. Project Need

Healthcare providers submitting to disease registries have common problems with regard to the collection of data for a registry submission, preparing data for a submission, and submitting the data, but lack a FHIR IG that describes the artifacts that would help them to prepare a submission, and a description of the artifacts that would describe a submission. The model in which FHIR profiles or logical models would be defined for each disease registry to address its specific needs does not scale when there are hundreds of disease registries.

Existing IGs such as MedMorph and the Women's Health CRN provide a framework for submissions, but do not go into the essential details needed by provider organizations to extract or transform data for submission. This guide will address those needs.

This project proposal addresses the need to provide a common framework 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

TBD

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

5

Modifier

David Pyke

Modify Date

Apr 15, 2021 20:22

1a. Project Name

Disease Registry Data Extraction and Submission Framework

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Clinical Interoperability Council

2d. Project Facilitator

Dave Pyke

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

2i. Domain Expert Representative

James Tcheng, Samit Desai, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

2m. Implementers

ACC
CRISP
Audacious Inquiry

3a. Project Scope

The initial scope of this project is to advance registry infrastructure through modern APIs, specifically FHIR-based APIs. This project seeks to develop a framework for integrating registries into provider workflows by using and further constraining the FHIR standard and Bulk FHIR IG through a new FHIR IG.

While this project will build a framework that can be used and expanded upon for multiple registries, the initial use case will focus on the American College of Cariology (ACC) National Cardiovascular Data Registry (NCDR). More specifically, it will look at the CathPCI™ and Chest Pain-MI™ registries, both of which are national in scale and seek to improve the quality of care for patients who suffer a heart attack. These registries are optimal to test and pilot the acquisition of data from EMRs in a scalable, replicable fashion.

This project will build upon the MedMorph project as a flexible content IG and use CodeX, Women's Health CRN and other Implementation Guides as a reference for ways to enhance these efforts.

3b. Project Need

Healthcare providers submitting to disease registries have common problems with regard to the collection of data for a registry submission, preparing data for a submission, and submitting the data, but lack a FHIR IG that describes the artifacts that would help them to prepare a submission, and a description of the artifacts that would describe a submission. The model in which FHIR profiles or logical models would be defined for each disease registry to address its specific needs does not scale when there are hundreds of disease registries.

Existing IGs such as MedMorph and the Women's Health CRN provide a framework for submissions, but do not go into the essential details needed by provider organizations to extract or transform data for submission. This guide will address those needs.

This project proposal addresses the need to provide a common framework 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

TBD

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

4

Modifier

David Pyke

Modify Date

Apr 15, 2021 20:19

1a. Project Name

Disease Registry Data Extraction and Submission Framework

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Clinical Interoperability Council

2d. Project Facilitator

Dave Pyke

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

2i. Domain Expert Representative

James Tcheng, Samit Desai, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

2m. Implementers

ACC
CRISP
Audacious Inquiry

3a. Project Scope

The initial scope of this project is to advance registry infrastructure through modern APIs, specifically FHIR-based APIs. This project seeks to develop a framework for integrating registries into provider workflows by using and further constraining the FHIR standard and Bulk FHIR IG through a new FHIR IG.

While this project will build a framework that can be used and expanded upon for multiple registries, the initial use case will focus on the American College of Cariology (ACC) National Cardiovascular Data Registry (NCDR). More specifically, it will look at the CathPCI™ and Chest Pain-MI™ registries, both of which are national in scale and seek to improve the quality of care for patients who suffer a heart attack. These registries are optimal to test and pilot the acquisition of data from EMRs in a scalable, replicable fashion.

This project will build upon the MedMorph project and the as a flexible content IG and use CodeX and other Implementation Guides as a reference for ways to enhance these efforts.

3b. Project Need

Healthcare providers submitting to disease registries have common problems with regard to the collection of data for a registry submission, preparing data for a submission, and submitting the data, but lack a FHIR IG that describes the artifacts that would help them to prepare a submission, and a description of the artifacts that would describe a submission. The model in which FHIR profiles or logical models would be defined for each disease registry to address its specific needs does not scale when there are hundreds of disease registries.

Existing IGs such as MedMorph and the Women's Health CRN provide a framework for submissions, but do not go into the essential details needed by provider organizations to extract or transform data for submission. This guide will address those needs.

This project proposal addresses the need to provide a common framework 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

TBD

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

3

Modifier

Keith W. Boone

Modify Date

Apr 07, 2021 19:57

1a. Project Name

Disease Registry Data Extraction and Submission Framework

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Clinical Interoperability Council

2d. Project Facilitator

Dave Pyke

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

2i. Domain Expert Representative

James Tcheng, Samit Desai, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

2m. Implementers

ACC
CRISP
Audacious Inquiry

3a. Project Scope

The initial scope of this project is to advance registry infrastructure through modern APIs, specifically FHIR-based APIs. This project seeks to develop a framework for integrating registries into provider workflows by using and further constraining the FHIR standard and Bulk FHIR IG through a new FHIR IG.

While this project will build a framework that can be used and expanded upon for multiple registries, the initial use case will focus on the American College of Cariology (ACC) National Cardiovascular Data Registry (NCDR). More specifically, it will look at the CathPCI™ and Chest Pain-MI™ registries, both of which are national in scale and seek to improve the quality of care for patients who suffer a heart attack. These registries are optimal to test and pilot the acquisition of data from EMRs in a scalable, replicable fashion.

3b. Project Need

Healthcare providers submitting to disease registries have common problems with regard to the collection of data for a registry submission, preparing data for a submission, and submitting the data, but lack a FHIR IG that describes the artifacts that would help them to prepare a submission, and a description of the artifacts that would describe a submission. The model in which FHIR profiles or logical models would be defined for each disease registry to address its specific needs does not scale when there are hundreds of disease registries.

Existing IGs such as MedMorph and the Women's Health CRN provide a framework for submissions, but do not go into the essential details needed by provider organizations to extract or transform data for submission. This guide will address those needs.

This project proposal addresses the need to provide a common framework 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

TBD

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

2

Modifier

Keith W. Boone

Modify Date

Apr 07, 2021 19:52

1a. Project Name

Disease Registry Data Extraction and Submission Framework

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Clinical Interoperability Council

2d. Project Facilitator

Dave Pyke

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

2i. Domain Expert Representative

James Tcheng, Samit Desai, Ganesan Srinivasan

2j. Business Requirements Analyst

Nick Ramsing

2k. Conformance Facilitator

Dave Pyke

2m. Implementers

ACC
CRISP
Audacious Inquiry

3a. Project Scope

The initial scope of this project is to advance registry infrastructure through modern APIs, specifically FHIR-based APIs. This project seeks to develop a framework for integrating registries into provider workflows by using and further constraining the FHIR standard and Bulk FHIR IG through a new FHIR IG.

While this project will build a framework that can be used and expanded upon for multiple registries, the initial use case will focus on the American College of Cariology (ACC) National Cardiovascular Data Registry (NCDR). More specifically, it will look at the CathPCI™ and Chest Pain-MI™ registries, both of which are national in scale and seek to improve the quality of care for patients who suffer a heart attack. These registries are optimal to test and pilot the acquisition of data from EMRs in a scalable, replicable fashion.

3b. Project Need

Existing IGs such as MedMorph and the Women's Health CRN provide a framework for submissions, but do not go into the essential details needed by provider organizations to extract or transform data for submission. This guide will address those needs.


This project proposal addresses the need to provide a common framework 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

TBD

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

1

Modifier

Keith W. Boone

Modify Date

Apr 07, 2021 19:28

1a. Project Name

Disease Registry Data Extraction and Submission Framework

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Clinical Interoperability Council

2d. Project Facilitator

Keith Boone

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

Dave Pyke

2i. Domain Expert Representative

James Tcheng, Samit Desai, Ganesan Srinivasan

2k. Conformance Facilitator

Dave Pyke

2m. Implementers

ACC
CRISP
Audacious Inquiry

3a. Project Scope

The initial scope of this project is to advance registry infrastructure through modern APIs, specifically FHIR-based APIs. This project seeks to develop a framework for integrating registries into provider workflows by using and further constraining the FHIR standard and Bulk FHIR IG through a new FHIR IG.

While this project will build a framework that can be used and expanded upon for multiple registries, the initial use case will focus on the American College of Cariology (ACC) National Cardiovascular Data Registry (NCDR). More specifically, it will look at the CathPCI™ and Chest Pain-MI™ registries, both of which are national in scale and seek to improve the quality of care for patients who suffer a heart attack. These registries are optimal to test and pilot the acquisition of data from EMRs in a scalable, replicable fashion.

3b. Project Need

Existing IGs such as MedMorph and the Women's Health CRN provide a framework for submissions, but do not go into the essential details needed by provider organizations to extract or transform data for submission. This guide will address those needs.


This project proposal addresses the need to provide a common framework 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

TBD

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

N/A

4a. Products

FHIR Implementation Guide

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. Is the project adopting/endorsing an externally developed IG?

No

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6c. Content externally developed?

No

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

6h. Providers

Local and State Departments of Health, Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR