FHIR Chat · Bulk Data IG References US Core · bulk data

Stream: bulk data

Topic: Bulk Data IG References US Core

---

Eric Haas (Jul 16 2019 at 23:58):

Bulk Data IG References US Core and I am assuming the NPRM/USCDI regs will be looking to Bulk Data IG. @Brett Marquard and I have a few questions surrounding certification and certificaiton testing if these assumptions are accurate...

Eric Haas (Jul 17 2019 at 00:03):

• Will the Bulk Data IG be creating a Server CapStatement?
• What part of US Core profiles is in bounds?
  * Must Supports? (NRPM says yes - but neither IG says anything)
  * Search? (NRPM says no - but neither IG says anything)
  * Terminology?
  * Narrative Guidance? ( assuming no )
  * Server CapabilityStatements? (see above)

Eric Haas (Jul 17 2019 at 00:05):

• Are there any Certification tools in place or in the works?

Eric Haas (Jul 17 2019 at 00:10):

• Finally what is a reasonable boundary between bulk data and a RESTful patient based query? e.g search for these 1,3 , 6, 12, 144 patient alllergies?

Josh Mandel (Jul 17 2019 at 00:12):

The Bulk Data spec doesn't require any particular FHIR data profiles -- but it does mention USCDI as an example of a relevant data set.

Eric Haas (Jul 17 2019 at 00:14):

It reads a little stronger than that to me:

pasted image

Josh Mandel (Jul 17 2019 at 00:14):

Per our ballot reconciliation decisions, there will be a server capability statement (see work in progress at https://github.com/HL7/bulk-data/pull/8/files -- comments welcome.)

Josh Mandel (Jul 17 2019 at 00:15):

The headers for that special listing use cases says

This implementation guide is designed to support sharing any data that can be represented in FHIR.

Josh Mandel (Jul 17 2019 at 00:16):

Re: certification tools, this is outside the scope of the spec, but @Vladimir Ignatov at Boston Children's Hospital is working on a test suite, with funding from an ONC LEAP award.

Josh Mandel (Jul 17 2019 at 00:18):

Re: "reasonable boundary", no: bulk data async queries (like REST API synchronous queries) are defined without upper or lower bounds on the "size" of a query or a result set.

Eric Haas (Jul 17 2019 at 00:19):

Ok Got it... thanks.

Eric Haas (Jul 17 2019 at 00:20):

So this what the draft NRPM says...

Eric Haas (Jul 17 2019 at 00:20):

DATA RESPONSE
We propose in § 170.315(g)(10)(i) that the health IT presented for testing and certification must be capable of responding to requests for data on a single patient and multiple patients associated with each of the FHIR resources specified in ARCH Version 1 and consistent with FHIR Release 2 and the Argonaut IG implementation specification. More specifically, we clarify that all data elements indicated as “mandatory” and “must support” by the proposed standards and implementation specifications must be supported and would be in scope for testing. Through this approach, certification will provide for a consistent and predictable starting scope of data from which apps and other services can be developed.
SEARCH SUPPORT
We propose to require in § 170.315(g)(10)(ii) that the health IT presented for testing and certification must be capable of responding to all of the “supported searches” specified in the Argonaut Data Query Implementation Guide Server, which as a reminder we have proposed for adoption as an implementation specification in § 170.215(a)(4). (89) Given that there is not yet a consistent, standardized specification for FHIR servers to handle searches for multiple patients, we clarify that a health IT developer would be permitted to approach searches for multiple patients in the manner it deems most efficient to meet this proposed certification criterion. We note, consistent with the implementation specifications current scope, that conformance would focus on search associated with a single patient's data. However, we reiterate the health IT presented for testing and certification and as implemented must support searches for multiple patients independent of a required standard for such searches.

Josh Mandel (Jul 17 2019 at 00:21):

Indeed.

Eric Haas (Jul 17 2019 at 00:21):

This is technically out of scope for Bulk Data right?

Eric Haas (Jul 17 2019 at 00:22):

but reading tea leaves is this practically in scope for both IGs?

Josh Mandel (Jul 17 2019 at 00:23):

Well, "multiple patients" is a requirement that will need some technical approach. Presumably ONC will provide more detail in a final rule, after reviewing feedback on the proposal and taking into account the publication status of the various IGs.

Josh Mandel (Jul 17 2019 at 00:25):

https://www.federalregister.gov/d/2019-02224/p-447 and https://www.federalregister.gov/d/2019-02224/p-837 also mention "Population API Access" which is a clear fit for Bulk Data.

Eric Haas (Jul 17 2019 at 00:26):

I interpret this as sit tight. Will bring up on tomorrow's Argo R4 for more feedback.

Josh Mandel (Jul 17 2019 at 00:26):

What's the issue on which you're seeking feedback?

Eric Haas (Jul 17 2019 at 00:32):

• The particular way US core guide is written to narrowly support ONC certification single patient use case
• Lack of documentation of how to handle multiple patients
• the Must Supports for multiple patients seems problematic.
• CapabilitysStatements only supports single patient (which may be mitigated by the bulk data cap statement)

Eric Haas (Jul 17 2019 at 00:36):

draft slides here: https://docs.google.com/presentation/d/1wqJj_qcqXxE50NzkQiI9g8MklZImszs8R2afhEXQnlY/edit?usp=sharing

Josh Mandel (Jul 17 2019 at 02:10):

Thanks. I guess from my perspective US Core includes a set of data profiles --- and those are the relevant bits that the Bulk Data spec is referring to. Are you asking whether the US Core spec should define multiple capability sets, like "Support for SMART on FHIR user apps that access the USCDI via synchronous REST API" , and "Support for SMART Backend Service clients that access the USCDI via async bulk exposed"?

Josh Mandel (Jul 17 2019 at 02:11):

It's not a bad idea...

Isaac Vetter (Jul 17 2019 at 02:34):

1) Uscdi is a regulatory concept pointing to hl7 and fhir for real world functionality and constraints. We should be careful to not create infinite loops.
2) we should simply update the .well-known/smart-configuration to advertise client credentials.

Josh Mandel (Jul 17 2019 at 02:36):

For (2), I'm assuming you mean "advertise support for client credentials"?

Josh Mandel (Jul 17 2019 at 02:38):

That's the mechanics of how it's done -- and probably worth mentioning in our Backend Services guides, as a clarification :) We can take that up in FHIR-I. @Ricky Sahu are you able to draft a PR for this?

Ricky Sahu (Jul 17 2019 at 15:23):

Yup I'll get a PR into the repo on this point.

Josh Mandel (Jul 17 2019 at 17:13):

Sweet! So we'd want to document the use of the following in the smart-cofiguration.json:

• token_endpoint
• scopes_supported
• token_endpoint_auth_methods_supported (with values including private_key_jwt)
• token_endpoint_auth_signing_alg_values_supported (with values including at least one of RS384, ES384)

FYI @Ricky Sahu

nicola (RIO/SS) (Jul 17 2019 at 20:36):

Have you decided to specify this in such a detailed way? What is the reason? How about signed urls for bulk api?

Josh Mandel (Jul 17 2019 at 20:41):

This is just for a server to advertise its conformance data when supporting Backend Services.

Josh Mandel (Jul 17 2019 at 20:41):

Doesn't prevent use of signed URLs or other techniques for downloading the resulting files after an export.

Brian Postlethwaite (Aug 14 2019 at 12:38):

Has this completed rectification and been published yet?
(The bulk Data IG)

Josh Mandel (Aug 14 2019 at 12:44):

It's been reconciled; FMG/FHIR-I have approved publication (last week/this week). It's still pending TSC approval.

Brian Postlethwaite (Aug 14 2019 at 12:51):

Cool, thanks.
I'm just closing out the VhDir guide, and it has a reference to it, and would be good to not be referencing the CI build. (even though its just for informative reference)

---

Last updated: Apr 12 2022 at 19:14 UTC