Difference between revisions of "Bulk Data FHIR IG Proposal"
(→Scope of coverage)
(→Proposed IG realm and code)
|Line 39:||Line 39:|
==Proposed IG realm and code==
==Proposed IG realm and code==
Revision as of 17:28, 20 February 2019
- 1 Bulk Data
- 1.1 Owning work group name
- 1.2 Committee Approval Date:
- 1.3 Contributing or Reviewing Work Groups
- 1.4 FHIR Development Project Insight ID
- 1.5 Scope of coverage
- 1.6 IG Purpose
- 1.7 Content location
- 1.8 Proposed IG realm and code
- 1.9 Maintenance Plan
- 1.10 Short Description
- 1.11 Long Description
- 1.12 Involved parties
- 1.13 Expected implementations
- 1.14 Content sources
- 1.15 Example Scenarios
- 1.16 IG Relationships
- 1.17 Timelines
- 1.18 When IG Proposal Is Complete
- 1.19 FMG Notes
Owning work group name
Committee Approval Date:
Contributing or Reviewing Work Groups
FHIR Development Project Insight ID
Scope of coverage
The core FHIR specification describes an asynchronous request pattern (https://www.hl7.org/fhir/async.html). This Implementation Guide will define secure FHIR export Operations that uses this capability to provide an authenticated and authorized client with the ability to register as a backend service and retrieve any data in a FHIR server, data on all patients in a server, or data on a group of patients while optionally specifying data since a certain date. The implementation guide is not realm-specific.
Today FHIR applications are also built for reporting, analytics, population health, and other use cases which look at patients in aggregate. FHIR’s current APIs are suited to enable access to a few patients at a time or make ad hoc queries but do not cover the bulk data transmission use case. The industry has an need to transmit batches of data for entire populations or cohorts from data systems to apps or other organizations for workflows like provider to payer reporting or data migrations between systems. Additionally regulation is pushing for more standardized methods for transmitting all health data and reporting on it. As the data housed in health systems transitions to the FHIR standard, a standardized method to transfer FHIR server data in large tranches or entire data migrations is needed. To facilitate data transfer between FHIR servers and client applications or other systems, a more technically applicable method for bulk data transfer is required.
Proposed IG realm and code
The SMART Health IT team intends to provide ongoing support of this implementation guide
This Implementation Guide defines secure FHIR export Operations that use this capability to provide an authenticated and authorized client with the ability to register as a backend service and retrieve all data in a FHIR server, data on all patients in a server, or data on a group of patients while optionally specifying data since a certain date.
This Implementation Guide defines secure FHIR export Operations that use this capability to provide an authenticated and authorized client with the ability to register as a backend service and retrieve all data in a FHIR server, data on all patients in a server, or data on a group of patients while optionally specifying data since a certain date. Applications can use the bulk data export functionality to facilitate data transfer among back-end systems, various organizations, and for reporting or public health use cases.
Initial development by SMART Health IT and subsequent work by the Argonaut Project, HL7 FHIR Infrastructure, Security and Public Health work groups.
Boston Children's Hospital is implementing the bulk data export standard through a grant from the ONC. Specifically the SMART Health IT team is taking its prototype bulk data export server and implementing it with the Accountable Care Organization at Boston Children's. The bulk data standard will be used to transmit data between providers and payers in the context of this grant.
The guide will use the following standards:
- HL7 Fast Health Interoperability Resources (FHIR) Release 2, 3, 4, https://www.hl7.org/fhir/
- Newline-delimited JSON(NDJSON) http://ndjson.org
- The OAuth 2.0 Authorization Framework, RFC6749, https://tools.ietf.org/html/rfc6749
- Transport Layer Security (TLS) Protocol Version 1.2. RFC5246. https://tools.ietf.org/html/rfc5246
- The OAuth 2.0 Authorization Framework: Bearer Token Usage, RFC6750. https://tools.ietf.org/html/rfc6750
- JSON Web Signature (JWS), RFC7515, https://tools.ietf.org/html/rfc7515
- JSON Web Key (JWK), RFC7517, https://tools.ietf.org/html/rfc7517
- JSON Web Token (JWT), RFC7519, https://tools.ietf.org/html/rfc7519
- Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants, RFC7521, https://tools.ietf.org/html/rfc7521
- JSON Web Algorithms, RFC7518, https://tools.ietf.org/html/rfc7518
- JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants, RFC7523, https://tools.ietf.org/html/rfc7523
- OAuth 2.0 Dynamic Client Registration Protocol, RFC7591, https://tools.ietf.org/html/rfc7591
- Migration of data between one electronic medical record for clinical data repository and another
- Transmission of patient records for reporting use cases between payors and providers
- Full backup of data contained within a clinical data repository
- Exporting groups of patients between systems that should only have certain access based on business contracts
- Combination of Federated Data Systems for reporting or public health use cases on populations level data
Ready to Ballot Mar. 15
When IG Proposal Is Complete
When you have completed your proposal, please send an email to FMGcontact@HL7.org
Copyright © Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher.