This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201801 Bulk Data"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "{{subst::Template for FHIR Connectathon Track Proposals}}")
 
Line 3: Line 3:
 
__NOTOC__
 
__NOTOC__
 
=Track Name=
 
=Track Name=
 +
 +
Bulk Data Access
  
 
==Submitting WG/Project/Implementer Group==
 
==Submitting WG/Project/Implementer Group==
<!-- Who is asking for this track? -->
 
  
 +
FHIR-I
 +
 
==Justification==
 
==Justification==
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
+
 
 +
This track is created at the request of the ONC. ONC provided this justification:
 +
 
 +
* Ecosystem outcome expected to enable many specific use case/business needs: Providers and organizations accountable for managing the health of populations can efficiently access to large volumes of informationon a specified group of individuals without having to access one record at a time. This population-level access would enable these stakeholders to: assess the value of the care provided, conduct population analyses, identify at-risk populations, and track progress on quality improvement.
 +
* Technical Expectations: There would be a standardized method built into the FHIR standard to support access to and transfer of a large amount of data on a specified group of patients and that such method could be reused for any number of specific business purposes.
 +
* Policy Expectations: All existing legal requirements for accessing identifiable patient information via other bulk methods (e.g., ETL) used today would continue to apply (e.g., through HIPAA BAAs/contracts, Data Use Agreements, etc).
  
 
==Proposed Track Lead==
 
==Proposed Track Lead==
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon -->
+
 
See [[Connectathon_Track_Lead_Responsibilities]]
+
Dan Gottleib with support from Grahame Grieve ([[Connectathon_Track_Lead_Responsibilities]])
  
 
==Expected participants==
 
==Expected participants==
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
+
 
 +
* Grahame Grieve
 +
* Cerner
 +
* Epic
 +
* CARIN health alliance
  
 
==Roles==
 
==Roles==
Please include information here regarding how much advance preparation will be required if creating a client and/or server.
+
 
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on -->
+
Data Provider: provides data in the manner specified by the bulk data API
===Role 1 Name===
+
Data Consumer: consumes data in the manner specified by the bulk data API and displays/processes the data
<!-- Provide a description of the capabilities this role will have within the connectathon -->
+
 
  
 
==Scenarios==
 
==Scenarios==
<!-- What will be the actions performed by participants? -->
 
  
===Scenario Step 1 Name===
+
The bulk data track is divided into 3 scenarios:
 +
 
 +
# asynchronous access
 +
# nd-json support
 +
# smart back-end services
 +
 
 +
Participants are encouraged to support either of the following initiation points:
 +
* GET [base]/Patient/[id]/$everything
 +
* GET [base]/Patient/$everything
 +
 
 +
However for the purposes of this connectathon track, data providers can nominate any other URL to initiate the process, as long as it returns a FHIR Bundle
 +
 
 +
===Scenario Step 1: Asynchronous Access===
 
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
:Precondition: <!-- What setup is required prior to executing this step? -->
+
:Precondition: Use the nominated URL for the
 
:Success Criteria: <!-- How will the participants know if the test was successful? -->
 
:Success Criteria: <!-- How will the participants know if the test was successful? -->
 
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->
 
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->

Revision as of 22:53, 22 October 2017


Track Name

Bulk Data Access

Submitting WG/Project/Implementer Group

FHIR-I

Justification

This track is created at the request of the ONC. ONC provided this justification:

  • Ecosystem outcome expected to enable many specific use case/business needs: Providers and organizations accountable for managing the health of populations can efficiently access to large volumes of informationon a specified group of individuals without having to access one record at a time. This population-level access would enable these stakeholders to: assess the value of the care provided, conduct population analyses, identify at-risk populations, and track progress on quality improvement.
  • Technical Expectations: There would be a standardized method built into the FHIR standard to support access to and transfer of a large amount of data on a specified group of patients and that such method could be reused for any number of specific business purposes.
  • Policy Expectations: All existing legal requirements for accessing identifiable patient information via other bulk methods (e.g., ETL) used today would continue to apply (e.g., through HIPAA BAAs/contracts, Data Use Agreements, etc).

Proposed Track Lead

Dan Gottleib with support from Grahame Grieve (Connectathon_Track_Lead_Responsibilities)

Expected participants

  • Grahame Grieve
  • Cerner
  • Epic
  • CARIN health alliance

Roles

Data Provider: provides data in the manner specified by the bulk data API Data Consumer: consumes data in the manner specified by the bulk data API and displays/processes the data


Scenarios

The bulk data track is divided into 3 scenarios:

  1. asynchronous access
  2. nd-json support
  3. smart back-end services

Participants are encouraged to support either of the following initiation points:

  • GET [base]/Patient/[id]/$everything
  • GET [base]/Patient/$everything

However for the purposes of this connectathon track, data providers can nominate any other URL to initiate the process, as long as it returns a FHIR Bundle

Scenario Step 1: Asynchronous Access

Action:
Precondition: Use the nominated URL for the
Success Criteria:
Bonus point:


TestScript(s)

Security and Privacy Considerations