onc_certification_g10_test_kit 2.0.0 → 2.1.0.rc1
Sign up to get free protection for your applications and to get access to all the features.
- 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 +37 -16
- 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 +89 -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 +243 -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 +16 -12
|
@@ -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
|