Page tree
Skip to end of metadata
Go to start of metadata




1a. Project Name

Patient Corrections FHIR Implementation Guide Project

1b. Project ID

1645

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

Patient Empowerment

2d. Project Facilitator

Debi Willis

2e. Other Interested Parties (and roles)

Vulcan

2f. Modeling Facilitator

2g. Publishing Facilitator

2h. Vocabulary Facilitator

2i. Domain Expert Representative

2j. Business Requirements Analyst

2k. Conformance Facilitator

unknown

2l. Other Facilitators

2m. Implementers

PatientLink (Debi Willis), MaxMD (Lisa Nelson)

3a. Project Scope

The purpose of this project is to build a FHIR Implementation Guide to provide a standard way to communicate information required to support a patient request for corrections workflow.

Attachments

3b. Project Need

Now that patients have the ability to download their data into FHIR applications, they are finding errors in their data. Currently, no FHIR implementation guide exists to standardize the method of electronically exchanging the required information to facilitate the patient’s request for corrections to their information. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA implementation guidelines.

HIPAA has a very detailed implementation specification for a patient’s request for corrections to their information. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.

HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data corrected. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

3c. Security Risk

No

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

Complete analysis, design, draft specification work 2020 Dec

Submit for STU Ballot (First Ballot Cycle) 2021 May Ballot/ WGM

STU Reconciliation 2021 May Ballot/ WGM

Submit for 2nd STU Ballot 2021 Sept Ballot/ WGM

Request TSC Approval for STU publication 2022 Jan Ballot/WGM

STU Period – 12 months Jan, 2022 – Jan, 2023

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record/Amendment to PHI/ Rectification to PHI

3g. Lineage

3h. Project Dependencies

none

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/PE/Patient+Corrections

3j. Backwards Compatibility

No

3k. Additional Backwards Compatibility Information (if applicable)

3l. Using Current V3 Data Types?

Unknown

3l. Reason for not using current V3 data types?

3m. External Vocabularies

Unknown

3n. List of Vocabularies

3o. Earliest prior release and/or version to which the compatibility applies

FHIR R4

4a. Products

FHIR Implementation Guide, FHIR Profiles

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

none

6b. Content Already Developed

5%

6c. Content externally developed?

No

6d. List Developers of Externally Developed Content

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Regulatory Agency, Standards Development Organizations (SDOs), Payors

6f. Other Stakeholders

6g. Vendors

EHR, PHR, Equipment, Health Care IT

6g. Other Vendors

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health), Other

6h. Other Providers

clinicians, patients, researchers

6i. Realm

Universal

7d. US Realm Approval Date

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Jul 30, 2020

7c. Co-Sponsor Approval Date

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

Aug 05, 2020

7g. V2 MG Approval Date

7h. Architecture Review Board Approval Date

7i. Steering Division Approval Date

7j. TSC Approval Date



 Show Changes

Version

22

Modifier

Virginia Lorenzi

Modify Date

Aug 05, 2020 22:16

1a. Project Name

Patient Corrections FHIR Implementation Guide Project

1b. Project ID

1645

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

Payer/Provider Information Exchange

2d. Project Facilitator

Debi Willis

2e. Other Interested Parties (and roles)

Vulcan

2k. Conformance Facilitator

unknown

2m. Implementers

PatientLink (Debi Willis), MaxMD (Lisa Nelson)

3a. Project Scope

The purpose of this project is to build a FHIR Implementation Guide to provide a standard way to communicate information required to support a patient request for corrections workflow.

Attachments

3b. Project Need

Now that patients have the ability to download their data into FHIR applications, they are finding errors in their data. Currently, no FHIR implementation guide exists to standardize the method of electronically exchanging the required information to facilitate the patient’s request for corrections to their information. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA implementation guidelines.

HIPAA has a very detailed implementation specification for a patient’s request for corrections to their information. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.

HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data corrected. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

3c. Security Risk

No

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

Complete analysis, design, draft specification work 2020 Dec

Submit for STU Ballot (First Ballot Cycle) 2021 May Ballot/ WGM

STU Reconciliation 2021 May Ballot/ WGM

Submit for 2nd STU Ballot 2021 Sept Ballot/ WGM

Request TSC Approval for STU publication 2022 Jan Ballot/WGM

STU Period – 12 months Jan, 2022 – Jan, 2023

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record/Amendment to PHI/ Rectification to PHI

3h. Project Dependencies

none

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/PE/Patient+Corrections

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

Unknown

3m. External Vocabularies

Unknown

3o. Earliest prior release and/or version to which the compatibility applies

FHIR R4

4a. Products

FHIR Implementation Guide, FHIR Profiles

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

6a. External Project Collaboration

none

6b. Content Already Developed

5%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Regulatory Agency, Standards Development Organizations (SDOs), Payors

6g. Vendors

EHR, PHR, Equipment, Health Care IT

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health), Other

6h. Other Providers

clinicians, patients, researchers

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Jul 30, 2020

7f. FMG Approval Date

Aug 05, 2020

Version

21

Modifier

Dave Hamill

Modify Date

Aug 03, 2020 13:45

1a. Project Name

Patient Corrections FHIR Implementation Guide Project

1b. Project ID

1645

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

Payer/Provider Information Exchange

2d. Project Facilitator

Debi Willis

2e. Other Interested Parties (and roles)

Vulcan

2k. Conformance Facilitator

unknown

2m. Implementers

PatientLink (Debi Willis), MaxMD (Lisa Nelson)

3a. Project Scope

The purpose of this project is to build a FHIR Implementation Guide to provide a standard way to communicate information required to support a patient request for corrections workflow.

Attachments

3b. Project Need

Now that patients have the ability to download their data into FHIR applications, they are finding errors in their data. Currently, no FHIR implementation guide exists to standardize the method of electronically exchanging the required information to facilitate the patient’s request for corrections to their information. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA implementation guidelines.

HIPAA has a very detailed implementation specification for a patient’s request for corrections to their information. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.

HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data corrected. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

3c. Security Risk

No

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

Complete analysis, design, draft specification work 2020 Dec

Submit for STU Ballot (First Ballot Cycle) 2021 May Ballot/ WGM

STU Reconciliation 2021 May Ballot/ WGM

Submit for 2nd STU Ballot 2021 Sept Ballot/ WGM

Request TSC Approval for STU publication 2022 Jan Ballot/WGM

STU Period – 12 months Jan, 2022 – Jan, 2023

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record/Amendment to PHI/ Rectification to PHI

3h. Project Dependencies

none

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/PE/Patient+Corrections

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

Unknown

3m. External Vocabularies

Unknown

3o. Earliest prior release and/or version to which the compatibility applies

FHIR R4

4a. Products

FHIR Implementation Guide, FHIR Profiles

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

6a. External Project Collaboration

none

6b. Content Already Developed

5%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Regulatory Agency, Standards Development Organizations (SDOs), Payors

6g. Vendors

EHR, PHR, Equipment, Health Care IT

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health), Other

6h. Other Providers

clinicians, patients, researchers

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Jul 30, 2020

Version

20

Modifier

Virginia Lorenzi

Modify Date

Jul 31, 2020 05:38

1a. Project Name

Patient Corrections FHIR Implementation Guide Project

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

Payer/Provider Information Exchange

2d. Project Facilitator

Debi Willis

2e. Other Interested Parties (and roles)

Vulcan

2k. Conformance Facilitator

unknown

2m. Implementers

PatientLink (Debi Willis), MaxMD (Lisa Nelson)

3a. Project Scope

The purpose of this project is to build a FHIR Implementation Guide to provide a standard way to communicate information required to support a patient request for corrections workflow.

Attachments

3b. Project Need

Now that patients have the ability to download their data into FHIR applications, they are finding errors in their data. Currently, no FHIR implementation guide exists to standardize the method of electronically exchanging the required information to facilitate the patient’s request for corrections to their information. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA implementation guidelines.

HIPAA has a very detailed implementation specification for a patient’s request for corrections to their information. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.

HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data corrected. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

3c. Security Risk

No

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

Complete analysis, design, draft specification work 2020 Dec

Submit for STU Ballot (First Ballot Cycle) 2021 May Ballot/ WGM

STU Reconciliation 2021 May Ballot/ WGM

Submit for 2nd STU Ballot 2021 Sept Ballot/ WGM

Request TSC Approval for STU publication 2022 Jan Ballot/WGM

STU Period – 12 months Jan, 2022 – Jan, 2023

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record/Amendment to PHI/ Rectification to PHI

3h. Project Dependencies

none

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/PE/Patient+Corrections

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

Unknown

3m. External Vocabularies

Unknown

3o. Earliest prior release and/or version to which the compatibility applies

FHIR R4

4a. Products

FHIR Implementation Guide, FHIR Profiles

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

6a. External Project Collaboration

none

6b. Content Already Developed

5%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Regulatory Agency, Standards Development Organizations (SDOs), Payors

6g. Vendors

EHR, PHR, Equipment, Health Care IT

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health), Other

6h. Other Providers

clinicians, patients, researchers

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Jul 30, 2020

Version

19

Modifier

Debi Willis

Modify Date

Jul 30, 2020 18:03

1a. Project Name

Patient Corrections FHIR Implementation Guide Project

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

Payer/Provider Information Exchange

2d. Project Facilitator

Debi Willis

2e. Other Interested Parties (and roles)

Vulcan

2k. Conformance Facilitator

unknown

2m. Implementers

PatientLink (Debi Willis), MaxMD (Lisa Nelson)

3a. Project Scope

The purpose of this project is to build a FHIR Implementation Guide to provide a standard way to communicate information required to support a patient request for corrections workflow.

Attachments

3b. Project Need

Now that patients have the ability to download their data into FHIR applications, they are finding errors in their data. Currently, no FHIR implementation guide exists to standardize the method of electronically exchanging the required information to facilitate the patient’s request for corrections to their information. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA implementation guidelines.

HIPAA has a very detailed implementation specification for a patient’s request for corrections to their information. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.

HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data corrected. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

3c. Security Risk

No

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

Complete analysis, design, draft specification work 2020 Dec

Submit for STU Ballot (First Ballot Cycle) 2021 May Ballot/ WGM

STU Reconciliation 2021 May Ballot/ WGM

Submit for 2nd STU Ballot 2021 Sept Ballot/ WGM

Request TSC Approval for STU publication 2022 Jan Ballot/WGM

STU Period – 12 months Jan, 2022 – Jan, 2023

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record/Amendment to PHI/ Rectification to PHI

3h. Project Dependencies

none

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/PE/Patient+Corrections

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

Unknown

3m. External Vocabularies

Unknown

3o. Earliest prior release and/or version to which the compatibility applies

FHIR R4

4a. Products

FHIR Implementation Guide, FHIR Profiles

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

6a. External Project Collaboration

none

6b. Content Already Developed

5%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Regulatory Agency, Standards Development Organizations (SDOs), Payors

6g. Vendors

EHR, PHR, Equipment, Health Care IT

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health), Other

6h. Other Providers

clinicians, patients, researchers

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

Version

18

Modifier

Terrie Reed

Modify Date

Jul 30, 2020 14:34

1a. Project Name

Patient Corrections FHIR Implementation Guide Project

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

Payer/Provider Information Exchange

2d. Project Facilitator

Debi Willis

2e. Other Interested Parties (and roles)

Vulcan

2k. Conformance Facilitator

unknown

2m. Implementers

PatientLink (MyLinks) FIND ANOTHER IMPLEMENTER

3a. Project Scope

The purpose of this project is to build a FHIR Implementation Guide to provide a standard way to communicate information required to support a patient request for corrections (does this include additions?) workflow. We will use the HIPAA specifications for our basis because it includes the patient rights outlined in both HIPAA and GDPR regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

Attachments

3b. Project Need

Now that patients have the ability to download their data into FHIR applications, they are finding errors in their data. Currently, no FHIR implementation guide exists to standardize the method of electronically exchanging the required information to facilitate the patient’s request for corrections to their information. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA implementation guidelines.

HIPAA has a very detailed implementation specification for a patient’s request for corrections to their information. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.

HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data corrected. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

3c. Security Risk

No

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

Complete analysis, design, draft specification work 2020 Dec

Submit for STU Ballot (First Ballot Cycle) 2021 May Ballot/ WGM

STU Reconciliation 2021 May Ballot/ WGM

Submit for 2nd STU Ballot 2021 Sept Ballot/ WGM

Request TSC Approval for STU publication 2022 Jan Ballot/WGM

STU Period – 12 months Jan, 2022 – Jan, 2023

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record/Amendment to PHI/ Rectification to PHI

3h. Project Dependencies

none

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/PE/Patient+Corrections

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

Unknown

3m. External Vocabularies

Unknown

3o. Earliest prior release and/or version to which the compatibility applies

FHIR R4

4a. Products

FHIR Implementation Guide, FHIR Profiles

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

6a. External Project Collaboration

none

6b. Content Already Developed

5%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Regulatory Agency, Standards Development Organizations (SDOs), Payors

6g. Vendors

EHR, PHR, Equipment, Health Care IT

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health), Other

6h. Other Providers

clinicians

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

Version

17

Modifier

Terrie Reed

Modify Date

Jul 30, 2020 14:31

1a. Project Name

Patient Corrections FHIR Implementation Guide Project

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

Payer/Provider Information Exchange

2d. Project Facilitator

Debi Willis

2e. Other Interested Parties (and roles)

Vulcan

2k. Conformance Facilitator

unknown

2m. Implementers

PatientLink (MyLinks) FIND ANOTHER IMPLEMENTER

3a. Project Scope

The purpose of this project is to build a FHIR Implementation Guide to provide a standard way to communicate information required to support a patient request for corrections (does this include additions?) workflow. We will use the HIPAA specifications for our basis because it includes the patient rights outlined in both HIPAA and GDPR regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

Attachments

3b. Project Need

Now that patients have the ability to download their data into FHIR applications, they are finding errors in their data. Currently, no FHIR implementation guide exists to standardize the method of electronically exchanging the required information to facilitate the patient’s request for corrections to their information. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA implementation guidelines.

HIPAA has a very detailed implementation specification for a patient’s request for corrections to their information. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.

HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data corrected. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

3c. Security Risk

No

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

Complete analysis, design, draft specification work 2020 Dec

Submit for STU Ballot (First Ballot Cycle) 2021 May Ballot/ WGM

STU Reconciliation 2021 May Ballot/ WGM

Submit for 2nd STU Ballot 2021 Sept Ballot/ WGM

Request TSC Approval for STU publication 2022 Jan Ballot/WGM

STU Period – 12 months Jan, 2022 – Jan, 2023

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record/Amendment to PHI/ Rectification to PHI

3h. Project Dependencies

none

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/PE/Patient+Corrections

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

Unknown

3m. External Vocabularies

Unknown

3o. Earliest prior release and/or version to which the compatibility applies

FHIR R4

4a. Products

FHIR Implementation Guide, FHIR Profiles

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

6a. External Project Collaboration

none

6b. Content Already Developed

5%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Payors

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health), Other

6h. Other Providers

clinicians

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

Version

16

Modifier

Debi Willis

Modify Date

Jul 29, 2020 18:25

1a. Project Name

Patient Corrections FHIR Implementation Guide Project

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

Payer/Provider Information Exchange

2d. Project Facilitator

Debi Willis

2e. Other Interested Parties (and roles)

Vulcan

2k. Conformance Facilitator

unknown

2m. Implementers

PatientLink (MyLinks) FIND ANOTHER IMPLEMENTER

3a. Project Scope

The purpose of this project is to build a FHIR Implementation Guide to provide a standard way to communicate information required to support a patient request for corrections workflow. We will use the HIPAA specifications for our basis because it includes the patient rights outlined in both HIPAA and GDPR regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

Attachments

3b. Project Need

Now that patients have the ability to download their data into FHIR applications, they are finding errors in their data. Currently, no FHIR implementation guide exists to standardize the method of electronically exchanging the required information to facilitate the patient’s request for corrections to their information. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA implementation guidelines.

HIPAA has a very detailed implementation specification for a patient’s request for corrections to their information. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.

HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data corrected. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

3c. Security Risk

No

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

Complete analysis, design, draft specification work 2020 Dec

Submit for STU Ballot (First Ballot Cycle) 2021 May Ballot/ WGM

STU Reconciliation 2021 May Ballot/ WGM

Submit for 2nd STU Ballot 2021 Sept Ballot/ WGM

Request TSC Approval for STU publication 2022 Jan Ballot/WGM

STU Period – 12 months Jan, 2022 – Jan, 2023

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record/Amendment to PHI/ Rectification to PHI

3h. Project Dependencies

none

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/PE/Patient+Corrections

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

Unknown

3m. External Vocabularies

Unknown

3o. Earliest prior release and/or version to which the compatibility applies

FHIR R4

4a. Products

FHIR Implementation Guide, FHIR Profiles

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

6a. External Project Collaboration

none

6b. Content Already Developed

5%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Payors

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health), Other

6h. Other Providers

clinicians

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

Version

15

Modifier

Debi Willis

Modify Date

Jul 25, 2020 00:58

1a. Project Name

Patient Corrections FHIR Implementation Guide Project

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

Payer/Provider Information Exchange

2b. Co-Sponsor WG

Patient Care

2d. Project Facilitator

Debi Willis

2e. Other Interested Parties (and roles)

Vulcan

2k. Conformance Facilitator

unknown

2m. Implementers

PatientLink (MyLinks) FIND ANOTHER IMPLEMENTER

3a. Project Scope

The purpose of this project is to build a FHIR Implementation Guide to provide a standard way to communicate information required to support a patient request for corrections workflow. We will use the HIPAA specifications for our basis because it includes the patient rights outlined in both HIPAA and GDPR regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

Attachments

3b. Project Need

Now that patients have the ability to download their data into FHIR applications, they are finding errors in their data. Currently, no FHIR implementation guide exists to standardize the method of electronically exchanging the required information to facilitate the patient’s request for corrections to their information. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA implementation guidelines.

HIPAA has a very detailed implementation specification for a patient’s request for corrections to their information. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.

HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data corrected. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

3c. Security Risk

No

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

Complete analysis, design, draft specification work 2020 Dec

Submit for STU Ballot (First Ballot Cycle) 2021 May Ballot/ WGM

STU Reconciliation 2021 May Ballot/ WGM

Submit for 2nd STU Ballot 2021 Sept Ballot/ WGM

Request TSC Approval for STU publication 2022 Jan Ballot/WGM

STU Period – 12 months Jan, 2022 – Jan, 2023

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record/Amendment to PHI/ Rectification to PHI

3h. Project Dependencies

none

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/PE/Patient+Corrections

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

Unknown

3m. External Vocabularies

Unknown

3o. Earliest prior release and/or version to which the compatibility applies

FHIR R4

4a. Products

FHIR Implementation Guide, FHIR Profiles

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

6a. External Project Collaboration

none

6b. Content Already Developed

5%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Payors

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health), Other

6h. Other Providers

clinicians

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

Version

14

Modifier

Debi Willis

Modify Date

Jul 25, 2020 00:53

1a. Project Name

Patient Corrections FHIR Implementation Guide Project

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

Payer/Provider Information Exchange

2b. Co-Sponsor WG

Patient Care

2d. Project Facilitator

Debi Willis

2e. Other Interested Parties (and roles)

Vulcan

2k. Conformance Facilitator

unknown

2m. Implementers

PatientLink (MyLinks) FIND ANOTHER IMPLEMENTER

3a. Project Scope

The purpose of this project is to build a FHIR Implementation Guide to provide a standard way to communicate information required to support a patient request for corrections workflow. We will use the HIPAA specifications for our basis because it includes the patient rights outlined in both HIPAA and GDPR regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

Attachments

3b. Project Need

Now that patients have the ability to download their data into FHIR applications, they are finding errors in their data. Currently, no FHIR implementation guide exists to standardize the method of electronically exchanging the required information to facilitate the patient’s request for corrections to their information. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA implementation guidelines.

HIPAA has a very detailed implementation specification for a patient’s request for corrections to their information. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.

HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data corrected. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

3c. Security Risk

No

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

Complete analysis, design, draft specification work 2020 Dec

Submit for STU Ballot (First Ballot Cycle) 2021 May Ballot/ WGM

STU Reconciliation 2021 May Ballot/ WGM

Submit for 2nd STU Ballot 2021 Sept Ballot/ WGM

Request TSC Approval for STU publication 2022 Jan Ballot/WGM

STU Period – 12 months Jan, 2022 – Jan, 2023

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record/Amendment to PHI/ GDPR WORD HERE

3h. Project Dependencies

none

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/PE/Patient+Corrections

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

Unknown

3m. External Vocabularies

Unknown

3o. Earliest prior release and/or version to which the compatibility applies

FHIR R4

4a. Products

FHIR Implementation Guide, FHIR Profiles

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

6a. External Project Collaboration

none

6b. Content Already Developed

5%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Payors

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health), Other

6h. Other Providers

clinicians

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

Version

13

Modifier

Debi Willis

Modify Date

Jul 25, 2020 00:37

1a. Project Name

Patient Corrections FHIR Implementation Guide Project

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

Payer/Provider Information Exchange

2b. Co-Sponsor WG

Patient Care

2d. Project Facilitator

Debi Willis

2e. Other Interested Parties (and roles)

Vulcan

2k. Conformance Facilitator

unknown

2m. Implementers

PatientLink (MyLinks) FIND ANOTHER IMPLEMENTER

3a. Project Scope

The purpose of this project is to build a FHIR Implementation Guide to provide a standard way to communicate information required to support a patient request for corrections workflow. We will use the HIPAA specifications for our basis because it includes the patient rights outlined in both HIPAA and GDPR regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

Attachments

3b. Project Need

Now that patients have the ability to download their data into FHIR applications, they are finding errors in their data. Currently, no FHIR implementation guide exists to standardize the method of electronically exchanging the required information to facilitate the patient’s request for corrections to their information. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA implementation guidelines.

HIPAA has a very detailed implementation specification for a patient’s request for corrections to their information. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.

HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data corrected. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

3c. Security Risk

No

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

Complete analysis, design, draft specification work 2020 Dec

Submit for STU Ballot (First Ballot Cycle) 2021 May Ballot/ WGM

STU Reconciliation 2021 May Ballot/ WGM

Submit for 2nd STU Ballot 2021 Sept Ballot/ WGM

Request TSC Approval for STU publication 2022 Jan Ballot/WGM

STU Period – 12 months Jan, 2022 – Jan, 2023

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record/Amendment to PHI/ GDPR WORD HERE

3h. Project Dependencies

none

3i. HL7-Managed Project Document Repository URL:

CREATE PROJECT PAGE

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

Unknown

3m. External Vocabularies

Unknown

3o. Earliest prior release and/or version to which the compatibility applies

FHIR R4

4a. Products

FHIR Implementation Guide, FHIR Profiles

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

6a. External Project Collaboration

none

6b. Content Already Developed

5%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Payors

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health), Other

6h. Other Providers

clinicians

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

Version

12

Modifier

Debi Willis

Modify Date

Jul 25, 2020 00:35

1a. Project Name

Patient Corrections FHIR Implementation Guide Project

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

Payer/Provider Information Exchange

2b. Co-Sponsor WG

Patient Care

2d. Project Facilitator

Debi Willis

2e. Other Interested Parties (and roles)

Vulcan

2k. Conformance Facilitator

unknown

2m. Implementers

PatientLink (MyLinks) FIND ANOTHER IMPLEMENTER

3a. Project Scope

The purpose of this project is to build a FHIR Implementation Guide to provide a standard way to communicate information required to support a patient request for corrections workflow. We will use the HIPAA specifications for our basis because it includes the patient rights outlined in both HIPAA and GDPR regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

Attachments

3b. Project Need

Now that patients have the ability to download their data into FHIR applications, they are finding errors in their data. Currently, no FHIR implementation guide exists to standardize the method of electronically exchanging the required information to facilitate the patient’s request for corrections to their information. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA implementation guidelines.

HIPAA has a very detailed implementation specification for a patient’s request for corrections to their information. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.

HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data corrected. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

3c. Security Risk

No

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

Complete analysis, design, draft specification work 2020 Dec
Submit for STU Ballot (First Ballot Cycle)
First Ballot Cycle" is a prompt for the PMO to create a schedule task in Project Insight to email the Sponsor/Co-Sponsor lists 2 weeks prior to the WGM prior to the first ballot cycle. 2021 May Ballot/ WGM
STU Reconciliation 2021 May Ballot/ WGM
Submit for 2nd STU Ballot 2021 Sept Ballot/ WGM
Request TSC Approval for STU publication 2022 Jan Ballot/WGM
STU Period – 12 months Jan, 2022 – Jan, 2023

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record/Amendment to PHI/ GDPR WORD HERE

3h. Project Dependencies

none

3i. HL7-Managed Project Document Repository URL:

CREATE PROJECT PAGE

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

Unknown

3m. External Vocabularies

Unknown

3o. Earliest prior release and/or version to which the compatibility applies

FHIR R4

4a. Products

FHIR Implementation Guide, FHIR Profiles

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

6a. External Project Collaboration

none

6b. Content Already Developed

5%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Payors

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health), Other

6h. Other Providers

clinicians

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

Version

11

Modifier

Debi Willis

Modify Date

Jul 25, 2020 00:24

1a. Project Name

Patient Corrections FHIR Implementation Guide Project

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

Payer/Provider Information Exchange

2b. Co-Sponsor WG

Patient Care

2d. Project Facilitator

Debi Willis

2e. Other Interested Parties (and roles)

Vulcan

2k. Conformance Facilitator

unknown

2m. Implementers

PatientLink (MyLinks) FIND ANOTHER IMPLEMENTER

3a. Project Scope

The purpose of this project is to build a FHIR Implementation Guide to provide a standard way to communicate information required to support a patient request for corrections workflow. We will use the HIPAA specifications for our basis because it includes the patient rights outlined in both HIPAA and GDPR regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

Attachments

3b. Project Need

Now that patients have the ability to download their data into FHIR applications, they are finding errors in their data. Currently, no FHIR implementation guide exists to standardize the method of electronically exchanging the required information to facilitate the patient’s request for corrections to their information. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA implementation guidelines.

HIPAA has a very detailed implementation specification for a patient’s request for corrections to their information. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.

HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data corrected. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

3c. Security Risk

No

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

* Outline current HIPAA laws concerning patients' rights for amendment (7/2020)
* Create a flow diagram to show steps for meeting the HIPAA standards via an electronic mechanism (7/2020)
* Research and document the typical workflow within healthcare organizations (for example: providers, payers) for patient corrections following the HIPAA guidelines. (8/2020)
* Define patients' data element needs in requesting amendment to their charts. (9/2020)
* Identify current FHIR resources and interactions that are needed to meet this need (11/2020)
* Develop a FHIR Implementation Guide (standard for trial use) to meet the patient correction requirements (2022)

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record/Amendment to PHI/ GDPR WORD HERE

3h. Project Dependencies

none

3i. HL7-Managed Project Document Repository URL:

CREATE PROJECT PAGE

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

Unknown

3m. External Vocabularies

Unknown

3o. Earliest prior release and/or version to which the compatibility applies

FHIR R4

4a. Products

FHIR Implementation Guide, FHIR Profiles

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

6a. External Project Collaboration

none

6b. Content Already Developed

5%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Payors

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health), Other

6h. Other Providers

clinicians

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

Version

10

Modifier

Debi Willis

Modify Date

Jul 25, 2020 00:20

1a. Project Name

PSS: Patient Corrections DRAFT

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

Payer/Provider Information Exchange

2b. Co-Sponsor WG

Patient Care

2d. Project Facilitator

Debi Willis

2e. Other Interested Parties (and roles)

Vulcan

2k. Conformance Facilitator

unknown

2m. Implementers

PatientLink (MyLinks) FIND ANOTHER IMPLEMENTER

3a. Project Scope

The purpose of this project is to build a FHIR Implementation Guide to provide a standard way to communicate information required to support a patient request for corrections workflow. We will use the HIPAA specifications for our basis because it includes the patient rights outlined in both HIPAA and GDPR regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

Attachments

3b. Project Need

Now that patients have the ability to download their data into FHIR applications, they are finding errors in their data. Currently, no FHIR implementation guide exists to standardize the method of electronically exchanging the required information to facilitate the patient’s request for corrections to their information. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA implementation guidelines.

HIPAA has a very detailed implementation specification for a patient’s request for corrections to their information. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.

HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data corrected. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

3c. Security Risk

No

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

* Outline current HIPAA laws concerning patients' rights for amendment (7/2020)
* Create a flow diagram to show steps for meeting the HIPAA standards via an electronic mechanism (7/2020)
* Research and document the typical workflow within healthcare organizations (for example: providers, payers) for patient corrections following the HIPAA guidelines. (8/2020)
* Define patients' data element needs in requesting amendment to their charts. (9/2020)
* Identify current FHIR resources and interactions that are needed to meet this need (11/2020)
* Develop a FHIR Implementation Guide (standard for trial use) to meet the patient correction requirements (2022)

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record/Amendment to PHI/ GDPR WORD HERE

3h. Project Dependencies

none

3i. HL7-Managed Project Document Repository URL:

CREATE PROJECT PAGE

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

Unknown

3m. External Vocabularies

Unknown

3o. Earliest prior release and/or version to which the compatibility applies

FHIR R4

4a. Products

FHIR Implementation Guide, FHIR Profiles

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

6a. External Project Collaboration

none

6b. Content Already Developed

5%

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Payors

6g. Vendors

EHR, PHR, Health Care IT

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health), Other

6h. Other Providers

clinicians

6i. Realm

Universal

7a. Management Group(s) to Review PSS

FHIR

Version

9

Modifier

Debi Willis

Modify Date

Jul 17, 2020 22:20

1a. Project Name

PSS: Patient Corrections DRAFT

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

Payer/Provider Information Exchange

2d. Project Facilitator

Debi Willis and Abigail Watson

2e. Other Interested Parties (and roles)

EHR vendors, clinicians, patients

3a. Project Scope

The purpose of this project is to build a FHIR Implementation Guide to provide a standard way to communicate information required to support a patient request for corrections workflow. We will use the HIPAA specifications for our basis because it includes the patient rights outlined in both HIPAA and GDPR regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

Attachments

3b. Project Need

Now that patients have the ability to download their data into FHIR applications, they are finding errors in their data. Currently, no FHIR implementation guide exists to standardize the method of electronically exchanging the required information to facilitate the patient’s request for corrections to their information. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA implementation guidelines.

HIPAA has a very detailed implementation specification for a patient’s request for corrections to their information. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.

HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data corrected. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

* Outline current HIPAA laws concerning patients' rights for amendment (7/2020)
* Create a flow diagram to show steps for meeting the HIPAA standards via an electronic mechanism (7/2020)
* Research and document the typical workflow within healthcare organizations (for example: providers, payers) for patient corrections following the HIPAA guidelines. (8/2020)
* Define patients' data element needs in requesting amendment to their charts. (9/2020)
* Identify current FHIR resources and interactions that are needed to meet this need (11/2020)
* Develop a FHIR Implementation Guide (standard for trial use) to meet the patient correction requirements (2022)

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record/Amendment to PHI

3j. Backwards Compatibility

No

6e. Is this a hosted (externally funded) project?

No

Version

8

Modifier

Debi Willis

Modify Date

Jul 17, 2020 21:27

1a. Project Name

PSS: Patient Corrections DRAFT

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

Payer/Provider Information Exchange

2d. Project Facilitator

Debi Willis and Abigail Watson

2e. Other Interested Parties (and roles)

EHR vendors, clinicians, patients

3a. Project Scope

The purpose of this project is to build a FHIR Implementation Guide to provide a standard way to communicate information required to support a patient request for corrections workflow. We will use the HIPAA specifications for our basis because it includes the patient rights outlined in both HIPAA and GDPR regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

Attachments

3b. Project Need

Now that patients have the ability to download their data into FHIR applications, they are finding errors in their data. Currently, no FHIR implementation guide exists to standardize the method of electronically exchanging the required information to facilitate the patient’s request for corrections to their information. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA implementation guidelines.

HIPAA has a very detailed implementation specification for a patient’s request for corrections to their information. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.

HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data corrected. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

* Outline current HIPAA laws concerning patients' rights for amendment
* Break out the individual HIPAA specifications and identify how they are currently being met
* Create an flow diagram to show steps for meeting the HIPAA standards via an electronic mechanism
* Define patients' data element needs in requesting amendment to their charts.
* Identify current resources that might be used to meet this need
* Work with the many brilliant people in HL7 to build an IG

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record/Amendment to PHI

3j. Backwards Compatibility

No

6e. Is this a hosted (externally funded) project?

No

Version

7

Modifier

Debi Willis

Modify Date

Jul 17, 2020 20:51

1a. Project Name

PSS: Patient Corrections DRAFT

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

Payer/Provider Information Exchange

2d. Project Facilitator

Debi Willis and Abigail Watson

2e. Other Interested Parties (and roles)

EHR vendors, clinicians, patients

Attachments

3b. Project Need

Now that patients have the ability to download their data into FHIR applications, they are finding errors in their data. Currently, no FHIR implementation guide exists to standardize the method of electronically exchanging the required information to facilitate the patient’s request for corrections to their information. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA implementation guidelines.

HIPAA has a very detailed implementation specification for a patient’s request for corrections to their information. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.

HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data corrected. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations. Our goal is to consider patient corrections in a global context but our focus in this guide is to follow the HIPAA implementation guidelines due to the details provided in that guide.

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

* Outline current HIPAA laws concerning patients' rights for amendment
* Break out the individual HIPAA specifications and identify how they are currently being met
* Create an flow diagram to show steps for meeting the HIPAA standards via an electronic mechanism
* Define patients' data element needs in requesting amendment to their charts.
* Identify current resources that might be used to meet this need
* Work with the many brilliant people in HL7 to build an IG

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record/Amendment to PHI

3j. Backwards Compatibility

No

6e. Is this a hosted (externally funded) project?

No

Version

6

Modifier

Debi Willis

Modify Date

Jul 16, 2020 22:33

1a. Project Name

PSS: Patient Corrections DRAFT

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

Payer/Provider Information Exchange

2d. Project Facilitator

Debi Willis and Abigail Watson

2e. Other Interested Parties (and roles)

EHR vendors, clinicians, patients

Attachments

3b. Project Need

HIPAA has a very detailed implementation specification for a patient’s request for amendment to their PHI. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.
Currently, no FHIR implementation guide exits to standardize the method of electronically exchanging the required information to facilitate the patient’s request for amendment to their PHI. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA guidelines.
HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data amended. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations.

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

* Outline current HIPAA laws concerning patients' rights for amendment
* Break out the individual HIPAA specifications and identify how they are currently being met
* Create an flow diagram to show steps for meeting the HIPAA standards via an electronic mechanism
* Define patients' data element needs in requesting amendment to their charts.
* Identify current resources that might be used to meet this need
* Work with the many brilliant people in HL7 to build an IG

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record/Amendment to PHI

3j. Backwards Compatibility

No

6e. Is this a hosted (externally funded) project?

No

Version

5

Modifier

Debi Willis

Modify Date

Jul 16, 2020 18:23

1a. Project Name

PSS: Patient Corrections DRAFT

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

Payer/Provider Information Exchange

2d. Project Facilitator

Debi Willis and Abigail Watson

2e. Other Interested Parties (and roles)

EHR vendors, clinicians, patients

Attachments

3b. Project Need

HIPAA has a very detailed implementation specification for a patient’s request for amendment to their PHI. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.
Currently, no FHIR implementation guide exits to standardize the method of electronically exchanging the required information to facilitate the patient’s request for amendment to their PHI. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA guidelines.
HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data amended. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations.

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

* Outline current HIPAA laws concerning patients' rights for amendment
* Break out the individual HIPAA specifications and identify how they are currently being met
* Create an flow diagram to show steps for meeting the HIPAA standards via an electronic mechanism
* Define patients' data element needs in requesting amendment to their charts.
* Identify current resources that might be used to meet this need

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record/Amendment to PHI

3j. Backwards Compatibility

No

6e. Is this a hosted (externally funded) project?

No

Version

4

Modifier

Debi Willis

Modify Date

Jul 16, 2020 16:49

1a. Project Name

PSS: Patient Corrections DRAFT

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

Payer/Provider Information Exchange

2d. Project Facilitator

Debi Willis and Abigail Watson

2e. Other Interested Parties (and roles)

EHR vendors, clinicians, patients

Attachments

3b. Project Need

HIPAA has a very detailed implementation specification for a patient’s request for amendment to their PHI. (See regulation here: https://www.govinfo.gov/content/pkg/CFR-2003-title45-vol1/xml/CFR-2003-title45-vol1-sec164-526.xml) This process is usually handled via mail or phone conversations, making a “paper trail” more difficult to manage. It is also very burdensome for patients and health organizations because of the lengthy process of exchange of information through mail or multiple phone calls. As portals have become more popular since the initial release of this HIPAA regulation, some patients and health organizations have begun to manage the request electronically.
Currently, no FHIR implementation guide exits to standardize the method of electronically exchanging the required information to facilitate the patient’s request for amendment to their PHI. This implementation guide will provide a FHIR based standard for the communication of required data elements according to the HIPAA guidelines.
HIPAA and GDPR are very similar in their regulations concerning patients’ rights to have their data amended. There are minor differences in the period of time for covered entities to respond to the patient’s initial request for corrections and the preference in GDPR for a means for patient requests to be made electronically. GDPR has no detailed implementation specification, so we will use the HIPAA specifications for our basis because it includes the patient rights outlined in both regulations.

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

* Outline current HIPAA laws concerning patients' rights for amendment
* Break out the individual HIPAA specifications and identify how they are currently being met
* Create an flow diagram to show steps for meeting the HIPAA standards via an electronic mechanism
* Define patients' data element needs in requesting amendment to their charts.
* Identify current resources that might be used to meet this need

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record

3j. Backwards Compatibility

No

6e. Is this a hosted (externally funded) project?

No

Version

3

Modifier

Dave deBronkart

Modify Date

Jun 25, 2020 17:32

1a. Project Name

PSS: Patient Corrections DRAFT

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

Payer/Provider Information Exchange

2d. Project Facilitator

Debi Willis and Abigail Watson

2e. Other Interested Parties (and roles)

EHR vendors, clinicians, patients

3a. Project Scope

Now that patients are able to retrieve their records via the FHIR API, there will be more focus on incorrect/missing data in the EHR. HIPAA gives the right to a patient to request amendments to their chart. The old way is via a paper request. We would like to provide a new electronic way using FHIR.

Attachments

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

* Outline current HIPAA laws concerning patients' rights for amendment
* Break out the individual HIPAA specifications and identify how they are currently being met
* Create an flow diagram to show steps for meeting the HIPAA standards via an electronic mechanism
* Define patients' data element needs in requesting amendment to their charts.
* Identify current resources that might be used to meet this need

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record

3j. Backwards Compatibility

No

6e. Is this a hosted (externally funded) project?

No

Version

2

Modifier

Debi Willis

Modify Date

Jun 24, 2020 19:47

1a. Project Name

PSS: Patient Corrections

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

Payer/Provider Information Exchange

2d. Project Facilitator

Debi Willis and Abigail Watson

2e. Other Interested Parties (and roles)

EHR vendors, clinicians, patients

3a. Project Scope

Now that patients are able to retrieve their records via the FHIR API, there will be more focus on incorrect/missing data in the EHR. HIPAA gives the right to a patient to request amendments to their chart. The old way is via a paper request. We would like to provide a new electronic way using FHIR.

Attachments

3d. External Drivers

Patients have more access to their data via FHIR. Moving the paper-based process to electronic process using FHIR.

3e. Objectives/Deliverables and Target Dates

* Outline current HIPAA laws concerning patients' rights for amendment
* Break out the individual HIPAA specifications and identify how they are currently being met
* Create an flow diagram to show steps for meeting the HIPAA standards via an electronic mechanism
* Define patients' data element needs in requesting amendment to their charts.
* Identify current resources that might be used to meet this need

3f. Common Names / Keywords / Aliases:

Patient corrections /Corrections to medical record

3j. Backwards Compatibility

No

6e. Is this a hosted (externally funded) project?

No

Version

1

Modifier

Debi Willis

Modify Date

Jun 24, 2020 19:30

1a. Project Name

PSS: Patient Corrections

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

Payer/Provider Information Exchange

2d. Project Facilitator

Debi Willis and Abigail Watson

2e. Other Interested Parties (and roles)

EHR vendors, clinicians, patients

3a. Project Scope

Now that patients are able to retrieve their records via the FHIR API, there will be more focus on incorrect/missing data in the EHR. HIPAA gives the right to a patient to request amendments to their chart. The old way is via a paper request. We would like to provide a new electronic way using FHIR.

3j. Backwards Compatibility

No

1 Comment

  1. Interested Parties and Co-Sponsors: These should be workgroups.  I think we should encourage cosponsors and interested parties.  I think Patient Care and Patient Administration would be good examples here.  Also, perhaps Emergency Care would like to be an interested party.  And perhaps CBCP or Security have an angle.


    Project Scope currently says: Now that patients are able to retrieve their records via the FHIR API, there will be more focus on incorrect/missing data in the EHR. HIPAA gives the right to a patient to request amendments to their chart. The old way is via a paper request. We would like to provide a new electronic way using FHIR.


    This sounds more like Project Need.  I recommend we move this to Project Need and change to:

    Now that patients are able to retrieve their records via the FHIR API, there will be more focus on incorrect/missing data in the EHR. Laws such as the US HIPAA law gives the right to a patient to request amendments to their chart. The old way is via a paper request. We would like to provide a new electronic way using FHIR.


    I think Project Scope should say:  Create a FHIR implementation guide to support the ability for patients to electronically communicate corrections to their information via FHIR with a focus on the US HIPAA law use case.


    I think those currently listed under interested parties could be stakeholders.