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
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
Documents
Pages
- FHIR Shorthand 2.0 Publication Request
- FHIR Shorthand - Documents
- FHIR Shorthand - PSS
- FHIR Shorthand Updates - PSS
- FSH-Based Implementation Guides
- HL7 FHIR® Implementation Guide: FHIR Shorthand, Release 1
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
Team Members
The content of this macro can only be viewed by users who have logged in.
The content of this macro can only be viewed by users who have logged in.
The content of this macro can only be viewed by users who have logged in.
The content of this macro can only be viewed by users who have logged in.
The content of this macro can only be viewed by users who have logged in.
The content of this macro can only be viewed by users who have logged in.
The content of this macro can only be viewed by users who have logged in.
Description
This project is responsible for reviewing FHIR Methodology and FHIR Data Types tracker items.
Minutes
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"
- Approval
- 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
Meeting schedule
Meetings paused until STU 2
Status
HL7 Ballot Cycle: Jan 2022 - STU 1
FAST Hybrid/ Intermediary Exchange FHIR IG STU1 Balloting Dashboard
Project Documents
HL7 Artifacts:
- Project Scope Statement (PSS)
- FHIR IG Proposal
- Jan 2021 FHIR Connectathon Track Page
- HL7 IG Reliable Routing Over Intermediaries_DRAFT_122120.docx
Implementation Guide:
- Hybrid/ Intermediary Exchange Implementation Guide - 1.0.0 - STU 1 (Published Version)
- Hybrid/ Intermediary Exchange Implementation Guide - CI Build
- Hybrid/ Intermediary Exchange Implementation Guide - Balloted Version (Jan 2022 Cycle)
Related Connectathon Tracks:
- 2021-01 FHIR at Scale (FAST): Exchange with or without Intermediaries
- 2021-05 Hybrid/Intermediary Exchange (Exchange with or without Intermediaries)
- CMS2021-07 ONC FAST Exchange
- 2021-09 ONC FAST - Hybrid/Intermediary Exchange
- CMS 2022 - 07 FAST Infrastructure (Security, Identity, Directory, Exchange)
- 2022 - 09 FAST Infrastructure (Security, Identity, Directory, Exchange)
Issues/Hot Topics
Categorization
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 2.0.0 of the IG. Version 2.0.0 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 (Completed)
Draft change log for upcoming ballot.
Open HL7 Process items:
- E - Notice of Intent to Ballot (NIB) - FHIR- Approval Due 3/7/2021 for May 2021 ballot
- F - Submission for Ballot or Publication
Open items:
- https://jira.hl7.org/browse/FHIR-28444 - zulip chat sent to commenter
- Updated history page - http://hl7.org/fhir/uv/bulkdata/history.html
Connectathons
Project Documents
Historical Documents
- (2020) Bulk Data 1.01 Technical Correction Approval
- (2019) HL7 FHIR® Implementation Guide: Bulk Data, Release 1 Publication Request
- Bulk Data FHIR IG Proposal
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
(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)
- review applied trackers
- 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
- Tuesday, Mar 23, 2021 - FHIR Connectathon Proposals Due
- Sunday, Apr 11, 2021 Final Content Deadline
- Validation QA items
- QA for typos/grammar
- 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
- 2020-11-02 FHIR-Security Meeting Agenda approving version 2 fits within existing PSS
- 2020-05-11 FHIR-I Minutes approving version 2 fits within existing PSS
- 2018 SMART Publication Request and approval
- SMART Application Launch Framework Implementation Guide Release 1.0.0
- 2017 Project Insight #1341
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
- 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)
- review applied trackers
- 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)
- hl7.fhir.uv.smart-app-launch package id
- canonical: http://hl7.org/fhir/smart-app-launch
- defined here: package-list.json : the URL at which this package-list.json will be published
- used here: IG resource base:
- used to be: Canonical = http://fhir-registry.smarthealthit.org for FHIR Resource bases
- issue is the "uv" part of the path...
- http://hl7.org/fhir/uv/smart-app-launch vs
- http://hl7.org/fhir/smart-app-launch
- historically no uv but rules changed for most recent cycle.
- build page: http://build.fhir.org/ig/HL7/smart-app-launch
- html page: http://hl7.org/fhir/smart-app-launch/
- package-list.json STU2 entry "path": "http://hl7.org/fhir/smart-app-launch/STU2"
- history page: http://hl7.org/fhir/smart-app-launch/history.html is empty
- publish change log ?
- Complete Publication Request (EH complete on FHIR-I call)
- Publication approval from FHIR-I
- Publication approval from FMG ?
- Publication approval from TSC ?
- Complete publication readiness checklist (EH link to checklist) Draft
- Work with Grahame and Lynn to publish
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.
Links
- R5
- Subscriptions Overview
- Resource: SubscriptionTopic
- Resource: Subscription
- Resource: SubscriptionStatus
- Jira: Open 'subscription' tickets (rough)
- R4
- Resource: Subscription
- CI Build: Subscription Backport IG
- 2021 January Ballot: Subscription Backport IG
- GitHub: Subscription Backport IG (FSH)
Known Implementations
Product | Subscriptions Actor | Organization | License | Contact | Description |
---|---|---|---|---|---|
Reference Subscription Client https://subscriptions.argo.run/ Source: GitHub | Client | The Argonaut Project / Microsoft | MIT | 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 Additional Documentation can be found here. |
Reference Subscription Server https://server.subscriptions.argo.run/r4 https://server.subscriptions.argo.run/r5 Source: GitHub | Server | The Argonaut Project / Microsoft | MIT | 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
- Zulip: #subscriptions
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
- Issues related to what IG authors must do in terms of content, publishing process and how published IGs look and behave to readers.
- Determine process for agreeing to IGPublisher and template revisions that impact IG appearance/function (including base, HL7, product-family-specific)
- Gathering requirements
- Determining appropriate layer for the change to be made at (international, HL7, family)
- Proposing solutions
- Alignment of proposed solutions across tools/outside the publishing environment (e.g. core publisher, validation, registries, etc.) where there’s an impact.
- Seeking review of solutions
- Prioritizing changes
- Expectations for documentation, test cases, etc.
- Release management & deployment
- Execute that process on proposed changes
- Make (and evaluate) recommendations for change to the ImplementationGuide and related resources that relate to IG authoring & rendering process.
- Document ‘HL7’ and ‘HL7 FHIR’ publication requirements as distinct from general IG publishing requirements as distinct from HL7 IGPublisher requirements.
- Document how organizations using base templates and tools can influence IG rendering
- Grow capacity around template and IGPublisher maintenance (including creation of necessary documentation & education materials to support on-ramping)
- 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
- 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.
- IGs published within HL7 should have a consistent look & feel so that users familiar with one IG can easily navigate and use others
- Process needs to provide a mechanism for experimentation – with results fed back into the consistent look & feel
- 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
- We want our IGs to be easy to read & intuitive - use 'typical' and best practice web navigation techniques
- IGs should be authored in such a way that different developers can easily pick up an existing IG and maintain it
- Where we can get consensus, we will encourage consistency across implementation guide inputs to reduce barriers to converting between tooling suites
- We want to minimize the number of skills and complexity of tooling environment someone needs to have to write an IG
- 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.
- Feature set changes will, where possible, be released on a predictable basis.
Minutes
This is the page for the project work. Related project: FHIR at Scale (FAST): Exchange with or without Intermediaries
Open Issues to address in the document
- What happens if the system can't completely resolve patient identification?
- How does searching for patients to find multiple matches work?
- How does the system handle if it there isn't trusted user authentication id?
- (we could assume that this is handled?)
- What is the impact with regard to records from multiple patient records (different hosts)
- Define a wrapping envelope around the source resources if they can't be changed? (Soap is dead, long live Soap!) (or just a header)
- Explain what 'manage the content vs manage the client' means
- URLs that are purely identification - what if you change them?
Jurgen's diagram: