onc_certification_g10_test_kit 5.4.2 → 6.0.0

data/lib/onc_certification_g10_test_kit/onc_program_procedure.yml

@@ -1,4 +1,4 @@
-procedure:
+ procedure:
   - section: Paragraph (g)(10)(iii) - Application registration
     steps:
       - group: Application Registration
@@ -16,7 +16,7 @@ procedure:
           registration functions to enable authentication and authorization in §
           170.315(g)(10)(v).
         inferno_tests:
-          - 9.10.01
+          - '11.01'
         inferno_supported: 'yes'
         inferno_notes: |
           This requires a visual inspection and attestation because it is not
@@ -36,7 +36,7 @@ procedure:
           registration functions to enable authentication and authorization in §
           170.315(g)(10)(v).
         inferno_tests:
-          - 9.10.02
+          - '11.02'
         inferno_supported: 'yes'
         inferno_notes: |
           This requires a visual inspection and attestation because it is not
@@ -50,7 +50,7 @@ procedure:
           For all transmissions between the Health IT Module and the
           application, the health IT developer demonstrates the use of a secure
           and trusted connection in accordance with the implementation
-          specifications adopted in § 170.215(a)(2) and § 170.215(a)(3),
+          specifications adopted in § 170.215(b)(1) and § 170.215(c),
           including:
           * Using TLS version 1.2 or higher; and
           * Conformance to FHIR® Communications Security requirements.
@@ -58,7 +58,7 @@ procedure:
           For all transmissions between the Health IT Module and the
           application, the tester verifies the use of a secure and trusted
           connection in accordance with the implementation specifications
-          adopted in § 170.215(a)(2) and § 170.215(a)(3), including:
+          adopted in § 170.215(b)(1) and § 170.215(c), including:
           * Using TLS version 1.2 or higher; and
           * Conformance to FHIR® Communications Security requirements.
         inferno_supported: 'yes'
@@ -92,7 +92,19 @@ procedure:
           - 9.8.06
           - 9.9.03
           - 9.9.06
-          - 9.10.15
+          - '11.15'
+          - 9.11.1.2.01
+          - 9.11.1.2.04
+          - 9.12.2.01
+          - 9.12.2.04
+          - 9.13.2.01
+          - 9.13.2.04
+          - 9.14.1.1.2.01
+          - 9.14.1.1.2.04
+          - 9.14.2.1.2.01
+          - 9.14.2.1.2.04
+          - 9.15.2.01
+          - 9.15.2.04
         inferno_notes: |
           Inferno tests that all endpoints provided support at least TLS
           version 1.2, and rejects all requests for TLS version 1.1 or below.
@@ -110,12 +122,12 @@ procedure:
           The health IT developer demonstrates the ability of the Health IT
           Module to support the following for “EHR-Launch,” “Standalone-Launch,”
           and “Both” (“EHR-Launch” and “Standalone-Launch”) as specified in the
-          implementation specification adopted in § 170.215(a)(3).
+          implementation specification adopted in § 170.215(c)(1).
         TLV: |
           The tester verifies the ability of the Health IT Module to support the
           following for “EHR-Launch,” “Standalone-Launch,” and “Both”
           (“EHR-Launch” and “Standalone-Launch”) as specified in the
-          implementation specification adopted in § 170.215(a)(3).
+          implementation specification adopted in § 170.215(c)(1).
         inferno_supported: 'yes'
         inferno_tests:
           - 1.3.01 - 1.3.07
@@ -131,14 +143,14 @@ procedure:
           Health IT Module to initiate a “launch sequence” using the
           “launch-ehr" “SMART on FHIR® Core Capability” SMART EHR Launch mode
           detailed in the implementation specification adopted in §
-          170.215(a)(3), including:
+          170.215(c)(1), including:
           * Launching the registered launch URL of the application; and
           * Passing the parameters: “iss” and “launch”.
         TLV: |
           [EHR-Launch] The tester verifies the ability of the Health IT Module
           to initiate a “launch sequence” using the “launch-ehr" “SMART on FHIR®
           Core Capability” SMART EHR Launch mode detailed in the implementation
-          specification adopted in § 170.215(a)(3), including:
+          specification adopted in § 170.215(c)(1), including:
           * Launching the registered launch URL of the application; and
           * Passing the parameters: “iss” and “launch”.
         inferno_supported: 'yes'
@@ -152,12 +164,12 @@ procedure:
           [Standalone-Launch] The health IT developer demonstrates the ability
           of the Health IT Module to launch using the “launch-standalone" “SMART
           on FHIR® Core Capability” SMART Standalone Launch mode detailed in the
-          implementation specification adopted in § 170.215(a)(3).
+          implementation specification adopted in § 170.215(c)(1).
         TLV: |
           [Standalone-Launch] The tester verifies the ability of the Health IT
           Module to launch using the “launch-standalone" “SMART on FHIR® Core
           Capability” SMART Standalone Launch mode detailed in the
-          implementation specification adopted in § 170.215(a)(3).
+          implementation specification adopted in § 170.215(c)(1).
         inferno_supported: 'yes'
         inferno_tests:
           - 1.3.02
@@ -179,15 +191,15 @@ procedure:
         SUT: |
           [Both] The health IT developer demonstrates the ability of the Health
           IT Module to support the following as detailed in the implementation
-          specification adopted in § 170.215(a)(3) and standard adopted in §
+          specification adopted in § 170.215(c)(1) and standard adopted in §
           170.215(a)(1):
-          * The “.well-known/smart-configuration.json” path; and
+          * The “.well-known/smart-configuration” path; and
           * A FHIR® “CapabilityStatement”.
         TLV: |
           [Both] The tester verifies the ability of the Health IT Module to
           support the following as detailed in the implementation specification
-          adopted in § 170.215(a)(3) and standard adopted in § 170.215(a)(1):
-          * The “.well-known/smart-configuration.json” path; and
+          adopted in § 170.215(c)(1) and standard adopted in § 170.215(a)(1):
+          * The “.well-known/smart-configuration” path; and
           * A FHIR® “CapabilityStatement”.
         inferno_supported: 'yes'
         inferno_tests:
@@ -196,14 +208,14 @@ procedure:
       - id: AUT-PAT-24
         SUT: |
           [Both] The health IT developer demonstrates the ability of the Health
-          IT Module to support a “.well-known/smart-configuration.json” path as
+          IT Module to support a “.well-known/smart-configuration” path as
           detailed in the implementation specification adopted in §
-          170.215(a)(3) and standard adopted in § 170.215(a)(1).
+          170.215(c)(2) and standard adopted in § 170.215(a)(1).
         TLV: |
           [Both] The tester verifies the ability of the Health IT Module to
-          support a “.well-known/smart-configuration.json” path as detailed in
-          the implementation specification adopted in § 170.215(a)(3) and
-          standard adopted in § 170.215(a)(1).
+          support a “.well-known/smart-configuration” path as detailed in the
+          implementation specification adopted in § 170.215(c)(2) and standard
+          adopted in § 170.215(a)(1).
         inferno_supported: 'yes'
         inferno_tests:
           - 1.2.01 - 1.2.03
@@ -211,18 +223,18 @@ procedure:
       - id: AUT-PAT-6
         SUT: |
           [Both] The health IT developer demonstrates the ability of the
-          “.well-known/smart-configuration.json” path to support at least the
+          “.well-known/smart-configuration” path to support at least the
           following as detailed in the implementation specification adopted in §
-          170.215(a)(3):
+          170.215(c)(1):
           * “authorization_endpoint”;
           * “token_endpoint”; and
           * “capabilities” (including support for all the “SMART on FHIR® Core
             Capabilities”).
         TLV: |
           [Both] The tester verifies the ability of the
-          “.well-known/smart-configuration.json” path to support at least the
+          “.well-known/smart-configuration” path to support at least the
           following as detailed in the implementation specification adopted in §
-          170.215(a)(3):
+          170.215(c)(1):
           * “authorization_endpoint”;
           * “token_endpoint”; and
           * “capabilities” (including support for all the “SMART on FHIR® Core
@@ -240,19 +252,18 @@ procedure:
       - id: AUT-PAT-25
         SUT: |
           [Both] The health IT developer demonstrates the ability of the
-          “.well-known/smart-configuration.json” path to support at least the
+          “.well-known/smart-configuration” path to support at least the
           following as detailed in the implementation specification adopted in §
-          170.215(a)(3):
-
+          170.215(c)(2):
           * “authorization_endpoint”;
           * “token_endpoint”;
           * “capabilities” including support for “launch-ehr",
-            “launch-standalone”, “client-public”,
-            “client-confidential-symmetric", “sso-openid-connect",
-            “context-banner”, “context-style”, “context-ehr-patient",
-            “context-standalone-patient", “permission-offline”,
-            “permission-patient”, “permission-user”, “authorize-post”,
-            “permission-v2”;
+            “launch-standalone”, “authorize-post”, “client-public”,
+            “client-confidential-symmetric”, “client-confidential-asymmetric”,
+            “sso-openid-connect", “context-banner”, “context-style”,
+            “context-ehr-patient", “context-standalone-patient",
+            “permission-offline”, “permission-patient”, “permission-user”,
+            “authorize-post”, “permission-v1”, “permission-v2”;
           * “grant_types_supported” with support for “authorization_code” and
             “client_credentials”; and
           * “code_challenge_methods_supported” with support for “S256” and shall
@@ -263,19 +274,18 @@ procedure:
           * "context-ehr-encounter"
         TLV: |
           [Both] The tester verifies the ability of the
-          “.well-known/smart-configuration.json” path to support at least the
+          “.well-known/smart-configuration” path to support at least the
           following as detailed in the implementation specification adopted in §
-          170.215(a)(3):
-
+          170.215(c)(2):
           * “authorization_endpoint”;
           * “token_endpoint”;
           * “capabilities” including support for “launch-ehr",
-            “launch-standalone”, “client-public”,
-            “client-confidential-symmetric", “sso-openid-connect",
-            “context-banner”, “context-style”, “context-ehr-patient",
-            “context-standalone-patient", “permission-offline”,
-            “permission-patient”, “permission-user”, “authorize-post”,
-            “permission-v2”;
+            “launch-standalone”, “authorize-post”, “client-public”,
+            “client-confidential-symmetric", “client-confidential-asymmetric”,
+            “sso-openid-connect", “context-banner”, “context-style”,
+            “context-ehr-patient", “context-standalone-patient",
+            “permission-offline”, “permission-patient”, “permission-user”,
+            “authorize-post”, “permission-v1”, “permission-v2”;
           * “grant_types_supported” with support for “authorization_code” and
             “client_credentials”; and
           * “code_challenge_methods_supported” with support for “S256” and shall
@@ -293,14 +303,14 @@ procedure:
           [Both] The health IT developer demonstrates the ability of the FHIR®
           “CapabilityStatement” to support at least the following components as
           detailed in the implementation specification adopted in §
-          170.215(a)(3) and standard adopted in § 170.215(a)(1), including:
+          170.215(c)(1) and standard adopted in § 170.215(a)(1), including:
           * “authorize”; and
           * “token”.
         TLV: |
           [Both] The tester verifies the ability of the FHIR®
           “CapabilityStatement” to support at least the following components as
           detailed in the implementation specification adopted in §
-          170.215(a)(3) and standard adopted in § 170.215(a)(1), including:
+          170.215(c)(1) and standard adopted in § 170.215(a)(1), including:
           * “authorize”; and
           * “token”.
         inferno_supported: 'yes'
@@ -315,7 +325,7 @@ procedure:
         SUT: |
           [Both] The health IT developer demonstrates the ability of the Health
           IT Module to receive an authorization request according to the
-          implementation specification adopted in § 170.215(a)(3), including
+          implementation specification adopted in § 170.215(c)(1), including
           support for the following parameters:
           * “response_type”;
           * “client_id”;
@@ -327,7 +337,7 @@ procedure:
         TLV: |
           [Both] The tester verifies the ability of the Health IT Module to
           receive an authorization request according to the implementation
-          specification adopted in § 170.215(a)(3), including support for the
+          specification adopted in § 170.215(c)(1), including support for the
           following parameters:
           * “response_type”;
           * “client_id”;
@@ -344,7 +354,7 @@ procedure:
         SUT: |
           [Both] The health IT developer demonstrates the ability of the Health
           IT Module to receive an authorization request according to the
-          implementation specification adopted in § 170.215(a)(3), including
+          implementation specification adopted in § 170.215(c)(2), including
           support for the following parameters:
           * “response_type”;
           * “client_id”;
@@ -358,7 +368,7 @@ procedure:
         TLV: |
           [Both] The tester verifies the ability of the Health IT Module to
           receive an authorization request according to the implementation
-          specification adopted in § 170.215(a)(3), including support for the
+          specification adopted in § 170.215(c)(2), including support for the
           following parameters:
           * “response_type”;
           * “client_id”;
@@ -378,12 +388,12 @@ procedure:
           [Both] The health IT developer demonstrates the ability of the Health
           IT Module’s Authorization Server to support the use of the HTTP GET
           and POST methods at the Authorization Endpoint as detailed in the
-          implementation specification adopted in § 170.215(a)(3).
+          implementation specification adopted in § 170.215(c)(2).
         TLV: |
           [Both] The tester verifies the ability of the Health IT Module’s
           Authorization Server to support the use of the HTTP GET and POST
           methods at the Authorization Endpoint as detailed in the
-          implementation specification adopted in § 170.215(a)(3).
+          implementation specification adopted in § 170.215(c)(2).
         inferno_supported: 'yes'
         inferno_tests:
             - 1.4.05 - 1.4.07
@@ -393,10 +403,10 @@ procedure:
           [Both] The health IT developer demonstrates the ability of the Health
           IT Module to support the receipt of the following scopes and
           capabilities according to the implementation specification adopted in
-          § 170.215(a)(3) and standard adopted in § 170.215(b):
+          § 170.215(c)(1) and standard adopted in § 170.215(e)(1):
           * “openid” (to support “sso-openid-connect” “SMART on FHIR® Core
             Capability”);
-          * “FHIR®User” (to support “sso-openid-connect” “SMART on FHIR® Core
+          * “fhirUser” (to support “sso-openid-connect” “SMART on FHIR® Core
             Capability”);
           * “need_patient_banner” (to support “context-banner” “SMART on FHIR®
             Core Capability” for EHR-Launch mode only);
@@ -414,11 +424,11 @@ procedure:
         TLV: |
           [Both] The tester verifies the ability of the Health IT Module to
           support the receipt of the following scopes according to the
-          implementation specification adopted in § 170.215(a)(3) and standard
-          adopted in § 170.215(b):
+          implementation specification adopted in § 170.215(c)(1) and standard
+          adopted in § 170.215(e)(1):
           * “openid” (to support “sso-openid-connect” “SMART on FHIR® Core
             Capability”);
-          * “FHIR®User” (to support “sso-openid-connect” “SMART on FHIR® Core
+          * “fhirUser” (to support “sso-openid-connect” “SMART on FHIR® Core
             Capability”);
           * “need_patient_banner” (to support “context-banner” “SMART on FHIR®
             Core Capability” for EHR-Launch mode only);
@@ -449,10 +459,10 @@ procedure:
           [Both] The health IT developer demonstrates the ability of the Health
           IT Module to support the receipt of the following scopes and
           capabilities according to the implementation specification adopted in
-          § 170.215(a)(3) and standard adopted in § 170.215(b):
+          § 170.215(c)(2) and standard adopted in § 170.215(e)(1):
           * “openid” (to support “sso-openid-connect” “SMART on FHIR®
             Capability”);
-          * “FHIR®User” (to support “sso-openid-connect” “SMART on FHIR®
+          * “fhirUser” (to support “sso-openid-connect” “SMART on FHIR®
             Capability”);
           * “need_patient_banner” (to support “context-banner” “SMART on FHIR®
             Capability” for EHR-Launch mode only);
@@ -464,19 +474,28 @@ procedure:
           * “offline_access” (to support “permission-offline” “SMART on FHIR®
             Capability”);
           * Patient-level scopes (to support “permission-patient” and “SMART on
-            FHIR® Capability”); and
+            FHIR® Capability”);
           * User-level scopes (to support “permission-user” “SMART on FHIR®
-            Capability”).
-          * SMARTv2 scope syntax for patient-level and user-level scopes (to
-            support “permission-v2” “SMART on FHIR® Capability”)
+            Capability”); and
+          * SMART v1 scope syntax for patient-level and user-level scopes to
+            support the “permission-v1” “SMART on FHIR® Capability”
+          * SMART v2 scope syntax for patient-level and user-level scopes to
+            support the “permission-v2” “SMART on FHIR® Capability”, including
+            support for finer-grained resource constraints using search
+            parameters according to section 3.0.2.3 of the implementation
+            specification at § 170.215(c)(2) for the “category” parameter for
+            the following resources: (1) Condition resource with Condition
+            sub-resources Encounter Diagnosis, Problem List, and Health Concern;
+            and (2) Observation resource with Observation sub-resources Clinical
+            Test, Laboratory, Social History, SDOH, Survey, and Vital Signs
         TLV: |
           [Both] The tester verifies the ability of the Health IT Module to
           support the receipt of the following scopes and capabilities according
-          to the implementation specification adopted in § 170.215(a)(3) and
-          standard adopted in § 170.215(b):
+          to the implementation specification adopted in § 170.215(c)(2) and
+          standard adopted in § 170.215(e)(1):
           * “openid” (to support “sso-openid-connect” “SMART on FHIR®
             Capability”);
-          * “FHIR®User” (to support “sso-openid-connect” “SMART on FHIR®
+          * “fhirUser” (to support “sso-openid-connect” “SMART on FHIR®
             Capability”);
           * “need_patient_banner” (to support “context-banner” “SMART on FHIR®
             Capability” for EHR-Launch mode only);
@@ -488,15 +507,29 @@ procedure:
           * “offline_access” (to support “permission-offline” “SMART on FHIR®
             Capability”);
           * Patient-level scopes (to support “permission-patient” and “SMART on
-            FHIR® Capability”); and
+            FHIR® Capability”);
           * User-level scopes (to support “permission-user” “SMART on FHIR®
-            Capability”).
-          * SMARTv2 scope syntax for patient-level and user-level scopes (to
-            support “permission-v2” “SMART on FHIR® Capability”)
+            Capability”); and
+          * SMART v1 scope syntax for patient-level and user-level scopes to
+            support the “permission-v1” “SMART on FHIR® Capability”
+          * SMART v2 scope syntax for patient-level and user-level scopes to
+            support the “permission-v2” “SMART on FHIR® Capability”, including
+            support for finer-grained resource constraints using search
+            parameters according to section 3.0.2.3 of the implementation
+            specification at § 170.215(c)(2) for the “category” parameter for
+            the following resources: (1) Condition resource with Condition
+            sub-resources Encounter Diagnosis, Problem List, and Health Concern;
+            and (2) Observation resource with Observation sub-resources Clinical
+            Test, Laboratory, Social History, SDOH, Survey, and Vital Signs
         inferno_supported: 'yes'
         inferno_tests:
           - 1.4.02
           - 3.4.04
+          - 9.13.2.02
+          - 9.14.1.1.2.02
+          - 9.14.2.1.2.02
+          - '11.18'
+          - 9.15.2.05
         inferno_notes: |
           This step refers to only the receipt of these scopes, which is covered in
           Inferno in one step in each the EHR and Standalone launch cases.  However,
@@ -511,9 +544,9 @@ procedure:
           input, if applicable (required for patient-facing applications),
           including the ability for the end-user to authorize an application to
           receive EHI based on FHIR® resource-level scopes for all of the FHIR®
-          resources associated with the profiles specified in the standard
-          adopted in § 170.213 and implementation specification adopted in
-          § 170.215(a)(2).
+          resources associated with the profiles specified in a standard adopted
+          in § 170.213 and the corresponding implementation specification
+          adopted in § 170.215(b)(1).
 
           If using US Core 3.1.1, 4.0.0, or 6.1.0 these resources include:
 
@@ -546,8 +579,9 @@ procedure:
           applicable (required for patient-facing applications), including the
           ability for the end-user to authorize an application to receive EHI
           based on FHIR® resource-level scopes for all of the FHIR® resources
-          associated with the profiles specified in the standard adopted in
-          § 170.213 and implementation specification adopted in § 170.215(a)(2).
+          associated with the profiles specified in a standard adopted in
+          § 170.213 and the corresponding implementation specification adopted
+          in § 170.215(b)(1).
 
           If using US Core 3.1.1, 4.0.0, or 6.1.0 these resources include:
 
@@ -620,28 +654,20 @@ procedure:
           - 2.1.05
           - 2.2.02
           - 2.2.05
-          - 1.7.01 - 1.7.20
-          - 2.3.01 - 2.3.19
-        inferno_notes: |
-          Inferno verifies that end-user input is requested by requiring one app
-          launch have complete access to required resources and having one app
-          launch have limited access based on the preferences of the tester.
-          Inferno requests full resource and 'offline_access' access, and the tester
-          is expected to select the correct subset of resources and deny 'offline_access'
-          based on previously selected preferences.
+          - '11.04'
       - id: AUT-PAT-12
         SUT: |
           [Both] The health IT developer demonstrates the ability of the Health
           IT Module to deny an application’s authorization request according to
           a patient’s preferences selected in AUT-PAT-10, and AUT-PAT-11, of
           this section in accordance with the implementation specification
-          adopted in § 170.215(a)(3).
+          adopted in § 170.215(c)(1).
         TLV: |
           [Both] The tester verifies the ability of the Health IT Module to deny
           an application’s authorization request according to a patient’s
           preferences selected in AUT-PAT-10, and AUT-PAT-11, of this section in
           accordance with the implementation specification adopted in §
-          170.215(a)(3).
+          170.215(c)(1).
         inferno_supported: 'yes'
         inferno_tests:
           - 1.3.02
@@ -667,12 +693,12 @@ procedure:
           Health IT Module to establish a patient in context if an application
           requests a clinical scope which is restricted to a single patient as
           detailed in the implementation specification adopted in §
-          170.215(a)(3).
+          170.215(c)(2).
         TLV: |
           [EHR-Launch] The tester verifies the ability of the Health IT Module
           to establish a patient in context if an application requests a
           clinical scope which is restricted to a single patient as detailed in
-          the implementation specification adopted in § 170.215(a)(3).
+          the implementation specification adopted in § 170.215(c)(2).
         inferno_supported: 'yes'
         inferno_tests:
           - 9.9.01 - 9.9.10
@@ -697,7 +723,7 @@ procedure:
           [Both] The health IT developer demonstrates the ability of the Health
           IT Module to grant an application access to EHI by returning an
           authorization code to the application according to the implementation
-          specification adopted in § 170.215(a)(3), including the following
+          specification adopted in § 170.215(c)(1), including the following
           parameters:
           * “code”; and
           * “state”.
@@ -705,7 +731,7 @@ procedure:
           [Both] The tester verifies the ability of the Health IT Module to
           grant an application access to EHI by returning an authorization code
           to the application according to the implementation specification
-          adopted in § 170.215(a)(3), including the following parameters:
+          adopted in § 170.215(c)(1), including the following parameters:
           * “code”; and
           * “state”.
         inferno_supported: 'yes'
@@ -719,25 +745,32 @@ procedure:
           [Both] The health IT developer demonstrates the ability of the Health
           IT Module to receive the following parameters from an application
           according to the implementation specification adopted in §
-          170.215(a)(3):
+          170.215(c)(1):
           * “grant_type”;
           * “code”;
           * “redirect_uri”;
-          * “client_id”; and
-          * Authorization header including “client_id” and “client_secret”.
+          * “client_id” (to support “client-public” “SMART on FHIR®
+            Capability”); and
+          * Authorization header including “client_id” and “client_secret” (to
+            support “client-confidential-symmetric” “SMART on FHIR®
+            Capability”).
         TLV: |
           [Both] The tester verifies the ability of the Health IT Module to
           receive the following parameters from an application according to the
-          implementation specification adopted in § 170.215(a)(3):
+          implementation specification adopted in § 170.215(c)(1):
           * “grant_type”;
           * “code”;
           * “redirect_uri”;
-          * “client_id”; and
-          * Authorization header including “client_id” and “client_secret”.
+          * “client_id” (to support “client-public” “SMART on FHIR®
+            Capability”); and
+          * Authorization header including “client_id” and “client_secret” (to
+            support “client-confidential-symmetric” “SMART on FHIR®
+            Capability”).
         inferno_supported: 'yes'
         inferno_tests:
           - 1.3.05
           - 3.3.07
+          - 9.1.05
         inferno_notes: |
           "client_secret" is only provided in the case of confidential clients.
       - id: AUT-PAT-30
@@ -745,50 +778,59 @@ procedure:
           [Both] The health IT developer demonstrates the ability of the Health
           IT Module to receive the following access token request parameters
           from an application according to the implementation specification
-          adopted in § 170.215(a)(3):
+          adopted in § 170.215(c)(2):
           * “grant_type”;
           * “code”;
           * “redirect_uri”;
           * “code_verifier”;
-          * “client_id”; and
-          * Authorization header including “client_id” and “client_secret”.
+          * “client_id” (to support “client-public” “SMART on FHIR®
+            Capability”);
+          * Authorization header including “client_id” and “client_secret” (to
+            support “client-confidential-symmetric” “SMART on FHIR®
+            Capability”); and
+          * Authentication JSON Web Token (to support
+            “client-confidential-asymmetric” “SMART on FHIR® Capability”)
         TLV: |
           [Both] The tester verifies the ability of the Health IT Module to
           receive the following access token request parameters from an
           application according to the implementation specification adopted in §
-          170.215(a)(3):
+          170.215(c)(2):
           * “grant_type”;
           * “code”;
           * “redirect_uri”;
           * “code_verifier”;
-          * “client_id”; and
-          * Authorization header including “client_id” and “client_secret”.
+          * “client_id” (to support “client-public” “SMART on FHIR®
+            Capability”);
+          * Authorization header including “client_id” and “client_secret” (to
+            support “client-confidential-symmetric” “SMART on FHIR®
+            Capability”); and
+          * Authentication JSON Web Token (to support
+            “client-confidential-asymmetric” “SMART on FHIR® Capability”)
         inferno_supported: 'yes'
         inferno_tests:
-          - 1.3.05
-          - 3.3.07
+          - 1.4.05
+          - 3.4.07
+          - 9.12.2.05
       - id: AUT-PAT-31
         SUT: |
           [Both] The health IT developer demonstrates the ability of the Health
           IT Module to return an error response if an invalid “code_verifier”
           value is supplied with an access token request according to the
-          implementation specification adopted in § 170.215(a)(3).
+          implementation specification adopted in § 170.215(c)(2).
         TLV: |
           [Both] The tester verifies the ability of the Health IT Module to
           return an error response if an invalid “code_verifier” value is
           supplied with an access token request according to the implementation
-          specification adopted in § 170.215(a)(3).
+          specification adopted in § 170.215(c)(2).
         inferno_supported: 'yes'
         inferno_tests:
-          - 1.4.05
-          - 3.4.07
+          - 9.7.01 - 9.7.12
       - id: AUT-PAT-16
         SUT: |
           [Both] The health IT developer demonstrates the ability of the Health
           IT Module to return a JSON object to applications according to the
-          implementation specification adopted in § 170.215(a)(3) and standard
-          adopted in § 170.215(b), including the following:
-
+          implementation specification adopted in § 170.215(c)(1) and standard
+          adopted in § 170.215(e)(1), including the following:
           * “access_token”;
           * “token_type”;
           * “scope”;
@@ -811,9 +853,8 @@ procedure:
         TLV: |
           [Both] The tester verifies the ability of the Health IT Module to
           return a JSON object to applications according to the implementation
-          specification adopted in § 170.215(a)(3) and standard adopted in §
-          170.215(b), including the following:
-
+          specification adopted in § 170.215(c)(1) and standard adopted in §
+          170.215(e)(1), including the following:
           * “access_token”;
           * “token_type”;
           * “scope”;
@@ -835,30 +876,32 @@ procedure:
             Capability”)
         inferno_supported: 'yes'
         inferno_tests:
-          - 1.3.06 - 1.3.07
-          - 1.4.06 - 1.4.07
-          - 3.3.08 - 3.3.09
-          - 3.3.13
-          - 3.4.08 - 3.4.09
-          - 3.4.13
-          - 9.8.08 - 9.8.09
-          - 9.9.08 - 9.9.09
+          - 1.3.06 - 1.3.08
+          - 1.4.06 - 1.4.08
+          - 3.3.08 - 3.3.10
+          - 3.3.16
+          - 3.4.08 - 3.4.10
+          - 3.4.16
+          - 9.8.08 - 9.8.10
+          - 9.9.08 - 9.9.10
+          - 9.12.2.06 - 9.12.2.07
+          - 9.12.2.09
       - id: AUT-PAT-17
         SUT: |
           [Both] The health IT developer demonstrates the ability of the Health
           IT Module to provide an OpenID Connect well-known URI in accordance
-          with the implementation specification adopted in § 170.215(b),
+          with the implementation specification adopted in § 170.215(e)(1),
           including:
           * All required fields populated according to implementation
-            specification adopted in § 170.215(b); and
+            specification adopted in § 170.215(e)(1); and
           * Valid JWKS populated according to implementation specification can
             be retrieved via JWKS URI.
         TLV: |
           [Both] The tester verifies the ability of the Health IT Module to
           provide an OpenID Connect well-known URI in accordance with the
-          implementation specification adopted in § 170.215(b), including:
+          implementation specification adopted in § 170.215(e)(1) , including:
           * All required fields populated according to implementation
-            specification adopted in § 170.215(b); and
+            specification adopted in § 170.215(e)(1); and
           * Valid JWKS populated according to implementation specification can
             be retrieved via JWKS URI.
         inferno_supported: 'yes'
@@ -874,11 +917,11 @@ procedure:
         SUT: |
           [Both] The health IT developer demonstrates the ability of the Health
           IT Module to deny an application’s authorization request in accordance
-          with the implementation specification adopted in § 170.215(a)(3).
+          with the implementation specification adopted in § 170.215(c)(1).
         TLV: |
           [Both] The tester verifies the ability of the Health IT Module to deny
           an application’s authorization request in accordance with the
-          implementation specification adopted in § 170.215(a)(3).
+          implementation specification adopted in § 170.215(c)(1).
         inferno_supported: 'yes'
         inferno_notes: |
           Inferno verifies that the user has the ability to explicitly authorize
@@ -895,34 +938,39 @@ procedure:
         SUT: |
           [Both] The health IT developer demonstrates the ability of the Health
           IT Module to return a “Patient” FHIR® resource that matches the
-          patient context provided in step AUT-PAT-9 of this section according
-          to the implementation specification adopted in § 170.215(a)(2).
+          patient context provided in step AUT-PAT-16 of this section according
+          to an implementation specification adopted in § 170.215(b)(1).
         TLV: |
           [Both] The tester verifies the ability of the Health IT Module to
           return a “Patient” FHIR® resource that matches the patient context
-          provided in step AUT-PAT-9 of this section according to the
-          implementation specification adopted in § 170.215(a)(2).
+          provided in step AUT-PAT-16 of this section according to the
+          implementation specification adopted in § 170.215(b)(1).
         inferno_supported: 'yes'
         inferno_tests:
           - 1.3.10
           - 1.4.10
           - 3.3.12
           - 3.4.12
+          - 9.1.08
+          - 9.2.08
           - 9.8.10
           - 9.9.10
+          - 9.12.2.08
+          - 9.13.2.10
       - id: AUT-PAT-32
         SUT: |
           [EHR-Launch] The following must be supported if using US Core 6.1.0:
-          The health IT developer demonstrates the ability of the Health
-          IT Module to return an “Encounter” FHIR® resource that matches the
-          encounter context provided in step AUT-PAT-9 of this section according
-          to the implementation specification adopted in § 170.215(a)(2).
+          The health IT developer demonstrates the ability of the Health IT
+          Module to return an “Encounter” FHIR® resource that matches the
+          encounter context provided in step AUT-PAT-16 of this section
+          according to an implementation specification adopted in §
+          170.215(b)(1).
         TLV: |
-          [EHR-Launch] The following must be supported if using US Core 6.1.0:
-          The tester verifies the ability of the Health IT Module to
+          AUT-PAT-32: [EHR-Launch] The following must be supported if using US
+          Core 6.1.0: The tester verifies the ability of the Health IT Module to
           return an “Encounter” FHIR® resource that matches the encounter
-          context provided in step AUT-PAT-9 of this section according to the
-          implementation specification adopted in § 170.215(a)(2).
+          context provided in step AUT-PAT-16 of this section according to an
+          implementation specification adopted in § 170.215(b)(1).
         inferno_supported: 'yes'
         inferno_tests:
           - 3.3.16
@@ -931,16 +979,17 @@ procedure:
         SUT: |
           [Both] The health IT developer demonstrates the ability of the Health
           IT Module to grant an access token when a refresh token is supplied
-          according to the implementation specification adopted in §
-          170.215(a)(2).
+          according to an implementation specification adopted in §
+          170.215(b)(1).
         TLV: |
           [Both] The tester verifies the ability of the Health IT Module to
-          grant an access token when a refresh token is supplied according to
-          the implementation specification adopted in § 170.215(a)(2).
+          grant an access token when a refresh token is supplied according to an
+          implementation specification adopted in § 170.215(b)(1).
         inferno_supported: 'yes'
         inferno_tests:
-          - 1.6.03 - 1.6.05
-          - 3.6.05 - 3.6.05
+          - 1.6.01 - 1.6.04
+          - 3.6.01 - 3.6.04
+          - 9.12.3.01 - 9.12.3.04
       - id: AUT-PAT-21
         SUT: |
           [Both] The health IT developer demonstrates the ability of the Health
@@ -953,7 +1002,7 @@ procedure:
           to native applications capable of securing a refresh token.
         inferno_supported: 'yes'
         inferno_tests:
-          - 9.10.13
+          - '11.13'
       - group: 'Subsequent Connections: Authentication and Authorization for Patient and User Scopes'
         id: AUT-PAT-22
         SUT: |
@@ -962,16 +1011,16 @@ procedure:
           than three months without requiring re-authentication and
           re-authorization when a valid refresh token is supplied by the
           application according to the implementation specification adopted in §
-          170.215(a)(3).
+          170.215(c)(1).
         TLV: |
           The tester verifies the ability of the Health IT Module to issue a
           refresh token valid for a new period of no shorter than three months
           without requiring re-authentication and re-authorization when a valid
           refresh token is supplied by the application according to the
-          implementation specification adopted in § 170.215(a)(3).
+          implementation specification adopted in § 170.215(c)(1).
         inferno_supported: 'yes'
         inferno_tests:
-          - 9.10.16
+          - '11.16'
         inferno_notes: |
           Inferno cannot verify the three month token expiration requirement
           automatically during the token refresh tests, but the tester can
@@ -981,15 +1030,16 @@ procedure:
           The health IT developer demonstrates the ability of the Health IT
           Module to return an error response when supplied an invalid refresh
           token as specified in the implementation specification adopted in §
-          170.215(a)(3).
+          170.215(c)(1).
         TLV: |
           The tester verifies the ability of the Health IT Module to return an
           error response when supplied an invalid refresh token as specified in
-          the implementation specification adopted in § 170.215(a)(3).
+          the implementation specification adopted in § 170.215(c)(1).
         inferno_supported: 'yes'
         inferno_tests:
           - 1.6.06
           - 3.6.06
+          - 9.12.3.06
   - section: Paragraph (g)(10)(vi) – Patient authorization revocation
     steps:
       - group: Patient Authorization Revocation
@@ -1014,12 +1064,12 @@ procedure:
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
           Module to support OAuth 2.0 client credentials grant flow in
-          accordance with the implementation specification adopted in §
-          170.215(a)(4).
+          accordance with an implementation specification adopted in §
+          170.215(d).
         TLV: |
           The tester verifies the ability of the Health IT Module to support
-          OAuth 2.0 client credentials grant flow in accordance with the
-          implementation specification adopted in § 170.215(a)(4).
+          OAuth 2.0 client credentials grant flow in accordance with an
+          implementation specification adopted in § 170.215(d).
         inferno_supported: 'yes'
         inferno_tests:
           - 7.1.02 - 7.1.06
@@ -1027,16 +1077,16 @@ procedure:
       - id: AUT-SYS-2
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
-          Module to support the following parameters according to the
-          implementation specification adopted in § 170.215(a)(4):
+          Module to support the following parameters according to an
+          implementation specification adopted in § 170.215(d):
           * “scope”;
           * “grant_type”;
           * “client_assertion_type”; and
           * “client_assertion”.
         TLV: |
           The tester verifies the ability of the Health IT Module to support the
-          following parameters according to the implementation specification
-          adopted in § 170.215(a)(4):
+          following parameters according to an implementation specification
+          adopted in § 170.215(d):
           * “scope”;
           * “grant_type”;
           * “client_assertion_type”; and
@@ -1049,8 +1099,8 @@ procedure:
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
           Module to support the following JSON Web Token (JWT) Headers and
-          Claims according to the implementation specification adopted in §
-          170.215(a)(4):
+          Claims according to an implementation specification adopted in §
+          170.215(d):
           * “alg” header;
           * “kid” header;
           * “typ” header;
@@ -1061,8 +1111,8 @@ procedure:
           * “jti” claim.
         TLV: |
           The tester verifies the ability of the Health IT Module to support the
-          following JSON Web Token (JWT) Headers and Claims according to the
-          implementation specification adopted in § 170.215(a)(4):
+          following JSON Web Token (JWT) Headers and Claims according to an
+          implementation specification adopted in § 170.215(d):
           * “alg” header;
           * “kid” header;
           * “typ” header;
@@ -1103,17 +1153,17 @@ procedure:
           This test requires the tester to register an attestation from the
           Health IT Module that the "cache-control" header is obeyed.
         inferno_tests:
-          - 9.10.10
+          - '11.10'
       - id: AUT-SYS-6
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
           Module to validate an application’s JWT, including its JSON Web
-          Signatures, according to the implementation specification adopted in §
-          170.215(a)(4).
+          Signatures, according to an implementation specification adopted in §
+          170.215(d).
         TLV: |
           The tester verifies the ability of the Health IT Module to validate an
-          application’s JWT, including its JSON Web Signatures, according to the
-          implementation specification adopted in § 170.215(a)(4).
+          application’s JWT, including its JSON Web Signatures, according to an
+          implementation specification adopted in § 170.215(d).
         inferno_supported: 'yes'
         inferno_tests:
           - 7.1.05
@@ -1122,13 +1172,13 @@ procedure:
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
           Module to respond with an “invalid_client” error for errors
-          encountered during the authentication process according to the
-          implementation specification adopted in § 170.215(a)(4).
+          encountered during the authentication process according to an
+          implementation specification adopted in § 170.215(d).
         TLV: |
           The tester verifies the ability of the Health IT Module to respond
           with an “invalid_client” error for errors encountered during the
-          authentication process according to the implementation specification
-          adopted in § 170.215(a)(4).
+          authentication process according to an implementation specification
+          adopted in § 170.215(d).
         inferno_supported: 'yes'
         inferno_tests:
           - 7.1.02 - 7.1.04
@@ -1138,13 +1188,13 @@ procedure:
           The health IT developer demonstrates the ability of the Health IT
           Module to assure the scope granted based on the scope requested by an
           application is no greater than the pre-authorized scope for multiple
-          patients according to the implementation specification adopted in §
-          170.215(a)(4).
+          patients according to an implementation specification adopted in §
+          170.215(d).
         TLV: |
           The tester verifies the ability of the Health IT Module to assure the
           scope granted based on the scope requested by an application is no
           greater than the pre-authorized scope for multiple patients according
-          to the implementation specification adopted in § 170.215(a)(4).
+          to an implementation specification adopted in § 170.215(d).
         inferno_supported: 'yes'
         inferno_notes: |
           There is no requirement for support of a subset of the resources
@@ -1152,21 +1202,21 @@ procedure:
           more than what was pre-authorized.  The Health IT module must
           demonstrate this and register its attestation within Inferno.
         inferno_tests:
-          - 9.10.08
+          - '11.08'
       - id: AUT-SYS-9
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
           Module to issue an access token to an application as a JSON object in
-          accordance with the implementation specification adopted in §
-          170.215(a)(4), including the following property names:
+          accordance with an implementation specification adopted in §
+          170.215(d), including the following property names:
           * “access_token”;
           * “token_type”;
           * “expires_in”; and
           * “scope”.
         TLV: |
           The tester verifies the ability of the Health IT Module to issue an
-          access token to an application as a JSON object in accordance with the
-          implementation specification adopted in § 170.215(a)(4), including the
+          access token to an application as a JSON object in accordance with an
+          implementation specification adopted in § 170.215(d), including the
           following property names:
           * “access_token”;
           * “token_type”;
@@ -1180,12 +1230,11 @@ procedure:
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
           Module to respond to errors using the appropriate error messages as
-          specified in the implementation specification adopted in §
-          170.215(a)(4).
+          specified in an implementation specification adopted in § 170.215(d).
         TLV: |
           The tester verifies the ability of the Health IT Module to respond to
-          errors using the appropriate error messages as specified in the
-          implementation specification adopted in § 170.215(a)(4).
+          errors using the appropriate error messages as specified in an
+          implementation specification adopted in § 170.215(d).
         inferno_supported: 'yes'
         inferno_tests:
           - 7.1.02 - 7.1.04
@@ -1198,17 +1247,16 @@ procedure:
         id: TOK-INTRO-1
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
-          Module to receive and validate a token it has issued.
+          Module to receive and validate a token it has issued in accordance
+          with an implementation specification in § 170.215(c).
         TLV: |
           The tester verifies the ability of the Health IT Module to receive and
-          validate a token it has issued.
+          validate a token it has issued in accordance with an implementation
+          specification in § 170.215(c).
         inferno_supported: 'yes'
-        inferno_notes: |
-          No standard is required and therefore Inferno cannot do this in
-          an automated fashion and this is recorded as an attestation
-          within Inferno.
         inferno_tests:
-          - 9.10.06
+          - 9.11.2.01 - 9.11.2.02
+          - 9.11.3.01 - 9.11.3.02
   - section: Paragraph (g)(10)(ii) – Supported search operations
     steps:
       - group: Supported Search Operations for a Single Patient’s Data
@@ -1218,14 +1266,14 @@ procedure:
           Module to support the “capabilities” interaction as specified in the
           standard adopted in § 170.215(a)(1), including support for a
           “CapabilityStatement” as specified in the standard adopted in §
-          170.215(a)(1) and implementation specification adopted in §
-          170.215(a)(2).
+          170.215(a)(1) and an implementation specification adopted in §
+          170.215(b)(1).
         TLV: |
           The tester verifies the ability of the Health IT Module to support the
           “capabilities” interaction as specified in the standard adopted in §
           170.215(a)(1), including support for a “CapabilityStatement” as
-          specified in the standard adopted in § 170.215(a)(1) and
-          implementation specification adopted in § 170.215(a)(2).
+          specified in the standard adopted in § 170.215(a)(1) and an
+          implementation specification adopted in § 170.215(b)(1).
         inferno_supported: 'yes'
         inferno_tests:
           - 4.1.02 - 4.1.05
@@ -1236,125 +1284,127 @@ procedure:
           The health IT developer demonstrates the ability of the Health IT
           Module to respond to requests for a single patient’s data consistent
           with the search criteria detailed in the “US Core Server
-          CapabilityStatement” section of the implementation specification
-          adopted in § 170.215(a)(2), including demonstrating search support for
+          CapabilityStatement” section of an implementation specification
+          adopted in § 170.215(b)(1), including demonstrating search support for
           “SHALL” operations and parameters for all the data included in the
-          standard adopted in § 170.213.
+          corresponding standard adopted in § 170.213.
         TLV: |
           The tester verifies the ability of the Health IT Module to respond to
           requests for a single patient’s data consistent with the search
           criteria detailed in the “US Core Server CapabilityStatement” section
-          of the implementation specification adopted in § 170.215(a)(2),
+          of an implementation specification adopted in § 170.215(b)(1),
           including demonstrating search support for “SHALL” operations and
-          parameters for all the data included in the standard adopted in §
-          170.213.
+          parameters for all the data included in the corresponding standard
+          adopted in § 170.213.
         inferno_supported: 'yes'
         inferno_tests:
-          - 4.2.01
+          - 4.2.01 - 4.2.03
           - 4.3.01
           - 4.4.01
           - 4.5.01
           - 4.6.01
           - 4.7.01
-          - 4.8.01
-          - 4.9.01
-          - 4.10.01
+          - 4.8.01 - 4.8.04
+          - 4.9.01 - 4.9.04
+          - 4.10.01 - 4.10.05
           - 4.11.01
           - 4.12.01
-          - 4.13.01
+          - 4.13.01 - 4.13.02
           - 4.14.01
-          - 4.15.01
-          - 4.16.01
-          - 4.17.01
-          - 4.18.01
-          - 4.19.01
-          - 4.20.01
-          - 4.21.01
-          - 4.22.01
-          - 4.23.01
-          - 4.24.01
-          - 4.25.01
-          - 4.26.01
-          - 5.2.01
+          - 4.15.01 - 4.15.03
+          - 4.16.01 - 4.16.03
+          - 4.17.01 - 4.17.03
+          - 4.18.01 - 4.18.03
+          - 4.19.01 - 4.19.03
+          - 4.20.01 - 4.20.03
+          - 4.21.01 - 4.21.03
+          - 4.22.01 - 4.22.03
+          - 4.23.01 - 4.23.03
+          - 4.24.01 - 4.24.03
+          - 4.25.01 - 4.25.03
+          - 4.26.01 - 4.26.02
+          - 5.2.01 - 5.2.05
           - 5.3.01
           - 5.4.01
           - 5.5.01
           - 5.6.01
           - 5.7.01
-          - 5.8.01
-          - 5.9.01
-          - 5.10.01
+          - 5.8.01 - 5.8.04
+          - 5.9.01 - 5.9.04
+          - 5.10.01 - 5.10.05
           - 5.11.01
           - 5.12.01
-          - 5.13.01
-          - 5.14.01
-          - 5.15.01
-          - 5.16.01
-          - 5.17.01
-          - 5.18.01
-          - 5.19.01
-          - 5.20.01
-          - 5.21.01
-          - 5.22.01
-          - 5.23.01
-          - 5.24.01
-          - 5.25.01
-          - 5.26.01
-          - 5.27.01
-          - 5.28.01
-          - 10.2.01
+          - 5.13.01 - 5.13.02
+          - 5.14.01 - 5.14.03
+          - 5.15.01 - 5.15.03
+          - 5.16.01 - 5.16.03
+          - 5.17.01 - 5.17.03
+          - 5.18.01 - 5.18.03
+          - 5.19.01 - 5.19.03
+          - 5.20.01 - 5.20.03
+          - 5.21.01 - 5.21.03
+          - 5.22.01 - 5.22.03
+          - 5.23.01 - 5.23.03
+          - 5.24.01 - 5.24.03
+          - 5.25.01 - 5.25.03
+          - 5.26.01 - 5.26.03
+          - 5.27.01 - 5.27.03
+          - 5.28.01 - 5.28.02
+          - 10.2.01 - 10.2.05
           - 10.3.01
           - 10.4.01
           - 10.5.01
-          - 10.6.01
-          - 10.7.01
+          - 10.6.01 - 10.6.02
+          - 10.7.01 - 10.7.02
           - 10.8.01
           - 10.9.01
-          - 10.10.01
-          - 10.11.01
-          - 10.12.01
-          - 10.13.01
+          - 10.10.01 - 10.10.04
+          - 10.11.01 - 10.11.04
+          - 10.12.01 - 10.12.05
+          - 10.13.01 - 10.13.03
           - 10.14.01
           - 10.15.01
           - 10.16.01
-          - 10.17.01
-          - 10.18.01
-          - 10.19.01
-          - 10.20.01
-          - 10.21.01
-          - 10.22.01
-          - 10.23.01
-          - 10.24.01
-          - 10.25.01
-          - 10.26.01
-          - 10.27.01
+          - 10.17.01 - 10.17.02
+          - 10.18.01 - 10.18.03
+          - 10.19.01 - 10.19.03
+          - 10.20.01 - 10.20.03
+          - 10.21.01 - 10.21.03
+          - 10.22.01 - 10.22.03
+          - 10.23.01 - 10.23.03
+          - 10.24.01 - 10.24.03
+          - 10.25.01 - 10.25.03
+          - 10.26.01 - 10.26.03
+          - 10.27.01 - 10.27.03
           - 10.28.01
-          - 10.29.01
-          - 10.30.01
-          - 10.31.01
-          - 10.32.01
-          - 10.33.01
-          - 10.34.01
-          - 10.35.01
-          - 10.36.01
-          - 10.37.01
+          - 10.29.01 - 10.29.03
+          - 10.30.01 - 10.30.03
+          - 10.31.01 - 10.31.03
+          - 10.32.01 - 10.32.03
+          - 10.33.01 - 10.33.03
+          - 10.34.01 - 10.34.03
+          - 10.35.01 - 10.35.03
+          - 10.36.01 - 10.36.03
+          - 10.37.01 - 10.37.03
+          - 10.38.01 - 10.38.02
+          - 10.39.01 - 10.39.05
       - id: SH-PAT-3
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
           Module to support a resource search for the provenance target
           “(_revIncludes: Provenance:target)” for all the FHIR® resources
-          included in the standard adopted in § 170.213 and implementation
-          specification adopted in § 170.215(a)(2) according to the “Basic
-          Provenance Guidance” section of the implementation specification
-          adopted in § 170.215(a)(2).
+          included in a standard adopted in § 170.213 and the corresponding
+          implementation specification adopted in § 170.215(b)(1) according to
+          the “Basic Provenance Guidance” section of an implementation
+          specification adopted in § 170.215(b)(1).
         TLV: |
           The tester verifies the ability of the Health IT Module to support a
           resource search for the provenance target “(_revIncludes:
-          Provenance:target)” for all the FHIR® resources included in the
-          standard adopted in § 170.213 and implementation specification adopted
-          in § 170.215(a)(2) according to the “Basic Provenance Guidance”
-          section of the implementation specification adopted in §
-          170.215(a)(2).
+          Provenance:target)” for all the FHIR® resources included in a standard
+          adopted in § 170.213 and the corresponding implementation
+          specification adopted in § 170.215(b)(1) according to the “Basic
+          Provenance Guidance” section of an implementation specification
+          adopted in § 170.215(b)(1).
         inferno_supported: 'yes'
         inferno_tests:
           - 4.2.07
@@ -1409,42 +1459,44 @@ procedure:
           - 5.26.05
           - 5.27.05
           - 5.28.04
-          - 10.2.01
-          - 10.3.01
-          - 10.4.01
-          - 10.5.01
-          - 10.6.01
-          - 10.7.01
-          - 10.8.01
-          - 10.9.01
-          - 10.10.01
-          - 10.11.01
-          - 10.12.01
-          - 10.13.01
-          - 10.14.01
-          - 10.15.01
-          - 10.16.01
-          - 10.17.01
-          - 10.18.01
-          - 10.19.01
-          - 10.20.01
-          - 10.21.01
-          - 10.22.01
-          - 10.23.01
-          - 10.24.01
-          - 10.25.01
-          - 10.26.01
-          - 10.27.01
-          - 10.28.01
-          - 10.29.01
-          - 10.30.01
-          - 10.31.01
-          - 10.32.01
-          - 10.33.01
-          - 10.34.01
-          - 10.35.01
-          - 10.36.01
-          - 10.37.01
+          - 10.2.07
+          - 10.3.03
+          - 10.4.03
+          - 10.5.03
+          - 10.6.04
+          - 10.7.04
+          - 10.8.03
+          - 10.9.03
+          - 10.10.06
+          - 10.11.06
+          - 10.12.07
+          - 10.13.05
+          - 10.14.03
+          - 10.15.03
+          - 10.16.03
+          - 10.17.04
+          - 10.18.05
+          - 10.19.05
+          - 10.20.05
+          - 10.21.05
+          - 10.22.05
+          - 10.23.05
+          - 10.24.05
+          - 10.25.05
+          - 10.26.05
+          - 10.27.05
+          - 10.28.03
+          - 10.29.05
+          - 10.30.05
+          - 10.31.05
+          - 10.32.05
+          - 10.33.05
+          - 10.34.05
+          - 10.35.05
+          - 10.36.05
+          - 10.37.05
+          - 10.38.04
+          - 10.39.07
       - group: Supported Search Operations for Multiple Patients’ Data
         id: SH-PAT-4
         SUT: |
@@ -1452,14 +1504,14 @@ procedure:
           Module to support the “capabilities” interaction as specified in the
           standard adopted in § 170.215(a)(1), including support for a
           “CapabilityStatement” as specified in the standard adopted in §
-          170.215(a)(1) and implementation specification adopted in §
-          170.215(a)(4).
+          170.215(a)(1) and an implementation specification adopted in §
+          170.215(d).
         TLV: |
           The tester verifies the ability of the Health IT Module to support the
           “capabilities” interaction as specified in the standard adopted in §
           170.215(a)(1), including support for a “CapabilityStatement” as
-          specified in the standard adopted in § 170.215(a)(1) and
-          implementation specification adopted in § 170.215(a)(4).
+          specified in the standard adopted in § 170.215(a)(1) and an
+          implementation specification adopted in § 170.215(d).
         inferno_supported: 'yes'
         inferno_tests:
           - 7.2.02
@@ -1468,13 +1520,13 @@ procedure:
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
           Module to support requests for multiple patients’ data as a group
-          using the “group-export” operation as detailed in the implementation
-          specification adopted in § 170.215(a)(4).
+          using the “group-export” operation as detailed in an implementation
+          specification adopted in § 170.215(d).
         TLV: |
           The tester verifies the ability of the Health IT Module to support
           requests for multiple patients’ data as a group using the
-          “group-export” operation as detailed in the implementation
-          specification adopted in § 170.215(a)(4).
+          “group-export” operation as detailed in an implementation
+          specification adopted in § 170.215(d).
         inferno_supported: 'yes'
         inferno_tests:
           - 7.2.04
@@ -1488,14 +1540,14 @@ procedure:
           steps DAT-PAT-7, and DAT-PAT-8, of this section respectively, the
           health IT developer demonstrates the ability of the Health IT Module
           to respond to requests for data according to the implementation
-          specification adopted in § 170.215(a)(2), including the following
+          specification adopted in § 170.215(b)(1)(i), including the following
           steps.
         TLV: |
           For responses to data for single and multiple patients as described in
           steps DAT-PAT-7, and DAT-PAT-8, of this section respectively, the
           tester verifies the ability of the Health IT Module to respond to
           requests for data according to the implementation specification
-          adopted in § 170.215(a)(2), including the following steps.
+          adopted in § 170.215(b)(1)(i), including the following steps.
         inferno_supported: 'yes'
         inferno_tests:
           - 4.2.06
@@ -1605,6 +1657,7 @@ procedure:
           - 10.42.01
           - 10.43.01
           - 10.44.01
+          - 10.47.01
       - id: DAT-PAT-2
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
@@ -1634,8 +1687,8 @@ procedure:
             DAT-PAT-5, and DAT-PAT-6, of this section.
         inferno_supported: 'yes'
         inferno_tests:
-          - 9.10.07
-          - 9.10.11
+          - '11.07'
+          - '11.11'
           - 4.2.08 - 4.2.09
           - 4.3.04 - 4.3.05
           - 4.4.04 - 4.4.05
@@ -1758,17 +1811,17 @@ procedure:
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
           Module to support a “Provenance” FHIR® resource for all the FHIR®
-          resources included in the standard adopted in § 170.213 and
-          implementation specification adopted in § 170.215(a)(2) according to
-          the “Basic Provenance Guidance” section of the implementation
-          specification adopted in § 170.215(a)(2).
+          resources included in the standard adopted in § 170.213(a) and
+          implementation specification adopted in § 170.215(b)(1)(i) according
+          to the “Basic Provenance Guidance” section of the implementation
+          specification adopted in § 170.215(b)(1)(i).
         TLV: |
           The tester verifies the ability of the Health IT Module to support a
           “Provenance” FHIR® resource for all the FHIR® resources included in
-          the standard adopted in § 170.213 and implementation specification
-          adopted in § 170.215(a)(2) according to the “Basic Provenance
+          the standard adopted in § 170.213(a) and implementation specification
+          adopted in § 170.215(b)(1)(i) according to the “Basic Provenance
           Guidance” section of the implementation specification adopted in §
-          170.215(a)(2).
+          170.215(b)(1)(i).
         inferno_supported: 'yes'
         inferno_tests:
           - 4.2.07
@@ -1873,13 +1926,13 @@ procedure:
           FHIR® resource for each of the “Clinical Notes” and “Diagnostic
           Reports” included in and according to the “Clinical Notes Guidance”
           section of the implementation specification adopted in §
-          170.215(a)(2).
+          170.215(b)(1)(i).
         TLV: |
           The tester verifies the ability of the Health IT Module to support a
           “DocumentReference” and/or “DiagnosticReport” FHIR® resource for each
           of the “Clinical Notes” and “Diagnostic Reports” included in and
           according to the “Clinical Notes Guidance” section of the
-          implementation specification adopted in § 170.215(a)(2).
+          implementation specification adopted in § 170.215(b)(1)(i).
         inferno_supported: 'yes'
         inferno_tests:
           - 4.31.01 - 4.31.02
@@ -1891,13 +1944,13 @@ procedure:
           health IT developer demonstrates the ability of the Health IT Module
           to support a “Medication” FHIR® resource according to the “Medication
           List Guidance” section of the implementation specification adopted in
-          § 170.215(a)(2).
+          § 170.215(b)(1)(i).
         TLV: |
           If supported, and for responses to data for a single patient only, the
           tester verifies the ability of the Health IT Module to support a
           “Medication” FHIR® resource according to the “Medication List
           Guidance” section of the implementation specification adopted in §
-          170.215(a)(2).
+          170.215(b)(1)(i).
         inferno_supported: 'yes'
         inferno_tests:
           - 4.13.06
@@ -1907,14 +1960,14 @@ procedure:
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
           Module to support “Missing Data” according to the implementation
-          specification adopted in § 170. 215(a)(2), including:
+          specification adopted in § 170. 215(b)(1)(i), including:
           * For non-coded data elements; and
           * For coded data elements, including support for the
             “DataAbsentReason” Code System.
         TLV: |
           The tester verifies the ability of the Health IT Module to support
           “Missing Data” according to the implementation specification adopted
-          in § 170. 215(a)(2), including:
+          in § 170. 215(b)(1)(i), including:
           * For non-coded data elements; and
           * For coded data elements, including support for the
             “DataAbsentReason” Code System.
@@ -1929,14 +1982,15 @@ procedure:
           The health IT developer demonstrates the ability of the Health IT
           Module to return all of the data associated with requests for a single
           patient’s data according to the “US Core Server CapabilityStatement”
-          section of the implementation specification adopted in § 170.215(a)(2)
-          for all the data included in the standard adopted in § 170.213.
+          section of the implementation specification adopted in §
+          170.215(b)(1)(i) for all the data included in the standard adopted in
+          § 170.213(a).
         TLV: |
           The tester verifies the ability of the Health IT Module to return all
           of the data associated with requests for a single patient’s data
           according to the “US Core Server CapabilityStatement” section of the
-          implementation specification adopted in § 170.215(a)(2) for all the
-          data included in the standard adopted in § 170.213.
+          implementation specification adopted in § 170.215(b)(1)(i) for all the
+          data included in the standard adopted in § 170.213(a).
         inferno_supported: 'yes'
         inferno_tests:
           - 4.2.01
@@ -2029,20 +2083,15 @@ procedure:
           - 10.37.01
           - 10.38.01
           - 10.39.01
-          - 10.40.01
-          - 10.41.01
-          - 10.42.01
-          - 10.43.01
-          - 10.44.01
       - group: Response to Requests for Multiple Patients’ Data
         id: DAT-PAT-8
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
           Module to respond to requests for multiple patients’ data according to
-          the implementation specification adopted in § 170.215(a)(4) for all of
-          the FHIR® resources associated with the profiles and Data Elements
-          specified in and according to the standard adopted in § 170.213 and
-          implementation specification adopted in § 170.215(a)(2).:
+          an implementation specification adopted in § 170.215(d) for all of the
+          FHIR® resources associated with the profiles and Data Elements
+          specified in and according to the standard adopted in § 170.213(a) and
+          implementation specification adopted in § 170.215(b)(1)(i):
           * “AllergyIntolerance”;
           * “CarePlan”;
           * “CareTeam”;
@@ -2064,11 +2113,11 @@ procedure:
           * “Provenance”.
         TLV: |
           The tester verifies the ability of the Health IT Module to respond to
-          requests for multiple patients’ data according to the implementation
-          specification adopted in § 170.215(a)(4) for all of the FHIR®
-          resources associated with the profiles and Data Elements specified in
-          and according to the standard adopted in § 170.213 and implementation
-          specification adopted in § 170.215(a)(2).
+          requests for multiple patients’ data according to an implementation
+          specification adopted in § 170.215(d) for all of the FHIR® resources
+          associated with the profiles and Data Elements specified in and
+          according to the standard adopted in § 170.213(a) and implementation
+          specification adopted in § 170.215(b)(1)(i):
           * “AllergyIntolerance”;
           * “CarePlan”;
           * “CareTeam”;
@@ -2094,82 +2143,14 @@ procedure:
           - 7.3.06 - 7.3.23
           - 8.3.03
           - 8.3.06 - 8.3.23
-      - id: DAT-PAT-16
-        SUT: |
-          The health IT developer demonstrates the ability of the Health IT
-          Module to respond to requests for multiple patients’ data according to
-          the implementation specification adopted in § 170.215(a)(4) for all of
-          the FHIR® resources associated with the profiles and Data Elements
-          specified in and according to the standard adopted in § 170.213 and
-          implementation specification adopted in § 170.215(a)(2).
-          * “AllergyIntolerance”;
-          * “CarePlan”;
-          * “CareTeam”;
-          * “Condition”;
-          * “Device”;
-          * “DiagnosticReport”;
-          * “DocumentReference”;
-          * “Encounter”;
-          * “Goal”;
-          * “Immunization”;
-          * “Location” (if supported);
-          * “Medication” (if supported);
-          * “MedicationRequest”;
-          * “Observation”;
-          * “Organization”;
-          * “Patient”;
-          * “Practitioner”
-          * “Procedure”; and
-          * “Provenance”.
-          * “PractitionerRole” (if supported);
-          * “QuestionnaireReponse” (if supported);
-          * “RelatedPerson”; and
-          * “ServiceRequest”
-        TLV: |
-          The health IT developer verifies the ability of the Health IT Module
-          to respond to requests for multiple patients’ data according to the
-          implementation specification adopted in § 170.215(a)(4) for all of the
-          FHIR® resources associated with the profiles and Data Elements
-          specified in and according to the standard adopted in § 170.213 and
-          implementation specification adopted in § 170.215(a)(2).
-          * “AllergyIntolerance”;
-          * “CarePlan”;
-          * “CareTeam”;
-          * “Condition”;
-          * “Device”;
-          * “DiagnosticReport”;
-          * “DocumentReference”;
-          * “Encounter”;
-          * “Goal”;
-          * “Immunization”;
-          * “Location” (if supported);
-          * “Medication” (if supported);
-          * “MedicationRequest”;
-          * “Observation”;
-          * “Organization”;
-          * “Patient”;
-          * “Practitioner”
-          * “Procedure”; and
-          * “Provenance”.
-          * “PractitionerRole” (if supported);
-          * “QuestionnaireReponse” (if supported);
-          * “RelatedPerson”; and
-          * “ServiceRequest”
-        inferno_supported: 'yes'
-        inferno_tests:
-          - 7.3.03
-          - 7.3.06 - 7.3.27
-          - 8.3.03
-          - 8.3.06 - 8.3.27
       - id: DAT-PAT-17
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
           Module to respond to requests for multiple patients’ data according to
-          the implementation specification adopted in § 170.215(a)(4) for all of
-          the FHIR® resources associated with the profiles and Data Elements
-          specified in and according to the standard adopted in § 170.213 and
-          implementation specification adopted in § 170.215(a)(2).
-
+          an implementation specification adopted in § 170.215(d) for all of the
+          FHIR® resources associated with the profiles and Data Elements
+          specified in and according to the standard adopted in § 170.213(b) and
+          implementation specification adopted in § 170.215(b)(1)(ii).
           * “AllergyIntolerance”;
           * “CarePlan”;
           * “CareTeam”;
@@ -2198,11 +2179,11 @@ procedure:
           * “ServiceRequest”
         TLV: |
           The health IT developer verifies the ability of the Health IT Module
-          to respond to requests for multiple patients’ data according to the
-          implementation specification adopted in § 170.215(a)(4) for all of the
+          to respond to requests for multiple patients’ data according to an
+          implementation specification adopted in § 170.215(d) for all of the
           FHIR® resources associated with the profiles and Data Elements
-          specified in and according to the standard adopted in § 170.213 and
-          implementation specification adopted in § 170.215(a)(2).
+          specified in and according to the standard adopted in § 170.213(b) and
+          implementation specification adopted in § 170.215(b)(1)(ii).
           * “AllergyIntolerance”;
           * “CarePlan”;
           * “CareTeam”;
@@ -2239,28 +2220,25 @@ procedure:
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
           Module to limit the data returned to only those FHIR® resources for
-          which the client is authorized according to the implementation
-          specification adopted in § 170.215(a)(4).
+          which the client is authorized according to an implementation
+          specification adopted in § 170.215(d).
         TLV: |
           The tester verifies the ability of the Health IT Module to limit the
           data returned to only those FHIR® resources for which the client is
-          authorized according to the implementation specification adopted in §
-          170.215(a)(4).
+          authorized according to an implementation specification adopted in §
+          170.215(d).
         inferno_supported: 'yes'
         inferno_tests:
-          - 2.3.01 - 2.3.15
-        inferno_notes: |
-          Inferno does not do this because there is no requirement to only
-          supported a subset of the scopes.
+          - 2.3.01 - 2.3.19
       - id: DAT-PAT-10
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
-          Module to support a successful data response according to the
-          implementation adopted in § 170.215(a)(4).
+          Module to support a successful data response according to an
+          implementation adopted in § 170.215(d).
         TLV: |
           The tester verifies the ability of the Health IT Module to support a
-          successful data response according to the implementation adopted in §
-          170.215(a)(4).
+          successful data response according to an implementation adopted in §
+          170.215(d).
         inferno_supported: 'yes'
         inferno_tests:
           - 7.2.04 - 7.2.05
@@ -2270,12 +2248,12 @@ procedure:
       - id: DAT-PAT-11
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
-          Module to support a data response error according to the
-          implementation adopted in § 170.215(a)(4).
+          Module to support a data response error according to an implementation
+          adopted in § 170.215(d).
         TLV: |
           The tester verifies the ability of the Health IT Module to support a
-          data response error according to the implementation adopted in §
-          170.215(a)(4).
+          data response error according to an implementation adopted in §
+          170.215(d).
         inferno_supported: 'yes'
         inferno_tests:
           - 7.2.03
@@ -2283,12 +2261,12 @@ procedure:
       - id: DAT-PAT-12
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
-          Module to support a bulk data delete request according to the
-          implementation specification adopted in § 170.215(a)(4).
+          Module to support a bulk data delete request according to an
+          implementation specification adopted in § 170.215(d).
         TLV: |
           The tester verifies the ability of the Health IT Module to support a
-          bulk data delete request according to the implementation specification
-          adopted in § 170.215(a)(4).
+          bulk data delete request according to an implementation specification
+          adopted in § 170.215(d).
         inferno_supported: 'yes'
         inferno_tests:
           - 7.4.01
@@ -2297,12 +2275,12 @@ procedure:
       - id: DAT-PAT-13
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
-          Module to support a bulk data status request according to the
-          implementation specification adopted in § 170.215(a)(4).
+          Module to support a bulk data status request according to an
+          implementation specification adopted in § 170.215(d).
         TLV: |
           The tester verifies the ability of the Health IT Module to support a
-          bulk data status request according to the implementation specification
-          adopted in § 170.215(a)(4).
+          bulk data status request according to an implementation specification
+          adopted in § 170.215(d).
         inferno_supported: 'yes'
         inferno_tests:
           - 7.2.05 - 7.2.06
@@ -2310,13 +2288,13 @@ procedure:
       - id: DAT-PAT-14
         SUT: |
           The health IT developer demonstrates the ability of the Health IT
-          Module to support a file request according to the implementation
-          specification adopted in § 170.215(a)(4), including support for the
+          Module to support a file request according to an implementation
+          specification adopted in § 170.215(d), including support for the
           “ndjson” format for files provided.
         TLV: |
           The tester verifies the ability of the Health IT Module to support a
-          file request according to the implementation specification adopted in
-          § 170.215(a)(4), including support for the “ndjson” format for files
+          file request according to an implementation specification adopted in §
+          170.215(d), including support for the “ndjson” format for files
           provided.
         inferno_supported: 'yes'
         inferno_tests:
@@ -2366,29 +2344,31 @@ procedure:
             registration.
         inferno_supported: 'yes'
         inferno_tests:
-          - 9.10.09
+          - '11.09'
       - id: API-DOC-2
         SUT: |
           The health IT developer demonstrates that the documentation described
-          in step 1, of this section is available via a publicly accessible
-          hyperlink that does not require preconditions or additional steps to
-          access.
+          in step API-DOC-1, of this section is available via a publicly
+          accessible hyperlink that does not require preconditions or additional
+          steps to access.
         TLV: |
-          The tester verifies the documentation described in step 1, of this
-          section is available via a publicly accessible hyperlink that does not
-          require preconditions or additional steps to access.
+          The tester verifies the documentation described in step API-DOC-1, of
+          this section is available via a publicly accessible hyperlink that
+          does not require preconditions or additional steps to access.
         inferno_supported: 'yes'
         inferno_tests:
-          - 9.10.09
+          - '11.09'
       - id: API-DOC-3
         SUT: |
           To fulfill the API Maintenance of Certification requirement at §
           170.404(b)(2), the health IT developer demonstrates the public
-          location of its certified API technology service base URLs.
+          location of its certified API technology service base URLs and related
+          organization details.
         TLV: |
           To fulfill the API Maintenance of Certification requirement at §
           170.404(b)(2), the tester verifies the public location of the health
-          IT developer's certified API technology service base URLs.
+          IT developer’s certified API technology service base URLs and related
+          organization details.
         inferno_supported: 'yes'
         inferno_tests:
-          - 9.10.14
+          - '11.14'