procedure:
- section: Paragraph (g)(10)(iii) - Application registration
steps:
- group: Application Registration
id: APP-REG-1
SUT: |
The health IT developer demonstrates the Health IT Module supports
application registration with an authorization server for the purposes
of Electronic Health Information (EHI) access for single patients,
including support for application registration functions to enable
authentication and authorization in § 170.315(g)(10)(v).
TLV: |
The tester verifies the Health IT Module supports application
registration with an authorization server for the purposes of EHI
access for single patients, including support for application
registration functions to enable authentication and authorization in §
170.315(g)(10)(v).
inferno_tests:
- 9.10.01
inferno_supported: 'yes'
inferno_notes: |
This requires a visual inspection and attestation because it is not
possible to automate without any standard method required for application
registration.
- id: APP-REG-2
SUT: |
The health IT developer demonstrates the Health IT Module supports
application registration with an authorization server for the purposes
of EHI access for multiple patients including support for application
registration functions to enable authentication and authorization in §
170.315(g)(10)(v).
TLV: |
The tester verifies the Health IT Module supports application
registration with an authorization server for the purposes of EHI
access for multiple patients including support for application
registration functions to enable authentication and authorization in §
170.315(g)(10)(v).
inferno_tests:
- 9.10.02
inferno_supported: 'yes'
inferno_notes: |
This requires a visual inspection and attestation because it is not
possible to automate without any standard method required for application
registration.
- section: Paragraph (g)(10)(iv) – Secure connection
steps:
- group: Secure connection
id: SEC-CNN-1
SUT: |
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),
including:
* Using TLS version 1.2 or higher; and
* Conformance to FHIR® Communications Security requirements.
TLV: |
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:
* Using TLS version 1.2 or higher; and
* Conformance to FHIR® Communications Security requirements.
inferno_supported: 'yes'
inferno_tests:
- 1.3.01
- 1.3.04
- 1.4.01
- 1.4.04
- 2.1.01
- 2.1.04
- 2.2.01
- 2.2.04
- 3.3.03
- 3.3.06
- 3.4.03
- 3.4.06
- 4.1.01
- 5.1.01
- 10.1.01
- 7.1.01
- 7.2.01
- 7.3.01
- 8.1.01
- 8.2.01
- 8.3.01
- 9.1.01
- 9.1.04
- 9.2.01
- 9.2.04
- 9.8.03
- 9.8.06
- 9.9.03
- 9.9.06
- 9.10.15
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.
This includes all FHIR endpoints (if more than one is provided), as
well as authorization endpoints required by SMART. Inferno can be
configured to disable TLS testing if configuring TLS within a
lab environment is not possible. Note that there are no SHALL
requirements within the "FHIR Communications Security Requirements" in
FHIR R4, and therefore there are no tests based on this requirement.
- section: Paragraph (g)(10)(v)(A) – Authentication and authorization for patient and user scopes
steps:
- group: Authentication and Authorization for Patient and User Scopes
id: AUT-PAT-1
SUT: |
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).
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).
inferno_supported: 'yes'
inferno_tests:
- 1.3.01 - 1.3.07
- 1.4.01 - 1.4.07
- 3.3.01 - 3.3.09
- 3.4.01 - 3.4.09
inferno_notes: |
Complete demonstration of these capabilities are accomplished
through subsequent steps in the test procedure.
- id: AUT-PAT-2
SUT: |
[EHR-Launch] The health IT developer demonstrates 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:
* 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:
* Launching the registered launch URL of the application; and
* Passing the parameters: “iss” and “launch”.
inferno_supported: 'yes'
inferno_tests:
- 3.3.01 - 3.3.02
- 3.3.04
- 3.4.01 - 3.4.02
- 3.4.04
- id: AUT-PAT-3
SUT: |
[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).
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).
inferno_supported: 'yes'
inferno_tests:
- 1.3.02
- 1.4.02
- id: AUT-PAT-4
SUT: |
[Standalone-Launch] The health IT developer demonstrates the ability
of the Health IT Module to support SMART’s public client profile.
TLV: |
[Standalone-Launch] The tester verifies the ability of the Health IT
Module to support SMART’s public client profile.
inferno_supported: 'yes'
inferno_tests:
- 9.1.02 - 9.1.03
- 9.1.05 - 9.1.09
- 9.2.02 - 9.2.03
- 9.2.05 - 9.2.09
- id: AUT-PAT-5
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 §
170.215(a)(1):
* The “.well-known/smart-configuration.json” 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
* A FHIR® “CapabilityStatement”.
inferno_supported: 'yes'
inferno_tests:
- 1.1.01 - 1.1.03
- 3.1.01 - 3.1.03
- 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
detailed in the implementation specification adopted in §
170.215(a)(3) 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).
inferno_supported: 'yes'
inferno_tests:
- 1.2.01 - 1.2.03
- 3.2.01 - 3.2.03
- 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
following as detailed in the implementation specification adopted in §
170.215(a)(3):
* “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
following as detailed in the implementation specification adopted in §
170.215(a)(3):
* “authorization_endpoint”;
* “token_endpoint”; and
* “capabilities” (including support for all the “SMART on FHIR® Core
Capabilities”).
inferno_supported: 'yes'
inferno_tests:
- 1.1.02
- 1.1.04 - 1.1.05
- 3.1.02
- 3.1.04 - 3.1.05
inferno_notes: |
Inferno additionally checks that the "authorization endpoint" and the
"token endpoint" are consistent between the Capability Statement and
the well-known endpoint.
- 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
following as detailed in the implementation specification adopted in §
170.215(a)(3):
* “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”;
* “grant_types_supported” with support for “authorization_code” and
“client_credentials”; and
* “code_challenge_methods_supported” with support for “S256” and shall
not include support for “plain”
Additionally, the following “capabilities” must be supported if using
US Core 5.0.1 or 6.1.0:
* "context-ehr-encounter"
TLV: |
[Both] The tester verifies the ability of the
“.well-known/smart-configuration.json” path to support at least the
following as detailed in the implementation specification adopted in §
170.215(a)(3):
* “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”;
* “grant_types_supported” with support for “authorization_code” and
“client_credentials”; and
* “code_challenge_methods_supported” with support for “S256” and shall
not include support for “plain”
Additionally, the following “capabilities” must be supported if using
US Core 5.0.1 or 6.1.0:
* "context-ehr-encounter"
inferno_supported: 'yes'
inferno_tests:
- 1.2.01 - 1.2.03
- 3.2.01 - 3.2.03
- id: AUT-PAT-7
SUT: |
[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:
* “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:
* “authorize”; and
* “token”.
inferno_supported: 'yes'
inferno_tests:
- 1.1.03 - 1.1.04
- 3.1.03 - 3.1.04
inferno_notes: |
Inferno additionally checks that the "authorization endpoint" and the
"token endpoint" are consistent between the Capability Statement and
the well-known endpoint.
- id: AUT-PAT-8
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
support for the following parameters:
* “response_type”;
* “client_id”;
* “redirect_uri”;
* “launch” (for EHR-Launch mode only);
* “scope”;
* “state”; and
* “aud”.
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
following parameters:
* “response_type”;
* “client_id”;
* “redirect_uri”;
* “launch” (for EHR-Launch mode only);
* “scope”;
* “state”; and
* “aud”.
inferno_supported: 'yes'
inferno_tests:
- 1.3.02 - 1.3.03
- 3.3.04 - 3.3.05
- id: AUT-PAT-26
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
support for the following parameters:
* “response_type”;
* “client_id”;
* “redirect_uri”;
* “launch” (for EHR-Launch mode only);
* “scope”;
* “state”;
* “aud”;
* “code_challenge”; and
* “code_challenge_method”
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
following parameters:
* “response_type”;
* “client_id”;
* “redirect_uri”;
* “launch” (for EHR-Launch mode only);
* “scope”;
* “state”;
* “aud”;
* “code_challenge”; and
* “code_challenge_method”
inferno_supported: 'yes'
inferno_tests:
- 1.4.02 - 1.4.03
- 3.4.04 - 3.4.05
- id: AUT-PAT-27
SUT: |
[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).
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).
inferno_supported: 'yes'
inferno_tests:
- 1.4.05 - 1.4.07
- 3.4.07 - 3.4.09
- id: AUT-PAT-9
SUT: |
[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):
* “openid” (to support “sso-openid-connect” “SMART on FHIR® Core
Capability”);
* “FHIR®User” (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);
* “smart_style_url” (to support “context-style” “SMART on FHIR® Core
Capability” for EHR-Launch mode only);
* “launch/patient” (to support “context-standalone-patient” “SMART on
FHIR® Core Capability” for Standalone-Launch mode only);
* “launch” (for EHR-Launch mode only);
* “offline_access” (to support “permission-offline” “SMART on FHIR®
Core Capability”);
* Patient-level scopes (to support “permission-patient” “SMART on
FHIR® Core Capability”); and
* User-level scopes (to support “permission-user” “SMART on FHIR® Core
Capability”).
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):
* “openid” (to support “sso-openid-connect” “SMART on FHIR® Core
Capability”);
* “FHIR®User” (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);
* “smart_style_url” (to support “context-style” “SMART on FHIR® Core
Capability” for EHR-Launch mode only);
* “launch/patient” (to support “context-standalone-patient” “SMART on
FHIR® Core Capability” for Standalone-Launch mode only);
* “launch” (for EHR-Launch mode only);
* “offline_access” (to support “permission-offline” “SMART on FHIR®
Core Capability”);
* Patient-level scopes (to support “permission-patient” “SMART on
FHIR® Core Capability”); and
* User-level scopes (to support “permission-user” “SMART on FHIR® Core
Capability”).
inferno_supported: 'yes'
inferno_tests:
- 1.3.02
- 3.3.04
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,
it is not possible to tell if these scopes were properly granted until
verifying that the client has access to perform the necessary steps.
Inferno does this as well, but this mapping only refers to the 'receipt' portion
of the launch process.
- id: AUT-PAT-28
SUT: |
[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):
* “openid” (to support “sso-openid-connect” “SMART on FHIR®
Capability”);
* “FHIR®User” (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);
* “smart_style_url” (to support “context-style” “SMART on FHIR®
Capability” for EHR-Launch mode only);
* “launch/patient” (to support “context-standalone-patient” “SMART on
FHIR® Capability” for Standalone-Launch mode only);
* “launch” (for EHR-Launch mode only);
* “offline_access” (to support “permission-offline” “SMART on FHIR®
Capability”);
* Patient-level scopes (to support “permission-patient” and “SMART on
FHIR® Capability”); and
* 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”)
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):
* “openid” (to support “sso-openid-connect” “SMART on FHIR®
Capability”);
* “FHIR®User” (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);
* “smart_style_url” (to support “context-style” “SMART on FHIR®
Capability” for EHR-Launch mode only);
* “launch/patient” (to support “context-standalone-patient” “SMART on
FHIR® Capability” for Standalone-Launch mode only);
* “launch” (for EHR-Launch mode only);
* “offline_access” (to support “permission-offline” “SMART on FHIR®
Capability”);
* Patient-level scopes (to support “permission-patient” and “SMART on
FHIR® Capability”); and
* 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”)
inferno_supported: 'yes'
inferno_tests:
- 1.4.02
- 3.4.04
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,
it is not possible to tell if these scopes were properly granted until
verifying that the client has access to perform the necessary steps.
Inferno does this as well, but this mapping only refers to the 'receipt' portion
of the launch process.
- id: AUT-PAT-10
SUT: |
[Both] The health IT developer demonstrates the ability of the Health
IT Module to evaluate the authorization request and request end-user
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).
If using US Core 3.1.1, 4.0.0, 5.0.1, or 6.1.0 these resources include:
* “AllergyIntolerance”;
* “CarePlan”;
* “CareTeam”;
* “Condition”;
* “Device”;
* “DiagnosticReport”;
* “DocumentReference”;
* “Goal”;
* “Immunization”;
* “Medication” (if supported);
* “MedicationRequest”;
* “Observation”;
* “Patient”;
* “Procedure”; and
* “Provenance”.
The following resources must also be supported if using US Core 5.0.1:
* “Encounter”;
* “RelatedPerson”; and
* “ServiceRequest”
The following resources must also be supported if using US Core 6.1.0:
* "Encounter"
* "Coverage"
* "Specimen"
* "MedicationDispense"
* "RelatedPerson"; and
* "ServiceRequest"
TLV: |
[Both] The tester verifies the ability of the Health IT Module to
evaluate the authorization request and request end-user 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).
If using US Core 3.1.1, 4.0.0, 5.0.1, or 6.1.0 these resources include:
* “AllergyIntolerance”;
* “CarePlan”;
* “CareTeam”;
* “Condition”;
* “Device”;
* “DiagnosticReport”;
* “DocumentReference”;
* “Goal”;
* “Immunization”;
* “Medication” (if supported);
* “MedicationRequest”;
* “Observation”;
* “Patient”;
* “Procedure”; and
* “Provenance”.
The following resources must also be supported if using US Core 5.0.1:
* “Encounter”;
* “RelatedPerson”; and
* “ServiceRequest”
The following resources must also be supported if using US Core 6.1.0:
* "Encounter"
* "Coverage"
* "Specimen"
* "MedicationDispense"
* "RelatedPerson"; and
* "ServiceRequest"
inferno_supported: 'yes'
inferno_tests:
- 1.3.02
- 1.3.05
- 1.4.02
- 1.4.05
- 3.3.04
- 3.3.07
- 3.4.04
- 3.4.07
- 2.1.02
- 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.
- id: AUT-PAT-11
SUT: |
[Both] The health IT developer demonstrates the ability of the Health
IT Module to evaluate the authorization request and request end-user
input, if applicable (required for patient-facing applications),
including either the ability for the end-user to explicitly enable /
disable the “offline_access” scope or information communicating the
application’s request for the “offline_access” scope.
TLV: |
[Both] The tester verifies the ability of the Health IT Module to
evaluate the authorization request and request end-user input, if
applicable (required for patient-facing applications), including
either the ability for the end-user to explicitly enable / disable the
“offline_access” scope or information communicating the application’s
request for the “offline_access” scope.
inferno_supported: 'yes'
inferno_tests:
- 1.3.02
- 1.3.05
- 1.4.02
- 1.4.05
- 2.1.02
- 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.
- 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).
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).
inferno_supported: 'yes'
inferno_tests:
- 1.3.02
- 1.3.05
- 1.4.02
- 1.4.05
- 2.1.02
- 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.
- id: AUT-PAT-29
SUT: |
[EHR-Launch] The health IT developer demonstrates 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).
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).
inferno_supported: 'yes'
inferno_tests:
- 9.9.01 - 9.9.10
- id: AUT-PAT-13
SUT: |
[Both] The health IT developer demonstrates the ability of the Health
IT Module to return an error response if the "aud" parameter provided
by an application to the Health IT Module in AUT-PAT-8, is not a valid
FHIR® resource server associated with the Health IT Module's
authorization server.
TLV: |
[Both] The tester verifies the ability of the Health IT Module to
return an error response if the "aud" parameter provided by an
application to the Health IT Module in AUT-PAT-8, is not a valid FHIR®
resource server associated with the Health IT Module's authorization
server.
inferno_supported: 'yes'
inferno_tests:
- 9.4.01 - 9.4.03
- id: AUT-PAT-14
SUT: |
[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
parameters:
* “code”; and
* “state”.
TLV: |
[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:
* “code”; and
* “state”.
inferno_supported: 'yes'
inferno_tests:
- 1.3.03
- 1.4.03
- 3.3.05
- 3.4.05
- id: AUT-PAT-15
SUT: |
[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):
* “grant_type”;
* “code”;
* “redirect_uri”;
* “client_id”; and
* Authorization header including “client_id” and “client_secret”.
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):
* “grant_type”;
* “code”;
* “redirect_uri”;
* “client_id”; and
* Authorization header including “client_id” and “client_secret”.
inferno_supported: 'yes'
inferno_tests:
- 1.3.05
- 3.3.07
inferno_notes: |
"client_secret" is only provided in the case of confidential clients.
- id: AUT-PAT-30
SUT: |
[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):
* “grant_type”;
* “code”;
* “redirect_uri”;
* “code_verifier”;
* “client_id”; and
* Authorization header including “client_id” and “client_secret”.
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):
* “grant_type”;
* “code”;
* “redirect_uri”;
* “code_verifier”;
* “client_id”; and
* Authorization header including “client_id” and “client_secret”.
inferno_supported: 'yes'
inferno_tests:
- 1.3.05
- 3.3.07
- 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).
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).
inferno_supported: 'yes'
inferno_tests:
- 1.4.05
- 3.4.07
- 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:
* “access_token”;
* “token_type”;
* “scope”;
* “id_token”;
* “refresh_token” (valid for a period of no shorter than three
months);
* HTTP “Cache-Control” response header field with a value of
“no-store”;
* HTTP “Pragma” response header field with a value of “no-cache”;
* “patient” (to support “context-ehr-patient” and
“context-standalone-patient” “SMART on FHIR® Core Capabilities”);
* “need_patient_banner” (to support “context-banner” “SMART on FHIR®
Core Capability” for EHR-Launch mode only); and
* “smart_style_url” (to support “context-style” “SMART on FHIR® Core
Capability” for EHR-Launch mode only).
Additionally, the following must be supported if using US Core 5.0.1
or 6.1.0:
* “encounter” (to support "context-ehr-encounter" “SMART on FHIR®
Capability”)
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:
* “access_token”;
* “token_type”;
* “scope”;
* “id_token”;
* “refresh_token” (valid for a period of no shorter than three
months);
* HTTP “Cache-Control” response header field with a value of
“no-store”;
* HTTP “Pragma” response header field with a value of “no-cache”;
* “patient” (to support “context-ehr-patient” and
“context-standalone-patient” “SMART on FHIR® Core Capabilities”);
* “need_patient_banner” (to support “context-banner” “SMART on FHIR®
Core Capability” for EHR-Launch mode only); and
* “smart_style_url” (to support “context-style” “SMART on FHIR® Core
Capability” for EHR-Launch mode only).
Additionally, the following must be supported if using US Core 5.0.1
or 6.1.0:
* “encounter” (to support"context-ehr-encounter" “SMART on FHIR®
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
- 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),
including:
* All required fields populated according to implementation
specification adopted in § 170.215(b); 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:
* All required fields populated according to implementation
specification adopted in § 170.215(b); and
* Valid JWKS populated according to implementation specification can
be retrieved via JWKS URI.
inferno_supported: 'yes'
inferno_tests:
- 1.5.01 - 1.5.07
- 3.5.01 - 3.5.07
inferno_notes: |
Inferno decodes the id_token provided during authentication and
verifies that it contains the correct claims, has a valid signature,
and the fhirUser claim contains a reference to the current user that
can be retreived using the bearer token provided during the application launch.
- id: AUT-PAT-18
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).
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).
inferno_supported: 'yes'
inferno_notes: |
Inferno verifies that the user has the ability to explicitly authorize
apps to appropriate resources and capabilities. Inferno also verifies
that apps that send invalid information during the authorization process
are denied.
inferno_tests:
- 2.1.02 - 2.1.09
- 2.2.02 - 2.2.09
- 2.3.01 - 2.3.19
- 9.5.01 - 9.5.04
- 9.6.01 - 9.6.04
- id: AUT-PAT-19
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).
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).
inferno_supported: 'yes'
inferno_tests:
- 1.3.10
- 1.4.10
- 3.3.12
- 3.4.12
- 9.8.10
- 9.9.10
- id: AUT-PAT-32
SUT: |
[EHR-Launch] The following must be supported if using US Core 5.0.1 or
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).
TLV: |
[EHR-Launch] The following must be supported if using US Core 5.0.1 or
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).
inferno_supported: 'yes'
inferno_tests:
- 3.3.16
- 3.4.16
- id: AUT-PAT-20
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).
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).
inferno_supported: 'yes'
inferno_tests:
- 1.6.03 - 1.6.05
- 3.6.05 - 3.6.05
- id: AUT-PAT-21
SUT: |
[Both] The health IT developer demonstrates the ability of the Health
IT Module to grant a refresh token valid for a period of no less than
three months to native applications capable of securing a refresh
token.
TLV: |
[Both] The tester verifies the ability of the Health IT Module to
grant a refresh token valid for a period of no less than three months
to native applications capable of securing a refresh token.
inferno_supported: 'yes'
inferno_tests:
- 9.10.13
- group: 'Subsequent Connections: Authentication and Authorization for Patient and User Scopes'
id: AUT-PAT-22
SUT: |
The health IT developer demonstrates 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).
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).
inferno_supported: 'yes'
inferno_tests:
- 9.10.16
inferno_notes: |
Inferno cannot verify the three month token expiration requirement
automatically during the token refresh tests, but the tester can
register an attestation that this requirement is met.
- id: AUT-PAT-23
SUT: |
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).
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).
inferno_supported: 'yes'
inferno_tests:
- 1.6.06
- 3.6.06
- section: Paragraph (g)(10)(vi) – Patient authorization revocation
steps:
- group: Patient Authorization Revocation
id: PAR-1
SUT: |
The health IT developer demonstrates the ability of the Health IT
Module to revoke access to an authorized application at a patient’s
direction, including a demonstration of the inability of the
application with revoked access to receive patient EHI.
TLV: |
The tester verifies the ability of the Health IT Module to revoke
access to an authorized application at a patient’s direction,
including a demonstration of the inability of the application with
revoked access to receive patient EHI.
inferno_supported: 'yes'
inferno_tests:
- 9.3.01 - 9.3.03
- section: Paragraph (g)(10)(v)(B) Authentication and authorization for system scopes
steps:
- group: Authentication and Authorization for System Scopes
id: AUT-SYS-1
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).
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).
inferno_supported: 'yes'
inferno_tests:
- 7.1.02 - 7.1.06
- 8.1.02 - 8.1.06
- 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):
* “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):
* “scope”;
* “grant_type”;
* “client_assertion_type”; and
* “client_assertion”.
inferno_supported: 'yes'
inferno_tests:
- 7.1.05
- 8.1.05
- id: AUT-SYS-3
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):
* “alg” header;
* “kid” header;
* “typ” header;
* “iss” claim;
* “sub” claim;
* “aud” claim;
* “exp” claim; and
* “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):
* “alg” header;
* “kid” header;
* “typ” header;
* “iss” claim;
* “sub” claim;
* “aud” claim;
* “exp” claim; and
* “jti” claim.
inferno_supported: 'yes'
inferno_tests:
- 7.1.05
- 8.1.05
- id: AUT-SYS-4
SUT: |
The health IT developer demonstrates the ability of the Health IT
Module to receive and process the JSON Web Key (JWK) Set via a
TLS-protected URL to support authorization for system scopes in §
170.315(g)(10)(v)(B).
TLV: |
The tester verifies the ability of the Health IT Module to receive and
process the JWK structure via a TLS-protected URL to support
authorization for system scopes in § 170.315(g)(10)(v)(B).
inferno_supported: 'yes'
inferno_tests:
- 7.1.05
- 8.1.05
- id: AUT-SYS-5
SUT: |
The health IT developer demonstrates that the Health IT Module does
not cache a JWK Set received via a TLS-protected URL for longer than
the “cache-control” header sent by an application indicates.
TLV: |
The tester verifies that the Health IT Module does not cache a JWK Set
received via a TLS-protected URL for longer than the “cache-control”
header sent by an application indicates.
inferno_supported: 'yes'
inferno_notes: |
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
- 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).
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).
inferno_supported: 'yes'
inferno_tests:
- 7.1.05
- 8.1.05
- id: AUT-SYS-7
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).
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).
inferno_supported: 'yes'
inferno_tests:
- 7.1.02 - 7.1.04
- 8.1.02 - 8.1.04
- id: AUT-SYS-8
SUT: |
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).
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).
inferno_supported: 'yes'
inferno_notes: |
There is no requirement for support of a subset of the resources
so you can't check to see what happens when you attempt to access
more than what was pre-authorized. The Health IT module must
demonstrate this and register its attestation within Inferno.
inferno_tests:
- 9.10.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:
* “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
following property names:
* “access_token”;
* “token_type”;
* “expires_in”; and
* “scope”.
inferno_supported: 'yes'
inferno_tests:
- 7.1.06
- 8.1.06
- id: AUT-SYS-10
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).
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).
inferno_supported: 'yes'
inferno_tests:
- 7.1.02 - 7.1.04
- 8.1.02 - 8.1.04
- 7.2.03
- 8.2.03
- section: Paragraph (g)(10)(vii) – Token introspection
steps:
- group: Token Introspection
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.
TLV: |
The tester verifies the ability of the Health IT Module to receive and
validate a token it has issued.
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
- section: Paragraph (g)(10)(ii) – Supported search operations
steps:
- group: Supported Search Operations for a Single Patient’s Data
id: SH-PAT-1
SUT: |
The health IT developer demonstrates 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).
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).
inferno_supported: 'yes'
inferno_tests:
- 4.1.02 - 4.1.05
- 5.1.02 - 5.1.06
- 10.1.02 - 10.1.06
- id: SH-PAT-2
SUT: |
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
“SHALL” operations and parameters for all the data included in the
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),
including demonstrating search support for “SHALL” operations and
parameters for all the data included in the standard adopted in §
170.213.
inferno_supported: 'yes'
inferno_tests:
- 4.2.01
- 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.11.01
- 4.12.01
- 4.13.01
- 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
- 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.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
- 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
- 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).
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).
inferno_supported: 'yes'
inferno_tests:
- 4.2.07
- 4.3.03
- 4.4.03
- 4.5.03
- 4.6.03
- 4.7.03
- 4.8.06
- 4.9.06
- 4.10.07
- 4.11.03
- 4.12.03
- 4.13.04
- 4.14.03
- 4.15.05
- 4.16.05
- 4.17.05
- 4.18.05
- 4.19.05
- 4.20.05
- 4.21.05
- 4.22.05
- 4.23.05
- 4.24.05
- 4.25.05
- 4.26.04
- 5.2.07
- 5.3.03
- 5.4.03
- 5.5.03
- 5.6.03
- 5.7.03
- 5.8.06
- 5.9.06
- 5.10.07
- 5.11.03
- 5.12.03
- 5.13.04
- 5.14.05
- 5.15.05
- 5.16.05
- 5.17.05
- 5.18.05
- 5.19.05
- 5.20.05
- 5.21.05
- 5.22.05
- 5.23.05
- 5.24.05
- 5.25.05
- 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
- group: Supported Search Operations for Multiple Patients’ Data
id: SH-PAT-4
SUT: |
The health IT developer demonstrates 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).
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).
inferno_supported: 'yes'
inferno_tests:
- 7.2.02
- 8.2.02
- id: SH-PAT-5
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).
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).
inferno_supported: 'yes'
inferno_tests:
- 7.2.04
- 8.2.04
- section: Paragraph (g)(10)(i) – Data response
steps:
- group: Data Response Checks for Single and Multiple Patients
id: DAT-PAT-1
SUT: |
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
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
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.
inferno_supported: 'yes'
inferno_tests:
- 4.2.06
- 4.3.02
- 4.4.02
- 4.5.02
- 4.6.02
- 4.7.02
- 4.8.05
- 4.9.05
- 4.10.06
- 4.11.02
- 4.12.02
- 4.13.03
- 4.14.02
- 4.15.04
- 4.16.04
- 4.17.04
- 4.18.04
- 4.19.04
- 4.20.04
- 4.21.04
- 4.22.04
- 4.23.04
- 4.24.04
- 4.25.04
- 4.26.03
- 4.27.01
- 4.28.01
- 4.29.01
- 4.30.01
- 5.2.06
- 5.3.02
- 5.4.02
- 5.5.02
- 5.6.02
- 5.7.02
- 5.8.05
- 5.9.05
- 5.10.06
- 5.11.02
- 5.12.02
- 5.13.03
- 5.14.04
- 5.15.04
- 5.16.04
- 5.17.04
- 5.18.04
- 5.19.04
- 5.20.04
- 5.21.04
- 5.22.04
- 5.23.04
- 5.24.04
- 5.25.04
- 5.26.04
- 5.27.04
- 5.28.03
- 5.29.01
- 5.30.01
- 5.31.01
- 5.32.01
- 7.3.03
- 7.3.06 - 7.3.34
- 8.3.03
- 8.3.06 - 8.3.34
- 10.2.06
- 10.3.02
- 10.4.02
- 10.5.02
- 10.6.03
- 10.7.03
- 10.8.02
- 10.9.02
- 10.10.05
- 10.11.05
- 10.12.06
- 10.13.04
- 10.14.02
- 10.15.02
- 10.16.02
- 10.17.03
- 10.18.04
- 10.19.04
- 10.20.04
- 10.21.04
- 10.22.04
- 10.23.04
- 10.24.04
- 10.25.04
- 10.26.04
- 10.27.04
- 10.28.02
- 10.29.04
- 10.30.04
- 10.31.04
- 10.32.04
- 10.33.04
- 10.34.04
- 10.35.04
- 10.36.04
- 10.37.04
- 10.38.03
- 10.39.06
- 10.40.01
- 10.41.01
- 10.42.01
- 10.43.01
- 10.44.01
- id: DAT-PAT-2
SUT: |
The health IT developer demonstrates the ability of the Health IT
Module to respond with data that meet the following conditions:
* All data elements indicated with a cardinality of one or greater and
/ or “must support” are included;
* Content is structurally correct;
* All invariant rules are met;
* All data elements with required “ValueSet” bindings contain codes
within the bound “ValueSet”;
* All information is accurate and without omission; and
* All references within the resources can be resolved and validated,
as applicable, according to steps DAT-PAT-2, DAT-PAT-3, DAT-PAT-4,
DAT-PAT-5, and DAT-PAT-6, of this section.
TLV: |
The tester verifies the ability of the Health IT Module to respond
with data that meet the following conditions:
* All data elements indicated with a cardinality of one or greater and
/ or “must support” are included;
* Content is structurally correct;
* All invariant rules are met;
* All data elements with required “ValueSet” bindings contain codes
within the bound “ValueSet”;
* All information is accurate and without omission; and
* All references within the resources can be resolved and validated,
as applicable, according to steps DAT-PAT-2, DAT-PAT-3, DAT-PAT-4,
DAT-PAT-5, and DAT-PAT-6, of this section.
inferno_supported: 'yes'
inferno_tests:
- 9.10.07
- 9.10.11
- 4.2.08 - 4.2.09
- 4.3.04 - 4.3.05
- 4.4.04 - 4.4.05
- 4.5.04 - 4.5.05
- 4.6.04 - 4.6.05
- 4.7.04 - 4.7.05
- 4.8.07 - 4.8.08
- 4.9.07 - 4.9.08
- 4.10.08 - 4.10.09
- 4.11.04 - 4.11.05
- 4.12.04 - 4.12.05
- 4.13.06 - 4.13.07
- 4.14.04 - 4.14.05
- 4.15.06 - 4.15.07
- 4.16.06 - 4.16.07
- 4.17.06 - 4.17.07
- 4.18.06 - 4.18.07
- 4.19.06 - 4.19.07
- 4.20.06 - 4.20.07
- 4.21.06 - 4.21.07
- 4.22.06 - 4.22.07
- 4.23.06 - 4.23.07
- 4.24.06 - 4.24.07
- 4.25.06 - 4.25.07
- 4.26.05 - 4.26.06
- 4.27.02 - 4.27.03
- 4.28.02 - 4.28.03
- 4.29.02 - 4.29.03
- 4.30.02 - 4.30.03
- 5.2.08 - 5.2.09
- 5.3.04 - 5.3.05
- 5.4.04 - 5.4.05
- 5.5.04 - 5.5.05
- 5.6.04 - 5.6.05
- 5.7.04 - 5.7.05
- 5.8.07 - 5.8.08
- 5.9.07 - 5.9.08
- 5.10.08 - 5.10.09
- 5.11.04 - 5.11.05
- 5.12.04 - 5.12.05
- 5.13.06 - 5.13.07
- 5.14.06 - 5.14.07
- 5.15.06 - 5.15.07
- 5.16.06 - 5.16.07
- 5.17.06 - 5.17.07
- 5.18.06 - 5.18.07
- 5.19.06 - 5.19.07
- 5.20.06 - 5.20.07
- 5.21.06 - 5.21.07
- 5.22.06 - 5.22.07
- 5.23.06 - 5.23.07
- 5.24.06 - 5.24.07
- 5.25.06 - 5.25.07
- 5.26.05 - 5.26.06
- 5.27.06 - 5.27.07
- 5.28.05 - 5.28.06
- 5.29.02 - 5.29.03
- 5.30.02 - 5.30.03
- 5.31.02 - 5.31.03
- 5.32.02 - 5.32.03
- 10.2.08 - 10.2.09
- 10.3.04 - 10.3.05
- 10.4.04 - 10.4.05
- 10.5.04 - 10.5.05
- 10.6.05 - 10.6.06
- 10.7.05 - 10.7.06
- 10.8.04 - 10.8.05
- 10.9.04 - 10.9.05
- 10.10.07 - 10.10.08
- 10.11.07 - 10.11.08
- 10.12.08 - 10.12.09
- 10.13.06 - 10.13.07
- 10.14.04 - 10.14.05
- 10.15.04 - 10.15.05
- 10.16.04 - 10.16.05
- 10.17.06 - 10.17.07
- 10.18.06 - 10.18.07
- 10.19.06 - 10.19.07
- 10.20.06 - 10.20.07
- 10.21.06 - 10.21.07
- 10.22.06 - 10.22.07
- 10.23.06 - 10.23.07
- 10.24.06 - 10.24.07
- 10.25.06 - 10.25.07
- 10.26.06 - 10.26.07
- 10.27.06 - 10.27.07
- 10.28.04 - 10.28.05
- 10.29.06 - 10.29.07
- 10.30.06 - 10.30.07
- 10.31.06 - 10.31.07
- 10.32.06 - 10.32.07
- 10.33.06 - 10.33.07
- 10.34.06 - 10.34.07
- 10.35.06 - 10.35.07
- 10.36.06 - 10.36.07
- 10.37.06 - 10.37.07
- 10.38.05 - 10.38.06
- 10.39.08 - 10.39.09
- 10.40.02 - 10.40.03
- 10.41.02 - 10.41.03
- 10.42.02 - 10.42.03
- 10.43.02 - 10.43.03
- 10.44.03 - 10.44.04
- 7.3.03
- 7.3.06 - 7.3.34
- 8.3.03
- 8.3.06 - 8.3.34
inferno_notes: |
The requirement "all information is accurate and without omission"
cannot be verified automatically by Inferno, as Inferno only has
visibility into the data being returned in the API. Inferno also does
not require a specific set of data to be loaded. Because of this,
omissions are not possible to detect. However, the tester can use the
tool to compare responses to what is displayed in the system, and
register this as an attestation. Additionally, US Core v3.1 does
not include three required USCDI v1 data elements for Patient Demographics
and Allergy and Intolerances, and this requires visual inspection
by the tester.
- id: DAT-PAT-3
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).
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
Guidance” section of the implementation specification adopted in §
170.215(a)(2).
inferno_supported: 'yes'
inferno_tests:
- 4.2.07
- 4.3.03
- 4.4.03
- 4.5.03
- 4.6.03
- 4.7.03
- 4.8.06
- 4.9.06
- 4.10.07
- 4.11.03
- 4.12.03
- 4.13.04
- 4.14.03
- 4.15.05
- 4.16.05
- 4.17.05
- 4.18.05
- 4.19.05
- 4.20.05
- 4.21.05
- 4.22.05
- 4.23.05
- 4.24.05
- 4.25.05
- 4.26.04
- 4.30.01 - 4.30.04
- 5.2.07
- 5.3.03
- 5.4.03
- 5.5.03
- 5.6.03
- 5.7.03
- 5.8.06
- 5.9.06
- 5.10.07
- 5.11.03
- 5.12.03
- 5.13.04
- 5.14.05
- 5.15.05
- 5.16.05
- 5.17.05
- 5.18.05
- 5.19.05
- 5.20.05
- 5.21.05
- 5.22.05
- 5.23.05
- 5.24.05
- 5.25.05
- 5.26.05
- 5.27.05
- 5.28.04
- 5.32.01 - 5.32.04
- 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
- 10.42.01 - 10.42.04
- 7.3.21
- 8.3.21
- id: DAT-PAT-4
SUT: |
The health IT developer demonstrates 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).
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).
inferno_supported: 'yes'
inferno_tests:
- 4.31.01 - 4.31.02
- 5.33.01 - 5.33.02
- 10.45.01 - 10.45.02
- id: DAT-PAT-5
SUT: |
If supported, and for responses to data for a single patient only, the
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).
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).
inferno_supported: 'yes'
inferno_tests:
- 4.13.06
- 5.13.06
- 10.17.06
- id: DAT-PAT-6
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:
* 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:
* For non-coded data elements; and
* For coded data elements, including support for the
“DataAbsentReason” Code System.
inferno_supported: 'yes'
inferno_tests:
- 4.32.01 - 4.32.02
- 5.34.01 - 5.34.02
- 10.46.01 - 10.46.02
- group: Response to Requests for a Single Patient’s Data
id: DAT-PAT-7
SUT: |
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.
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.
inferno_supported: 'yes'
inferno_tests:
- 4.2.01
- 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.11.01
- 4.12.01
- 4.13.01
- 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
- 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.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
- 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.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).:
* “AllergyIntolerance”;
* “CarePlan”;
* “CareTeam”;
* “Condition”;
* “Device”;
* “DiagnosticReport”;
* “DocumentReference”;
* “Encounter”;
* “Goal”;
* “Immunization”;
* “Location” (if supported);
* “Medication” (if supported);
* “MedicationRequest”;
* “Observation”;
* “Organization”;
* “Patient”;
* “Practitioner”
* “Procedure”; and
* “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).
* “AllergyIntolerance”;
* “CarePlan”;
* “CareTeam”;
* “Condition”;
* “Device”;
* “DiagnosticReport”;
* “DocumentReference”;
* “Encounter”;
* “Goal”;
* “Immunization”;
* “Location” (if supported);
* “Medication” (if supported);
* “MedicationRequest”;
* “Observation”;
* “Organization”;
* “Patient”;
* “Practitioner”
* “Procedure”; and
* “Provenance”.
inferno_supported: 'yes'
inferno_tests:
- 7.3.03
- 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).
* “AllergyIntolerance”;
* “CarePlan”;
* “CareTeam”;
* “Condition”;
* “Coverage”
* “Device”;
* “DiagnosticReport”;
* “DocumentReference”;
* “Encounter”;
* “Goal”;
* “Immunization”;
* “Location” (if supported);
* “Medication” (if supported);
* “MedicationDispense”
* “MedicationRequest”;
* “Observation”;
* “Organization”;
* “Patient”;
* “Practitioner”
* “Procedure”;
* “Provenance”;
* “PractitionerRole” (if supported);
* “QuestionnaireReponse” (if supported);
* “RelatedPerson”;
* “Specimen”; 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”;
* “Coverage”
* “Device”;
* “DiagnosticReport”;
* “DocumentReference”;
* “Encounter”;
* “Goal”;
* “Immunization”;
* “Location” (if supported);
* “Medication” (if supported);
* “MedicationDispense”
* “MedicationRequest”;
* “Observation”;
* “Organization”;
* “Patient”;
* “Practitioner”
* “Procedure”;
* “Provenance”;
* “PractitionerRole” (if supported);
* “QuestionnaireReponse” (if supported);
* “RelatedPerson”;
* “Specimen”; and
* “ServiceRequest”
inferno_supported: 'yes'
inferno_tests:
- 7.3.03
- 7.3.06 - 7.3.34
- 8.3.03
- 8.3.06 - 8.3.34
- id: DAT-PAT-9
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).
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).
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.
- 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).
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).
inferno_supported: 'yes'
inferno_tests:
- 7.2.04 - 7.2.05
- 8.2.04 - 8.2.05
- 8.5.01
- 8.5.02
- 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).
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).
inferno_supported: 'yes'
inferno_tests:
- 7.2.03
- 8.2.03
- 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).
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).
inferno_supported: 'yes'
inferno_tests:
- 7.4.01
- 8.4.01
- 8.4.02
- 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).
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).
inferno_supported: 'yes'
inferno_tests:
- 7.2.05 - 7.2.06
- 8.2.05 - 8.2.06
- 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
“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
provided.
inferno_supported: 'yes'
inferno_tests:
- 7.3.01 - 7.3.34
- 8.3.01 - 8.3.34
- id: DAT-PAT-15
SUT: |
The health IT developer demonstrates that the information provided as
part of this data response includes data for patients in the group
identifier provided during the “group-export” request.
TLV: |
The tester verifies the information provided as part of this data
response includes data for patients in the group identifier provided
during the “group-export” request.
inferno_supported: 'yes'
inferno_tests:
- 7.3.05
- 8.3.05
- section: Paragraph (g)(10)(viii) – Documentation
steps:
- group: Supported Search Operations for a Single Patient’s Data
id: API-DOC-1
SUT: |
The health IT developer supplies documentation describing the API(s)
of the Health IT Module and includes at a minimum:
* 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;
* Mandatory software components;
* Mandatory software configurations; and
* All technical requirements and attributes necessary for
registration.
TLV: |
The tester verifies that the documentation supplied by the health IT
developer describing the API(s) of the Health IT Module includes at a
minimum:
* 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;
* Mandatory software components;
* Mandatory software configurations; and
* All technical requirements and attributes necessary for
registration.
inferno_supported: 'yes'
inferno_tests:
- 9.10.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.
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.
inferno_supported: 'yes'
inferno_tests:
- 9.10.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.
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.
inferno_supported: 'yes'
inferno_tests:
- 9.10.14