This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Bulk Data FHIR IG Proposal"
Jump to navigation
Jump to search
(Created page with "{{subst::Template:FHIR IG Proposal}}") |
|||
| Line 13: | Line 13: | ||
| − | = | + | =Bulk Datae= |
<!-- Resource names should meet the following characteristics: | <!-- Resource names should meet the following characteristics: | ||
| Line 29: | Line 29: | ||
<!-- The name of the committee that is proposed to have responsibility for developing and maintaining the IG. --> | <!-- The name of the committee that is proposed to have responsibility for developing and maintaining the IG. --> | ||
| − | [[ | + | [[FHIR Infrastructure]] |
==Committee Approval Date:== | ==Committee Approval Date:== | ||
| Line 36: | Line 36: | ||
==Contributing or Reviewing Work Groups== | ==Contributing or Reviewing Work Groups== | ||
| + | * [[Security]] | ||
| + | * [[Public Health]] | ||
<!-- Additional work groups that may have an interest in contributing to, or reviewing the content of the IG (optional) --> | <!-- Additional work groups that may have an interest in contributing to, or reviewing the content of the IG (optional) --> | ||
* Work Group Name | * Work Group Name | ||
| Line 43: | Line 45: | ||
==FHIR Development Project Insight ID== | ==FHIR Development Project Insight ID== | ||
| + | Pending | ||
<!-- Please specify the id of your work group’s PSS for doing FHIR work that covers the development and maintenance of this IG. (If submitted but not yet approved, just write “pending”.) The link to the PSS template can be found here: http://gforge.hl7.org/gf/download/docmanfileversion/6832/9398/HL7FHIR_DSTUballotPSS-20120529.doc --> | <!-- Please specify the id of your work group’s PSS for doing FHIR work that covers the development and maintenance of this IG. (If submitted but not yet approved, just write “pending”.) The link to the PSS template can be found here: http://gforge.hl7.org/gf/download/docmanfileversion/6832/9398/HL7FHIR_DSTUballotPSS-20120529.doc --> | ||
==Scope of coverage== | ==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 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. | ||
<!-- Define the full scope of coverage for the IG. The scope must be clearly delineated such that it does not overlap with any other existing or expected HL7 Int'l-maintained IG. The scope will be used to govern "what is the set of potential applications to consider when evaluating what elements are 'core' – i.e. in the 80%" | <!-- Define the full scope of coverage for the IG. The scope must be clearly delineated such that it does not overlap with any other existing or expected HL7 Int'l-maintained IG. The scope will be used to govern "what is the set of potential applications to consider when evaluating what elements are 'core' – i.e. in the 80%" | ||
| Line 57: | Line 61: | ||
==IG Purpose== | ==IG Purpose== | ||
| + | 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. | ||
<!-- Why is this IG necessary? --> | <!-- Why is this IG necessary? --> | ||
==Content location== | ==Content location== | ||
| − | + | https://github.com/HL7/bulk-data-export | |
<!-- What is the path within the HL7 github repository (i.e. https://github.com/HL7/xxx) or what is the Simplifier project name? --> | <!-- What is the path within the HL7 github repository (i.e. https://github.com/HL7/xxx) or what is the Simplifier project name? --> | ||
==Proposed IG realm and code== | ==Proposed IG realm and code== | ||
| − | + | uv/bulk-data-export | |
<!-- What is the realm code (2-character country code or 'uv') and IG code to use for the path when the IG is published under http://hl7.org/fhir? E.g. us/ccda --> | <!-- What is the realm code (2-character country code or 'uv') and IG code to use for the path when the IG is published under http://hl7.org/fhir? E.g. us/ccda --> | ||
==Maintenance Plan== | ==Maintenance Plan== | ||
| − | + | The SMART Health IT team intends to provide ongoing support of this implementation guide | |
<!-- What commitment does the WG have to maintaining this IG as the FHIR core specification continues to evolve - particularly if the initial project sponsors are no longer providing resources --> | <!-- What commitment does the WG have to maintaining this IG as the FHIR core specification continues to evolve - particularly if the initial project sponsors are no longer providing resources --> | ||
==Short Description== | ==Short Description== | ||
| + | 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. | ||
<!-- 1-2 sentences describing the purpose/scope of the IG for inclusion in the registry --> | <!-- 1-2 sentences describing the purpose/scope of the IG for inclusion in the registry --> | ||
| Line 79: | Line 86: | ||
==Long Description== | ==Long Description== | ||
| − | + | 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. | |
<!-- 1 paragraph describing the purpose/scope of the IG in more detail for inclusion in the version history --> | <!-- 1 paragraph describing the purpose/scope of the IG in more detail for inclusion in the version history --> | ||
==Involved parties== | ==Involved parties== | ||
| − | + | Initial development by SMART Health IT and subsequent work by the HL7 FHIR Infrastructure, Security and Public Health work groups. | |
<!-- 1 paragraph describing who is sponsoring or involved in creating the IG for inclusion in the version history --> | <!-- 1 paragraph describing who is sponsoring or involved in creating the IG for inclusion in the version history --> | ||
==Expected implementations== | ==Expected implementations== | ||
| + | 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. | ||
<!--Key resources are justified by CCDA, for resources not deemed "key", what interest is there by implementers in using this particular resource. Provide named implementations if possible - ideally provide multiple independent implementations. --> | <!--Key resources are justified by CCDA, for resources not deemed "key", what interest is there by implementers in using this particular resource. Provide named implementations if possible - ideally provide multiple independent implementations. --> | ||
==Content sources== | ==Content sources== | ||
| + | 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 | ||
| + | * The JavaScript Object Notation (JSON) Data Interchange Format, RFC7159. https://tools.ietf.org/html/rfc7159 | ||
| + | * 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 | ||
<!-- List all of the specifications (beyond those in the "standard" (FHIR_Design_Requirements_Sources) list of source specifications) that you’re planning to consult | <!-- List all of the specifications (beyond those in the "standard" (FHIR_Design_Requirements_Sources) list of source specifications) that you’re planning to consult | ||
| Line 99: | Line 122: | ||
==Example Scenarios== | ==Example Scenarios== | ||
| + | * 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 | ||
<!-- Provide a listing of the types of scenarios to be represented in the examples produced for this IG. They should demonstrate the full scope of the IG and allow exercising of the IG's capabilities (all profiles, different types of applications, etc.) --> | <!-- Provide a listing of the types of scenarios to be represented in the examples produced for this IG. They should demonstrate the full scope of the IG and allow exercising of the IG's capabilities (all profiles, different types of applications, etc.) --> | ||
==IG Relationships== | ==IG Relationships== | ||
| − | + | N/A | |
<!-- Are there any IGs this resource depends on or that depend on this IG? --> | <!-- Are there any IGs this resource depends on or that depend on this IG? --> | ||
==Timelines== | ==Timelines== | ||
| − | + | Ready to Ballot Mar. 15 | |
<!-- Indicate the target date for having the IGcomplete from a committee perspective and ready for vetting and voting --> | <!-- Indicate the target date for having the IGcomplete from a committee perspective and ready for vetting and voting --> | ||
Revision as of 16:12, 16 February 2019
This page documents a Pending FHIR IG Proposal
Contents
- 1 Bulk Datae
- 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
Bulk Datae
Owning work group name
Committee Approval Date:
Please enter the date that the committee approved this IGproposal
Contributing or Reviewing Work Groups
- Security
- Public Health
- Work Group Name
- or link
- or "None"
FHIR Development Project Insight ID
Pending
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 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.
IG Purpose
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.
Content location
https://github.com/HL7/bulk-data-export
Proposed IG realm and code
uv/bulk-data-export
Maintenance Plan
The SMART Health IT team intends to provide ongoing support of this implementation guide
Short Description
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.
Long Description
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.
Involved parties
Initial development by SMART Health IT and subsequent work by the HL7 FHIR Infrastructure, Security and Public Health work groups.
Expected implementations
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.
Content sources
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
- The JavaScript Object Notation (JSON) Data Interchange Format, RFC7159. https://tools.ietf.org/html/rfc7159
- 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
Example Scenarios
- 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
IG Relationships
N/A
Timelines
Ready to Ballot Mar. 15
When IG Proposal Is Complete
When you have completed your proposal, please send an email to FMGcontact@HL7.org
