Merge pull request #76 from onc-healthit/ccg-pull-oct-2024

CCG Pull October 2024

docs/404-conditions-maintenance.md

@@ -180,7 +180,8 @@ To submit questions or comments to ONC please use our <a target = "_blank" href
 	* As discussed in section VIII.C.6.c of the ONC Cures Act Final Rule, API Information Sources who locally manage their Fast Healthcare Interoperability Resources (FHIR®) servers without Certified API Developer assistance cannot refuse to provide to Certified API Developers the FHIR® service base URL(s) that is/are necessary for patients to use to access their EHI. Equally, pursuant to this Maintenance of Certification requirement, they would be required to publish the FHIR® service base URLs they centrally manage on behalf of API Information Sources.
 	* To be open and transparent to the public, developers must provide a hyperlink to the FHIR® Bundle of service base URLs and related organization details to be published with the § 170.315(g)(10)-certified product on the ONC Certified Health IT Product List (CHPL).
 	* Facility level identifiers, for the purposes of certification to these publication requirements, include identifiers such as: a National Provider Identifier (NPI), Clinical Laboratory Improvement Amendments (CLIA) number, CMS Certification Number (CCN), or other health system ID. Support for one of these identifier types is sufficient, meaning Certified API Developers are not, for example, required to publish individual NPIs as a floor for certification. Different identifiers may be used depending on the customers a Certified API Developer has. [see [89 FR 1288](https://www.federalregister.gov/d/2023-28857/p-1183)]
-	* Certified API Developers have the flexibility to consider using “Organization” and “Endpoint” FHIR® resources profiles, such as the profiles in the [User-access Brands and Endpoints](https://hl7.org/fhir/smart-app-launch/2024Jan/brands.html) specification or [Validated Healthcare Directory IG](https://hl7.org/fhir/uv/vhdir/2018Jan/index.html). [see [89 FR 1287](https://www.federalregister.gov/d/2023-28857/p-1176)]
+	* Certified API Developers have the flexibility to consider using “Organization” and “Endpoint” FHIR® resources profiles, such as the profiles in the [User-access Brands and Endpoints](https://hl7.org/fhir/smart-app-launch/STU2.2/brands.html) specification or [Validated Healthcare Directory IG](https://hl7.org/fhir/uv/vhdir/2018Jan/index.html). [see [89 FR 1287](https://www.federalregister.gov/d/2023-28857/p-1176)]
+	* Certified API Developers can utilize the "Organization.partOf" data element in the FHIR "Organization" resource to represent parent/child organization relationships that make up organization hierarchies. A child organization may use the same service base URL (i.e., FHIR endpoint) as its parent organization. For the purposes of Certification Program service base URL publication requirements, it is not required that a child "Organization" resource include an "Organization.endpoint" element if its parent "Organization" resource, referenced through the "Organization.partOf" element, already contains the applicable endpoint information in its own "Organization.endpoint" element.
 	* For the time period between when the HTI-1 final rule is effective and December 31, 2024, Certified API Developers may fulfill their obligations at §170.404(b)(2) by publicly publishing the service base URLs for all customers in a machine-readable format at no charge. [see [89 FR 1287](https://www.federalregister.gov/d/2023-28857/p-1176)]
 
 

docs/g10-criterion.md

@@ -231,7 +231,7 @@ healthcare providers to implement Health IT Modules certified to requirements in
 	* 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).
 	* 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(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.