├── team-overview.md ├── okrs-2019-september.md ├── okrs-2022-january.md ├── videos.md ├── okrs-2021-may.md ├── okrs-2019-draft.md ├── okrs-2025-may.md ├── okrs-2020-february.md ├── okrs-2022-may.md ├── README.md ├── README.jmandel.md ├── okrs-2021-jan.md ├── okrs-2024-september.md ├── okrs-2024-may.md ├── okrs-2023-may.md ├── okrs-2022-september.md ├── okrs-2023-january.md ├── okrs-2021-september.md ├── okrs-2020-may.md ├── okrs-2025-september.md ├── okrs-2025-january.md ├── okrs-2023-september.md ├── okrs-2026-january.md └── okrs-2024-january.md /team-overview.md: -------------------------------------------------------------------------------- 1 | # Health Interop Team Overview 2 | 3 | Guiding vision: learning health system & patient-centered interop 4 | 5 | * Identify gaps and areas of under-investment in health interop 6 | * e.g., Slow data flow into patient apps --> Suscriptions 7 | * e.g., Clinical challenges of incorporating assessment data --> Profile develpoment 8 | * e.g., Insufficient patient controls in TEFCA --> Policy advocacy 9 | * Advocate, coordinate, and lead developement of interop standards 10 | * e.g., within HL7 and accelerators like Argonaut Project 11 | * e.g., [FHIR Subscriptions](https://build.fhir.org/subscriptions) 12 | * e.g., [Structured Data Capture](http://hl7.org/fhir/uv/sdc/) 13 | * e.g., [SMART Health Cards](https://spec.smarthealth.cards) and [SMART Health Links](https://hackmd.io/@vci/smart-health-links) 14 | * Bring engineering practices to HL7's spec development 15 | * Open source reference implementations and sandboxes 16 | * e.g., [subscriptions.argo.run](subscriptions.argo.run) 17 | * e.g., fhirpath-lab.azurewebsites.net 18 | * Testing and continuous integration 19 | * e.g., github.com/fhir/auto-ig-builder ([dashboard](https://fhir.github.io/auto-ig-builder/builds.html)) 20 | * Make interop specs easier to learn and adopt 21 | * Libraries and tools 22 | * e.g., github.com/microsoft/fhir-codegen 23 | * e.g., github.com/fhir-typescript/fhir-typescript 24 | * e.g., github.com/brianpos/fhir-net-web-api 25 | * Tutorials, open discussion, education 26 | * e.g., brianpos.com 27 | * e.g., youtube.com/c/GinoCanessa/videos 28 | * e.g., youtube.com/c/JoshMandelMD/videos 29 | -------------------------------------------------------------------------------- /okrs-2019-september.md: -------------------------------------------------------------------------------- 1 | ## OKRs for September 2019 2 | We're following a planning schedule that mirrors the HL7 workging group meeting schedule -- in four-month intervals ending in September, January, and May. 3 | 4 | ## Objective: Make sure the community is ready for a successful Subscriptions connectathon track 5 | P0: 1.0: Ensure that all necessary changes to Subscription and Topic are merged into the main FHIR build before Sunday, August 11 (to make the R5 Connectathon snapshot for tooling). 6 | 7 | P0: 1.0: Prepare connectathon track descriptions including descriptions for Argonaut scenarios 8 | 9 | P1: 0.25: Prepare and publish tutorials for connectathon participants and others to learn about Subscriptions 10 | 11 | P1: 0.1: Document how developers can use our tooling and deploy their own copies of the core components of our reference implementation (server, client, and test harness) including locally via docker 12 | 13 | P2: 0.0: Blog post in early September about our work and its relevance 14 | 15 | P1: 0.5: Solicit feedback on our work by including relevant links for ratings/questions/comments in our published guides 16 | 17 | P2: 0.5: Solicit feedback on our work by creating a survey that at least 50% of connectathon participants re: what worked/didn’t. 18 | 19 | P1/2: 1.0: Prepare and deliver a Webinar covering all the tutorial information 20 | - (Should record / make available to the public, and tie to blog post) 21 | 22 | P1: 0.67: Ensure that participation in connectathon includes representatives from at least three EHR vendors 23 | 24 | P1: 1.0: Ensure that participaiton in connectathon includes at lesat 15 or more participants 25 | 26 | 27 | ## Objective: Build technical documentation and reference implementation for Subscriptions 28 | 29 | P0: 1.0: Merge relevant changes into the FHIR core (FHIR CI Build) – targeting FHIR R5 30 | - Work with Firely and HAPI to get changes in snapshot build 31 | 32 | P0: 1.0: Create a draft Argonaut IG for subscriptions that includes 33 | - P0: 1.0: specific admissions and discharge topic 34 | - P0: 1.0: a profile for single-patient subscriptions (consumer use case ) 35 | - P0: 1.0: a profile for group-based subscriptions (health system, payer, or clearinghouse use case) 36 | 37 | P0: 0.75: Build, document, and publicly deploy a subscriptions server reference implementation to 38 | - P0: 1.0: accept FHIR calls re: Subscriptions 39 | - P0: 1.0: Handle sending notifications to clients via REST-hook and Websocket 40 | - P2: 0.0: Implement Server Side Events (SSE) 41 | - P3: 0.0: Support creation of arbitrary client-defined topics 42 | - P4: 0.5: Support additional (extension) channel types 43 | 44 | P0: 1.0: Build, document, and publicly deploy a subscriptions client reference implementation to 45 | - P0: 1.0: create listener endpoints 46 | - P0: 1.0: create subscriptions and register/receive/display notifications 47 | - P1: 1.0: configure filters with for more prescise subscriptions (e.g., by patient or group) 48 | 49 | P0: 0.80: Build, document, and publicly deploy a testing harness for client / server to 50 | - P1: 1.0: trigger various Topic events by issuing a FHIR operations (e.g., `POST /Encounter`) 51 | - P1: 0.67: enable triggering manually and by schedule 52 | - P1: 0.67: generate any necessary data on-the-fly or load from pre-built Synthea exports 53 | -------------------------------------------------------------------------------- /okrs-2022-january.md: -------------------------------------------------------------------------------- 1 | # OKRs for January 2022 2 | 3 | ## Balloted specifications flow smoothly through HL7 process/pipeline 4 | * P0: (1.0) SMART App Launch v2 is published 5 | * P1: (1.0) SMART Web Messaging ballot resolutions are applied 6 | * P1: (1.0) Argonaut committed to supporting publication 7 | * P1: (0) Publication request submitted 8 | 9 | ## Open source tools and libraries make it easy to work with FHIR and related IGs 10 | * P2: (0.5 -- PR outstanding) Support for SMARTv2 features is merged into SMART App Launcher 11 | * P2: (0.5 -- PR outstanding) Support for SMARTv2 features is merged into SMART `client-js` 12 | 13 | ## Anyone in the FHIR community can easily learn about our team's work and the specs we contribute to 14 | * P0: (1.0) Ask #smart community for volunteeres to lead a SMART on FHIR Connectathon track 15 | * P1: (0.0) Record and publish four short videos on new features of SMART v2 (PKCE, Token Introspection, scopes, and asymmetric client auth) 16 | * P1: (1.0) Record and publish three "transparent consultation" videos from "everyday" interop discussions 17 | 18 | ## SMART Health Cards are widely available, recognized, and used 19 | * P1: (0.8) "Help Desk" support in place to offload this responsibility 20 | * P2: (1.0) An approach to SHC revocation is reviewed and published 21 | * P2: (1.0) SHC revocation is supported by at least one issuer 22 | * P2: (0.0 -- several WIP) At least one state-based issuer supports non-COVID immunization data 23 | 24 | ## Subscriptions IG / R4B 25 | * P0: (0.7, QA ongoing pending R4B publication) Publish Backport IG v0.1.0 based on FHIR R4B 26 | * P0: (1.0) Make available for testing at the next connectathon 27 | 28 | ## Subscriptions R5 29 | * P1: (1.0) Sync changes from Backport IG and R4B 30 | * P1: (1.0) Make available for testing at the next connectathon 31 | 32 | ## Code-Gen: C# (Firely) 33 | * P0: (0.9 -- landed in beta release) Implementation of IDicionary model definitions 34 | * P0: (0.8 -- as beta) Published in NuGet (Firely Net API) 35 | * P0: (0.8) Customized serializers and parsers 36 | * P0: (1.0) For JSON, based on `System.Text.Json` 37 | * P2: (0.6) For XML, based on [`System.Xml` (?)] 38 | * P0: (0.8 -- as beta) Published in NuGet (Firely Net API) 39 | * P1: (?.?) Add option to either throw or 'do what you can' and return an OperationOutcome 40 | * P2: (0.8 -- done but need review) Support for `_summary` 41 | * P2: (0.8 -- done but need review) Support for `_elements` 42 | * P2: (0.5 -- groundwork for bringing data in) Create tooling to better support use of IGs and Extensions 43 | * e.g., classes with ergonomic support for (complex) extensions defined in IG 44 | * A better story than OpenAPI (e.g., discovery, unit testing) 45 | * P5: (0.1 -- early design sketches) Design and implement a process for non-terminology validation (e.g., Fluent Validation, CUE) 46 | * P5: (0.0) Support IG model validation 47 | * P5: (0.0 -- no longer planned) Create a streaming JSON 'modification' transcoder (add/remove/modify elements in single pass) 48 | 49 | ## Madison Team 50 | 51 | * P1: (1.0) Expand the team by posting a job req for at least one new software engineering position (Madison-based or remote) 52 | * P1: (1.0) Dedicate time for a "hack week" project (could be .NET tooling, QR links, structuredefinition editor UI, maybe as a VC Code Browser-based extension) 53 | * P2: (1.0) Publish source on GitHub 54 | * P2: (1.0) Share a short video project video with FHIR community 55 | 56 | ## Other work not captured in OKRs 57 | 58 | * Argonaut project pitches, selection 59 | * Typescript classes/interfaces (codegen WIP) 60 | * FHIR Search Page rewrite 61 | 62 | --- 63 | 64 | ## Lay groundwork for a community-supported comprehensive TS/JS FHIR library [TBD] 65 | 66 | * Propose a roadmap of features 67 | * Identify candidates for a community lead 68 | * point person for decision making 69 | * committed to active development work 70 | * depending on this library for real-world projects 71 | * Select a community lead 72 | * Establish a 'home' for the project 73 | -------------------------------------------------------------------------------- /videos.md: -------------------------------------------------------------------------------- 1 | # FHIR Tutorials, etc 2 | 3 | ### Guided Walk Through FHIR 4 | * [Youtube playlist](https://www.youtube.com/playlist?list=PLMc5uWlrR04diE7Pl7An4d-vnsLJDTC-M) 5 | * Direct file download: 6 | * [#1](https://openaccessvideos.blob.core.windows.net/openaccessvideos/A%20Guided%20Walk%20Through%20FHIR%20%231%20-%20Operations%20Framework%20Overview-9Zmvk9ocB5s.mp4?sp=r&st=2020-10-30T21:12:19Z&se=2099-10-31T05:12:19Z&spr=https&sv=2019-12-12&sr=b&sig=5aXFMhB8TI7Vyx6KYeEJY4sU3ew5qOA0IQWXCciVyLg%3D), 7 | * [#2](https://openaccessvideos.blob.core.windows.net/openaccessvideos/A%20Guided%20Walk%20Through%20FHIR%20%232%20-%20SMART%20Access%20Token%20Format-X2lmbHAeOMg.mp4?sp=r&st=2020-10-30T21:13:12Z&se=2099-10-31T05:13:12Z&spr=https&sv=2019-12-12&sr=b&sig=iP6HkjqytRle3b6aZvx9j%2Br8NG47K1kN35I3nN%2BTaHo%3D) 8 | * [#3](https://openaccessvideos.blob.core.windows.net/openaccessvideos/A%20Guided%20Walk%20Through%20FHIR%20%233%20-%20Resolving%20Bundle%20References-ZK0AKB5PqGM.mp4?sp=r&st=2020-10-30T21:13:33Z&se=2099-10-31T05:13:33Z&spr=https&sv=2019-12-12&sr=b&sig=ktPRN0QT9xXgJ4tVDiSSE76c7F4izp7gwideItPrh8o%3D) 9 | * [#4](https://openaccessvideos.blob.core.windows.net/openaccessvideos/A%20Guided%20Walk%20Through%20FHIR%20%234%20-%20Terminology%20%20-%20-%20CodeableConcepts-_Vwp2gehXug.mp4?sp=r&st=2020-10-30T21:13:45Z&se=2099-10-31T05:13:45Z&spr=https&sv=2019-12-12&sr=b&sig=cnNADPd0AvLGiDO1pmASVYoz4FvNBp0exnjAjQpevbY%3D) 10 | * [#5](https://openaccessvideos.blob.core.windows.net/openaccessvideos/A%20Guided%20Walk%20Through%20FHIR%20%235%20-%20Terminology%20Con't%20--%20Codes%2C%20and%20Codings%20and%20CodeableConcepts%20(Oh%20My!)-rM3SR0MAi74.mp4?sp=r&st=2020-10-30T21:13:56Z&se=2099-10-31T05:13:56Z&spr=https&sv=2019-12-12&sr=b&sig=pgPdDtgZLwn495quSly6JN5LlgvacjVDZ1Ego85Lwo0%3D) 11 | 12 | ### FHIR for Developers Series 13 | * [Youtube playlist](https://www.youtube.com/playlist?list=PLsR-zcO--dypUxuALrmuq70aM-VGX_ql1) 14 | * Direct file download: 15 | * [FHIR for Developers - C# Tutorial 01 Part 01](https://openaccessvideos.blob.core.windows.net/openaccessvideos/FHIR%20for%20Developers%20-%20C%23%20Tutorial%2001%20Part%2001-k9VKg0E1evM.mp4) 16 | * [FHIR for Developers - C# Tutorial 01 Part 02](https://openaccessvideos.blob.core.windows.net/openaccessvideos/FHIR%20for%20Developers%20-%20C%23%20Tutorial%2001%20Part%2002-aP6DRYH-qOI.mp4) 17 | * [FHIR for Developers - FHIR via HTTP](https://openaccessvideos.blob.core.windows.net/openaccessvideos/FHIR%20for%20Developers%20-%20FHIR%20via%20HTTP-eBAQYMT2KtM.mp4) 18 | * [FHIR for Developers - Getting Started](https://openaccessvideos.blob.core.windows.net/openaccessvideos/FHIR%20for%20Developers%20-%20Getting%20Started-m2O6HiA1Z7g.mp4) 19 | * [FHIR for Developers - SMART Overview](https://openaccessvideos.blob.core.windows.net/openaccessvideos/FHIR%20for%20Developers%20-%20SMART%20Overview-4okFXW0Ex1E.mp4) 20 | * [SMART on FHIR - C# with a local web server. Part 01 - Discovering SMART](https://openaccessvideos.blob.core.windows.net/openaccessvideos/SMART%20on%20FHIR%20-%20C%23%20with%20a%20local%20web%20server.%20%20Part%2001%20-%20Discovering%20SMART-250UNIdndeY.mp4) 21 | * [SMART on FHIR - C# with a local web server. Part 01 - Setup](https://openaccessvideos.blob.core.windows.net/openaccessvideos/SMART%20on%20FHIR%20-%20C%23%20with%20a%20local%20web%20server.%20%20Part%2001%20-%20Setup-lrlQjpGdKI0.mp4) 22 | * [SMART on FHIR - C# with a local web server. Part 03 - Setting up a web serverr](https://openaccessvideos.blob.core.windows.net/openaccessvideos/SMART%20on%20FHIR%20-%20C%23%20with%20a%20local%20web%20server.%20%20Part%2003%20-%20Setting%20up%20a%20web%20server-_WNBRxvNORg.mp4) 23 | * [SMART on FHIR - C# with a local web server. Part 04 - Completing a flow](https://openaccessvideos.blob.core.windows.net/openaccessvideos/SMART%20on%20FHIR%20-%20C%23%20with%20a%20local%20web%20server.%20%20Part%2004%20-%20Completing%20a%20flow-3CWpn3FtpX8.mp4) 24 | * [SMART on FHIR - C# with a local web server. Part 05 - Using a token](https://openaccessvideos.blob.core.windows.net/openaccessvideos/SMART%20on%20FHIR%20-%20C#%20with%20a%20local%20web%20server.%20Part%2005%20-%20Using%20a%20token-L0FefJZrOVY.mp4) 25 | -------------------------------------------------------------------------------- /okrs-2021-may.md: -------------------------------------------------------------------------------- 1 | ## OKRs for May 2021 2 | 3 | ## Standards publication and process (balloting, etc) 4 | 5 | ### SMARTv2 6 | * P1 (1.0): Submit ballot request in time for May ballot cycle 7 | * P1: Content from "wip" page integrated and ready for ballot 8 | * P1: Changelog included in spec 9 | * P2 (0.8): May 2021 Connectathon Track 10 | 11 | ### Web Messaging 12 | 13 | * P0 (0.7): Submit IG publication request 14 | * P0 (0.9, need scratchpad query): Finalize reconciliation from 2020Sep ballot 15 | * P2: Continue to engage the community with 16 | * P2 (0.7): a connectathon track, focusing on 1.0 published spec + specific design issues (e.g., capability discovery) 17 | * P2 (0.6): Continue regular SWM calls at less frequent cadence (monthly?) and shorter (60 min) 18 | 19 | ### Subscriptions 20 | 21 | #### R4 "backport" 22 | * P0 (0.7): Submit IG publication request 23 | * P0 (1.0): Triage all ballot comments (Jan 2021 ballot) 24 | * P0 (.53): Resolve all ballot comments (Jan 2021 ballot) 25 | * P1 (0.2): Determine plans for R4 backport support in conversation with two cloud-hosted FHIR platforms 26 | * P1 (0.0): Determine plans for R4 backport support in conversation with two EHR systems 27 | * P2 (0.9): Test at May Connectathon (need to determine what this looks like) 28 | 29 | #### R5 30 | * P0 (1.0): Apply all approved Subscription Jira tickets (up through issue number 29315) 31 | * P1 (1.0): Identify a track lead for May Connectathon (need to determine what this looks like) 32 | * P2 (1.0): Update Subscription resources to FMM2+ (hard deadline is July 2021; now October 2021) 33 | 34 | ## Standards Acceleration / Rapid IG Development 35 | 36 | ### Argonaut 37 | 38 | * P0 (1.0): Participate in project selection (targeting three or four 2021 projects) 39 | * P0 (1.0): Commit to leading or co-leading projects (at least one; up to three) 40 | * P1 (1.0): DevDays June 2021 presentation with project overview 41 | * P1 (1.0): Kick off regular meetings; list details on HL7 conference call tracker; invite community participation 42 | * P1 (0.6): Establish project scope 43 | 44 | ### CARIN 45 | 46 | * P1 (0.4): Establish imaging access project participants 47 | * P2 (0.4): (Pending staffing) Develop draft IG with FHIR, DICOM Web, SMART App Launch, and Token Introspection (updates to Sync for Science 2018 work) 48 | * P3 (0.0): (Pending staffing) Develop reference implementation for consumer imaging access 49 | 50 | ### VCI: Health Cards 51 | 52 | * P0 (0.9): Finalize an "implementation-ready" version of the specification with "v1.0" tag 53 | * P0 (0.0): Re-record intro video and context, given recent updates (cut dependency on DID/SIOP) 54 | * P0 (1.0): Open source tools to validate issuance (data formats, signatures, APIs) 55 | * P1 (0.7): Work with VCI to determine an evaluation plan for UX 56 | * P2 (0.3): Open source verifier SDK with data-driven rules, implementing current USA-based guidelines for products and immunization schedule 57 | * P2 (0.0): Tooling to enable publication of >1 version of the spec to https://smarthealth.cards 58 | 59 | ## Outreach and communications 60 | 61 | ### MS Internal 62 | 63 | * P1 (0.9): Develop guidance on how to interact with standards communities / bodies 64 | * P1 (0.6): Schedule "check-in" meetings with at least 2 teams re: standards guidance 65 | * P2 (0.1): Schedule "office hours" for open FHIR discussion (?) 66 | 67 | ### External FHIR community 68 | 69 | * P1 (1.0): Gino to continue "FHIR for Developers" video series on intro topics for FHIR videos. E.g. for specific languages provide an overview of how to connect to a server or issue queries. Focus on the security + data connectivity >> UI. 70 | 71 | * P1 (0.0): Clean up and publish an external-facing version of "how to interact with standards communities" in our public team repo 72 | 73 | * P1 (0.4): Continue "guided walk through FHIR" youtube series with weekly content 74 | 75 | ## "Community" Tooling 76 | 77 | ### fhir-codegen 78 | 79 | * P0 (1.0): Support Firely with updates and fixes as needed. 80 | * P? (0.7): Improve serialization / parsing performance 81 | * P1 (1.0): Update parsing and serialization benchmarks to compare existing approaches, including latency to first pass + warmed-up throughput 82 | * P1 (1.0): Update internal libraries to System.Text.Json and .Net 5.0 83 | * P2 (1.0): Start creating tagged releases 84 | * Determine structure of releases 85 | * Determine schedule for releases 86 | * P2 (1.0): Brian uses codegen for getting fhir interfaces added to TypeScript DefinitelyTyped repo 87 | * P3 (0.5): Add support for parsing profiles. 88 | * Create C# code that integrates profiles and existing Firely models 89 | * P5 (0.0): Build OpenAPI docs compliant with 'official' FHIR build. 90 | * Add to 'generated' for compatibility checking. 91 | * Pipeline for IGs -> OpenAPI 92 | 93 | #### Not captured in OKR planning 94 | * Support for R4B / R5 new build tooling 95 | 96 | ### SMW library 97 | 98 | * P0 (0.8): available library covers common message groups & discovery 99 | * P0 (1.0): available in NPM 100 | * P1 (0.5): codelab or educational materials to support developer experience 101 | * P2 (0.0): SMART app launcher supports at least one Web Messaging feature 102 | * P2 (0.0): CDS Hooks Sandbox supports at least one Web Messaging feature 103 | -------------------------------------------------------------------------------- /okrs-2019-draft.md: -------------------------------------------------------------------------------- 1 | # Draft 2019 OKRs for “Team Madison” 2 | jmandel@microsoft.com, May 2019 3 | 4 | ## Mission: unlock health data to enable better decisions and care 5 | 6 | The thesis for OKRs below is that we’re uniquely positioned to contribute by advancing open standards, tools, and practices. We can’t do it alone, but we can have outsize impact working with the community. 7 | 8 | --- 9 | 10 | #### Accelerate development of health interop standards and improve their quality... 11 | 12 | #### … via Argonaut: Develop an implementation guide for [admission/discharge Subscriptions](http://bit.ly/argo19-subscriptions) (P0) 13 | 14 | Incorporate R5 Subscriptions proposal (Topic + Subscription resource) into FHIR CI build 15 | 16 | Build a FHIR proxy server to implement R5 Subscriptions proposal in front of an R4 “data-only” server 17 | 18 | Develop or extend a tool to generate V2 ADT messages, based on simulated patients (e.g., Synthea) 19 | 20 | Generate and openly publish a set of sample messages for 100 Patients + medium or large population 21 | 22 | Configure or build tooling to broadcast these ADT message over a simulated timeline (with speed-up) 23 | 24 | Develop a sample Web application to demonstrate client-side subscription API 25 | 26 | Develop a test suite to determine if FHIR Servers are compliant with admission/discharge Subscriptions 27 | 28 | Develop an open-source “server bridge” that can receive FHIR deliveries and forward them to at least one flavor of non-web-accessible endpoints (e.g., by Mobile Push APIs on Android + iOS) 29 | 30 | Publish blog post describing our contributions to the FHIR core spec (Subscriptions) + Argonaut Project 31 | 32 | Draft proposal for “catch up on missed messages” operations 33 | 34 | 35 | --- 36 | 37 | #### Accelerate development of health interop standards and improve their quality... 38 | 39 | #### … via Argonaut: Develop a spec for [SMART Web Messaging and CDS Hooks for radiology orders](http://bit.ly/argo19-messaging) (P0) 40 | 41 | Implement support for radiology ordering in CDS Hooks Sandbox 42 | 43 | Implement support for order-select and order-sign hooks in CDS Hooks Sandbox 44 | 45 | Develop a demonstration CDS Hooks Service that implements user-configurable behaviors to facilitate testing (e.g., “always report appropriate,” or “always report inappropriate”) 46 | 47 | Implement general orders scratchpad UX in CDS Hooks Sandbox 48 | 49 | Develop a demonstration “companion app” for the CDS Hooks Service, that implements UX (e.g., a flow chart or navigation sequence for gathering information and listing appropriate order choices) 50 | 51 | Publish Argonaut specification for CDS Hooks v1 52 | 53 | Publish SMART Web Messaging specification including “scratchpad.*” messages 54 | 55 | Develop a test suite to determine if EHRs are compatible with SMART Web Messaging 56 | 57 | 58 | --- 59 | #### Accelerate development of health interop standards and improve their quality... 60 | 61 | #### … via HL7: Use and improve the FHIR implementation guide framework (P3) 62 | 63 | Apply the FHIR IG publisher to at least one project ourselves (e.g., one Argonaut Guide) 64 | 65 | Contribute at least one performance improvement or bug fix, to begin exploring the codebase 66 | 67 | Interview 3 users (1 MITRE, 1 Argonaut, 1 international) about experience with the tool and publish an open summary of our findings 68 | 69 | 70 | --- 71 | #### Accelerate development of health interop standards and improve their quality... 72 | 73 | #### … via HL7: Evaluate and improve the usability of the FHIR specification by developers (P3) 74 | 75 | Conduct preliminary UX research on the FHIR Spec + IG template. Interview three software developers in the Madison area who agree to be screen + voice recorded, answering "simple" questions about the specification 76 | 77 | Identify MS Healthcare staff resources to provide 1-2 days of UX consulting to assess and suggest an improvement plan for usability of FHIR IG template and core specification. 78 | 79 | 80 | --- 81 | #### Accelerate development of health interop standards and improve their quality... 82 | 83 | #### … via CARIN Alliance: Drive support for frictionless consumer access (P3) 84 | 85 | Participate in CARIN community + board meetings 86 | 87 | Support CARIN publication of an implementation guide for consumer access to healthcare financial data 88 | 89 | Send a representative to June 4 DC Identity Summit 90 | 91 | [Others TODO] 92 | 93 | 94 | --- 95 | 96 | #### Leverage our unique position in Madison to build relationships and grow the team (P1) 97 | 98 | Host one meet-up, educational session, or whiteboarding/brainstorming session per quarter, with at least 10 attendees 99 | 100 | Invite developers from the community to participate in UX testing sessions (e.g., on FHIR specification) 101 | 102 | Build a Madison-area FHIR channel on chat.fhir.org as a local community hub, with 25 subscribers 103 | 104 | Schedule workshop with 2-6 local developers re: their needs for testing, libraries, tools (on Argonaut) 105 | 106 | Identify one or more local companies or health systems that can contribute to a public, heterogeneous collection of real-world-derived HL7 V2 data 107 | 108 | Interview 3 local candidates for a position on our team 109 | 110 | --- 111 | #### Expand and communicate Microsoft Healthcare’s commitment to open standards (P2) 112 | [Not published publicly] 113 | 114 | 115 | --- 116 | #### Reinforce Microsoft’s internal alignment on open healthcare standards (P2) 117 | 118 | [Not published publicly] 119 | 120 | 121 | -------------------------------------------------------------------------------- /okrs-2025-may.md: -------------------------------------------------------------------------------- 1 | # OKRs for March - May 2025 2 | 3 | ## Enhance HL7 Specifications 4 | * P1 (BP) 1.0 Continue progress in reconciling FHIRPath specification toward R3 release 5 | * P1 (BP) 1.0 Continue progress in reconciling SDC specification toward R4 release 6 | * P2 (BP) 0.9 Apply the Patient Administration R6 changes to the core specification 7 | * P1 (BP) 0.7 Draft new spec language describing how to resolve canonical references in the context of a package. 8 | * 0.7 Land guidance in Confluence 9 | * 0.7 Community review + feedback from developers working with FHIR Packages 10 | * P1 (GC) 1.0 Apply the Search and Subscriptions R6 changes to the core specification 11 | * P6 (GC) 0.0 (dependency failed) Publish Subscriptions Backport IG 1.2 12 | * Depends on xver finalization + publication prior to May WGM 13 | * P4 (BP) 0.0 (pending following on with Gino's xver work) FML g4 approved into FHIR R6 14 | 15 | ## Provide Educational Content to support Users of HL7 specifications 16 | * P1 (BP) 0.0 Education Material supporting UploadFIG dependency management - YouTube clip(s) and blog post 17 | * Learning objective 18 | * understand FHIR package deps and the meaning of a dependency tree 19 | * Deploying an IG and its dependency tree to a reference server 20 | * P1 (BP) 0.2 Education Material supporting SDC extraction - At least 2 YouTube clips and 2 blog posts 21 | * Learning objectives 22 | * 0.5 Understand and apply template-based extraction 23 | * Understand and apply definition-based extraction 24 | * P1 (BP) 1.0 Present on SDC Extract and what's New in FhirPath at DevDays 25 | 26 | ## Enhanced tooling to support IG creators and consumers 27 | * P3 (BP) 0.0 FML Tooling Updates for the cross version maps leveraging Gino's database and new extensions pack 28 | * Today, some FML transforms use cross-version extensions (but ad-hoc, may not match formal definitions) 29 | * Want to automatically inject backport extensions when mapping into a version where the necessary property is absent 30 | * P4 (BP) 0.0 UploadFIG to validate cross version extensions using the "new" extension pack 31 | * Prototyping activities: 32 | * P3 (BP) 0.0 FML Validator onto nuget - consider permanent home 33 | 34 | * Unscheduled (BP): Fhirpath debugger-like experience in the FhirPath Lab 35 | * PRs for HAPI/FhirPath.js engines to provide injection interface 36 | * POC in DotNet engine 37 | * Enhancements in FhirPth Lab UI to step through the debug trace information 38 | * Presented experience at DevDays 39 | * *Born from experimentation to produce something similar for FML* 40 | 41 | ## Authors and Implementers can use elements from FHIR versions outside their current version 42 | * P2 (GC) 0.5 Document "automatic" processing algorithm 43 | * P0 (GC) 1.0 Finish "automatic" processing pass of software to run comparisons and save to database 44 | * P0 (GC) 1.0 Generate markdown documentation of all mappings from the database 45 | * P1 (GC) 0.3 (External review in-progress) Review/coordinate review of all mappings 46 | * P0 (GC) 1.0 Generate FHIR Extensions based on the mappings in the database 47 | * P0 (GC) 0.5 (nearing Snapshot 2) Publish the cross-version extensions packages 48 | 49 | ## FHIR community has a concrete plan for R6+ resource development 50 | * P0 (GC) 1.0 Coordinate with Grahame to update proposal prior to Madrid WGM 51 | * [Overview thread from Grahame](https://chat.fhir.org/#narrow/channel/179280-fhir.2Finfrastructure-wg/topic/Proposed.20R6.20change.3A.20Opening.20up.20for.20other.20resources) 52 | * P1 (GC) 0.8 Proposal for naming / registering name(spaces) 53 | * P1 (GC) 0.5 Proposal for versioning best practices 54 | * P0 (GC) 0.0 (Grahame presented instead :) Prepare presentation 55 | * P5 (GC) 0.0 Prepare prototype 56 | * P4 (BP) 0.0 dotnet façade project updated with custom resource/module support 57 | * P1 (GC) 1.0 Work with Firely on plans for how to support this 58 | 59 | ## FHIR community is able to leverage AI productively and ethically 60 | * P0 (GC) 1.0 Build demo application to work with FHIR Search via AI 61 | * P0 ? (changed to MCP) Basic chat-style functionality 62 | * P1 ? (changed to extraction from xver DB) Spec parsing for RAG 63 | * P5 0.0 LOINC / SNOMED / RxNorm for ~~RAG~~ MCP (get FHIR definitions from [Josh](https://github.com/jmandel/fhir-concept-publication-demo)) 64 | * P1 0.5 Define FHIR Operations for FHIR-server feedback (tool calls - MCP?) 65 | * e.g., "validate search", or "parse search" 66 | * P3 0.0 Simple way of comparing models / results 67 | * P0 1.0 Present at DevDays 68 | * P99 (BP) 0.5 FHIRPath tools/resources available as MCP servers (tool calls) 69 | 70 | * Unplanned (JM): AI Club, Connectathon Planning 71 | 72 | ## US Core Supports a Patient Data Feed 73 | 74 | * P0 (JM) 1.0 Achieve Argonaut consensus on subscription parameters/payload for US Core 'futures' page. 75 | * P0 (JM) 0.75 Drive consensus and planning through >=3 focused Argonaut calls. 76 | * P1 (JM) 0.2 Document plan for enhanced subscription topic metadata (computability, v2 maps). 77 | 78 | ## Prior Auth workflows are simplified with MCP-based Tools 79 | 80 | * P0 (JM) 1.0 Build functional MCP prototype using EHR sandbox API to initiate PA request. 81 | * P0 (JM) 1.0 Implement minimal simulated PA Tool endpoint for prototype interaction. 82 | * P1 (JM) 1.0 Record and share video demonstrating prototype PA initiation flow. 83 | * P2 (JM) 1.0 Draft feedback for active PA automation regulations/RFIs using prototype insights; else share demo/insights with >=2 policy contacts. 84 | 85 | Other areas: A2A implmention, TEFCA analysis and QHIN design, quality measure PoC, CMS RFI. 86 | -------------------------------------------------------------------------------- /okrs-2020-february.md: -------------------------------------------------------------------------------- 1 | ## OKRs for Feb 2020 2 | 3 | We follow a planning schedule that mirrors the HL7 workging group meeting 4 | schedule -- in four-month intervals ending in September, January, and May. 5 | (In 2020, the "January" meeting is later than usual, so this doc is scoped 6 | to February 2020.) 7 | 8 | ## Objective: Wrap up Argonaut Encounter Subscriptions IG 9 | 10 | P0: Finalize canonical SubscriptionTopics for Encounter events 11 | * Score: 0.8 (Will still need to keep updated with R5 evolution) 12 | 13 | P0: Complete conformance language in the Argonaut Encounter IG 14 | * Score: 0.8 (One more piece of feedback to incorporate; the occasional updates with R5 evolution) 15 | 16 | P0: Ensure complete support in Reference Implementation 17 | * Score: 0.5 (Still need to align Topic names and add "encounter-end") 18 | 19 | P1: Format the IG for publication using HL7's publisher template ("or something") 20 | * Score: 0.0 (Deferred; WIP given R5 status) 21 | 22 | P1: Publish the guide through Argonaut 23 | * Score: 0.5 (Hard to find the spec from Argonaut wiki; no deep links to the Encounters IG) 24 | 25 | P2: Prepare a community tutorial showing how to build a well-behaved 26 | Encounter Subscriptions client, including error handling (e.g., 27 | missed message detection, out-of-order delivery). 28 | * Score: 0.5 (Have core content from Lets Build at Dev Days; need narrative structure explaining how to think about / approach error handling, etc.) 29 | 30 | Notes: 31 | * Work on the Argonaut project was derailed by focus on core model redesign. 32 | * Work on the Reference Implementation has been reduced by untracked projects (e.g., codegen). 33 | 34 | ## Objective: Prepare FHIR R5 Topic-based Subscriptions for ballot 35 | 36 | P0: Solicit design review from at least two cloud engineering teams 37 | (e.g., re: "eventCount" or other scaling concerns) 38 | * Score: 1.0 (in-depth review with Google + Azure teams, incorporated feedback) 39 | 40 | P0: Complete definition for "built-in" channel types (including Web Sockets, E-mail) 41 | * Score: 0.5 (Defined REST, e-mail; need to define Messaging, Web Sockets; nixed SMS from the list.) 42 | 43 | P0: Ensure full support for built-in channel types in Reference Implementation 44 | * Score: 0.75 (Supporting REST, e-mail so far; draft Web Sockets ahead of what's documented) 45 | 46 | P1: Document how developers can use our tooling and deploy their own copies of 47 | the core components of our reference implementation (server, client, and test 48 | harness) including locally via docker 49 | * Score: 0.4 (Some slideware from DevDays; no published docs) 50 | 51 | P2: Blog post explaining rationale for and technical details of R5 Topic-based Subscriptions 52 | * Score: 0.8 (Wrote a Subscriptions blog, focused pre/post state) 53 | 54 | P3: Build out tooling for arbitrary (computable) SubscriptionTopic definition / testing. 55 | * Score: 0.0 56 | 57 | Notes: 58 | * Too ambitious on timeline - will likely need the entire R5 timeline to get right. 59 | 60 | ## Objective: Wrap up Argonaut PAMA IG 61 | 62 | P0: Complete a last-call for participant feedback 63 | * Score: 1.0 (Not much actual feedback...) 64 | 65 | P0: Format the IG for publication (e.g. using mkdocs or HL7's publisher template) 66 | * Score: 0.7 (mkdocs sites now exists; nav / structure / polish still TODO) 67 | 68 | P1: Prepare a community tutorial with code samples and end-to-end walk-through 69 | demonstrating the three key PAMA interactions. 70 | * Score 0.75 (https://aka.ms/pama-codelab has App Launch, suggestion cards; not yet support for automated ratings via `systemActions` response) 71 | 72 | P1: Put SMART Web Messaging onto HL7's standards track with a Project Scope Statement, 73 | and a "standard for trial use" ballot 74 | * Score: 0.4 (PSS written, approved; no NIB) 75 | 76 | P1: Establish a documentation go-to spot for state-of-the world information, IGs, contact 77 | info, etc. 78 | * Score: 0.0 (Could be folded into IG) 79 | 80 | P2: Build a markdown matrix showing which EHR vendors support which CDS hooks to be 81 | maintained by the community. 82 | * Score: 0.0 (We have a list of names in Excel, but nothing summarized/published) 83 | 84 | P2: Build a markdown matrix showing which qCDSMs support which PLE's guidelines to be 85 | maintained by the community. 86 | * Score: 0.0 (We have a list of names in Excel, but nothing summarized/published) 87 | 88 | 89 | ## Objective: Establish Argonaut 2020 project for "SMART Scheduling Links" 90 | 91 | P0: Submit 2020 project proposal for "SMART Scheduling Links" 92 | * Score: 1.0 93 | 94 | P1: Develop a list of supporting organizations including at least three Argonaut participants 95 | * Score 0.75 (We had >3 supporting orgs, but this didn't get selected as a 2020 project :-( ) 96 | 97 | 98 | ## Objective: Develop an open-source Patient On-ramp to TEFCA access 99 | 100 | P0: Determine the right organizational entry-point (e.g., within Carequality, Commonwell) 101 | * Score: 0.2 (Conversations with CW, CEQ leadership, but no strategy to take this forward) 102 | 103 | P0: Discuss opportunities to co-develop with at least two outside organizations 104 | * Score: 0.2 (Conversations within CARIN; no concrete plans developed) 105 | 106 | P0: Publish a design document that covers identity proofing plug-ins, app registration 107 | allowing for public client registration, developer-facing questionnaires, published 108 | app lists, and a SMART proxy to TEFCA. 109 | * Score: 0.0 110 | 111 | P1: Hire two software engineers to begin work on MVP 112 | * Score: 0.2 (Job req published; interviews not started) 113 | 114 | P1: Conduct a "design sprint" or similar session to establish MVP user experience 115 | * Score: 0.0 (Brainstorming session scheduled post-HIMSS) 116 | 117 | -------------------------------------------------------------------------------- /okrs-2022-may.md: -------------------------------------------------------------------------------- 1 | # OKRs for May 2022 2 | 3 | ## SMART specs move through the HL7 publication pipeline 4 | * P0: (1.0) SMART Web Messaging publication request in place 5 | * P0: (1.0) SMART Web Messaging publication request approved by FHIR-I, FMG 6 | * P0: (1.0) SMART Web Messaging published 7 | * P4: (0.1) SMART App Launch Technical Correction requested 8 | * only if Vassil is willing to carry the torch 9 | 10 | ## Open source tools and libraries make it easy to work with FHIR and related IGs 11 | * P0: (0.0) Vlad has reviewed outstanding PR for SMART Launcher 12 | * P3: PR Merged 13 | * P0: (0.2) Vlad has reviewed outstanding PR for SMART Client-JS 14 | * P3: PR Merged 15 | 16 | ## Argonaut "Patient Access Endpoints" project enables a "connect to my provider" UX 17 | * P0: (1.0) Propose design for patient access endpoints and branded organizations 18 | * P0: (0.8) At least one Argonaut EHR vendor commits to implementing design 19 | * P1: (1.0) Demo JSON file and .smart-configuration files supporting discovery 20 | * P2: (1.0) Demo app rendering tiles from sample data 21 | 22 | ## Argonaut "EHI Export" project defines a wrapper API for vendor EHI export capabilities 23 | * P0: (1.0) Design feedback shared on weekly calls 24 | * P3: (0.0) Prototype server implementing a bare-bones export on top of static data 25 | * P3: Automated approvals so clients can test the UI 26 | * P5: Provider-side "queue" UX simulating HIM staff view of pending requests 27 | 28 | ## Argonaut "SMART Health Links" project is ready for summer launch 29 | * P0: (1.0) Define initial use case for public health ("all my immunizations") 30 | * P1: (0.5) Define one more initial use case 31 | * Candidate: Insurance data (link to CARIN BB Profile) 32 | * Candidate: COVID lab results from at-home test kit 33 | * P2: (1.0) Choose a top candidate from our three API designs (OAuth, Redirects, GNAP) 34 | 35 | ## Define a new pattern for community collaboration upstream from the standards space (e.g., to support work from cloud vendors) -- e.g., "Amplifier" 36 | 37 | * Pitch: if you've got a project that needs rough consensus and isn't ready for a formal SDO process (e.g., how we started CDS Hooks and SMART Health Cards), Amplifier provides a home and a template to help you launch a community project, including guidelines for running the project, a namespace for publishing your materials, and a framework for lightweight governance 38 | * P0: One-pager explaining triage process to determine what should happen in FHIR "core" vs HL7 IGs, vs "community collaboration", vs "one company's IGs" 39 | * Clinical vs mechanical specs: are both in scope? Could clinical projects be advertised for Argonaut participation? 40 | * How does each project define its relevant "rough consensus" community? 41 | * Long-term home in community space vs consensus space 42 | * Transition plan: explicit expectation when a project stars explaining the intended disposition 43 | * Governance / editorial process: for this to be a meaningful effort, it's important that we focus on projects where the set of editors spans more than one company, and where some level of rough consensus is required to label a spec as "published" -- see, e.g., https://github.com/cds-hooks/docs/blob/master/GOVERNANCE.md from CDS Hooks, or https://infra.apache.org/new-committers-guide.html 44 | * P0: (0.0) Review proposed process: with at least two cloud vendors 45 | * P1: (0.0) Define naming conventions for canonical URLs in "community IG space" 46 | * P4: (0.0) Establish licensing conventions for "community IG space" 47 | * P4: (0.0) Decide on a home 48 | * Candidate: FHIR Community Process (https://www.fhir.org/community/process) 49 | * Candidate: new FHIR Acclerator 50 | * Candidate: an existing FHIR Accelerator 51 | 52 | ## Subscriptions 53 | * P0: (0.8) Sync all changes between R4B+IG and R5 until R4B+IG are published 54 | * P0: (1.0) R5 QA Completed 55 | * P0: (0.8) Publish Backport IG (depends on R4B publication) 56 | * P0: (1.0) QA Completed 57 | * P0: (1.0) Publication request in place 58 | * P0: (0.5) Publication request approved by FHIR-I, FMG 59 | * P0: (0.0) Published 60 | * P?: (0.7) Have connectathon track available, either as a standalone track or part of an Argo-wide track (?) 61 | * P0: (0.9) RI is up to date with R4B+IG and R5 62 | * P1: (1.0) Prior to connectathon 63 | * P0: (0.9) With final R4B/IG version 64 | 65 | ## Code-Gen 66 | * P0: (0.5) Define 'IG Export Language' interface 67 | * P0: (0.1) At least one language implemented: Firely C#, TypeScript, HAPI Java 68 | * P5: (0.0) All of: Firely C#, TypeScript, HAPI Java are implmenented 69 | * P5: (0.0) Create basic Rust language export 70 | * P5: (0.3) Design and implement a process for non-terminology validation (e.g., Fluent Validation, CUE) 71 | * P5: (0.1) Support IG model validation 72 | 73 | ### TS/JS FHIR library 74 | * P0: (1.0) Complete MVP of TypeScript (v2) library 75 | * P0: (1.0) Establish a 'home' for the project 76 | * P1: (0.0) Record basic educational content 77 | * P1: Client application (React?) 78 | * P3: Server applicaiton (Node?) 79 | * P4: (0.5, Gino *de facto*) Select a community lead 80 | 81 | ## FHIR Core Specification 82 | * P0: (0.6) Complete pass of FHIR Search Page 83 | * P?: (0.0) Review tickets submitted by our team and apply or submit PRs to apply the resolutions 84 | * ?P?: (0.0) Identify 3 key areas of the spec that we want to improve and apply outstanding tickets to resolve them (targeting 40 hours of "community service" work)? 85 | 86 | ## Specs balloted through HL7 receive productive critical feedback 87 | * P1: (0.4) Coordinate MS-internal review plan for May ballot cycle 88 | * P1: (0.5) call to review candidate specs and identify "matchmaking" opportunities with product teams 89 | * P2: (0.5) Review/comment/vote on at least '##' ballot publications 90 | 91 | ---- 92 | 93 | # Work that wasn't covered in OKRs 94 | 95 | ## SMART App State 96 | * Design, reference implementation 97 | 98 | ## Brian joined the team! 99 | * .NET facade 100 | * Terminology services integration to support serach 101 | * Fhirpath testing 102 | * PA and SDC editorial work 103 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Team 2 | Docs about our team, working on Healthcare Standards and Interoperability. 3 | 4 | Our mission is to enable / improve digital healthcare. We are a public-facing team, focused on standards and interoperability. We contribute to specifications (e.g., [FHIR](http://hl7.org/fhir)) and Open Source Software (below). 5 | 6 | # Standards Governance Roles 7 | * HL7 Board Member 8 | * HL7 Technical Steering Committee Member 9 | * FHIR Management Group Members 10 | * FHIR Work Groups 11 | * FHIR Infrastructure co-chairs 12 | * Patient Administration co-chair 13 | 14 | # Selected Accelerator Involvement 15 | * Argonaut Project 16 | * Steering Committee Member 17 | * Subject matter expert and project management contributions 18 | * IG Authoring 19 | * Reference implementations 20 | * CARIN Alliance 21 | * Board Member 22 | * Review IGs 23 | * Reference Implementation (unofficial) 24 | * DaVinci 25 | * Review of IGs 26 | * Reference implementations (unofficial) 27 | * FHIR at Scale Taskforce (FAST) 28 | * Review of IGs 29 | * Implementation testing 30 | * Gravity Project 31 | * Review of IGs 32 | * Support tooling (SDOH / Questionnaire) 33 | * Helios 34 | * Allied work (e.g., USCDI, US Core) 35 | * Vulcan 36 | * Advisory Board Member 37 | * Project participation 38 | 39 | 40 | # Selected Specification Work / Contributions 41 | * Implementation Guides 42 | * [SMART App Launch](https://github.com/HL7/smart-app-launch) 43 | * [User-access Brands and Endpoints](https://build.fhir.org/ig/HL7/smart-app-launch/brands.html) 44 | * [SMART Health Cards](https://spec.smarthealth.cards/) 45 | * [SMART Health Links](https://docs.smarthealthit.org/smart-health-links/spec/) 46 | * [Subscriptions Backport IG](https://www.hl7.org/fhir/uv/subscriptions-backport/) 47 | * [Bulk Data](https://www.hl7.org/fhir/uv/bulkdata/) 48 | * FHIR Write (in development, per category) 49 | * e.g., [FHIR Write for Vital Sign Observations](https://build.fhir.org/ig/HL7/US-Core/fhir-write.html) 50 | * [Patient Request for Corrections](https://build.fhir.org/ig/HL7/fhir-patient-correction/) 51 | 52 | * FHIR Core Specification 53 | * [FHIR R6](https://build.fhir.org/) 54 | * [FHIR Extensions Pack](https://build.fhir.org/ig/HL7/fhir-extensions/) 55 | * [FHIR Cross-Version Extensions](https://github.com/HL7/fhir-cross-version) 56 | * [FHIR Test Cases](https://github.com/FHIR/fhir-test-cases) 57 | 58 | # Selected OSS Project Work / Contributions 59 | * [DefinitelyTyped FHIR](https://www.npmjs.com/package/@types/fhir) 60 | * TypeScript FHIR definitions hosted in DT 61 | * [FHIR Candle](https://github.com/GinoCanessa/fhir-candle) 62 | * Reference-implementation base FHIR server 63 | * Hosted - [Subscriptions RI](https://subscriptions.argo.run/) 64 | * Hosted - [Vitals Write Server RI](https://vitals-server.ri.argo.run/) 65 | * Hosted (WIP) - [CDex Server RI](https://cdex-server.ri.argo.run/) 66 | * [FHIR Code Generator](https://github.com/microsoft/fhir-codegen) 67 | * Library and related utilities to create source code from FHIR specifications. 68 | * [FHIR JS](https://github.com/smart-on-fhir/client-js) 69 | * JavaScript client for FHIR 70 | * [FHIR SDC Helpers](https://github.com/brianpos/fhir-sdc-helpers) 71 | * Unofficial set of helper functions to ease working with the FHIR R4 Structured Data Capture Extensions in Javascript and TypeScript. 72 | * [FHIR WebApi Facade](https://github.com/brianpos/fhir-net-web-api) 73 | * An unofficial WebAPI controller implementation for exposing a HL7 FHIR on the Microsoft .NET (dotnet) platform. 74 | * [Questionnaire Validation Tools](https://github.com/brianpos/fhir-net-web-api/tree/develop/src/Hl7.Fhir.StructuredDataCapture) 75 | * [FHIRPath Lab](https://github.com/brianpos/fhirpath-lab) 76 | * Open source tool to simplify testing fhirpath expressions against the various open source fhirpath engines available. 77 | * [Hosted](https://fhirpath-lab.azurewebsites.net/) 78 | * [FHIRPath Validator](https://github.com/brianpos/Hl7.Fhir.FhirPath.Validator) 79 | * Static analysis tool that can help ensure that a valid fhirpath expression is valid for the context in which it is to be used. 80 | * [Firely Net SDK](https://github.com/FirelyTeam/firely-net-sdk) 81 | * .NET SDK for FHIR 82 | * [SMART App Launcher](https://github.com/smart-on-fhir/smart-launcher) 83 | * Launcher for SMART on FHIR applications 84 | * [Hosted](https://launch.smarthealthit.org/) 85 | * [SMART Health Cards Dev Tools](https://github.com/smart-on-fhir/health-cards-dev-tools) 86 | * Developer tools for validating SMART Health Cards 87 | * [Upload FIG](https://github.com/brianpos/UploadFIG) 88 | * Tool to deploy a FHIR Implementation Guide to a FHIR Server 89 | * User Brands Reference 90 | * [Brand Editor](https://github.com/argonautproject/patient-access-brands-editor/) - [Hosted](https://brand-editor.argo.run/) 91 | * [Brand Browser](https://github.com/argonautproject/brand-browser) - [Hosted](https://brand-browser.argo.run/config) 92 | 93 | # Educational Content 94 | * Josh Mandel's [YouTube Channel](https://www.youtube.com/c/JoshMandelMD/videos) 95 | * [A Guided Walk Through FHIR](https://www.youtube.com/playlist?list=PLMc5uWlrR04diE7Pl7An4d-vnsLJDTC-M) 96 | * [Discussions on interop](https://www.youtube.com/playlist?list=PLMc5uWlrR04c4IgByY4ak09qv7F1oxzGL) 97 | * [FHIR Tools, etc.](https://www.youtube.com/playlist?list=PLMc5uWlrR04eaaL5m4F7CvlKJ0ia7QdQY) 98 | * [Presentations](https://www.youtube.com/playlist?list=PLMc5uWlrR04fAuUgl2rO79jO49VOhq-FY) 99 | * Gino Canessa's [YouTube Channel](https://www.youtube.com/c/GinoCanessa) 100 | * [Looking at the FHIR Specification](https://www.youtube.com/playlist?list=PLsR-zcO--dypwthv7_QXwLMXKkdqsQvAm) 101 | * [FHIR Search](https://www.youtube.com/playlist?list=PLsR-zcO--dypskMPAd8r-EoiQOCdiYrux) 102 | * [SMART on FHIR](https://www.youtube.com/playlist?list=PLsR-zcO--dyp0cnv1AbOZ2EUC36tMLpXY) 103 | * [FHIR Profiles and Validation](https://www.youtube.com/playlist?list=PLsR-zcO--dyo9eNVVTMD3OdPSKQ67kG8e) 104 | * [FHIR in C#](https://www.youtube.com/playlist?list=PLsR-zcO--dypP688ilpL3rAiYjWnZbubA) 105 | * [FHIR Test Servers](https://www.youtube.com/playlist?list=PLsR-zcO--dyqQv87yZ2AXb5cJG8ubCDeJ) 106 | * [Connectathon 28 - FHIR Subscriptions](https://www.youtube.com/playlist?list=PLsR-zcO--dyqViyu-cb70JExLw7HJJf06) 107 | * Brian Postlethwaite's [Blog](https://brianpos.com) 108 | * [Creating your own FHIR Server with Microsoft .net](https://brianpos.com/2022/04/19/create-your-own-net-fhir-server-fast/) 109 | * [Adding Resource Validation](https://brianpos.com/2022/08/25/adding-resource-validation/) 110 | * [Unit Testing your FHIR Server/Facade](https://brianpos.com/2022/05/02/unit-testing-a-fhir-server/) 111 | * [Supporting Canonical Versioning in a FHIR Server](https://brianpos.com/2022/12/13/canonical-versioning-in-your-fhir-server/) 112 | * [FHIR Azure Function Apps - Part 1](https://brianpos.com/2022/07/12/fhir-with-azure-function-apps/) 113 | * [More FHIR with Azure Function Apps](https://brianpos.com/2022/08/25/more-fhir-with-azure-function-apps/) -------------------------------------------------------------------------------- /README.jmandel.md: -------------------------------------------------------------------------------- 1 | # README: jmandel@microsoft.com 2 | 3 | ## Why a README? 4 | 5 | This doc is a “manager README”: a guide to set expectations for new team members. The aim is to share mindset, style, preferences, and quirks. I’m still new to Microsoft and building a small team in “remote” Madison, WI. Foremost I’ll aim for transparency within the team and reflecting outward (to the community) and inward (to Microsoft). 6 | 7 | ## About me 8 | 9 | I’m focused at the intersection of healthcare and technology – spurred by my own experience (and frustration) working in hospitals and clinics, and motivated by the belief that technology will change the way we maintain wellness and manage disease. Over the course of my career I’ve dug farther and farther “down the stack” to lay infrastructure that supports a better healthcare developer experience, with a focus on open protocols and standards for data, communication, and the integration of apps/tools/advice into clinical workflow. I tend to value designs that are 1) as simple as possible, 2) clever, and 3) build on real-world, working systems. 10 | 11 | ## About you 12 | 13 | First, welcome! I’m so excited you’re on board – and we’ve got our work cut out for us :-) 14 | 15 | Your job is to help us build better standards, explain how they work, and test them in the real world. You should expect a mix of engineering, product design, “customer” engagement across the health standards community (with a variety of stakeholders, who may or may not be Microsoft customers in a conventional sense). 16 | 17 | ## About “Team Madison” 18 | 19 | We're growing out a new group from scratch. It’s a tremendous privilege, and a challenge. I'm exhilarated about the opportunity and will be asking for your help in recruiting and evaluating candidates (as part of a shared process with the broader team in Redmond). Over time we’ll explore differentiated roles and responsibilities; but as we get started, my bias is to share knowledge and responsibilities across the team rather than expecting individuals to sub-specialize in a single area. It really helps if anyone can pitch in or cover when someone else is unavailable. 20 | 21 | **Outward focus; working with “the community”.** We’ll be an unusual team at Microsoft because we’re focused on the health interoperability community. We’re building specs, tools, and libraries for broad adoption by large companies, academic health centers, startups, and even government agencies. As we engage with diverse stakeholders, I want to help you form direct connections so you can work directly and effectively with this community, rather than via me. Early on, this will be a bit of a balancing act. A few principles for our choice of tools and tech stack. We should... 22 | 23 | * not assume our target audience is “on the Microsoft stack” in any way 24 | 25 | * build tools that can run smoothly in any cloud (or on a developer’s laptop) 26 | 27 | * plan, develop, and document our work in the open (i.e., publicly visible and comment-able) 28 | 29 | **Transparency and discoverability.** We'll work out the details as we go, but some of my personal, pragmatic preferences are to... 30 | 31 | * manage code and issues in GitHub 32 | 33 | * manage project plans with something visual like GitHub or Trello 34 | 35 | * build prototypes that interact with standards-based servers by wrapping/proxying, rather than modifying code from underlying systems (where possible) 36 | 37 | * “containerize all the things” so developers can deploy wherever Docker runs 38 | 39 | **Planning.** We'll plan together, and I expect our planning process will evolve. We'll start with“OKRs”, defining team-level Objectives and Key Results. Let me know if you prefer paper or an e-reader platform so I can buy you a copy of John Doerr's book, Measure What Matters. (As John will tell you, OKRs aren’t a silver bullet – but having a framework and planning transparently can be hugely effective.) 40 | 41 | **Protoypes > Production.** As a small team working in a big, challenging space, our goal is not to develop production-level software. It’s to drive interoperability forward by experimenting, exploring, documenting, and iterating together with the community. We should have a low threshold for sharing and soliciting feedback. Within and outside of our regular planning and design cycles, I hope you’ll feel empowered to explore new tech, try out some wacky ideas, and share what you learn. 42 | 43 | **Microsoft runs on trust.** [The tag line](https://www.microsoft.com/en-us/legal/compliance/integrity) can seem trite to outsiders, but this is an incredibly important part of the way we engage. Working with the healthcare community, we must be collaborative, transparent, direct, reliable, and trustworthy. 44 | 45 | ## Preferences, Quirks and Challenges 46 | 47 | **“The Cloud – not just Microsoft’s cloud.”** My remit from Peter Lee is broader than just Microsoft: to make healthcare interoperability work in the cloud, no matter whose. I’m strongly focused on the development and adoption of open protocols for health interop – regardless of where they run. This means I try to stay vendor-agnostic in nearly all my interactions (unless I’m specifically pulled into a customer meeting or pitch). 48 | 49 | **Open door.** Please ask me questions and share feedback-- especially the hard questions about context, history, why we're adopting an approach, and whether we’re overlooking something important. Realistically my most frequent answers will be "it depends" and "because it's something we can get consensus on.” But part of your job is to push back and challenge assumptions. Especially if you can do it with data, demos, or both. 50 | 51 | **Connections within Microsoft.** Since I’m new to Microsoft and work 2000 miles from Redmond, my personal network within the company is relatively weak. I don’t expect this to be a huge handicap, since 1) we’re largely an outward-facing team, focused on the healthcare interoperability community, and 2) we have tremendous support from within the Microsoft Healthcare org. But still, I want to help connect you internally at MS, because it’s an important part of your career development and support network. Sometimes this will mean that I "hand off" your questions by connecting you to folks in Redmond, rather than guiding you through a process that I don't fully understand myself. When this happens, we should aim to close the loop, reviewing what we've learned about process/policy/how get stuff done at Microsoft. This way we can learn together. 52 | 53 | **Travel and availability.** I travel extensively for work, including routine week-long meetings (e.g., HL7 Working Group Meetings) where my availability can be quite low. During these times, asynchronous communication will be key. In any case, the goal is to ensure you have ownership over team objectives and can work and make decisions autonomously. For code and design reviews, we’ll evolve practices as the teams grows. I want to give feedback because this kind of iteration improves designs; but I never want to be a blocker. 54 | 55 | **Mobile communication.** It’s helpful to know that my mobile phone is split across two profiles (personal + Microsoft). I don’t see Teams or MS e-mail messages on mobile unless I explicitly check -- so if you want to get in touch in real-time, and I’m not sitting down in front of a computer, I'm more responsive on https://chat.fhir.org . (And you should always feel free to text me at 617-500-FAKE.) It's fine to contact me any time of day; I silence my phone anytime I don't want to be disturbed. 56 | 57 | 58 | ## What else? 59 | 60 | What did I miss? Create an issue or a PR here :) 61 | 62 | 63 | -------------------------------------------------------------------------------- /okrs-2021-jan.md: -------------------------------------------------------------------------------- 1 | ## OKRs for Jan 2021 2 | 3 | We're following a planning schedule that mirrors the HL7 working group meeting schedule -- in four-month intervals ending in September, January, and May. 4 | 5 | ## Argonaut Project: SMART v2 6 | 7 | * P0 (0.8): SMART IG Draft ready for Argonaut Review prior to January Connectathon, suitable for January testing + May ballot. 8 | 9 | * P1 (0.8): Reference server and client implementation for v2 IG (including granular scopes and token introspection) merged into SMART App Launcher repo 10 | 11 | * P2 (0): Conduct 1:1 design reviews with two EHR vendors and two cloud vendors 12 | 13 | * P3 (0): Automated testing tool for EHR implementations (e.g. standalone CLI, or features on top of Inferno) 14 | 15 | 16 | 17 | ## Argonaut Projects: Bulk Data 18 | 19 | * P0 (1.0): Wrap up Bulk Data 1.5 IG 20 | 21 | * P1 (0.5): Work with at least two certified EHRs for testing and support 22 | 23 | * P2 (0.7): Ensure the bulk data test suite covers new features 24 | 25 | 26 | ## Argonaut Projects: Patient Lists 27 | 28 | * P0 (0.7): Patient Lists IG Draft ready for Argonaut Review prior to January Connectathon, suitable for January testing 29 | 30 | * P1 (0.3 -- no Questionnaire/Responses / other optional data): Demo data collection representing full feature set of Patient Lists API 31 | 32 | * Represent a "full experience" from a clinician's perspective – point in time snapshot. 33 | 34 | * Synthea data loader released in a separate repo. 35 | 36 | * P1 (0.3): Demo application exercises full feature set for Patient Lists API. Demo App / Sandbox enhancements 37 | 38 | * App deployment process includes at least one unit and at least one integration test. 39 | 40 | * Developer panel provides data validation and API statistics. 41 | 42 | * P1 (0.2) : Determine scope / level of effort to add Synthea functionality 43 | 44 | * that can generate Patient Lists data (populated groups of all types) 45 | 46 | * evaluate improvements to Synthea suitable for fast / direct loading without duplicate providers, etc. 47 | 48 | * P2 (0.1 -- bounded by demo app functionality): Codelab complete and published, teaching developers how to implement all data flows for the demo app 49 | 50 | 51 | ## Argonaut Projects: SMART Web Messaging 52 | 53 | * P0 (0.7): All ballot comments are triaged. 54 | 55 | * P0 (0.9): Proposed dispositions for any spec edits are tied to GitHub pull requests. 56 | 57 | * P0 (0.6): Shepherd proposals through FHIR-I 58 | 59 | * P2 (0.1 -- internal sketch / discussion only): SMART core JS library is augmented to support Web Messaging. 60 | 61 | * P3 (0.0): Standalone test tool demonstrates API support. 62 | 63 | * P3 (0.0): SMART app launcher supports at least one Web Messaging feature (e.g., app close) 64 | 65 | 66 | 67 | ## Subscriptions in R4 + R5 68 | 69 | * P0 (0.9): Subscriptions R5 is "ready to ballot at any time" 70 | 71 | * (1.0) Apply feedback from September 2020 Connectathon 72 | 73 | * (1.0) Complete documentation TODOs on existing areas of the spec including error discovery and recovery 74 | 75 | * (0.75 -- was passing; then core build changes broke it) Update resources to FMM 2/3 and ensure build passes 76 | 77 | * P1 (0.3 -- discussion, no definition): Define an approach to requesting Graphs when creating a FHIR Subscription 78 | 79 | * P1 (0.0): Host a deep-dive discussion with (at least) Carequality and two EHR vendors determine whether a new channel type is required to meet CMS encounter notification requirements 80 | 81 | * P1 (1.0): Subscriptions "R4 Back-port IG" ballots in the January ballot cycle (ballot opens Dec 11) 82 | 83 | * P3 (0.0): Add support for 'error' scenarios to subscriptions.argo.run system. 84 | 85 | * (0.0) Missing event / out-of-order delivery. 86 | 87 | * (0.0) Sending error state to client. 88 | 89 | * P1 (0.8): Maintain the Argonaut Encounters IG with changes from the specifications. 90 | 91 | * P0 (1.0): Presentation, demos, and Let's Build content ready for DevDays 92 | 93 | * P3 (0.0): Push Notification routing for inclusion in DevDays demo 94 | 95 | ### Not captured in OKRs, but spent time on and also accomplished: 96 | 97 | * Update reference system to support backport IG 98 | * Update reference system to support websocket changes for testing (prior to Connectathon) 99 | 100 | 101 | ## SMART Health Cards Framework 102 | 103 | * P1 (0.7): Freeze dependencies and publish a "1.0" implementation guide 104 | 105 | * P2 (0.7 -- this morphed into VCI): Creates a plan with The Commons Project to pilot the IG with at least one US-based lab 106 | 107 | * P2 (1.0): Report feedback from early implementation to the DID SIOP and Sidetree projects in Identity Foundation 108 | 109 | * P3 (0.6): Identify gaps with MS Authenticat 110 | 111 | ### Not captured in OKRs, but spent time on and also accomplished: 112 | * Develop data profiles for immunization + labs 113 | * 1:1 planning with VCI participants 114 | 115 | 116 | ## Expand the capabilities of fhir-codegen 117 | 118 | * P1 (0.5): Define parsing and serialization benchmarks to compare existing approaches, including latency to first pass + warmed-up throughput. 119 | 120 | * P1 (0.75): Improve time to first pass by 3x and improve throughput by __x without breaking API compatibility by leveraging System.Text.Json (vs NewtonSoft) for serialization and parsing. 121 | 122 | * P2 (0.0): Codegen library is published in Nuget 123 | 124 | * P3 (0.5): Add support for parsing profiles. 125 | 126 | * P3 (0.1): Build OpenAPI docs compliant with 'official' FHIR build. 127 | 128 | * (0.0): Add to 'generated' for compatibility checking. 129 | 130 | * (0.0): Talk with MS PowerApps Custom Connector team 131 | 132 | * P4 (0.0): Add API server and UI. 133 | 134 | * P4 (1.0): Add support for loading from a local build (output) folder (depends on changes to FHIR core infrastructure in the R4b refactor) 135 | 136 | ### Not captured in OKRs, but spent time on and also accomplished: 137 | 138 | * Support Firely with updates and fixes as needed. 139 | 140 | 141 | ## Internal MS team connections 142 | 143 | * P1 (0): Conduct FHIR office hours once in the month of December, open for questions and advertised through internal Teams channels 144 | 145 | * P2 (0): Introduce the idea of a FHIR/SMART review and/or test process. Some way for people doing work in the space to determine if what they are doing is 'ok'. 146 | 147 | * P3 (0): Decide on a feature to prototype in MS FHIR Server 148 | 149 | 150 | ## External community development 151 | 152 | * P1 (0.7): Gino to Record a "Friday Afternoons" video series on intro topics for FHIR videos. E.g. for specific languages provide an overview of how to connect to a server or issue queries. Focus on the security + data connectivity >> UI. 153 | 154 | * P1 (1.0): Josh in October to solicit topics on #implementers + #social for a series of "Guided walk through the FHIR spec" livestreams 155 | 156 | * P2 (0.6): Josh by November to select one topic and run a "Guided walk through the FHIR spec" livestream 157 | 158 | * P2 (0): Carl to record a Codelab working session (virtual session walking developers through the first part of the PL / PAMA codelab)? 159 | 160 | 161 | ## Other ideas not captured in OKRs 162 | 163 | ### FHIR Tooling 164 | 165 | * (0.1): SMART proxy 'package' 166 | 167 | * Server deployment to act as web-proxy. 168 | 169 | * SMART on FHIR Client packages for languages that need them (C#:Nuget, Java?:Jar?). 170 | 171 | ? Infrastrucutre, k8s deployment, dev ops to document publicly? 172 | -------------------------------------------------------------------------------- /okrs-2024-september.md: -------------------------------------------------------------------------------- 1 | # OKRs for July - Sept 2024 2 | 3 | ## Competing Interests / Keeping the Lights On 4 | * JM 5 | * Argo CGM lead-up to connectathon 6 | * Security Waves 7 | * (Unplanned: HTI-2 Responses ;) 8 | * (Unplanned: Argo Subscriptions for US Core) 9 | * GC 10 | * Cross-version extension work 11 | * Backport IG work 12 | * R6 content (https://confluence.hl7.org/pages/viewpage.action?pageId=234784975#FHIRInfrastructureMinutesWGM202405Dallas-TuesdayQ4) 13 | * Ballot Content Freeze deadline July 30 14 | * Final Content Deadline August 11 15 | * Subscriptions (resources + Framework page) 16 | * FHIR Candle work (+ finish move to FCP) 17 | * FHIR Codegen work (IG, Firely v6, Cross-Version, Ruby, TS, (FHIR Shorthand, CQL)) 18 | * Security Waves 19 | * FHIR packaging (Firely Packaging project) 20 | * BP 21 | * (1.0) PA Extensions Applied 22 | * (1.0) PA R6 Changes Applied 23 | * FHIRPath spec normative ballot 24 | - (0.8) Spec updates 25 | - (0.0) Tooling/testing updates to support evidence of normative 26 | * (0.9) FhirPath-Lab pre-pop/extract refinements? 27 | * (0.0) Pre-pop/extract education clips? 28 | * (0.7) FhirPath-Lab AI chat more open/released 29 | 30 | --- 31 | ## Objective: FHIR enables cross-version compatibility, with a clear division of responsibilities and helpful tooling 32 | 33 | Note: We'll focus initially on Core versioning rather than IG versioning. 34 | 35 | ### Create a Versioning Strategy Document 36 | 37 | - **[P0] (1.0) Problem Statement:** 38 | - **Challenges from R2 to R5:** 39 | - Identify specific challenges in the R4B cycle focusing on Subscriptions and medication knowledge resources. 40 | - **Impact on Stakeholders:** 41 | - Discuss impacts on EHRs, app developers, standards developers, and regulators. 42 | - **Transition Issues from R4 to R6:** 43 | - Explore the challenges and regulatory landscapes in transitioning to R6, and propose improvements for future versions. 44 | 45 | - **[P0] (0.8) Proposed Model for Managing Version Changes:** 46 | - ? **Versioning Alternatives:** 47 | - Review versioning strategies used in other standards including DICOM. 48 | - What works, what does not, what *could* be used, what cannot... 49 | - **Modularity of Spec Components:** 50 | - Enable development of content as part of independent modules, rather than a monolithic specification 51 | - **Granular Change Management:** 52 | - Develop a system to track and categorize individual element changes during specification development. 53 | - Define "normative" versus "trial use" changes and their management implications. 54 | - **Mechanisms for Version Negotiation:** 55 | - Propose how data producers and consumers can negotiate using "supported version ranges." 56 | - Show how an individual interaction can invoke module/version-specific behaviors 57 | - **Compatibility Guarantees:** 58 | - Specify compatibility guarantees and annotate potential breaking changes. 59 | - **Extension Mechanisms:** 60 | - Describe appropriate uses for extensions to handle "elements from the future." 61 | - **Asynchronous Cutover:** 62 | - Enable stakeholders to upgrade on their own schedules and allow regulators to manage minimum standards independently. 63 | 64 | - **[P0] (0.5) Stakeholder Responsibilities:** 65 | - **Roles and Expectations:** 66 | - Outline specific roles for HL7 Workgroups and the FHIR Management Group. 67 | - Define expectations for implementers, data providers, and regulators regarding asynchronous cutover. 68 | 69 | ### Subscriptions Module Case Study (by September 2024) 70 | - **[P0] (0.3 - started, but it was too much detail to be useful) Repository Development:** 71 | - Create and maintain a Git repository simulating the evolution of the Subscriptions module with detailed versioning and release notes. 72 | - Include multiple commits leading up to each "release" 73 | - Include major, minor, and patch releases showing spec evolution 74 | * Original Subscription model (simplified for clarity) 75 | * Bug fixes (patch release) 76 | * Rework to add Topic (simplified for clarity, major release) 77 | * Addition of `$event` and `$status` (minor release) 78 | * Addition of new data element + search param (minor release) 79 | * Bug fixes (patch release) 80 | * Include comparisons of structures (clean proposed vs Basic + Extensions) 81 | 82 | - **[P1] (0.3 -- developed a general framework but not maps for Subscriptions case study) Structure Maps:** 83 | - Develop detailed structure maps demonstrating upgrade paths for each version increment. 84 | 85 | - **[P0] (0.1 -- did not build these into a repo, did not automate) Example Resource Management:** 86 | - [P0] Include example resources that evolve with the spec. 87 | - [P2] Show how sample resources can be updated via standalone script running up-conversion from spec maps. 88 | 89 | - **[P1] (0.0) JS/C#? Server Implementation:** 90 | - P0 Request/Response examples showing how feature negotiation and feature mandating works 91 | - P1 Set up JS server that evolves with the Subscriptions module. 92 | - P1 Add support for each new release 93 | - P1 Enables version negotiation across the full span, returning content according to the requested version 94 | - P1 Supports search + create (any other behaviors can be canned) 95 | - P1 Supports R4 96 | - P3 Supports R5 also 97 | 98 | - **[P1] (0.0) JS Client Implementation:** 99 | - Build a JS client capable of version negotiation with the server. 100 | - Evolves along with the Subscriptions module but ahead of the server 101 | - Configure client settings to manage the version range for negotiation. 102 | - Demonstrate client operations such as creating and searching over Subscription resources, and handling notifications in requested versions. 103 | 104 | - **[P1] (0.4 -- created a slide with publication timeline but not server/client support) Timeline Visualization / Slide:** 105 | - Show fictional dates of spec development + release 106 | - Show lag to server support 107 | - Show lag to client support 108 | - Demonstrate that server + client remain compatible throughout 109 | 110 | ### Proof of Concept: Version Management Toolkit 111 | - **Implementer Toolkit:** 112 | - **[P1] (0.2 -- PoC for mapping, execution in unit testing, execution in fhirpath lab) Up/Down Conversion Utility:** 113 | - Create utilities that transform resources between different FHIR versions. 114 | - (Done but not planned for) Validation tooling for cross version maps (to ensure map/model validity) 115 | - **Version Negotiation support in Client SDK:** 116 | - [P1] (0.1 -- submitted comments on App Feature IG) Develop an approach for a library that facilitates client-server communication to determine compatible FHIR versions. Can be used by JS client above. 117 | - [P2] (0.7) PoC that handles parsing and generation of resources for different versions 118 | - Takes a resource in a specified version, and a library of maps, and applies the maps in sequence to create the target output 119 | - https://github.com/brianpos/fhir-net-mappinglanguage/tree/main/VersionConversionTester 120 | - **[P3] (0.1) Version-Aware Validation Tool:** 121 | - Q. What context does a validator need to resolve (e.g., collection of modules/versions) prior to validation? 122 | - P? Exercise existing Firely SDK functionality to show validation of content from Subscription module at various versions 123 | - Q. What context does a validator need to resolve (e.g., collection of modules/versions) prior to validation? 124 | 125 | - **Spec Editorial Toolkit:** 126 | - **[P1] (0.1 -- still hoping much of this can be determined automatically outside of editorial flow) Change Intent Capture System:** 127 | - Create a format to document change rationale, impact, including converters, potential data loss, deprecation schedules, and "backport" extension needs. 128 | - [P1] Simple markdown format with no executable behavior 129 | - [P2] Show "close enough" examples from WIP tooling to communicate how this *could work* 130 | - **[P5] (0.0) Automated Test Case Generator:** 131 | - Develop a system that generates test cases to validate backward compatibility of changes. 132 | - (Done but not planned for) Updating existing cross version maps to be consistent/valid 133 | 134 | - **[P5] (0.3 -- draft UI, will be ripped/replaced) Cross-Version Difference Display Tool:** 135 | - Develop a tool that visually displays differences between versions of a resource or element. 136 | -------------------------------------------------------------------------------- /okrs-2024-may.md: -------------------------------------------------------------------------------- 1 | ## FHIRPath is well specified and easy to learn, with many robust implementations 2 | * P2 (0.5; reduced backlog; next, committee time is needed) BP More fhirpath spec updates - help encourage reducing the backlog through committee and into spec 3 | * P3 (0.5; committee now agrees this is needed) BP Foster a path to get another normative ballot of the fhirpath spec 4 | 5 | * Dev days content 6 | * (1.0) Questionnaires base presentation and examples 7 | * (1.0) FhirPath Lab extensions to test questionnaires 8 | * (1.0) Questionnaires pre-pop extract presentation and examples 9 | * (0.9; in dev branch) FhirPath Lab extensions to support this 10 | * (1.0) FhirPath basics presentation and examples (and fhirpath lab demos) 11 | 12 | ### fhirpath implementations are continuously tested, with transparent results and feedback loop for improvements 13 | 14 | * Support for various implementations in the lab (?) 15 | * (0.1) Ensure clarity of user-facing explanation on where data is processed 16 | * (0.9) Beda Software (Python engine) - review PR, 17 | * (0.8) Aidbox (FHIRPath and bonus questionnaire renderer) 18 | * Conformance matrix 19 | * P1 (0.0) BP augment official test file with better metadata 20 | * Update the fhirpath test file to include reference to sections of the spec that are being tested 21 | * P1 (0.0) BP Publish results for each implementation 22 | * generated by unit tests 23 | * P1 BP (0.0) Fhirpath engine test cross-reference - to help with next ballot 24 | * Viewer for results 25 | * with deep links back to spec 26 | * with deep links back to unit test results 27 | 28 | ### Open source Tooling to help efficiently work with fhirpath 29 | * BP FirelySDK fhirpath parser enhancements (complete existing work) 30 | * P0 (1.0) position info, brackets 31 | * P2 (1.0) comments - as ignore/skip, or including for round-tripping? 32 | * P2 BP fhirpath lab AI Chat 33 | * (0.5) Incorporate recent learning (RAG/multi-step/multi-agent processing) 34 | * (0.5) Improved Questionnaire support - applying changes 35 | * (0.1) Decide on rollout path 36 | * Independent project with bring-your-own keys, or a MS supported tool? 37 | * Responsible AI and other internal reviews? 38 | * Decision on feedback mechanism(s) and sharing location(s) 39 | * Update documentation on use of data/storage/sharing 40 | 41 | ## SMART App Launch 2.2 is published with User Access Brands 42 | 43 | Key Results: 44 | * P1 (1.0) All remaining ballot issues from the HL7 process are resolved by April 1 45 | * P1 (1.0) Feedback from the upcoming Connectathon is incorporated 46 | * P2 (0.5 -- recording in DevDays) An educational video explaining Patient Access Branding for app developers is produced by May 1 47 | * P1 (0 -- HTI-2 proposal not yet published) A detailed response to the ONC proposed rule for HTI2 promoting adoption of Patient Access Branding is submitted 48 | * P3 (0) A conversation to propose inclusion of Patient Access Branding support in the Inferno testing tool 49 | 50 | ## A proof-of-concept showcase demonstrates techniques for mapping and visualizing my EHI export data using AI tools. 51 | 52 | Key Results: 53 | * P1 (1.0) Analyze my EHI export data from Epic in-depth 54 | * Openly publish an EHI Toolkit with 55 | - P1 (1.0) Components to strip specific sensitive identifiers from the data set 56 | - P1 (1.0) Utilities to extract, clean and structure the EHI data into suitable formats for analysis 57 | * Openly publish an EHI Showcase 58 | - P2 (0.7 -- published with my own data) Web-based data viewer capable of displaying EHI 59 | - P2 (0) Clinical and administrative views at the encounter level 60 | - P3 (0) Configurable with logical data views and links between related views 61 | _ P4 (0.3 -- only one-offs) Including visualizations of key insights from the EHI data 62 | * P1 (0.8 published demo video on youtube; devdays) Create and publicly publish a video walkthrough of both 63 | * Use large language models in a semi-automated workflow to: 64 | * P3 (0.7 -- working but only tested with my data, limited LLM role) infer and characterize links between data across different tables 65 | * P5 (0) Implement techniques to generate candidate custom views and evaluate/refine them iteratively 66 | 67 | ## VCL allows rich, dynamic queries over FHIR terminology systems 68 | * P1 (0.8 thanks to Michael) VCL proposal includes support for subqueries 69 | * P1 (0.8 ditto) Proposal includes support for designation queries 70 | * P2 (0) Proposal is merged into draft content for R6 71 | 72 | # Argo 2024: Continuous Glucose Write 73 | * Project launch with scope that balances needs of consumer-facing apps, clinician platforms, and EHRs 74 | * P1 (1.0) device data including manufacturer and identifier 75 | * P1 (1.0) "on demand" data pulls into EHR 76 | * P1 (1.0) "all at once" data pushes into EHR 77 | * P1 (1.0) coarse-grained (e.g., "daily") data pushes into EHR 78 | * P3 (1.0) near-realtime data pushes into EHR 79 | 80 | # Developers using C# have access to comprehensive definitions and properties (GC) 81 | * Core spec 82 | * (P0) - (1.0) Firely export is working with refactored models 83 | * (P0) - (0.9) Firely export has method for exporting _interfaces_ (e.g., CanonicalResource) with fillers for properties that do not exist 84 | * IG profiles 85 | * (P0) - (1.0) Firely export can generate a set of canonical urls for an IG (e.g., extensions) 86 | * (P0) - (1.0) Firely export can generate a set of getters and setters for extensions 87 | * (P1) - (0.5) Firely export can generate a set of getters and setters for slices 88 | * (P5) - (0.0) Export any artifacts/extension methods and document nice path to use Firely validation on instances 89 | * Validation entrypoint included in generated interfaces 90 | * (?) New Firely Validator (old one covered https://brianpos.com/2022/08/25/adding-resource-validation) 91 | * (P0) - (1.0) Demo at DevDays 92 | 93 | # Developers in other languages have access to comprehensive definitions and properties (GC) 94 | * Core spec 95 | * (P0) - (1.0) Info Language export is working with refactored models 96 | * (P0) - (1.0) TypeScript export is working with refactored models 97 | * (P0) - (1.0) OpenAPI export is working with refactored models 98 | * IG Profiles 99 | * (P5 BP) - (0.0) Typescript extension getters/setters/extension URLs 100 | 101 | 102 | # Developers using C# have can translate resources between versions (GC) 103 | * (P1) - (1.0 - GC+BP) Code-gen can parse FML structure maps 104 | * (P1) - (0.5) Code-gen can use cross-version maps to export: 105 | * (P1) - (0.5) Determine where FML is insufficient to describe required transformations 106 | * Write missing code and document. 107 | * Where do hooks go in Code-Gen vs. Runtime vs. Static configuration 108 | * (P1) - (0.0) R5 serializer for an R4B SubscriptionTopic resource 109 | * (P1) - (0.0) R5 parser for an R4B SubscriptionTopic resource 110 | * (P1) - (0.0) R5 serializer for an R4 SubscriptionTopic (Basic) 111 | * (P1) - (0.0) R5 parser for an R4 SubscriptionTopic (Basic) 112 | * (P2) - (0.0) R4 serializer for an R5 SubscriptionTopic 113 | * (P2) - (0.0) R4 parser for an R5 SubscriptionTopic 114 | * (P2) - (0.0) R4 serializer for an R4B SubscriptionTopic resource 115 | * (P2) - (0.0) R4 parser for an R4B SubscriptionTopic resource 116 | * ? Explore automated test case generation for round-tripping 117 | * (P3) - (0.0) Code-gen can use structure maps to export 'x' additional resources 118 | * Patient 119 | * Encounter 120 | * Observation 121 | * Condition 122 | * DiagnosticReport 123 | * (?) https://github.com/brianpos/fhir-net-mappinglanguage/blob/main/Test.Hl7.Fhir.MappingLanguage/SimpleMapTests.cs 124 | 125 | Additional Key Results: 126 | * (P1) - (0.5 - BP+GC) Get fixes for cross-version structure maps incorporated upstream. 127 | * (P♾️) Match cross-version code in JS/Liquid/TS 128 | 129 | # Users have simple and consistent access to FHIR packages (GC) 130 | * (P2) - (0.4; pending CI-based resolution PR) Integrate changes from local package resolution into Firely.Fhir.Packages 131 | * (P3) - (0.0) Ensure changes flow into Firely Terminal 132 | * (P4) - (0.4) Move updated documentation into Confluence 133 | 134 | # FHIR Subscriptions: Patients have timely notifications about events in their healthcare 135 | 136 | ### IG authors and implementers have access to the latest and best versions of Subscriptions (GC) 137 | * (P1) - (1.0) Completion of 'additional granularity' design work 138 | * (P1) - (0.8) Finish reconciliation of 1.2.0 ballot 139 | * (P1) - (1.0) Propose resolutions for the 27 remaining ballot JIRA tickets 140 | * (P1) - (1.0) Submit block vote for ballot tickets 141 | * (P1) - (0.5) Apply resolutions for ballot tickets 142 | * (P1) - (0.0) Publication of FHIR Subscriptions IG 1.2 143 | * Check proposed HTI-2 rule to ensure necessary functionality is published 144 | -------------------------------------------------------------------------------- /okrs-2023-may.md: -------------------------------------------------------------------------------- 1 | ## Argonaut Assessments project offers clear guidance for SDOH 2 | * P0-BP: (0.2 -- validated some upstream content in Gravity IG, and early content in "SDC By Example" repo.) Example content covering 3 | * External form to be "ingested" into an EHR for ... 4 | * "PRAPARE Prime" (i.e., locally modified PRAPARE hide fields, add some extras) --> FHIR Questionnaire 5 | * Not technically required by US Core, but we have to write it *somehow* 6 | * "PRAPARE Prime Response" --> QR 7 | * Not technically required by US Core, but we have to write it *somehow* 8 | * "PRAPARE Prime Response" --> Observation tree (the current "SHALL") 9 | * Required by US Core, so we need to make sure it works 10 | * Include examples of local codes for the "invented" questions 11 | * Conditions derived from this assessment (e.g., food insecurity) 12 | * Following current US Core spec's requirements / Must-Supports 13 | * P1-BP: (0.2 as above) Project includes the Assessment *recipient* perspective, by use case 14 | * Clinical reporting / measurement tools 15 | * Jurisdictional health departments 16 | * Clinical research? 17 | * P1-BP: (0.0) US Core provides clear guidance and a diagram distinguishing 18 | * data collection (e.g., recorded as Observations) 19 | * problems actively tracked (e.g., Conditions) 20 | * P2-BP: (0.0) Short video on SDC Data Extraction (Argonaut Assessments) 21 | 22 | ## SMART on FHIR v2.1 is available for implementation 23 | * P0-JM: (1.0) Resolve remaining open issues from Ballot 24 | * P1-JM: (1.0) Request for publication 25 | * P1-JM: (1.0) Published 26 | 27 | ## Consumers can access imaging data via SMART on FHIR 28 | 29 | ### Imaging Access Spec 30 | Define and document the scopes and endpoints for imaging access in SMART on FHIR authorization flow by Q1 2023 31 | 32 | * P0-JM: (1.0) Publish a draft spec on GitHub 33 | * P1-JM: (1.0) Present the spec and use cases and refine over >=3 3 project calls 34 | * P2-JM: (0.6) Collect feedback from at least 2 EHR vendors 35 | * P2-JM: (0.5) Collect feedback from at least least 2 PACS or imaging network vendors 36 | * (After May) Incorporate feedback and finalize the spec 37 | 38 | ### Demo Environment 39 | Develop and deploy a demo environment with a facade over PACS that supports imaging access 40 | 41 | * P0-JM: (1.0) Design and implement a facade over PACS that supports imaging access 42 | * P0-JM: (1.0) Develop a sample data set for demo environment 43 | * including at least 3 patients 44 | * including at least 3 imaging modalities 45 | * P1-JM: (1.0) Deploy the facade over PACS on a cloud platform that is world-accessible 46 | * P1-JM: (1.0) Integrate deployed facade with SMART App Launcher 47 | * P1-JM: (1.0) Develop a "basic mechanics" demonstration app that can run against SMART App Launcher 48 | * P4-JM: (0.2 sceeenshots only) Develop a more playful and open-ended demonstration app like "make a 3D print of my brain" 49 | * (After May) Collect feedback from at least five end users who use the demo environment 50 | 51 | ### Community, Education and Dissemination 52 | Educate and disseminate the imaging specs and best practices to potential users and developers through libraries, tools, or examples 53 | 54 | * P0-JM: (0.75 DevDays recording) Quick blurb outlining imaging project, inviting participation, including telecon details 55 | 5min video recording of the Argonaut pitch to go along with it 56 | * P1-JM: (0.8 -- needs more PACS participation) Argonaut call participation includes diverse perspectives 57 | * EHR 58 | * PACS / VNA 59 | * Imaging Network 60 | * HL7 Imaging WG 61 | * Application developers 62 | * P2-JM: (0.2 inline in demo app only) Create a reusable client-side library that supports imaging access 63 | * P2-JM: (0.8 -- content in DevDays video) Publish a video showing how to use the openly-hosted demo environment 64 | * P2-JM: (0.0 -- no reusable library) Publish a video showing how to use the library in a demo app 65 | * (After May) Host a Birds of a Feather session at DevDays for June 66 | 67 | ### Evaluation 68 | Evaluate the spec with components running in a provider’s staging environment 69 | 70 | * P2-JM: (0.4 -- in talks) Identify and recruit at least one provider organization that is willing to participate in the evaluation 71 | * (After May) Integrate the demo environment with the provider’s EHR’s SMART API and verify interoperability 72 | * (After May) Collect feedback from at least five end users who use the staging environment 73 | 74 | ## SMART Health Insurance Cards 75 | Note: May UCDS Demo came together (see https://today.ucsd.edu/story/uc-san-diego-health-spotlights-smart-health-insurance-cards) 76 | 77 | ## Topic-based subscriptions are testable 78 | * P0-GC: (1.0) Sandbox is deployed that supports at least one of R4, R4B, R5 79 | * P0-GC: (0.8 -- no button wired to UI) Sandbox supports arbitrary fhirpath-based topics 80 | * UI supports SubscriptionTopic.eventTrigger via a "trigger this event" button 81 | * Anyone can POST a SubscriptionTopic and subscribe to it 82 | * Any fhirpath expression over current/previous works 83 | * Any query expression will work 84 | * P1-GC: (1.0) Sandbox supports basic filtering of subscription events 85 | * Any equality filter works 86 | * P1-GC: (1.0) Sandbox is deployed that supports all of R4, R4B, R5 87 | * Review of Firely's v5 SDK and multiversion/base versionless support? 88 | * P2-GC: (0.75 -- still need filtering on some modifiers including group membership tests) Sandbox supports advanced filtering of subscription events 89 | * Any filter for any search parameter (with simple fhirpath expression) works 90 | * remove dependency on external fhir-server 91 | * P2-GC/BP: (0.0) Subscriptions sandbox integrates with FhirPathLab 92 | * for subscription topic editing 93 | * subscription topic debugging 94 | * P5-GC: (0.8 -- server supports; not exposed in demo UI) Sandbox supports multi-tenancy to isolate users 95 | * P5-GC: (0.5 -- can manually POST SearchParams, but no auto-loading at startup) Sandbox supports IG loading for search parameters 96 | * new SearchParameters can be installed via POST 97 | * P5-BP: (0.0) Partial Subscriptions support POC inside Facade project (including write-up how this fits into the facade model for others to build on) 98 | 99 | ## FHIR R5 is published and available for community use 100 | * P1-BP/GC/JM: (1.0) FHIR QA issues are applied and publication is out 101 | * P2-GC: (0.0) Host an 'R5 Changes' session with internal folks 102 | 103 | ## FHIR Community has access to high quality open source libraries 104 | * P0-BP/GC: (1.0) Support Firely in v5 SDK publication 105 | * P1-BP: (1.0) Dotnet FHIR Facade Project supports Firely v5 SDK (FHIR R4B) 106 | * P0-BP: (1.0) Dotnet FHIR Facade Project supporting FHIR R5 107 | * P0-GC: (1.0) @types/fhir is updated with R5 models 108 | * P0-BP: (1.0) fhirpath.js supports R5 models 109 | * P0-BP: (1.0) Fhirpath Lab support R5 110 | * P2-BP: (1.0) Review/refine Firely SDK Serialization hooks to better handle invalid content and reporting 111 | * invalid value for enumeration to be handled by ExceptionHandler (when not permissive parsing) 112 | * Decimal value parsing: Value was either too large or too small for a Decimal 113 | * FhirXmlNode and FhirJsonNode use the ExceptionHandler settings object for fine grained control 114 | * location should be able to read from a property, not embedded in the message to ease construction of custom error outcome messages 115 | * P5-BP: (0.1) Research Fhirpath Lab support Kotlin based android fhirpath engine 116 | 117 | ## FHIR community continually improves our processes 118 | * P1-BP/JM: (0.2 -- discussed and no appetite) Propose a short time span and narrow quality focus for FHIR R6 (socialize this with FMG) 119 | * P1-BP/JM: (0.2 -- hard without a commitment to shorter cycles) Start a conversation about preventing accumulation of backlog between publications 120 | * P4-GC/JM: (0.6 -- evaluated github registry) Evaluate suitability of an existing open-source NPM registry server for FHIR's needs 121 | * Understand where/how FHIR uses NPM 122 | * Document current capabilities and any custom behaviors of FHIR's NPM registry sever 123 | * Firely's packages.fhir.org 124 | * Grahame's packages-2.fhir.org 125 | 126 | ### Patient Request for Corrections IG is on a path toward real-world EHR implementation 127 | * P4-GC: (0.8 -- drafts, not merged) Finalize "project scope" section of IG 128 | * P4-GC: (0.4) Clean up diagrams and section references 129 | * P4-GC: (0.5 -- WIP, believe there is agreement but not fully documented) Clarify what implementation choices are required vs allowed 130 | 131 | ## FHIR SMART Launch and SDC is adopted worldwide 132 | * P0-BP: (1.0 -- also organized presentation of MS Server new capabilities) Participate in the HL7 Australia FHIR Connectathon on localizing SMART App Launch and disseminate the recent updates and future changes coming to SMART, and also how SDC can be leveraged in this environment - retrieving context parameters 133 | -------------------------------------------------------------------------------- /okrs-2022-september.md: -------------------------------------------------------------------------------- 1 | # OKRs for June-September 2022 2 | 3 | ## FHIR-based software uses topic-based subscriptions to avoid polling 4 | * P0-GC: (1.0) R4B Backport IG is published 5 | * P0-GC: (1.0) Publication request approved by FHIR-I, FMG, and TSC 6 | * P0-GC: (1.0) Specification is Published 7 | * P1-GC: (1.0) Have connectathon track available, either as a standalone track or part of an Argo-wide track (?) 8 | * P3-GC: (0.0) Subscriptions sandbox supports more SubscriptionTopics (e.g., arbitrary fhirpath-based topics, or a "button push event" topic) 9 | * P0-GC/BP: (0.75 -- need to review R5) RI is up to date with R4B+IG and R5 10 | * P0-GC: (1.0) With final R4B/IG version 11 | * P2-GC: (0.0) Track usage for Subscription sandbox (counts by R4B vs R5, standard channel types or "any custom channel") 12 | * P2-GC/BP: (0.0) Develop SubscriptionTopic content from at least one of the following: 13 | * Public health 14 | * MedMorph for public 15 | * National Center for Health Statistics (NCHS) Reporting 16 | * DaVinci Notifications IG? 17 | * P2-BP: (0.0) Create a cloud messaging channel type (e.g., azure event grid) 18 | * Draft channel def, docs for compatibility with existing notifications 19 | * Prototype from an existing FHIR server 20 | * P2-GC: (0.5) Follow up with at least 2 potential implementers (e.g., cloud vendors, EHRs) 21 | 22 | ## Developers, students, and others learn FHIR through openly published educational content 23 | * P0-GC: (0.0) Publish at least 2 videos the usage of the new typescript SDK 24 | * P0-GC/BP (0.0 -- we did blog content though): Publish at least 2 videos about developing in FHIR using C# 25 | * P0-BP (0.1 -- but did broadly publicize/promote tooling at WGM/others): Publish educational content on writing FHIRPath and tooling available 26 | * P2-BP (0.7): Publish educational content on integrating FHIR Servers and FHIR Terminology Services 27 | * P2-JM-GC (0.5): Review and "groom" educational content ideas at https://github.com/orgs/microsoft-healthcare-madison/projects/1 28 | * P1-JM (0.5): Publish at least 2 videos from the content backlog 29 | 30 | ## Open source tools and libraries make it easy to work with FHIR and related IGs 31 | 32 | ### SMART on FHIR tooling 33 | * P0-JM: (1.0) Decide on path forward for SMART v2, from the following options 34 | * Seek commitment from BCH? 35 | * Take over maintenance short or long term 36 | * Fork 37 | * Create something new (fhir-typescript?) 38 | * P1-JM: (1.0) Client-JS supports SMARTv2 39 | * P1-JM: (0.2) Launcher supports SMARTv2 40 | * P2-JM: (0.1) Review analytics from SMART Launcher 41 | 42 | ### FHIRPath is easy to learn, debug, and use 43 | * P0-BP: (1.0) Tooling to simplify writing/debugging fhirpath expressions 44 | * P0-BP: (1.0) Contribute to aligning the variances in implementations/conformance (e.g. comment support in .NET, Join in HAPI) 45 | * P4-BP: (0.1) Prepare a foundation for a library of fhirpath expressions 46 | * Announce the creation of an openly licensed fhirpath library 47 | * Develop initial content using the FHIR Library resource 48 | * Allow users to create/contribute to the library content 49 | * Provide an easy way to open any branch/fork of the library in the editor 50 | * P2-BP: (0.9 PR review in-progress) Contributions to open source `fhirpath.js` to support split/join/encode/decode/trace 51 | 52 | ### Changes between versions of specification publications are easy to discover 53 | * Technical implementers can access tooling to compare the contents of package versions 54 | * P0-GC: (.75 -- need to go deeper on CapabilityStatement including SHOULD/SHALL/MAY annotations) Implement software that finds and categorizes changes in all relevant artifacts. 55 | * P4-GC/BP: (0.5 docs in place, internal deployment infra WIP) Packaged deployment of tooling 56 | * Non-technical implementers can access tooling to compare the contents of package versions 57 | * P2-GC/BP: (0.0) Hosted solution for common package+version combinations 58 | * P2-GC: (0.3 -- JSON in place) CSV or Excel export of contents 59 | 60 | ### Typescript/JS (DT and SDK) 61 | * Developers can use tooling quickly after specification packages are published 62 | * P0-GC: (0.2) Expand build tooling to reduce maintenance burden (e.g., daily automatic checks?). 63 | * P0-GC: (1.0) Publish contents for all 'common' versions of FHIR. 64 | * P2-GC: (0.0) Choose a strategy for publication of pre-prelease and CI builds of packages. 65 | * e.g., to express 5.0.0-ballot in sdk version 0.0.3 *versus* 5.0.0-snapshot2 in sdk 0.0.3 66 | * package `@fhir-typescript/r4-core` (lib version: `0.0.12-beta.18`) 67 | * package `@fhir-typescript/r5-core` (lib version: `0.0.12-beta.18`) 68 | * ??package `@fhir-typescript/r5-core-snapshot2` (lib version: `0.0.12-beta.18`) 69 | * Improved quality and correctness of runtime SDK 70 | * P1-GC: (0.5 - WIP) Support invariant testing in the core specification 71 | * P5-GC: (0.0) Implement custom JSON serializer/parser 72 | * Expanded scope of 'core' SDK functionality 73 | * P1-GC: (0.0) Determine path for 'expected' functionality (develop or build integrations) and implement at least 2 of: 74 | * P1: FHIRPath 75 | * P1: SMART App Launch 76 | * P1: HTTP Client (e.g., fetch, query) 77 | * P5: XML Support 78 | * Simplify usage of Implementation Guides for SDK developers 79 | * P3-GC: (0.2) Create tooling for IG-based NPM packages 80 | * SDK has a low barrier to entry 81 | * P0-GC: (0.0) Create documentation site for SDK / API 82 | * Build a community around SDK use 83 | * P1-GC: (0.0) Determine 'primary' feedback mechanism 84 | * P3-GC: (0.0) Build and publish roadmap 85 | * P4-GC: (0.0) Develop 'feedback' form and solicit responses from users and non-users in the JS/TS space 86 | 87 | ### .NET (Firely) SDK 88 | * Expanded scope of 'core' SDK functionality 89 | * P2-BP: (0.0) Provide a "validator" or SDK for search parameter input (e.g., evaluate querystring for valid FHIR syntax, modifiers, values) 90 | * Simplify usage of Implementation Guides for SDK developers 91 | * P5-BP/GC: (0.2) Create tooling for IG-based NuGet packages 92 | * SDK users understand and are comfortable with the long-term FHIR versioning strategy 93 | * P1-BP/GC: (0.2 - BoF and Working Group Meeting discussions) Coordinate with Firely 94 | 95 | ## The FHIR specs are clear, concise, correct, and new-user friendly 96 | 97 | ### Important and high-traffic areas of the FHIR Core spec receive special attention 98 | * P0-GC: (1.0) Search Page rewrite is ready for QA 99 | * P1-GC/BP/JM: (1.0) Search Page rewrite is QA'd for ballot 100 | * P0-BP/GC/JM: (1.0) Assisting in applying the backlog of approved changes to the core FHIR R5 specification 101 | * P2-all: (1.0) Review tickets submitted by our team and apply or submit PRs to apply the resolutions 102 | * P2-JM: (0.5) Propose to HL7 and discuss feasibility of usability metrics from the official HL7 web server (logs or JS analytics) and build.fhir.org 103 | * P2-GC/BP: (0.0) Engage a MS documentation or usability team for review 104 | * P2-JM: (0.0) Propose a WGM quarter with Education Advisory Council (reach out to Viet, Virginia), topics to include... 105 | * Understand level of interest in spec usability 106 | * Consider role for survey and/or individual interviews 107 | * Discuss possible roadmap, usability practices 108 | 109 | ## The extended FHIR Community (including MS-internal stakeholders) understands our team and mission 110 | * P1-JM: (1.0) Develop a short bullet list of talking points (MSR org; focus on spec; interop across clouds) 111 | * Added https://github.com/microsoft-healthcare-madison/team/blob/master/team-overview.md 112 | * P3-all: (0.2) Incorporate these into our various decks/docs/demos? 113 | * P2-??: (0.8 ran "intro" session) Organize a cross-org FHIR users group ("FHIR at Microsoft" Teams team? mailing list? meeting?) within MS 114 | * Invite all relevant/known orgs to join 115 | * Include a recorded session on our team's work including demos / showcase 116 | * Include a session on Ballot process and why to participate 117 | * Include links to educational content 118 | * Invite others to reciprocate, share their work, build awareness 119 | 120 | ## Our team consistently advocates for patient rights 121 | * P2-JM: (0.75 -- re-submitted manuscript) Outline principles for patients under TEFCA (transparency / AoD, consent based access, partitioning of data across personas) 122 | * P2-JM: (0.25) Interview QHINs to understand their plans for these 123 | * P3-JM: (0.0 -- dependency on paper?) Write a brief or blog post 124 | 125 | ## SMART Health Links are adopted for use cases beyond the scope of SHCs 126 | * P0-JM: (1.0) Argonaut launches with project scope that includes lifetime immunization record 127 | * P1-JM: (1.0) Open invitation to participate 128 | * P1-JM: (1.0) At least one EHR vendor participates 129 | * P1-JM: (1.0) At least one state registry or state IIS vendor participates 130 | * P2-JM: (0.0 but we do have feedback) Connectathon testing provides feedback for the spec 131 | 132 | ## Argonaut projects reach consensus with a pragmatic, productive, and inclusive process that leads to real-world implementation 133 | * P0-JM: (0.8 -- lacking real EHR implementations) SMART App State connectathon includes 2+ EHRs and 2+ Clients 134 | * P1-JM: (1.0) SMART App State spec incorporates connectathon feedback 135 | * P2-JM: (0.1 -- don't have consensus) SMART App State is proposed for inclusion as "experimental capability" in SMARTv2 STU Update 136 | * P5-JM: (0.0) Patient Access Brands spec is supported by 2+ EHRs in production 137 | -------------------------------------------------------------------------------- /okrs-2023-january.md: -------------------------------------------------------------------------------- 1 | # OKRs for Oct 2022 - Jan 2023 2 | 3 | ## Argonaut convenes and drives consensus on high-impact interop projects 4 | 5 | ### Patient Access Branding information is available for certified EHR endpoints 6 | * P0-JM (0.8): Document current implementation support based on EHRs listed in CHLP 7 | * P2-JM (0.0): Meet with EHRs to determine value of editing tools or auto-suggestions to bootstrap publication of branding information 8 | * (Also: IG content incorporated into SMART branch; connectathon late March) 9 | 10 | ### SMART App State is available for real-world apps 11 | * P0-JM (1.0): Merge "Persisting App State" functionality into SMART App Launch 12 | * P0-JM (1.0): Reach a go/no-go decision about including App State in STU2.1 update (choices: do not include in 2.1; include in 2.1 as a balloted update; include in 2.1) 13 | * (Also: Resolved all the ballot comments) 14 | 15 | ### Consumers can access and share health data with standardized links (SMART Health Links) 16 | * P0-JM (0.8): Participation in Argonaut workgroup includes diverse perspectives from public health, state immunization registry software, and insurance providers 17 | * P0-JM (1.0): SHL testing and validation tools are openly available to the community 18 | * P1-JM (0.7): Specification stablilized at "1.0 RC" stage (ready to commit to backward compatibility) 19 | * P1-JM (1.0): Focused discussions with 2 immunization registries or registry vendors to document deployment plans 20 | * P1-JM (0.0): Ask for presentation slot on a monthly Da Vinci call to present background on SHL and a digital insurance card use case. Invite CARIN and Argonaut members to join. 21 | 22 | ### Social needs screening results are shared across software systems 23 | * P0-JM (0.6): Conduct interviews with at least five EHR and social needs platform vendors to document current capabilities 24 | * P1-JM (1.0): Current-state platform capabilities are documented publicly on HL7 wiki 25 | * P0-JM (1.0): Conduct interviews with at least two health systems to document current use of screening tools 26 | * P1-JM (1.0): Current-state usage is documented publicly on HL7 wiki 27 | * P2-JM/BP (0.1): Example responses for 2 LOINC-coded surveys in QR and Observation format, consistent with latest US Core specs 28 | * P3-JM (N/A -- rolled into Assessments Sprint): Propose Argonaut project for 2023 to enhance US Core for social needs submissions 29 | * P3-BP (0 -- but may come up in Assessments Sprint): Discuss with EHR vendors the opportunity to configure their sandbox env (or a customer's sandbox env) to test existing capabilities 30 | 31 | ### Patient Request for Corrections use case is on a path toward real-world EHR implementation 32 | * P2-GC (0.5): Small-group discussion on feasibility / scoping 33 | * P2-GC (0.5 -- now "choose your own adventure"): Propose scope (perhaps narrower than current PE IG) / changes 34 | * P2-GC (1.0): Submit as Argo23 project proposal 35 | 36 | ## The FHIR specs are clear, concise, correct, and new-user friendly 37 | * Canonical functionality is consistently supported in generic FHIR servers 38 | * P0-BP (1.0): `$current-canonical` operation applied to the R5 specification (approved HL7 change) 39 | * P0-BP (1.0): `$current-canonical` operation is implemented in .net and available in reference implementation(s) 40 | * P2-BP (0.5 -- written but not contributed): contribute unit tests to the [core test packages](https://github.com/FHIR/fhir-test-cases) for the f`$current-canonical` 41 | * P0-BP: Blog posts discussing: 42 | * (1.0) usage for registries (pretty well covered) 43 | * (0.5 -- written, awaiting feedback) usage for health institutions (basically not covered at all) 44 | 45 | * P1-GC (0.2): Standard reverse proxy headers from https://www.rfc-editor.org/rfc/rfc7239#section-5 are documented in FHIR's http.html 46 | * P2-JM/GC/BP (1.0 -- this wound up being a much bigger lift, very long tail of unapplied issues, often duplicative or contradictory): FHIR R5 Ballot comments are addressed for areas of the spec that we maintain 47 | 48 | ## Topic-based subscriptions are testable 49 | * P0-GC (0.5 -- WIP on new server, unreleased): Subscriptions sandbox supports more SubscriptionTopics 50 | * "button push event" topic 51 | * arbitrary fhirpath-based topics 52 | * P2-GC (0.0 -- .NET build works locally, but nothing new): Subscriptions sandbox has a local-deployment story (e.g., Docker image) 53 | * P2-GC/BP (0.25 -- ability to test SubscriptionTopic expressions in Lab): Subscriptions sandbox integrates with FhirPathLab for subscription topic editing 54 | * P5-BP/GC (0.5 -- WIP on new server): In memory only fhir-server for testing (cache policy?) 55 | 56 | ## Open source tools and libraries make it easy to work with FHIR and related IGs 57 | 58 | ### FHIRPath is easy to learn, debug, and use 59 | * P1-BP (0.1 -- current integration status documented): FHIRPath Lab supports an "Edit this expression" mode where: 60 | * inputs: sample data / context (if any), starting expression (possibly blank), caller name 61 | * outputs: button like `Return to ${caller}` with the edited expression --> window.opener.postMessage() 62 | * document the "API" for integrating the edit/debug fhirpath window *experimental 63 | * P3-BP (1.0): Discuss with Firely if using this tighter integration with Simplifier would be practical/useful 64 | * P1-BP (0.1 -- some infrastructure work): Prepare a foundation for a library of fhirpath expressions 65 | * Announce the creation of an openly licensed fhirpath library 66 | * Develop initial content using the FHIR Library resource 67 | * Allow users to create/contribute to the library content (simplify sharing/managing content) 68 | * Provide an easy way to open any branch/fork of the library in the editor 69 | * P3-BP (0.7): Contributions to open source `fhirpath.js` to support accessing the **path** of the returned values where available (facilitates diagnosing where content came from) 70 | * P5-BP (0.0): Enhanced fhirpath expression debugging/visualizing features (e.g., AST summarization / viz, to show explanations or warnings about behaviors) 71 | 72 | ### Changes between versions of specification publications are easy to discover 73 | * P0-GC (0.1): Technical implementers can access diff tooling to compare the contents of package versions, without having to compile code 74 | * P1-GC (1.0): Change detection covers all definitional resource types (e.g., canonical resources) 75 | * P1-GC (0.0): The Diff-tooling is well-documented 76 | * Documentation Site 77 | * Video walkthrough/tutorial 78 | 79 | ### Technical implementers have access to specification-based tooling 80 | * P0-GC (0.25 -- docs updated for current capabilities, but users still need to compile): Technical implementers can access code-generation tooling, without having to compile code 81 | * Documentation Site 82 | * Video walkthrough/tutorial 83 | * P0-GC (1.0): OpenAPI supports: 84 | * Azure API Management 85 | * Swagger definitions in aspnet (for developer documentation and testing) 86 | * CapabilityStatement conformance-expectations 87 | * P1-GC (0.4 -- internal session; no public content): Setup and record show & tell for OpenAPI 88 | * P3-GC (0.2 -- some infrastructure): Web-UI can show/display/download exports 89 | * PX-BP (1.0 loader tool + repo): Server support for loading IGs, followed up with Firely 90 | 91 | ### FHIR community has a shared long-term versioning strategy 92 | * P1-BP/GC (0.0): Published educational content (youtube/blog) series evaluating options, including discussion of: 93 | * Up/down converting using FHIR Mapping language and other techniques 94 | * GC/BP impact on server implementers 95 | * impact on client implementers 96 | * impact on health institutions (pure FHIR vs. facade) 97 | * Later... 98 | * Presentation to ... FMG? FHIR-I? 99 | * POC implementations of some of the approaches 100 | * Impact on toolchains/software packages/packaging 101 | 102 | ### .NET (Firely) SDK 103 | * Firely SDK incorporates SDC Functionality (Hl7.Fhir.StructuredDataCapture) 104 | * SDC Validator 105 | * P1-BP (0.0): Work is underway to merge component into Firely SDK (R4/R4B) 106 | * P4-BP (0.0): Decide with Firely on approach to R5 implementation 107 | * SDC Extrator 108 | * P1-BP (0.0): Include/Enhance the QuestionnaireResponse SDC $extract functionality to also cover Definition as well as Observation functionality (supporting future use in SDOH based implementations - social needs screenings) 109 | * Simplify usage of Implementation Guides for SDK developers 110 | * P5-BP/GC (0.1 -- some upstream work on core spec): Create tooling for IG-based NuGet packages to support easier adoption (e.g., codegen to provide accessors for extensions) 111 | * P1-GC (0.0): Building internal Firely models is a separate step during export, within the Firely `ILanguage` implementation 112 | * P0-BP/GC (1.0 from Jan connectathon snapshot + R5 candidate): Each time FHIR publishes a new shapshot or ballot candidate, we run codegen, validate results, repair bugs, and notify Firely that it is ready for packaging/release 113 | 114 | ## Our team consistently advocates for patient access rights 115 | * P0-JM (1.0): Published set of principles for patient access under TEFCA 116 | * Blog or "op-ed" on the case for consumer access in healthcare 117 | * P2-JM (0.1): Draft and shared internally 118 | * P3-JM (0.0): Published 119 | 120 | ## Team Communication 121 | * P1-GC (0.9): Create or piggyback on some "FHIR Friends" Team, inviting relevant folk 122 | * 30+ participants 123 | * 3+ teams 124 | * P1-JM/GC/BP (1.0 -- two sessions including Argonaut review): coordinate cross-team show-and-tell or Q&A on "hot topics" 125 | 126 | --- 127 | 128 | Also spent time on: team hack week, OpenAI integration examples 129 | -------------------------------------------------------------------------------- /okrs-2021-september.md: -------------------------------------------------------------------------------- 1 | # OKR Scratchpad 2 | 3 | # Sept 2021 OKRs (HL7 WGM Sept 20-24) 4 | 5 | ## HL7-published SMART standards improve every year based on community feedback 6 | 7 | ### (0.25) SMART Web Messaging V1 is published 8 | * P0 (0.6) Remaining ballot (and post-ballot) issues are resolved and applied 9 | * includes support for scratchpad query / read 10 | * P0 (0.5) Demo app and library support the full Web Messaging spec 11 | * P0 (0.0) Publication requested through HL7 12 | * P1 (0.0) Migrate the client [library portion of the current repo](https://github.com/barabo/swm-dd-demo/tree/main/lib) into [microsoft-healthcare-madison](https://github.com/microsoft-healthcare-madison) (or smart-on-fhir, if possible) 13 | 14 | ### Bulk Data V2 is ready for publication 15 | * P0 (1.0) All ballot comments triaged 16 | * P1 (1.0) Dedicated telecon session is scheduled (or joint with App Launch) for all ballot comments requiring "in-person" discussion 17 | * P1 (1.0) All ballot comments have proposed resolutions 18 | * P1 (1.0) All ballot comments that can be block-voted are block-voted 19 | * P2 (1.0) All ballot comments requiring in-perseon discussion are discussed and voted 20 | * P2 (1.0) All decisions are applied in GitHub 21 | * P2 (0.8) Publication requested through HL7 22 | 23 | ### SMART App Launch V2 is ready for publication 24 | * P0 (1.0) All ballot comments triaged 25 | * P1 (1.0) Dedicated telecon session (or joint with Bulk) is scheduled for all ballot comments requiring "in-person" discussion 26 | * P2 (1.0) All ballot comments have proposed resolutions 27 | * P2 (1.0) All ballot comments that can be block-voted are block-voted 28 | * P2 (1.0) All ballot comments requiring in-person discussion are discussed and voted 29 | * P3 (1.0) All decisions are applied in GitHub 30 | * P3 (0.8) Publication requested through HL7 31 | 32 | ## Subscriptions are scalable and flexible 33 | * P0 (1.0) Design / decide on a mechanism for including additional resources 34 | * P0 (1.0) Design / decide on a mechanism for creating event-based subscription topics 35 | * P1 (0.8) Document updated security guidelines for REST notifications 36 | * P1 (1.0) Review SMART backend services auth 37 | * P1 (1.0) Evaluate if additional elements are required to support auth 38 | * P5 (0.8) Additional tooling for implementer support 39 | * P5 (0.0) Prototype implementation of encrypted rest hook (e.g., by comparison with India's HealthStack) 40 | 41 | ### Subscription Backport IG is ready for publication 42 | * P0 (0.8; websocket subprotocol still TBD) All January ballot comments applied 43 | * P0 (1.0) Document and model mechanism for additional resources 44 | * P0 (1.0) Document and model mechanism for event-based subscription topics 45 | * P0 (0.9; still need to incorporate `SubscriptionTopic.notificationShape.revInclude`) Add new resources to R4B (SubscriptionTopic and SubscriptionStatus) 46 | * P0 (1.0; some newer tickets still TODO) All approved tickets applied by end of August (included in connectathon snapshots) 47 | * P0 (1.0) Run connectathon track to get 'last chance' feedback prior to IG publication 48 | * P1 (1.0) Update RI prior to connectathon for testing 49 | * P2 (0.5) Perform 1:1 content reviews with at least 2 implmenenters (not present on Argo calls, include both cloud and dedicated EHR vendors) 50 | 51 | ### Subscription R5 Content is ready for publication 52 | * P0 (0.0; decided to prioritize design and backport over R5) Block-vote all open tickets that match R4 backport changes 53 | * P0 (0.0) Apply all tickets to match updates from backport feedback 54 | * P0 (0.0) Document and model mechanism for additional resources 55 | * P0 (0.0) Document and model mechanism for event-based subscription topics 56 | * P1 (0.0) All approved tickets applied by end of August (included in connectathon snapshots) 57 | * P2 (1.0) Include in connectathon track for testing 58 | * P3 (1.0) Update RI prior to connectathon for testing 59 | * P5 (0.0; but CS2 is no longer part of R5) Implement CapabilityStatement2 60 | 61 | ## Standards Incubation and Acceleration projects expand interoperability 62 | 63 | ### SMART Health Cards are widely available to consumers 64 | * P0 (1.0) Consumer landing page is finalized including translations in at least English, Spanish, and French 65 | * P1 (1.0) New issuers are subscribed to Zulip chat and bring questions to the community (at least three new issuers) 66 | * P1 (0.4; discussions but no deployment) Issuers that are healthcare providers or pharmacies offer Immunization records for at least one vaccine type beyond COVID-19 (e.g., childhood vaccines or travel vaccines) 67 | * P3 (0.0) HL7 PSS submitted for SMART Health Cards "Framework IG" 68 | * Joint copyright agreement in place with HL7 69 | 70 | ### SMART Scheduling Links are widely available to consumers 71 | * P1 (1.0) New pharmacies or healthcare providers are subscribed to Zulip chat and bring questions to the community (at least three new organizations) 72 | * P1 (0.3; discussion only) Publishers begin to publish "granular appointment" data including specific 73 | * P1 product information for COVID-19 vaccines 74 | * P2 appointment times (rather than just dates) 75 | * P2 (0.0; brief discussion of flu) Publishers begin to publish appointments for vaccines other than COVID-19 76 | 77 | ## Expand and engage the FHIR Community (including inside of Microsoft) 78 | 79 | ### Microsoft-internal teams review and provide HL7 ballot feedback 80 | * P0 (0.4) Work with product team to identify a broad pool of at least five voting members 81 | * P0 (0.4) Coordinate voting members (e.g., internal mailing list) prior to ballot registration (end of July), identifying at least one spec (and not more than three!) for each voting member to review 82 | * P1 (1.0) Check in with voting members at least one week before ballot closes 83 | * P1 (0.5) Check in with at least 2 orgs/teams for visibility 84 | 85 | ### Developers, students, and others learn FHIR through openly published content 86 | 87 | * P1 (0.4; took suggestions from #implementers discussion) Solicit community topic suggestions in #social and with pointers to [Team Project Board](https://github.com/microsoft-healthcare-madison/team/projects/1) 88 | * P2 (1.0) At least six new videos in Josh's "Guided Walk through FHIR" series 89 | * P3 (0.0) Start a "Welcome to SMART App Launch V2" video series 90 | * P2 Explanation of granular scopes, including demo queries 91 | * P2 Explanation of PKCE, including demo 92 | * P2 Explanation of token introspection, including demo 93 | * P4 Explanation of asymmetric client authentication in SMART App Launch 94 | 95 | * P1 (1.0) At least 10 new videos in Gino's "FHIR for Developer Series" 96 | * ?P?2 (0.0) Begin including TypeScript content (at least 2 videos) 97 | 98 | ## Advanced tooling addresses unmet community needs (e.g., library support, ergonomics, performance) 99 | 100 | * P1 (0.3) SMART App Launcher has merged support for all SMARTv2 features 101 | * P1 (0.7; PR in place sans backend services) including UI and documentation for registering clients with asymmetric keys 102 | * P2 (0.3; some support but enforcement is all-or-nothing, doesn't yet support _include) including a mode for enforcing granular scopes (*only* allowing queries that ~directly match a granted scope, without enabling `_include`, `_has`, or other "advanced" features) 103 | 104 | ### C# 105 | * P0 (0.2) Design / implement 'pluggable' serializer interfaces / factories to Firely 106 | * P0 (0.0) Published in NuGet (Firely Net API) 107 | * P0 (0.6) System.Tex.JSON serializer/parser 108 | * P0 (0.0) Published in NuGet (Firely Net API) 109 | * P1 (0.4) Add option to either throw or 'do what you can' and return an OperationOutcome 110 | * P5 (?) Add support for `_summary` 111 | * P5 (?) Add support for `_elements` 112 | * P1 (1.0) Discuss / design / evaluate updated target model definitions (e.g., IDictionary) 113 | * P2 (0.2) Create tooling to better support use of IGs and Extensions 114 | * e.g., classes with ergonomic support for (complex) extensions defined in IG 115 | * P5 (0.4) Design and implement a process for non-terminology validation (e.g., Fluent Validation) 116 | * P5 Support IG model validation 117 | * P5 (0.0) Create a streaming JSON 'modification' transcoder (add/remove/modify elements in single pass) 118 | 119 | ### Python 120 | * P1 (0.1) 1 week sprint - evaluate the current state of the [smart-on-fhir python client](https://docs.smarthealthit.org/client-py/index.html) 121 | * P2? (0.0) fork that only supports Python3 122 | 123 | 124 | --- 125 | 126 | # Future scope / Ideas Scratchpad 127 | 128 | * SMART Proxy (simplify SMART workflow from desktop apps) 129 | * Generic FHIR UI / browser (from code-gen?) 130 | 131 | ### Argonaut provides specifications for individual level "Full EHI Export" API 132 | * P0 A telecon series of at least three calls is scheduled 133 | * P0 In telecon calls, review "default" vendor plans 134 | * UX and/or APIs for consumer 135 | * Expected data formats 136 | * Expected export size ranges (e.g., 99th percentile export size might be ... ?) 137 | * Expected workflow for moving data (e.g., something allowing resume/recover?) 138 | * P1 Draft an API definition as a thin wrapper supporting diverse vendor plans 139 | 140 | ### CARIN / Consumer Access to Imaging 141 | 142 | ### TypeScript 143 | * Design 'library' style FHIR models (coordinate with community) 144 | * P4 Extension handling (primitive and complex types) 145 | * P5 Runtime validation (non-terminology) / schema-based 146 | 147 | ### OpenAPI 148 | * Support definitions that are useful for tools such as ReDoc 149 | 150 | --- 151 | 152 | # Other things we spent time on but didn't plan... 153 | 154 | * Core FHIR spec / usability 155 | * Da Vinci coordination? 156 | * FAST coordination? 157 | * FHIRCast coordination? 158 | -------------------------------------------------------------------------------- /okrs-2020-may.md: -------------------------------------------------------------------------------- 1 | # OKRs for May 2020 2 | 3 | *(Scoring note: COVID! We wound up putting significant effort into projects not planned in the previous cycle, including SANER + SMART Health Cards framework. For many of our "not completed" tasks, these are things we'll want to carry forward, +/- adjustment for virtual rather than in-person meetings.)* 4 | 5 | 6 | ## Objective: Subscriptions spec + reference implementation are feature complete and ready for testing at Connectathon (i.e., something we believe is ready, even if the community process introduces further changes) 7 | * P0: 1.0: Design in place and communicated to FHIR-I that addresses all known feedback (March 15) 8 | * P0: 0.8 (gaps were for low-maturity channels): Merge current pass of models and documentation in time for May Connectathon (March 31 ;-) 9 | * Resources include Bundle, Subscription, SubscriptionTopic, SubscriptionStatus 10 | * Channels include rest-hook, websocket, email, messaging 11 | * P1: (0.9m; no support for messaging channel): Update reference implementation prior to May Connectathon (May 1), supporting 12 | * All channel types (current channels + new support for messaging channel) 13 | * SubscriptionTopics for `encounter-start` and `encounter-end` 14 | * P2: (0 -- still FAQs on spec level to address how this works): Extra features for reference implementation 15 | * Missing event workflow testing 16 | * Simulation of error states (e.g., messages not sent; messages delayed) 17 | * P0: (1.0 as of April; new ones now) Complete all "Resolved, Changed Required" Jira issues (April 1?) 18 | * (Some are already done and just need to be marked as such) 19 | * P0: (1.0 as of April; new ones now): Triage all "Triaged" and "Waiting for inputs" Subscription-related Jira issues (April 1?) 20 | * P0: (1.0 - FHIR-I incorporated these): Create required Jira issues (e.g., for creation of SubscriptionTopic) 21 | * P0: (1.0 - addressed in-band on FHIR-I):Schedule an ad-hoc FHIR-I call for Subscription issues (early April?) 22 | 23 | 24 | ## Objective: SMART Web Messaging is a formally published specification 25 | * P0 (0.4 -- missed May but included in Sept, no/low participation): Track definition submitted for May connectathon (deadline late March/early April), either standalone or piggybacking on CDS Hooks 26 | * P0: 0: Tested at May connectathon 27 | * P0: 1.0: NIB completed and approved in time for September ballot cycle (~ mid June, given holidays etc. [Calendar here](https://confluence.hl7.org/display/HL7/HL7+Calendars#a024f57c-d5fc-4f39-8b26-bf9f1e280100-35717170)) 28 | * P1: 1.0: FHIR Implementation Guide is published on "CI Server" 29 | * P0: 1.0: FHIR Implementation Guide snapshot is ready for ballot 30 | * P1: 0: Testing harness in place that performs the EHR side of the SMW interaction, maybe built on top of SMART App Launcher; maybe standalone. (Ready by May 1) 31 | * Includes support for authentication protocol (haven't had any implementation of this pre-2020) 32 | * P1: 0: Developers Guide / codelab describing how to use the test harness 33 | 34 | 35 | ## Objective: Lead the launch of Argo 2020 "Granular Permissions" Project 36 | * P0: 0.8: Establish an open community process to ensure that meeting schedules, meeting notes, and Zulip discussions are discoverable from Argonaut project homepage 37 | * P0: 0.75 (TBD still are chaining & operations, but *could* omit if needed): Define goals and non-goals for granular permissions, with group-wide consensus 38 | * P0: 0.6: Draft updates to SMART scope language to satisfy goals, and document these in a draft "SMART v2" IG, starting from the existing SMART IG repository 39 | * P2: (0.2 -- discussions but not formal review): Conduct design review with at least two cloud technology providers to ensure a path toward real-world implementation 40 | * P2: (0.5 -- got feedback from two vendors, but didn't run one-on-one review sessions): Conduct design review with at least two EHR technology providers to ensure a path toward real-world implementation 41 | * P3: (0.75 -- core features in SMART app launcher) Build reference implementation. Probably build into an open-source FHIR server (e.g., HAPI or Microsoft FHIR Server), but also see what can be done in a proxy or gateway 42 | 43 | 44 | ## Objective: Support the launch of Argo 2020 "Bulk Data $export" Project 45 | * P0: 0.8: Launch project using the open community process described above 46 | * P0: 0.9: Define goals and non-goals for incremental updates to Bulk Data $export 47 | * P1: 0.7 (impl is keeping in sync, but no formal process around it): Work with team at Boston Children's Hospital CHIP to ensure reference servers are up-to-date as specification evolves 48 | * P1: 1.0: Schedule a May WGM Connectathon track and advertise participation to key stakeholders including at least two server developers and at least two client developers 49 | 50 | 51 | ## Objective: Support the launch of Argo 2020 "Patient Lists" Project 52 | * P0: 0.8: Launch project using the open community process described above 53 | * P1: 0.6 (small data set in place; need clearer mapping to use cases): Support draft specification development with a set of sample data in bundles, suitable for loading into any FHIR server. Bundles should include pre-defined lists for each use case identified in the project goals (e.g., "which patients is Provider X responsible for today?", "Which patients are in Location Y right now?", or possibly "Which patients are in Cohort Z?"), and each resource should be tagged to facilitate updates or resets 54 | * P1: 0.4 (some scripts, not wired into automated updates): Support draft specification development by keeping a public server up-to-date, with scripts to bulk-replace our example data (e.g., in https://test.fhir.org) 55 | * P1: 0.5 (demo app with some queries, not a standalone collection): Support draft specification development by publishing a list of queries that exercise the full scope of the draft specification (e.g., as a [Postman collection](https://blog.postman.com/2015/07/02/introducing-postman-collection-format-schema/)) 56 | 57 | 58 | ## Objective: FHIR Codegen 59 | * Parse FHIR specification into an intermediate type model 60 | * P0: 1.0: R4, STU3, DSTU2 61 | * P2: 1.0: R5 62 | * P0: 0.8 (generating; still learning about specific / idiosyncratic requirements): Generate OpenAPI {interaction, model, complete} files. 63 | * P0: 1.0: Release open-source on GitHub 64 | * P0: 0.5 (zulip yes, blog post no): Announce project on Zulip and in blog post 65 | * P1: 1.0 (Firely + MS internal groups): Get feedback from at least one external user. 66 | * P1: 0.5 (Delivered tools for this work; team priorities unclear): Ensure that the team can generate (Power Platform) M-code successfully. 67 | * P2: 1.0: Generate C# models. 68 | * P2: 1.0: Generate TypeScript models. 69 | * Retrieve Capability Statements from FHIR servers to restrict outputs based on types, interactions, and search parameters supported 70 | * P1: 1.0: R4, STU3, DSTU2 71 | * P2: 1.0: R5 72 | * P1: 0.0: Build an API server to accept configuration options and return a desired code file. 73 | * P2: 0.0: Build a UI on top of the API server to allow a user to configure code generation and download the generated code file 74 | 75 | 76 | ## Objective: Maintain community presence through education, communications 77 | * P0: 1.0: Present on 2+ team projects at FHIR Dev Days (note, this is reflected in other objectives, too) 78 | * P0: 1.0: Lead tracks for 2+ team projects at FHIR Connectathon (note, this is reflected in other objectives, too) 79 | * P1: 0.0 (some work on one code lab): Create a collection of codelabs/tutorials at a new site 80 | * similar to: https://codelabs.developers.google.com/ 81 | * register https://fhir.how/to/ (or something) 82 | * P1: 0.0: Publish two blog posts on MS Open Source Blog 83 | * P2: 0.0: Create a list of potential blog post topics as a team (below is a starter list) 84 | * PAMA Imaging 85 | * Decentralized Identity 86 | * Argonaut projects for 2020 87 | * AllOfUs participation experience & project overview 88 | * Creation of a collection of codelabs/tutorials at a new site 89 | * P2: 0.0 (COVID): Get Wild - Engage the Madison Healthcare Tech community 90 | * Define target community for a meet-up at Microsoft in Madison 91 | * Attend any Madison-area health tech meetups 92 | * Host a social / offsite for Madison area Argonaut participants 93 | * (Scoring note: other activities -- participated in Authz meetup, ONC Dev Forum as community events) 94 | 95 | 96 | ## Objective: Commit to a "Team Madison Core Project" 97 | * P0: 0.0: Conduct a brainstorming session to explore projects that emphasize these key goals 98 | * We can make progress at our own pace without external (standards body) dependencies 99 | * Expand frictionless data access for consumers 100 | * Leverage existing and emerging open standards 101 | * Tackle challenges that are "under-served" in industry today 102 | 103 | * P1 (0.5 -- in this span, focused on SMART Health Cards Framework): Scope out and make a decision among the following project ideas 104 | * Consumer access to query networks, using self-owned identifiers 105 | * Consumer access to imaging data, using "glue" services between EHR FHIR implementations and cloud-hosted DICOM services 106 | * Placeholder -- other project ideas? 107 | 108 | 109 | ## Objective: Maintain connections within and across MS teams working on healthcare 110 | * P1: 0.0 (COVID): Schedule travel and draft (or glom onto!) a project plan for team particiaption in the Microsoft June OneWeek hackathon 111 | * P2: 0.2 (Several ad-hoc, but not advertized): Offer a "health standards office hours" or "FHIR workshop" to internal teams, advertising and hosting one session with a broad invite list 112 | * P2: 0.2 (Again, ad-hoc discussions for data mapping, anonymization tagging, but not planned/advertised): Host an internal a "wishlist" or brainstorming session to solicit experiences and gaps across internal teams 113 | -------------------------------------------------------------------------------- /okrs-2025-september.md: -------------------------------------------------------------------------------- 1 | # OKRs for July - Sept 2025 2 | 3 | ## Enhance HL7 Specifications 4 | * P1 (BP) Continue progress in reconciling FHIRPath specification toward R3 release before Christmas 2025 (2 weeks) 5 | * [x] (1.0) All approved jira changes applied to the specification - *remaining tickets need clarifications/re-opening* 6 | * (0.9) All open jira issues have proposed dispositions pending committee time/approval 7 | * (0.1) Additional unit test cases added for enhancements/changes to the fhirpath specification 8 | * [x] P1 (BP) (1.0) Support the reconciliation of the SDC R4 specification, hoping to be complete, and changes applied for publication around Sept WGM (2 weeks) 9 | * P2 (BP) (0.5) Apply the Patient Administration R6 changes to the core specification (3 days) 10 | * P2 (BP/GC) (0.0) FML core spec issues identified and changes applied (1 week) 11 | * P1 (BP) (0.1) Apply all approved core spec fhirpath page changes 12 | * P3 (BP) (0.0) FML g4 approved into FHIR R6 (1 week) 13 | * P3 (BP) (0.0) Apply Gino's updated xver extensions database into the FML cross version maps, and validate consistency (2 weeks) 14 | * P3 FML Maps validated for consistency with xversion extensions/maps - tooling reports issues 15 | * P4 FML Maps updated to also include the xversion extensions 16 | 17 | ## Provide Educational Content to support Users of HL7 specifications 18 | * P1 (BP) Education Material supporting SDC extraction - At least 2 YouTube clips and 2 blog posts (3 days) 19 | * Learning objectives 20 | * (0.5) Understand and apply template-based extraction 21 | * Understand and apply definition-based extraction 22 | * P2 (BP) Education Material supporting FHIRPath - At least 2 YouTube clips and 2 blog posts (3 days) 23 | * Learning objectives 24 | * (0.5) Debugging FhirPath expressions 25 | * Understanding FhirPath $this, $focus and input collections 26 | * unplanned (0.1) started building learning material for fhirpath "fhirpath-by-example" 27 | 28 | 29 | ## Enhanced tooling to support IG creators and consumers 30 | * P1 (BP) finish first pass of the FHIRPath debugger in dotnet, js and hapi (and Health Samuari?) 31 | * [x] (1.0) Debug Trace injection point available in public HAPI library 32 | * [x] (1.0) UI for Debugging released in production deployment of FhirPath Lab 33 | * (0.9 *PR in progress*) Debug Trace injection point available in public FhirPath.js library 34 | * [x] (1.0) Debug Trace injection point available in public Firely SDK 35 | * [x] P2 (1.0) AST/Debug interface documented 36 | * P3 (0.0 *though they are considering it*) Health Samurai implements AST and debug trace support for the FhirPath Lab 37 | * P2 (BP) Approved new FhirPath features applied to open source engines 38 | * (0.5) coalesce 39 | * (0.5) sort 40 | * (0.2) (testing and education for $focus) 41 | * [x] P3 (BP) (1.0) Continue discussions with Ewout to move my SDC project into Firely (3 days) 42 | * Prototyping activities: 43 | * P3 (BP) (0.0) FML Validator onto nuget - consider permanent home 44 | * P4 (BP) (0.0) POC FML Map transpilation into c#/typescript/js for more performant execution (1 week) 45 | * P5 (BP) (0.0) Test tooling for x-fhir-query in the fhirpath lab? (2 days) 46 | * Unplanned extras (BP) 47 | * [x] (1.0) Inclusion of new fhirpath engines from Heleos Software (rust), OctoFHIR(rust), AtomicEHR(ts) and Damedic(go) 48 | * (0.8) CQL-Facade Proof Of Concept in advanced developer mode 49 | * Exploration of SMART Web Messaging to integrate forms engines 50 | 51 | 52 | ## Objective: FHIR R6 is a high-quality release for Long-Term Use 53 | 54 | ### The following areas of the specification are clear, correct, concise, and have examples detailing use 55 | * The following areas of the specification have no tickets in 'waiting for input' or 'unapplied' states. 56 | * P0 (GC) (0.3): FHIR Search 57 | * P0 (GC) (0.5): FHIR RESTful API 58 | * P0 (GC) (0.5): Subscriptions Framework 59 | * Review the following areas of the specification to ensure there are examples where they are needed, and that examples are correct. 60 | * P3 (GC) (0.2): FHIR Search 61 | * P3 (GC) (0.1): FHIR RESTful API 62 | * P3 (GC) (0.5): Subscriptions Framework 63 | 64 | ### FMG and WGs are aligned on content for core and 'additional' resource development 65 | * P2 (GC) (0.75): FMG has concrete plan for improved communication with WGs moving forward (whether liasons or other framework) 66 | * P0 (GC) (0.8): FMG publishes a clear description of the process for *determining* whether content is 'core' or 'additional' 67 | * P3 (GC) (0.25): FMG publishes a clear description of the process for developing/publishing additional content 68 | * P1 (GC) (0.75): WGs responsible for core FHIR content understand the 'core' vs. 'additional' distinction for resources 69 | * P2 (GC) (1.0): WGs responsible for core FHIR content have the majority of their resources properly allocated (target: ~75%) 70 | * P3 (GC) (0.2): FMG publishes guidance for breaking change considerations between R4, R5, and R6. 71 | 72 | ## Objective: FHIR Implementers have a path for interoperably adopting features from outside 'their' FHIR version 73 | * P0 (GC) (0.75): Publish the cross-version extension packages in a milestone release 74 | * Cross-Version artifacts have been reviewed 75 | * P2 (GC) (?): ValueSets 76 | * P2 (GC) (?): Extensions 77 | * P2 (GC) (?): Profiles 78 | * P3 (GC) (0.5): Publish version ~~1.2~~ 2.0 of the subscription backport IG 79 | * P5 (GC) (0.5): Argonaut R4-R6 transition work... (e.g., socialize with other accelerators, etc.) 80 | 81 | ## Objective: Patients and Implementers can use AI to interact with FHIR in reliable and ethical ways 82 | ? ## Objective: AI Tools can Understand, Consume, and Produce FHIR Reliably 83 | * P0 (GC) (0.25): `FHIR-MCP-Tools`: Start or support the start of a repo that contains MCP Tool definitions for common tools. 84 | * Definitions include: 85 | * Desriptions of definitional content (e.g., resources, search types, etc.) 86 | * Input and output schemas 87 | * ... 88 | * Example tools include: 89 | * Validate a search query 90 | * Look up definitions from a FHIR Core version 91 | * Look up definitions from an IG Version 92 | * Answer questions based on a capability statement (and feature) 93 | -- 94 | * Validate a FHIR resource against specific FHIR + IG versions 95 | * P0 (GC) (0.5): Add support to candle that exposes `FHIR-MCP-Tools`: 96 | * P0 (0.5): In a general purpose way 97 | * P1 (0.0): "About" an external FHIR server, i.e., constrainted by that server's 98 | * Capabilities 99 | * Search 100 | * SMART Launch / Scopes (tie in with Argo project) 101 | * Note: Determine if this type of implementation should even expose the FHIR API 102 | 103 | ## Objective: Lower the bar for implementers working through IG-based requirements 104 | * P3 (GC) (0.0): Update the IG-based C# generation to ensure complete support of: 105 | * P3 (GC): IG-based canonical URL listings 106 | * P3 (GC): IG-based extension accessors 107 | * P3 (GC): IG-based profile accessors (e.g., slice accessors) 108 | * P9 (GC) (0.0): Create a first pass of TypeScript IG-based export 109 | 110 | ## Objective: Handle unplanned work 111 | * (GC) (0.65): Transition fhir-codegen to a FHIR Foundation project 112 | * (GC) (1.0): Meeting coordination tasks (internal) 113 | * (GC) (0.75): FMG has tooling available to help WGs process all of their FHIR content 114 | * (GC) (1.0): Create tooling to generate SQL databases based on specification content (in fhir-codegen) 115 | * (GC) (0.4): FHIR and openEHR have sensible and usable data type mappings between specifications 116 | 117 | ## Objective: Improve analytics and AI-training workflows by improving the performance of FHIR content-extraction 118 | * P∞: (GC/BP) Review FHIR-Net-SDK (v6) parse/serialize performance and look for optimization opportunities 119 | * P∞: Implement a high-performance SQL-on-FHIR extraction utility 120 | * P∞: Consider pre-extraction of _measure_ type data into discrete values for later use 121 | 122 | ## Objective: Secure a pathway for standards-based, patient-controlled data sharing 123 | 124 | * P0 (JM) (1.0): The SMART Health Cards & Links specification is finalized and published through HL7. 125 | 126 | * P1 (JM) (0.0): Clear principles guide policy development for trustworthy network exchange 127 | * P1 Conduct discussions with at least two TEFCA stakeholders to inform the paper's content. 128 | * P1 Draft paper to include clear principles and a proposed pathway from today's exchange networks. 129 | * P1 Publish the paper as a publicly accessible article 130 | * [Unplanned] LinkedIn versions of this :-) 131 | 132 | ## Objective: Inspire the community and build momentum for AI in health interoperability 133 | 134 | * P0 (JM/GC?) (1.0): A successful "Conversational Interop" connectathon track is hosted to demonstrate a practical AI use case. 135 | * P1 (1.0) Develop and publish a v0.1 open-source reference implementation (client and server) for a conversational clinical referral workflow. 136 | * P0 (1.0) Finalize and publish the connectathon track page with scope, scenarios, and links to the reference implementation. 137 | * P1 (1.0) Attract between 10 and 30 participants to actively test the workflow. 138 | * P2 (1.0) Synthesize connectathon feedback into a public summary document with key findings and recommendations. 139 | * [Unplanned] (0.8) Submit a scholarly publication proposing conversational interoperability and sharing early experience 140 | 141 | * P1 (JM/GC?) (0.0): The HL7 "AI in Standards" Club is launched to build a community of practice. 142 | * P1 Draft and publish a charter for the group, outlining its goals and lightweight governance. 143 | * P1 Establish a dedicated public channel (`#ai-in-standards-club`?) on chat.fhir.org. 144 | * Maybe [Artificial Intelligence/Machine Learning (AI/ML)](https://chat.fhir.org/#narrow/channel/323443-Artificial-Intelligence.2FMachine-Learning-.28AI.2FML.29) 145 | * P1 Schedule and host the first two monthly meetings, focusing on practical prototypes and member-driven topics. 146 | 147 | * P2 (JM) (0.0): The "EHI Showcase" research demo is published to inspire new thinking about complex health data. 148 | * P1 Develop and publish the open-source EHI toolkit on GitHub, including utilities to structure and de-identify data. 149 | * P2 Implement an AI-powered agentic workflow that dynamically generates at least three distinct clinical summary views (e.g., Medication History, Problem List). 150 | * P2 Record and publicly share a video walkthrough of the showcase and its underlying concepts. 151 | 152 | * [Unplanned] (1.0): Kiln for synthetic FHIR data! 153 | * [Unplanned]: CMS Health Tech Pledge Ecosystem 154 | -------------------------------------------------------------------------------- /okrs-2025-january.md: -------------------------------------------------------------------------------- 1 | # OKRs for October 2024 - January 2025 2 | 3 | ## Continuous Glucose Monitoring (CGM) 2024 Project 4 | 5 | ### Objective: Argo 2024 CGM IG is ready for implementation and positioned within OO for further development 6 | 7 | * P0 (.9): Successfully conduct the November Connectathon with: 8 | * At least 2 organizations implementing the client interface 9 | * At least 2 organizations implementing the server interface 10 | * At least 1 organization representing researchers participating 11 | * P2 (0.0): (Stretch goal) At least 1 organization testing SMART Health Link capabilities 12 | 13 | * P0 (1.0): Incorporate Connectathon feedback into the draft Implementation Guide (IG) within 2 weeks of the event 14 | 15 | * P0 (1.0): Transition the project to HL7 Orders and Observations (OO) workgroup: 16 | * Host at least 2 calls under the OO workgroup by year-end 17 | * Work with OO to formally vote on importing the draft content, clearing the path for incremental future work 18 | 19 | * P1 (0.0): Create a long-lived reference snapshot of the specification that implementers can reference indefinitely 20 | 21 | * P2 (1.0): Prepare the draft IG for future HL7 ballot process: 22 | * Ensure all sections are complete and reviewed 23 | * Address any known issues or ambiguities 24 | * OO workgroup agrees on a timeline for the ballot process 25 | 26 | ## Imaging Access 27 | 28 | ### Objective: Patients can easily access their imaging data in an app of their choice, alongside their clinical data 29 | 30 | * P0 (1.0): Conduct a follow-up call with EHR developer to discuss: 31 | * Approach for separate authorization servers with shared patient accounts 32 | * Potential solutions for streamlined app registration across systems 33 | * Document key insights and action items from the call 34 | 35 | * P2 (1.0): Identify at least one potential testing site willing to explore implementation of a pragmatic approach to patient imaging access 36 | 37 | * P3 (1.0): Secure commitment from at least one imaging vendor to participate in the testing process. 38 | 39 | 40 | ## US Core Subscriptions 41 | 42 | ### Objective: US Core applications receive timely updates when clinical data changes 43 | 44 | * P0 (0.5): Conclude the consensus process for US Core subscription data feed: 45 | * Achieve agreement on core subscription parameters and payloads 46 | * Document any remaining areas of contention 47 | 48 | * P1 (0.2): Formally propose incorporation of subscription content into US Core: 49 | * Present proposal to US Core working group 50 | * Drive decision on inclusion in the next US Core release 51 | 52 | * P1 (0.2): Evaluate R6 subscription enhancements based on US Core work: 53 | * Assess need for hierarchical topics 54 | * Determine if additional flexibility is required for topic implementations that restrict the set of filters defined in a canonical topic 55 | 56 | * P2 (0.0): Create and publish a tutorial video providing an overview of core concepts behind the US Core subscription data feed 57 | 58 | ## AI for HL7 Spec Editors 59 | 60 | ### Objective: HL7 specification editors share their experiences with AI tools to enhance their work 61 | 62 | * P1 (0.8) : Organize and conduct an "AI for Spec Editors" roundtable: 63 | * Send invitations to all HL7 work group chairs and known spec editors 64 | * Secure at least 5 experienced spec editors to share their AI usage tips and tricks 65 | * Ensure representation from at least 3 different HL7 work groups 66 | * Achieve attendance of at least 15 participants 67 | * Record the session and share the recording with all HL7 work group chairs within one week 68 | 69 | ## Authors and Implementers can use elements from FHIR versions outside their current version 70 | * P0 (0.1): A single slide process flow explaining how we get from Ra/Rb definitions --> a-vs-b diff --> [manual review] --> xver extensions 71 | * P0 (0.7): Complete a pass of Cross-Version IG content for review (note this is not balloted, but needs review) 72 | > [name=Josh Mandel]"RC1?" 73 | > [name=Gino Canessa] 👍 74 | * Canonical resource content: 75 | * Difference-based Value Set definitions 76 | * Extension definitions 77 | * Narrative content 78 | * Site / page content 79 | * All the element-wise diffs for all elements with changes 80 | * Package structure and contents 81 | * P? (0.6): Basic tooling to enable faster review and simpler Cross-Version IG content 82 | * View + edit of concept-domain changes (exist in ConceptMaps) 83 | > [name=Josh Mandel] e.g., semantics defining what content belongs in an element. The "concept of what the element means." 84 | * View of value-domain changes (exist in StructureMaps / FML) 85 | > [name=Josh Mandel] e.g. changing type, cardinality, binding... the stuff that appears in an ElementDefinition. The "validatable constraints that apply to an element" 86 | * View + edit of renamed code/elements (exist in ConceptMaps and StructureMaps / FML) 87 | * P? (0.0): Publish 88 | * P4 (0.0): (BP) Basic tooling to update cross-version maps to inject/validate the new extensions 89 | * All the existing cross version maps are updated and published 90 | 91 | ## FHIR community has a concrete plan for R6+ versioning issues 92 | * P0 (0.4): Document three alternative approaches for how FHIR is published 93 | * Explain the desirable properties (which are the subject of tradeoffs) 94 | * Definitions of the three approaches 95 | * Published core (6.0.0) plus modules + Singular modules package (e.g., published once per quarter - Experimental module package) 96 | * Published core (6.0.0) plus modules + Independent module packages (e.g., published by WGs) 97 | * Published minor releases with unchanged stable and breaking 'newer' content 98 | * Document the differences in the approaches (pros/cons) for the following tasks / stakeholders: 99 | * Core spec authoring (WG process and effort) 100 | * Core spec balloting and publication (WG process, HL7 staff process and effort, reviewer effort) 101 | * IG authoring and maintenance (accelerator and WG process and effort) 102 | * IG balloting and publication 103 | * Regulatory authorities (cycle time, version pinning concerns, core vs IG) 104 | * Tooling / SDK implementers 105 | * EHR/facade and native server implementers 106 | * Provider organizations (production servers) 107 | * Client implementers (app developers, integration projects) 108 | * Answers the following questions for each approach: 109 | * What does the standard process (e.g., 'normal' content development, consensus review, and publication) look like? 110 | * What do patches and unballoted updates look like for each category - e.g., would we need 6.0.1 and 6.1.1? 111 | * What does future-proofing look like in each solution - e.g., resources that do not exist yet? 112 | * Reflect on a comparison with R4B - was it successful? was the effort worth it? 113 | * Same question regarding R5 114 | * P1 (1.0): Make another presentation deck to summarize (due for FHIR Camp) 115 | * P1 (0.0): Schedule and record a roundtable discussion 116 | * P5 (0.0): Record overview video 117 | * Prototyping activities: 118 | * P3 (0.0): (BP) FML Validator onto nuget 119 | * P2 (0.0): (BP) FML g4 approved into FHIR R6 120 | * P2 (0.0): (BP) façade project updated with custom resource/module support 121 | * P5: (??) GH Build Status Check for `hl7/fhir`: "detected breaking change! Please fill out this form explaining why it's justified"? Active for FMM>=4 content. 122 | 123 | ## Implementers are able to leverage SDC extract in more cases 124 | * P0 (1.0): (BP) Enhance Definition-based extract to support extraction of multiple resources, removing the following current limitations: 125 | * Need to create hidden "shadow" properties in questionnaire 126 | * No access to QR.subject, author, or encounter (header props) - resulting in duplicating in hidden props 127 | * Linking the multiple resources together is impractical 128 | * P0 (1.0): (BP) The Definition based extract documentation is clearer and some known gaps working with multiple resources and updating existing resources are reduced/removed 129 | * P0 (1.0): (BP) Document capabilities and limitations of Template-based $extact 130 | * (Current proposal) 131 | * https://jira.hl7.org/browse/FHIR-39498 132 | * https://hackmd.io/@brianpos/extract-template 133 | * Create examples of template-based extractions 134 | * Bring analysis back to SDC committee (FHIR Infrastructure) 135 | * P1 (0.0): (BP) Produce at least 2 education artifacts supporting the use of $extract from the SDC IG (e.g. blog posts, YouTube clips) 136 | * P2 (1.0): (BP) Implementers are able to efficiently test multiple $extract implementations using the fhirpath lab 137 | * P2: (BP) Collaborate with others to produce a library of Questionnaire/QuestionnaireResponse $extract examples 138 | * (1.0) Published on github 139 | * (1.0) At least 2 contributors 140 | * (1.0) At least 5 examples 141 | * P2 (0.5): (BP) fhirpath lab supports: 142 | * Questionnaire definitions include context of 143 | * Which patient (subject) 144 | * Who is completing the form (user) 145 | * This context can drive pre-population of (e.g.) demographics, conditions 146 | * The same context can drive extraction into derived resources 147 | 148 | ## Implementers can efficiently work with geo-spatial information and FHIR content 149 | Location information is widely available inside and outside FHIR in multiple representations. 150 | This diversity of information is currently un-managed and only done in an ad-hoc manner. 151 | https://confluence.hl7.org/display/PA/Location+Service 152 | 153 | * P1: (BP) Document the way this information is currently represented (in summary form) 154 | * FHIR - Locations (points, areas, named spaces), Terminologies (named spaces + relationships) 155 | * GIS - points, named shapes 156 | * Excel Spreadsheets or other simple lists/relationships (roughly terminologies) 157 | * P1: (BP) Document how implementers are currently utilizing this information (in summary form) 158 | * Several simple use cases that the project seeks to support 159 | * P1: (BP) Recruit additional participants to work on a potential implementation guide (beyond myself and Nathan) 160 | * P2: (BP) Complete preparation of a HL7 Project Scope statement describing the scale of the work to be undertaken 161 | * ^ The above was considered, whitepaper discussion around how to do this with terminologies and decided was not a new project. 162 | 163 | ## Unplanned 164 | 165 | * (BP) IG Dependency Canonical version resolution 166 | * (0.8) Clarify how resolution of canonical resources works between packages 167 | * (1.0) Extensive processing in UploadFIG to handle package dependencies 168 | * "tree shake" resources from dependent packages 169 | * Patch the canonical URLs to be versioned while processing 170 | * Enhanced the unit testing to better support updates into the future 171 | * Investigate migrating into Microsoft GitHub Organization 172 | * (BP) VhDir finally published 173 | 174 | * (GC) FHIR-Candle work: Compartments, arch-images, transactions, and more. 175 | 176 | * (JM) Imaging authz: Connectathon with prototypes across vendors 177 | -------------------------------------------------------------------------------- /okrs-2023-september.md: -------------------------------------------------------------------------------- 1 | ## FHIR Community builds on high-quality open source tools, libraries, and sandboxes 2 | 3 | ### Working with Profiles (e.g., national and regional base profiles) is easy and error-free 4 | 5 | * P0-GC/BP: (0.0) Short series of "problem statements", as tiny programs solving a "real" problem the hard way --> the easy way 6 | * GC: (0.0) app searching for and displaying data when you _think_ the content will be in US Core 7 | * GC: (0.0) service mapping your internal structures into US Core for a FHIR API service 8 | * BP: (0.0) Compare implementing a small slice of SDC behavior (say, "execute FHIR REST queries driven by pre-pop extensions") on top of SDC-enabled Questionnaires with helpers or raw typescript 9 | 10 | * P0-BP: (1.0) [FHIR IG uploader](https://github.com/brianpos/UploadFIG) works everywhere 11 | * Without recompiling, users can supply CLI arguments for... 12 | * P0 Target server address 13 | * P0 Source package id (defaults to public registries) 14 | * P0 Local package file 15 | * P0 Remote package file by URL 16 | * P0 By default, all major canonical resources are loaded 17 | * P5 Some kind of filter to say which artifacts should be loaded? 18 | * P0 Documentation and introduction video explain usage 19 | * P0 Published as dotnet tool, invocable with `dotnet tool install ...` 20 | * P3 Tool can generate a report to verify content in server/package 21 | * Note: example usage of System.CommandLine package in [fhir-candle](https://github.com/GinoCanessa/fhir-candle/blob/main/src/fhir-candle/Program.cs) 22 | 23 | * P2-GC: (0.3) Complete a pass of IG package export for Firely C# 24 | * Goal: IG-based helper packages work alongside Firely .NET SDK (`Hl7.Fhir.R5` .NET package) 25 | * Prior work: [sdc-helpers](https://github.com/brianpos/fhir-sdc-helpers), [CS-Profiling](https://github.com/GinoCanessa/FHIR-CS-Profiling-Basic/tree/main/src) 26 | * Decide what the package contents should look like 27 | * P0: (1.0) Define namespaces to use within packages and for artifacts 28 | * P0: (1.0) Define Level 0 functionality for constants (e.g., extension URLs) 29 | * P1: (0.3) Define Level 1 functionality for getters/setters to wrap extensions (e.g., patient.UsCoreRace) 30 | * P2: (0.0) Define non-terminology validation against profile 31 | * P0: (0.5) Decide what the package names, versions and publication process should look like. Examples to think through: 32 | * `dotnet add package Hl7.Fhir.Uv.Sdc_3_0_0` 33 | * `dotnet add package Hl7.Fhir.Us.Core.6.0.0` 34 | * Support generation with codegen 35 | * P1: (0.2) Generate namespaces to use within packages and for artifacts 36 | * P1: (0.2) Generate Level 0 functionality for constants (e.g., extension URLs) 37 | * P2: (0.2) Generate Level 1 functionality for getters/setters to wrap extensions (e.g., patient.UsCoreRace) 38 | * P3: (0.0) Generate non-terminology validation against profile 39 | * P3-BP: (0.0) Experimental cut of SDC Helpers functionality using this framework 40 | * PX: (0.0) Experimental cut of subscription backport library using this framework 41 | * P3: (0.3 discussions started) Work with Firely to establish long-term publication + management plan for these packages 42 | 43 | ### Firely .NET SDK users have access to FHIR's "interface" system (e.g., CanonicalResource) 44 | * P0-GC: (0.2 design discussion) Complete a pass of FHIR Interface support from `fhir-codegen` 45 | * Background: Firely hand-maintains `IVersionableConformanceResource` interface by hand 46 | * P0-GC: Expose .NET interfaces automatically through codegen, corresponding to FHIR's 47 | * `CanonicalResource` 48 | * `MetadataResource` (sub-interface of `CanonicalResource`) 49 | * For later: Expose .NET interfaces for FHIR's patterns (Request, Event, Definition) 50 | 51 | ### Tooling helps SDK authors work with multiple versions of FHIR 52 | * Background: today normative resource classes (and a few others) in Firely use hand-authored annotations like 53 | * "since version x.y.z" (on Resources, Elements) 54 | * "not mapped after version x.y.z" (on Resources, Elements) 55 | * P0-GC: (0.8) Complete refactoring of internal models to use C# record types 56 | * P3-GC: (0.2) Improve the multi-version story of code-gen 57 | * Caller requests an export specifying multiple FHIR versions 58 | * Propose / sketch codgen interface with access to cross-version details, which can be used to determine and output things like diffs, since/not-mapped annotations 59 | 60 | ### Tooling improves the quality of specifications/applications 61 | * P1-BP: (0.8) Static Analysis Tool for FhirPath C# 62 | * Ability to verify: 63 | * Already done: all core spec Search Parameters 64 | * P1: (1.0) all core spec Invariants 65 | * P1: (1.0) CLI supports passing package to trigger testing of invariants/search parameters 66 | * *(Note: verifier may not have full coverage of language)* 67 | * P2: (0.7 discussed; no decision yet) Discuss with Firely for inclusion in the SDK 68 | * (Extra: supported validation of fhirpath in UploadFIG, validation of IG content pre-publication) 69 | * P5: (0.7) POC inclusion in Facade/Microsoft FHIR Server 70 | * P5: (0.0) Support scanning Questionnaire/SDC linkIds in expressions 71 | 72 | ## FHIR Community has access to high-quality demo environments 73 | 74 | ### Subscriptions reference stack 75 | * P0-GC: (0.5) Complete the subscriptions client page in the UI and have it deployed 76 | * P6-GC: (0.2) Add support for 'localhost' routing 77 | * Build and post a 'subscription topic' "on-ramp" (HL7 terminology for confluence pages) 78 | * Key concepts: 79 | * P1-GC: (0.0) For IG authors: Getting started with subscriptions / using the RI 80 | * For later: 81 | * For IG consumers: Getting started with subscriptions / using the RI 82 | * Designing topics: Concepts / basics / advanced? 83 | * Video walkthrough / tutorial covering 84 | * Documentation / written instructions 85 | * Detect and reject POSTed `SubscriptionTopic`s that are invalid or not supported because of: 86 | * P0: (1.0) Query-based triggers with unsupported modifiers 87 | * P0: (1.0) `canFilterBy` with unsupported modifiers 88 | * P5: (1.0) invalid fhirpath expressions (compile) 89 | * *(Point users to zulip to share their use case for prioritization)* 90 | * P4-GC/BP: (0.0 -- in-person opportunity!) Topic authoring UI - integration/linkage between RI and FHIRPath Lab. 91 | * GC: Add a button to each topic view (e.g., https://subscriptions.argo.run/store/resource-viewer?store=r4b&type=SubscriptionTopic&id=encounter-complete) with "Explore in FHIRPath Lab" 92 | * BP: Process URL parameters passed from the subs UI 93 | 94 | ### FHIR Facade 95 | * P2-BP: (1.0) Keep pace with the Firely SDK releases 96 | * P3-BP: (0.0) POC Canonical Packaging IG to show support to be a downstream server 97 | * implement the [packaging]( http://build.fhir.org/ig/HL7/crmi-ig/packaging.html) in support of SDC content distribution and loading 98 | * Support for `GET Questionnaire/:id/$crmi.package` based on http://build.fhir.org/ig/HL7/crmi-ig/index.html 99 | * Output includes Questionnaire 100 | * Output includes all external ValueSets needed for Questionnaire ("where practical") 101 | * Output includes all external CodeSystems needed for Questionnaire ("where practical") 102 | * Blog post covering the how and why of this functionality (extending on my existing posts) 103 | 104 | ### FHIRPath-Lab 105 | * P1-BP: (1.0) Support to validate fhirpath expressions (using static analysis) 106 | * P1-BP: (0.5 -- draft material) Short video on using the FHIRPath-Lab 107 | * P2-BP: (0.0) Better support for Subscription Topic editing and testing 108 | * P3-BP: (0.2) Introduction of the co-pilot style AI 109 | * P5-BP: (0.0) Experiment with design choices to evaluate all engines at once 110 | * P5-BP: (0.0) Run the HL7 fhirpath unit test suite via the tool and view output 111 | * P5-BP: (0.5 -- discussed; they plan to implement) Followup with Health Samurai and MayJuun on integrating their fhirpath engines 112 | 113 | ## FHIR community continually improves our specifications and our processes 114 | * P1: (0.3) Schedule a session to discuss quality plan for "path to R6". Brief retrospective: 115 | * Unmanageable backlog of unapplied changes 116 | * Double-application of changes from R5 + R4B 117 | * Late-breaking changes 118 | * *With suggested mitigations* 119 | * P1-BP (0.5) Keep PA/FHIR R6 on track (maintain low backlog) 120 | * P1-GC (0.5) Keep FHIR Infrastructure R6/Subscriptions on track (maintain low backlog) 121 | 122 | ## FHIR community offers high-quality openly licesned educational content 123 | 124 | ### Create annotated examples of HL7 specifications 125 | * P0-BP: (0.2) Extend the `SDC by Example` content 126 | * (Extra: built Questionnaires for IPS-based prepopulation demo) 127 | * Observation extraction 128 | * Observation & fhirpath pre-population 129 | * Assemble operation 130 | * P0-BP: (0.0) Example content covering 131 | * External form to be "ingested" into an EHR for ... 132 | * "PRAPARE Prime" (i.e., locally modified PRAPARE hide fields, add some extras) --> FHIR Questionnaire 133 | * Not technically required by US Core, but we have to write it *somehow* 134 | * "PRAPARE Prime Response" --> QR 135 | * Not technically required by US Core, but we have to write it *somehow* 136 | * "PRAPARE Prime Response" --> Observation tree (the current "SHALL") 137 | * Required by US Core, so we need to make sure it works 138 | * Include examples of local codes for the "invented" questions 139 | * Conditions derived from this assessment (e.g., food insecurity) 140 | * Following current US Core spec's requirements / Must-Supports 141 | * P1-BP: (0.0) US Core provides clear guidance and a diagram distinguishing 142 | * data collection (e.g., recorded as Observations) 143 | * problems actively tracked (e.g., Conditions) 144 | * P1-BP: (0.2) Short video series on SDC: (4-5 clips) 145 | * SDC Basics + Terminologies 146 | * Data Extraction - Obs/StructureMap 147 | * Pre-Population - Obs/FhirPath 148 | 149 | ## Health apps integrate with EHR data + workflows 150 | 151 | ### SMART apps can access imaging data 152 | 153 | * P1-JM: (0.6) Imaging specification reviewed with at least 2 PACS/network vendors 154 | * P1-JM (1.0) Connectathon scheduled for Argo Imaging participants 155 | * P2: (0.6) Includes at least 2 imaging servers 156 | * P2: (0.6) Includes at least 2 imaging apps 157 | * P2-JM: (0.0) Deployment plan is finalized for at least 1 clinical site 158 | * SMART App Launcher supports "associated_endpoints" discovery 159 | * P1-JM: (1.0) In the Imaging fork 160 | * P3-JM: (1.0) In the upstream project 161 | * SMART Client JS fork supports "associated_endpoints" retrievals 162 | * P2-JM: (1.0) In the Imaging fork 163 | * P4-JM: (0.0) In the upstream project 164 | 165 | ### SMART apps can write blood pressures to EHR 166 | 167 | * P1-JM: (1.0) Argonaut "Write Vitals" project has launched 168 | * P2-JM: (1.0) Participants include at least 2 EHRs 169 | * P2: (1.0) Participants include at least 2 apps 170 | * P3: (0.6) Participants include at least 2 health systems 171 | * P1-JM: (1.0) Consensus on use cases 172 | * P2: (1.0) clinician-triggered writes 173 | * P2: (1.0) patient-triggered writes 174 | * P1: (1.0) record the device used 175 | * P3: (1.0) convey external provenance (from outside provider) 176 | * P3: (1.0) convey app used to capture data 177 | * P3: (1.0) convey app used to submit data 178 | --- 179 | 180 | ## Extra things we worked on 181 | 182 | * SQL on FHIR -- reference implementation, tests, example 183 | * IPS Prepopulation examples including SHLink 184 | * Work with CSIRO renderer for Questionnaires 185 | * FHIRPath Lab "Save to Library" 186 | * `fhir-candle` infrastructure, tooling for IG-based reference implementations (CDEX, PAS) 187 | * Publication support for Patient Corrections IG 188 | * Refactor Patient Access Brands, and bring into scope for SMART IG 189 | * Design for notified pull within FHIR Subscriptions 190 | -------------------------------------------------------------------------------- /okrs-2026-january.md: -------------------------------------------------------------------------------- 1 | # OKRs for Oct 2025 - Jan 2026 2 | 3 | ## Enhance HL7 Specifications 4 | 5 | ### Objective: FHIR R6 is a high-quality release for Long-Term Use 6 | * P1 BP: All jira issues related to fhirpath extensions to FHIR are resolved and applied 7 | * P1 BP: All jira issues related to FHIR Mapping Language (FML) are resolved and applied 8 | * P1 BP: All approved jira issues related to Patient Administration are applied (core specification) 9 | * P1 BP: All approved jira issues related to Patient Administration are applied (extensions) 10 | * P1 BP: All approved jira issues related to Patient Administration are applied (terminology) 11 | 12 | ### Objective: FHIR Mapping Language is complete and ready for R6 conversions 13 | * P2 BP: FML g4 approved into FHIR R6 (1 week) 14 | * P2 BP: Apply Gino's updated xver extensions database into the FML cross version maps, and validate consistency (2 weeks) 15 | * P3 FML Maps validated for consistency with xversion extensions/maps - tooling reports issues 16 | * P4 FML Maps updated to also include the xversion extensions 17 | * P3 BP(/GC?): First draft maps to R6 prototyped (using Gino's tooling) 18 | 19 | ### Objective: FHIRPath is published as STU3 and ready for use by R6 and others, and on track for another normative release 20 | * P1 BP: All fhirpath jira issues are resolved 21 | * P1 BP: All approved fhirpath jira issues are applied to the specification 22 | * P1 BP: The fhirpath specification is published as STU3 23 | * P2 BP: Additional test cases are added to the FHIR unit test library covering the updated specification 24 | * P2 BP: fhirpath test cases are marked with the FHIRPath version they were introduced in where required (e.g. STU3) 25 | * P3 BP: the fhirpath test cases are verified as accurate according to the updated specification, and "contested" tests are marked as such 26 | * P3 BP: The test runner for evaluating the fhirpath test cases is verified 27 | * P3 BP: The test result matrix for all engines is executed against all engines and results published openly 28 | 29 | 30 | ## Objective: Provide Educational Content to support Users of HL7 specifications 31 | * P1 BP: Education Material supporting SDC extraction - At least 2 YouTube clips and 2 blog posts 32 | * Learning objectives 33 | * Understand and apply template-based extraction 34 | * Understand and apply definition-based extraction 35 | * P2 BP: Education Material supporting FHIRPath - At least 2 YouTube clips and 2 blog posts 36 | * Learning objectives 37 | * Debugging FhirPath expressions 38 | * Understanding FhirPath $this, $focus and input collections 39 | * Building invariants 40 | * Building search parameters 41 | * First part(s) of "fhirpath by example" published 42 | * P1 GC?/BP?: Blog post/clip(?) Understanding the R6 additional resources - walkthrough of an Additional Resources IG (e.g., Testing IG)? 43 | 44 | 45 | ## Enhanced tooling to support IG creators and consumers 46 | ### Objective: Demonstrate prototype functionality for the .NET stack implementing R6 additional resources 47 | 48 | * ??? Pick or develop an IG (Testing IG? / SQL on FHIR) 49 | * Code generation, parsing, serialization, incoproration of mixed resource content into bundles 50 | * Example REST API support for CRUDS, including: 51 | * search params defined on the additional resources 52 | * at least one operation 53 | * capability statement / feature ig support 54 | * Discussions with Firely on approach, comparison with Java approach 55 | 56 | ### Objective: Research suitability and "need" for a standardized SMART web messaging profile for SDC/forms 57 | * P2 BP: Prepare draft content for what this could look like 58 | * P2 BP: Extend the POC to demonstrate the concept as appropriate 59 | * P2 BP: Socialize draft and hold at least 2 meetings covering the content and develop a possible future plan 60 | 61 | ### Objective: The FHIRPath Lab is able to safely integrate external SDC renderers 62 | * P2 BP: The FHIRPath Lab integrates the Aidbox Forms engine 63 | 64 | ### Objective: The FHIRPath Lab usage continues to grow meeting the needs of the broader FHIR community 65 | * P3 BP: Usage increases through educational use and content promotion 66 | * P4 BP: POC usage with logical models, or other models i.e. CDA/CCDA/OpenEHR/custom 67 | * P5 BP: Supporting external terminology services better 68 | * P5 BP: Test tooling for x-fhir-query in the fhirpath lab? 69 | 70 | ### Objective: Open Source tooling supports updated FHIRPath specification 71 | * P2 BP: Approved new FhirPath features applied to open source engines (Firely/Java/FhirPath.js) 72 | * coalesce 73 | * sort 74 | * others 75 | * Other implementations are aware of changes required, and have feedback via unit test engine results 76 | * P2 BP: The FHIRPath unit test runner is more easily used locally by others to verify their engines 77 | 78 | ### Objective: Users on the .NET stack are able to more easily implement SDC and FHIRPath static validation functionality 79 | * P2 BP: Support Firely in migrating the FHIRPath static validator into the core Firely SDK 80 | * P3 BP: Prepare an agreed timeline with Firely to transition my SDC project into Firely 81 | 82 | ### Objective: FML Prototyping activities - supporting broader implementation/use of FML in other languages 83 | * P4 BP: FML Validator onto nuget - consider permanent home 84 | * P5 BP: POC FML Map transpilation into c#/typescript/js for more performant execution 85 | 86 | ---- 87 | ## Standards Development: Process and Publication 88 | 89 | ### **Objective:** Implementers are able to reliably pre-adopt features from other versions of FHIR 90 | - **P0** (GC): Cross-version tooling updated for ease of maintenance 91 | - **P4**: Update installation and usage instructions 92 | 93 | - **P0** (GC): Cross-version definitions cover all provided feedback and scenarios 94 | - **P0**: All extension definitions have proper constraints (`value` cardinality, `open` slicing, etc.) 95 | - **P0**: Review and validate vs. the manual diff pages between versions (e.g., R4/diff.html) 96 | - **P0**: Add 'reasoning'/justification narrative content to extensions 97 | - **P5**: Update technical messages with detailed mapping decisions and comparisons 98 | 99 | - **P0** (GC): IG 'Lookup' pages provide reader-friendly and comprehensive guidance to consumers 100 | - **P0**: Add Lookup files for Value Sets with parent extension inclusion 101 | - **P0**: Pages include links to: profiles of 'full resources', value set comparisons in relevant element lookups, etc. 102 | - **P2**: Improve lookup file support for display of multiple mapping targets 103 | - **P4**: ValueSet comparisons include 'escape-valve' code documentation 104 | 105 | - **P0** (GC): Computable resources for version transitions are defined 106 | - **P0**: Computable representation of "Lookup Page" content -- e.g., Map/Parameter resources for structures and elements to 'outcome' (use element same name, renamed, extension, extension of backbone) 107 | - **P0**: ConceptMap resources for mapping ValueSet codes between versions 108 | - **P8**: (GC/BP) StructureMap / FML for mapping structures (see line 17) 109 | 110 | - **P4** (GC): Cross-version support content is managed in a database instead of code 111 | - **P4**: Move all content-file source into DB (IG Parameters, Suppression messages, change log, index, downloads, etc.) 112 | - **P4**: Add processing outcomes to a database 113 | - **P4**: Add invariants/constraints for extensions via database tables 114 | 115 | - **P0** (GC): Cross-Version extensions are published in a milestone release 116 | 117 | - **P7** (GC): Developer experience enhanced with a UI 118 | - **P7**: Complete UI updates for various database content (pages, parameters, etc.) 119 | - **P7**: Add "not reviewed by me" filter for collaborative review 120 | - **P7**: Add dedicated page for replacement URLs (Extension Substitutions) 121 | 122 | 123 | ### **Objective:** FHIR R6 is a quality publication 124 | - **P0** (GC): FMG has tooling to automate the bulk of detection and flagging of issues in FHIR Core that WGs need to review 125 | - **P0**: Document guidance for core specification pages and artifacts for review 126 | - **P0**: Create tooling for automatic review of items that _can_ be reviewed programmatically 127 | - **P0**: At least 80% of WGs have reviewed the content and applied changes based on the reports 128 | - **P4**: Develop tooling to create/read/update review checklists in Confluence 129 | 130 | - **P0** (GC): Outstanding tickets as of November 1 are applied and all content has been reviewed for: 131 | - FHIR Search (page and definitional artifacts) 132 | - FHIR HTTP (page) 133 | - Subscriptions Framework (page and related resources) 134 | - Versions 135 | 136 | ### **Objective:** Implementers are able to interoperably use topic-based subscriptions 137 | - **P0** (GC): Publish STU 2 of the Backport IG 138 | - **P0**: STU 1.2 Ballot tickets are applied 139 | - **P0**: Updated with official cross-version extensions 140 | - Map existing backport extensions into the cross-version extension substitutions 141 | - Update IG with cross-version extensions and remove unnecessary artifacts 142 | - **P0**: Workgroup process --> publication of STU2 143 | - **P0**: Engage with at least 3 downstream implementers and/or authors to streamline adoption 144 | 145 | ### **Objective:** HL7 Processes are current, discoverable, and support standards development 146 | - **P0** (GC): Documented proposal for an updated HL7 Standards process and present to TSC 147 | - **P0**: Document our real-life processes for project and publication lifecycle (Project Proposal -> PSS -> IG proposal -> publication 'life' -> retirement) 148 | - i.e., the things that are in fact routinely checked/enforced by committees and tools 149 | - avoiding misconceptions / wishful thinking, and pointing out where "real-life" processes are misaligned with the "official process". 150 | - **P0**: Draft of policies and expectations around change management match maturity 151 | - e.g., establish a terminal-state "standard publication level" that's shy of normative 152 | - e.g., establish a project lifecycle independent of publication lifecycle 153 | - **P0**: Documents presented to TSC for review 154 | 155 | - **P2** (GC): Documented ballot consensus pool requirements that match desired participation expectations 156 | - **P2**: Reviewed existing guidance to distill principles/intentions and document concisely 157 | - **P2**: Draft of guiding principles for new framework 158 | - **P3**: Draft of requirements for successful ballot participation 159 | - **P3**: Documents presented to TSC for review 160 | 161 | ### **Objective:** FHIR and openEHR implementers have a path toward interoperability 162 | - **P2** (GC): FHIR and openEHR data types have documented guidance to map content between formats 163 | - **P2**: Document mappings on [existing Confluence page](https://confluence.hl7.org/spaces/FHIRI/pages/391646604/Current+Mapping+Decisions) with expectations on loss, decision points, etc. 164 | - **P4**: Computable definitions are available online to allow easier use (e.g., on GitHub) 165 | 166 | ---- 167 | ## Lowering the Bar: Education and Tooling 168 | 169 | ### **Objective:** FHIR is accessible to implementers and newcomers 170 | - **P0** (GC): Educational content is published and freely available 171 | - **P0**: Review existing content and requests and document plan for next sequence of recordings 172 | - **P0**: Publish at least 5 new videos to YouTube 173 | 174 | 175 | ### **Objective:** FHIR Implementers have access to open and high-quality tooling 176 | - **P0** (GC): fhir-codgen completes move to FHIR Foundation 177 | - **P0**: Project contents (code, documentation, license, etc.) are clean of Microsoft branding 178 | - **P0**: Project contents (code, documentation, license, etc.) are conformant with FHIR Foundation policy 179 | - **P0**: Repository has been moved to FHIR GitHub org (with prior location as a forward pointer) 180 | - **P6**: Libraries and tools are publicly published via NuGet 181 | 182 | 183 | ------ 184 | 185 | ## Conversational Interoperability: From Connectathon to Community 186 | 187 | **Objective:** Build sustained community of practice around conversational interoperability 188 | * **P0** (JM): Host a community call 189 | * Host monthly "COIN Office Hours" on AI Zulip stream 190 | * Attract ≥5 participants per session 191 | * Document discussions and action items publicly 192 | * **P1** (JM): Evolve Banterop based on Connectathon learnings 193 | * Address participant feedback on scenario testing (e.g. A2A REST transport) 194 | * Improve deployment documentation 195 | * **P1** (JM): Submit scholarly perspective for publication 196 | * Draft paper on conversational interoperability patterns 197 | * Submit to academic venue or industry publication 198 | * Include co-authors from Connectathon participants 199 | --- 200 | 201 | ## HL7 Financial Interest Transparency: From Proposal to Implementation 202 | **Objective:** Establish transparent financial disclosure framework for HL7 governance and standards leadership 203 | * **P0** (JM): Secure Board approval for GOM amendments 204 | * Present proposal at [Month] Board meeting 205 | * Address Board member questions and concerns 206 | * Incorporate feedback and achieve majority support 207 | * **P1** (JM): Build coalition of supporting Board members 208 | * Conduct 1:1 discussions with ≥5 Board members prior to vote 209 | * Address concerns about implementation burden and privacy 210 | * Demonstrate alignment with nonprofit best practices 211 | * **P2** (JM): Develop implementation infrastructure 212 | * Draft disclosure form and submission process 213 | * Design public register website interface 214 | * Create guidance materials for affected individuals 215 | * **P2** (JM): Prepare community communications 216 | * Write blog post explaining rationale and approach 217 | * Develop FAQ addressing common concerns 218 | * Create timeline for phased rollout 219 | 220 | --- 221 | 222 | ## Electronic Health Information Export: Close the Gap Between Policy and Practice 223 | **Objective:** Transform EHI Export from compliance checkbox to genuinely useful patient capability 224 | * **P1** (JM): Complete updated personal EHI export 225 | * Request and obtain current EHI export from [Hospital] 226 | * Identify persistent barriers and new issues 227 | * **P2** (JM): Develop prompt library for EHI analysis 228 | * Create reusable prompts for common patient questions 229 | * Document effective multi-step workflows for complex queries 230 | * Test across ≥2 different LLM providers for robustness 231 | -------------------------------------------------------------------------------- /okrs-2024-january.md: -------------------------------------------------------------------------------- 1 | ## SMART Imaging Access is widely available for access (JM) 2 | 3 | ### Argonaut specification is finalized 4 | * P0 (0.8): Connectathon includes at least 2 PACS and at least 2 consumer app participants 5 | * P0 (0.7): Connectathon lessons learned are incorporated into spec 6 | * P2 (0.0 -- did not get traction even for the "simple" async of "please try again"): Update `async` functionality to match https://hl7.org/fhir/async-bundle.html 7 | 8 | ### Initial implementers are on a path to deployment 9 | * P0 (0.0 -- not for lack of trying): Identify at least one real-world clinical organization to deploy imaging access 10 | * P1 (0.0, missing prereq) : Establish deployment plan and support efforts with "high touch" engagement 11 | * P4 (0.0): Pre-production environment is ready for testing 12 | 13 | ## SMART ~~Patient~~User Access Brands (JM) 14 | * P0 (1.0): Branding Extensions on track for Jan ballot of FHIR Extensions IG 15 | * P1 (1.0): PAB updated to use Branding Extensions 16 | * Profiles in PAB, extensions in Extensions IG 17 | * Examples updated 18 | * P2 (1.0): PAB on track for Jan ballot 19 | * P5 (0.0): Identify a champion for "Shorthand in FHIR Extensions IG" -- it should be easier to write and review content for the extension IG, and FSH would help! 20 | 21 | ## Standards-based data serve as a foundation for clinical analytics (JM) 22 | 23 | ### SQL-on-FHIR v2 spec is widely implemented 24 | * P2 (0.8): Frozen draft spec 25 | * P2 (1.0): At least two implementations designed for use at scale 26 | * P3 (0.2 -- conversations started): Internal participation 27 | * P5 (0.0 -- but we have JSON Schema + FHIR Logical Model) Typescript definition for ViewDefinition 28 | * P5(BP) (0.0): DSL concepts? 29 | 30 | ### Digital quality measures are based on real-world EHR data (JM) 31 | * (0.3 -- drafted): Publish perspective highlighting use of real data to design lightweight measures 32 | * (1.0): Advocate for simplification of measures with ARPA-H leadership 33 | 34 | ## Interop community understands and leverages LLMs where applicable (JM) 35 | 36 | ### "Future of interop" perspective is submitted for academic publication 37 | * P0 (0.5 -- WIP): Outline 38 | * P1 (1.0): Authors on board 39 | * P2 (0.6): Draft reviewed with comments 40 | * P2 (0.0): Draft submitted for publication 41 | 42 | ### Open source demos and examples are widely available 43 | * P1(all) (1.0): HACK WEEK 44 | * Scheduled time in early December 45 | * P1(all) Questionnaire-filling as a focus (end result is a QuestionnaireResponse) 46 | * P5 (0.3 -- schema creation + instance data formatting): Data format conversion from EHI exports? 47 | * P5 (0.3) Manual data abstraction with GPT-4? 48 | 49 | ## FHIRPath Lab Supports Cross-Implementation Testing 50 | * P0(BP) (1.0): Community-maintained test cases are up-to-date; broken content is eliminated from https://github.com/FHIR/fhir-test-cases/pull/151 51 | * P0(BP) (1.0): Library-wrapped test cases are updated with to the latest content 52 | * P1(BP) (1.0): fhirpath-lab extensibility is documented 53 | - Git Repo includes documentation explaining how other engines can be incorporated 54 | - Health Samurai team is aware 55 | * P1(BP) (0.1): FhirPath-lab subscription supports subscription topic editing 56 | - FhirPath-lab supports "Topic Editing", starting from new or existing topic 57 | - Notification shape 58 | - Filters 59 | - All fields of SubscriptionTopic can be created/edited, with basic schema validation in place 60 | - More complete support for editing triggers 61 | - `fhirpathCriteria` can be edited and validated 62 | - `fhirpathCriteria` can be evaluated against sample instances *(basically done)* 63 | * P1(BP/GC) (0.2): FhirPath-lab subscription editor can be launched from fhir-candle 64 | - Launch from fhir-candle subscription topic window 65 | - Launch from fhir-candle test case window (with specific expression windows) 66 | - Launch includes `fhirserver` parameter to ensure correct server 67 | * P5(BP) (0.5): FhirPath-Lab AI Chat 68 | 69 | 70 | ## FHIR Questionnaires are robust and easy to use (BP) 71 | 72 | ### Educational material makes Questionnaires (including SDC pre-populated content) easy to adopt 73 | * (0.0): Introductory content for new users 74 | * P0 (0.0): Series of feature-focused videos including 75 | * Basic structuring simple questionnaires 76 | * Several pre-pop videos covering increasingly complex use cases 77 | * P0 Observation based 78 | * P0 fhirpath based 79 | * P2 StructureMap based 80 | * P1 (0.7): A standalone IPS pre-pop demonstration shows how to use SDC pre-population 81 | - published as separate repo 82 | - supports swappable renderers (lforms/csiro) 83 | - Responsibility of a renderer is maintaining the form and managing interactions 84 | - Renderer essentially uses: 85 | - `Renderer.render(domElement, questionnaire, [questionnaireResponse])` - can be partial or complete 86 | - `Renderer.retrieveCurrentStatus() => QR` 87 | - Hack week to try auto-populating forms embedding? 88 | - Populate a "best guess" above some threshold 89 | - Populate an extension with "other suggestions"? 90 | 91 | ### Open-source tools support advanced validation of Questionnaires 92 | * P2 (0.0): QuestionnaireResponse validation merged into Firely SDK 93 | 94 | ## FHIR community continually improves our processes (BP) 95 | * P0 (1.0): Keep PA backlog low - particularly changes applied 96 | - (1.0): Core build to support new resources (again) - sent to GG in PR - done 97 | - (0.0): VhDir STU1 published 98 | 99 | ## Open-source tooling makes FHIR easy to use (BP) 100 | 101 | * P1 (0.0): Upload-FIG is published as a MS open source project + Nuget package 102 | * Internal application submitted 103 | * Repository migrated 104 | * Internal build pipelines configured 105 | * Signing keys established 106 | * Automated publication to Nuget 107 | * P1 (0.0): MS FHIR Server POC materials shared with Server team (and my branch deployed - including the below features) 108 | * New Firely SDK 5.x parser 109 | * SDC Validation 110 | * SDC pre-pop 111 | * StructureMap/FML parser/serializer 112 | * StructureMap evaluator 113 | * fhirpath validation 114 | * current canonical processing 115 | * General feedback reviews 116 | * P3 (0.0): FHIR Canonical Resource Management Interface (CRMI) IG has independent reference implementation. 117 | * POC packaging server implementing https://build.fhir.org/ig/HL7/crmi-ig/OperationDefinition-crmi-package.html 118 | * Minimal use case: Moving questionnaires from a (development --> production) environment. Example deployment scenario: 119 | * Source server supports `$crmi.package` 120 | * Source server has `Questionnaire/example|2.0.0`, a new Questionnaire, which in turn depends on ... ValueSets and other Questionnaires (via `import-questionnaire` extensions) 121 | * User calls `$crmi.package( Questionnaire/example|2.0.0)` to produce an importable bundle 122 | * UploadFIG supports the uploading of a "package" prepared by the `$crmi.package` operation 123 | * As a reference implementation to test the IG 124 | * Key areas to implement 125 | * create package https://build.fhir.org/ig/HL7/crmi-ig/OperationDefinition-crmi-package.html 126 | 127 | * P2 FHIR-PATH Validator - symbol table merge with Firely SDK 128 | - (0.0): Update the SDK to better support leveraging the fhirpath symbol table for external usage 129 | - (0.0): Leverage the enhanced symbol table in the fhirpath validator 130 | - (0.7): Encourage if this validator can be adopted into the SDK 131 | - (0.3): comments parsing integrated into SDK (complete/merge existing work) 132 | - (0.9): Position information in fhirpath expression parsing - mostly complete 133 | - (0.9): Include `CustomExpression` capability into the SDK - done, needs to be merged in 134 | - (0.9): Brackets `()` to be able to be included in the expression tree (via the new CustomExpression) which then can enable round-tripping expressions to/from strings 135 | 136 | * P1 (1.0): Prepare `withVariable` proposal to add to fhirpath for consideration by HL7 137 | https://dev.fhirpath-lab.com/FhirPath?libaryId=7775d5cf3df540a38b34e83b27f8f284 138 | 139 | 140 | ## Open-source tooling makes FHIR easy to use (GC) 141 | 142 | * P1: (0.3): Publish a package resolution and local FHIR cache management tool 143 | * P1: .Net Library is available in NuGet 144 | * P1: .Net tool is available in NuGet 145 | * P6: Investigate the MS policies around publishing AOT compiled native binaries 146 | * P5: Create a PoC NPM facade that indexes the contents of CI Builds (core and IG) 147 | * P1: (0.3): Publish `fhir-codegen` 148 | * P1: .Net Library is available in NuGet 149 | * P1: .Net tool is available in NuGet 150 | * P0: (0.8) Update the `fhir-codegen` Firely language to output FHIR Interfaces 151 | * Background: Firely [hand-maintains the `IVersionableConformanceResource` interface](https://github.com/FirelyTeam/firely-net-sdk/blob/71269dfa12511b6c8372d8e540281ed5cd06014f/src/Hl7.Fhir.Base/Model/IConformanceResource.cs#L56) 152 | 153 | * P0: (0.5) Create .Net interfaces corresponding to FHIR's 154 | * `CanonicalResource` 155 | * `MetadataResource` (sub-interface of `CanonicalResource`) 156 | * P0: (0.2) Add partial class definitions to resource model classes that implement the interfaces for each version of FHIR 157 | * Background: Firely [hand-maintains implementations of the `IVersionableConformanceResource` interface](https://github.com/FirelyTeam/firely-net-sdk/blob/main/src/Hl7.Fhir.R4/Model/IConformanceResource.cs) 158 | * Add stub properties for elements that do not exist (i.e., getter returns null, setter throws exception). 159 | * For later: Expose .NET interfaces for FHIR's patterns (Request, Event, Definition) 160 | 161 | ## Make IGs more testable with Reference Implementations (GC) 162 | 163 | * Create an RI for vitals-write for the virtual connectathon (Nov 15) 164 | * Non-goal: Full SMART on FHIR reference implementation 165 | * P1: (0.8): feature set: 166 | * Complete the SMART standalone patient launch flow 167 | * Client app registration is implicit 168 | * Symmetric and Asymmetric authn both work, but no auth is actually checked 169 | * Works with SMARTv1 clients, using `patient/Observation.*` (or `.write`) 170 | * Works with SMARTv2, using IG-specified `patient/Observation.crs` (or further restricted per https://hackmd.io/@argonaut/SkGWnfQdn#Scopes-for-patient-facing-apps) 171 | * OK if we don't validate PKCE 172 | * Instead of users, login allows for selecting a patient or practitioner 173 | * Restrict read and write based on scopes 174 | * Host at: `vitals-server.ri.argo.run` 175 | * Include directions for local run (GH readme) 176 | * Allow apps to test error conditions like "can only write one blood pressure per ___ time per patient" 177 | * Walkthrough tour 178 | * Client perspective 179 | * Include creating a new patient ("clone" a sample patient) 180 | * P3: (0.5): feature set: 181 | * Include 'practitioner view' into written vitals 182 | * Check auth tokens 183 | * Additions to SMART access 184 | * Works with SMARTv2 clients, using `patient/Observation.u` (or further restricted per https://hackmd.io/@argonaut/SkGWnfQdn#Scopes-for-patient-facing-apps) 185 | * P5: (0.5): feature set: 186 | * Allow/deny the requested scopes 187 | * Explicit client app registration 188 | * Internal Provenance generation 189 | * External Provenance handling 190 | 191 | * P2: (0.0): Subscription RI include client-oriented page to allow testing of other Subscription servers. 192 | 193 | ## FHIR Subscriptions meet use case needs and are implementable (GC) 194 | 195 | ### Add required features to cover TA Notified Pull use case 196 | * P0: (1.0): Design mechanism for sending authorization information with subscription notifications 197 | * P0: (0.6): Add support for sending authorization information with subscription notifications 198 | * P0: (1.0): Backport for FHIR R4/R4B 199 | * P5: (0.5): FHIR R5 200 | * P1: (0.5): FHIR R6 201 | * P0: (0.6): Design mechanism for sending 'pull' (query/request) information with notifications 202 | * P0: (1.0): Backport for FHIR R4/R4B 203 | * P5: (0.5): FHIR R5 204 | * P1: (0.5): FHIR R6 205 | 206 | ## FHIR Specifications Improve Across Releases 207 | 208 | ### Subscriptions Framework 209 | * P0: (1.0): Apply all outstanding TC tickets to backport IG 210 | * P0: (0.5): Add mechanism for tagging notification events by FHIR interaction/event 211 | * e.g., differentiate between a create and update in a topic that allows both 212 | * e.g., different events in a topic with more than one event trigger 213 | * e.g., define a topic with several triggers on the same resource and be able to tell them apart 214 | * P0: (1.0): Define operation to *resend*/*replay* notifications (instead of just accessing them) 215 | * P0: (1.0): Ballot Subscriptions backport IG in January cycle 216 | * P2: (0.0): Ballot (for comment) FHIR R6 changes in January cycle 217 | * P5: (1.0): Determine path for maintaining feature parity in FHIR R5 218 | 219 | ### Prepare FHIR R6 content for comment ballot 220 | * P0: (1.0): Ensure submitted search and http page tickets are voted on. 221 | * P0: (1.0): Apply all search page tickets approved on or before November 27 222 | * P0: (1.0): Apply all http page tickets approved on or before November 27 223 | * P0: (1.0): Ensure new 'delete' functionality is documented 224 | * P0: (0.2): Reach out to at least 4 implementers to review draft content before content freeze (December 4) 225 | 226 | 227 | # FHIR-Candle 228 | * P1(GC) (1.0): Add support for IG-loading 229 | * Published packages 230 | * CI Builds 231 | * P1(GC) (1.0): Complete at least two items from the 'high priority' queue 232 | * P?(GC) (0.5) Extract `fhir-codegen`'s package resolution + `~/.fhir`cache management into a library 233 | * Something similar exists in Firely.Fhir.Packages (https://www.nuget.org/packages/Firely.Fhir.Packages) 234 | * If that's good enough, no need to do this task. 235 | * It does not handle CI builds (due to how simplifier works, they are not motivated to add that support) 236 | * Sort out MS Signing and Publishing requirements 237 | * Package as NuGet library for developer consumption 238 | * Package as dotnet tool for end-users 239 | * P4(GC) (0.1): Add support for at least 50 of the remaining search-modifier-element type combinations (187 remaining) 240 | 241 | ---- 242 | ## Unplanned work done: 243 | * BP FhirPath Spec migration & apply approved backlog! (which I guess could be in the prepare FHIR R6 content bucket) 244 | * BP Enhance uploadfig (dependency processing) 245 | * BP Enhance fhirpath-lab (questionnaires & co-pilot tweaks, java mapping engine, location navigator) 246 | * GC `_lastUpdated` Argo project 247 | * JM Deep dives on EHI, VCL 248 | --------------------------------------------------------------------------------