onc_certification_g10_test_kit 2.0.0 → 2.1.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/lib/inferno/terminology/tasks/check_built_terminology.rb +14 -12
- data/lib/onc_certification_g10_test_kit/bulk_data_authorization.rb +7 -4
- data/lib/onc_certification_g10_test_kit/bulk_data_group_export.rb +60 -17
- data/lib/onc_certification_g10_test_kit/bulk_data_group_export_validation.rb +10 -6
- data/lib/onc_certification_g10_test_kit/bulk_export_validation_tester.rb +48 -18
- data/lib/onc_certification_g10_test_kit/configuration_checker.rb +6 -5
- data/lib/onc_certification_g10_test_kit/multi_patient_api.rb +11 -0
- data/lib/onc_certification_g10_test_kit/onc_program_procedure.yml +1451 -0
- data/lib/onc_certification_g10_test_kit/profile_guesser.rb +2 -2
- data/lib/onc_certification_g10_test_kit/restricted_resource_type_access_group.rb +13 -13
- data/lib/onc_certification_g10_test_kit/single_patient_api_group.rb +93 -0
- data/lib/onc_certification_g10_test_kit/smart_app_launch_invalid_aud_group.rb +13 -12
- data/lib/onc_certification_g10_test_kit/smart_ehr_practitioner_app_group.rb +11 -5
- data/lib/onc_certification_g10_test_kit/smart_invalid_launch_group.rb +13 -16
- data/lib/onc_certification_g10_test_kit/smart_invalid_token_group.rb +11 -4
- data/lib/onc_certification_g10_test_kit/smart_limited_app_group.rb +18 -4
- data/lib/onc_certification_g10_test_kit/smart_public_standalone_launch_group.rb +15 -3
- data/lib/onc_certification_g10_test_kit/smart_standalone_patient_app_group.rb +8 -3
- data/lib/onc_certification_g10_test_kit/tasks/generate_matrix.rb +247 -0
- data/lib/onc_certification_g10_test_kit/tasks/test_procedure.rb +65 -0
- data/lib/onc_certification_g10_test_kit/token_revocation_group.rb +60 -60
- data/lib/onc_certification_g10_test_kit/unrestricted_resource_type_access_group.rb +13 -13
- data/lib/onc_certification_g10_test_kit/version.rb +1 -1
- data/lib/onc_certification_g10_test_kit/visual_inspection_and_attestations_group.rb +7 -6
- data/lib/onc_certification_g10_test_kit.rb +15 -82
- metadata +14 -10
|
@@ -0,0 +1,1451 @@
|
|
|
1
|
+
procedure:
|
|
2
|
+
- section: Paragraph (g)(10)(iii) - Application registration
|
|
3
|
+
steps:
|
|
4
|
+
- group: Application Registration
|
|
5
|
+
id: APP-REGISTRATION-1
|
|
6
|
+
SUT: |
|
|
7
|
+
The health IT developer demonstrates the Health IT Module supports
|
|
8
|
+
application registration with an authorization server for the purposes
|
|
9
|
+
of Electronic Health Information (EHI) access for single patients,
|
|
10
|
+
including support for application registration functions to enable
|
|
11
|
+
authentication and authorization in § 170.315(g)(10)(v).
|
|
12
|
+
TLV: |
|
|
13
|
+
The tester verifies the Health IT Module supports application
|
|
14
|
+
registration with an authorization server for the purposes of EHI
|
|
15
|
+
access for single patients, including support for application
|
|
16
|
+
registration functions to enable authentication and authorization in §
|
|
17
|
+
170.315(g)(10)(v).
|
|
18
|
+
inferno_tests:
|
|
19
|
+
- 6.6.01
|
|
20
|
+
inferno_supported: 'yes'
|
|
21
|
+
inferno_notes: |
|
|
22
|
+
This requires a visual inspection and attestation because it is not
|
|
23
|
+
possible to automate without any standard method required for application
|
|
24
|
+
registration.
|
|
25
|
+
- id: APP-REGISTRATION-2
|
|
26
|
+
SUT: |
|
|
27
|
+
The health IT developer demonstrates the Health IT Module supports
|
|
28
|
+
application registration with an authorization server for the purposes
|
|
29
|
+
of EHI access for multiple patients including support for application
|
|
30
|
+
registration functions to enable authentication and authorization in §
|
|
31
|
+
170.315(g)(10)(v).
|
|
32
|
+
TLV: |
|
|
33
|
+
The tester verifies the Health IT Module supports application
|
|
34
|
+
registration with an authorization server for the purposes of EHI
|
|
35
|
+
access for multiple patients including support for application
|
|
36
|
+
registration functions to enable authentication and authorization in §
|
|
37
|
+
170.315(g)(10)(v).
|
|
38
|
+
inferno_tests:
|
|
39
|
+
- 6.6.02
|
|
40
|
+
inferno_supported: 'yes'
|
|
41
|
+
inferno_notes: |
|
|
42
|
+
This requires a visual inspection and attestation because it is not
|
|
43
|
+
possible to automate without any standard method required for application
|
|
44
|
+
registration.
|
|
45
|
+
- section: Paragraph (g)(10)(iv) – Secure connection
|
|
46
|
+
steps:
|
|
47
|
+
- group: Secure connection
|
|
48
|
+
id: SECURE-CONNECTION-1
|
|
49
|
+
SUT: |
|
|
50
|
+
For all transmissions between the Health IT Module and the
|
|
51
|
+
application, the health IT developer demonstrates the use of a
|
|
52
|
+
secure and trusted connection in accordance with the
|
|
53
|
+
implementation specifications adopted in § 170.215(a)(2) and §
|
|
54
|
+
170.215(a)(3), including:
|
|
55
|
+
* Using TLS version 1.2 or higher; and
|
|
56
|
+
* Conformance to FHIR Communications Security requirements.
|
|
57
|
+
TLV: |
|
|
58
|
+
For all transmissions between the Health IT Module and the
|
|
59
|
+
application, the tester verifies the use of a secure and trusted
|
|
60
|
+
connection in accordance with the implementation specifications
|
|
61
|
+
adopted in § 170.215(a)(2) and § 170.215(a)(3), including:
|
|
62
|
+
* Using TLS version 1.2 or higher; and
|
|
63
|
+
* Conformance to FHIR Communications Security requirements.
|
|
64
|
+
inferno_supported: 'yes'
|
|
65
|
+
inferno_tests:
|
|
66
|
+
- 1.2.01
|
|
67
|
+
- 1.2.04
|
|
68
|
+
- 2.1.01
|
|
69
|
+
- 2.1.04
|
|
70
|
+
- 3.2.03
|
|
71
|
+
- 3.2.06
|
|
72
|
+
- 4.1.01
|
|
73
|
+
- 5.1.01
|
|
74
|
+
- 5.2.01
|
|
75
|
+
- 5.3.01
|
|
76
|
+
- 6.1.01
|
|
77
|
+
- 6.1.04
|
|
78
|
+
inferno_notes: |
|
|
79
|
+
Inferno tests that all endpoints provided support at least TLS
|
|
80
|
+
version 1.2, and rejects all requests for TLS version 1.1 or below.
|
|
81
|
+
This includes all FHIR endpoints (if more than one is provided), as
|
|
82
|
+
well as authorization endpoints required by SMART. Inferno can be
|
|
83
|
+
configured to disable TLS testing if configuring TLS within a
|
|
84
|
+
lab environment is not possible. Note that there are no SHALL
|
|
85
|
+
requirements within the "FHIR Communications Security Requirements" in
|
|
86
|
+
FHIR R4, and therefore there are no tests based on this requirement.
|
|
87
|
+
- section: Paragraph (g)(10)(v)(A) – Authentication and authorization for patient and user scopes
|
|
88
|
+
steps:
|
|
89
|
+
- group: Authentication and Authorization for Patient and User Scopes
|
|
90
|
+
id: AUTH-PATIENT-1
|
|
91
|
+
SUT: |
|
|
92
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
93
|
+
Module to support the following for “EHR-Launch,” “StandaloneLaunch,”
|
|
94
|
+
and “Both” (“EHR-Launch” and “Standalone-Launch”) as
|
|
95
|
+
specified in the implementation specification adopted in §
|
|
96
|
+
170.215(a)(3).
|
|
97
|
+
TLV: |
|
|
98
|
+
The tester verifies the ability of the Health IT Module to support
|
|
99
|
+
the following for “EHR-Launch,” “Standalone-Launch,” and “Both”
|
|
100
|
+
(“EHR-Launch” and “Standalone-Launch”) as specified in the
|
|
101
|
+
implementation specification adopted in § 170.215(a)(3).
|
|
102
|
+
inferno_supported: 'yes'
|
|
103
|
+
inferno_tests:
|
|
104
|
+
- 1.2.01 - 1.2.07
|
|
105
|
+
- 3.2.01 - 3.2.09
|
|
106
|
+
inferno_notes: |
|
|
107
|
+
Complete demonstration of these capabilities are accomplished
|
|
108
|
+
through subsequent steps in the test procedure.
|
|
109
|
+
- id: AUTH-PATIENT-2
|
|
110
|
+
SUT: |
|
|
111
|
+
[EHR-Launch] The health IT developer demonstrates the ability of
|
|
112
|
+
the Health IT Module to initiate a “launch sequence” using the
|
|
113
|
+
“launch-ehr" “SMART on FHIR Core Capability” SMART EHR Launch
|
|
114
|
+
mode detailed in the implementation specification adopted in §
|
|
115
|
+
170.215(a)(3), including:
|
|
116
|
+
* Launching the registered launch URL of the application; and
|
|
117
|
+
* Passing the parameters: “iss” and “launch”.
|
|
118
|
+
TLV: |
|
|
119
|
+
[EHR-Launch] The tester verifies the ability of the Health IT
|
|
120
|
+
Module to initiate a “launch sequence” using the “launch-ehr"
|
|
121
|
+
“SMART on FHIR Core Capability” SMART EHR Launch mode
|
|
122
|
+
detailed in the implementation specification adopted in §
|
|
123
|
+
170.215(a)(3), including:
|
|
124
|
+
* Launching the registered launch URL of the application; and
|
|
125
|
+
* Passing the parameters: “iss” and “launch”.
|
|
126
|
+
inferno_supported: 'yes'
|
|
127
|
+
inferno_tests:
|
|
128
|
+
- 3.2.01 - 3.2.02
|
|
129
|
+
- 3.2.04
|
|
130
|
+
- id: AUTH-PATIENT-3
|
|
131
|
+
SUT: |
|
|
132
|
+
[Standalone-Launch] The health IT developer demonstrates the
|
|
133
|
+
ability of the Health IT Module to launch using the “launch-standalone"
|
|
134
|
+
"SMART on FHIR Core Capability" SMART Standalone
|
|
135
|
+
Launch mode detailed in the implementation specification
|
|
136
|
+
adopted in § 170.215(a)(3).
|
|
137
|
+
TLV: |
|
|
138
|
+
[Standalone-Launch] The tester verifies the ability of the Health IT
|
|
139
|
+
Module to launch using the “launch-standalone" “SMART on FHIR
|
|
140
|
+
Core Capability” SMART Standalone Launch mode detailed in the
|
|
141
|
+
implementation specification adopted in § 170.215(a)(3).
|
|
142
|
+
inferno_supported: 'yes'
|
|
143
|
+
inferno_tests:
|
|
144
|
+
- 1.2.02
|
|
145
|
+
- id: AUTH-PATIENT-4
|
|
146
|
+
SUT: |
|
|
147
|
+
[Standalone-Launch] The health IT developer demonstrates the ability
|
|
148
|
+
of the Health IT Module to support SMART’s public client profile.
|
|
149
|
+
TLV: |
|
|
150
|
+
[Standalone-Launch] The tester verifies the ability of the Health IT
|
|
151
|
+
Module to support SMART’s public client profile.
|
|
152
|
+
inferno_supported: 'yes'
|
|
153
|
+
inferno_tests:
|
|
154
|
+
- 6.1.02 - 6.1.03
|
|
155
|
+
- 6.1.05 - 6.1.09
|
|
156
|
+
- id: AUTH-PATIENT-5
|
|
157
|
+
SUT: |
|
|
158
|
+
[Both] The health IT developer demonstrates the ability of the
|
|
159
|
+
Health IT Module to support the following as detailed in the
|
|
160
|
+
implementation specification adopted in § 170.215(a)(3) and
|
|
161
|
+
standard adopted in § 170.215(a)(1):
|
|
162
|
+
* The “.well-known/smart-configuration.json” path; and
|
|
163
|
+
* A FHIR “CapabilityStatement”.
|
|
164
|
+
TLV: |
|
|
165
|
+
[Both] The tester verifies the ability of the Health IT Module to
|
|
166
|
+
support the following as detailed in the implementation
|
|
167
|
+
specification adopted in § 170.215(a)(3) and standard adopted in §
|
|
168
|
+
170.215(a)(1):
|
|
169
|
+
* The “.well-known/smart-configuration.json” path; and
|
|
170
|
+
* A FHIR “CapabilityStatement”.
|
|
171
|
+
inferno_supported: 'yes'
|
|
172
|
+
inferno_tests:
|
|
173
|
+
- 1.1.01 - 1.1.03
|
|
174
|
+
- 3.1.01 - 3.1.03
|
|
175
|
+
- id: AUTH-PATIENT-6
|
|
176
|
+
SUT: |
|
|
177
|
+
[Both] The health IT developer demonstrates the ability of the
|
|
178
|
+
“.well-known/smart-configuration.json” path to support at least
|
|
179
|
+
the following as detailed in the implementation specification
|
|
180
|
+
adopted in § 170.215(a)(3):
|
|
181
|
+
* “authorization_endpoint”;
|
|
182
|
+
* “token_endpoint”; and
|
|
183
|
+
* “capabilities” (including support for all the “SMART on FHIR Core Capabilities”).
|
|
184
|
+
TLV: |
|
|
185
|
+
[Both] The tester verifies the ability of the “.well-known/smartconfiguration.json”
|
|
186
|
+
path to support at least the following as detailed in the implementation specification
|
|
187
|
+
adopted in § 170.215(a)(3):
|
|
188
|
+
* “authorization_endpoint”;
|
|
189
|
+
* “token_endpoint”; and
|
|
190
|
+
* “capabilities” (including support for all the “SMART on FHIR Core Capabilities”).
|
|
191
|
+
inferno_supported: 'yes'
|
|
192
|
+
inferno_tests:
|
|
193
|
+
- 1.1.02
|
|
194
|
+
- 1.1.04 - 1.1.05
|
|
195
|
+
- 3.1.02
|
|
196
|
+
- 3.1.04 - 3.1.05
|
|
197
|
+
inferno_notes: |
|
|
198
|
+
Inferno additionally checks that the "authorization endpoint" and the
|
|
199
|
+
"token endpoint" are consistent between the Capability Statement and
|
|
200
|
+
the well-known endpoint.
|
|
201
|
+
- id: AUTH-PATIENT-7
|
|
202
|
+
SUT: |
|
|
203
|
+
[Both] The health IT developer demonstrates the ability of the
|
|
204
|
+
FHIR “CapabilityStatement” to support at least the following
|
|
205
|
+
components as detailed in the implementation specification
|
|
206
|
+
adopted in § 170.215(a)(3) and standard adopted in §
|
|
207
|
+
170.215(a)(1), including:
|
|
208
|
+
* “authorize”; and
|
|
209
|
+
* “token”.
|
|
210
|
+
TLV: |
|
|
211
|
+
[Both] The tester verifies the ability of the FHIR
|
|
212
|
+
“CapabilityStatement” to support at least the following
|
|
213
|
+
components as detailed in the implementation specification
|
|
214
|
+
adopted in § 170.215(a)(3) and standard adopted in §
|
|
215
|
+
170.215(a)(1), including:
|
|
216
|
+
* “authorize”; and
|
|
217
|
+
* “token”.
|
|
218
|
+
inferno_supported: 'yes'
|
|
219
|
+
inferno_tests:
|
|
220
|
+
- 1.1.03 - 1.1.04
|
|
221
|
+
- 3.1.03 - 3.1.04
|
|
222
|
+
inferno_notes: |
|
|
223
|
+
Inferno additionally checks that the "authorization endpoint" and the
|
|
224
|
+
"token endpoint" are consistent between the Capability Statement and
|
|
225
|
+
the well-known endpoint.
|
|
226
|
+
- id: AUTH-PATIENT-8
|
|
227
|
+
SUT: |
|
|
228
|
+
[Both] The health IT developer demonstrates the ability of the
|
|
229
|
+
Health IT Module to receive an authorization request according to
|
|
230
|
+
the implementation specification adopted in § 170.215(a)(3),
|
|
231
|
+
including support for the following parameters:
|
|
232
|
+
* “response_type”;
|
|
233
|
+
* “client_id”;
|
|
234
|
+
* “redirect_uri”;
|
|
235
|
+
* “launch” (for EHR-Launch mode only);
|
|
236
|
+
* “scope”;
|
|
237
|
+
* “state”; and
|
|
238
|
+
* “aud”.
|
|
239
|
+
TLV: |
|
|
240
|
+
[Both] The tester verifies the ability of the Health IT Module to
|
|
241
|
+
receive an authorization request according to the implementation
|
|
242
|
+
specification adopted in § 170.215(a)(3), including support for the
|
|
243
|
+
following parameters:
|
|
244
|
+
* “response_type”;
|
|
245
|
+
* “client_id”;
|
|
246
|
+
* “redirect_uri”;
|
|
247
|
+
* “launch” (for EHR-Launch mode only);
|
|
248
|
+
* “scope”;
|
|
249
|
+
* “state”; and
|
|
250
|
+
* “aud”.
|
|
251
|
+
inferno_supported: 'yes'
|
|
252
|
+
inferno_tests:
|
|
253
|
+
- 1.2.02 - 1.2.03
|
|
254
|
+
- 3.2.04 - 3.2.05
|
|
255
|
+
- id: AUTH-PATIENT-9
|
|
256
|
+
SUT: |
|
|
257
|
+
[Both] The health IT developer demonstrates the ability of the Health
|
|
258
|
+
IT Module to support the receipt of the following scopes and
|
|
259
|
+
capabilities according to the implementation specification adopted in
|
|
260
|
+
§ 170.215(a)(3) and standard adopted in § 170.215(b):
|
|
261
|
+
* “openid” (to support “sso-openid-connect” “SMART on FHIR Core Capability”);
|
|
262
|
+
* “fhirUser” (to support “sso-openid-connect” “SMART on FHIR Core Capability”);
|
|
263
|
+
* “need_patient_banner” (to support “context-banner” “SMART on FHIR Core Capability” for EHR-Launch mode only);
|
|
264
|
+
* “smart_style_url” (to support “context-style” “SMART on FHIR Core Capability” for EHR-Launch mode only);
|
|
265
|
+
* “launch/patient” (to support “context-standalone-patient” “SMART on FHIR Core Capability” for Standalone-Launch mode only);
|
|
266
|
+
* “launch” (for EHR-Launch mode only);
|
|
267
|
+
* “offline_access” (to support “permission-offline” “SMART on FHIR Core Capability”);
|
|
268
|
+
* Patient-level scopes(to support “permission-patient” “SMART on FHIR Core Capability”); and
|
|
269
|
+
* User-level scopes (to support “permission-user” “SMART on FHIR Core Capability”).
|
|
270
|
+
TLV: |
|
|
271
|
+
[Both] The tester verifies the ability of the Health IT Module to
|
|
272
|
+
support the receipt of the following scopes and capabilities according
|
|
273
|
+
to the implementation specification adopted in § 170.215(a)(3) and
|
|
274
|
+
standard adopted in § 170.215(b):
|
|
275
|
+
* “openid” (to support “sso-openid-connect” “SMART on FHIR Core Capability”);
|
|
276
|
+
* “fhirUser” (to support “sso-openid-connect” “SMART on FHIR Core Capability”);
|
|
277
|
+
* “need_patient_banner” (to support “context-banner” “SMART on FHIR Core Capability” for EHR-Launch mode only);
|
|
278
|
+
* “smart_style_url” (to support “context-style” “SMART on FHIR Core Capability” for EHR-Launch mode only);
|
|
279
|
+
* “launch/patient” (to support “context-standalone-patient” “SMART on FHIR Core Capability” for Standalone-Launch mode only);
|
|
280
|
+
* “launch” (for EHR-Launch mode only);
|
|
281
|
+
* “offline_access” (to support “permission-offline” “SMART on FHIR Core Capability”);
|
|
282
|
+
* Patient-level scopes (to support “permission-patient” “SMART on FHIR Core Capability”); and
|
|
283
|
+
* User-level scopes (to support “permission-user” “SMART on FHIR Core Capability”).
|
|
284
|
+
inferno_supported: 'yes'
|
|
285
|
+
inferno_tests:
|
|
286
|
+
- 1.2.02
|
|
287
|
+
- 3.2.05
|
|
288
|
+
inferno_notes: |
|
|
289
|
+
This step refers to only the receipt of these scopes, which is covered in
|
|
290
|
+
Inferno in one step in each the EHR and Standalone launch cases. However,
|
|
291
|
+
it is not possible to tell if these scopes were properly granted until
|
|
292
|
+
verifying that the client has access to perform the necessary steps.
|
|
293
|
+
Inferno does this as well, but this mapping only refers to the 'receipt' portion
|
|
294
|
+
of the launch process.
|
|
295
|
+
- id: AUTH-PATIENT-10
|
|
296
|
+
SUT: |
|
|
297
|
+
[Both] The health IT developer demonstrates the ability of the
|
|
298
|
+
Health IT Module to evaluate the authorization request and
|
|
299
|
+
request end-user input, if applicable (required for patient-facing
|
|
300
|
+
applications), including the ability for the end-user to authorize an
|
|
301
|
+
application to receive Electronic Health Information (EHI) based
|
|
302
|
+
on FHIR resource-level scopes for all of the FHIR resources
|
|
303
|
+
associated with the profiles specified in the standard adopted in
|
|
304
|
+
§ 170.213 and implementation specification adopted in
|
|
305
|
+
§ 170.215(a)(2), including:
|
|
306
|
+
* "AllergyIntolerance";
|
|
307
|
+
* "CarePlan";
|
|
308
|
+
* "CareTeam";
|
|
309
|
+
* "Condition";
|
|
310
|
+
* "Device";
|
|
311
|
+
* "DiagnosticReport";
|
|
312
|
+
* "DocumentReference";
|
|
313
|
+
* "Goal";
|
|
314
|
+
* "Immunization";
|
|
315
|
+
* "Medication" (if supported);
|
|
316
|
+
* "MedicationRequest";
|
|
317
|
+
* "Observation";
|
|
318
|
+
* "Patient";
|
|
319
|
+
* "Procedure"; and
|
|
320
|
+
* "Provenance".
|
|
321
|
+
TLV: |
|
|
322
|
+
[Both] The tester verifies the ability of the
|
|
323
|
+
Health IT Module to evaluate the authorization request and
|
|
324
|
+
request end-user input, if applicable (required for patient-facing
|
|
325
|
+
applications), including the ability for the end-user to authorize an
|
|
326
|
+
application to receive Electronic Health Information (EHI) based
|
|
327
|
+
on FHIR resource-level scopes for all of the FHIR resources
|
|
328
|
+
associated with the profiles specified in the standard adopted in
|
|
329
|
+
§ 170.213 and implementation specification adopted in
|
|
330
|
+
§ 170.215(a)(2), including:
|
|
331
|
+
* "AllergyIntolerance";
|
|
332
|
+
* "CarePlan";
|
|
333
|
+
* "CareTeam";
|
|
334
|
+
* "Condition";
|
|
335
|
+
* "Device";
|
|
336
|
+
* "DiagnosticReport";
|
|
337
|
+
* "DocumentReference";
|
|
338
|
+
* "Goal";
|
|
339
|
+
* "Immunization";
|
|
340
|
+
* "Medication" (if supported);
|
|
341
|
+
* "MedicationRequest";
|
|
342
|
+
* "Observation";
|
|
343
|
+
* "Patient";
|
|
344
|
+
* "Procedure"; and
|
|
345
|
+
* "Provenance".
|
|
346
|
+
inferno_supported: 'yes'
|
|
347
|
+
inferno_tests:
|
|
348
|
+
- 1.2.02
|
|
349
|
+
- 1.2.05
|
|
350
|
+
- 3.2.04
|
|
351
|
+
- 3.2.07
|
|
352
|
+
- 2.1.02
|
|
353
|
+
- 2.1.05
|
|
354
|
+
- 1.5.01 - 1.5.14
|
|
355
|
+
- 2.2.01 - 2.2.13
|
|
356
|
+
inferno_notes: |
|
|
357
|
+
Inferno verifies that end-user input is requested by requiring one app
|
|
358
|
+
launch have complete access to required resources and having one app
|
|
359
|
+
launch have limited access based on the preferences of the tester.
|
|
360
|
+
- id: AUTH-PATIENT-11
|
|
361
|
+
SUT: |
|
|
362
|
+
[Both] The health IT developer demonstrates the ability of the
|
|
363
|
+
Health IT Module to evaluate the authorization request and request
|
|
364
|
+
end-user input, if applicable (required for patient-facing
|
|
365
|
+
applications), including either the ability for the end-user to
|
|
366
|
+
explicitly enable / disable the “offline_access” scope or
|
|
367
|
+
information communicating the application’s request for the
|
|
368
|
+
“offline_access” scope.
|
|
369
|
+
TLV: |
|
|
370
|
+
[Both] The tester verifies the ability of the Health IT Module to
|
|
371
|
+
evaluate the authorization request and request end-user input, if
|
|
372
|
+
applicable (required for patient-facing applications), including
|
|
373
|
+
either the ability for the end-user to explicitly enable / disable
|
|
374
|
+
the “offline_access” scope or information communicating the
|
|
375
|
+
application’s request for the “offline_access” scope.
|
|
376
|
+
inferno_supported: 'yes'
|
|
377
|
+
inferno_tests:
|
|
378
|
+
- 1.2.02
|
|
379
|
+
- 1.2.05
|
|
380
|
+
- 2.1.02
|
|
381
|
+
- 2.1.05
|
|
382
|
+
- 1.5.01 - 1.5.14
|
|
383
|
+
- 2.2.01 - 2.2.13
|
|
384
|
+
inferno_notes: |
|
|
385
|
+
Inferno verifies that end-user input is requested by requiring one app
|
|
386
|
+
launch have complete access to required resources and having one app
|
|
387
|
+
launch have limited access based on the preferences of the tester.
|
|
388
|
+
Inferno requests full resource and 'offline_access' access, and the tester
|
|
389
|
+
is expected to select the correct subset of resources and deny 'offline_access'
|
|
390
|
+
based on previously selected preferences.
|
|
391
|
+
- id: AUTH-PATIENT-12
|
|
392
|
+
SUT: |
|
|
393
|
+
[Both] The health IT developer demonstrates the ability of the Health
|
|
394
|
+
IT Module to deny an application’s authorization request according to
|
|
395
|
+
a patient’s preferences selected in steps 10 and 11 of this section in
|
|
396
|
+
accordance with the implementation specification adopted in §
|
|
397
|
+
170.215(a)(3).
|
|
398
|
+
TLV: |
|
|
399
|
+
[Both] The tester verifies the ability of the Health IT Module to deny
|
|
400
|
+
an application’s authorization request according to a patient’s
|
|
401
|
+
preferences selected in steps 10 and 11 of this section in accordance
|
|
402
|
+
with the implementation specification adopted in § 170.215(a)(3).
|
|
403
|
+
inferno_supported: 'yes'
|
|
404
|
+
inferno_tests:
|
|
405
|
+
- 1.2.02
|
|
406
|
+
- 1.2.05
|
|
407
|
+
- 2.1.02
|
|
408
|
+
- 2.1.05
|
|
409
|
+
- 1.5.01 - 1.5.14
|
|
410
|
+
- 2.2.01 - 2.2.13
|
|
411
|
+
inferno_notes: |
|
|
412
|
+
Inferno verifies that end-user input is requested by requiring one app
|
|
413
|
+
launch have complete access to required resources and having one app
|
|
414
|
+
launch have limited access based on the preferences of the tester.
|
|
415
|
+
Inferno requests full resource and 'offline_access' access, and the tester
|
|
416
|
+
is expected to select the correct subset of resources and deny 'offline_access'
|
|
417
|
+
based on previously selected preferences.
|
|
418
|
+
- id: AUTH-PATIENT-13
|
|
419
|
+
SUT: |
|
|
420
|
+
[Both] The health IT developer demonstrates the ability of
|
|
421
|
+
the Health IT Module to return an error response if the following
|
|
422
|
+
parameters provided by an application to the Health IT Module in
|
|
423
|
+
step 8 of this section do not match the parameters originally
|
|
424
|
+
provided to an application by the Health IT Module in step 2 of
|
|
425
|
+
this section according to the implementation specification
|
|
426
|
+
adopted in § 170.215(a)(3):
|
|
427
|
+
* “launch”; and
|
|
428
|
+
* “aud”.
|
|
429
|
+
TLV: |
|
|
430
|
+
[Both] The tester verifies the ability of the Health IT
|
|
431
|
+
Module to return an error response if the following parameters
|
|
432
|
+
provided by an application to the Health IT Module in step 8 of
|
|
433
|
+
this section do not match the parameters originally provided to an
|
|
434
|
+
application by the Health IT Module in step 2 of this section
|
|
435
|
+
according to the implementation specification adopted in §
|
|
436
|
+
170.215(a)(3):
|
|
437
|
+
* “launch”; and
|
|
438
|
+
* “aud”.
|
|
439
|
+
inferno_supported: 'yes'
|
|
440
|
+
inferno_tests:
|
|
441
|
+
- 6.3.01 - 6.3.02
|
|
442
|
+
- 6.4.01 - 6.4.04
|
|
443
|
+
- id: AUTH-PATIENT-14
|
|
444
|
+
SUT: |
|
|
445
|
+
[Both] The health IT developer demonstrates the ability of the
|
|
446
|
+
Health IT Module to grant an application access to EHI by
|
|
447
|
+
returning an authorization code to the application according to
|
|
448
|
+
the implementation specification adopted in § 170.215(a)(3),
|
|
449
|
+
including the following parameters:
|
|
450
|
+
* “code”; and
|
|
451
|
+
* “state”.
|
|
452
|
+
TLV: |
|
|
453
|
+
[Both] The tester verifies the ability of the
|
|
454
|
+
Health IT Module to grant an application access to EHI by
|
|
455
|
+
returning an authorization code to the application according to
|
|
456
|
+
the implementation specification adopted in § 170.215(a)(3),
|
|
457
|
+
including the following parameters:
|
|
458
|
+
* “code”; and
|
|
459
|
+
* “state”.
|
|
460
|
+
inferno_supported: 'yes'
|
|
461
|
+
inferno_tests:
|
|
462
|
+
- 1.2.03
|
|
463
|
+
- 3.2.05
|
|
464
|
+
- id: AUTH-PATIENT-15
|
|
465
|
+
SUT: |
|
|
466
|
+
[Both] The health IT developer demonstrates the ability of the
|
|
467
|
+
Health IT Module to receive the following parameters from an
|
|
468
|
+
application according to the implementation specification adopted
|
|
469
|
+
in § 170.215(a)(3):
|
|
470
|
+
* “grant_type”;
|
|
471
|
+
* “code”;
|
|
472
|
+
* “redirect_uri”;
|
|
473
|
+
* “client_id”; and
|
|
474
|
+
* Authorization header including “client_id” and "client_secret"
|
|
475
|
+
TLV: |
|
|
476
|
+
[Both] The tester verifies the ability of the
|
|
477
|
+
Health IT Module to receive the following parameters from an
|
|
478
|
+
application according to the implementation specification adopted
|
|
479
|
+
in § 170.215(a)(3):
|
|
480
|
+
* “grant_type”;
|
|
481
|
+
* “code”;
|
|
482
|
+
* “redirect_uri”;
|
|
483
|
+
* “client_id”; and
|
|
484
|
+
* Authorization header including “client_id” and "client_secret"
|
|
485
|
+
inferno_supported: 'yes'
|
|
486
|
+
inferno_tests:
|
|
487
|
+
- 1.2.05
|
|
488
|
+
- 3.2.07
|
|
489
|
+
inferno_notes: |
|
|
490
|
+
"client_secret" is only provided in the case of confidential clients.
|
|
491
|
+
- id: AUTH-PATIENT-16
|
|
492
|
+
SUT: |
|
|
493
|
+
[Both] The health IT developer demonstrates the ability of the
|
|
494
|
+
Health IT Module to return a JSON object to applications according
|
|
495
|
+
to the implementation specification adopted in § 170.215(a)(3)
|
|
496
|
+
and standard adopted in § 170.215(b), including the following:
|
|
497
|
+
* “access_token”;
|
|
498
|
+
* “token_type”;
|
|
499
|
+
* “scope”;
|
|
500
|
+
* “id_token”;
|
|
501
|
+
* “refresh_token” (valid for a period of no shorter than three months);
|
|
502
|
+
* HTTP “Cache-Control” response header field with a value of “no-store”;
|
|
503
|
+
* HTTP “Pragma” response header field with a value of “nocache”;
|
|
504
|
+
* “patient” (to support “context-ehr-patient” and “contextstandalone-patient” “SMART on FHIR Core Capabilities”);
|
|
505
|
+
* “need_patient_banner” (to support “context-banner” “SMART on FHIR Core Capability” for EHR-Launch mode only); and
|
|
506
|
+
* “smart_style_url” (to support “context-style” “SMART on FHIR Core Capability” for EHR-Launch mode only).
|
|
507
|
+
TLV: |
|
|
508
|
+
[Both] The tester verifies the ability of the
|
|
509
|
+
Health IT Module to return a JSON object to applications according
|
|
510
|
+
to the implementation specification adopted in § 170.215(a)(3)
|
|
511
|
+
and standard adopted in § 170.215(b), including the following:
|
|
512
|
+
* “access_token”;
|
|
513
|
+
* “token_type”;
|
|
514
|
+
* “scope”;
|
|
515
|
+
* “id_token”;
|
|
516
|
+
* “refresh_token” (valid for a period of no shorter than three months);
|
|
517
|
+
* HTTP “Cache-Control” response header field with a value of “no-store”;
|
|
518
|
+
* HTTP “Pragma” response header field with a value of “nocache”;
|
|
519
|
+
* “patient” (to support “context-ehr-patient” and “contextstandalone-patient” “SMART on FHIR Core Capabilities”);
|
|
520
|
+
* “need_patient_banner” (to support “context-banner” “SMART on FHIR Core Capability” for EHR-Launch mode only); and
|
|
521
|
+
* “smart_style_url” (to support “context-style” “SMART on FHIR Core Capability” for EHR-Launch mode only).
|
|
522
|
+
inferno_supported: 'yes'
|
|
523
|
+
inferno_tests:
|
|
524
|
+
- 1.2.06 - 1.2.07
|
|
525
|
+
- 3.2.08 - 3.2.09
|
|
526
|
+
- id: AUTH-PATIENT-17
|
|
527
|
+
SUT: |
|
|
528
|
+
[Both] The health IT developer demonstrates the ability of the
|
|
529
|
+
Health IT Module to provide an OpenID Connect well-known URI in
|
|
530
|
+
accordance with the implementation specification adopted in §
|
|
531
|
+
170.215(b), including:
|
|
532
|
+
* All required fields populated according to implementation specification adopted in § 170.215(b)
|
|
533
|
+
* Valid JWKS populated according to implementation specification can be retrieved via JWKS URI
|
|
534
|
+
TLV: |
|
|
535
|
+
[Both] The tester verfies the ability of the Health IT Module to
|
|
536
|
+
provide an OpenID Connect well-known URI in accordance with the
|
|
537
|
+
implementation specification adopted in § 170.215(b), including:
|
|
538
|
+
* All required fields populated according to implementation specification adopted in § 170.215(b)
|
|
539
|
+
* Valid JWKS populated according to implementation specification can be retrieved via JWKS URI
|
|
540
|
+
inferno_supported: 'yes'
|
|
541
|
+
inferno_tests:
|
|
542
|
+
- 1.3.01 - 1.3.07
|
|
543
|
+
- 3.3.01 - 3.3.07
|
|
544
|
+
inferno_notes: |
|
|
545
|
+
Inferno decodes the id_token provided during authentication and
|
|
546
|
+
verifies that it contains the correct claims, has a valid signature,
|
|
547
|
+
and the fhirUser claim contains a reference to the current user that
|
|
548
|
+
can be retreived using the bearer token provided during the application launch.
|
|
549
|
+
- id: AUTH-PATIENT-18
|
|
550
|
+
SUT: |
|
|
551
|
+
[Both] The health IT developer demonstrates the ability of the
|
|
552
|
+
Health IT Module to deny an application’s authorization request in
|
|
553
|
+
accordance with the implementation specification adopted in §
|
|
554
|
+
170.215(a)(3).
|
|
555
|
+
TLV: |
|
|
556
|
+
[Both] The tester demonstrates the ability of the
|
|
557
|
+
Health IT Module to deny an application’s authorization request in
|
|
558
|
+
accordance with the implementation specification adopted in §
|
|
559
|
+
170.215(a)(3).
|
|
560
|
+
inferno_supported: 'yes'
|
|
561
|
+
inferno_notes: |
|
|
562
|
+
Inferno verifies that the user has the ability to explicitly authorize
|
|
563
|
+
apps to appropriate resources and capabilities. Inferno also verifies
|
|
564
|
+
that apps that send invalid information during the authorization process
|
|
565
|
+
are denied.
|
|
566
|
+
inferno_tests:
|
|
567
|
+
- 2.1.02 - 2.1.09
|
|
568
|
+
- 2.2.01 - 2.2.13
|
|
569
|
+
- 6.5.01 - 6.5.04
|
|
570
|
+
- id: AUTH-PATIENT-19
|
|
571
|
+
SUT: |
|
|
572
|
+
[Standalone-Launch] The health IT developer the ability of the Health IT
|
|
573
|
+
Module to return a “Patient” FHIR resource that matches the
|
|
574
|
+
patient context provided in step 9 of this section according to the
|
|
575
|
+
implementation specification adopted in § 170.215(a)(2).
|
|
576
|
+
TLV: |
|
|
577
|
+
[Standalone-Launch] The tester verifies the ability of the Health IT
|
|
578
|
+
Module to return a “Patient” FHIR resource that matches the
|
|
579
|
+
patient context provided in step 9 of this section according to the
|
|
580
|
+
implementation specification adopted in § 170.215(a)(2).
|
|
581
|
+
inferno_supported: 'yes'
|
|
582
|
+
inferno_tests:
|
|
583
|
+
- 1.2.08
|
|
584
|
+
- 3.2.12
|
|
585
|
+
- id: AUTH-PATIENT-20
|
|
586
|
+
SUT: |
|
|
587
|
+
[Both] The health IT developer demonstrates the ability of the
|
|
588
|
+
Health IT Module to grant an access token when a refresh token is
|
|
589
|
+
supplied according to the implementation specification adopted in
|
|
590
|
+
§ 170.215(a)(2).
|
|
591
|
+
TLV: |
|
|
592
|
+
[Both] The health IT developer demonstrates the ability of the
|
|
593
|
+
Health IT Module to grant an access token when a refresh token is
|
|
594
|
+
supplied according to the implementation specification adopted in
|
|
595
|
+
§ 170.215(a)(2).
|
|
596
|
+
inferno_supported: 'yes'
|
|
597
|
+
inferno_tests:
|
|
598
|
+
- 1.4.03 - 1.4.05
|
|
599
|
+
- 3.4.05 - 3.4.05
|
|
600
|
+
- id: AUTH-PATIENT-21
|
|
601
|
+
SUT: |
|
|
602
|
+
[Both] The health IT developer demonstrates the ability of the
|
|
603
|
+
Health IT Module to grant a refresh token valid for a period of no
|
|
604
|
+
less than three months to native applications capable of storing a
|
|
605
|
+
refresh token.
|
|
606
|
+
TLV: |
|
|
607
|
+
[Both] The tester verifies the ability of the Health IT Module to
|
|
608
|
+
grant a refresh token valid for a period of no less than three
|
|
609
|
+
months to native applications capable of storing a refresh token.
|
|
610
|
+
inferno_supported: 'yes'
|
|
611
|
+
inferno_tests:
|
|
612
|
+
- 6.6.13
|
|
613
|
+
- group: 'Subsequent Connections: Authentication and Authorization for Patient and User Scopes'
|
|
614
|
+
id: AUTH-PATIENT-22
|
|
615
|
+
SUT: |
|
|
616
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
617
|
+
Module to issue a new refresh token valid for a new period of no
|
|
618
|
+
shorter than three months without requiring re-authentication
|
|
619
|
+
and re-authorization when a valid refresh token is supplied by the
|
|
620
|
+
application according to the implementation specification adopted
|
|
621
|
+
in § 170.215(a)(3).
|
|
622
|
+
TLV: |
|
|
623
|
+
The tester verifies the ability of the Health IT
|
|
624
|
+
Module to issue a new refresh token valid for a new period of no
|
|
625
|
+
shorter than three months without requiring re-authentication
|
|
626
|
+
and re-authorization when a valid refresh token is supplied by the
|
|
627
|
+
application according to the implementation specification adopted
|
|
628
|
+
in § 170.215(a)(3).
|
|
629
|
+
inferno_supported: 'yes'
|
|
630
|
+
inferno_tests:
|
|
631
|
+
- 6.6.05
|
|
632
|
+
inferno_notes: |
|
|
633
|
+
Inferno cannot verify the three month token expiration requirement
|
|
634
|
+
automatically during the token refresh tests, but the tester can
|
|
635
|
+
register an attestation that this requirement is met.
|
|
636
|
+
- id: AUTH-PATIENT-23
|
|
637
|
+
SUT: |
|
|
638
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
639
|
+
Module to return an error response when supplied an invalid
|
|
640
|
+
refresh token as specified in the implementation specification
|
|
641
|
+
adopted in § 170.215(a)(3).
|
|
642
|
+
TLV: |
|
|
643
|
+
The tester verifies the ability of the Health IT
|
|
644
|
+
Module to return an error response when supplied an invalid
|
|
645
|
+
refresh token as specified in the implementation specification
|
|
646
|
+
adopted in § 170.215(a)(3).
|
|
647
|
+
inferno_supported: 'yes'
|
|
648
|
+
inferno_tests:
|
|
649
|
+
- 1.4.01 - 1.4.02
|
|
650
|
+
- 3.4.01 - 3.4.02
|
|
651
|
+
- section: Paragraph (g)(10)(vi) – Patient authorization revocation
|
|
652
|
+
steps:
|
|
653
|
+
- group: Patient Authorization Revocation
|
|
654
|
+
id: REVOCATION-1
|
|
655
|
+
SUT: |
|
|
656
|
+
The health IT developer demonstrates the ability of the Health IT Module to revoke
|
|
657
|
+
access to an authorized application at a patient’s direction,
|
|
658
|
+
including a demonstration of the inability of the application with
|
|
659
|
+
revoked access to receive patient EHI.
|
|
660
|
+
TLV: |
|
|
661
|
+
The tester verifies the ability of the Health IT Module to revoke
|
|
662
|
+
access to an authorized application at a patient’s direction,
|
|
663
|
+
including a demonstration of the inability of the application with
|
|
664
|
+
revoked access to receive patient EHI.
|
|
665
|
+
inferno_supported: 'yes'
|
|
666
|
+
inferno_tests:
|
|
667
|
+
- 6.2.01 - 6.2.03
|
|
668
|
+
- section: Authentication and authorization for system scopes
|
|
669
|
+
steps:
|
|
670
|
+
- group: Authentication and Authorization for System Scopes
|
|
671
|
+
id: AUTH-SYSTEM-1
|
|
672
|
+
SUT: |
|
|
673
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
674
|
+
Module to support OAuth 2.0 client credentials grant flow in
|
|
675
|
+
accordance with the implementation specification adopted in §
|
|
676
|
+
170.215(a)(4).
|
|
677
|
+
TLV: |
|
|
678
|
+
The tester verfies the ability of the Health IT
|
|
679
|
+
Module to support OAuth 2.0 client credentials grant flow in
|
|
680
|
+
accordance with the implementation specification adopted in §
|
|
681
|
+
170.215(a)(4).
|
|
682
|
+
inferno_supported: 'yes'
|
|
683
|
+
inferno_tests:
|
|
684
|
+
- 5.1.02 - 5.1.06
|
|
685
|
+
- id: AUTH-SYSTEM-2
|
|
686
|
+
SUT: |
|
|
687
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
688
|
+
Module to support the following parameters according to the
|
|
689
|
+
implementation specification adopted in § 170.215(a)(4):
|
|
690
|
+
* “scope”;
|
|
691
|
+
* “grant_type”;
|
|
692
|
+
* “client_assertion_type”; and
|
|
693
|
+
* “client_assertion”
|
|
694
|
+
TLV: |
|
|
695
|
+
The tester verifies the ability of the Health IT
|
|
696
|
+
Module to support the following parameters according to the
|
|
697
|
+
implementation specification adopted in § 170.215(a)(4):
|
|
698
|
+
* “scope”;
|
|
699
|
+
* “grant_type”;
|
|
700
|
+
* “client_assertion_type”; and
|
|
701
|
+
* “client_assertion”
|
|
702
|
+
inferno_supported: 'yes'
|
|
703
|
+
inferno_tests:
|
|
704
|
+
- 5.1.05
|
|
705
|
+
- id: AUTH-SYSTEM-3
|
|
706
|
+
SUT: |
|
|
707
|
+
The tester verifies the ability of the Health IT
|
|
708
|
+
Module to support the following JSON Web Token (JWT) Headers
|
|
709
|
+
and Claims according to the implementation specification adopted
|
|
710
|
+
in § 170.215(a)(4):
|
|
711
|
+
* “alg” header;
|
|
712
|
+
* “kid” header;
|
|
713
|
+
* “typ” header;
|
|
714
|
+
* “iss” claim;
|
|
715
|
+
* “sub” claim;
|
|
716
|
+
* “aud” claim;
|
|
717
|
+
* “exp” claim; and
|
|
718
|
+
* “jti” claim.
|
|
719
|
+
TLV: |
|
|
720
|
+
The tester verifies the ability of the Health IT
|
|
721
|
+
Module to support the following JSON Web Token (JWT) Headers
|
|
722
|
+
and Claims according to the implementation specification adopted
|
|
723
|
+
in § 170.215(a)(4):
|
|
724
|
+
* “alg” header;
|
|
725
|
+
* “kid” header;
|
|
726
|
+
* “typ” header;
|
|
727
|
+
* “iss” claim;
|
|
728
|
+
* “sub” claim;
|
|
729
|
+
* “aud” claim;
|
|
730
|
+
* “exp” claim; and
|
|
731
|
+
* “jti” claim.
|
|
732
|
+
inferno_supported: 'yes'
|
|
733
|
+
inferno_tests:
|
|
734
|
+
- 5.1.05
|
|
735
|
+
- id: AUTH-SYSTEM-4
|
|
736
|
+
SUT: |
|
|
737
|
+
The tester verifies the ability of the Health IT
|
|
738
|
+
Module to receive and process the JSON Web Key (JWK) Set via a
|
|
739
|
+
TLS-protected URL to support authorization for system scopes in §
|
|
740
|
+
170.315(g)(10)(v)(B).
|
|
741
|
+
TLV: |
|
|
742
|
+
The tester verifies the ability of the Health IT
|
|
743
|
+
Module to receive and process the JSON Web Key (JWK) Set via a
|
|
744
|
+
TLS-protected URL to support authorization for system scopes in §
|
|
745
|
+
170.315(g)(10)(v)(B).
|
|
746
|
+
inferno_supported: 'yes'
|
|
747
|
+
inferno_tests:
|
|
748
|
+
- 5.1.05
|
|
749
|
+
- id: AUTH-SYSTEM-5
|
|
750
|
+
SUT: |
|
|
751
|
+
The health IT developer demonstrates that the Health IT Module
|
|
752
|
+
does not cache a JWK Set received via a TLS-protected URL for
|
|
753
|
+
longer than the “cache-control” header received by an application
|
|
754
|
+
indicates.
|
|
755
|
+
TLV: |
|
|
756
|
+
The tester verifies the Health IT Module
|
|
757
|
+
does not cache a JWK Set received via a TLS-protected URL for
|
|
758
|
+
longer than the “cache-control” header received by an application
|
|
759
|
+
indicates.
|
|
760
|
+
inferno_supported: 'yes'
|
|
761
|
+
inferno_notes: |
|
|
762
|
+
This test requires the tester to register an attestation from the
|
|
763
|
+
Health IT Module that the "cache-control" header is obeyed.
|
|
764
|
+
inferno_tests:
|
|
765
|
+
- 6.6.10
|
|
766
|
+
- id: AUTH-SYSTEM-6
|
|
767
|
+
SUT: |
|
|
768
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
769
|
+
Module to validate an application’s JWT, including its JSON Web
|
|
770
|
+
Signatures, according to the implementation specification adopted
|
|
771
|
+
in § 170.215(a)(4).
|
|
772
|
+
TLV: |
|
|
773
|
+
The tester verifies the ability of the Health IT
|
|
774
|
+
Module to validate an application’s JWT, including its JSON Web
|
|
775
|
+
Signatures, according to the implementation specification adopted
|
|
776
|
+
in § 170.215(a)(4).
|
|
777
|
+
inferno_supported: 'yes'
|
|
778
|
+
inferno_tests:
|
|
779
|
+
- 5.1.05
|
|
780
|
+
- id: AUTH-SYSTEM-7
|
|
781
|
+
SUT: |
|
|
782
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
783
|
+
Module to respond with an “invalid_client” error for errors
|
|
784
|
+
encountered during the authentication process according to the
|
|
785
|
+
implementation specification adopted in § 170.215(a)(4).
|
|
786
|
+
TLV: |
|
|
787
|
+
The tester verifies the ability of the Health IT
|
|
788
|
+
Module to respond with an “invalid_client” error for errors
|
|
789
|
+
encountered during the authentication process according to the
|
|
790
|
+
implementation specification adopted in § 170.215(a)(4).
|
|
791
|
+
inferno_supported: 'yes'
|
|
792
|
+
inferno_tests:
|
|
793
|
+
- 5.1.02 - 5.1.04
|
|
794
|
+
- id: AUTH-SYSTEM-8
|
|
795
|
+
SUT: |
|
|
796
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
797
|
+
Module to assure the scope requested by an application is no
|
|
798
|
+
greater than the pre-authorized scope for multiple patients
|
|
799
|
+
according to the implementation specification adopted in §
|
|
800
|
+
170.215(a)(4).
|
|
801
|
+
TLV: |
|
|
802
|
+
The tester verifies the ability of the Health IT
|
|
803
|
+
Module to assure the scope requested by an application is no
|
|
804
|
+
greater than the pre-authorized scope for multiple patients
|
|
805
|
+
according to the implementation specification adopted in §
|
|
806
|
+
170.215(a)(4).
|
|
807
|
+
inferno_supported: 'yes'
|
|
808
|
+
inferno_notes: |
|
|
809
|
+
There is no requirement for support of a subset of the resources
|
|
810
|
+
so you can't check to see what happens when you attempt to access
|
|
811
|
+
more than what was pre-authorized. The Health IT module must
|
|
812
|
+
demonstrate this and register its attestation within Inferno.
|
|
813
|
+
inferno_tests:
|
|
814
|
+
- 6.6.08
|
|
815
|
+
- id: AUTH-SYSTEM-9
|
|
816
|
+
SUT: |
|
|
817
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
818
|
+
Module to issue an access token to an application as a JSON object
|
|
819
|
+
in accordance with the implementation specification adopted in §
|
|
820
|
+
170.215(a)(4), including the following property names:
|
|
821
|
+
* “access_token”;
|
|
822
|
+
* “token_type”;
|
|
823
|
+
* “expires_in”; and
|
|
824
|
+
* “scope”
|
|
825
|
+
TLV: |
|
|
826
|
+
The tester verifies the ability of the Health IT
|
|
827
|
+
Module to issue an access token to an application as a JSON object
|
|
828
|
+
in accordance with the implementation specification adopted in §
|
|
829
|
+
170.215(a)(4), including the following property names:
|
|
830
|
+
* “access_token”;
|
|
831
|
+
* “token_type”;
|
|
832
|
+
* “expires_in”; and
|
|
833
|
+
* “scope”
|
|
834
|
+
inferno_supported: 'yes'
|
|
835
|
+
inferno_tests:
|
|
836
|
+
- 5.1.06
|
|
837
|
+
- id: AUTH-SYSTEM-10
|
|
838
|
+
SUT: |
|
|
839
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
840
|
+
Module to respond to errors using the appropriate error messages
|
|
841
|
+
as specified in the implementation specification adopted in §
|
|
842
|
+
170.215(a)(4).
|
|
843
|
+
TLV: |
|
|
844
|
+
The tester verifies the ability of the Health IT
|
|
845
|
+
Module to respond to errors using the appropriate error messages
|
|
846
|
+
as specified in the implementation specification adopted in §
|
|
847
|
+
170.215(a)(4).
|
|
848
|
+
inferno_supported: 'yes'
|
|
849
|
+
inferno_tests:
|
|
850
|
+
- 5.1.02 - 5.1.04
|
|
851
|
+
- 5.2.03
|
|
852
|
+
- section: Paragraph (g)(10)(vii) – Token introspection
|
|
853
|
+
steps:
|
|
854
|
+
- group: Token Introspection
|
|
855
|
+
id: INTROSPECTION-1
|
|
856
|
+
SUT: |
|
|
857
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
858
|
+
Module to receive and validate a token it has issued.
|
|
859
|
+
TLV: |
|
|
860
|
+
The tester verifies the ability of the Health IT
|
|
861
|
+
Module to receive and validate a token it has issued.
|
|
862
|
+
inferno_supported: 'yes'
|
|
863
|
+
inferno_notes: |
|
|
864
|
+
No standard is required and therefore Inferno cannot do this in
|
|
865
|
+
an automated fashion and this is recorded as an attestation
|
|
866
|
+
within Inferno.
|
|
867
|
+
inferno_tests:
|
|
868
|
+
- 6.6.06
|
|
869
|
+
- section: Paragraph (g)(10)(ii) – Supported search operations
|
|
870
|
+
steps:
|
|
871
|
+
- group: Supported Search Operations for a Single Patient’s Data
|
|
872
|
+
id: SEARCH-1
|
|
873
|
+
SUT: |
|
|
874
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
875
|
+
Module to support the “capabilities” interaction as specified in the
|
|
876
|
+
standard adopted in § 170.215(a)(1), including support for a
|
|
877
|
+
“CapabilityStatement” as specified in the standard adopted in §
|
|
878
|
+
170.215(a)(1) and implementation specification adopted in §
|
|
879
|
+
170.215(a)(2).
|
|
880
|
+
TLV: |
|
|
881
|
+
The tester verfies the ability of the Health IT
|
|
882
|
+
Module to support the “capabilities” interaction as specified in the
|
|
883
|
+
standard adopted in § 170.215(a)(1), including support for a
|
|
884
|
+
“CapabilityStatement” as specified in the standard adopted in §
|
|
885
|
+
170.215(a)(1) and implementation specification adopted in §
|
|
886
|
+
170.215(a)(2).
|
|
887
|
+
inferno_supported: 'yes'
|
|
888
|
+
inferno_tests:
|
|
889
|
+
- 4.1.02 - 4.1.05
|
|
890
|
+
- id: SEARCH-2
|
|
891
|
+
SUT: |
|
|
892
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
893
|
+
Module to respond to requests for a single patient’s data
|
|
894
|
+
consistent with the search criteria detailed in the “US Core Server
|
|
895
|
+
CapabilityStatement” section of the implementation specification
|
|
896
|
+
adopted in § 170.215(a)(2), including demonstrating search
|
|
897
|
+
support for “SHALL” operations and parameters for all the data
|
|
898
|
+
included in the standard adopted in § 170.213.
|
|
899
|
+
TLV: |
|
|
900
|
+
The tester verifies the ability of the Health IT Module to respond to
|
|
901
|
+
requests for a single patient’s data consistent with the search
|
|
902
|
+
criteria detailed in the “US Core Server CapabilityStatement”
|
|
903
|
+
section of the implementation specification adopted in §
|
|
904
|
+
170.215(a)(2), including demonstrating search support for “SHALL”
|
|
905
|
+
operations and parameters for all the data included in the standard
|
|
906
|
+
adopted in § 170.213.
|
|
907
|
+
inferno_supported: 'yes'
|
|
908
|
+
inferno_tests:
|
|
909
|
+
- 4.2.01
|
|
910
|
+
- 4.3.01
|
|
911
|
+
- 4.4.01
|
|
912
|
+
- 4.5.01
|
|
913
|
+
- 4.6.01
|
|
914
|
+
- 4.7.01
|
|
915
|
+
- 4.8.01
|
|
916
|
+
- 4.9.01
|
|
917
|
+
- 4.10.01
|
|
918
|
+
- 4.11.01
|
|
919
|
+
- 4.12.01
|
|
920
|
+
- 4.13.01
|
|
921
|
+
- 4.14.01
|
|
922
|
+
- 4.15.01
|
|
923
|
+
- 4.16.01
|
|
924
|
+
- 4.17.01
|
|
925
|
+
- 4.18.01
|
|
926
|
+
- 4.20.01
|
|
927
|
+
- 4.21.01
|
|
928
|
+
- 4.22.01
|
|
929
|
+
- 4.23.01
|
|
930
|
+
- 4.19.01
|
|
931
|
+
- 4.24.01
|
|
932
|
+
- 4.25.01
|
|
933
|
+
- 4.26.01
|
|
934
|
+
- 4.31.01
|
|
935
|
+
- 4.28.01
|
|
936
|
+
- 4.30.01
|
|
937
|
+
- id: SEARCH-3
|
|
938
|
+
SUT: |
|
|
939
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
940
|
+
Module to support a resource search for the provenance target
|
|
941
|
+
“(_revIncludes: Provenance:target)” for all the FHIR resources
|
|
942
|
+
included in the standard adopted in § 170.213 and implementation
|
|
943
|
+
specification adopted in § 170.215(a)(2) according to the “Basic
|
|
944
|
+
Provenance Guidance” section of the implementation specification
|
|
945
|
+
adopted in § 170.215(a)(2).
|
|
946
|
+
TLV: |
|
|
947
|
+
The tester verifies the ability of the Health IT
|
|
948
|
+
Module to support a resource search for the provenance target
|
|
949
|
+
“(_revIncludes: Provenance:target)” for all the FHIR resources
|
|
950
|
+
included in the standard adopted in § 170.213 and implementation
|
|
951
|
+
specification adopted in § 170.215(a)(2) according to the “Basic
|
|
952
|
+
Provenance Guidance” section of the implementation specification
|
|
953
|
+
adopted in § 170.215(a)(2).
|
|
954
|
+
inferno_supported: 'yes'
|
|
955
|
+
inferno_tests:
|
|
956
|
+
- 4.2.07
|
|
957
|
+
- 4.3.03
|
|
958
|
+
- 4.4.03
|
|
959
|
+
- 4.5.03
|
|
960
|
+
- 4.6.03
|
|
961
|
+
- 4.7.03
|
|
962
|
+
- 4.8.06
|
|
963
|
+
- 4.9.06
|
|
964
|
+
- 4.10.07
|
|
965
|
+
- 4.11.04
|
|
966
|
+
- 4.12.03
|
|
967
|
+
- 4.13.04
|
|
968
|
+
- 4.14.03
|
|
969
|
+
- 4.15.05
|
|
970
|
+
- 4.16.06
|
|
971
|
+
- 4.17.05
|
|
972
|
+
- 4.18.05
|
|
973
|
+
- 4.20.05
|
|
974
|
+
- 4.21.05
|
|
975
|
+
- 4.22.05
|
|
976
|
+
- 4.23.05
|
|
977
|
+
- 4.19.05
|
|
978
|
+
- 4.24.05
|
|
979
|
+
- 4.25.05
|
|
980
|
+
- 4.26.04
|
|
981
|
+
- group: Supported Search Operations for Multiple Patients’ Data
|
|
982
|
+
id: SEARCH-4
|
|
983
|
+
SUT: |
|
|
984
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
985
|
+
Module to support the “capabilities” interaction as specified in the
|
|
986
|
+
standard adopted in § 170.215(a)(1), including support for a
|
|
987
|
+
“CapabilityStatement” as specified in the standard adopted in §
|
|
988
|
+
170.215(a)(1) and implementation specification adopted in §
|
|
989
|
+
170.215(a)(4).
|
|
990
|
+
TLV: |
|
|
991
|
+
The tester verifies the ability of the Health IT
|
|
992
|
+
Module to support the “capabilities” interaction as specified in the
|
|
993
|
+
standard adopted in § 170.215(a)(1), including support for a
|
|
994
|
+
“CapabilityStatement” as specified in the standard adopted in §
|
|
995
|
+
170.215(a)(1) and implementation specification adopted in §
|
|
996
|
+
170.215(a)(4).
|
|
997
|
+
inferno_supported: 'yes'
|
|
998
|
+
inferno_tests:
|
|
999
|
+
- 5.2.02
|
|
1000
|
+
- id: SEARCH-5
|
|
1001
|
+
SUT: |
|
|
1002
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
1003
|
+
Module to support requests for multiple patients’ data as a group
|
|
1004
|
+
using the “group-export” operation as detailed in the
|
|
1005
|
+
implementation specification adopted in § 170.215(a)(4).
|
|
1006
|
+
TLV: |
|
|
1007
|
+
The tester verifies the ability of the Health IT Module to support
|
|
1008
|
+
requests for multiple patients’ data as a group using the “group
|
|
1009
|
+
export” operation as detailed in the implementation specification
|
|
1010
|
+
adopted in § 170.215(a)(4).
|
|
1011
|
+
inferno_supported: 'yes'
|
|
1012
|
+
inferno_tests:
|
|
1013
|
+
- 5.2.07
|
|
1014
|
+
- section: Paragraph (g)(10)(i) – Data response
|
|
1015
|
+
steps:
|
|
1016
|
+
- group: Data Response Checks for Single and Multiple Patients
|
|
1017
|
+
id: RESPONSE-1
|
|
1018
|
+
SUT: |
|
|
1019
|
+
For responses to data for single and multiple patients as described
|
|
1020
|
+
in steps 7 and 8 of this section respectively, the health IT developer
|
|
1021
|
+
demonstrates the ability of the Health IT Module to respond to
|
|
1022
|
+
requests for data according to the implementation specification
|
|
1023
|
+
adopted in § 170.215(a)(2), including the following steps.
|
|
1024
|
+
inferno_supported: 'yes'
|
|
1025
|
+
inferno_tests:
|
|
1026
|
+
- 4.2.06
|
|
1027
|
+
- 4.3.02
|
|
1028
|
+
- 4.4.02
|
|
1029
|
+
- 4.5.02
|
|
1030
|
+
- 4.6.02
|
|
1031
|
+
- 4.7.02
|
|
1032
|
+
- 4.8.05
|
|
1033
|
+
- 4.9.05
|
|
1034
|
+
- 4.10.06
|
|
1035
|
+
- 4.11.02
|
|
1036
|
+
- 4.12.02
|
|
1037
|
+
- 4.13.03
|
|
1038
|
+
- 4.14.02
|
|
1039
|
+
- 4.15.04
|
|
1040
|
+
- 4.16.04
|
|
1041
|
+
- 4.17.04
|
|
1042
|
+
- 4.18.04
|
|
1043
|
+
- 4.20.04
|
|
1044
|
+
- 4.21.04
|
|
1045
|
+
- 4.22.04
|
|
1046
|
+
- 4.23.04
|
|
1047
|
+
- 4.19.04
|
|
1048
|
+
- 4.24.04
|
|
1049
|
+
- 4.25.04
|
|
1050
|
+
- 4.26.03
|
|
1051
|
+
- 4.28.02
|
|
1052
|
+
- 4.30.01
|
|
1053
|
+
- 5.3.06 - 5.3.23
|
|
1054
|
+
- id: RESPONSE-2
|
|
1055
|
+
SUT: |
|
|
1056
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
1057
|
+
Module to respond with data that meet the following conditions:
|
|
1058
|
+
* All data elements indicated with a cardinality of one or greater and / or “must support” are included;
|
|
1059
|
+
* Content is structurally correct;
|
|
1060
|
+
* All invariant rules are met;
|
|
1061
|
+
* All data elements with required “ValueSet” bindings contain codes within the bound “ValueSet”;
|
|
1062
|
+
* All information is accurate and without omission; and
|
|
1063
|
+
* All references within the resources can be resolved and validated, as applicable, according to steps 2-6 of this section
|
|
1064
|
+
TLV: |
|
|
1065
|
+
The tester verfies the ability of the Health IT
|
|
1066
|
+
Module to respond with data that meet the following conditions:
|
|
1067
|
+
* All data elements indicated with a cardinality of one or greater and / or “must support” are included;
|
|
1068
|
+
* Content is structurally correct;
|
|
1069
|
+
* All invariant rules are met;
|
|
1070
|
+
* All data elements with required “ValueSet” bindings contain codes within the bound “ValueSet”;
|
|
1071
|
+
* All information is accurate and without omission; and
|
|
1072
|
+
* All references within the resources can be resolved and validated, as applicable, according to steps 2-6 of this section
|
|
1073
|
+
inferno_supported: 'yes'
|
|
1074
|
+
inferno_tests:
|
|
1075
|
+
- 6.6.07
|
|
1076
|
+
- 6.6.11
|
|
1077
|
+
- 6.6.12
|
|
1078
|
+
- 4.2.01
|
|
1079
|
+
- 4.3.01
|
|
1080
|
+
- 4.4.01
|
|
1081
|
+
- 4.5.01
|
|
1082
|
+
- 4.6.01
|
|
1083
|
+
- 4.7.01
|
|
1084
|
+
- 4.8.01
|
|
1085
|
+
- 4.9.01
|
|
1086
|
+
- 4.10.01
|
|
1087
|
+
- 4.11.01
|
|
1088
|
+
- 4.12.01
|
|
1089
|
+
- 4.13.01
|
|
1090
|
+
- 4.14.01
|
|
1091
|
+
- 4.15.01
|
|
1092
|
+
- 4.16.01
|
|
1093
|
+
- 4.17.01
|
|
1094
|
+
- 4.18.01
|
|
1095
|
+
- 4.20.01
|
|
1096
|
+
- 4.21.01
|
|
1097
|
+
- 4.22.01
|
|
1098
|
+
- 4.23.01
|
|
1099
|
+
- 4.19.01
|
|
1100
|
+
- 4.24.01
|
|
1101
|
+
- 4.25.01
|
|
1102
|
+
- 4.26.01
|
|
1103
|
+
- 4.31.01
|
|
1104
|
+
- 4.28.01
|
|
1105
|
+
- 4.30.01
|
|
1106
|
+
- 5.3.02
|
|
1107
|
+
inferno_notes: |
|
|
1108
|
+
The requirement "all information is accurate and without omission"
|
|
1109
|
+
cannot be verified automatically by Inferno, as Inferno only has
|
|
1110
|
+
visibility into the data being returned in the API. Inferno also does
|
|
1111
|
+
not require a specific set of data to be loaded. Because of this,
|
|
1112
|
+
omissions are not possible to detect. However, the tester can use the
|
|
1113
|
+
tool to compare responses to what is displayed in the system, and
|
|
1114
|
+
register this as an attestation. Additionally, US Core v3.1 does
|
|
1115
|
+
not include three required USCDI v1 data elements for Patient Demographics
|
|
1116
|
+
and Allergy and Intolerances, and this requires visual inspection
|
|
1117
|
+
by the tester.
|
|
1118
|
+
- id: RESPONSE-3
|
|
1119
|
+
SUT: |
|
|
1120
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
1121
|
+
Module to support a “Provenance” FHIR resource for all the FHIR
|
|
1122
|
+
resources included in the standard adopted in § 170.213 and
|
|
1123
|
+
implementation specification adopted in § 170.215(a)(2) according
|
|
1124
|
+
to the “Basic Provenance Guidance” section of the implementation
|
|
1125
|
+
specification adopted in § 170.215(a)(2).
|
|
1126
|
+
TLV: |
|
|
1127
|
+
The tester verfies the ability of the Health IT
|
|
1128
|
+
Module to support a “Provenance” FHIR resource for all the FHIR
|
|
1129
|
+
resources included in the standard adopted in § 170.213 and
|
|
1130
|
+
implementation specification adopted in § 170.215(a)(2) according
|
|
1131
|
+
to the “Basic Provenance Guidance” section of the implementation
|
|
1132
|
+
specification adopted in § 170.215(a)(2).
|
|
1133
|
+
inferno_supported: 'yes'
|
|
1134
|
+
inferno_tests:
|
|
1135
|
+
- 4.2.07
|
|
1136
|
+
- 4.3.03
|
|
1137
|
+
- 4.4.05
|
|
1138
|
+
- 4.5.03
|
|
1139
|
+
- 4.6.04
|
|
1140
|
+
- 4.7.03
|
|
1141
|
+
- 4.8.06
|
|
1142
|
+
- 4.9.06
|
|
1143
|
+
- 4.10.07
|
|
1144
|
+
- 4.11.04
|
|
1145
|
+
- 4.12.03
|
|
1146
|
+
- 4.13.04
|
|
1147
|
+
- 4.14.03
|
|
1148
|
+
- 4.15.05
|
|
1149
|
+
- 4.16.05
|
|
1150
|
+
- 4.17.05
|
|
1151
|
+
- 4.18.05
|
|
1152
|
+
- 4.20.05
|
|
1153
|
+
- 4.21.05
|
|
1154
|
+
- 4.22.05
|
|
1155
|
+
- 4.23.05
|
|
1156
|
+
- 4.19.05
|
|
1157
|
+
- 4.24.05
|
|
1158
|
+
- 4.25.05
|
|
1159
|
+
- 4.26.04
|
|
1160
|
+
- 4.30.01 - 4.30.04
|
|
1161
|
+
- 5.3.01
|
|
1162
|
+
- id: RESPONSE-4
|
|
1163
|
+
SUT: |
|
|
1164
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
1165
|
+
Module to support a “DocumentReference” and/or “DiagnosticReport” FHIR
|
|
1166
|
+
resource for each of the “Clinical Notes” and “Diagnostic Reports”
|
|
1167
|
+
included in and according to the “Clinical Notes Guidance” section of
|
|
1168
|
+
the implementation specification adopted in § 170.215(a)(2)..
|
|
1169
|
+
TLV: |
|
|
1170
|
+
The tester verifies the ability of the Health IT Module to support
|
|
1171
|
+
a “DocumentReference” and/or “DiagnosticReport” FHIR resource for each
|
|
1172
|
+
of the “Clinical Notes” and “Diagnostic Reports” included in and
|
|
1173
|
+
according to the “Clinical Notes Guidance” section of the
|
|
1174
|
+
implementation specification adopted in § 170.215(a)(2).
|
|
1175
|
+
inferno_supported: 'yes'
|
|
1176
|
+
inferno_tests:
|
|
1177
|
+
- 4.31.01 - 4.31.02
|
|
1178
|
+
- id: RESPONSE-5
|
|
1179
|
+
SUT: |
|
|
1180
|
+
If supported, and for responses to data for a single patient only, the
|
|
1181
|
+
health IT developer demonstrates the ability of the Health IT
|
|
1182
|
+
Module to support a “Medication” FHIR resource according to the
|
|
1183
|
+
“Medication List Guidance” section of the implementation
|
|
1184
|
+
specification adopted in § 170.215(a)(2).
|
|
1185
|
+
TLV: |
|
|
1186
|
+
If supported, and for responses to data for a single patient only, the
|
|
1187
|
+
tester verfies the ability of the Health IT
|
|
1188
|
+
Module to support a “Medication” FHIR resource according to the
|
|
1189
|
+
“Medication List Guidance” section of the implementation
|
|
1190
|
+
specification adopted in § 170.215(a)(2).
|
|
1191
|
+
inferno_supported: 'yes'
|
|
1192
|
+
inferno_tests:
|
|
1193
|
+
- 4.13.06
|
|
1194
|
+
- id: RESPONSE-6
|
|
1195
|
+
SUT: |
|
|
1196
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
1197
|
+
Module to support “DataAbsentReason” as specified in the
|
|
1198
|
+
implementation specification adopted in § 170. 215(a)(2),
|
|
1199
|
+
including:
|
|
1200
|
+
* “DataAbsentReason” Extension; and
|
|
1201
|
+
* “DataAbsentReason” Code System.
|
|
1202
|
+
TLV: |
|
|
1203
|
+
The tester verfies the ability of the Health IT
|
|
1204
|
+
Module to support “DataAbsentReason” as specified in the
|
|
1205
|
+
implementation specification adopted in § 170. 215(a)(2),
|
|
1206
|
+
including:
|
|
1207
|
+
* “DataAbsentReason” Extension; and
|
|
1208
|
+
* “DataAbsentReason” Code System.
|
|
1209
|
+
inferno_supported: 'yes'
|
|
1210
|
+
inferno_tests:
|
|
1211
|
+
- 4.32.01 - 4.32.02
|
|
1212
|
+
- group: Response to Requests for a Single Patient’s Data
|
|
1213
|
+
id: RESPONSE-7
|
|
1214
|
+
SUT: |
|
|
1215
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
1216
|
+
Module to return all of the data associated with requests for a
|
|
1217
|
+
single patient’s data according to the “US Core Server
|
|
1218
|
+
CapabilityStatement” section of the implementation specification
|
|
1219
|
+
adopted in § 170.215(a)(2) for all the data included in the standard
|
|
1220
|
+
adopted in § 170.213.
|
|
1221
|
+
TLV: |
|
|
1222
|
+
The tester verifies the ability of the Health IT
|
|
1223
|
+
Module to return all of the data associated with requests for a
|
|
1224
|
+
single patient’s data according to the “US Core Server
|
|
1225
|
+
CapabilityStatement” section of the implementation specification
|
|
1226
|
+
adopted in § 170.215(a)(2) for all the data included in the standard
|
|
1227
|
+
adopted in § 170.213.
|
|
1228
|
+
inferno_supported: 'yes'
|
|
1229
|
+
inferno_tests:
|
|
1230
|
+
- 4.2.01
|
|
1231
|
+
- 4.3.01
|
|
1232
|
+
- 4.4.01
|
|
1233
|
+
- 4.5.01
|
|
1234
|
+
- 4.6.01
|
|
1235
|
+
- 4.7.01
|
|
1236
|
+
- 4.8.01
|
|
1237
|
+
- 4.9.01
|
|
1238
|
+
- 4.10.01
|
|
1239
|
+
- 4.11.01
|
|
1240
|
+
- 4.12.01
|
|
1241
|
+
- 4.13.01
|
|
1242
|
+
- 4.14.01
|
|
1243
|
+
- 4.15.01
|
|
1244
|
+
- 4.16.01
|
|
1245
|
+
- 4.17.01
|
|
1246
|
+
- 4.18.01
|
|
1247
|
+
- 4.20.01
|
|
1248
|
+
- 4.21.01
|
|
1249
|
+
- 4.22.01
|
|
1250
|
+
- 4.23.01
|
|
1251
|
+
- 4.19.01
|
|
1252
|
+
- 4.24.01
|
|
1253
|
+
- 4.25.01
|
|
1254
|
+
- 4.26.01
|
|
1255
|
+
- 4.31.01
|
|
1256
|
+
- 4.28.01
|
|
1257
|
+
- 4.30.01
|
|
1258
|
+
- group: Response to Requests for Multiple Patients’ Data
|
|
1259
|
+
id: RESPONSE-8
|
|
1260
|
+
SUT: |
|
|
1261
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
1262
|
+
Module to respond to requests for multiple patients’ data
|
|
1263
|
+
according to the implementation specification adopted in §
|
|
1264
|
+
170.215(a)(4) for all of the FHIR resources associated with the
|
|
1265
|
+
profiles and Data Elements specified in and according to the
|
|
1266
|
+
standard adopted in § 170.213 and implementation specification
|
|
1267
|
+
adopted in § 170.215(a)(2), including the following FHIR resources:
|
|
1268
|
+
* “AllergyIntolerance”;
|
|
1269
|
+
* “CarePlan”;
|
|
1270
|
+
* “CareTeam”;
|
|
1271
|
+
* “Condition”;
|
|
1272
|
+
* “Device”;
|
|
1273
|
+
* “DiagnosticReport”;
|
|
1274
|
+
* “DocumentReference”;
|
|
1275
|
+
* “Encounter”;
|
|
1276
|
+
* “Goal”;
|
|
1277
|
+
* “Immunization”;
|
|
1278
|
+
* “Location”;
|
|
1279
|
+
* “Medication” (if supported);
|
|
1280
|
+
* “MedicationRequest”;
|
|
1281
|
+
* “Observation”;
|
|
1282
|
+
* “Organization”;
|
|
1283
|
+
* “Patient”;
|
|
1284
|
+
* “Practitioner”;
|
|
1285
|
+
* “Procedure”; and
|
|
1286
|
+
* “Provenance”;
|
|
1287
|
+
TLV: |
|
|
1288
|
+
The tester verifies the ability of the Health IT
|
|
1289
|
+
Module to respond to requests for multiple patients’ data
|
|
1290
|
+
according to the implementation specification adopted in §
|
|
1291
|
+
170.215(a)(4) for all of the FHIR resources associated with the
|
|
1292
|
+
profiles and Data Elements specified in and according to the
|
|
1293
|
+
standard adopted in § 170.213 and implementation specification
|
|
1294
|
+
adopted in § 170.215(a)(2), including the following FHIR resources:
|
|
1295
|
+
* “AllergyIntolerance”;
|
|
1296
|
+
* “CarePlan”;
|
|
1297
|
+
* “CareTeam”;
|
|
1298
|
+
* “Condition”;
|
|
1299
|
+
* “Device”;
|
|
1300
|
+
* “DiagnosticReport”;
|
|
1301
|
+
* “DocumentReference”;
|
|
1302
|
+
* “Encounter”;
|
|
1303
|
+
* “Goal”;
|
|
1304
|
+
* “Immunization”;
|
|
1305
|
+
* “Location”;
|
|
1306
|
+
* “Medication” (if supported);
|
|
1307
|
+
* “MedicationRequest”;
|
|
1308
|
+
* “Observation”;
|
|
1309
|
+
* “Organization”;
|
|
1310
|
+
* “Patient”;
|
|
1311
|
+
* “Practitioner”;
|
|
1312
|
+
* “Procedure”; and
|
|
1313
|
+
* “Provenance”;
|
|
1314
|
+
inferno_supported: 'yes'
|
|
1315
|
+
inferno_tests:
|
|
1316
|
+
- 5.3.03
|
|
1317
|
+
- 5.3.06 - 5.3.21
|
|
1318
|
+
- id: RESPONSE-9
|
|
1319
|
+
SUT: |
|
|
1320
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
1321
|
+
Module to limit the data returned to only those FHIR resources for
|
|
1322
|
+
which the client is authorized according to the implementation
|
|
1323
|
+
specification adopted in § 170.215(a)(4).
|
|
1324
|
+
TLV: |
|
|
1325
|
+
The tester verifies the ability of the Health IT
|
|
1326
|
+
Module to limit the data returned to only those FHIR resources for
|
|
1327
|
+
which the client is authorized according to the implementation
|
|
1328
|
+
specification adopted in § 170.215(a)(4).
|
|
1329
|
+
inferno_supported: 'yes'
|
|
1330
|
+
inferno_tests:
|
|
1331
|
+
- 2.2.01 - 2.2.13
|
|
1332
|
+
inferno_notes: |
|
|
1333
|
+
Inferno does not do this because there is no requirement to only
|
|
1334
|
+
supported a subset of the scopes.
|
|
1335
|
+
- id: RESPONSE-10
|
|
1336
|
+
SUT: |
|
|
1337
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
1338
|
+
Module to support a successful data response according to the
|
|
1339
|
+
implementation adopted in § 170.215(a)(4).
|
|
1340
|
+
TLV: |
|
|
1341
|
+
The tester verifies the ability of the Health IT
|
|
1342
|
+
Module to support a successful data response according to the
|
|
1343
|
+
implementation adopted in § 170.215(a)(4).
|
|
1344
|
+
inferno_supported: 'yes'
|
|
1345
|
+
inferno_tests:
|
|
1346
|
+
- 5.2.04 - 5.2.05
|
|
1347
|
+
- id: RESPONSE-11
|
|
1348
|
+
SUT: |
|
|
1349
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
1350
|
+
Module to support a data response error according to the
|
|
1351
|
+
implementation adopted in § 170.215(a)(4).
|
|
1352
|
+
TLV: |
|
|
1353
|
+
The tester verifies the ability of the Health IT
|
|
1354
|
+
Module to support a data response error according to the
|
|
1355
|
+
implementation adopted in § 170.215(a)(4).
|
|
1356
|
+
inferno_supported: 'yes'
|
|
1357
|
+
inferno_tests:
|
|
1358
|
+
- 5.2.03
|
|
1359
|
+
- id: RESPONSE-12
|
|
1360
|
+
SUT: |
|
|
1361
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
1362
|
+
Module to support a bulk data delete request according to the
|
|
1363
|
+
implementation specification adopted in § 170.215(a)(4).
|
|
1364
|
+
TLV: |
|
|
1365
|
+
The tester verifies the ability of the Health IT
|
|
1366
|
+
Module to support a bulk data delete request according to the
|
|
1367
|
+
implementation specification adopted in § 170.215(a)(4).
|
|
1368
|
+
inferno_supported: 'yes'
|
|
1369
|
+
inferno_tests:
|
|
1370
|
+
- 5.2.07
|
|
1371
|
+
- id: RESPONSE-13
|
|
1372
|
+
SUT: |
|
|
1373
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
1374
|
+
Module to support a bulk data status request according to the
|
|
1375
|
+
implementation specification adopted in § 170.215(a)(4).
|
|
1376
|
+
TLV: |
|
|
1377
|
+
The tester verifies the ability of the Health IT
|
|
1378
|
+
Module to support a bulk data status request according to the
|
|
1379
|
+
implementation specification adopted in § 170.215(a)(4).
|
|
1380
|
+
inferno_supported: 'yes'
|
|
1381
|
+
inferno_tests:
|
|
1382
|
+
- 5.2.05 - 5.2.06
|
|
1383
|
+
- id: RESPONSE-14
|
|
1384
|
+
SUT: |
|
|
1385
|
+
The health IT developer demonstrates the ability of the Health IT
|
|
1386
|
+
Module to support a file request according to the implementation
|
|
1387
|
+
specification adopted in § 170.215(a)(4), including support for the
|
|
1388
|
+
“ndjson” format for files provided.
|
|
1389
|
+
TLV: |
|
|
1390
|
+
The tester verifies the ability of the Health IT
|
|
1391
|
+
Module to support a file request according to the implementation
|
|
1392
|
+
specification adopted in § 170.215(a)(4), including support for the
|
|
1393
|
+
“ndjson” format for files provided.
|
|
1394
|
+
inferno_supported: 'yes'
|
|
1395
|
+
inferno_tests:
|
|
1396
|
+
- 5.3.01 - 5.3.21
|
|
1397
|
+
- id: RESPONSE-15
|
|
1398
|
+
SUT: |
|
|
1399
|
+
The health IT developer demonstrates that the information
|
|
1400
|
+
provided as part of this data response includes data for patients in
|
|
1401
|
+
the group identifier provided during the “group-export” request.
|
|
1402
|
+
TLV: |
|
|
1403
|
+
The tester verifies the information
|
|
1404
|
+
provided as part of this data response includes data for patients in
|
|
1405
|
+
the group identifier provided during the “group-export” request.
|
|
1406
|
+
inferno_supported: 'yes'
|
|
1407
|
+
inferno_tests:
|
|
1408
|
+
- 5.3.05
|
|
1409
|
+
- section: Paragraph (g)(10)(viii) – Documentation
|
|
1410
|
+
steps:
|
|
1411
|
+
- group: Supported Search Operations for a Single Patient’s Data
|
|
1412
|
+
id: DOCUMENTATION-1
|
|
1413
|
+
SUT: |
|
|
1414
|
+
The health IT developer supplies documentation describing the
|
|
1415
|
+
API(s) of the Health IT Module and includes at a minimum:
|
|
1416
|
+
* API syntax;
|
|
1417
|
+
* Function names;
|
|
1418
|
+
* Required and optional parameters supported and their data types;
|
|
1419
|
+
* Return variables and their types/structures;
|
|
1420
|
+
* Exceptions and exception handling methods and their returns;
|
|
1421
|
+
* Mandatory software components;
|
|
1422
|
+
* Mandatory software configurations; and
|
|
1423
|
+
* All technical requirements and attributes necessary for registration.
|
|
1424
|
+
TLV: |
|
|
1425
|
+
The tester verifies the
|
|
1426
|
+
API(s) of the Health IT Module and includes at a minimum:
|
|
1427
|
+
* API syntax;
|
|
1428
|
+
* Function names;
|
|
1429
|
+
* Required and optional parameters supported and their data types;
|
|
1430
|
+
* Return variables and their types/structures;
|
|
1431
|
+
* Exceptions and exception handling methods and their returns;
|
|
1432
|
+
* Mandatory software components;
|
|
1433
|
+
* Mandatory software configurations; and
|
|
1434
|
+
* All technical requirements and attributes necessary for registration.
|
|
1435
|
+
inferno_supported: 'yes'
|
|
1436
|
+
inferno_tests:
|
|
1437
|
+
- 6.6.09
|
|
1438
|
+
- id: DOCUMENTATION-2
|
|
1439
|
+
SUT: |
|
|
1440
|
+
The health IT developer demonstrates that the documentation
|
|
1441
|
+
described in step 1 of this section is available via a publicly
|
|
1442
|
+
accessible hyperlink that does not require preconditions or
|
|
1443
|
+
additional steps to access.
|
|
1444
|
+
TLV: |
|
|
1445
|
+
The tester verifies the documentation
|
|
1446
|
+
described in step 1 of this section is available via a publicly
|
|
1447
|
+
accessible hyperlink that does not require preconditions or
|
|
1448
|
+
additional steps to access.
|
|
1449
|
+
inferno_supported: 'yes'
|
|
1450
|
+
inferno_tests:
|
|
1451
|
+
- 6.6.09
|