Description

This project will involve updating the existing Structured Data Capture (SDC) Implementation Guide. Specific objectives include:
- Aligning the implementation guide with the forthcoming R4 version of FHIR
- Updating profiles to reflect the experience of early implementers
- Migrating the implementation guide from U.S.-specific to international in scope by relaxing the only requirement that makes the implementation guide U.S.-specific
- Encourage feedback from early and potential future adopters including EHR vendors, payors and clinical research organizations through consultation and connectathons.
- Examine the feasibility and appropriateness of alignment with the SDC project managed by the IHE organization

NOTE: At present, the project does not include updating the companion Structured Data Capture – Data Element (SDC-DE) implementation guide as, thus far, no implementer has expressed interest and it’s not entirely clear that such implementers exist.


Calls are held on Thursdays at 17:00 Eastern: https://hl7-org.zoom.us/j/8583747934?pwd=VnZiWFZsNm1TSk5QWmZlbVJyQVZGdz09

Current CI Build of the Integration Guide is here: http://build.fhir.org/ig/HL7/sdc/

Known Implementations

SDC Implementations

Minutes

FHIR Structured Data Capture Minutes



Description

This wiki was initiated after a joint session at the Oct. 2015 Atlanta meeting on FHIR workflow. It tracks documents related to the FHIR Workflow project.   

Calls are held on Mondays at 14:00 Eastern: https://hl7-org.zoom.us/j/8583747934?pwd=VnZiWFZsNm1TSk5QWmZlbVJyQVZGdz09


Minutes

FHIR Workflow Minutes

FHIR Workflow WGM


Documents

Workflow_Issues.docx

FHIR Shorthand (FSH) is a specially-designed language for defining the content of FHIR Implementation Guides (IG). It is simple and compact, with tools to produce FHIR profiles, extensions, and other artifacts typically found in IGs (as well as the IGs themselves).
https://github.com/FHIR/sushi

Pages

Links:

Specification Documentation: http://build.fhir.org/ig/HL7/fhir-shorthand/  (see history for published versions)

Specification Repository:  https://github.com/HL7/fhir-shorthand

Reference implementation (SUSHI): https://github.com/FHIR/sushi

Chat: https://chat.fhir.org/#narrow/stream/215610-shorthand

Meetings (Open to all)

FHIR Shorthand now discusses all topics of import on the Zulip #shorthand stream.  Come join us!

Minutes

FHIR Shorthand Minutes

Team Members

Mark Kramer

Chris Moesel

Nick Freiter

Ward Weistra

Website: https://simplifier.net/user/wardweistra
Position: Product owner for Simplifier & Forge at Firely

Kurt Allen

Richard R. Esmond

Rick Geimer

Phone: 12099546030
Position: Chief Innovation Officer


Description

This project is responsible for reviewing FHIR Methodology and FHIR Data Types tracker items.


Minutes

Methodology & Data Types


Subscriptions Backport IG Punchlist

Process

  •  HL7 PSS
    • [X] reviewe FHIR-I (voted and approved)
    • [X] FMG
    • [X] Steering Committee
    • [X] TSC
  • Need a list of implementers / projects who intend to implement (only need 2)
  •  IG Proposal
  • [Notice of Intent to ballot (Sunday, November 1, 2020)
    •  Approval
      • FHIR-I
      • FMG
      • TSC
    • (temporary marked up pdf: 
    • Rationale:  "It is anticipated that R4 implementations will be be around for several years
      before full adoption of R5. However, the current (R4) approach to subscriptions
      has many shortcoming and does not publishers to manage what can be subscribed to.
      The reworked R5 subscription"topic-based" pub/sub pattern overcomesthese shortcommings.
      The publication of a standard method of back-porting reworked R5 subscriptions provides
      implementers with a bridge to adoption prior to the adoption of the R5 FHIR standard."
    • Description: "The goal of publishing this guide is to define a standard method
      of back-porting reworked R5 subscription "topic-based" pub/sub pattern to provide
      implementers with a bridge to adoption prior to the adoption of the R5 FHIR standard.


      The Current (R4) approach to subscriptions lacks a proper flexible
      search semantics, doesn't scale across resource types, lacks criteria
      semantics for any named events and a way to advertise what to
      subscribe to. In R5, subscription uses a "topic-based" pub/sub pattern that enables:
      1) FHIR clients to subscribe (optionally with some additional filtering) to a topic
      which defines the resource(s) for the subscription and the events on which
      they happen. 2) The publisher to deliver subscription notification containing
      the combination of data and (optional) attributes to subscribers"

  •  Complete Draft
  •  Connectathon
  • Publication Request
  • [X] Publish for ballot (Friday, November 13, 2020)
  • [Connectathon Jan 2021
  •  Ballot Reconciliation
  • [Publication Request
  • [Publish for ballot (Friday, November 13, 2020)


  •  
  •  

Healthcare and payor organizations have many reasons to transmit data on large populations of patients, such as moving clinical data into an analytic data warehouse, sharing data between organizations, or submitting data to regulatory agencies. Today, bulk export is often accomplished with proprietary pipelines, and data transfer operations often involve an engineering and field mapping project. The bulk data implementation guide (IG) is exciting effort by HL7, Argonaut, and SMART to bring the FHIR standard to bear on these challenges of bulk-data export. This track will focus on introducing new users to the Bulk Data Implementation Guide (IG), and providing a forum for implementers to test the proposed updates to version 1.5 of the IG. Version 1.5 incorporates learnings from implementer experience with v1.0 and has been developed over the past year through a series of open community meetings coordinated by the Argonaut FHIR Accelerator.

Continuous build: http://build.fhir.org/ig/HL7/bulk-data/

2021 Ballot Plan

Draft change log for upcoming ballot.

Open HL7 Process items:

Open items:


Connectathons

Project Documents

Historical Documents


Bulk Data is following the FHIR Implementation Guide Process Flow



Publishing Task list

  •  Resolve and Apply all Trackers
  • Submit Reconciliation Spreadsheet and notify Commenters (BAM)
  •  QA
    • review applied trackers  (question) (BAM/JM)
    • errors and warnings - document and get variances  ()
    • update ignoreWarnings.txt (DG)
    • update to latest ig publisher and review address any new validation checks (DG)
    • final QA read through (GC/BAM)
  • update title and version to proper version 2.0.0 (DG)

  • update Jira tracker file (EH) and will add ignore warnings
  • update package-list.json (BAM) (look at SMART)
    • update current to proper version 2 (bam)
    • update description (DG)
    • figure out the URL conundrum with GG  (EH see zulip chat)
  •  publish change log ?
  •  Complete Publication Request  (BAM)
  •  Publication approval from FHIR-I   
  •  Publication approval from FMG    ?
  •  Publication approval from TSC   ?
  • Complete publication readiness checklist (BAM link to checklist)
  • Work with Grahame and Lynn to publish

The SMART on FHIR v1 IG has been widely adopted for clinician- and patient-facing app integration into EHRs and other FHIR data systems. Based on community feedback, the Argonaut Project has undertaken a 2020 effort to revise and improve the SMART App Launch IG. A key area of focus in adding support for "granular permissions," e.g. to provide access to resources at the category level in addition to the type level. This would allow apps to request narrower access, like "all vital signs" rather than "all observations." 

Continuous build: http://build.fhir.org/ig/HL7/smart-app-launch/

2021 Ballot Plan

Draft change log (see tracker FHIR-30578) for upcoming ballot - full log to be included in the ballot:

  • clarification on launch context scopes
  • new scope syntax for granular permissions
  • POST-based authorization
  • addition of PKCE to authorization requirements
  • profiling on token introspection
  • guidance for communicating permissions to end users
  • update discovery properties to support these changes

Open HL7 Process items:

SMART Project ID : 1341 (TSC Approval Date Aug 17, 2017)  ** Project End Date 2021 May WGM extended to 2024 May WMG **

  • Sunday, Mar 7, 2021 - NIB Deadline

NIB: 2021 May Ballot Cycle

  • Tuesday, Mar 23, 2021 - FHIR Connectathon Proposals Due
  • Sunday, Apr 11, 2021 Final Content Deadline
  • Apr 13 – 14, 2021 - Ballot Readiness sign-off/publish for ballot
  • Publication Checklist

  • Apr 16, 2021 - May 17, 2021 2021 May Ballot Cycle


Connectathons

Project Documents


SMART v2 is following the FHIR Implementation Guide Process Flow


Publishing Task list

  •  Resolve and Apply all Trackers
  • Submit Reconciliation Spreadsheet and notify Commenters (JM)
  •  QA
    • review applied trackers  (question)
    • errors and warnings - document and get variances  (EH)
    • update ignoreWarnings.txt (EH)
    • update to latest ig publisher and review address any new validation checks (EH)
    • final QA read through (EH following Bas QA edits updated by JM)
  • update title and version to proper version 2.0.0 (EH)

  • update Jira tracker file (EH)
  • update package-list.json (EH)
    •  update current to proper version 2 (EH)
    • update description (EH)
    • figure out the URL conundrum with GG  (EH see zulip chat)

Description

This project involves creating and maintaining FHIR core Topic-based Subscriptions and the R4 Subscriptions Backport Implementation Guide. Specific objectives include:
- Aligning the implementation guide with the forthcoming R5 version of FHIR
- Updating profiles to reflect the experience of early implementers
- Encourage feedback from early and potential future adopters through consultation and connectathons.

There are no project-specific calls scheduled at this time.  Questions and discussions occur during the regular FHIR Infrastructure Work Group calls.

Known Implementations

ProductSubscriptions ActorOrganizationLicenseContactDescription

Reference Subscription Client

https://subscriptions.argo.run/

Source: GitHub

ClientThe Argonaut Project /  MicrosoftMIT

Gino Canessa -

Gino Canessa 

A React application that serves as a client to create and test functionality of topic-based subscriptions.

The Client has been written to be as self-contained as possible. The major issue with running the client a web-browser is that it cannot host REST endpoints. Instead, the client connects to the Endpoint Host via Websockets and receives notifications from there.

Since the client is in the browser and the Endpoint Host is public, you can use the client to test against locally hosted servers.

Additional Documentation can be found here.

Reference Subscription Server

https://server.subscriptions.argo.run/r4

https://server.subscriptions.argo.run/r5

Source: GitHub

ServerThe Argonaut Project /  MicrosoftMIT

Gino Canessa -

Gino Canessa

A .Net Core application that implements functionality for topic-based subscriptions.

This system sits in front of a FHIR R4 Server and intercepts all calls relating to these scenarios. It handles triggering and sending notifications via the specified channels to clients. This was done to highlight the areas needed to implement the Server portion of Subscription handling.

An implementer may choose to take a similar approach (of proxying calls), or may use a modified server directly. Either option should result in the same behavior.

Additional Documentation can be found here.


Communication

Description

The IG creation project defines and manages the process and documentation around the IG creation process and HL7-maintained tooling from the international, HL7 and product family perspectives.

Project Scope

  1. Issues related to what IG authors must do in terms of content, publishing process and how published IGs look and behave to readers.
  2. Determine process for agreeing to IGPublisher and template revisions that impact IG appearance/function (including base, HL7, product-family-specific)
    1. Gathering requirements
    2. Determining appropriate layer for the change to be made at (international, HL7, family)
    3. Proposing solutions
    4. Alignment of proposed solutions across tools/outside the publishing environment (e.g. core publisher, validation, registries, etc.) where there’s an impact.
    5. Seeking review of solutions
    6. Prioritizing changes
    7. Expectations for documentation, test cases, etc.
    8. Release management & deployment
  3. Execute that process on proposed changes
  4. Make (and evaluate) recommendations for change to the ImplementationGuide and related resources that relate to IG authoring & rendering process.
  5. Document ‘HL7’ and ‘HL7 FHIR’ publication requirements as distinct from general IG publishing requirements as distinct from HL7 IGPublisher requirements.
  6. Document how organizations using base templates and tools can influence IG rendering
  7. Grow capacity around template and IGPublisher maintenance (including creation of necessary documentation & education materials to support on-ramping)
  8. Compile, vet and publish ‘best practices’ around IG content (where we can’t/don’t want to enforce with tooling/templates)

Future phase

  • IG registry UI/function
  • IG history page appearance

Out of scope:

  • Packages & what the tools consume?
  • Core spec publication
  • We are not a governance body – methodology, “thou shalts” ultimately need endorsement/enforcement by TSC/management groups/methodology groups

Principles

  1. Publishing features should be defined, as much as possible, in a tool independent way. I.e. It should be possible for them to work in both Simplifier and HL7 IGPublisher.  E.g. what metadata must be displayed and where, minimum requirements for navigation, etc.
  2. IGs published within HL7 should have a consistent look & feel so that users familiar with one IG can easily navigate and use others
  3. Process needs to provide a mechanism for experimentation – with results fed back into the consistent look & feel
  4. Not every external organization needs to use the ‘standard’ template – and if you choose to use the standard template, it may impose some expectations on how your IG looks
  5. We want our IGs to be easy to read & intuitive - use 'typical' and best practice web navigation techniques
  6. IGs should be authored in such a way that different developers can easily pick up an existing IG and maintain it
  7. Where we can get consensus, we will encourage consistency across implementation guide inputs to reduce barriers to converting between tooling suites
  8. We want to minimize the number of skills and complexity of tooling environment someone needs to have to write an IG
  9. We want to minimize surprise - IG authors should understand what features are coming and be able to influence what their IG will look like in the future.  We will strive for a mechanism where ideas can be trialed before they impact everyone.
  10. Feature set changes will, where possible, be released on a predictable basis.

Minutes

FHIR IG Authoring Minutes



  • No labels