From 1dded18a9065bfd5c38e04bdc6894d54375ed783 Mon Sep 17 00:00:00 2001 From: Keith Carlson Jr Date: Mon, 11 Mar 2024 20:15:57 -0400 Subject: [PATCH 01/25] updating header refs and reg text --- docs/g10-criterion.md | 48 +++++++++++++++++++++---------------------- 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/docs/g10-criterion.md b/docs/g10-criterion.md index f49302c..1cc154a 100644 --- a/docs/g10-criterion.md +++ b/docs/g10-criterion.md @@ -53,9 +53,9 @@ healthcare providers to implement Health IT Modules certified to requirements in ### Data Response (Single Patient) ???+ quote "**Regulation text at § 170.315(g)(10)(i)(A)**" - (i) Data response. (A) Respond to requests for a single patient's data according to the standard adopted in § 170.215(a)(1) and implementation specification adopted in § 170.215(a)(2), including the mandatory capabilities described in “US Core Server CapabilityStatement,” for each of the data included in the standard adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported. + (i) Data response. (A) Respond to requests for a single patient’s data according to the standard adopted in § 170.215(a)(1) and implementation specifications adopted in § 170.215(a) and in § 170.215(b)(1), including the mandatory capabilities described in “US Core Server CapabilityStatement,” for each of the data included in the standards adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported. - + ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(i)(A)*" Technical outcome – Respond to requests for a single patient’s data according to the standard adopted in § 170.215(a)(1) and implementation specification adopted in § 170.215(a)(2), including the mandatory capabilities described in “US Core Server CapabilityStatement,” for each of the data included in the standard adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported. @@ -99,9 +99,9 @@ healthcare providers to implement Health IT Modules certified to requirements in ### Data Response (Multiple Patients) ???+ quote "**Regulation text at § 170.315(g)(10)(i)(B)**" - (B) Respond to requests for multiple patients' data as a group according to the standard adopted in § 170.215(a)(1), and implementation specifications adopted in § 170.215(a)(2) and (4), for each of the data included in the standard adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported. + (B) Respond to requests for multiple patients' data as a group according to the standards and implementation specifications adopted in § 170.215(a), (b)(1), and (d), for each of the data included in the standards adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported. - + ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(i)(B)*" Technical outcome – Respond to requests for multiple patients’ data as a group according to the standard adopted in § 170.215(a)(1), and implementation specifications adopted in § 170.215(a)(2) and (4), for each of the data included in the standard adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported. @@ -119,9 +119,9 @@ healthcare providers to implement Health IT Modules certified to requirements in ### Supported Search Operations (Single Patient) ???+ quote "**Regulation text at § 170.315(g)(10)(ii)(A)**" - (ii) Supported search operations. (A) Respond to search requests for a single patient's data consistent with the search criteria included in the implementation specification adopted in § 170.215(a)(2), specifically the mandatory capabilities described in “US Core Server CapabilityStatement.” + (ii) Supported search operations. (A) Respond to search requests for a single patient’s data consistent with the search criteria included in the implementation specifications adopted in § 170.215(b)(1), specifically the mandatory capabilities described in “US Core Server CapabilityStatement.” - + ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(ii)(A)*" Technical outcome – Respond to search requests for a single patient’s data consistent with the search criteria included in the implementation specification adopted in § 170.215(a)(2), specifically the mandatory capabilities described in “US Core Server CapabilityStatement”. @@ -138,9 +138,9 @@ healthcare providers to implement Health IT Modules certified to requirements in ### Supported Search Operations (Multiple Patients) ???+ quote "**Regulation text at § 170.315(g)(10)(ii)(B)**" - (B) Respond to search requests for multiple patients' data consistent with the search criteria included in the implementation specification adopted in § 170.215(a)(4) + (B) Respond to search requests for multiple patients' data consistent with the search criteria included in the implementation specification adopted in § 170.215(d). - + ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(ii)(B)*" Technical outcome – Respond to search requests for multiple patients' data consistent with the search criteria included in the implementation specification adopted in § 170.215(a)(4). @@ -158,9 +158,9 @@ healthcare providers to implement Health IT Modules certified to requirements in ### Application Registration ???+ quote "**Regulation text at § 170.315(g)(10)(iii)**" - (iii) Application registration. Enable an application to register with the Health IT Module's “authorization server.” + (iii) Application registration. Enable an application to register with the Health IT Module’s “authorization server.” - + ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(iii)*" Technical outcome – Enable an application to register with the Health IT Module’s “authorization server.” @@ -191,9 +191,9 @@ healthcare providers to implement Health IT Modules certified to requirements in ### Secure Connection ???+ quote "**Regulation text at § 170.315(g)(10)(iv)(A)**" - (iv) Secure connection. (A) Establish a secure and trusted connection with an application that requests data for patient and user scopes in accordance with the implementation specifications adopted in § 170.215(a)(2) and (3). + (iv) Secure connection. (A) Establish a secure and trusted connection with an application that requests data for patient and user scopes in accordance with the implementation specifications adopted in § 170.215(b)(1) and (c). (B) Establish a secure and trusted connection with an application that requests data for system scopes in accordance with the implementation specification adopted in § 170.215(d). - + ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(iv)*" Technical outcome - (A) Establish a secure and trusted connection with an application that requests data for patient and user scopes in accordance with the implementation specifications adopted in § 170.215(a)(2) and (3). (B) Establish a secure and trusted connection with an application that requests data for system scopes in accordance with the implementation specification adopted in § 170.215(a)(4). @@ -210,9 +210,9 @@ healthcare providers to implement Health IT Modules certified to requirements in ### First time Authentication / Authorization for Single Patient Services ???+ quote "**Regulation text at § 170.315(g)(10)(V)(A)(1)**" - (v) Authentication and authorization—(A) Authentication and authorization for patient and user scopes—(1) First time connections—(i) Authentication and authorization must occur during the process of granting access to patient data in accordance with the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(b). (ii) A Health IT Module's authorization server must issue a refresh token valid for a period of no less than three months to applications capable of storing a client secret. (iii) A Health IT Module's authorization server must issue a refresh token for a period of no less than three months to native applications capable of securing a refresh token. + (v) Authentication and authorization—(A) Authentication and authorization for patient and user scopes—(1) First time connections—(i) Authentication and authorization must occur during the process of granting access to patient data in accordance with the implementation specification adopted in § 170.215(c) and standard adopted in § 170.215(e). (ii) A Health IT Module’s authorization server must issue a refresh token valid for a period of no less than three months to applications using the “confidential app” profile according to an implementation specification adopted in § 170.215(c). (iii) A Health IT Module’s authorization server must issue a refresh token for a period of no less than three months to native applications capable of securing a refresh token. - + ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(v)(A)(1)*" Technical outcome – For first time connections, authentication and authorization must occur during the process of granting access to patient data in accordance with the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(b). Additionally, a Health IT Module's authorization server must issue a refresh token valid for a period of no less than three months to applications capable of storing a client secret. Finally, a Health IT Module's authorization server must issue a refresh token for a period of no less than three months to native applications capable of securing a refresh token. @@ -312,9 +312,9 @@ healthcare providers to implement Health IT Modules certified to requirements in ### Subsequent Authentication / Authorization for Single Patient Services ???+ quote "**Regulation text at § 170.315(g)(10)(V)(A)(2)**" - (2) Subsequent connections. (i) Access must be granted to patient data in accordance with the implementation specification adopted in § 170.215(a)(3) without requiring reauthorization and re-authentication when a valid refresh token is supplied by the application. (ii) A Health IT Module's authorization server must issue a refresh token valid for a new period of no less than three months to applications capable of storing a client secret. + (2) Subsequent connections. (i) Access must be granted to patient data in accordance with the implementation specification adopted in § 170.215(c) without requiring re-authorization and re-authentication when a valid refresh token is supplied by the application. (ii) A Health IT Module’s authorization server must issue a refresh token valid for a new period of no less than three months to applications using the “confidential app” profile according to an implementation specification adopted in § 170.215(c). - + ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(V)(A)(2)*" Technical outcome – For subsequent connections, access must be granted to patient data in accordance with the implementation specification adopted in § 170.215(a)(3) without requiring re-authorization and re-authentication when a valid refresh token is supplied by the application. Additionally, a Health IT Module's authorization server must issue a refresh token valid for a new period of no less than three months to applications capable of storing a client secret. @@ -367,9 +367,9 @@ new period of no less than three months. ### Authentication / Authorization for Multiple Patient Services ???+ quote "**Regulation text at § 170.315(g)(10)(v)(B)**" - (B) Authentication and authorization for system scopes. Authentication and authorization must occur during the process of granting an application access to patient data in accordance with the “SMART Backend Services: Authorization Guide” section of the implementation specification adopted in § 170.215(a)(4) and the application must be issued a valid access token. + (B) Authentication and authorization for system scopes. Authentication and authorization must occur during the process of granting an application access to patient data in accordance with the “SMART Backend Services: Authorization Guide” section of the implementation specification adopted in § 170.215(d) and the application must be issued a valid access token. - + ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(v)(B)*" Technical outcome – Authentication and authorization must occur during the process of granting an application access to patient data in accordance with the “SMART Backend Services: Authorization Guide” section of the implementation specification adopted in § 170.215(a)(4) and the application must be issued a valid access token. @@ -430,9 +430,9 @@ new period of no less than three months. ### Patient Authorization Revocation ???+ quote "**Regulation text at § 170.315(g)(10)(vi)**" - (vi) Patient authorization revocation. A Health IT Module's authorization server must be able to revoke an authorized application's access at a patient's direction. + (vi) Patient authorization revocation. A Health IT Module’s authorization server must be able to revoke and must revoke an authorized application’s access at a patient’s direction within 1 hour of the request. - + ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(vi)*" Technical outcome – A Health IT Module’s authorization server must be able to revoke an authorized application’s access at a patient’s direction. @@ -450,9 +450,9 @@ new period of no less than three months. ### Token Introspection ???+ quote "**Regulation text at § 170.315(g)(10)(vii)**" - (vii) Token introspection. A Health IT Module's authorization server must be able to receive and validate tokens it has issued. + (vii) Token introspection. A Health IT Module’s authorization server must be able to receive and validate tokens it has issued in accordance with an implementation specification in § 170.215(c). - + ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(vii)*" Technical outcome – A Health IT Module’s authorization server must be able to receive and validate tokens it has issued. @@ -466,7 +466,7 @@ new period of no less than three months. ???+ quote "**Regulation text at § 170.315(g)(10)(viii)(A)**" (viii) Documentation. (A) The API(s) must include complete accompanying documentation that contains, at a minimum: (1) API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns. (2) The software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s). (3) All applicable technical requirements and attributes necessary for an application to be registered with a Health IT Module's authorization server. - + ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(viii)(A)*" Technical outcome – The API(s) must include complete accompanying documentation that contains, at a minimum: (*1*) API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns; (*2*) The software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s); and (*3*) All applicable technical requirements and attributes necessary for an application to be registered with a Health IT Module’s authorization server. @@ -481,7 +481,7 @@ new period of no less than three months. ???+ quote "**Regulation text at § 170.315(g)(10)(viii)(B)**" (B) The documentation used to meet paragraph (g)(10)(viii)(A) of this section must be available via a publicly accessible hyperlink without any preconditions or additional steps. - + ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(viii)(B)*" Technical outcome – The documentation used to meet paragraph (g)(10)(viii)(A) of this section must be available via a publicly accessible hyperlink without any preconditions or additional steps. From 1895167ff30888f191dd7774ab4a46584029a82f Mon Sep 17 00:00:00 2001 From: Keith Carlson Jr Date: Mon, 11 Mar 2024 20:16:59 -0400 Subject: [PATCH 02/25] remove erroneously included paragraph --- docs/g10-criterion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/g10-criterion.md b/docs/g10-criterion.md index 1cc154a..c5cbc99 100644 --- a/docs/g10-criterion.md +++ b/docs/g10-criterion.md @@ -191,7 +191,7 @@ healthcare providers to implement Health IT Modules certified to requirements in ### Secure Connection ???+ quote "**Regulation text at § 170.315(g)(10)(iv)(A)**" - (iv) Secure connection. (A) Establish a secure and trusted connection with an application that requests data for patient and user scopes in accordance with the implementation specifications adopted in § 170.215(b)(1) and (c). (B) Establish a secure and trusted connection with an application that requests data for system scopes in accordance with the implementation specification adopted in § 170.215(d). + (iv) Secure connection. (A) Establish a secure and trusted connection with an application that requests data for patient and user scopes in accordance with the implementation specifications adopted in § 170.215(b)(1) and (c). ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(iv)*" From c2050193e0efe3d466393bf4da0c0ab144158559 Mon Sep 17 00:00:00 2001 From: Keith Carlson Jr Date: Mon, 11 Mar 2024 20:20:45 -0400 Subject: [PATCH 03/25] add hti-1 link --- docs/g10-criterion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/g10-criterion.md b/docs/g10-criterion.md index c5cbc99..520dc1f 100644 --- a/docs/g10-criterion.md +++ b/docs/g10-criterion.md @@ -2,7 +2,7 @@ # Standardized API Certification Criterion at § 170.315(g)(10) -This section considers the HL7®[^1] FHIR® standardized API for patient and population services certification criterion, including all of the content contained in the ONC Cures Act Final Rule API preamble, the IFC API preamble, and the regulation paragraphs in § 170.315(g)(10). +This section considers the HL7®[^1] FHIR® standardized API for patient and population services certification criterion, including all of the content contained in the ONC Cures Act Final Rule API preamble, the IFC API preamble, HTI-1 API preamble, and the regulation paragraphs in § 170.315(g)(10). ## Applicability § 170.315(g)(10) is applicable to all health IT developers who are certifying to the EHR base definition on or after December 31, 2022. From 6114a55fd25c810cd3c03dff82e6fbca2267c4b9 Mon Sep 17 00:00:00 2001 From: Keith Carlson Jr Date: Mon, 11 Mar 2024 20:28:20 -0400 Subject: [PATCH 04/25] updating client secrret language --- docs/g10-criterion.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/g10-criterion.md b/docs/g10-criterion.md index 520dc1f..49c0c80 100644 --- a/docs/g10-criterion.md +++ b/docs/g10-criterion.md @@ -275,7 +275,7 @@ healthcare providers to implement Health IT Modules certified to requirements in authz -->> authz: End-user authorization alt Granted authz -->> app: Authorization granted - alt App is capable of storing a client secret + alt App is a “confidential app” according to an implementation specification adopted in § 170.215(c) (SMART App Launch IG) app ->> authz: Access token request note over app,authz: Client secret used for authentication else App is a native app capable of securing a refresh token @@ -345,7 +345,7 @@ new period of no less than three months. participant fhir as Health IT Module's FHIR® Server loop while refresh token is valid - alt App is capable of storing a client secret + alt App is a “confidential app” according to an implementation specification adopted in § 170.215(c) (SMART App Launch IG) app ->> authz: Refresh token note over app,authz: Client secret used for authentication note over authz: The (g)(10) criterion paragraph at § 170.315(g)(10)(v)(A)(2)(ii) requires
that apps capable of storing a client secret have their refresh tokens renewed
(i.e., made valid for a new period of no less than three months). This could
include the authorization server issuing a new refresh token or renewing the
existing refresh token. @@ -355,7 +355,7 @@ new period of no less than three months. authz -->> app: New access token response authz -->> authz: Existing refresh token renewed end - else App is not capable of storing a client secret + else App is not a “confidential app” according to an implementation specification adopted in § 170.215(c) (SMART App Launch IG) app ->> authz: Refresh token authz -->> app: New access token response end From c4cebfd58a6ee4a48d392fd461a7525091654d7a Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Wed, 20 Mar 2024 11:17:59 -0400 Subject: [PATCH 05/25] remove banner --- mkdocs.yml | 1 - overrides/main.html | 5 ----- 2 files changed, 6 deletions(-) delete mode 100644 overrides/main.html diff --git a/mkdocs.yml b/mkdocs.yml index 6814718..0519f8f 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -10,7 +10,6 @@ nav: copyright: Privacy Policy theme: name: material - custom_dir: overrides palette: - media: "(prefers-color-scheme: light)" scheme: default diff --git a/overrides/main.html b/overrides/main.html deleted file mode 100644 index 28e4795..0000000 --- a/overrides/main.html +++ /dev/null @@ -1,5 +0,0 @@ -{% extends "base.html" %} - -{% block announce %} - The API Resource Guide has not yet been updated post HTI-1 effective date of 3/11/2024. This banner will be removed once it has been updated. In the meantime, please refer to the CCGs and Test Procedures on www.healthit.gov for the latest information. -{% endblock %} \ No newline at end of file From e090f7edf245690d5c9bf0b96cb91d6e93248908 Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Wed, 20 Mar 2024 11:27:03 -0400 Subject: [PATCH 06/25] make page names consistent --- docs/g10-criterion.md | 2 +- docs/index.md | 2 +- mkdocs.yml | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/g10-criterion.md b/docs/g10-criterion.md index 49c0c80..f8a8e6b 100644 --- a/docs/g10-criterion.md +++ b/docs/g10-criterion.md @@ -1,6 +1,6 @@ -# Standardized API Certification Criterion at § 170.315(g)(10) +# HL7 FHIR API Criterion at § 170.315(g)(10) This section considers the HL7®[^1] FHIR® standardized API for patient and population services certification criterion, including all of the content contained in the ONC Cures Act Final Rule API preamble, the IFC API preamble, HTI-1 API preamble, and the regulation paragraphs in § 170.315(g)(10). diff --git a/docs/index.md b/docs/index.md index 8e7f69a..02126ae 100644 --- a/docs/index.md +++ b/docs/index.md @@ -2,7 +2,7 @@ ## How to use this resource guide -This informative resource supplements other public documentation available to help health IT developers certify to the API criteria in the ONC Health IT Certification Program and meet the requirements under the API Conditions and Maintenance of Certification. At the highest level, this document mirrors the organization of paragraphs in the Code of Federal Regulations, including headers for “§ 170.315(g)(10) Standardized API Certification Criterion” (the FHIR®-based standardized API), “§ 170.404 Conditions and Maintenance of Certification” (the broader API behavior requirements), and sub-paragraphs. Efforts have been made to make this resource easily navigable, searchable, and consumable. If you have recommendations to improve this resource, please submit an inquiry to the Health IT Feedback and Inquiry Portal or submit an issue on GitHub. +This informative resource supplements other public documentation available to help health IT developers certify to the API criteria in the ONC Health IT Certification Program and meet the requirements under the API Conditions and Maintenance of Certification. At the highest level, this wesbite mirrors the organization of paragraphs in the Code of Federal Regulations, including pages for “HL7 FHIR API Criterion - § 170.315(g)(10)” (the FHIR®-based standardized API), “API Conditions and Maintenance of Certification - § 170.404” (the broader API behavior requirements), and sub-paragraphs. Efforts have been made to make this resource easily navigable, searchable, and consumable. If you have recommendations to improve this resource, please submit an inquiry to the Health IT Feedback and Inquiry Portal or submit an issue on GitHub. This resource is intended to provide clarifications to assist developers in implementing applicable provisions contained in 45 CFR part 170. In developing and implementing APIs and other health IT, developers should remain mindful of the information blocking provisions of the ONC Cures Act Final Rule contained in 45 CFR part 171. **This resource does not supersede existing statutory or regulatory requirements**. The use of the term “Health IT Module(s)” or “Certified Health IT Module(s)” in this resource refers to Health IT Modules certified through the ONC Health IT Certification Program. diff --git a/mkdocs.yml b/mkdocs.yml index 0519f8f..156427c 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -1,8 +1,8 @@ site_name: ONC Health IT Certification Program API Resource Guide nav: - Home: index.md - - HL7 FHIR API criterion - 170.315(g)(10): g10-criterion.md - - API Conditions and Maintenance of Certification: 404-conditions-maintenance.md + - HL7 FHIR API Criterion - § 170.315(g)(10): g10-criterion.md + - API Conditions and Maintenance of Certification - § 170.404: 404-conditions-maintenance.md - Directory of Published Versions: version-directory.md - Helpful Links: helpful-links.md - HealthIT.gov: https://www.healthit.gov/ From c0d24d574f503ca7dc17a85eadabc9f36a840449 Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Wed, 20 Mar 2024 11:29:25 -0400 Subject: [PATCH 07/25] remove reference to cures act final rule --- docs/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/index.md b/docs/index.md index 02126ae..ab1f7f0 100644 --- a/docs/index.md +++ b/docs/index.md @@ -4,7 +4,7 @@ This informative resource supplements other public documentation available to help health IT developers certify to the API criteria in the ONC Health IT Certification Program and meet the requirements under the API Conditions and Maintenance of Certification. At the highest level, this wesbite mirrors the organization of paragraphs in the Code of Federal Regulations, including pages for “HL7 FHIR API Criterion - § 170.315(g)(10)” (the FHIR®-based standardized API), “API Conditions and Maintenance of Certification - § 170.404” (the broader API behavior requirements), and sub-paragraphs. Efforts have been made to make this resource easily navigable, searchable, and consumable. If you have recommendations to improve this resource, please submit an inquiry to the Health IT Feedback and Inquiry Portal or submit an issue on GitHub. -This resource is intended to provide clarifications to assist developers in implementing applicable provisions contained in 45 CFR part 170. In developing and implementing APIs and other health IT, developers should remain mindful of the information blocking provisions of the ONC Cures Act Final Rule contained in 45 CFR part 171. **This resource does not supersede existing statutory or regulatory requirements**. The use of the term “Health IT Module(s)” or “Certified Health IT Module(s)” in this resource refers to Health IT Modules certified through the ONC Health IT Certification Program. +This resource is intended to provide clarifications to assist developers in implementing applicable provisions contained in 45 CFR part 170. In developing and implementing APIs and other health IT, developers should remain mindful of the information blocking provisions contained in 45 CFR part 171. **This resource does not supersede existing statutory or regulatory requirements**. The use of the term “Health IT Module(s)” or “Certified Health IT Module(s)” in this resource refers to Health IT Modules certified through the ONC Health IT Certification Program. This resource encompasses clarifications from the § 170.315(g)(10) Certification Companion Guide and § 170.404 CCG. Within each regulation paragraph, there is a section titled “Clarifications Included in [name of CCG],” which includes clarifications from the respective CCG, and “Additional Clarifications to the [name of CCG],” which includes additional clarifications not included in the respective CCG. This documentation accompanies the Certification Companion Guides and Test Procedures for the API certification criterion finalized in § 170.315(g)(10) and the CCG for API Conditions and Maintenance of Certification requirements finalized at § 170.404. From d5603464132f096afc3e466eb800eb309f6e7b0c Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Wed, 20 Mar 2024 11:33:17 -0400 Subject: [PATCH 08/25] add deep/header specific link --- docs/g10-criterion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/g10-criterion.md b/docs/g10-criterion.md index f8a8e6b..dee2b52 100644 --- a/docs/g10-criterion.md +++ b/docs/g10-criterion.md @@ -2,7 +2,7 @@ # HL7 FHIR API Criterion at § 170.315(g)(10) -This section considers the HL7®[^1] FHIR® standardized API for patient and population services certification criterion, including all of the content contained in the ONC Cures Act Final Rule API preamble, the IFC API preamble, HTI-1 API preamble, and the regulation paragraphs in § 170.315(g)(10). +This section considers the HL7®[^1] FHIR® standardized API for patient and population services certification criterion, including all of the content contained in the ONC Cures Act Final Rule API preamble, the IFC API preamble, HTI-1 API preamble, and the regulation paragraphs in § 170.315(g)(10). ## Applicability § 170.315(g)(10) is applicable to all health IT developers who are certifying to the EHR base definition on or after December 31, 2022. From 64fceba7a411f7f7e456a0faf5c1d4dcc3478fb3 Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Wed, 20 Mar 2024 11:41:05 -0400 Subject: [PATCH 09/25] remove cures act final rule ref --- docs/g10-criterion.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/g10-criterion.md b/docs/g10-criterion.md index dee2b52..9dc59f3 100644 --- a/docs/g10-criterion.md +++ b/docs/g10-criterion.md @@ -5,7 +5,7 @@ This section considers the HL7®[^1] FHIR® standardized API for patient and population services certification criterion, including all of the content contained in the ONC Cures Act Final Rule API preamble, the IFC API preamble, HTI-1 API preamble, and the regulation paragraphs in § 170.315(g)(10). ## Applicability -§ 170.315(g)(10) is applicable to all health IT developers who are certifying to the EHR base definition on or after December 31, 2022. +§ 170.315(g)(10) is applicable to all health IT developers who are certifying to the EHR base definition. The API certification criterion finalized in § 170.315(g)(10) was included as part of the EHR Base Definition at § 170.102. While developers of health information technology are not required by the ONC to meet certification requirements, including certification requirements that are included as part of the EHR Base Definition, several federal, state and tribal entities, including Centers for Medicare & Medicaid Services, Centers for Disease Control and Prevention, and other programs reference the ONC Health IT Certification Program and require the use of certified health IT for program participation. @@ -43,7 +43,7 @@ To submit questions or comments to ONC please use our information blocking policies established by the ONC Cures Act Final Rule do not compel +- The information blocking policies do not compel healthcare providers to implement Health IT Modules certified to requirements in § 170.315(g)(10). - While there may be slight variation between each instance of a Standardized API for patient and population services Health IT Module implemented by API Information Sources, ONC believes the standards that form the basis of the § 170.315(g)(10) certification criterion will enable interoperability across implementations. From 05945f3b96199a1e7ed7401f68baea41736b98e9 Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Wed, 20 Mar 2024 12:13:23 -0400 Subject: [PATCH 10/25] g10 page update for HTI-1 --- docs/g10-criterion.md | 52 ++++++++++++++++++------------------------- 1 file changed, 22 insertions(+), 30 deletions(-) diff --git a/docs/g10-criterion.md b/docs/g10-criterion.md index 9dc59f3..c0b8cf3 100644 --- a/docs/g10-criterion.md +++ b/docs/g10-criterion.md @@ -53,7 +53,7 @@ healthcare providers to implement Health IT Modules certified to requirements in ### Data Response (Single Patient) ???+ quote "**Regulation text at § 170.315(g)(10)(i)(A)**" - (i) Data response. (A) Respond to requests for a single patient’s data according to the standard adopted in § 170.215(a)(1) and implementation specifications adopted in § 170.215(a) and in § 170.215(b)(1), including the mandatory capabilities described in “US Core Server CapabilityStatement,” for each of the data included in the standards adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported. + (i) *Data response*. (A) Respond to requests for a single patient's data according to the standards and implementation specifications adopted in § 170.215(a) and in § 170.215(b)(1), including the mandatory capabilities described in “US Core Server CapabilityStatement,” for each of the data included in the standards adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported. ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(i)(A)*" @@ -99,7 +99,7 @@ healthcare providers to implement Health IT Modules certified to requirements in ### Data Response (Multiple Patients) ???+ quote "**Regulation text at § 170.315(g)(10)(i)(B)**" - (B) Respond to requests for multiple patients' data as a group according to the standards and implementation specifications adopted in § 170.215(a), (b)(1), and (d), for each of the data included in the standards adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported. + (B) Respond to requests for multiple patients' data as a group according to the standards and implementation specifications adopted in § 170.215(a), (b)(1), and (d), for each of the data included in the standards adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported. ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(i)(B)*" @@ -119,7 +119,7 @@ healthcare providers to implement Health IT Modules certified to requirements in ### Supported Search Operations (Single Patient) ???+ quote "**Regulation text at § 170.315(g)(10)(ii)(A)**" - (ii) Supported search operations. (A) Respond to search requests for a single patient’s data consistent with the search criteria included in the implementation specifications adopted in § 170.215(b)(1), specifically the mandatory capabilities described in “US Core Server CapabilityStatement.” + (ii) *Supported search operations*. (A) Respond to search requests for a single patient's data consistent with the search criteria included in the implementation specifications adopted in § 170.215(b)(1), specifically the mandatory capabilities described in “US Core Server CapabilityStatement.” ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(ii)(A)*" @@ -153,12 +153,12 @@ healthcare providers to implement Health IT Modules certified to requirements in *Additional Clarifications to the (g)(10) CCG:* - The scope of data available in the data responses defined in § 170.315(g)(10)(i) must be supported for searches for multiple patients via the supported search operations finalized in § 170.315(g)(10)(ii). -- The HL7® FHIR® Bulk Data Access (Flat FHIR®) (v1.0.0: STU 1) implementation specification adopted in § 170.215(a)(4) includes mandatory support for the “group-export” "OperationDefinition." -- ONC has not included a requirement for Bulk FHIR® import because the standards for these features are still being developed by industry. Applications or systems seeking to import information formatting according to the HL7® FHIR® Bulk Data Access (Flat FHIR®) (V1.0.0:STU 1) can use several methods developed by industry, or can refer to Bulk FHIR® import methods being defined by HL7® at the HL7® FHIR® Bulk Data GitHub page. +- The HL7® FHIR® Bulk Data Access (Flat FHIR®) (v1.0.1: STU 1) implementation specification adopted in § 170.215(d) includes mandatory support for the “group-export” "OperationDefinition." +- ONC has not included a requirement for Bulk FHIR® import because the standards for these features are still being developed by industry. Applications or systems seeking to import information formatting according to the HL7® FHIR® Bulk Data Access (Flat FHIR®) (V1.0.1:STU 1) can use several methods developed by industry, or can refer to Bulk FHIR® import methods being defined by HL7® at the HL7® FHIR® Bulk Data GitHub page. ### Application Registration ???+ quote "**Regulation text at § 170.315(g)(10)(iii)**" - (iii) Application registration. Enable an application to register with the Health IT Module’s “authorization server.” + (iii) *Application registration*. Enable an application to register with the Health IT Module's “authorization server.” ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(iii)*" @@ -184,14 +184,14 @@ healthcare providers to implement Health IT Modules certified to requirements in - ONC expects that apps executed within an implementer’s clinical environment will be registered with an authorization server, but ONC does not require a health IT developer to demonstrate its registration process for these “provider-facing” apps. - The requirement that health IT developers must enable an application to register with the § 170.315(g)(10)-certified Health IT Module’s authorization server only applies for the purposes of demonstrating technical conformance to the finalized certification criterion and API Condition and Maintenance of Certification requirements. The practices by all parties (including implementers of Health IT Modules) other than developers of Certified Health IT Modules are not in scope for this certification criterion nor the associated Condition and Maintenance of Certification requirements. -- Any practices associated with third-party application review or “vetting” by implementers must not violate the information blocking provisions established in the ONC Cures Act Final Rule. +- Any practices associated with third-party application review or “vetting” by implementers must not violate the information blocking provisions. !!! note "" [Health IT Feedback and Inquiry Portal Q&A: Paragraph (g)(10)(iii): Application Registration](inquiry-portal/g10-inquiries.md#paragraph-g10iii-application-registration) ### Secure Connection -???+ quote "**Regulation text at § 170.315(g)(10)(iv)(A)**" - (iv) Secure connection. (A) Establish a secure and trusted connection with an application that requests data for patient and user scopes in accordance with the implementation specifications adopted in § 170.215(b)(1) and (c). +???+ quote "**Regulation text at § 170.315(g)(10)(iv)**" + (iv) *Secure connection*. (A) Establish a secure and trusted connection with an application that requests data for patient and user scopes in accordance with the implementation specifications adopted in § 170.215(b)(1) and (c). (B) Establish a secure and trusted connection with an application that requests data for system scopes in accordance with the implementation specification adopted in § 170.215(d). ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(iv)*" @@ -210,7 +210,7 @@ healthcare providers to implement Health IT Modules certified to requirements in ### First time Authentication / Authorization for Single Patient Services ???+ quote "**Regulation text at § 170.315(g)(10)(V)(A)(1)**" - (v) Authentication and authorization—(A) Authentication and authorization for patient and user scopes—(1) First time connections—(i) Authentication and authorization must occur during the process of granting access to patient data in accordance with the implementation specification adopted in § 170.215(c) and standard adopted in § 170.215(e). (ii) A Health IT Module’s authorization server must issue a refresh token valid for a period of no less than three months to applications using the “confidential app” profile according to an implementation specification adopted in § 170.215(c). (iii) A Health IT Module’s authorization server must issue a refresh token for a period of no less than three months to native applications capable of securing a refresh token. + (v) *Authentication and authorization*—(A) *Authentication and authorization for patient and user scopes*—(1) *First time connections*—(i) Authentication and authorization must occur during the process of granting access to patient data in accordance with the implementation specification adopted in § 170.215(c) and standard adopted in § 170.215(e). (ii) Authentication and authorization must occur during the process of granting access to patient data in accordance with the implementation specification adopted in § 170.215(c) and standard adopted in § 170.215(e). (iii) A Health IT Module's authorization server must issue a refresh token for a period of no less than three months to native applications capable of securing a refresh token. ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(v)(A)(1)*" @@ -312,7 +312,7 @@ healthcare providers to implement Health IT Modules certified to requirements in ### Subsequent Authentication / Authorization for Single Patient Services ???+ quote "**Regulation text at § 170.315(g)(10)(V)(A)(2)**" - (2) Subsequent connections. (i) Access must be granted to patient data in accordance with the implementation specification adopted in § 170.215(c) without requiring re-authorization and re-authentication when a valid refresh token is supplied by the application. (ii) A Health IT Module’s authorization server must issue a refresh token valid for a new period of no less than three months to applications using the “confidential app” profile according to an implementation specification adopted in § 170.215(c). + (2) *Subsequent connections*. (i) Access must be granted to patient data in accordance with the implementation specification adopted in § 170.215(c) without requiring re-authorization and re-authentication when a valid refresh token is supplied by the application. (ii) A Health IT Module's authorization server must issue a refresh token valid for a new period of no less than three months to applications using the “confidential app” profile according to an implementation specification adopted in § 170.215(c). ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(V)(A)(2)*" @@ -335,7 +335,7 @@ new period of no less than three months. ??? info "Subsequent Authentication / Authorization for Single Patient Services: Sequence Diagram" As specified in RFC 6749 and the HL7® SMART Application Launch Framework Implementation Guide, authorization servers can send and receive refresh tokens to and from apps in two different OAuth 2.0 connection flows. On [first time connections (see sequence diagram above)](#first-time-authentication-authorization-for-single-patient-services), an app requests an authorization code and is granted one after obtaining end-user authorization. An app can then exchange a valid authorization code for an initial access token and initial refresh token. - After an access token expires, an app can subsequently connect to an authorization server to exchange a valid refresh token for a new access token and also have its refresh token renewed without needing to obtain end-user authorization. During both exchanges, security is increased (i.e., greater protection against leaked refresh tokens) when confidential apps use their client secret for client authentication. The (g)(10) criterion paragraphs at § 170.315(g)(10)(v)(A)(1)(ii) and § 170.315(g)(10)(v)(A)(2)(ii) require that apps “capable of storing a client secret” and thus capable of authenticating themselves, must be given a refresh token upon valid first time connections and have their refresh tokens renewed upon valid subsequent connections. This enables persistent access for apps capable of storing a client secret without requiring end-user re-authorization. + After an access token expires, an app can subsequently connect to an authorization server to exchange a valid refresh token for a new access token and also have its refresh token renewed without needing to obtain end-user authorization. During both exchanges, security is increased (i.e., greater protection against leaked refresh tokens) when confidential apps use their client secret for client authentication. The (g)(10) criterion paragraphs at § 170.315(g)(10)(v)(A)(1)(ii) and § 170.315(g)(10)(v)(A)(2)(ii) require that apps using the “confidential app” profile and thus capable of authenticating themselves, must be given a refresh token upon valid first time connections and have their refresh tokens renewed upon valid subsequent connections. This enables persistent access for apps using the “confidential app” profile without requiring end-user re-authorization. **Subsequent connections:** ``` mermaid @@ -348,7 +348,7 @@ new period of no less than three months. alt App is a “confidential app” according to an implementation specification adopted in § 170.215(c) (SMART App Launch IG) app ->> authz: Refresh token note over app,authz: Client secret used for authentication - note over authz: The (g)(10) criterion paragraph at § 170.315(g)(10)(v)(A)(2)(ii) requires
that apps capable of storing a client secret have their refresh tokens renewed
(i.e., made valid for a new period of no less than three months). This could
include the authorization server issuing a new refresh token or renewing the
existing refresh token. + note over authz: The (g)(10) criterion paragraph at § 170.315(g)(10)(v)(A)(2)(ii) requires
that apps using the “confidential app” profile have their refresh tokens renewed
(i.e., made valid for a new period of no less than three months). This could
include the authorization server issuing a new refresh token or renewing the
existing refresh token. alt Health IT Module's Authorization Server issues a new refresh token authz -->> app: New access token and new refresh token response else Health IT Module's Authorization Server renews existing refresh token @@ -367,7 +367,7 @@ new period of no less than three months. ### Authentication / Authorization for Multiple Patient Services ???+ quote "**Regulation text at § 170.315(g)(10)(v)(B)**" - (B) Authentication and authorization for system scopes. Authentication and authorization must occur during the process of granting an application access to patient data in accordance with the “SMART Backend Services: Authorization Guide” section of the implementation specification adopted in § 170.215(d) and the application must be issued a valid access token. + (B) *Authentication and authorization for system scopes*. Authentication and authorization must occur during the process of granting an application access to patient data in accordance with the “SMART Backend Services: Authorization Guide” section of the implementation specification adopted in § 170.215(d) and the application must be issued a valid access token. ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(v)(B)*" @@ -430,7 +430,7 @@ new period of no less than three months. ### Patient Authorization Revocation ???+ quote "**Regulation text at § 170.315(g)(10)(vi)**" - (vi) Patient authorization revocation. A Health IT Module’s authorization server must be able to revoke and must revoke an authorized application’s access at a patient’s direction within 1 hour of the request. + (vi) *Patient authorization revocation*. A Health IT Module's authorization server must be able to revoke and must revoke an authorized application's access at a patient's direction within 1 hour of the request. ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(vi)*" @@ -450,7 +450,7 @@ new period of no less than three months. ### Token Introspection ???+ quote "**Regulation text at § 170.315(g)(10)(vii)**" - (vii) Token introspection. A Health IT Module’s authorization server must be able to receive and validate tokens it has issued in accordance with an implementation specification in § 170.215(c). + (vii) *Token introspection*. A Health IT Module's authorization server must be able to receive and validate tokens it has issued in accordance with an implementation specification in § 170.215(c). ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(vii)*" @@ -464,7 +464,7 @@ new period of no less than three months. ### Technical API Documentation Content ???+ quote "**Regulation text at § 170.315(g)(10)(viii)(A)**" - (viii) Documentation. (A) The API(s) must include complete accompanying documentation that contains, at a minimum: (1) API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns. (2) The software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s). (3) All applicable technical requirements and attributes necessary for an application to be registered with a Health IT Module's authorization server. + (viii) *Documentation*. (A) The API(s) must include complete accompanying documentation that contains, at a minimum: (1) API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns. (2) The software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s). (3) All applicable technical requirements and attributes necessary for an application to be registered with a Health IT Module's authorization server. ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(viii)(A)*" @@ -510,30 +510,22 @@ The inferno.healthit.gov

-??? tip "Explore Inferno for (g)(10) Testing" - **Inferno Walkthroughs/Documentation** - - - :material-video: Inferno Walkthrough (Video) - - :material-file-document: Inferno Walkthrough (GitHub Wiki) - +??? tip "Explore Inferno for (g)(10) Testing" **Get Involved and Ask Questions** - - Join the Inferno Google Group (*Google account required, join by clicking "joining the group"*). Here you will also find information on the **Inferno Monthly Tech Talk** meeting which is open to anyone and occurs on the second Wednesday of each month from 1 - 2 PM EST. - Join the Inferno Zulip Stream on chat.fhir.org (*creating a Zulip account is free*). This stream is actively monitored by Inferno's development team. - Submit inquiries to ONC via the Health IT Feedback Portal. - Submit discovered technical issues on GitHub. - -### Drummond G10+ FHIR API powered by Touchstone -In July 2022, ONC announced the approval of the Drummond Group’s Drummond G10+ FHIR API powered by Touchstone tool, a new alternative test method (ATM) for testing conformance to ONC’s §170.315(g)(10) Standardized API for patient and population services certification criterion. Through this new ATM, software developers will now have a new option for conformance testing in addition to the previously approved Inferno (g)(10) Standardized API Test Kit. The approval of Drummond’s testing method continues ONC’s mission to further diversify the suite of test methods used as part of the ONC Health IT Certification Program. + - Join the Inferno Google Group (*Google account required, join by clicking "joining the group"*). Here you will also find information on the **Inferno Monthly Tech Talk** meeting which is open to anyone and occurs on the second Wednesday of each month from 1 - 2 PM EST. ### Real World Testing Condition and Maintenance of Certification **Health IT developers are required to test the real-world use of APIs.** -The § 170.315(g)(10) criterion is included under the Real World Testing Condition and Maintenance of Certification requirements of the ONC Cures Act Final Rule in §170.405, which states: +The § 170.315(g)(10) criterion is included under the Real World Testing Condition and Maintenance of Certification requirements in §170.405, which state: !!! note "" - “A health IT developer with Health IT Module(s) certified to any one or more 2015 Edition certification criteria in § 170.315(b), (c)(1) through (3), (e)(1), (f), (g)(7) through (10), and (h) must successfully test the real world use of those Health IT Module(s) for interoperability (as defined in 42 U.S.C.300jj(9) and § 170.102) in the type of setting in which such Health IT Module(s) would be/is marketed.” + “A health IT developer with one or more Health IT Module(s) certified to any one or more of the ONC Certification Criteria for Health IT in § 170.315(b), (c)(1) through (3), (e)(1), (f), (g)(7) through (10), and (h) must successfully test the real world use of those Health IT Module(s) for interoperability (as defined in 42 U.S.C. 300jj(9) and § 170.102) in the type of setting in which such Health IT Module(s) would be/is marketed.” More information can be found on the Real World Testing Fact Sheet and Real World Testing Resource Guide. @@ -542,7 +534,7 @@ The § 170.315(g)(10) criterion is included under the SVAP landing page. +Using SVAP, Certified Health IT Developers are permitted to voluntarily use a more advanced version of the standard(s) and implementation specification(s) approved by the National Coordinator, than is adopted in the ONC Certification Criteria. Currently, this flexibility is limited to standards and implementation specifications that are adopted in the certification criteria required to meet the Real World Testing Condition of Certification, which include § 170.315(b), (c)(1) through (3), (e)(1), (f), (g)(7) through (10), and (h). Health IT developers must ensure that they address standards adopted under SVAP in their Real World Testing plans and results submitted to Authorized Certification Bodies. More information can be found on the SVAP landing page. {== From 16d0bebe72afd6840253d14bf8b8c9d14a3d6686 Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Wed, 20 Mar 2024 12:41:50 -0400 Subject: [PATCH 11/25] post hti-1 updates --- docs/404-conditions-maintenance.md | 38 ++++++++++++++---------------- docs/g10-criterion.md | 2 +- 2 files changed, 19 insertions(+), 21 deletions(-) diff --git a/docs/404-conditions-maintenance.md b/docs/404-conditions-maintenance.md index 93611ea..be2ec80 100644 --- a/docs/404-conditions-maintenance.md +++ b/docs/404-conditions-maintenance.md @@ -2,12 +2,12 @@ # API Conditions and Maintenance of Certification at § 170.404 -This section considers the API Condition and Maintenance of Certification requirements, including all the content contained in the ONC Cures Act Final Rule Conditions of Certification API preamble, the ONC Interim Final Rule API preamble and the regulation paragraphs in § 170.404. +This section considers the API Condition and Maintenance of Certification requirements, including all the content contained in the ONC Cures Act Final Rule Conditions of Certification API preamble, the ONC Interim Final Rule API preamble, the HTI-1 API preamble and the regulation paragraphs in § 170.404. ## Applicability § 170.404 applies to all developers with health IT certified to § 170.315(g)(7) – § 170.315(g)(10). -ONC described several actors in the preamble and regulation text for § 170.404. These actors are defined at § 170.404(c), and include “API Information Source”, “API User”, and “Certified API Developer”. ONC clarified in preamble and have included in the CCG for § 170.404 that “A person or entity is permitted to serve more than one role for the terms defined in § 170.404(c)” and “Stakeholders meet the definition of a term defined in § 170.404(c) based on the context in which they are acting.” Generally, the API Conditions and Maintenance of Certification requirements finalized in § 170.404 apply to Certified API Developers only, which are developers with Health IT Modules certified to § 170.315(g)(7), § 170.315(g)(8), § 170.315(g)(9) and/or § 170.315(g)(10). API Users and API Information Sources, unless they are also acting as a Certified API Developer, are not required to conform to § 170.315(g)(10) or abide by the requirements in § 170.404. The ONC Health IT Certification Program does not have certification criteria for patient facing applications developed by API Users. +ONC described several actors in the preamble and regulation text for § 170.404. These actors are defined at § 170.404(c), and include “API Information Source”, “API User”, and “Certified API Developer”. ONC clarified in preamble and have included in the CCG for § 170.404 that “A person or entity is permitted to serve more than one role for the terms defined in § 170.404(c)” and “Stakeholders meet the definition of a term defined in § 170.404(c) based on the context in which they are acting.” Generally, the API Conditions and Maintenance of Certification requirements finalized in § 170.404 apply to Certified API Developers only, which are developers with Health IT Modules certified to § 170.315(g)(7), § 170.315(g)(9) and/or § 170.315(g)(10). API Users and API Information Sources, unless they are also acting as a Certified API Developer, are not required to conform to § 170.315(g)(10) or abide by the requirements in § 170.404. The ONC Health IT Certification Program does not have certification criteria for patient facing applications developed by API Users. ## Certified APIs and the HIPAA Privacy Rule Certified API Developers must publish Service Base URLs for patient access. @@ -30,12 +30,12 @@ To submit questions or comments to ONC please use our information blocking provisions of the ONC Cures Act Final Rule, which include a larger scope of data. + - Regarding the recommendation by commenters that the scope of “all data elements” include the data elements of the standard adopted in § 170.213 and FHIR® resources referenced by the implementation specification adopted in § 170.215(b), ONC notes that both the standard and implementation specification are included in the interpretation of “all data elements of a patient's electronic health record to the extent permissible under applicable privacy laws” above. We note that this specific interpretation does not extend beyond the API Condition and Maintenance of Certification requirements finalized in § 170.404 and cannot be inferred to reduce the scope or applicability of other Cures Act Conditions of Certification or the information blocking provisions which include a larger scope of data. ### API Condition Of Certification Requirements #### API Condition Of Certification General Requirements ???+ quote "**Regulation text at § 170.404(A)(1)**" - (a) Condition of certification requirements—(1) General. A Certified API Developer must publish APIs and allow electronic health information from such technology to be accessed, exchanged, and used without special effort through the use of APIs or successor technology or standards, as provided for under applicable law, including providing access to all data elements of a patient's electronic health record to the extent permissible under applicable privacy laws. + (a) *Condition of certification requirements*—(1) *General*. A Certified API Developer must publish APIs and allow electronic health information from such technology to be accessed, exchanged, and used without special effort through the use of APIs or successor technology or standards, as provided for under applicable law, including providing access to all data elements of a patient's electronic health record to the extent permissible under applicable privacy laws. ??? quote "*Clarifications included in the § 170.404 Certification Companion Guide (CCG) that apply to paragraph § 170.404(A)(1)*" @@ -45,7 +45,7 @@ To submit questions or comments to ONC please use our ??? quote "*Clarifications included in the § 170.404 Certification Companion Guide (CCG) that apply to paragraph § 170.404(A)(2)*" @@ -56,7 +56,7 @@ To submit questions or comments to ONC please use our ??? quote "*Clarifications included in the § 170.404 Certification Companion Guide (CCG) that apply to paragraph § 170.404(A)(3)(I)*" @@ -77,12 +77,12 @@ To submit questions or comments to ONC please use our information blocking provisions established in the ONC Cures Act Final Rule, and would equally not be permitted by this API Condition of Certification requirement. -- Health IT developers are permitted to offer discounts to customers, as long as the discounted fees do not constitute information blocking and otherwise conform to ONC Cures Act Final Rule requirements as well as all other applicable laws. +- Any fee that is not covered by an exception would be suspect under the information blocking provisions and would equally not be permitted by this API Condition of Certification requirement. +- Health IT developers are permitted to offer discounts to customers, as long as the discounted fees do not constitute information blocking and otherwise conform to applicable ONC certification requirements as well as all other applicable laws. #### API Fees – Permitted Fee (Development, Deployment, Upgrades) ???+ quote "**Regulation text at § 170.404(A)(3)(II)**" - (ii) Permitted fee—development, deployment, and upgrades. A Certified API Developer is permitted to charge fees to an API Information Source to recover the costs reasonably incurred by the Certified API Developer to develop, deploy, and upgrade certified API technology. + (ii) *Permitted fee—development, deployment, and upgrades*. A Certified API Developer is permitted to charge fees to an API Information Source to recover the costs reasonably incurred by the Certified API Developer to develop, deploy, and upgrade certified API technology. ??? quote "*Clarifications included in the § 170.404 Certification Companion Guide (CCG) that apply to paragraph § 170.404(A)(3)(II)*" @@ -97,11 +97,11 @@ To submit questions or comments to ONC please use our information blocking provisions established by the ONC Cures Act Final Rule if the API Information Source is a “covered actor” for purposes of information blocking. Accordingly, we emphasize that such stakeholders should take care to ensure they do not engage in information blocking and are compliant with other federal and state laws and regulations that may prohibit or limit certain types of relationships involving remuneration. +- Should API Users stand to generate revenue from the use of their apps, any fee an API Information Source may impose would not be in scope for this Condition of Certification but would be subject to information blocking provisions if the API Information Source is a “covered actor” for purposes of information blocking. Accordingly, we emphasize that such stakeholders should take care to ensure they do not engage in information blocking and are compliant with other federal and state laws and regulations that may prohibit or limit certain types of relationships involving remuneration. #### API Fees – Permitted Fee (Recovering API Usage Costs) ???+ quote "**Regulation text at § 170.404(A)(3)(III)**" - (iii) Permitted fee—recovering API usage costs. A Certified API Developer is permitted to charge fees to an API Information Source related to the use of certified API technology. The fees must be limited to the recovery of incremental costs reasonably incurred by the Certified API Developer when it hosts certified API technology on behalf of the API Information Source. + (iii) *Permitted fee—recovering API usage costs*. A Certified API Developer is permitted to charge fees to an API Information Source related to the use of certified API technology. The fees must be limited to the recovery of incremental costs reasonably incurred by the Certified API Developer when it hosts certified API technology on behalf of the API Information Source. ??? quote "*Clarifications included in the § 170.404 Certification Companion Guide (CCG) that apply to paragraph § 170.404(A)(3)(III)*" @@ -116,7 +116,7 @@ To submit questions or comments to ONC please use our ??? quote "*Clarifications included in the § 170.404 Certification Companion Guide (CCG) that apply to paragraph § 170.404(A)(3)(IV)*" @@ -133,7 +133,7 @@ To submit questions or comments to ONC please use our ??? quote "*Clarifications included in the § 170.404 Certification Companion Guide (CCG) that apply to paragraph § 170.404(A)(4)*" @@ -149,7 +149,7 @@ To submit questions or comments to ONC please use our ??? quote "*Clarifications included in the § 170.404 Certification Companion Guide (CCG) that apply to paragraph § 170.404(B)(1)*" @@ -161,7 +161,7 @@ To submit questions or comments to ONC please use our ??? quote "*Clarifications included in the § 170.404 Certification Companion Guide (CCG) that apply to paragraph § 170.404(B)(2)*" @@ -174,8 +174,6 @@ To submit questions or comments to ONC please use our December 2021 ONC Lantern Workshop (starting at 36:47). - ??? question "Why is this requirement only applicable to Certified API Developers with health IT certified to § 170.315(g)(10) and only for publishing Service Base URLs for patient-facing APIs and not any others, including Bulk Data Access APIs?" - The regulatory requirement is a result of both a proposed provision (84 FR 7494; see also 84 FR 7483) and the consideration of public comments on the proposal with consideration given the benefits and burden of the requirement and alternative means to achieve ONC's policy goals (85 FR 25764-25765). - To facilitate patients’ access to their health information, ONC proposed requirements for Certified API Developers to publish FHIR Service Base URLs to “…allow health information from [APIs] to be accessed, exchanged, and used without special effort…including providing access to all data elements of **a patient’s** electronic health record…” (emphasis added) (84 FR 7494) @@ -187,7 +185,7 @@ To submit questions or comments to ONC please use our ??? quote "*Clarifications included in the § 170.404 Certification Companion Guide (CCG) that apply to paragraph § 170.404(B)(3)*" @@ -201,7 +199,7 @@ To submit questions or comments to ONC please use our ??? quote "*Clarifications included in the § 170.404 Certification Companion Guide (CCG) that apply to paragraph § 170.404(B)(4)*" @@ -211,7 +209,7 @@ To submit questions or comments to ONC please use our ??? quote "*Clarifications included in the § 170.404 Certification Companion Guide (CCG) that apply to paragraph § 170.404(C)*" diff --git a/docs/g10-criterion.md b/docs/g10-criterion.md index c0b8cf3..8f7e1aa 100644 --- a/docs/g10-criterion.md +++ b/docs/g10-criterion.md @@ -2,7 +2,7 @@ # HL7 FHIR API Criterion at § 170.315(g)(10) -This section considers the HL7®[^1] FHIR® standardized API for patient and population services certification criterion, including all of the content contained in the ONC Cures Act Final Rule API preamble, the IFC API preamble, HTI-1 API preamble, and the regulation paragraphs in § 170.315(g)(10). +This section considers the HL7®[^1] FHIR® standardized API for patient and population services certification criterion, including all of the content contained in the ONC Cures Act Final Rule API preamble, the ONC Interim Final Rule (g)(10) API preamble, HTI-1 API preamble, and the regulation paragraphs in § 170.315(g)(10). ## Applicability § 170.315(g)(10) is applicable to all health IT developers who are certifying to the EHR base definition. From 6ad213d29377bdbce112ae3295dce169501b9ba8 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Wed, 20 Mar 2024 16:46:31 +0000 Subject: [PATCH 12/25] pull latest ccg clarifications from healthit.gov --- docs/404-conditions-maintenance.md | 14 +++-- docs/g10-criterion.md | 87 ++++++++++++++++-------------- 2 files changed, 58 insertions(+), 43 deletions(-) diff --git a/docs/404-conditions-maintenance.md b/docs/404-conditions-maintenance.md index be2ec80..eca5de3 100644 --- a/docs/404-conditions-maintenance.md +++ b/docs/404-conditions-maintenance.md @@ -167,9 +167,15 @@ To submit questions or comments to ONC please use our ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(i)(A)*" - Technical outcome – Respond to requests for a single patient’s data according to the standard adopted in § 170.215(a)(1) and implementation specification adopted in § 170.215(a)(2), including the mandatory capabilities described in “US Core Server CapabilityStatement,” for each of the data included in the standard adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported. + Technical outcome – Respond to requests for a single patient’s data according to the standards and implementation specifications adopted in § 170.215(a) and (b)(1), including the mandatory capabilities described in “US Core Server CapabilityStatement,” for each of the data included in the corresponding standard adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported. ***Clarifications:*** @@ -68,16 +67,16 @@ healthcare providers to implement Health IT Modules certified to requirements in * For purposes of ONC Health IT Certification, health IT developers that always provide HL7® FHIR® “observation” values are not required to demonstrate Health IT Module support for “dataAbsentReason” elements. These include “dataAbsentReason” elements contained in the US Core implementation guide profiles and FHIR® Vital Sign profiles that build on the HL7® FHIR® “observation” and its derived profiles including HL7® FHIR® “observation-vitalsigns”, and HL7® FHIR® “observation-oxygensat”, including “component.dataAbsentReason” elements. However, health IT developers are still required to adhere to and demonstrate Health IT Module support for the [“Missing Data” section](http://hl7.org/fhir/us/core/STU3.1.1/general-guidance.html#missing-data) of the US Core implementation guide. * For purposes of testing and certification, health IT developers are not required to demonstrate Health IT Module support for the “USCoreFetchDocumentReferences” ($docref) US Core IG operation. - **Applies to base regulatory standard US Core 3.1.1** + **Applies to US Core 3.1.1 (expires on January 1, 2026)** * The HL7® Cross-Group Projects work group, through the [US Core 'Patch' Process](https://confluence.hl7.org/display/CGP/US+Core+%27Patch%27+Process) ticket [FHIR-28393](https://jira.hl7.org/browse/FHIR-28393), approved patching US Core 3.1.1 to remove "must support" from the "DocumentReference.custodian" data element. For the purposes of testing and certification, health IT developers are not required to demonstrate Health IT Module support for the “custodian” data element in the “DocumentReference” US Core 3.1.1 IG Profile. - **Applies to base regulatory standard US Core 3.1.1 and SVAP approved standard US Core 4.0.0:** + **Applies to US Core 3.1.1 and SVAP approved standard US Core 4.0.0 (expires on January 1, 2026):** - * For “Encounter,” “Organization,” and “Practitioner,” US Core IG profiles, only the “read” type interaction must be supported and will be included in testing and certification. For the “Location” FHIR® resource, Health IT Modules must either demonstrate support for the “read” type interaction or demonstrate support for providing the “Location” and FHIR® resource references as a contained resource. The “search” type interactions for these profiles and resource are not in scope for testing and certification. Health IT Modules must support these US Core IG profiles / FHIR® resource because they are included as “must support” data elements in US Core IG profiles required by the USCDI. + * For “Encounter,” “Organization,” and “Practitioner,” US Core IG profiles, only the “read” type interaction must be supported and will be included in testing and certification. For the “Location” FHIR® resource, Health IT Modules must either demonstrate support for the “read” type interaction or demonstrate support for providing the “Location” and FHIR® resource references as a contained resource. The “search” type interactions for these profiles and resource are not in scope for testing and certification. Health IT Modules must support these US Core IG profiles / FHIR® resource because they are included as “must support” data elements in US Core IG profiles required by the United States Core Data for Interoperability (USCDI). * Health IT Modules must support provenance according to the [“Basic Provenance Guidance” section of the US Core IG.](https://www.hl7.org/fhir/us/core/STU3.1.1/basic-provenance.html) - **Applies to SVAP approved standards US Core 5.0.1 and USCDI v2, and US Core 6.1.0 and USCDI v3:** + **Applies to US Core 6.1.0 and USCDI v3 (required by December 31, 2025):** * For the “Organization” US Core IG profile, only the “read” type interaction must be supported and will be included in testing and certification. For the “Location” FHIR® resource, Health IT Modules must either demonstrate support for the “read” type interaction or demonstrate support for providing the “Location” FHIR® resource reference as a contained resource. The “search” type interactions for these profiles and resource are not in scope for testing and certification. Health IT Modules must support these US Core IG profiles / FHIR® resource because they are included as “must support” data elements in US Core IG profiles required by the United States Core Data for Interoperability (USCDI). * For purposes of testing and certification, health IT developers are not required to demonstrate Health IT Module support for the “QuestionnaireResponse” US Core IG profile. @@ -103,7 +102,7 @@ healthcare providers to implement Health IT Modules certified to requirements in ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(i)(B)*" - Technical outcome – Respond to requests for multiple patients’ data as a group according to the standard adopted in § 170.215(a)(1), and implementation specifications adopted in § 170.215(a)(2) and (4), for each of the data included in the standard adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported. + Technical outcome – Respond to requests for multiple patients’ data as a group according to the standards and implementation specifications adopted in § 170.215(a), (b)(1) and (d), for each of the data included in the corresponding standard adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported. ***Clarifications:*** @@ -123,7 +122,7 @@ healthcare providers to implement Health IT Modules certified to requirements in ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(ii)(A)*" - Technical outcome – Respond to search requests for a single patient’s data consistent with the search criteria included in the implementation specification adopted in § 170.215(a)(2), specifically the mandatory capabilities described in “US Core Server CapabilityStatement”. + Technical outcome – Respond to search requests for a single patient’s data consistent with the search criteria included in the implementation specification adopted in § 170.215(b)(1), specifically the mandatory capabilities described in “US Core Server CapabilityStatement”. ***Clarifications:*** @@ -142,7 +141,7 @@ healthcare providers to implement Health IT Modules certified to requirements in ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(ii)(B)*" - Technical outcome – Respond to search requests for multiple patients' data consistent with the search criteria included in the implementation specification adopted in § 170.215(a)(4). + Technical outcome – Respond to search requests for multiple patients' data consistent with the search criteria included in an implementation specification adopted in § 170.215(d). ***Clarifications:*** @@ -172,13 +171,13 @@ healthcare providers to implement Health IT Modules certified to requirements in * This certification criterion requires a health IT developer, as finalized in the Condition of Certification requirements, to demonstrate its registration process, but does not require conformance to a standard. * The third-party application registration process that a health IT developer must meet under this criterion is not a form of review or “vetting” for purposes of this criterion. - **Applies to base regulatory standard US Core 3.1.1 and SVAP approved standard US Core 4.0.0:** + **Applies to US Core 3.1.1 and SVAP approved standard US Core 4.0.0 (expires on January 1, 2026):** - * For demonstration of the SMART IG "Standalone Launch" steps, health IT developers are permitted to scope US Core IG resources that do not exist in either the standard adopted at § 170.213 (USCDI version 1) or the "Compartment Patient" section of the standard adopted at § 170.215(a)(1) (HL7® FHIR® Release 4.0.1) as either patient/[Resource] or user/[Resource]. These resources include “Encounter,” “Device,” “Location,” “Medication,” “Organization,” “Practitioner,” and “PractitionerRole.” Health IT developers must document their supported scopes according to the technical documentation requirements at § 170.315(g)(10)(viii)(A) and § 170.404(a)(2). + * For demonstration of the SMART IG "Standalone Launch" steps, health IT developers are permitted to scope US Core IG resources that do not exist in either the standard adopted at § 170.213(a) (USCDI v1) or the "Compartment Patient" section of the standard adopted at § 170.215(a)(1) (HL7® FHIR® Release 4.0.1) as either patient/[Resource] or user/[Resource]. These resources include “Encounter,” “Device,” “Location,” “Medication,” “Organization,” “Practitioner,” and “PractitionerRole.” Health IT developers must document their supported scopes according to the technical documentation requirements at § 170.315(g)(10)(viii)(A) and § 170.404(a)(2). - **Applies to SVAP approved standards US Core 5.0.1 and USCDI v2, and US Core 6.1.0 and USCDI v3:** + **Applies to US Core 6.1.0 and USCDI v3 (required by December 31, 2025):** - * For demonstration of the SMART IG “Standalone Launch” steps, health IT developers are permitted to scope US Core IG resources that do not exist in either the standard adopted at § 170.213 (USCDI version 2) or the “Compartment Patient” section of the standard adopted at § 170.215(a)(1) (HL7® FHIR® Release 4.0.1) as either patient/[Resource] or user/[Resource]. These resources include “Device,” “Location,” “Medication,” “Organization,” “Practitioner,” and “PractitionerRole.” Health IT developers must document their supported scopes according to the technical documentation requirements at § 170.315(g)(10)(viii)(A) and § 170.404(a)(2). + * For demonstration of the SMART IG “Standalone Launch” steps, health IT developers are permitted to scope US Core IG resources that do not exist in either the standard adopted at § 170.213(b) (USCDI v3) or the “Compartment Patient” section of the standard adopted at § 170.215(a)(1) (HL7® FHIR® Release 4.0.1) as either patient/[Resource] or user/[Resource]. These resources include “Device,” “Location,” “Medication,” “Organization,” “Practitioner,” and “PractitionerRole.” Health IT developers must document their supported scopes according to the technical documentation requirements at § 170.315(g)(10)(viii)(A) and § 170.404(a)(2). *Additional Clarifications to the (g)(10) CCG:* @@ -195,14 +194,14 @@ healthcare providers to implement Health IT Modules certified to requirements in ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(iv)*" - Technical outcome - (A) Establish a secure and trusted connection with an application that requests data for patient and user scopes in accordance with the implementation specifications adopted in § 170.215(a)(2) and (3). (B) Establish a secure and trusted connection with an application that requests data for system scopes in accordance with the implementation specification adopted in § 170.215(a)(4). + Technical outcome - (A) Establish a secure and trusted connection with an application that requests data for patient and user scopes in accordance with the implementation specifications adopted in § 170.215(b)(1) and (c). (B) Establish a secure and trusted connection with an application that requests data for system scopes in accordance with an implementation specification adopted in § 170.215(d). ***Clarifications:*** **Applies to all applicable base regulatory and SVAP standards:** * TLS version 1.2 or above must be enforced for the appropriate connections. - * Health IT developers are encouraged but not required to follow [TLS Best Current Practice (BCP 195)](https://www.rfc-editor.org/info/bcp195) for TLS version enforcement, referenced in [section 6.1.0.3 of the HL7 4.0.1 Fast Healthcare Interoperability Resources Specification (FHIR) Release 4, October 30, 2019](http://hl7.org/fhir/R4/security.html#http), which recommends TLS 1.2 or above to be used for all production data exchange and limits support for lower versions of TLS. To meet ONC Certification requirements, Health IT developers must document how the Health IT Module enforces TLS version 1.2 or above to meet the API documentation requirements at § 170.315(g)(10)(viii) and API Transparency Conditions at 45 CFR 170.404(a)(2). + * Health IT developers are encouraged but not required to follow [TLS Best Current Practice (BCP 195)](https://www.rfc-editor.org/info/bcp195) for TLS version enforcement, referenced in [section 6.1.0.3 of the HL7](http://hl7.org/fhir/R4/security.html#http)® 4.0.1 Fast Healthcare Interoperability Resources Specification (FHIR®) Release 4, October 30, 2019, which recommends TLS 1.2 or above to be used for all production data exchange and limits support for lower versions of TLS. To meet ONC Certification requirements, Health IT developers must document how the Health IT Module enforces TLS version 1.2 or above to meet the API documentation requirements at § 170.315(g)(10)(viii) and API Transparency Conditions at 45 CFR 170.404(a)(2). !!! note "" @@ -214,38 +213,48 @@ healthcare providers to implement Health IT Modules certified to requirements in ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(v)(A)(1)*" - Technical outcome – For first time connections, authentication and authorization must occur during the process of granting access to patient data in accordance with the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(b). Additionally, a Health IT Module's authorization server must issue a refresh token valid for a period of no less than three months to applications capable of storing a client secret. Finally, a Health IT Module's authorization server must issue a refresh token for a period of no less than three months to native applications capable of securing a refresh token. + Technical outcome – For first time connections, authentication and authorization must occur during the process of granting access to patient data in accordance with an implementation specification adopted in § 170.215(c) and standard adopted in § 170.215(e)(1). Additionally, a Health IT Module’s authorization server must issue a refresh token valid for a period of no less than three months to applications using the “confidential app” profile according to an implementation specification adopted in § 170.215(c). Finally, a Health IT Module’s authorization server must issue a refresh token for a period of no less than three months to native applications capable of securing a refresh token. ***Clarifications:*** **Applies to all applicable base regulatory and SVAP standards:** - * Health IT Modules will be explicitly tested for US Core IG operations using authentication and authorization tokens acquired via the process described in the implementation specification adopted in § 170.215(a)(3). - * Only the relevant parts of the OpenID Connect Core 1.0 including errata set 1 adopted in § 170.215(b) that are also included in the implementation specification adopted in § 170.215(a)(3) will be in-scope for testing and certification. - * As part of the “permission-patient” “SMART on FHIR® Core Capability” in § 170.215(a)(3), Health IT Modules presented for testing and certification must include the ability for patients to authorize an application to receive their electronic health information (EHI) based on FHIR® resource-level scopes. Specifically, this means patients would need to have the ability to authorize access to their EHI at the individual FHIR® resource level, from one specific FHIR® resource (e.g., “Immunization”) up to all FHIR® resources necessary to implement the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2). + * Health IT Modules will be explicitly tested for US Core IG operations using authentication and authorization tokens acquired via the process described in an implementation specification adopted in § 170.215(c). + * Only the relevant parts of the OpenID Connect Core 1.0 including errata set 1 adopted in § 170.215(e)(1) that are also included in an implementation specification adopted in § 170.215(c) will be in-scope for testing and certification. + * As part of the “permission-patient” “SMART on FHIR® Core Capability” in § 170.215(c), Health IT Modules presented for testing and certification must include the ability for patients to authorize an application to receive their electronic health information (EHI) based on FHIR® resource-level scopes. Specifically, this means patients would need to have the ability to authorize access to their EHI at the individual FHIR® resource level, from one specific FHIR® resource (e.g., “Immunization”) up to all FHIR® resources necessary to implement a standard adopted in § 170.213 and corresponding implementation specification adopted in § 170.215(b)(1). * Although Health IT Modules presented for testing and certification must include the ability for patients to authorize an application to receive their EHI based on FHIR® resource-level scopes, Health IT Modules are not prohibited from presenting authorization scopes in a more user-friendly format (e.g. grouping resources under categories, renaming the scopes for easier comprehension by the end-user, using more granular scopes), as long as the ability for patients to authorize applications based on resource-level scopes is available, if requested by the patient. - * Health IT Modules will only be tested for the "Patient Access for Standalone Apps" and "Clinician Access for EHR Launch" "Capability Sets”described in the standard adopted at § 170.215(a)(3). - * Since the “Patient Access for Standalone Apps” and “Clinician Access for EHR Launch” “Capability Sets” do not include “context-standalone-encounter" ONC will not test Health IT Modules for support for the "context-standalone-encounter" SMART on FHIR® Capability described in the standard adopted at § 170.215(a)(3). + * For § 170.315(g)(10) criterion requirements at § 170.315(g)(10)(v)(A) regarding authorization for patient and user scopes, we clarify wildcard scopes as defined in the implementation specifications at § 170.215(c) are not required to be supported. + * Health IT Modules will only be tested for the "Patient Access for Standalone Apps" and "Clinician Access for EHR Launch" "Capability Sets” described in an implementation specification adopted at § 170.215(c). + * Since the “Patient Access for Standalone Apps” and “Clinician Access for EHR Launch” “Capability Sets” do not include “context-standalone-encounter" ONC will not test Health IT Modules for support for the "context-standalone-encounter" SMART on FHIR® Capability described in an implementation specification adopted at § 170.215(c). * Implementers of § 170.315(g)(10)-certified Health IT Modules should be mindful of the information blocking provisions. - * As part of the requirements at § 170.315(g)(10)(v)(A)(1)(iii), health IT developers must publish the method(s) by which their Health IT Modules support the secure issuance of an initial refresh token to native applications according to the technical documentation requirements at § 170.315(g)(10)(viii) and transparency conditions at § 170.404(a)(2). [see also [ONC Clarifications in the Interim Final Rule to Support Native Applications](https://www.healthit.gov/sites/default/files/page/2021-07/Clarifications_For_Native_Apps_v5.pdf)] + * As part of the requirements at § 170.315(g)(10)(v)(A)(1)(iii), health IT developers must publish the method(s) by which their Health IT Modules support the secure issuance of an initial refresh token to native applications according to the technical documentation requirements at § 170.315(g)(10)(viii) and transparency conditions at § 170.404(a)(2). [see also [ONC Clarifications in the Interim Final Rule to Support Native Applications](https://www.healthit.gov/sites/default/files/page/2021-07/Clarifications_For_Native_Apps_v5.pdf)] * Application developer affirmations to health IT developers regarding the ability of their applications to secure a refresh token, a client secret, or both, must be treated in a good faith manner consistent with the provisions established in the openness and pro-competitive conditions at § 170.404(a)(4). * Health IT developers can determine the method(s) they use to support interactions with native applications and clarify that health IT developers are not required to support all methods third-party application developers seek to use. - * ONC recognizes there may be some ambiguity in the HL7® SMART Application Launch Framework Implementation Guide (incorporated by reference at § 170.215(a)(3)) in its guidance for supporting native applications, in particular, in providing references to best practices, strategies, and examples such as “OAuth 2.0 for Native Apps: 8.5. Client Authentication”, “OAuth 2.0 Dynamic Client Registration Protocol”, and “universal redirect\_uris” without a standardized solution. ONC provides flexibility for how the health IT developer implements the HL7® SMART Application Launch Framework implementation specification, as long as the Certified Health IT Module supports for first time connections the issuance of three-month refresh tokens to native applications capable of securing a refresh token. - * The paragraph at § 170.215(a)(3) requires health IT developers to support the SMART Application Launch Framework Implementation Guide (SMART IG) “SMART [on FHIR®] Core Capabilities,” including “permission-offline,” which grants support for refresh tokens. The ONC Cures Act Final Rule states, “…Importantly, the implementation specification adopted in § 170.215(a)(3) requires that patients have the ability to explicitly enable the “offline\_access” scope during authorization. If the “offline\_access” scope is not enabled by patients, patients will be required to re-authenticate and re-authorize an application's access to their EHI after the application's access token expires…” ([85 FR 25747](https://www.federalregister.gov/d/2020-07419/p-1254)). However, the ability of a patient to explicitly enable the “offline\_access” scope during authorization is not described in the implementation specification. ONC clarifies that health IT developers must support the ability for patients to be provided information about an application’s request for persistent access prior to the patient sharing their health information, in order to enable patients to make an informed decision during authorization. Examples include, but are not limited to a health IT developer allowing patients to granularly grant “offline-access” scopes during authorization or clearly providing this information as a notice during authorization. The critical requirement is that patients are empowered to deny authorization for offline access. + * ONC recognizes there may be some ambiguity in the HL7® SMART Application Launch Framework Implementation Guide (incorporated by reference at § 170.215(c)) in its guidance for supporting native applications, in particular, in providing references to best practices, strategies, and examples such as “OAuth 2.0 for Native Apps: 8.5. Client Authentication”, “OAuth 2.0 Dynamic Client Registration Protocol”, and “universal redirect\_uris” without a standardized solution. ONC provides flexibility for how the health IT developer implements the HL7® SMART Application Launch Framework implementation specification, as long as the Certified Health IT Module supports for first time connections the issuance of three-month refresh tokens to native applications capable of securing a refresh token. + * The paragraph at § 170.215(c) requires health IT developers to support the SMART Application Launch Framework Implementation Guide (SMART IG) “SMART [on FHIR®] Core Capabilities,” including “permission-offline,” which grants support for refresh tokens. The implementation specifications adopted in § 170.215(c) require that patients have the ability to explicitly enable the “offline\_access” scope during authorization. If the “offline\_access” scope is not enabled by patients, patients will be required to re-authenticate and re-authorize an application's access to their EHI after the application's access token expires. However, the ability of a patient to explicitly enable the “offline\_access” scope during authorization is not described in the implementation specification. ONC clarifies that health IT developers must support the ability for patients to be provided information about an application’s request for persistent access prior to the patient sharing their health information, in order to enable patients to make an informed decision during authorization. Examples include, but are not limited to a health IT developer allowing patients to granularly grant “offline-access” scopes during authorization or clearly providing this information as a notice during authorization. The critical requirement is that patients are empowered to deny authorization for offline access. + * The SMART capabilities in § 170.215(c) are explicitly required for testing and certification because these capabilities are otherwise indicated as optional in the implementation specification. - **Applies to base regulatory standard US Core 3.1.1 and SVAP approved standard US Core 4.0.0:** + **Applies to US Core 3.1.1 and SVAP approved standard US Core 4.0.0 (expires on January 1, 2026):** - * Since "Encounter" is not a USCDI v1 data class or data element, ONC will not test Health IT Modules for support for "context-ehr-encounter" SMART on FHIR® Core Capabilities described in the standard adopted at § 170.215(a)(3). + * Since "Encounter" is not a USCDI v1 data class or data element, ONC will not test Health IT Modules for support for "context-ehr-encounter" SMART on FHIR® Core Capabilities described in an implementation specification adopted at § 170.215(c). - **Applies to base regulatory standard SMART App Launch Framework 1.0.0:** + **Applies to SMART App Launch Framework 1.0.0 (expires on January 1, 2026):** - * The “SMART on FHIR® Core Capabilities” in § 170.215(a)(3) are explicitly required for testing and certification because these capabilities are otherwise indicated as optional in the implementation specification. * As described in the ONC Cures Act Final Rule, we encourage implementers to adhere to industry best practices to mitigate Cross-Site Request Forgery (CSRF) and other known security threats ([85 FR 25742](https://www.federalregister.gov/d/2020-07419/p-1186)). Proof Key for Code Exchange (PKCE) ([Internet Engineering Task Force Request for Comments 7636](https://datatracker.ietf.org/doc/html/rfc7636)) is an industry standard that can help mitigate CSRF and other known security threats. The ONC Health IT Certification Program will support the optional use of PKCE during authentication and authorization testing. Health IT developers that implement and require the use of PKCE should include documentation for their PKCE implementation as part of the API Documentation requirement at [45 CFR 170.315(g)(10)(viii)](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170/subpart-C#p-170.315(g)(10)(viii)) and API Transparency Conditions at [45 CFR 170.404(a)(2)](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170/subpart-D#p-170.404(a)(2)). - **Applies to SVAP approved standard SMART App Launch Framework 2.0.0:** + **Applies to SMART App Launch 2.0.0:** - * The “capabilities” in AUT-PAT-25 of [this criterion’s test procedure](https://www.healthit.gov/test-method/standardized-api-patient-and-population-services#test_procedure) are explicitly required for testing and certification because these capabilities are otherwise indicated as optional in the implementation specification. * A Health IT Module may optionally support the "fhirContext" launch context parameter defined in the SMART App Launch 2.0.0 implementation guide. If the "fhirContext" parameter is supported, the Health IT Module must conform to the requirements for the parameter detailed in the SMART App Launch 2.0.0 implementation guide. + * We clarify the following SMART App Launch v2.0.0 capabilities must be supported as part of fulfilling the authentication and authorization requirements at § 170.315(g)(10)(v)(A) when certifying using the implementation specification at § 170.215(c)(2): + + To support patient access for standalone apps, the Health IT Module must support: + - the capabilities of "launch-standalone" and "context-standalone-patient"; and + - the capabilities in subsections "Authorization Methods", "Client Types", "Single Sign-on", and "Permissions" except the "permission-online" and "permission-user" capabilities + + To support clinician access for EHR launch, the Health IT Module must support: + - the capabilities of "launch-ehr", "context-banner", "context-style", "context-ehr-patient", and "context-ehr-encounter" (if supporting USCDI v2 or v3); and + - the capabilities in subsections "Authorization Methods", "Client Types", "Single Sign-on", and "Permissions" except the "permission-online" capability + * As finalized in the HTI-1 Final Rule ([89 FR 1294](https://www.federalregister.gov/d/2023-28857/p-1250)), Health IT Modules are required to support SMART App Launch v2.0.0 "Finer-grained resource constraints using search parameters" for the “category” parameter for the Condition resource with Condition sub-resources Encounter Diagnosis, Problem List, and Health Concern, and the Observation resource with Observation sub-resources Clinical Test, Laboratory, Social History, SDOH, Survey, and Vital Signs. We defer to the implementation guides referenced at § 170.215(b)(1) and § 170.215(c) for specific implementation guidance for this requirement. In the context of the US Core 6.1.0 implementation guide, the Observation sub-resources of Clinical Test and SDOH may have scopes supported as follows: + + support for scopes for the Observation sub-resource Clinical Test using the "procedure" code from the [US Core Clinical Result Observation Category value set](https://hl7.org/fhir/us/core/STU6.1/ValueSet-us-core-clinical-result-observation-category.html). + + support for scopes for the Observation sub-resource SDOH using the "sdoh" code from the [US Core Category code system](https://hl7.org/fhir/us/core/STU6.1/CodeSystem-us-core-category.html). *Additional Clarifications to the (g)(10) CCG:* @@ -316,7 +325,7 @@ healthcare providers to implement Health IT Modules certified to requirements in ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(V)(A)(2)*" - Technical outcome – For subsequent connections, access must be granted to patient data in accordance with the implementation specification adopted in § 170.215(a)(3) without requiring re-authorization and re-authentication when a valid refresh token is supplied by the application. Additionally, a Health IT Module's authorization server must issue a refresh token valid for a new period of no less than three months to applications capable of storing a client secret. + Technical outcome – For subsequent connections, access must be granted to patient data in accordance with an implementation specification adopted in§ 170.215(c) without requiring re-authorization and re-authentication when a valid refresh token is supplied by the application. Additionally, a Health IT Module’s authorization server must issue a refresh token valid for a new period of no less than three months to applications using the “confidential app” profile according to an implementation specification adopted in § 170.215(c). ***Clarifications:*** @@ -371,7 +380,7 @@ new period of no less than three months. ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(v)(B)*" - Technical outcome – Authentication and authorization must occur during the process of granting an application access to patient data in accordance with the “SMART Backend Services: Authorization Guide” section of the implementation specification adopted in § 170.215(a)(4) and the application must be issued a valid access token. + Technical outcome – Authentication and authorization must occur during the process of granting an application access to patient data in accordance with the “SMART Backend Services: Authorization Guide” section of an implementation specification adopted in § 170.215(d) and the application must be issued a valid access token. ***Clarifications:*** @@ -434,7 +443,7 @@ new period of no less than three months. ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(vi)*" - Technical outcome – A Health IT Module’s authorization server must be able to revoke an authorized application’s access at a patient’s direction. + Technical outcome – A Health IT Module’s authorization server must be able to revoke and must revoke an authorized application’s access at a patient’s direction within one hour of the request. ***Clarifications:*** @@ -442,7 +451,7 @@ new period of no less than three months. * This is a functional requirement to allow health IT developers the ability to implement it in a way that best suits their existing infrastructure and allows for innovative models for authorization revocation to develop. * Patients are expected to have the ability to revoke an authorized application’s access to their EHI at any time. - * For authorization revocation, Health IT Modules presented for certification are permitted to allow short-lived access tokens to expire in lieu of immediate access token revocation. ONC recommends health IT developers limit the lifetime of access tokens to one hour or less as recommended in the standard adopted at § 170.215(a)(3). For purposes of testing and certification, Health IT Modules will be tested for patient authorization revocation occurring within one hour of the request. + * For authorization revocation, Health IT Modules presented for certification are permitted to allow short-lived access tokens to expire in lieu of immediate access token revocation. ONC recommends health IT developers limit the lifetime of access tokens to one hour or less as recommended in the implementation specifications adopted at § 170.215(c). For purposes of testing and certification, Health IT Modules will be tested for patient authorization revocation occurring within one hour of the request. !!! note "" @@ -454,13 +463,13 @@ new period of no less than three months. ??? quote "*Clarifications included in the (g)(10) CCG that apply to paragraph § 170.315(g)(10)(vii)*" - Technical outcome – A Health IT Module’s authorization server must be able to receive and validate tokens it has issued. + Technical outcome – A Health IT Module’s authorization server must be able to receive and validate tokens it has issued in accordance with an implementation specification in § 170.215(c). ***Clarifications:*** **Applies to all applicable base regulatory and SVAP standards:** - * Although ONC does not specify a standard for token introspection, ONC encourages industry to coalesce around using a common standard, like OAuth 2.0 Token Introspection (RFC 7662), and specifically the profile of the OAuth 2.0 Token Introspection standard included in the SMART App Launch Framework 2.0.0 implementation specification. + * Health IT Developers must update their § 170.315(g)(10)-certified Health IT Modules to support token introspection as defined in the SMART App Launch 2.0.0 implementation specification and provide such updated Certified Health IT Modules to their customers by December 31, 2025. ### Technical API Documentation Content ???+ quote "**Regulation text at § 170.315(g)(10)(viii)(A)**" From 1378338a89e33aca8f1e68bae975828ba3c7faab Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Wed, 20 Mar 2024 13:25:11 -0400 Subject: [PATCH 13/25] post hti-1 updates --- docs/helpful-links.md | 22 ++++++++++++++-------- includes/abbreviations.md | 3 ++- 2 files changed, 16 insertions(+), 9 deletions(-) diff --git a/docs/helpful-links.md b/docs/helpful-links.md index ce29016..d7e88ca 100644 --- a/docs/helpful-links.md +++ b/docs/helpful-links.md @@ -15,10 +15,15 @@ - Inferno Program Edition (§ 170.315(g)(10)) - Inferno Framework: (g)(10) Standardized API Test Kit Online Demonstration Instance - Inferno Framework: (g)(10) Standardized API Test Kit Source Code -- Drummond G10+ FHIR API powered by Touchstone ## **Rules and regulations links** +=== "HTI-1" + - § 170.315(g)(10) Preamble + - § 170.315(g)(10) Regulation text + - § 170.404 Preamble + - § 170.404 Regulation text + === "Cures Act Final Rule" - § 170.315(g)(10) Preamble - § 170.315(g)(10) Regulation text @@ -44,17 +49,18 @@ === "§ 170.315(g)(10)" - § 170.213: United States Core Data for Interoperability (USCDI) - § 170.215(a)(1): Health Level 7 (HL7®) Version 4.0.1 Fast Healthcare Interoperability Resources Specification (FHIR®) Release 4, October 30, 2019 - - § 170.215(a)(2): FHIR® US Core Implementation Guide STU V3.1.1 - - § 170.215(a)(3): HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0 - - § 170.215(a)(4): HL7® FHIR® Bulk Data Access (Flat FHIR®) (V1.0.1:STU 1) - - § 170.215(b): OpenID Connect Core 1.0 incorporating errata set 1 + - § 170.215(b)(1): HL7® FHIR® US Core Implementation Guide STU 3.1.1. The adoption of this standard expires on January 1, 2026. + - § 170.215(b)(2): HL7® FHIR® US Core Implementation Guide STU 6.1.0 + - § 170.215(c)(1): HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0. The adoption of this standard expires on January 1, 2026. + - § 170.215(c)(2): HL7® SMART Application Launch Framework Implementation Guide Release 2.0.0 + - § 170.215(d)(1): HL7® FHIR® Bulk Data Access (Flat FHIR®) (V1.0.1:STU 1) + - § 170.215(e)(1): OpenID Connect Core 1.0 incorporating errata set 1 **Standards Version Advancement Process (SVAP) Version(s) Approved** - - United States Core Data for Interoperability (USCDI), Version 2, July 2021 + - United States Core Data for Interoperability (USCDI), Version 3, October 2022 Errata - HL7® FHIR® US Core Implementation Guide STU 4.0.0, June 2021 - - HL7® FHIR® US Core Implementation Guide STU 5.0.1, June 2022 - - HL7® FHIR® SMART Application Launch Framework Implementation Guide Release 2.0.0, November 26, 2021 + - HL7® FHIR® US Core Implementation Guide STU 6.1.0, June 30, 2023 - HL7® FHIR® Bulk Data Access (Flat FHIR®) (v2.0.0: STU 2), November 26, 2021 --8<-- "includes/abbreviations.md" diff --git a/includes/abbreviations.md b/includes/abbreviations.md index ee93aca..961752f 100644 --- a/includes/abbreviations.md +++ b/includes/abbreviations.md @@ -30,4 +30,5 @@ *[Cures Act Final Rule]: 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program -*[Interim Final Rule]: Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency \ No newline at end of file +*[Interim Final Rule]: Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency +*[HTI-1]: Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing \ No newline at end of file From 4be5865b2405e84923f5825e7d9256e5ffbc3bb2 Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Wed, 20 Mar 2024 13:49:58 -0400 Subject: [PATCH 14/25] HTI-1 updates and grouping pre 2023 inquiries --- docs/inquiry-portal/404-inquiries.md | 14 ++-- docs/inquiry-portal/g10-inquiries.md | 99 ++++++++++++++++++++-------- 2 files changed, 79 insertions(+), 34 deletions(-) diff --git a/docs/inquiry-portal/404-inquiries.md b/docs/inquiry-portal/404-inquiries.md index f012f76..d756c2d 100644 --- a/docs/inquiry-portal/404-inquiries.md +++ b/docs/inquiry-portal/404-inquiries.md @@ -7,7 +7,7 @@ This section contains anonymized feedback and inquiries, related to the API Cond The date headers provide important context as some information may have changed since the time of an inquiry and response. ## Paragraph (a)(3)(iv): API Fees - Permitted Fee (Value-Added Services) -### July 2021 +### Pre 2023 **Stakeholder Inquiry**: If an EHR developer’s API includes both certified and non-certified capabilities, does the entire API fall within the requirements of § 170.404? - Can an API be certified if it also contains non-certified capabilities so long as it also meets the certification criteria? @@ -42,7 +42,7 @@ To be open and transparent to the public, developers must provide a hyperlink to There are no exceptions to the requirement that Certified API Developers must publish service base URLs for all Health IT Modules certified to § 170.315(g)(10) that can be used by patients to access their EHI. -### October 2022 +### Older (Pre 2023) **Stakeholder Inquiry**: If an EHR vendor chooses to obtain and integrate a 3rd party solution that is certified to 170.315(g)(10), who is responsible for publish the service base URLs? **ONC Response**: The API Maintenance of Certification requirement at § 170.404(b)(2) requires a Certified API Developer to publish the service base URLs for all Health IT Modules certified to § 170.315(g)(10) that can be used by patients to access their electronic health information. This includes publishing the service base URLs for all of its customers regardless of whether the Health IT Modules certified to § 170.315(g)(10) are centrally managed by the Certified API Developer or locally deployed by an API Information Source. @@ -52,7 +52,7 @@ ONC provides discussion regarding Certified API Developer publication of service The ONC Cures Act Final Rule at 85 FR 25813 provides an example which discusses API Information Sources providing Certified API Developers service base URLs in the context of Information Blocking. ## Paragraph (b)(3): Rollout of (g)(10)-Certified APIs -### May 2022 +### Pre 2023 **Stakeholder Inquiry**: According to the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule (ONC Cures Act Final Rule) timeline, ONC Cures Update Certification Criteria must be made available by 12/31/2022. Can you clarify what "made available" means? **ONC Response**: The API Maintenance of Certification requirement at 45 CFR 170.404(b)(3) requires that a Certified API Developer with certified API technology previously certified to the certification criterion in § 170.315(g)(8) must deploy to all of their API Information Sources (e.g., customers) API technology certified to the criterion in § 170.315(g)(10) no later than December 31, 2022. @@ -63,7 +63,7 @@ Additional context and background discussion of this Maintenance of Certificatio We encourage all Certified Health IT Developers to work with their ONC-ACBs and customers to develop a certification and roll-out strategy to meet ONC Health IT Certification Program requirements by the required regulatory deadlines. -### April 2022 +### Older (Pre 2023) **Stakeholder Inquiry**: If an EHR system that is currently certified to (g)(7)-(g)(9) is unable to get certified to (g)(10) by January 1, 2023, what is the outcome with respect to their certification? - If they then certify to (g)(10) at some point in CY 2023 how is their CHPL entry effected? @@ -82,7 +82,8 @@ Additionally, if a Certified Health IT Developer does not comply with the Condit We encourage all Certified Health IT Developers to work with their ONC-ACBs and customers to develop a certification and roll-out strategy to meet all ONC Health IT Certification Program requirements by the required regulatory deadlines. -### February 2022 +*** + **Stakeholder Inquiry**: Can you provide some more information on what the requirement below entails? *A Certified API Developer with certified API technology previously certified to the certification criterion in § 170.315(g)(8) must provide all API Information Sources with such certified API technology deployed with certified API technology certified to the certification criterion in § 170.315(g)(10) by no later than December 31, 2022.* @@ -93,7 +94,8 @@ If a health IT developer currently has Health IT Modules certified to 45 CFR 170 We encourage health IT developers to work with their ONC-ACB and customers to develop a certification and roll-out strategy to meet ONC Health IT Certification Program requirements by the required regulatory deadlines. -### October 2021 +*** + **Stakeholder Inquiry**: Do all products have to be HL7® FHIR capable by Dec 31, 2022, or just the certified products? **ONC Response**: The API compliance requirement for certified products is contained in 45 CFR 170.404: API Conditions and Maintenance of Certification requirements. According to 170.404(b)(3): diff --git a/docs/inquiry-portal/g10-inquiries.md b/docs/inquiry-portal/g10-inquiries.md index ca6377e..d8c59c5 100644 --- a/docs/inquiry-portal/g10-inquiries.md +++ b/docs/inquiry-portal/g10-inquiries.md @@ -23,6 +23,8 @@ We note that these regulations do not require that impacted payers use health IT Regarding the 2023 date mentioned, you may be referring to the Promoting Interoperability (PI) Programs (previously Medicare and Medicaid EHR Incentive Programs) administered by the Centers for Medicare & Medicaid Services (CMS) which focus on adoption and use of certified health IT by eligible hospitals, critical access hospitals, and eligible clinicians. This program does include requirements that the health care providers who participate in the program use certified health IT incorporating FHIR APIs during 2023. For more information about the PI program for eligible hospitals and CAHs, see https://www.cms.gov/regulations-and-guidance/legislation/ehrincentiveprograms. For more information about the Promoting Interoperability performance category of MIPS that pertains to eligible clinicians, see https://qpp.cms.gov/. +*** + ### April 2023 **Stakeholder Inquiry**: Can a 3rd party app developer approach a Certified Health IT Developer for implementing a FHIR API without any reference from a Clinic/Provider/Patient? There should be consent from provider/clinic, or patient to share the info, right? @@ -48,6 +50,8 @@ For an overview of key elements of the HIPPA Privacy Rule including who is cover The Office for Civil Rights (OCR) enforces the HIPAA Privacy, Security, and Breach Notification Rules. For questions related to Health Information Privacy, please email OCRPrivacy@hhs.gov. +*** + ### January 2023 **Stakeholder Inquiry**: We have a question about this text in the US Core Server CapabilityStatement: !!! note "" @@ -66,7 +70,9 @@ Please see the ONC Certification (g)(10) Standardized API Test Kit implements tests according to the § 170.315(g)(10) Test Procedure. This Test Procedure defines tests to verify conformance to § 170.315(g)(10) requirements to support US Core profiles (or FHIR core profiles if no corresponding US Core profile exists) for each of the data in USCDI. Therefore, the Inferno ONC Certification (g)(10) Standardized API Test Kit includes tests for US Core profiles beyond the US Core Patient profile. -### November 2022 +*** + +### Older (Pre 2023) **Stakeholder Inquiry**: We have some questions regarding the consent requirements for § 170.315(g)(10) Standardized API for patient and population services. - If a patient is accessing data, are providers required to obtain a separate consent from the patient? @@ -91,17 +97,20 @@ For an overview of key elements of the HIPPA Privacy Rule including who is cover The Office for Civil Rights (OCR) enforces the HIPAA Privacy, Security, and Breach Notification Rules. For questions related to Health Information Privacy, please email OCRPrivacy@hhs.gov. -### October 2022 +*** + **Stakeholder Inquiry**: Can you confirm that the requirements of the 2015 Edition Cures Update Base EHR Definition (specifically the requirement to satisfy 170.315(g)(10)) can be met using one Certified Health IT Module or a combination of Certified Health IT Modules? **ONC Response**: You are correct that the requirements of the 2015 Edition Cures Update Base EHR Definition can be met using one Certified Health IT Module or a combination of Certified Health IT Modules. -### July 2022 +*** + **Stakeholder Inquiry**: Are there any (g)(10) requirements around patient data retention? **ONC Response**: Neither the § 170.315(g)(10) "Standardized API for patient and population services" certification criterion nor the § 170.315 (b)(10) "Electronic Health Information export" criterion have any data retention requirement. However, most states have laws and regulations governing the retention of patient medical records. As such, historical data should be maintained by the organization in accordance with all applicable state laws, and once those requirements have been met, managing historical data in a consistent manner as business needs dictate. Organizations must follow all HIPAA requirements for the destruction of protected health information. And, in addition, they should review the Office of Civil Rights guidance on data destruction to ensure their policies and practices align to it. -### June 2022 +*** + **Stakeholder Inquiry**: If a Health IT Developer is providing a FHIR Server and FHIR API for patient access, but not the authorization server (e.g. OAuth 2 + OIDC) or the App registration portal, can such a solution be certified? Some organizations already have an authorization server, so providing the Patient Access API involves integrating the FHIR API with the existing authorization server. It seems from a (g)(10) perspective that demonstration or live testing must include authorization, authentication, etc. As such is it accurate to assume that each fully integrated solution comprised of multiple vendor components needs to be certified, but that some of the individual components such as a FHIR API + FHIR Server cannot be certified alone? **ONC Response**: Health IT developers are permitted to use “relied upon software” to demonstrate compliance with certification criteria in ONC's Health IT Certification Program. Relied upon software is typically 3rd party software that is not developed by the health IT developer presenting its health IT for testing and certification. Relied upon software may be used to demonstrate compliance with a portion of an adopted certification criterion or an entire certification criterion. @@ -111,7 +120,8 @@ A developer must present its own health IT for certification, and may also use In the provided example, the health IT developer could use "relied upon software" in the form of an authorization server to fulfill authentication and authorization requirements in the § 170.315(g)(10) "Standardized API for patient and population services" criterion. However, a Health IT Module cannot be certified to the § 170.315(g)(10) "Standardized API for patient and population services" criterion without fulfilling all of its specified requirements, including authentication and authorization requirements. For more information about "relied upon software", please see the Relied Upon Software Program Guidance document. -### December 2021 +*** + **Stakeholder Inquiry**: If we certify to 170.315(g)(10), does that cover all of the API requirements specified in this PDF? https://www.healthit.gov/cures/sites/default/files/cures/2020-03/APICertificationCriterion.pdf Are there any other criteria in that PDF not covered in the (g)(10) criterion? @@ -124,7 +134,8 @@ The (g)(10) Test Procedure specifies a list of capabilities required by Health I We have also published an API Resource Guide which can be used to help navigate the API testing criteria in the ONC Health IT Certification Program. This interactive document includes all the information from the (g)(10) CCG and additional examples and context. -### September 2021 +*** + **Stakeholder Inquiry**: Is it sufficient for Certified API Technology to include at least one method of documenting and accessing data via an API for each data class for certification to (g)(10)? We are uncertain about how to handle ambiguities in the underlying standard(s). **ONC Response**: Health IT developers certified to the criterion at 45 CFR 170.315(g)(10) are required to support standardized API access to electronic health information according to the adopted standards and implementation specifications referenced in the criterion for all applicable information (e.g. USCDI and US Core IG “mandatory” and “must support” data elements) that have been incorporated into certified EHR technology. For example, some health organizations may choose to incorporate only a portion of a HL7 CDA document received from an external setting into their clinical record; (g)(10)-certified Health IT Modules would need to support access to the portion of incorporated information via a standardized FHIR-based API. Similarly, if a patient were to supply health information that was incorporated into the clinical record, (g)(10)-certified Health IT Modules would need to support access to the incorporated patient-supplied health information via a standardized FHIR-based API. @@ -137,15 +148,18 @@ In regard to ambiguities in the underlying standard(s) that present challenges f Any missing information made available via the (g)(10) standardized API should be represented as not available according to applicable standards and implementation specifications (e.g. US Core IG section 2.1.1.6: Missing Data). -### April 2021 +*** + **Stakeholder Inquiry**: Does the Cures Act mandate the use of FHIR for eCQM's? Also, if it is mandatory, from which performance year will this be applicable? **ONC Response**: The 21st Century Cures Act adopts a new API certification criterion §  170.315(g)(10) Standardized API for patient and population services. This API certification criterion requires the use of Health Level 7 (HL7®) Fast Healthcare Interoperability Resources (FHIR®) standard Release 4 and references several standards and implementation specifications including FHIR US Core Implementation Guide STU V3.1.1, and HL7 FHIR Bulk Data Access (Flat FHIR)(V1.0.0:STU 1). The ONC Certification criteria for eCQMs does not require any FHIR standards. For additional information on CMS regulations, please reference CMS sources or contact CMS if you have questions about specific requirements. The CMS.gov website is a great place to start for information about the requirements of any particular CMS program that may be of interest to health care providers and those who support them with health IT solutions. For one example, the Quality Payment Program overview page (https://qpp.cms.gov/about/qpp-overview) offers links to educational resources and information how to contact CMS. Similarly, the CMS.gov Promoting Interoperability Programs page (https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms) currently indicates that Medicare and dually eligible hospitals participating in the Medicare and Medicaid Promoting Interoperability Programs may contact the QualityNet help desk for assistance. +*** + ## Paragraph (g)(10)(i)(A): Data Response (Single Patient) -### October 2022 +### Pre 2023 **Stakeholder Inquiry**: Two FHIR® DocumentReference resource related questions: 1. The Inferno (g)(10) Standardized API Test Kit test 4.31.01 requires a system under test to demonstrate support for the Discharge Summary note type (18842-5). Are ambulatory vendors expected to demonstrate support for this note type for the purposes of (g)(10) certification? @@ -156,12 +170,14 @@ The ONC Certification criteria for eCQMs does not require any FHIR standards. Fo 1. The § 170.315(g)(10) "Standardized API for patient and population services" certification criterion requires the Health IT Module respond to requests for single and multiple patient's data according to the USCDI standard and the US Core implementation guide. Using the base regulatory standards for reference, the USCDI v1 standard requires support for the "Discharge Summary Note" data element and its corresponding LOINC code. Similarly, the US Core 3.1.1 implementation guide section 2.2.1 Clinical Notes Guidance requires support for the Discharge Summary clinical note and its corresponding LOINC code. Therefore, the Inferno testing tool tests for support for the Discharge Summary clinical note and its corresponding LOINC code. 1. To certify to the § 170.315(g)(10) criterion, a Health IT Module must respond to requests and searches for single and multiple patient's data according to the USCDI standard and the US Core implementation guide. This includes support for the USCDI Clinical Notes data class and the corresponding SHALL and Must Support requirements in the US Core clinical notes guidance and FHIR profiles (e.g., DocumentReference). The US Core 3.1.1 implementation guide includes a shall requirement in the DocumentReference profile to "support searching using the combination of the patient and type search parameters" and specifies "The DocumentReference.type binding must support at a minimum the 5 Common Clinical Notes and may extend to the full US Core DocumentReference Type Value Set". Thus, while the FHIR 4.0.1 specification provides flexibility to the server to determine which resources meet the search parameter criteria and provide additional search results if they are deemed relevant, the server should provide meaningful search results for searches regarding the 5 Common Clinical note types specified in the US Core implantation guide. Also, while the § 170.315(g)(10) criterion does not specify how patient data storage must be implemented, patient data should be stored in such a manner that permits the Health IT Module's single patient FHIR API to return relevant search results to FHIR searches. In the context of this inquiry, this includes providing appropriate search results to searches regarding the 5 Common Clinical note types specified in the US Core implementation guide. -### August 2022 +*** + **Stakeholder Inquiry**: The US Core IG requires support for the $docref operation. Can you clarify what the (g)(10) requirements regarding the $docref operation are? **ONC Response**: The § 170.315(g)(10) "Standardized API for patient and population services" certification criterion does not require support for the US Core $docref operation. -### December 2021 +*** + **Stakeholder Inquiry**: US Core 3.1.1 requires Procedure.performed. For (g)(10) certification how are we expected to accommodate cancelled or not done procedures where a date or period does not exist? **ONC Response**: Health IT modules certified to the Standardized API for patient and population services (45 CFR 170.315(g)(10)) must "Respond to requests for a single patient’s data according to the standard adopted in § 170.215(a)(1) and implementation specification adopted in § 170.215(a)(2), including the mandatory capabilities described in “US Core Server CapabilityStatement,” for each of the data included in the standard adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported." @@ -174,7 +190,8 @@ The requirements at 45 CFR 170.315(g)(10) do not currently address methods devel During the HL7 Connectathon, we discussed how the US Core version 3.1.1 IG does not satisfactorily address some of these Procedure use cases as described above, and observed efforts underway by HL7 to create a process in the US Core IG to better accommodate corrections to sections of prior standards (e.g. labeling certain updates as "patch" fixes). Unfortunately, we do not have a process in place to accommodate the updated conformance rules of `Procedure.performed[x]` in US Core 4.0.1 and later versions as a “patch” at this time, but we will monitor this effort over the next several months and provide any updates on the (g)(10) Certification Companion Guide when available. -### August 2021 +*** + **Stakeholder Inquiry**: US Core 3.1.1 requires that a server demonstrate support for the "composite OR" search for the CareTeam.status search parameter (US Core 3.1.1 CareTeam Mandatory Search Parameters). However, neither US Core, nor USCDI require that multiple CareTeam resource be supported. Can you clarify what is required here? **ONC Response**: According to the regulation text for the 170.315(g)(10) certification criterion at 45 CFR 170.315(g)(10)(i)(A), health IT developers must demonstrate the ability of Health IT Modules to: @@ -195,8 +212,10 @@ However, for purposes of testing and certification for the ONC Health IT Certifi We will issue a clarification on the § 170.315(g)(10) Standardized API for patient and population services Certification Companion Guide regarding this issue, and the Inferno testing tool will be updated in the next regular release, which occurs at least monthly, to accommodate this clarification. +*** + ## Paragraph (g)(10)(i)(B): Data Response (Multiple Patients) -### August 2022 +### Pre 2023 **Stakeholder Inquiry**: We are working on the Multi-Patient API Certification requirements, what are the requirements around group ids? **ONC Response**: The § 170.315(g)(10) "Standardized API for patient and population services" certification criterion requires the Health IT Module support requests for multiple patients’ data as a group using the “group-export” operation as detailed in the Bulk Data Access implementation guide. The `group-export` operation allows authorized clients to obtain FHIR resources pertaining to all patients in a specified Group. The client uses the Group ID to specify which Group is to be exported. @@ -209,7 +228,8 @@ The § 170.315(g)(10) criterion does not specify how the health IT developer cre Additionally, health IT developers may choose to implement the Standards Version Advancement Process (SVAP) approved standard of Bulk Data Access 2.0.0 instead of Bulk Data Access 1.0.1. Bulk Data Access 2.0.0 defines an experimental, optional "patient" parameter for the "group-export" operation which restricts the returned resources to the Patient Compartments associated with the patients specified within the parameter. -### June 2022 +*** + **Stakeholder Inquiry**: ONC (g)(10) Certification requirements and the Inferno Test Tool indicate that we are to demonstrate support for bulk FHIR requests with Group IDs (e.g. `[base url]/Group/[id]/$export`). Is there any minimum requirement in the upcoming 2022 (g)(10) certification for EHRs on how many different types of groups should be supported by the EHR? Can you give more guidance on what groups we need? **ONC Response**: The § 170.315(g)(10) "Standardized API for patient and population services" certification criterion requires the Health IT Module support requests for multiple patients’ data as a group using the “group-export” operation as detailed in the Bulk Data Access 1.0.1 implementation guide. The § 170.315(g)(10) criterion does not specify how the health IT developer creates groups nor how many groups must be supported. The health IT developer is expected to work with its customers to define the appropriate groups for export via the Health IT Module. @@ -218,7 +238,8 @@ Bulk Data Access 1.0.1 section 5.1.2 Endpoint - Group of Patients includes the f *How these Groups are defined is specific to each FHIR system’s implementation. For example, a payer may send a healthcare institution a roster file that can be imported into their EHR to create or update a FHIR group. Group membership could be based upon explicit attributes of the patient, such as age, sex or a particular condition such as PTSD or Chronic Opioid use, or on more complex attributes, such as a recent inpatient discharge or membership in the population used to calculate a quality measure. FHIR-based group management is out of scope for the current version of this implementation guide.* -### February 2022 +*** + **Stakeholder Inquiry**: We are seeking some further confirmation in relation to the [1] new clarification published to the (g)(10) Certification Companion Guide (CCG) on the use of capability URLs. Can our Health IT Module require clients to re-direct to a capability URL with an authorization header? [1] *Health IT Modules may use access control schemes other than OAuth 2.0 for controlling access to the file server, such as capability URLs. The HL7 FHIR-I Work Group has documented expectations for the use of capability URLs with the Bulk Data Access IG on the HL7 confluence website. For purposes of Certification testing, Health IT Modules will be tested for the ability to share bulk data files either using OAuth 2.0 bearer tokens or via capability URLs accessible without preconditions or additional steps.* @@ -229,7 +250,8 @@ As specified in Bulk Data Access 1.0.1 Inferno testing tool ONC Health IT Certification Program tests for § 170.315(g)(10) will be updated to accommodate this change in the coming weeks. +*** + ## Paragraph (g)(10)(iv): Secure Connection -### July 2022 +### Pre 2023 **Stakeholder Inquiry**: We are failing the Inferno (g)(10) Standardized API Test Kit test “5.3.01 Bulk Data Server is secured by transport layer security Server did not permit/deny the connections with the correct TLS versions.” Our implementation enforces TLS connections at the application layer and not the network layer. Is this allowable for certification to (g)(10)? **ONC Response**: ONC has issued the following clarification in the § 170.315(g)(10) "Standardized API for patient and population services" Certification Companion Guide regarding the requirements at § 170.315(g)(10)(iv) “Secure connection”. @@ -266,6 +292,8 @@ The information blocking regulations or requirements for successful participation in CMS programs such as the Promoting Interoperability Program. -### February 2022 +*** + +### Older (Pre 2023) **Stakeholder Inquiry**: Can you provide some more clarification on what is required in (g)(10)(v)(A)(1) where systems are expected to support refresh tokens for “no less than 3 months.” **ONC Response**: The § 170.315(g)(10) "Standardized API for patient and population services" certification criterion includes requirements for first time connections at § 170.315(g)(10)(v)(A)(1) that a Health IT Module’s authorization server must issue a refresh token valid for a period of no less than three months to applications capable of storing a client secret and native applications capable of securing a refresh token. A requirement for subsequent connections is also included under § 170.315(g)(10)(v)(A)(2) that a Health IT Module’s authorization server must issue a refresh token valid for a new period of no less than three months to applications capable of storing a client secret. These refresh token requirements are intended to enable a patient's persistent access to their electronic health information without special effort. In fulfillment of the aforementioned § 170.315(g)(10) requirements, health IT developers are not prohibited from allowing patients to express their persistent access preferences and from configuring the duration of persistent access according to patient preferences. When patients are presented with options for the duration of persistent access, an option of at least three months must be included. -### December 2021 +*** + **Stakeholder Inquiry**: What is a permissible method of allowing patients to authorize access to individual FHIR resources, and if this means that the FHIR server must be able to support requests from client applications for one to all USCDI resources; or if it means the FHIR server must allow the user at the time of authorization to pick/choose which resources are granted access? Client applications are often designed to request access for their full list and then be granted/denied for the full list and don’t necessarily support this individual selection option at the authorization level. Meaning, they say they need all requested items, and the user can accept that or deny it. @@ -300,7 +331,8 @@ Or, does the requirement mean the server MUST allow the user to choose which of In the example you provided, it would be acceptable “for the FHIR Server to have the user accept the list as a whole … or reject the list as a whole” as long as the patient has the ability to authorize the application based on resource-level scopes, if requested by the patient. For example, the patient could be presented a “request list for the user to blanket request/deny access” accompanied with a hyperlink that could direct them to choose individual resources, if they desired. -### May 2021 +*** + **Stakeholder Inquiry**: Can you clarify what is required of OAuth 2.0 in the Patient Access API? **ONC Response**: The § 170.315(g)(10) Standardized API for patient and population services certification criterion requires the following for authentication and authorization for patient and user scopes for first time connections: @@ -315,8 +347,10 @@ and for subsequent connections: - A Health IT Module’s authorization server must issue a refresh token valid for a new period of no less than three months to applications capable of storing a client secret. Beyond the certification criteria requirements, health IT developers are not required to support all methods that third-party application developers seek to use. Additional information and clarifications regarding this criterion can be found on the Certification Companion Guide for § 170.315(g)(10). +*** + ## Paragraph (g)(10)(v)(B): Authentication / Authorization for Multiple Patient Services -### October 2021 +### Pre 2023 **Stakeholder Inquiry**: There is a requirement that clients downloading the bulk data use the same access token as they did to make the original request. Does it permit other equivalently secure means of authorization as well? The FHIR specification says that there should be alternatives: https://hl7.org/fhir/uv/bulkdata/export/index.html#response---complete-status @@ -333,23 +367,28 @@ According to the requirements in § 170.315(g)(10)(v)(B), Health IT Modules must At a minimum for the ONC Health IT Certification Program, Health IT Modules certified to the § 170.315(g)(10) criterion must support the issuance of a valid access token to an application during authentication and authorization as per the “SMART Backend Services: Authorization Guide” section of the Bulk FHIR IG. However, if the minimum requirements are met, health IT developers may support additional access-control schemes beyond OAuth 2.0 bearer tokens. +*** + ## Paragraph (g)(10)(vi): Patient Auhtorization Revocation -### October 2021 +### Pre 2023 **Stakeholder Inquiry**: To satisfy the “Patient authorization revocation” requirements can short-lived access tokens be allowed to expire in lieu of immediate access token revocation? **ONC Response**: The § 170.315(g)(10) "Standardized API for patient and population services" Certification Companion Guide will be updated with the following clarification: *For authorization revocation, Health IT Modules presented for certification are permitted to allow short-lived access tokens to expire in lieu of immediate access token revocation. ONC recommends health IT developers limit the lifetime of access tokens to one hour or less as recommended in the standard adopted at § 170.215(a)(3), HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0. For purposes of testing and certification, Health IT Modules will be tested for patient authorization revocation occurring within one hour of the request.* +*** + ## Inferno -### July 2022 +### Pre 2023 **Stakeholder Inquiry**: In Inferno test 4.2.04 (and others) patient data is included in the URL of the HTTP GET request. Is this a Privacy and Security concern? **Stakeholder Inquiry**: The Inferno testing tool acts as a demanding client to test the conformance of servers to health IT standards. In particular, the ONC Certification (g)(10) Standardized API Test Kit, which uses Inferno, tests a health IT developer's APIs' conformance to the requirements of the § 170.315(g)(10) "Standardized API for patient and population services" certification criterion. The Inferno implementation provided by ONC on healthit.gov includes a banner indicating it is for demonstration purposes only and must not be used to access sensitive data or Protected Health Information (PHI). Regarding the privacy and security of the FHIR APIs certified to the § 170.315(g)(10) "Standardized API for patient and population services" certification criterion, there are numerous privacy and security requirements to protect patient data. The ONC Certification (g)(10) Standardized API Test Kit includes tests for conformance to authentication and authorization requirements, such as those detailed in the SMART App Launch Framework and SMART Backend Services: Authorization Guide, which require that only authorized clients can access data. Additionally, there are requirements that the connections for data responses for single and multiple patients' data are appropriately secured using Transport Layer Security (TLS) 1.2 or above. When used to secure HTTP connections via HTTPS, TLS protects the confidentiality of the data included in the HTTP URL via encryption, including the URL path and query string parameters (e.g. name and birthdate). -### June 2022 +*** + **Stakeholder Inquiry**: We are testing our FHIR Server using the Inferno (g)(10) Standardized API Test Kit. We are failing some Pulse Oximetry Tests. Specifically, in one of our Observation resources, we use dataAbsentReason for 'Inhaled oxygen flow rate'. But Inferno is failing the test mentioning that 'component.value[x].code' is not present in the Observation. Can you provide some clarity on why this is failing? **ONC Response**: The Inferno ONC Certification (g)(10) Standardized API Test Kit FAQ includes the following guidance regarding how Inferno tests the "MustSupport" flag on an element. @@ -365,7 +404,8 @@ For the Inferno Pulse Oximetry Tests (4.18), the Health IT Module must provide F *Relaxes constraint that prevented systems from returning additional resource types in search responses. Systems may return other resource types if they believe them to be relevant, and tests now provide informational messages in this case.* -### April 2022 +*** + **Stakeholder Inquiry**: Does ONC have a published list of IP addresses we can whitelist for the (g)(10) Standardized API Test Kit hosted at https://inferno.healthit.gov/onc-certification-g10-test-kit? **ONC Response**: The IP addresses for ONC's hosted instance of Inferno are as follows: @@ -373,7 +413,8 @@ For the Inferno Pulse Oximetry Tests (4.18), the Health IT Module must provide F - The latest Inferno release (inferno.healthit.gov): 52.20.119.0 - The development build of Inferno (inferno-dev.healthit.gov): 34.225.213.213 -### March 2022 +*** + **Stakeholder Inquiry**: Do we need to register Inferno as EHR Practitioner App to test ONC certification criteria or we can use SMART Apps like Cardiac Risk to test the criteria? If it’s the Inferno that we need to register for EHR Practitioner App criteria testing, can you please guide me on the workflow on which the EHR practitioner app criteria works for testing in Inferno tool? **ONC Response**: Response to Question 1: *Do we need to register Inferno as EHR Practitioner App to test the specific criteria or we can use SMART APPS like Cardiac Risk to test the criteria?* @@ -386,7 +427,8 @@ The "EHR Practitioner App" tests in Inferno require the Health IT Module demonst Additional detail regarding the "EHR Practitioner App" tests in Inferno is available in the ONC Certification (g)(10) Matrix provided with each Inferno release. The ONC Certification (g)(10) Matrix for the current version of Inferno is available via the onc-certification-g10-test-kit repository on GitHub. -### August 2021 +*** + **Stakeholder Inquiry**: What are the test data requirements for testing to (g)(10) using Inferno? **ONC Response**: The Inferno (g)(10) Standardized API Test Kit does not currently require a specific set of data to be entered into the system under test prior to testing. Instead, it leverages HL7 FHIR's built-in conformance rules to ensure that data returned is valid, conforms to required profiles, and contains all elements that must be supported. This allows systems to use either their own sample data or supplied sample data. @@ -395,7 +437,8 @@ If needed, Inferno supplies multiple synthetic data sets suitable for testing. T Otherwise, a health IT developer can supply their own sample data loaded into the system under test for certification, but the sample data must be able to demonstrate all the conformance requirements for certification according to the Test Procedure for 170.315(g)(10). We also encourage health IT developers read the clarifications provided on the Certification Companion Guide for 170.315(g)(10). -### April 2021 +*** + **Stakeholder Inquiry**: Can Inferno be used for Provider Directory testing? We have been able to use this tool for Patient Access API testing. **ONC Response**: The Inferno (g)(10) Standardized API Test Kit is designed to support the Standardized API for Patient and Population Services certification criterion (§ 170.315(g)(10)) for the ONC Health IT Certification Program. Since a provider directory is not part of the § 170.315(g)(10) certification criterion, the Inferno (g)(10) Standardized API Test Kit does not support provider directory testing. From f25d1a9bf1e5aa11ac5b4b095e959e67a3f2efef Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Thu, 21 Mar 2024 11:17:41 -0400 Subject: [PATCH 15/25] language cleanup --- docs/g10-criterion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/g10-criterion.md b/docs/g10-criterion.md index 5c69b82..8e62818 100644 --- a/docs/g10-criterion.md +++ b/docs/g10-criterion.md @@ -2,7 +2,7 @@ # HL7 FHIR API Criterion at § 170.315(g)(10) -This section considers the HL7®[^1] FHIR® standardized API for patient and population services certification criterion, including all of the content contained in the ONC Cures Act Final Rule API preamble, the ONC Interim Final Rule (g)(10) API preamble, HTI-1 API preamble, and the regulation paragraphs in § 170.315(g)(10). +This section considers the HL7®[^1] FHIR® standardized API for patient and population services certification criterion, including all of the relevant content contained in the ONC Cures Act Final Rule, the ONC Interim Final Rule, HTI-1, and the regulation paragraphs in § 170.315(g)(10). ## Applicability § 170.315(g)(10) is applicable to all health IT developers who are certifying to the EHR base definition. From 59ccb00f25981aad3b0b487fb6d1f12efa2e6b4f Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Thu, 21 Mar 2024 11:51:41 -0400 Subject: [PATCH 16/25] HTI-1 proof read fixes --- docs/404-conditions-maintenance.md | 4 ++-- docs/g10-criterion.md | 8 ++++---- includes/abbreviations.md | 11 +++++++---- 3 files changed, 13 insertions(+), 10 deletions(-) diff --git a/docs/404-conditions-maintenance.md b/docs/404-conditions-maintenance.md index eca5de3..2897622 100644 --- a/docs/404-conditions-maintenance.md +++ b/docs/404-conditions-maintenance.md @@ -2,7 +2,7 @@ # API Conditions and Maintenance of Certification at § 170.404 -This section considers the API Condition and Maintenance of Certification requirements, including all the content contained in the ONC Cures Act Final Rule Conditions of Certification API preamble, the ONC Interim Final Rule API preamble, the HTI-1 API preamble and the regulation paragraphs in § 170.404. +This section considers the API Condition and Maintenance of Certification requirements, including all the relevant content contained in the ONC Cures Act Final Rule, the ONC Interim Final Rule, HTI-1 and the regulation paragraphs in § 170.404. ## Applicability § 170.404 applies to all developers with health IT certified to § 170.315(g)(7) – § 170.315(g)(10). @@ -18,7 +18,7 @@ Certified API Developers are required to publish Service Base URLs (§ 170.404(b To submit questions or comments to ONC please use our Inquiry Portal. Anonymized versions of the § 170.404 inquires and responses that ONC has handled through this portal can be accessed on the [Health IT Feedback and Inquiry Portal: API Conditions and Maintenance of Certification at § 170.404](inquiry-portal/404-inquiries.md) page. -## Information Clarifications +## Information and Clarifications ### Entire Criterion diff --git a/docs/g10-criterion.md b/docs/g10-criterion.md index 8e62818..f331f8a 100644 --- a/docs/g10-criterion.md +++ b/docs/g10-criterion.md @@ -5,9 +5,9 @@ This section considers the HL7®[^1] FHIR® standardized API for patient and population services certification criterion, including all of the relevant content contained in the ONC Cures Act Final Rule, the ONC Interim Final Rule, HTI-1, and the regulation paragraphs in § 170.315(g)(10). ## Applicability -§ 170.315(g)(10) is applicable to all health IT developers who are certifying to the EHR base definition. +§ 170.315(g)(10) is applicable to all health IT developers who are certifying to the Base EHR definition. -The API certification criterion finalized in § 170.315(g)(10) was included as part of the EHR Base Definition at § 170.102. While developers of health information technology are not required by the ONC to meet certification requirements, including certification requirements that are included as part of the EHR Base Definition, several federal, state and tribal entities, including Centers for Medicare & Medicaid Services, Centers for Disease Control and Prevention, and other programs reference the ONC Health IT Certification Program and require the use of certified health IT for program participation. +The API certification criterion finalized in § 170.315(g)(10) was included as part of the Base EHR Definition at § 170.102. While developers of health information technology are not required by the ONC to meet certification requirements, including certification requirements that are included as part of the Base EHR Definition, several federal, state and tribal entities, including Centers for Medicare & Medicaid Services, Centers for Disease Control and Prevention, and other programs reference the ONC Health IT Certification Program and require the use of certified health IT for program participation. ## Health IT Feedback and Inquiry Portal @@ -342,7 +342,7 @@ decision left to the health IT developer, as long as the “refreshed” refresh new period of no less than three months. ??? info "Subsequent Authentication / Authorization for Single Patient Services: Sequence Diagram" - As specified in RFC 6749 and the HL7® SMART Application Launch Framework Implementation Guide, authorization servers can send and receive refresh tokens to and from apps in two different OAuth 2.0 connection flows. On [first time connections (see sequence diagram above)](#first-time-authentication-authorization-for-single-patient-services), an app requests an authorization code and is granted one after obtaining end-user authorization. An app can then exchange a valid authorization code for an initial access token and initial refresh token. + As specified in RFC 6749 and the HL7® SMART Application Launch Framework Implementation Guide, authorization servers can send and receive refresh tokens to and from apps in two different OAuth 2.0 connection flows. On [first time connections (see sequence diagram above)](#first-time-authentication-authorization-for-single-patient-services), an app requests an authorization code and is granted an authorization code after obtaining end-user authorization. An app can then exchange a valid authorization code for an initial access token and initial refresh token. After an access token expires, an app can subsequently connect to an authorization server to exchange a valid refresh token for a new access token and also have its refresh token renewed without needing to obtain end-user authorization. During both exchanges, security is increased (i.e., greater protection against leaked refresh tokens) when confidential apps use their client secret for client authentication. The (g)(10) criterion paragraphs at § 170.315(g)(10)(v)(A)(1)(ii) and § 170.315(g)(10)(v)(A)(2)(ii) require that apps using the “confidential app” profile and thus capable of authenticating themselves, must be given a refresh token upon valid first time connections and have their refresh tokens renewed upon valid subsequent connections. This enables persistent access for apps using the “confidential app” profile without requiring end-user re-authorization. @@ -515,7 +515,7 @@ The - ![Inferno (g)(10) testing tool logo](../images/inferno-logo.PNG){: style="height:100px"} + ![Inferno (g)(10) testing tool logo](images/inferno-logo.PNG){: style="height:100px"}

inferno.healthit.gov

diff --git a/includes/abbreviations.md b/includes/abbreviations.md index 961752f..d731705 100644 --- a/includes/abbreviations.md +++ b/includes/abbreviations.md @@ -8,6 +8,7 @@ *[IFC]: interim final rule with comment period *[API criteria]: Certification criteria at § 170.315(g)(7) - (10) *[SVAP]: Standards Version Advancement Process +*[USCDI]: United States Core Data for Interoperability @@ -15,16 +16,18 @@ *[FHIR]: HL7® Fast Healthcare Interoperability Resources *[a)(1]: Health Level 7 (HL7®) Version 4.0.1 Fast Healthcare Interoperability Resources Specification (FHIR®) Release 4, October 30, 2019 -*[a)(2]: FHIR® US Core Implementation Guide STU V3.1.1 -*[a)(3]: HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0 +*[b)(1]: FHIR® US Core Implementation Guide STU V3.1.1 +*[b)(2]: FHIR® US Core Implementation Guide STU V6.1.0 +*[c)(1]: HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0 +*[c)(2]: HL7® SMART Application Launch Framework Implementation Guide Release 2.0.0 +*[d)(1]: HL7® FHIR® Bulk Data Access (Flat FHIR®) (V1.0.1:STU 1) +*[e)(1]: OpenID Connect Core 1.0 incorporating errata set 1 *[170.213]: United States Core Data for Interoperability (USCDI) -*[USCDI]: United States Core Data for Interoperability *[g)(10]: Standardized HL7® FHIR-based API certification criterion *[170.404]: API Conditions and Maintenance of certification requirements that apply to health IT developers with Health IT Modules certified to § 170.315(g)(7) - (10) *[g)(7]: Non-standardized API certification criterion (patient selection) -*[g)(8]: Non-standardized API certification criterion (data category request) *[g)(9]: Non-standardized API certification criterion (all data request) *[170.405]: Real World Testing Condition and Maintenance of Certification requirements From dc8173d4c44bf5d3768c8271cd8661c752328e8f Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Fri, 22 Mar 2024 14:46:01 -0400 Subject: [PATCH 17/25] links for ATM --- docs/g10-criterion.md | 3 +++ docs/helpful-links.md | 1 + 2 files changed, 4 insertions(+) diff --git a/docs/g10-criterion.md b/docs/g10-criterion.md index f331f8a..693ce85 100644 --- a/docs/g10-criterion.md +++ b/docs/g10-criterion.md @@ -527,6 +527,9 @@ The GitHub. - Join the Inferno Google Group (*Google account required, join by clicking "joining the group"*). Here you will also find information on the **Inferno Monthly Tech Talk** meeting which is open to anyone and occurs on the second Wednesday of each month from 1 - 2 PM EST. +### Drummond G10+ FHIR API powered by Touchstone +In July 2022, ONC announced the approval of the Drummond Group’s Drummond G10+ FHIR API powered by Touchstone tool, a new alternative test method (ATM) for testing conformance to ONC’s §170.315(g)(10) Standardized API for patient and population services certification criterion. Through this new ATM, software developers will now have a new option for conformance testing in addition to the previously approved Inferno (g)(10) Standardized API Test Kit. The approval of Drummond’s testing method continues ONC’s mission to further diversify the suite of test methods used as part of the ONC Health IT Certification Program. + ### Real World Testing Condition and Maintenance of Certification **Health IT developers are required to test the real-world use of APIs.** diff --git a/docs/helpful-links.md b/docs/helpful-links.md index d7e88ca..51b79a2 100644 --- a/docs/helpful-links.md +++ b/docs/helpful-links.md @@ -15,6 +15,7 @@ - Inferno Program Edition (§ 170.315(g)(10)) - Inferno Framework: (g)(10) Standardized API Test Kit Online Demonstration Instance - Inferno Framework: (g)(10) Standardized API Test Kit Source Code + - Drummond G10+ FHIR API powered by Touchstone ## **Rules and regulations links** From 88bb512dd0764bbcbef8523d6d0d76c266d59c6a Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Fri, 22 Mar 2024 14:50:18 -0400 Subject: [PATCH 18/25] fix us core references --- docs/helpful-links.md | 4 ++-- includes/abbreviations.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/helpful-links.md b/docs/helpful-links.md index 51b79a2..8eaedad 100644 --- a/docs/helpful-links.md +++ b/docs/helpful-links.md @@ -50,8 +50,8 @@ === "§ 170.315(g)(10)" - § 170.213: United States Core Data for Interoperability (USCDI) - § 170.215(a)(1): Health Level 7 (HL7®) Version 4.0.1 Fast Healthcare Interoperability Resources Specification (FHIR®) Release 4, October 30, 2019 - - § 170.215(b)(1): HL7® FHIR® US Core Implementation Guide STU 3.1.1. The adoption of this standard expires on January 1, 2026. - - § 170.215(b)(2): HL7® FHIR® US Core Implementation Guide STU 6.1.0 + - § 170.215(b)(1)(i): HL7® FHIR® US Core Implementation Guide STU 3.1.1. The adoption of this standard expires on January 1, 2026. + - § 170.215(b)(1)(ii): HL7® FHIR® US Core Implementation Guide STU 6.1.0 - § 170.215(c)(1): HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0. The adoption of this standard expires on January 1, 2026. - § 170.215(c)(2): HL7® SMART Application Launch Framework Implementation Guide Release 2.0.0 - § 170.215(d)(1): HL7® FHIR® Bulk Data Access (Flat FHIR®) (V1.0.1:STU 1) diff --git a/includes/abbreviations.md b/includes/abbreviations.md index d731705..f1b1a70 100644 --- a/includes/abbreviations.md +++ b/includes/abbreviations.md @@ -16,8 +16,8 @@ *[FHIR]: HL7® Fast Healthcare Interoperability Resources *[a)(1]: Health Level 7 (HL7®) Version 4.0.1 Fast Healthcare Interoperability Resources Specification (FHIR®) Release 4, October 30, 2019 -*[b)(1]: FHIR® US Core Implementation Guide STU V3.1.1 -*[b)(2]: FHIR® US Core Implementation Guide STU V6.1.0 +*[b)(1)(i]: FHIR® US Core Implementation Guide STU V3.1.1 +*[b)(1)(ii]: FHIR® US Core Implementation Guide STU V6.1.0 *[c)(1]: HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0 *[c)(2]: HL7® SMART Application Launch Framework Implementation Guide Release 2.0.0 *[d)(1]: HL7® FHIR® Bulk Data Access (Flat FHIR®) (V1.0.1:STU 1) From 3ea8dc59079fa0822ae946272be8aea638b0f101 Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Fri, 22 Mar 2024 15:15:04 -0400 Subject: [PATCH 19/25] update inquiry headers --- docs/inquiry-portal/404-inquiries.md | 14 +++--- docs/inquiry-portal/g10-inquiries.md | 65 ++++++++-------------------- 2 files changed, 25 insertions(+), 54 deletions(-) diff --git a/docs/inquiry-portal/404-inquiries.md b/docs/inquiry-portal/404-inquiries.md index d756c2d..8fc19a9 100644 --- a/docs/inquiry-portal/404-inquiries.md +++ b/docs/inquiry-portal/404-inquiries.md @@ -7,7 +7,7 @@ This section contains anonymized feedback and inquiries, related to the API Cond The date headers provide important context as some information may have changed since the time of an inquiry and response. ## Paragraph (a)(3)(iv): API Fees - Permitted Fee (Value-Added Services) -### Pre 2023 +### 2021 Inquiries **Stakeholder Inquiry**: If an EHR developer’s API includes both certified and non-certified capabilities, does the entire API fall within the requirements of § 170.404? - Can an API be certified if it also contains non-certified capabilities so long as it also meets the certification criteria? @@ -27,7 +27,7 @@ We are not able to provide individualized advice on whether a specific fact patt Anyone who believes they may have experienced or observed information blocking by any health care provider, health IT developer of Certified Health IT, or health information network or health information exchange is encouraged to share their concerns with us through the Information Blocking Portal on ONC’s website, HealthIT.gov. ## Paragraph (b)(2): Service base URL publiciation -### June 2023 +### June 2023 Inquiries **Stakeholder Inquiry**: I have questions about the regulatory text in the ONC Cures Act Final Rule found here: https://www.federalregister.gov/d/2020-07419/p-1405. Should this list be published on CHPL? We see the "place" for the information on CHPL, but we are seeing that many EHRs have very little to no information published and most don't have their customer list. Is this a violation of the requirements? Are there any exceptions to publishing this information? @@ -42,7 +42,7 @@ To be open and transparent to the public, developers must provide a hyperlink to There are no exceptions to the requirement that Certified API Developers must publish service base URLs for all Health IT Modules certified to § 170.315(g)(10) that can be used by patients to access their EHI. -### Older (Pre 2023) +### 2022 Inquiries **Stakeholder Inquiry**: If an EHR vendor chooses to obtain and integrate a 3rd party solution that is certified to 170.315(g)(10), who is responsible for publish the service base URLs? **ONC Response**: The API Maintenance of Certification requirement at § 170.404(b)(2) requires a Certified API Developer to publish the service base URLs for all Health IT Modules certified to § 170.315(g)(10) that can be used by patients to access their electronic health information. This includes publishing the service base URLs for all of its customers regardless of whether the Health IT Modules certified to § 170.315(g)(10) are centrally managed by the Certified API Developer or locally deployed by an API Information Source. @@ -52,7 +52,7 @@ ONC provides discussion regarding Certified API Developer publication of service The ONC Cures Act Final Rule at 85 FR 25813 provides an example which discusses API Information Sources providing Certified API Developers service base URLs in the context of Information Blocking. ## Paragraph (b)(3): Rollout of (g)(10)-Certified APIs -### Pre 2023 +### 2022 Inquiries **Stakeholder Inquiry**: According to the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule (ONC Cures Act Final Rule) timeline, ONC Cures Update Certification Criteria must be made available by 12/31/2022. Can you clarify what "made available" means? **ONC Response**: The API Maintenance of Certification requirement at 45 CFR 170.404(b)(3) requires that a Certified API Developer with certified API technology previously certified to the certification criterion in § 170.315(g)(8) must deploy to all of their API Information Sources (e.g., customers) API technology certified to the criterion in § 170.315(g)(10) no later than December 31, 2022. @@ -63,7 +63,8 @@ Additional context and background discussion of this Maintenance of Certificatio We encourage all Certified Health IT Developers to work with their ONC-ACBs and customers to develop a certification and roll-out strategy to meet ONC Health IT Certification Program requirements by the required regulatory deadlines. -### Older (Pre 2023) +*** + **Stakeholder Inquiry**: If an EHR system that is currently certified to (g)(7)-(g)(9) is unable to get certified to (g)(10) by January 1, 2023, what is the outcome with respect to their certification? - If they then certify to (g)(10) at some point in CY 2023 how is their CHPL entry effected? @@ -94,8 +95,7 @@ If a health IT developer currently has Health IT Modules certified to 45 CFR 170 We encourage health IT developers to work with their ONC-ACB and customers to develop a certification and roll-out strategy to meet ONC Health IT Certification Program requirements by the required regulatory deadlines. -*** - +### 2021 Inquiries **Stakeholder Inquiry**: Do all products have to be HL7® FHIR capable by Dec 31, 2022, or just the certified products? **ONC Response**: The API compliance requirement for certified products is contained in 45 CFR 170.404: API Conditions and Maintenance of Certification requirements. According to 170.404(b)(3): diff --git a/docs/inquiry-portal/g10-inquiries.md b/docs/inquiry-portal/g10-inquiries.md index d8c59c5..c368b50 100644 --- a/docs/inquiry-portal/g10-inquiries.md +++ b/docs/inquiry-portal/g10-inquiries.md @@ -7,7 +7,7 @@ This section contains anonymized feedback and inquiries, related to the standard The date headers provide important context as some information may have changed since the time of an inquiry and response. ## Applies to Entire Criterion -### July 2023 +### July 2023 Inquiries **Stakeholder Inquiry**: We have been working to adopt the HL7 FHIR standard for all our external API communications. We were wondering if you can provide answers or linked resources to the following questions: - My understanding of the 21st Century Cures Act, as it pertains to data interoperability via HL7 FHIR, is that it requires Health Insurance Plans (and other health related orgs) to have HL7 FHIR APIs by end of year 2023. Is this correct? @@ -23,9 +23,7 @@ We note that these regulations do not require that impacted payers use health IT Regarding the 2023 date mentioned, you may be referring to the Promoting Interoperability (PI) Programs (previously Medicare and Medicaid EHR Incentive Programs) administered by the Centers for Medicare & Medicaid Services (CMS) which focus on adoption and use of certified health IT by eligible hospitals, critical access hospitals, and eligible clinicians. This program does include requirements that the health care providers who participate in the program use certified health IT incorporating FHIR APIs during 2023. For more information about the PI program for eligible hospitals and CAHs, see https://www.cms.gov/regulations-and-guidance/legislation/ehrincentiveprograms. For more information about the Promoting Interoperability performance category of MIPS that pertains to eligible clinicians, see https://qpp.cms.gov/. -*** - -### April 2023 +### April 2023 Inquiries **Stakeholder Inquiry**: Can a 3rd party app developer approach a Certified Health IT Developer for implementing a FHIR API without any reference from a Clinic/Provider/Patient? There should be consent from provider/clinic, or patient to share the info, right? **ONC Response**: A § 170.315(g)(10)-certified Health IT Module must support the capability to enable an application to register with the Health IT Module's “authorization server”, as per the requirement at § 170.315(g)(10)(iii). This requirement only applies for the purposes of demonstrating technical conformance to the certification criterion and Condition and Maintenance of Certification requirements. The practices by all parties (including implementers of Health IT Modules) other than developers of certified Health IT Modules are not in scope for the § 170.315(g)(10) criterion nor the associated Condition and Maintenance of Certification requirements. @@ -50,9 +48,7 @@ For an overview of key elements of the HIPPA Privacy Rule including who is cover The Office for Civil Rights (OCR) enforces the HIPAA Privacy, Security, and Breach Notification Rules. For questions related to Health Information Privacy, please email OCRPrivacy@hhs.gov. -*** - -### January 2023 +### January 2023 Inquiries **Stakeholder Inquiry**: We have a question about this text in the US Core Server CapabilityStatement: !!! note "" @@ -70,9 +66,7 @@ Please see the ONC Certification (g)(10) Standardized API Test Kit implements tests according to the § 170.315(g)(10) Test Procedure. This Test Procedure defines tests to verify conformance to § 170.315(g)(10) requirements to support US Core profiles (or FHIR core profiles if no corresponding US Core profile exists) for each of the data in USCDI. Therefore, the Inferno ONC Certification (g)(10) Standardized API Test Kit includes tests for US Core profiles beyond the US Core Patient profile. -*** - -### Older (Pre 2023) +### 2022 Inquiries **Stakeholder Inquiry**: We have some questions regarding the consent requirements for § 170.315(g)(10) Standardized API for patient and population services. - If a patient is accessing data, are providers required to obtain a separate consent from the patient? @@ -120,8 +114,7 @@ A developer must present its own health IT for certification, and may also use In the provided example, the health IT developer could use "relied upon software" in the form of an authorization server to fulfill authentication and authorization requirements in the § 170.315(g)(10) "Standardized API for patient and population services" criterion. However, a Health IT Module cannot be certified to the § 170.315(g)(10) "Standardized API for patient and population services" criterion without fulfilling all of its specified requirements, including authentication and authorization requirements. For more information about "relied upon software", please see the Relied Upon Software Program Guidance document. -*** - +### 2021 Inquiries **Stakeholder Inquiry**: If we certify to 170.315(g)(10), does that cover all of the API requirements specified in this PDF? https://www.healthit.gov/cures/sites/default/files/cures/2020-03/APICertificationCriterion.pdf Are there any other criteria in that PDF not covered in the (g)(10) criterion? @@ -156,10 +149,8 @@ Any missing information made available via the (g)(10) standardized API should b The ONC Certification criteria for eCQMs does not require any FHIR standards. For additional information on CMS regulations, please reference CMS sources or contact CMS if you have questions about specific requirements. The CMS.gov website is a great place to start for information about the requirements of any particular CMS program that may be of interest to health care providers and those who support them with health IT solutions. For one example, the Quality Payment Program overview page (https://qpp.cms.gov/about/qpp-overview) offers links to educational resources and information how to contact CMS. Similarly, the CMS.gov Promoting Interoperability Programs page (https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms) currently indicates that Medicare and dually eligible hospitals participating in the Medicare and Medicaid Promoting Interoperability Programs may contact the QualityNet help desk for assistance. -*** - ## Paragraph (g)(10)(i)(A): Data Response (Single Patient) -### Pre 2023 +### 2022 Inquiries **Stakeholder Inquiry**: Two FHIR® DocumentReference resource related questions: 1. The Inferno (g)(10) Standardized API Test Kit test 4.31.01 requires a system under test to demonstrate support for the Discharge Summary note type (18842-5). Are ambulatory vendors expected to demonstrate support for this note type for the purposes of (g)(10) certification? @@ -176,8 +167,7 @@ The ONC Certification criteria for eCQMs does not require any FHIR standards. Fo **ONC Response**: The § 170.315(g)(10) "Standardized API for patient and population services" certification criterion does not require support for the US Core $docref operation. -*** - +### 2021 Inquiries **Stakeholder Inquiry**: US Core 3.1.1 requires Procedure.performed. For (g)(10) certification how are we expected to accommodate cancelled or not done procedures where a date or period does not exist? **ONC Response**: Health IT modules certified to the Standardized API for patient and population services (45 CFR 170.315(g)(10)) must "Respond to requests for a single patient’s data according to the standard adopted in § 170.215(a)(1) and implementation specification adopted in § 170.215(a)(2), including the mandatory capabilities described in “US Core Server CapabilityStatement,” for each of the data included in the standard adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported." @@ -212,10 +202,8 @@ However, for purposes of testing and certification for the ONC Health IT Certifi We will issue a clarification on the § 170.315(g)(10) Standardized API for patient and population services Certification Companion Guide regarding this issue, and the Inferno testing tool will be updated in the next regular release, which occurs at least monthly, to accommodate this clarification. -*** - ## Paragraph (g)(10)(i)(B): Data Response (Multiple Patients) -### Pre 2023 +### 2022 Inquiries **Stakeholder Inquiry**: We are working on the Multi-Patient API Certification requirements, what are the requirements around group ids? **ONC Response**: The § 170.315(g)(10) "Standardized API for patient and population services" certification criterion requires the Health IT Module support requests for multiple patients’ data as a group using the “group-export” operation as detailed in the Bulk Data Access implementation guide. The `group-export` operation allows authorized clients to obtain FHIR resources pertaining to all patients in a specified Group. The client uses the Group ID to specify which Group is to be exported. @@ -250,8 +238,7 @@ As specified in Bulk Data Access 1.0.1 Inferno testing tool ONC Health IT Certification Program tests for § 170.315(g)(10) will be updated to accommodate this change in the coming weeks. -*** - ## Paragraph (g)(10)(iv): Secure Connection -### Pre 2023 +### 2022 Inquiries **Stakeholder Inquiry**: We are failing the Inferno (g)(10) Standardized API Test Kit test “5.3.01 Bulk Data Server is secured by transport layer security Server did not permit/deny the connections with the correct TLS versions.” Our implementation enforces TLS connections at the application layer and not the network layer. Is this allowable for certification to (g)(10)? **ONC Response**: ONC has issued the following clarification in the § 170.315(g)(10) "Standardized API for patient and population services" Certification Companion Guide regarding the requirements at § 170.315(g)(10)(iv) “Secure connection”. @@ -292,10 +275,8 @@ The information blocking regulations or requirements for successful participation in CMS programs such as the Promoting Interoperability Program. -*** - -### Older (Pre 2023) +### 2022 Inquiries **Stakeholder Inquiry**: Can you provide some more clarification on what is required in (g)(10)(v)(A)(1) where systems are expected to support refresh tokens for “no less than 3 months.” **ONC Response**: The § 170.315(g)(10) "Standardized API for patient and population services" certification criterion includes requirements for first time connections at § 170.315(g)(10)(v)(A)(1) that a Health IT Module’s authorization server must issue a refresh token valid for a period of no less than three months to applications capable of storing a client secret and native applications capable of securing a refresh token. A requirement for subsequent connections is also included under § 170.315(g)(10)(v)(A)(2) that a Health IT Module’s authorization server must issue a refresh token valid for a new period of no less than three months to applications capable of storing a client secret. These refresh token requirements are intended to enable a patient's persistent access to their electronic health information without special effort. In fulfillment of the aforementioned § 170.315(g)(10) requirements, health IT developers are not prohibited from allowing patients to express their persistent access preferences and from configuring the duration of persistent access according to patient preferences. When patients are presented with options for the duration of persistent access, an option of at least three months must be included. -*** - +### 2021 Inquiries **Stakeholder Inquiry**: What is a permissible method of allowing patients to authorize access to individual FHIR resources, and if this means that the FHIR server must be able to support requests from client applications for one to all USCDI resources; or if it means the FHIR server must allow the user at the time of authorization to pick/choose which resources are granted access? Client applications are often designed to request access for their full list and then be granted/denied for the full list and don’t necessarily support this individual selection option at the authorization level. Meaning, they say they need all requested items, and the user can accept that or deny it. @@ -347,10 +325,8 @@ and for subsequent connections: - A Health IT Module’s authorization server must issue a refresh token valid for a new period of no less than three months to applications capable of storing a client secret. Beyond the certification criteria requirements, health IT developers are not required to support all methods that third-party application developers seek to use. Additional information and clarifications regarding this criterion can be found on the Certification Companion Guide for § 170.315(g)(10). -*** - ## Paragraph (g)(10)(v)(B): Authentication / Authorization for Multiple Patient Services -### Pre 2023 +### 2021 Inquiries **Stakeholder Inquiry**: There is a requirement that clients downloading the bulk data use the same access token as they did to make the original request. Does it permit other equivalently secure means of authorization as well? The FHIR specification says that there should be alternatives: https://hl7.org/fhir/uv/bulkdata/export/index.html#response---complete-status @@ -367,20 +343,16 @@ According to the requirements in § 170.315(g)(10)(v)(B), Health IT Modules must At a minimum for the ONC Health IT Certification Program, Health IT Modules certified to the § 170.315(g)(10) criterion must support the issuance of a valid access token to an application during authentication and authorization as per the “SMART Backend Services: Authorization Guide” section of the Bulk FHIR IG. However, if the minimum requirements are met, health IT developers may support additional access-control schemes beyond OAuth 2.0 bearer tokens. -*** - ## Paragraph (g)(10)(vi): Patient Auhtorization Revocation -### Pre 2023 +### 2021 Inquiries **Stakeholder Inquiry**: To satisfy the “Patient authorization revocation” requirements can short-lived access tokens be allowed to expire in lieu of immediate access token revocation? **ONC Response**: The § 170.315(g)(10) "Standardized API for patient and population services" Certification Companion Guide will be updated with the following clarification: *For authorization revocation, Health IT Modules presented for certification are permitted to allow short-lived access tokens to expire in lieu of immediate access token revocation. ONC recommends health IT developers limit the lifetime of access tokens to one hour or less as recommended in the standard adopted at § 170.215(a)(3), HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0. For purposes of testing and certification, Health IT Modules will be tested for patient authorization revocation occurring within one hour of the request.* -*** - ## Inferno -### Pre 2023 +### 2022 Inquiries **Stakeholder Inquiry**: In Inferno test 4.2.04 (and others) patient data is included in the URL of the HTTP GET request. Is this a Privacy and Security concern? **Stakeholder Inquiry**: The Inferno testing tool acts as a demanding client to test the conformance of servers to health IT standards. In particular, the ONC Certification (g)(10) Standardized API Test Kit, which uses Inferno, tests a health IT developer's APIs' conformance to the requirements of the § 170.315(g)(10) "Standardized API for patient and population services" certification criterion. The Inferno implementation provided by ONC on healthit.gov includes a banner indicating it is for demonstration purposes only and must not be used to access sensitive data or Protected Health Information (PHI). @@ -427,8 +399,7 @@ The "EHR Practitioner App" tests in Inferno require the Health IT Module demonst Additional detail regarding the "EHR Practitioner App" tests in Inferno is available in the ONC Certification (g)(10) Matrix provided with each Inferno release. The ONC Certification (g)(10) Matrix for the current version of Inferno is available via the onc-certification-g10-test-kit repository on GitHub. -*** - +### 2021 Inquiries **Stakeholder Inquiry**: What are the test data requirements for testing to (g)(10) using Inferno? **ONC Response**: The Inferno (g)(10) Standardized API Test Kit does not currently require a specific set of data to be entered into the system under test prior to testing. Instead, it leverages HL7 FHIR's built-in conformance rules to ensure that data returned is valid, conforms to required profiles, and contains all elements that must be supported. This allows systems to use either their own sample data or supplied sample data. From 14e693c7fc666c9d8f1dc46180a75bb48991b0ea Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Fri, 22 Mar 2024 15:21:09 -0400 Subject: [PATCH 20/25] line breaks --- docs/inquiry-portal/404-inquiries.md | 8 ++++++++ docs/inquiry-portal/g10-inquiries.md | 30 ++++++++++++++++++++++++++++ 2 files changed, 38 insertions(+) diff --git a/docs/inquiry-portal/404-inquiries.md b/docs/inquiry-portal/404-inquiries.md index 8fc19a9..c20c46f 100644 --- a/docs/inquiry-portal/404-inquiries.md +++ b/docs/inquiry-portal/404-inquiries.md @@ -26,6 +26,8 @@ We are not able to provide individualized advice on whether a specific fact patt Anyone who believes they may have experienced or observed information blocking by any health care provider, health IT developer of Certified Health IT, or health information network or health information exchange is encouraged to share their concerns with us through the Information Blocking Portal on ONC’s website, HealthIT.gov. +*** + ## Paragraph (b)(2): Service base URL publiciation ### June 2023 Inquiries **Stakeholder Inquiry**: I have questions about the regulatory text in the ONC Cures Act Final Rule found here: https://www.federalregister.gov/d/2020-07419/p-1405. @@ -42,6 +44,8 @@ To be open and transparent to the public, developers must provide a hyperlink to There are no exceptions to the requirement that Certified API Developers must publish service base URLs for all Health IT Modules certified to § 170.315(g)(10) that can be used by patients to access their EHI. +*** + ### 2022 Inquiries **Stakeholder Inquiry**: If an EHR vendor chooses to obtain and integrate a 3rd party solution that is certified to 170.315(g)(10), who is responsible for publish the service base URLs? @@ -51,6 +55,8 @@ ONC provides discussion regarding Certified API Developer publication of service The ONC Cures Act Final Rule at 85 FR 25813 provides an example which discusses API Information Sources providing Certified API Developers service base URLs in the context of Information Blocking. +*** + ## Paragraph (b)(3): Rollout of (g)(10)-Certified APIs ### 2022 Inquiries **Stakeholder Inquiry**: According to the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule (ONC Cures Act Final Rule) timeline, ONC Cures Update Certification Criteria must be made available by 12/31/2022. Can you clarify what "made available" means? @@ -95,6 +101,8 @@ If a health IT developer currently has Health IT Modules certified to 45 CFR 170 We encourage health IT developers to work with their ONC-ACB and customers to develop a certification and roll-out strategy to meet ONC Health IT Certification Program requirements by the required regulatory deadlines. +*** + ### 2021 Inquiries **Stakeholder Inquiry**: Do all products have to be HL7® FHIR capable by Dec 31, 2022, or just the certified products? diff --git a/docs/inquiry-portal/g10-inquiries.md b/docs/inquiry-portal/g10-inquiries.md index c368b50..4ff8657 100644 --- a/docs/inquiry-portal/g10-inquiries.md +++ b/docs/inquiry-portal/g10-inquiries.md @@ -23,6 +23,8 @@ We note that these regulations do not require that impacted payers use health IT Regarding the 2023 date mentioned, you may be referring to the Promoting Interoperability (PI) Programs (previously Medicare and Medicaid EHR Incentive Programs) administered by the Centers for Medicare & Medicaid Services (CMS) which focus on adoption and use of certified health IT by eligible hospitals, critical access hospitals, and eligible clinicians. This program does include requirements that the health care providers who participate in the program use certified health IT incorporating FHIR APIs during 2023. For more information about the PI program for eligible hospitals and CAHs, see https://www.cms.gov/regulations-and-guidance/legislation/ehrincentiveprograms. For more information about the Promoting Interoperability performance category of MIPS that pertains to eligible clinicians, see https://qpp.cms.gov/. +*** + ### April 2023 Inquiries **Stakeholder Inquiry**: Can a 3rd party app developer approach a Certified Health IT Developer for implementing a FHIR API without any reference from a Clinic/Provider/Patient? There should be consent from provider/clinic, or patient to share the info, right? @@ -48,6 +50,8 @@ For an overview of key elements of the HIPPA Privacy Rule including who is cover The Office for Civil Rights (OCR) enforces the HIPAA Privacy, Security, and Breach Notification Rules. For questions related to Health Information Privacy, please email OCRPrivacy@hhs.gov. +*** + ### January 2023 Inquiries **Stakeholder Inquiry**: We have a question about this text in the US Core Server CapabilityStatement: !!! note "" @@ -66,6 +70,8 @@ Please see the ONC Certification (g)(10) Standardized API Test Kit implements tests according to the § 170.315(g)(10) Test Procedure. This Test Procedure defines tests to verify conformance to § 170.315(g)(10) requirements to support US Core profiles (or FHIR core profiles if no corresponding US Core profile exists) for each of the data in USCDI. Therefore, the Inferno ONC Certification (g)(10) Standardized API Test Kit includes tests for US Core profiles beyond the US Core Patient profile. +*** + ### 2022 Inquiries **Stakeholder Inquiry**: We have some questions regarding the consent requirements for § 170.315(g)(10) Standardized API for patient and population services. @@ -114,6 +120,8 @@ A developer must present its own health IT for certification, and may also use In the provided example, the health IT developer could use "relied upon software" in the form of an authorization server to fulfill authentication and authorization requirements in the § 170.315(g)(10) "Standardized API for patient and population services" criterion. However, a Health IT Module cannot be certified to the § 170.315(g)(10) "Standardized API for patient and population services" criterion without fulfilling all of its specified requirements, including authentication and authorization requirements. For more information about "relied upon software", please see the Relied Upon Software Program Guidance document. +*** + ### 2021 Inquiries **Stakeholder Inquiry**: If we certify to 170.315(g)(10), does that cover all of the API requirements specified in this PDF? https://www.healthit.gov/cures/sites/default/files/cures/2020-03/APICertificationCriterion.pdf @@ -167,6 +175,8 @@ The ONC Certification criteria for eCQMs does not require any FHIR standards. Fo **ONC Response**: The § 170.315(g)(10) "Standardized API for patient and population services" certification criterion does not require support for the US Core $docref operation. +*** + ### 2021 Inquiries **Stakeholder Inquiry**: US Core 3.1.1 requires Procedure.performed. For (g)(10) certification how are we expected to accommodate cancelled or not done procedures where a date or period does not exist? @@ -238,6 +248,8 @@ As specified in Bulk Data Access 1.0.1 Inferno testing tool ONC Health IT Certification Program tests for § 170.315(g)(10) will be updated to accommodate this change in the coming weeks. +*** + ## Paragraph (g)(10)(iv): Secure Connection ### 2022 Inquiries **Stakeholder Inquiry**: We are failing the Inferno (g)(10) Standardized API Test Kit test “5.3.01 Bulk Data Server is secured by transport layer security Server did not permit/deny the connections with the correct TLS versions.” Our implementation enforces TLS connections at the application layer and not the network layer. Is this allowable for certification to (g)(10)? @@ -275,6 +291,8 @@ The information blocking regulations or requirements for successful participation in CMS programs such as the Promoting Interoperability Program. +*** + ### 2022 Inquiries **Stakeholder Inquiry**: Can you provide some more clarification on what is required in (g)(10)(v)(A)(1) where systems are expected to support refresh tokens for “no less than 3 months.” @@ -292,6 +312,8 @@ Please note that the information above is specific and limited in scope to the r In fulfillment of the aforementioned § 170.315(g)(10) requirements, health IT developers are not prohibited from allowing patients to express their persistent access preferences and from configuring the duration of persistent access according to patient preferences. When patients are presented with options for the duration of persistent access, an option of at least three months must be included. +*** + ### 2021 Inquiries **Stakeholder Inquiry**: What is a permissible method of allowing patients to authorize access to individual FHIR resources, and if this means that the FHIR server must be able to support requests from client applications for one to all USCDI resources; or if it means the FHIR server must allow the user at the time of authorization to pick/choose which resources are granted access? @@ -325,6 +347,8 @@ and for subsequent connections: - A Health IT Module’s authorization server must issue a refresh token valid for a new period of no less than three months to applications capable of storing a client secret. Beyond the certification criteria requirements, health IT developers are not required to support all methods that third-party application developers seek to use. Additional information and clarifications regarding this criterion can be found on the Certification Companion Guide for § 170.315(g)(10). +*** + ## Paragraph (g)(10)(v)(B): Authentication / Authorization for Multiple Patient Services ### 2021 Inquiries **Stakeholder Inquiry**: There is a requirement that clients downloading the bulk data use the same access token as they did to make the original request. Does it permit other equivalently secure means of authorization as well? @@ -343,6 +367,8 @@ According to the requirements in § 170.315(g)(10)(v)(B), Health IT Modules must At a minimum for the ONC Health IT Certification Program, Health IT Modules certified to the § 170.315(g)(10) criterion must support the issuance of a valid access token to an application during authentication and authorization as per the “SMART Backend Services: Authorization Guide” section of the Bulk FHIR IG. However, if the minimum requirements are met, health IT developers may support additional access-control schemes beyond OAuth 2.0 bearer tokens. +*** + ## Paragraph (g)(10)(vi): Patient Auhtorization Revocation ### 2021 Inquiries **Stakeholder Inquiry**: To satisfy the “Patient authorization revocation” requirements can short-lived access tokens be allowed to expire in lieu of immediate access token revocation? @@ -351,6 +377,8 @@ At a minimum for the ONC Health IT Certification Program, Health IT Modules cert *For authorization revocation, Health IT Modules presented for certification are permitted to allow short-lived access tokens to expire in lieu of immediate access token revocation. ONC recommends health IT developers limit the lifetime of access tokens to one hour or less as recommended in the standard adopted at § 170.215(a)(3), HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0. For purposes of testing and certification, Health IT Modules will be tested for patient authorization revocation occurring within one hour of the request.* +*** + ## Inferno ### 2022 Inquiries **Stakeholder Inquiry**: In Inferno test 4.2.04 (and others) patient data is included in the URL of the HTTP GET request. Is this a Privacy and Security concern? @@ -399,6 +427,8 @@ The "EHR Practitioner App" tests in Inferno require the Health IT Module demonst Additional detail regarding the "EHR Practitioner App" tests in Inferno is available in the ONC Certification (g)(10) Matrix provided with each Inferno release. The ONC Certification (g)(10) Matrix for the current version of Inferno is available via the onc-certification-g10-test-kit repository on GitHub. +*** + ### 2021 Inquiries **Stakeholder Inquiry**: What are the test data requirements for testing to (g)(10) using Inferno? From af3dfb61792db0f2cf3d0d88374f42d28e866331 Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Fri, 22 Mar 2024 15:25:46 -0400 Subject: [PATCH 21/25] remove SVAP reference since now in HTI-1 --- docs/helpful-links.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/helpful-links.md b/docs/helpful-links.md index 8eaedad..4ac48f3 100644 --- a/docs/helpful-links.md +++ b/docs/helpful-links.md @@ -61,7 +61,6 @@ - United States Core Data for Interoperability (USCDI), Version 3, October 2022 Errata - HL7® FHIR® US Core Implementation Guide STU 4.0.0, June 2021 - - HL7® FHIR® US Core Implementation Guide STU 6.1.0, June 30, 2023 - HL7® FHIR® Bulk Data Access (Flat FHIR®) (v2.0.0: STU 2), November 26, 2021 --8<-- "includes/abbreviations.md" From 51ea527128514468076b9754314f1bd324acdcbf Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Fri, 22 Mar 2024 15:26:51 -0400 Subject: [PATCH 22/25] consistent smart language --- docs/helpful-links.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/helpful-links.md b/docs/helpful-links.md index 4ac48f3..e33e467 100644 --- a/docs/helpful-links.md +++ b/docs/helpful-links.md @@ -53,7 +53,7 @@ - § 170.215(b)(1)(i): HL7® FHIR® US Core Implementation Guide STU 3.1.1. The adoption of this standard expires on January 1, 2026. - § 170.215(b)(1)(ii): HL7® FHIR® US Core Implementation Guide STU 6.1.0 - § 170.215(c)(1): HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0. The adoption of this standard expires on January 1, 2026. - - § 170.215(c)(2): HL7® SMART Application Launch Framework Implementation Guide Release 2.0.0 + - § 170.215(c)(2): HL7® SMART App Launch Implementation Guide Release 2.0.0 - § 170.215(d)(1): HL7® FHIR® Bulk Data Access (Flat FHIR®) (V1.0.1:STU 1) - § 170.215(e)(1): OpenID Connect Core 1.0 incorporating errata set 1 From 9178dda36c261bd7f4c96273302123be0b79876a Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Fri, 22 Mar 2024 15:27:58 -0400 Subject: [PATCH 23/25] remove since in HTI-1 now --- docs/helpful-links.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/helpful-links.md b/docs/helpful-links.md index e33e467..6c05ce0 100644 --- a/docs/helpful-links.md +++ b/docs/helpful-links.md @@ -59,7 +59,6 @@ **Standards Version Advancement Process (SVAP) Version(s) Approved** - - United States Core Data for Interoperability (USCDI), Version 3, October 2022 Errata - HL7® FHIR® US Core Implementation Guide STU 4.0.0, June 2021 - HL7® FHIR® Bulk Data Access (Flat FHIR®) (v2.0.0: STU 2), November 26, 2021 From 8d846b7782db331bbf338aa0bd4033bb17a09a02 Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Fri, 22 Mar 2024 15:28:48 -0400 Subject: [PATCH 24/25] consistent langauge --- includes/abbreviations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/includes/abbreviations.md b/includes/abbreviations.md index f1b1a70..f5cf471 100644 --- a/includes/abbreviations.md +++ b/includes/abbreviations.md @@ -19,7 +19,7 @@ *[b)(1)(i]: FHIR® US Core Implementation Guide STU V3.1.1 *[b)(1)(ii]: FHIR® US Core Implementation Guide STU V6.1.0 *[c)(1]: HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0 -*[c)(2]: HL7® SMART Application Launch Framework Implementation Guide Release 2.0.0 +*[c)(2]: HL7® SMART App Launch Implementation Guide Release 2.0.0 *[d)(1]: HL7® FHIR® Bulk Data Access (Flat FHIR®) (V1.0.1:STU 1) *[e)(1]: OpenID Connect Core 1.0 incorporating errata set 1 *[170.213]: United States Core Data for Interoperability (USCDI) From 5d13ea9d1d6c39b4f56209fc8f8a85a426b23aa8 Mon Sep 17 00:00:00 2001 From: Keith Carlson Date: Fri, 22 Mar 2024 15:54:56 -0400 Subject: [PATCH 25/25] consistent use of year headers --- docs/inquiry-portal/404-inquiries.md | 2 +- docs/inquiry-portal/g10-inquiries.md | 6 ++---- 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/docs/inquiry-portal/404-inquiries.md b/docs/inquiry-portal/404-inquiries.md index c20c46f..713dbbe 100644 --- a/docs/inquiry-portal/404-inquiries.md +++ b/docs/inquiry-portal/404-inquiries.md @@ -29,7 +29,7 @@ Anyone who believes they may have experienced or observed information blocking b *** ## Paragraph (b)(2): Service base URL publiciation -### June 2023 Inquiries +### 2023 Inquiries **Stakeholder Inquiry**: I have questions about the regulatory text in the ONC Cures Act Final Rule found here: https://www.federalregister.gov/d/2020-07419/p-1405. Should this list be published on CHPL? We see the "place" for the information on CHPL, but we are seeing that many EHRs have very little to no information published and most don't have their customer list. Is this a violation of the requirements? Are there any exceptions to publishing this information? diff --git a/docs/inquiry-portal/g10-inquiries.md b/docs/inquiry-portal/g10-inquiries.md index 4ff8657..d1df4f8 100644 --- a/docs/inquiry-portal/g10-inquiries.md +++ b/docs/inquiry-portal/g10-inquiries.md @@ -7,7 +7,7 @@ This section contains anonymized feedback and inquiries, related to the standard The date headers provide important context as some information may have changed since the time of an inquiry and response. ## Applies to Entire Criterion -### July 2023 Inquiries +### 2023 Inquiries **Stakeholder Inquiry**: We have been working to adopt the HL7 FHIR standard for all our external API communications. We were wondering if you can provide answers or linked resources to the following questions: - My understanding of the 21st Century Cures Act, as it pertains to data interoperability via HL7 FHIR, is that it requires Health Insurance Plans (and other health related orgs) to have HL7 FHIR APIs by end of year 2023. Is this correct? @@ -25,7 +25,6 @@ Regarding the 2023 date mentioned, you may be referring to the Promoting Interop *** -### April 2023 Inquiries **Stakeholder Inquiry**: Can a 3rd party app developer approach a Certified Health IT Developer for implementing a FHIR API without any reference from a Clinic/Provider/Patient? There should be consent from provider/clinic, or patient to share the info, right? **ONC Response**: A § 170.315(g)(10)-certified Health IT Module must support the capability to enable an application to register with the Health IT Module's “authorization server”, as per the requirement at § 170.315(g)(10)(iii). This requirement only applies for the purposes of demonstrating technical conformance to the certification criterion and Condition and Maintenance of Certification requirements. The practices by all parties (including implementers of Health IT Modules) other than developers of certified Health IT Modules are not in scope for the § 170.315(g)(10) criterion nor the associated Condition and Maintenance of Certification requirements. @@ -52,7 +51,6 @@ The Office for Civil Rights (OCR) enforces the HIPAA Privacy, Security, and Brea *** -### January 2023 Inquiries **Stakeholder Inquiry**: We have a question about this text in the US Core Server CapabilityStatement: !!! note "" @@ -294,7 +292,7 @@ The Inferno testing tool will be updated to align with this clarification. Howev *** ## Paragraph (g)(10)(v)(A)(1): First Time Authentication / Authorization for Single Patients -### February 2023 Inquiries +### 2023 Inquiries **Stakeholder Inquiry**: Can ONC please clarify requirements around patient ability to authorize an application to receive their EHI based on FHIR resource level scopes? Is it required that the patient be given the ability to select or deselect individual FHIR resources? We’ve seen examples of other deployed systems not providing the ability for a patient to select or deselect individual FHIR resources. **ONC Response**: As part of the “permission-patient” “SMART on FHIR® Core Capability” in § 170.215(a)(3), Health IT Modules presented for § 170.315(g)(10) testing and certification must include the ability for patients to authorize an application to receive their electronic health information (EHI) based on FHIR® resource-level scopes. Specifically, this means patients would need to have the ability to authorize access to their EHI at the individual FHIR resource level, from one specific FHIR resource (e.g., “Immunization”) up to all FHIR resources necessary to implement the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2).