Objective: Argo 2024 CGM IG is ready for implementation and positioned within OO for further development
-
P0: Successfully conduct the November Connectathon with:
- At least 2 organizations implementing the client interface
- At least 2 organizations implementing the server interface
- At least 1 organization representing researchers participating
- P2: (Stretch goal) At least 1 organization testing Smart Health Link capabilities
-
P0: Incorporate Connectathon feedback into the draft Implementation Guide (IG) within 2 weeks of the event
-
P0: Transition the project to HL7 Orders and Observations (OO) workgroup:
- Host at least 2 calls under the OO workgroup by year-end
- Work with OO to formally vote on importing the draft content, clearing the path for incremental future work
-
P1: Create a long-lived reference snapshot of the specification that implementers can reference indefinitely
-
P2: Prepare the draft IG for future HL7 ballot process:
- Ensure all sections are complete and reviewed
- Address any known issues or ambiguities
- OO workgroup agrees on a timeline for the ballot process
Objective: Patients can easily access their imaging data in an app of their choice, alongside their clinical data
-
P0: Conduct a follow-up call with EHR developer to discuss:
- Approach for separate authorization servers with shared patient accounts
- Potential solutions for streamlined app registration across systems
- Document key insights and action items from the call
-
P2: Identify at least one potential testing site willing to explore implementation of a pragmatic approach to patient imaging access
-
P3: Secure commitment from at least one imaging vendor to participate in the testing process.
-
P0: Conclude the consensus process for US Core subscription data feed:
- Achieve agreement on core subscription parameters and payloads
- Document any remaining areas of contention
-
P1: Formally propose incorporation of subscription content into US Core:
- Present proposal to US Core working group
- Drive decision on inclusion in the next US Core release
-
P1: Evaluate R6 subscription enhancements based on US Core work:
- Assess need for hierarchical topics
- Determine if additional flexibility is required for topic implementations that restrict the set of filters defined in a canonical topic
-
P2: Create and publish a tutorial video providing an overview of core concepts behind the US Core subscription data feed
- P1: Organize and conduct an "AI for Spec Editors" roundtable:
- Send invitations to all HL7 work group chairs and known spec editors
- Secure at least 5 experienced spec editors to share their AI usage tips and tricks
- Ensure representation from at least 3 different HL7 work groups
- Achieve attendance of at least 15 participants
- Record the session and share the recording with all HL7 work group chairs within one week
- P0: A single slide process flow explaining how we get from Ra/Rb definitions --> a-vs-b diff --> [manual review] --> xver extensions
- P0: Complete a pass of Cross-Version IG content for review (note this is not balloted, but needs review)
[name=Josh Mandel]"RC1?" [name=Gino Canessa] 👍
- Canonical resource content:
- Difference-based Value Set definitions
- Extension definitions
- Narrative content
- Site / page content
- All the element-wise diffs for all elements with changes
- Package structure and contents
- Canonical resource content:
- P?: Basic tooling to enable faster review and simpler Cross-Version IG content
- View + edit of concept-domain changes (exist in ConceptMaps)
[name=Josh Mandel] e.g., semantics defining what content belongs in an element. The "concept of what the element means."
- View of value-domain changes (exist in StructureMaps / FML)
[name=Josh Mandel] e.g. changing type, cardinality, binding... the stuff that appears in an ElementDefinition. The "validatable constraints that apply to an element"
- View + edit of renamed code/elements (exist in ConceptMaps and StructureMaps / FML)
- P?: Publish
- P4: (BP) Basic tooling to update cross-version maps to inject/validate the new extensions
- All the existing cross version maps are updated and published
- P0: Document three alternative approaches for how FHIR is published
- Explain the desirable properties (which are the subject of tradeoffs)
- Definitions of the three approaches
- Published core (6.0.0) plus modules + Singular modules package (e.g., published once per quarter - Experimental module package)
- Published core (6.0.0) plus modules + Independent module packages (e.g., published by WGs)
- Published minor releases with unchanged stable and breaking 'newer' content
- Document the differences in the approaches (pros/cons) for the following tasks / stakeholders:
- Core spec authoring (WG process and effort)
- Core spec balloting and publication (WG process, HL7 staff process and effort, reviewer effort)
- IG authoring and maintenance (accelerator and WG process and effort)
- IG balloting and publication
- Regulatory authorities (cycle time, version pinning concerns, core vs IG)
- Tooling / SDK implementers
- EHR/facade and native server implementers
- Provider organizations (production servers)
- Client implementers (app developers, integration projects)
- Answers the following questions for each approach:
- What does the standard process (e.g., 'normal' content development, consensus review, and publication) look like?
- What do patches and unballoted updates look like for each category - e.g., would we need 6.0.1 and 6.1.1?
- What does future-proofing look like in each solution - e.g., resources that do not exist yet?
- Reflect on a comparison with R4B - was it successful? was the effort worth it?
- Same question regarding R5
- P1: Make another presentation deck to summarize (due for FHIR Camp)
- P1: Schedule and record a roundtable discussion
- P5: Record overview video
- Prototyping activities:
- P3: (BP) FML Validator onto nuget
- P2: (BP) FML g4 approved into FHIR R6
- P2: (BP) façade project updated with custom resource/module support
- 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.
- P0: (BP) Enhance Definition-based extract to support extraction of multiple resources, removing the following current limitations:
- Need to create hidden "shadow" properties in questionnaire
- No access to QR.subject, author, or encounter (header props) - resulting in duplicating in hidden props
- Linking the multiple resources together is impractical
- P0: (BP) The Definition based extract documentation is clearer and some known gaps working with multiple resources and updating existing resources are reduced/removed
- P0: (BP) Document capabilities and limitations of Template-based $extact
- (Current proposal)
- Create examples of template-based extractions
- Bring analysis back to SDC committee (FHIR Infrastructure)
- P1: (BP) Produce at least 2 education artifacts supporting the use of $extract from the SDC IG (e.g. blog posts, YouTube clips)
- P2: (BP) Implementers are able to efficiently test multiple $extract implementations using the fhirpath lab
- P2: (BP) Collaborate with others to produce a library of Questionnaire/QuestionnaireResponse $extract examples
- Published on github
- At least 2 contributors
- At least 5 examples
- P2: (BP) fhirpath lab supports:
- Questionnaire definitions include context of
- Which patient (subject)
- Who is completing the form (user)
- This context can drive pre-population of (e.g.) demographics, conditions
- The same context can drive extraction into derived resources
- Questionnaire definitions include context of
Location information is widely available inside and outside FHIR in multiple representations. This diversity of information is currently un-managed and only done in an ad-hoc manner. https://confluence.hl7.org/display/PA/Location+Service
- P1: (BP) Document the way this information is currently represented (in summary form)
- FHIR - Locations (points, areas, named spaces), Terminologies (named spaces + relationships)
- GIS - points, named shapes
- Excel Spreadsheets or other simple lists/relationships (roughly terminologies)
- P1: (BP) Document how implementers are currently utilizing this information (in summary form)
- Several simple use cases that the project seeks to support
- P1: (BP) Recruit additional participants to work on a potential implementation guide (beyond myself and Nathan)
- P2: (BP) Complete preparation of a HL7 Project Scope statement describing the scale of the work to be undertaken