Project Summary for Data Access Framework (DAF) FHIR Profile
Visit Project Insight to see the full project details. *
Project Details
| Number | 1143 View Ballot Items List (with NIBs) |
|---|---|
| Name | Data Access Framework (DAF) FHIR Profile |
| Sponsor(s) | Infrastructure and Messaging Work Group |
| Co-Sponsor(s) | Structured Documents Work Group |
| Steering Division | Infrastructure |
| Description | This updated DAF project scope statement is to support updates from pilot implementation, such as Argonaut, updates to account for FHIR DSTU changes, and any additional guidance from Meaningful Use. --Prior Scope-- This project aims to create Fast Healthcare Interoperability Resources (FHIR) Profiles for access to discrete Meaningful Use Stage 2 data as FHIR resource instances. It is not the intention of this project to create new FHIR resource, but work with resource profile owners if necessary. The project intends to use the defined FHIR security methods. This project will not create a profile for document access since this is covered by the Integrating Healthcare Enterprise Mobile access to Health Documents (IHE MHDv2). Artifacts to be produced as part of this project include: 1. Define profiles on selected FHIR resources that define additional search criteria for retrieving those resources. 2. Define a Conformance Resource instance that defines expected system behavior on server side and/or client side for DAF conformant systems. Project expects one for client, and one for servers. 3. Create profiles on selected FHIR resources identifying minimum data and corresponding constraints and value sets for query response. This activity may overlap with C-CDA on FHIR activities to some extent. See notes below on coordination with C-CDA on FHIR project. 4. Define a DAF implementation guide that organizes and provides context for the above artifacts. Coordination with C-CDA on FHIR project: This project will coordinate with the C-CDA on FHIR project to minimize duplicate profiles on common resources. An additional profile will only be created if the C-CDA profile doesn't already exist for the resource, or the C-CDA profile doesn't include required data elements in a current resource to support DAF. Coordination with the C-CDA on FHIR will be done by engagement with the work groups responsible for key resources. Where multiple profiles are required on the same resource, common data elements will be kept in alignment; Where different profiles require different scope in near term, additional work will be done in future to bring back into alignment. The DAF Profile(s) will build from the existing work of the Standards & Interoperability (S&I) Data Access Framework (DAF) Initiative. |
| Project Facilitator | Jonathan Coleman |
| Status | Archived |
| SD Approval Date | Nov 2, 2014 |
| TSC Approval Date | Dec 19, 2014 |
| Type | Ballot - STU to Normative |
| Objectives / Deliverables | Complete analysis, design, draft specification work on FHIR Profiles for DAF - Target: 2015 October/November Submit for DSTU ballot - Target: 2016 February Ballot Comments Reconciliation - Target: 2016 March DSTU Period - 24 months - Target: ~2016 August DSTU updates to align with new versions of FHIR - Target: TBD Normative with or following FHIR - Target: TBD |
| Next Milestone Date | 2019 May WGM |
| Project End Date | 2019 May WGM |
| Project Intent | Implementation Guide |
| Project Need | The nation is reaching a critical mass of Health IT systems (EHRs, Data Warehouses etc.) that comply with data and vocabulary standards. The wide deployment of Health IT systems has created unique opportunities for providers, provider support teams, healthcare professionals and organizations etc. to access and use the patient data that is already collected during clinical workflows. While the Health IT systems provide many access paths through their pre-defined interactions between a user and the system, they are limited in their support for data queries, APIs, or services to access data sets as needed. Where Health IT systems provide data access, they likely do not use industry standard access methods. Increasing support for this class of data access, using industry standards, would enable other applications to expand the ability of users to create value out of their data without having to rely on the predefined access paths. Allowing access to this data can enable a provider to further analyze the collected data to understand a patient's overall health, the health of a provider's collective patient population, and use the data to power innovative new applications and tools to take better care of patients and populations. The Data Access Framework (DAF) is standardizing how data can be accessed within an organization from disparate systems (called as Local DAF) and how data can be accessed from external organizations (called as Targeted DAF). Further DAF addresses both document access and discrete data element with granularity resembling FHIR resources. For Document access, DAF has adopted IHE XCA based protocols for SOAP, IHE MHDv2 for RESTful access which is based on FHIR. For discrete data element based access DAF is pursuing FHIR which is resulting in this PSS. DAF Discrete Data Element Access: DAF has developed a list of data elements starting from Meaningful Use Stage 2 which are expected to be retrieved using queries. These data elements include problems, medications, allergies, patient demographics among others. DAF will be specifying the Query parameters that must be supported for each FHIR resource representing the data elements. In addition DAF may constrain cardinality and vocabularies on FHIR resources being returned as part of the Query Result. Over 80% of the DAF data element needs are covered in the existing FHIR DSTU. So rather than wait for C-CDA on FHIR or other projects creating resource profiles, DAF intends to use existing FHIR DSTU and will focus on the 80% of the data elements available. The remaining 20% we expect to be added as part of the next version of FHIR DSTU and we will adopt then as they get added. The DAF profile is focused on constraining cardinality and vocabulary, is not planning on creating new extensions for data element purposes. The key reason why DAF would like to proceed on this project is to start getting pilots underway on FHIR using the DAF profiles to gather feedback and gain useful experience implementing these profiles in the real-world as soon as possible. These lessons learned will inform the ONC organization to determine various aspects of FHIR such as maturity, ease of implementation, effectiveness, policy frameworks and other aspects necessary for large scale adoption by the industry. |
| Implementers | 1) ONC Standards Implementation and Testing Environment (SITE) 2) Other Pilot recruitment activities currently in progress (Argonaut) |
| Security Risks | |
| External Drivers | |
| Common Names / Keywords/ Aliases | |
| Lineage | |
| Dependancies | 1. FHIR's tools and publication mechanisms 2. Collaboration with C-CDA on FHIR |
| Project Document Repository |
http://wiki.siframework.org/Data+Access+Framework+Homepage FHIR's SVN repository |
| Backwards Compatibility | Don't Know |
| External Vocabularies | |
| Products | FHIR Extensions |
| Joint Copyright? | No |
| External Pjt Collaborators | This project is based on community input from a group of experts and stakeholders across the public, private and academic sectors in the United States. These broad stakeholder groups confer, convene and collaborate as part of the ONC S and I Framework, while offering guidance consistent with their policy making responsibilities. |
| Realm | Realm Specific - Enter "U.S." or name of HL7 Affiliate below |
| HL7 Affiliate | |
| Stakeholders | Clinical and Public Health Laboratories, Immunization Registries, Regulatory Agency, Payors, Other (specify in Misc. Notes below) |
| Vendors | Pharmaceutical; EHR, PHR; Equipment; Health Care IT; Clinical Decision Support Systems; Lab |
| Providers | Clinical and Public Health Laboratories; Emergency Services; Local and State Departments of Health; Medical Imaging Service; Healthcare Institutions (hospitals, long term care, home care, mental health) |
| Ballot Cycle Info | 2015 May Ballot Cycle Info: DSTU Ballot results: Did not meet basic vote requirements Document Name: HL7 FHIR(®) Profile: Data Access Framework (DAF), Release 1 2015 Jan Ballot Cycle Info: COMMENT ONLY Ballot results: Met basic vote requirements. 54 Negatives to reconcile Document Name: HL7 FHIR(®) Profile: Data Access Framework (DAF), Release 1 -US Realm |
| Misc Notes | 2020 August: TJulian: Work Group submitted Withdrawal form; PMO archiving project. 2017 March: TSC approved STU publication request for HL7 FHIR Profile: US-Core, Release1.0.0 through 2019-03-22. Sept 2015: TSC approved publication of HL7 FHIR® Profile: Data Access Framework (DAF), Release 1 at TSC Tracker 8714 through 2019-03-28. |
| U.S. Govt Interest? | Yes |
| USRSC Approval | |
| FMG Approval | |
| ARB Approval | |
| Start Date | Oct 3, 2014 |
* A Project Insight User ID and password is required to access Project Insight. Contact the HL7 PMO at for more information.
Visit the Projects, Ballots and Standards Metrics Excel Report to view projects that are behind 120+ days along with other ballots and standards requiring a Work Group's attention.
Visit the Projects, Ballots and Standards Metrics Excel Report to view projects that are behind 120+ days along with other ballots and standards requiring a Work Group's attention.