Skip to content

Latest commit

 

History

History
143 lines (125 loc) · 8.25 KB

okrs-2024-may.md

File metadata and controls

143 lines (125 loc) · 8.25 KB

FHIRPath is well specified and easy to learn, with many robust implementations

  • 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

  • P3 (0.5; committee now agrees this is needed) BP Foster a path to get another normative ballot of the fhirpath spec

  • Dev days content

    • (1.0) Questionnaires base presentation and examples
      • (1.0) FhirPath Lab extensions to test questionnaires
    • (1.0) Questionnaires pre-pop extract presentation and examples
      • (0.9; in dev branch) FhirPath Lab extensions to support this
    • (1.0) FhirPath basics presentation and examples (and fhirpath lab demos)

fhirpath implementations are continuously tested, with transparent results and feedback loop for improvements

  • Support for various implementations in the lab (?)
    • (0.1) Ensure clarity of user-facing explanation on where data is processed
    • (0.9) Beda Software (Python engine) - review PR,
    • (0.8) Aidbox (FHIRPath and bonus questionnaire renderer)
  • Conformance matrix
    • P1 (0.0) BP augment official test file with better metadata
      • Update the fhirpath test file to include reference to sections of the spec that are being tested
    • P1 (0.0) BP Publish results for each implementation
      • generated by unit tests
    • P1 BP (0.0) Fhirpath engine test cross-reference - to help with next ballot
      • Viewer for results
        • with deep links back to spec
        • with deep links back to unit test results

Open source Tooling to help efficiently work with fhirpath

  • BP FirelySDK fhirpath parser enhancements (complete existing work)
    • P0 (1.0) position info, brackets
    • P2 (1.0) comments - as ignore/skip, or including for round-tripping?
  • P2 BP fhirpath lab AI Chat
    • (0.5) Incorporate recent learning (RAG/multi-step/multi-agent processing)
    • (0.5) Improved Questionnaire support - applying changes
    • (0.1) Decide on rollout path
      • Independent project with bring-your-own keys, or a MS supported tool?
        • Responsible AI and other internal reviews?
      • Decision on feedback mechanism(s) and sharing location(s)
      • Update documentation on use of data/storage/sharing

SMART App Launch 2.2 is published with User Access Brands

Key Results:

  • P1 (1.0) All remaining ballot issues from the HL7 process are resolved by April 1
  • P1 (1.0) Feedback from the upcoming Connectathon is incorporated
  • P2 (0.5 -- recording in DevDays) An educational video explaining Patient Access Branding for app developers is produced by May 1
  • 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
  • P3 (0) A conversation to propose inclusion of Patient Access Branding support in the Inferno testing tool

A proof-of-concept showcase demonstrates techniques for mapping and visualizing my EHI export data using AI tools.

Key Results:

  • P1 (1.0) Analyze my EHI export data from Epic in-depth
  • Openly publish an EHI Toolkit with
    • P1 (1.0) Components to strip specific sensitive identifiers from the data set
    • P1 (1.0) Utilities to extract, clean and structure the EHI data into suitable formats for analysis
  • Openly publish an EHI Showcase
    • P2 (0.7 -- published with my own data) Web-based data viewer capable of displaying EHI
    • P2 (0) Clinical and administrative views at the encounter level
    • P3 (0) Configurable with logical data views and links between related views _ P4 (0.3 -- only one-offs) Including visualizations of key insights from the EHI data
  • P1 (0.8 published demo video on youtube; devdays) Create and publicly publish a video walkthrough of both
  • Use large language models in a semi-automated workflow to:
    • P3 (0.7 -- working but only tested with my data, limited LLM role) infer and characterize links between data across different tables
    • P5 (0) Implement techniques to generate candidate custom views and evaluate/refine them iteratively

VCL allows rich, dynamic queries over FHIR terminology systems

  • P1 (0.8 thanks to Michael) VCL proposal includes support for subqueries
  • P1 (0.8 ditto) Proposal includes support for designation queries
  • P2 (0) Proposal is merged into draft content for R6

Argo 2024: Continuous Glucose Write

  • Project launch with scope that balances needs of consumer-facing apps, clinician platforms, and EHRs
    • P1 (1.0) device data including manufacturer and identifier
    • P1 (1.0) "on demand" data pulls into EHR
    • P1 (1.0) "all at once" data pushes into EHR
    • P1 (1.0) coarse-grained (e.g., "daily") data pushes into EHR
    • P3 (1.0) near-realtime data pushes into EHR

Developers using C# have access to comprehensive definitions and properties (GC)

  • Core spec
    • (P0) - (1.0) Firely export is working with refactored models
    • (P0) - (0.9) Firely export has method for exporting interfaces (e.g., CanonicalResource) with fillers for properties that do not exist
  • IG profiles
    • (P0) - (1.0) Firely export can generate a set of canonical urls for an IG (e.g., extensions)
    • (P0) - (1.0) Firely export can generate a set of getters and setters for extensions
    • (P1) - (0.5) Firely export can generate a set of getters and setters for slices
    • (P5) - (0.0) Export any artifacts/extension methods and document nice path to use Firely validation on instances
  • (P0) - (1.0) Demo at DevDays

Developers in other languages have access to comprehensive definitions and properties (GC)

  • Core spec
    • (P0) - (1.0) Info Language export is working with refactored models
    • (P0) - (1.0) TypeScript export is working with refactored models
    • (P0) - (1.0) OpenAPI export is working with refactored models
  • IG Profiles
    • (P5 BP) - (0.0) Typescript extension getters/setters/extension URLs

Developers using C# have can translate resources between versions (GC)

  • (P1) - (1.0 - GC+BP) Code-gen can parse FML structure maps
  • (P1) - (0.5) Code-gen can use cross-version maps to export:
    • (P1) - (0.5) Determine where FML is insufficient to describe required transformations
      • Write missing code and document.
      • Where do hooks go in Code-Gen vs. Runtime vs. Static configuration
    • (P1) - (0.0) R5 serializer for an R4B SubscriptionTopic resource
    • (P1) - (0.0) R5 parser for an R4B SubscriptionTopic resource
    • (P1) - (0.0) R5 serializer for an R4 SubscriptionTopic (Basic)
    • (P1) - (0.0) R5 parser for an R4 SubscriptionTopic (Basic)
    • (P2) - (0.0) R4 serializer for an R5 SubscriptionTopic
    • (P2) - (0.0) R4 parser for an R5 SubscriptionTopic
    • (P2) - (0.0) R4 serializer for an R4B SubscriptionTopic resource
    • (P2) - (0.0) R4 parser for an R4B SubscriptionTopic resource
  • ? Explore automated test case generation for round-tripping
  • (P3) - (0.0) Code-gen can use structure maps to export 'x' additional resources

Additional Key Results:

  • (P1) - (0.5 - BP+GC) Get fixes for cross-version structure maps incorporated upstream.
  • (P♾️) Match cross-version code in JS/Liquid/TS

Users have simple and consistent access to FHIR packages (GC)

  • (P2) - (0.4; pending CI-based resolution PR) Integrate changes from local package resolution into Firely.Fhir.Packages
  • (P3) - (0.0) Ensure changes flow into Firely Terminal
  • (P4) - (0.4) Move updated documentation into Confluence

FHIR Subscriptions: Patients have timely notifications about events in their healthcare

IG authors and implementers have access to the latest and best versions of Subscriptions (GC)

  • (P1) - (1.0) Completion of 'additional granularity' design work
  • (P1) - (0.8) Finish reconciliation of 1.2.0 ballot
    • (P1) - (1.0) Propose resolutions for the 27 remaining ballot JIRA tickets
    • (P1) - (1.0) Submit block vote for ballot tickets
    • (P1) - (0.5) Apply resolutions for ballot tickets
  • (P1) - (0.0) Publication of FHIR Subscriptions IG 1.2
    • Check proposed HTI-2 rule to ensure necessary functionality is published