Closed qtuan closed 3 years ago
Hello @qtuan , According to https://www.healthit.gov/test-method/standardized-api-patient-and-population-services Paragraph (10)(v)(B)
Technical outcome – Authentication and authorization must occur during the process of granting an application access to patient data in accordance with the “SMART Backend Services: Authorization Guide” section of the implementation specification adopted in § 170.215(a)(4) and the application must be issued a valid access token.
Hello @yunwwang. Many thanks for your answers! A couping of things I'd like to clarify:
Our system DID issue an access token in accordance with the “SMART Backend Services: Authorization Guide” section of the implementation specification adopted in § 170.215(a)(4). That is, support validating the clients who use JWKs to generate JSON Web Signatures. That access token is absolutely required to kick off the bulk export process, as well as polling the export process status, and getting the final response when the export completes, which contains the download URLs for the exported file on the file server. In other words, we completely comply with these official specs of § 170.215(a)(4): https://hl7.org/fhir/uv/bulkdata/authorization/index.html https://hl7.org/fhir/uv/bulkdata/export/index.html
BDE-09 specifically dealing with the access token to access the the exported files from the file server. This access token need NOT be the same with the first access token above. And it allows certain alternative methods, per the quote from my original post, which I put again here: Because requiresAccessToken "Value MAY be false for file servers that use access-control schemes other than OAuth 2.0, such as downloads from Amazon S3 bucket URLs...", per quoted from http://hl7.org/fhir/uv/bulkdata/export/index.html#response---complete-status And that quote come from an official spec of § 170.215(a)(4) as well.
So again, I strongly believe using Azure Storage Shared Access Signature for BDE-09 is a legit method. Would you mind looking into it again?
Here is our Inferno test session if you mind taking a look . You can see that actually we passed almost all the tests, including all those related to the first access token and the whole export process, except the BDE-09 one. https://inferno.healthit.gov/inferno/cL2H4A6lur8/test_sets/test_procedure/
Bulk data export involves two servers: FHIR server and file server. My reading on this paragraph is that "granting an application access to patient data" covers the file server also since the file server holds the patient data.
Then how should we intepret the statement "Value MAY be false for file servers that use access-control schemes other than OAuth 2.0, such as downloads from Amazon S3 bucket URLs..." for? Does it have any practical meaning?
It litterally says requiresAccessToken MAY be false. I would argue that strictly enforcing true value there like what Inferno doing apparently doesn't comply with that statement.
Bulk Data Implementation Guide has broader usage beyond ONC Certificate testing. I think it would better to ask ONC for clarification on Paragraph (10)(v)(B). Would you mind to create a comment?
Will have to go that route. ANW Thanks, @yunwwang!
Hi @qtuan, I am also interested in this question. Have you heard clarifications from ONC? Any responses that could be posted here?
Hi @bforbis, we ended up not contacting ONC, but modifying our solution to pass Inferno. We did kind of routing the export file download via our own service and do access token verification there.
That isn't ideal use of the external file server, but helped us to expedite the certification process. So sorry, I don't have any ONC clarification to share.
Have there been any updates or clarifications on this issue? We are also using another access control scheme (S3).
@medhost-bfindeisen I have not heard any update nor clarification. I suggest you to submit comments through ONC portal that server implementer need clarification on this specific issue.
So that others don't have to go through the troubles of submitting a request with ONC, I am pasting their response here:
Thank you for your inquiry. The § 170.315(g)(10) "Standardized API for patient and population services" certification criterion regulation text states in paragraph § 170.315(g)(10)(v)(B):
Authentication and authorization must occur during the process of granting an application access to patient data in accordance with the “SMART Backend Services: Authorization Guide” section of the implementation specification adopted in § 170.215(a)(4) and the application must be issued a valid access token.
According to the requirements in § 170.315(g)(10)(v)(B), Health IT Modules must issue an application a valid access token during authentication and authorization as per the “SMART Backend Services: Authorization Guide” section of the "FHIR Bulk Data Access (Flat FHIR) (v1.0.1: STU 1)" implementation guide (Bulk FHIR IG). In order for the aforementioned access token to be valid, the application must also be able to access patient data via the access token. The “SMART Backend Services: Authorization Guide” section of the Bulk FHIR IG requires the use of OAuth 2.0 bearer tokens for access control. According to section 5.3.4 of the Bulk FHIR IG, the “requiresAccessToken” element be set to “true” if “both the file server and the FHIR API server control access using OAuth 2.0 bearer tokens.” Therefore, the Inferno testing tool requires the "requiresAccessToken" parameter be set to "true" as part of the test to check if the granted access token is valid for accessing patient data.
At a minimum for the ONC Health IT Certification Program, Health IT Modules certified to the 170.315(g)(10) criterion must support the issuance of a valid access token to an application during authentication and authorization as per the “SMART Backend Services: Authorization Guide” section of the Bulk FHIR IG. However, if the minimum requirements are met, health IT developers may support additional access-control schemes beyond OAuth 2.0 bearer tokens.
This response seems very focused on the issuance
aspect, not the retrieval. This part is interesting as well:
According to section 5.3.4 of the Bulk FHIR IG, the “requiresAccessToken” element be set to “true” if “both the file server and the FHIR API server control access using OAuth 2.0 bearer tokens.” Therefore, the Inferno testing tool requires the "requiresAccessToken" parameter be set to "true" as part of the test to check if the granted access token is valid for accessing patient data.
The if aspect found ^ is odd, so if the file server doesn't use OAuth2 we can set requiresAccessToken
to false
?
@rsmayda The last paragraph clarify the testing requirement.
"At a minimum for the ONC Health IT Certification Program, ... must support the issuance of a valid access token to an application during authentication and authorization ... "
Yes, server can set requiresAccessToken to false if the file server doesn't use OAuth2. Such server does not meet the minimum requirement for ONC Health IT Certification Program.
ONC has clarified this on the latest CCG Update. Issue closed
Problem: Inferno doesn't seem to accept any alternative methods other than access token for BDE-09, even if those are legit. So BDE-09 failed, and BDGV-02 skipped as a result.
The specific alternative method we'd like to discuss: Azure Storage Shared Access Signature (kind of similar to S3 Signed URL).
Why we think that method is legit: Because requiresAccessToken "Value MAY be false for file servers that use access-control schemes other than OAuth 2.0, such as downloads from Amazon S3 bucket URLs...", per quoted from http://hl7.org/fhir/uv/bulkdata/export/index.html#response---complete-status
The questions:
Your official answers will be extremely essential to convince our Proctor. Any prompt response will be much appreciated since tomorrow is our last testing day.
Inferno edition: Program Version: 1.6.0