stanfordspezi / spezifhir Goto Github PK

Problem

The current documentation in the module provides a good overview of the API and includes documentation for most public APIs. In line with the newly published Stanford Spezi Documentation Guide, we should update the documentation in accordance with the guidelines.

Solution

The documentation should be updated to provide more insightful inline documentation, improve the README file and the DocC landing page in conformance with the Stanford Spezi Documentation Guide.

• Update inline documentation, including links and other elements noted in the Code Documentation section.
• Improve the DocC landing page as detailed in the Landing Page section.
• Add a graphic and visual representation of the module user interface (UI) or UML diagram of the architecture or interacting with the module API.
• Improve the READMe as noted in the README section.

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct and Contributing Guidelines

Problem

With Swift 6 approaching in a few months and nightly builds already being available we should ensure that all our packages are working well with all Swift concurrency checks.

Solution

Enable strict concurrency checking in the Swift Package in a PR and ensure that we don't have any warnings remaining in the packages as we develop new features or fix bugs from now.

The UI Testing App target should also enable Enable strict concurrency checking.

The corresponding PR should fix all related warnings when enabling strict concurrency checking.

Additional context

We should consider adding SWIFT_TREAT_WARNINGS_AS_ERRORS = YES to our general workflows to ensure all warnings are flagged as errors during our CI setup.

Code of Conduct

• I agree to follow this project's Code of Conduct and Contributing Guidelines

Problem

Xcode Previews or unit tests often require the injection of mock data into the FHIR standard.

Solution

It would be good to add an option initializer that is only available in the debug configuration or an instance method to easily inject mock objects in the FHIR resource standard.

Additional context

Mock data should be provided as FHIR data. We would expand the FHIR target to add another target to easily and quickly generate realistic mock data.

Code of Conduct

• I agree to follow this project's Code of Conduct and Contributing Guidelines

Problem

Currently, the SpeziFHIR package still depends on the legacy SpeziML 0.3.0 release. Since then, SpeziML was renamed to SpeziLLM and its version was bumped to 0.5.0. Due to the changed interface, SpeziFHIR is currently incompatible with the latest release of SpeziLLM.

Solution

There is some work required within SpeziLLM to bring back the previous functionality that SpeziFHIR uses. Once, this is done, SpeziFHIR can be upgraded to the latest releases of the Spezi framework ecosystem.

Additional context

This is currently a blocker to use SpeziFHIR with other Spezi releases which recently upgraded to the latest 1.0 releases.
As SpeziFHIR depends on a previous release of Spezi (SpeziLLM as well) it is incompatible to use with the latest version of packages.

Code of Conduct

• I agree to follow this project's Code of Conduct and Contributing Guidelines

Problem

The Spezi module should support watchOS to enable developers to build an Apple Watch-based application and visionOS to support developers who want to develop applications running on Apple Vision Pro.

The current Spezi module only supports and automatically tests iOS builds.

Solution

Add support for the latest watchOS and visionOS versions. We must add them as supported platforms in the Swift package file and update the Swift tools version to 5.9 if required.

Additional context

All changes should be as cross-platform as possible. Increasing the iOS minimum platform target is acceptable.

The StanfordBDHG/SwiftPackageTemplate demonstrates the CI setup for visionOS and watchOS that should also be adopted for this Spezi module.

Code of Conduct

• I agree to follow this project's Code of Conduct and Contributing Guidelines

Description

When collecting samples like this:

private var healthKit: HealthKit {
        HealthKit {
            CollectSamples(
                [
                    HKClinicalType(.allergyRecord),
                    HKClinicalType(.clinicalNoteRecord),
                    HKClinicalType(.conditionRecord),
                    HKClinicalType(.coverageRecord),
                    HKClinicalType(.immunizationRecord),
                    HKClinicalType(.labResultRecord),
                    HKClinicalType(.medicationRecord),
                    HKClinicalType(.procedureRecord),
                    HKClinicalType(.vitalSignRecord)
                ],
                predicate: HKQuery.predicateForSamples(
                    withStart: Date.distantPast,
                    end: nil,
                    options: .strictEndDate
                ),
                deliverySetting: .anchorQuery(saveAnchor: false)
                //deliverySetting: .manual(safeAnchor: false)
            )
        }
    }

I often get crashes ending with:

SwiftUI/FetchCommon.swift:51: Fatal error: Can only invoke this method on the main queue

The traceback is like:

Reproduction

See above

Expected behavior

Samples should be collected and added to the FHIRStore without crashing

Additional context

I am doing something similar to t:

Code of Conduct

• I agree to follow this project's Code of Conduct and Contributing Guidelines

Problem

As of now, the LLM is only able to access health data resources via function calling that are available upon initialization of the LLM, as can be seen here:

Solution

An example solution would be to use the Observable conformance of FHIRStore and utilize this to get informed about updates, re-assign the parameter property wrapper with new values, and then re-register for observation changes.

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct and Contributing Guidelines