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

Difference between revisions of "FHIR: Enhancing Implementation (ONC Grant Project)"

From HL7Wiki
Jump to navigation Jump to search
Line 72: Line 72:
 
#**''2018 May FHIR Connectathon Deliverables:''
 
#**''2018 May FHIR Connectathon Deliverables:''
 
#***Blog: [http://blog.aegis.net/fhir-connectathon-links-17-countries-efforts/ FHIR Connectathon Links Health Technology Efforts From 17 Countries]
 
#***Blog: [http://blog.aegis.net/fhir-connectathon-links-17-countries-efforts/ FHIR Connectathon Links Health Technology Efforts From 17 Countries]
#***FHIR Connectathon Communication Plan (did it differ for May?)
+
#***[https://gforge.hl7.org/gf/project/enhanceccdaimpl/docman/FHIR%20Connectathon%20Administrator/2018%20May%20FHIR%20Connectathon%20Deliverables/Communication%20Plan%20-%20Cologne.xlsx FHIR Connectathon Communication Plan]
 
#***Pre-Connectathon Survey for Participants   
 
#***Pre-Connectathon Survey for Participants   
 
#***Post-Connectathon Satisfaction Survey
 
#***Post-Connectathon Satisfaction Survey

Revision as of 13:40, 12 September 2018

Return to the HL7 wiki Main Page.
Return to the ONC Grant Project Page

Overview

This page supports the FHIR projects occurring within the ONC Grant funded opportunities:

  • Enhancing C-CDA and FHIR Implementation (2015 - 2017)
  • Maturing C-CDA and FHIR Implementation (2018 - )

The collaboration encompasses the following projects to support a grant awarded to HL7 by the Office of the National Coordinator for Health Information Technology (ONC).

Deliverables from the Maturing C-CDA and FHIR Implementation (2018 - ) projects are below.

  1. Project: Unified Terminology Governance Process (UTG); Working Prototype
    • Project Description: 1. Develop a working UTG prototype that further develops the current Proof of Concept (PoC) demonstration including the FHIR toolkit and Terminology Server, and use of JIRA/Confluence workflow) that includes the following capabilities:
      • Creation of sample Complete Harmonization Proposal(s) for any of the following (or any combination of following): V3 vocabulary, V2 vocabulary, FHIR vocabulary, CCDA vocabulary (demonstrate all state transitions in the Workflow, with all screens to manage and document functions) consistent with UTG Functional Requirements
      • Editing existing Draft Harmonization Proposal(s)
      • Submitting Harmonization Proposal(s) for Consensus approval (or abandonment)
      • Auto and Manual Validate Proposals (show Pass and Fail paths)
      • Integration with Confluence for Consensus Discussions
      • Ability to gather votes for approval/rejection
      • Ability to triage Submitted Proposal as per Consensus Decision (Approve, Reject, Controversial, Withdraw, Rework)
      • Ability to process Approved Proposal into Terminology Store; document and enable new release
      • Enabling on-demand extract of any value set
      • Output of terms in V3, CCDA, and V2 vocabulary in publishable form (coremif, Trifolia or Art Decor input format, V2 tools input format)
      • Management of Active Proposals
      • Management of Permissions for Submitters and Consensus Pool
  2. Project: FHIR Ballot Process & Tooling
    • Project Description: Leveraging Confluence and JIRA, design and implement a new ballot management and reconciliation process and tooling.
    1. Deliverable: HL7’s Proposed Revised Ballot Process
      • The new process will improve reliability and support consistency between how feedback is delivered during ballot and during STU and periods between ballot cycles. It will also provide increased transparency around the reconciliation process and give participants easier ways of exploring what feedback has been provided and what decisions are in the process of being made about that feedback.
  3. Project: FHIR Bulk Data Access & Push Project
    • Project Description: Add new capabilities to the FHIR specification to increase support for API-based access and push of data for large number of patients in support of provider-based exchange, analytics and other value-based services; upgrade existing FHIR reference server implementations to more effectively support “Bulk Access and Push” applications.
    1. Deliverable: January 2018 FHIR Connectathon Report
    2. Deliverable: Draft Implementation Guide
    3. Deliverable: Improvements discussed to the SMART Reference Implementation to support changes discussed at the January 2018 FHIR Connectathon and more reliable performance on very large dataset
    4. Deliverable: Initial work with Grahame on extracting the core of the bulk data approach into FHIR primitives
    5. Deliverable: Ongoing discussion with the community around how to name the operation and other implementation details
    6. Deliverables to support the May 2018 FHIR Connectathon in Cologne:
      1. May 2018 FHIR Connectathon Report
      2. Bulk data Issues_2018MayConnectathon
      3. Reference Implementation for the May 2018 Connectathon in Cologne, Germany
      4. [https://github.com/smart-on-fhir/bulk-data-server Reference Implementation code so May 2018 FHIR folks can install and run the server locally. It has a number of features like the ability to produce files with millions of FHIR Resources (it loops through a base set of data and alters the ids and references on the fly), simulate server errors such as an expired token when testing clients, and configure parameters like the time it takes to return a response so client apps can ensure they respond correctly to slow servers.
      5. BCH also built a sample client and posted the code at https://github.com/smart-on-fhir/sample-apps-stu3/tree/master/fhir-downloader .
    7. Deliverable: Push Button Population Health Data: Extending the HL7® FHIR® Standard to Support Bulk Data Export (aka FHIR Bulk Data Export Concepts Paper)
  4. Project: FHIR Ballot Coordinator and Facilitator(s)
    • Project Description: Fulfill the roles and responsibilities of the FHIR Ballot Facilitator to support three FHIR R4 ballots occurring in 2018. Two Facilitators were enlisted to provide specific support for the Orders and Observation Work Group and Vocabulary Work Group, along with other Work Groups as directed by the FHIR Product Director. Responsibilities include:
      • Facilitating the reconciliation of high priority product ballots, including clarification of content before Work Group discussions, proposing block votes, documenting discussions, decisions and actions related to ballot reconciliation and management of change proposals.
      • Working with the designated work group – both leadership and membership – to support the work group issue resolution process
      • Work with task and ballot item submitters to perform triage and prepare dispositions and block votes
      • Work with submitters/stakeholders to clarify and resolve issues, and describe or pre-apply changes for in-work group clarity.
      • Support work group discussion and resolution as required, looking for opportunities to minimize the work group time
      • Apply changes to specifications and task/ballot tracking as appropriate
      • Prepare reports or presentations for Coordinator at least monthly, or additionally as required.
      • Support other activities as defined by the CTO or responsible Product Director or FHIR Ballot Coordinator.
    • Project Description: Fulfill the roles and responsibilities of the FHIR Ballot Coordinator for administering and managing the Ballot Preparation Assistant program to maximize participant experience and outcomes as follows:
      • Work with the appropriate product manager and HL7 CTO; monitor the ballot assistant program.
      • Work with committees to clarify which have the right combination of workload and strategic importance to justify a ballot position, and propose an appointment to the CTO
      • Monitor the process to ensure that work is transparent and consultative so that it builds committee consensus
      • Consult with the co-chairs of committees to ensure that committee process is being followed and consult with the fhir Ballot Facilitator(s) to ensure that committee process limitations are not holding the process up
      • Provide educational materials to co-Chairs and project facilitators on best practices for streamlining the ballot reconciliation process
      • Collect and review monthly reports; provide reports of outcomes and performance to the appropriate product manager, the HL7 CTO, and the TSC as required/requested
      • Provide status updates at one FHIR Management Work Group Meeting during each ballot reconciliation period.
  5. Project: FHIR Connectathon Administrator
  6. Project: Support for FHIR R4 Ballot Processing
    • Project Description: Provide a quality review and pre-processing of the ballot comment spreadsheets for the April 2018 FHIR R4 ballot and facilitate loading them into gForge so comments can be expeditiously reconciled and resolved by the committees. Primary tasks include:
      • Upon close of the FHIR-related ballots at midnight eastern time end of day Monday May 7, begin processing the FHIR ballot responses in the following order:
        • Normative ballots first
        • FHIR Core STU ballot second
        • STU Implementation Guide (IG) ballots third
        • Draft IG ballots fourth
      • For each set of submitted contents, perform the steps identified in http://confluence.hl7.org/display/HL7/Process+for+Importing+Ballot+Spreadsheets+to+gForge
      • While it is difficult to know in advance how many line items of comments will be received, we expect on the order of 2000 lines of comments across all of the ballots
      • Objective is to have this process complete for all IGs by end of day Sunday May 12 prior to the official beginning of the May 2018 WGM.
      • The ballots must be completed sequentially, not in parallel, as there's a need for high-priority ballots to perform additional triaging prior to loading content into gForge after the clean-up process is complete.
    • Deliverable: FHIR Ballot Tip Sheet
    • Deliverable: FHIR R4 Ballot Processing Final Report includes a summary of ballot comment activities, issues encountered and future recommendations.
  7. Project: C-CDA to FHIR Mapping Proof of Concept
    • Project Description: The primary goal of this project is to evaluate the process and effort required to create bidirectional CDA/FHIR mappings that can be tested at FHIR Connectathons and used to assess the effort required to complete developing mappings for all priority CCDA templates to FHIR R4.
    • Deliverable: Draft Mappings of CCD and Discharge Summary Templates. Within this zip file, you will find the following:
      • HL7 Mappings word document - this document explains the mapping files, the testing, and identifies some of the gaps that we found
      • CDA-to-FHIR_mappings excel spreadsheet - this spreadsheet documents the mappings from CCDA to FHIR
      • Test_Results excel spreadsheet - this spreadsheet documents the testing that occurred
      • mappings folder - this folder contains all of our FHIR R4 Mapping Language mapping files
      • source_documents folder - this folder contains source CCDA documents we used for testing. NOTE: All of these were taken from previous CCDA IATs
      • test_output folder - this folder contains the output of our testing
  8. Project: Improvements to FHIR Publication Process
    • Project Description: A series of tooling and process improvements to streamline the preparation, balloting, and publication of 3 new versions of the FHIR standards will be implemented on approximately an 18-month cycle during the project period, applying learnings from experience of the prior years. Under the direction of the FHIR Product Director, who will work with other key FHIR SMEs, this task will implement specific improvements for long-term, sustainable FHIR processes and tools including the following areas:
      • Improvements to the build tools for the core FHIR specification to more efficiently accommodate new features, reduce risk dependencies, improve quality and minimize need for human support
      • Migration of FHIR code and version management to GitHub with enhanced control processes
      • Design and implementation of additional servers and processes to expand and improve FHIR Terminology Services
      • Additional improvements to product management and release processes, including improved integration with registry.fhir.org
  9. Increased support for implementers adopting the FHIR standard
    • Project Description: Development and implementation of tooling upgrades defined in the Fiscal Year 2017 (FY17) FHIR Tooling Roadmap project and other activities related to the business process improvement projects to support implementers, particularly in the following areas:
      • Improvements to the build tools for Implementation Guides to reduce risk dependencies, improve quality and ease of use and minimize need for human support
      • Implementation of various integration tools and processes to better leverage the FHIR registry and links between version control, task tracking, and communications software
      • Implementation of new, advanced tooling to operationalize and improve FHIR terminology services and support the FY17 Universal Terminology Governance Process project, building upon a proof of concept project conducted under FY17 FOA funding.
      • Creation of a testing platform to support ongoing development and adoption of FHIR-compliant systems. The project will include assessment and initial implementation of improved testing and quality assurance tools.


Deliverables from the Enhancing C-CDA and FHIR Implementation (2015 - 2017) projects are below.

  1. Project: FHIR Repository Process
    1. Deliverable: HL7 FHIR Repository Governance, Process and Requirements, Release 1 - August 2017 - This Guide establishes the governance, process and requirements to manage FHIR artifacts in a repository / registry that is accessible to all users. The goal is to ensure the quality and availability of FHIR artifacts and support adoption of FHIR by the healthcare community and regulators.
  2. Project: FHIR Registry Prototype
    1. Deliverable: Beta version of https://registry.fhir.org/
  3. Project: Standardize FHIR Info Models/Transform CIMI Core Logical Models to FHIR Profiles
    1. Deliverable: Documentation:
      1. ClinicalModelingPrimmer.pdf – A document defining Clinical Modeling terms and Synonyms in use. Target audience is clinical subject matter experts that have never modeled before. Revisions will be made available here.
      2. ModelRequestProcess.pdf – A guide detailing out the process for preparing and submitting clinical content that can be standardized and used among and across settings. Target audience is clinical subject matter experts that have never modeled before
      3. ModelRequestSpreadsheetTemplate.xlsx – A template document [with examples] cited in the model request process. This aids the process of organized note taking for clinical subject matters in extracting and documenting the fundamental truths a.k.a data elements related to a clinical topic or a use case.
      4. CIMI and FHIR Tooling Road-Map.pdf – A draft of proposed tooling road-map for the larger CIMI team to discuss and consider during the HL7 plenary meetings in September’ 2017. Revisions will be made available here.
      5. Transforming CIMI core logical models to FHIR profiles - Cognitive Medical Systems Deliverable Report
    2. Deliverable: Content
      1. ONCGrant_FHIR Profiles.zip - FHIR profiles in their XML form. This set contains FHIR profiles for one of each type– Coded, Ordinal and Nominal Labs. 2623 total LOINC codes were addressed, of which 1555 required new CEM models. The CEM models are all created and we continue to work to develop the corresponding FHIR profiles for them all.
      2. ONCGrant_CrossWalk_LOINCLabs_FHIR Profiles.xlsx – Crosswalk document that maps data elements from LOINC to the FHIR data elements, along with a reference to it’s FHIR XML, LOINC codes, VSAC codes, CEM etc.
        1. A subsequent version of this artifact will contain a complete set of FHIR profiles corresponding to the LOINC codes addressed.
  4. Project: FHIR Tools Profile Roadmap
    1. The tooling roadmap is here: http://wiki.hl7.org/index.php?title=FHIR_Tooling_Eco-system.
    2. Registry Requirements Analysis / Registry Gap Assessment - Gevity Consulting Deliverable
    3. Deliverable Documentation: FHIR Core
      1. During the period from May 2017 to September 2017, the FHIR core infrastructure was subject to ongoing maintenance throughout the period. The FHIR code infrastructure includes the following:
        1. the main FHIR build process for the specification itself
        2. the IG publisher
        3. the java validator
        4. tx.fhir.org terminology service
      2. Though these tools are primarily provided for the generation of the published specifications, where ever it is possible for the tools to provide services that are relevant to implementers, they are moved into their own module so these services are available. This means that the tools - and their viability - are tied to implementation success.
        1. Links:
          1. build process documentation: http://wiki.hl7.org/index.php?title=FHIR_Build_Process
          2. gForge: https://gforge.hl7.org/gf/project/fhir
          3. terminology server: http://tx.fhir.org
    4. Deliverable Documentation: IG Publisher
      1. During the period from May 2017 to September 2017, we undertook substantial rework of the FHIR IG Publisher so that it would be possible to run it as a web server rather than as a batch file. The principle purpose of this work is to allow the IG publisher to be used to serve website tools that publish implemetnation guides, the most important of which is the FHIR registry eco-system. The idea is that a web site will provide authoring services, and then use the web services provided to by the IG publisher to actually produce the publication content.
      2. The fundamental problem the work faced was that the IG publisher was structured so that the project was loaded, the configuration analysed, and then all the dependency content was loaded - a process that could take up to a minute. In order to rework the build process so that it was suitable for use as a web service, the code had to be re-organised to be both thread safe and for the large resource dependencies (internal and external terminology servers, conformance service) to be loaded in advance. Most of the work was under the cover improvements around the code structure.
      3. The outcome is a web process that re-uses the same code base as the IG publisher command line version, but can be invoked across the web.
        1. Links:
          1. IG Publisher server: http://hapi.fhir.org/igweb (not functional yet)
          2. Documentation: http://wiki.hl7.org/index.php?title=IG_Publisher_Documentation#Using_the_IG_Publisher_Web_Server
          3. source code: https://gforge.hl7.org/svn/fhir/trunk/build/tools/java/org.hl7.fhir.igweb