Skip to end of metadata
Go to start of metadata


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:

Current CI Build of the Integration Guide is here:

Known Implementations

SDC Implementations


FHIR Structured Data Capture Minutes


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:


FHIR Workflow Minutes

FHIR Workflow WGM



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).



Specification Documentation:  (see history for published versions)

Specification Repository:

Reference implementation (SUSHI):


Meetings (Open to all)

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


FHIR Shorthand Minutes

Subscriptions Backport IG Punchlist


  •  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)


Project Information

Project Insight Entry: Project #1653

Team Leads: Patrick Murtaand Durwin Day

Zulip Channel: FHIR at Scale (FAST): Exchange with/without intermediaries

Meeting Information

HL7 WGM - Jan 2022

Friday, January 21st 1:30-3pm CT (Q3) - ballot comment review with FHIR-I Workgroup

See WHOVA for Zoom links

Meeting schedule


HL7 Ballot Cycle: Jan 2022 - STU

FAST Hybrid/ Intermediary Exchange FHIR IG STU1 Balloting Dashboard

Project Documents

HL7 Artifacts:

Related Connectathon Tracks:

Issues/Hot Topics

  • List issues or link to issues tracking repository (Jira or GForge)


Use labels to organize your project page into its applicable category. 

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:

2021 Ballot Plan

Draft change log for upcoming ballot.

Open HL7 Process items:

Open items:


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:

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


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)

Meeting Schedule

Meetings occur every other Wednesday from 2:00 PM to 3:00 PM Eastern.  The first meeting will be on Wednesday March 24, and will continue through the end of the year.  Calendar links can be found on the HL7 Call Directory (under FHIR Infrastructure), or a Google Calendar link.

Calls are hosted on Zoom.

Meeting Format

As regular working calls, meetings will be as informal as possible.  However, whenever a call is conducting official FHIR Infrastructure work (e.g., voting on Jira tickets), there will be a FHIR-I co-chair in charge of that portion of the meeting, using standard HL7 processes.


  • Promote adoption of the Subscription framework (R4 & R5)
    • Work through implementation with a focused group (in conjunction with the Argonaut Project - an HL7 FHIR Accelerator).
    • Discuss implementation questions / issues / challenges
    • Build out testing and reporting
  • Ensure alignment between the specifications and implementations
    • Look at any areas that implementations vary from the specifications and update (e.g., state that implementers have choices, remove guidance until there is more experience, etc.)
  • Continued work on R5 and R4 Specifications
    • Jira Tickets
      • Resolve ballot issues from the January 2021 Ballot of the Backport IG (see: Jira Search).
      • Resolve any R5 subscription-related issues (see: FHIR-I Open Tickets). 
    • Requesting / Returning Graphs of Resources
    • Security for notifications (e.g., SMART backend authorization, etc.)



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


  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.


FHIR IG Authoring Minutes

  • No labels