The .github from stanfordspezi

Problem

Several applications require interactions with Bluetooth devices that provide data interpretable by Spezi-based applications.

Solution

The core requirement would be handling:

Automatic pairing
Multiple services
Multiple characteristics
Configurable parsing and state management
Easy reuse of the component in other Spezi modules

Additional context

The current code of existing Spezi applications can serve as a good basis to get started.

Code of Conduct

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

Use Case

Different applications require the downloading or larger amounts of data from web services that should be cached on the device. Caching reduces the amount of data loaded from web services, reduces the latency on subsequent loads, and improves the user experience.

Problem

The Spezi ecosystem should provide a simple caching module that allows developers to easily cache and retrieve data in accordance with the caching mechanisms established in the operating system.

Solution

The Caching component should ...

Provide mechanisms to easily retrieve values using a unique path, e.g., the URL where the content was downloaded from.
The cache should have the possibility to invalidate elements manually or after a specified time that can be configured on the component-basis.
Subsequent requests for a non-cached element that are requested while a network request is processed should be enqueued and all subsequently fulfilled once the download is complete or fail when the download cannot be completed.
The cache should be located in the caches directory of the application to allow the operating system to quickly clean the cache if it runs out of memory.

Additional context

The API should take advantage of existing programming language features such as async/await and structured concurrency to enable callers to wait for the result and transparently load elements with additional context beyond, e.g., a URL Session request.

Code of Conduct

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

Add Swift-based CodeQL Support

Problem

CodeQL is now supporting Swift: CodeQL code scanning now supports Swift (beta).

Solution

We should create reusable GitHub Actions that can be used in the Spezi ecosystem to automatically scan and analyze the code using CodeQL. We can follow the instructions Configuring the CodeQL workflow for compiled languages and other GitHub documentation.

Code of Conduct

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

watchOS Support & AppleWatch User Interface Adjustments

Problem

The Spezi modules should support watchOS to enable developers to build a watchOS-based application.

The current UI elements in the Spezi modules only support iOS. As we want to support the Apple Watch, we must ensure that the UI controls are adapted to the smaller screen size and can be navigated on the Apple Watch.

Solution

Update all UI components to use native SwiftUI components on watchOS. We also need to add watchOS 10 as a supported platform in the Swift package file and may update the Swift tools version to 5.9.

The watchOS UI components should support the watchOS 10 UI design paradigms.
You can learn more about watchOS 10 in the following WWDC 2023 videos:

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

Related Issues

Additional context

Feel free to use comments under the associated issues to discuss the best way to approach the adoption of watchOS for the Spezi modules.

Code of Conduct

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

Audio Player Module

Problem

Some applications require mechanisms to play audio, e.g., instructions or audio content.

Solution

Some of the content requires playback control, while some other elements just require the functionality to play audio.

The audio player module should provide a mechanism to play audio using a simple-to-use API.

In addition to the API, a separate target can offer a visual, audio player that can be embedded in an application.

Code of Conduct

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

Use String Catalogues

Problem

The current String.localized files are challenging to keep up to date and do not scale well if we add support for multiple languages.

Solution

Apple introduced and embedded String Catalogs in Xcode 15 and with Swift 5.9. The following WWDC session and documentation provides a good overview:

The seem to be supported for Swift Packages: https://developer.apple.com/forums/thread/731941

Related Issues

Code of Conduct

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

Access Guard Module

Use Case

Different applications require a separate authentication step when opening the application, e.g., ask for a pin entry, biometric authentication, or a combination of both.

Problem

Spezi currently offers no module that handles these types of use cases and would need a mechanism that makes it easy to safeguard the complete application or a specific part of the application using different authentication mechanisms.

Solution

Provide different access mechanisms ranging from ...
- ... a passcode only when the device has no passcode
- ... a passcode-based authentication
- ... biometrics-based authentication

There should be different options for how the passcode is defined, e.g., consisting of 4/6 digits or an alphanumeric code.

The authentication should be applied to any view or the complete window group.

Additional context

Feel free to use this issue to debate the best design for the API as well as the user interface and your plans to implement the module. We are happy to provide help and support for developing the module.

Code of Conduct

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

Connected Devices Module

Use Case

Digital health applications require access to a wide variety of connected devices that can sometimes be connected and paired to a mobile application or can provide their data using a web service-based API. Systems might want to access that data in the user context or by retrieving the data on a web service with the scope of the system to aggregate it independently of a mobile application.

Problem

The Spezi ecosystem currently mainly focuses on access to connected devices using HealthKit. While some connected devices store data within HealthKit, prominent devices do not. These devices include but are not limited to:

Solution

The Connected Devices Module should be a cross-platform Swift Package that supports iOS, macOS, and Linux to ensure usability across client applications and server-side web services.

Given the cross-platform nature, the SDK should ideally use AsyncHTTPClient as the basis for the work and allow the configuration of the NIO event loop and other injections to ensure a smooth integration into the server-side Swift ecosystem.

The module should contain different sub-targets for the different device types and should ideally provide additional modules that can map each of the gathered observations to HL7 FHIR representations using the Apple FHIR Models SDK.

Alternatives considered

Before implementing all the API connections ourselves, we should do a thorough investigation of existing Swift-based packages that might already integrate with the connected device SDKs or might be able to be reused as dependencies.

Additional context

Please use this issue as a discussion point for more concrete ideas about the structure of the Swift package, its focus and aim, and some first ideas around its API design.

Code of Conduct

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

Update Documentation in Conformance to the Documentation Guide

Problem

The current documentations in Spezi modules provides an 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 documentations 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 Spezi setup and architecture.
Improve the READMe as noted in the README section.

Related Issues

Additional context

Feel free to use comments under the associated issues to discuss the best way to approach update documentation in conformance to the documentation guide for the Spezi modules.

Code of Conduct

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

Privacy Module

Use Case

Different digital health applications need to mask and automatically redact any personal information for processing, forwarding, or displaying sensitive information.

Problem

Current approaches to automatically de-identify or anonymize data often happen on web services and central infrastructure, leading to a potential risk of data being leaked or accidentally forwarded.

These use cases can include:

Mobile health data retrieved from HealthKit
Text input from users
Health records received using FHIR APIs
Documents or other data inputted into third-party APIs, including large language models.

Solution

The Spezi Privacy module should provide a set of tools that allow developers to easily de-identify personal health information retrieved in different settings.

The module should provide simple interfaces to automatically de-identify, mask, and re-identify data using local processes on the phone. Natural language processing techniques, including the NaturalLanguage framework by Apple can be used to identify key components of the provided input and provide a transparent mapping for external vendors and APIs that can be reversed or applied to responses if needed.

Additional context

Please use this issue as a discussion point for more concrete ideas about the structure of the Swift package, its focus and aim, and some first ideas around API design.

Code of Conduct

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

Active Tasks Module

Problem

Active tasks like the "The 6-min-walk test (6MWT) is a validated proxy for frailty and a predictor of clinical outcomes, yet is not widely used due to implementation challenge" [Reliability and repeatability of a smartphone-based 6-min walk test as a patient-centred outcome measure]. The validated measure is needed in different Spezi-based applications and should be implemented as a reusable module.

Solution

We propose the creation of a reusable module, encapsulating the functionality of active taks, starting with the 6-min-walk test in a reusable package. The module should offer an option to incorporate the module in an application using an API or a UI component that uses the API under the surface.

Code of Conduct

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

Medication Module

Problem

Several applications need to keep track of medications including dosage and a patient-specific schedule.

Solution

The core requirements of the UI should be an API and UI that allows:

Medication selection from a predefined list of medications that could be loaded from a web service or configuration
Modification of dosages within constraints defined by the medications
Scheduling of medications including a repeating pattern and times of day

Additional context

No response

Code of Conduct

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

visionOS Support

Problem

With a few projects using visionOS and testing on the Apple Vision Pro, we want to move all Spezi modules in the Stanford Spezi organization to adopt the native UI components of visionOS.

Solution

Update all UI components to use native SwiftUI components on visionOS. We also need visionOS as a supported platform for the Swift package file, and we may update the Swift tools version to 5.9.

You can learn more about visionOS and SwiftUI for visionOS at https://developer.apple.com/visionos/learn/.

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

Feel free to use comments under the individual issues to discuss the best way to approach the adoption of visionOS for the Spezi modules.

Related Issues

Additional context

It is required to install the latest Xcode 15 beta to address this issue.

Unfortunately, UI tests are currently not supported for visionOS.
The StanfordBDHG/SwiftPackageTemplate demonstrates the CI setup for visionOS that should also be adopted for this Spezi module.

This change will be considered a breaking change.

Code of Conduct

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

Support Module

Use Case

Several applications require a support page to display helpful information to users. This information can range from simple list-based textual frequently asked questions (FAQ) information, more sophisticated searchable text entries including tags, and visual information such as images and videos to a chatbot-like interface powered by large language models (LLMs).

Problem

The current user interfaces for these solutions are custom build and can benefit from reusable components that make the following functionalities possible:

Simple list-based textual frequently asked questions (FAQ) information
Sophisticated searchable text entries, including tags
Embedded visual information such as images and videos
Chat-bot like interface powered by a large language models (LLMs)

Solution

The Spezi Support module should provide easy-to-use and reusable targets that offer user interface components that allow app developers to build these types of interfaces and include sophisticated interactions, including searching by tags and a chat-based interface that allows users to ask questions to an LLM-based chatbot interface.

Additional context

Please use this issue as a discussion point for more concrete ideas about the structure of the Swift package, its focus and aim, and some first ideas around API design and user interface mockups.

Code of Conduct

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

Invitation Code Module

Problem

Some applications require the usage of an innovation code to participate in an application. The invitation code must be verified and correlated with some additional information about the user, including identifiable information like the date of birth or name.

Solution

A module providing an invitation code module should provide the following functionality:

Provide a way to define the invitation code, e.g., using a regex expression that can be verified
Provide a UI to display the invitation code and additional configurable identifiable information
Provide a mocking mechanism to test the behavior locally or for UI tests in an application using Spezi

Additional context

Feel free to use this issue to debate the best design for the API as well as the user interface and your plans to implement the module. We are happy to provide help and support for developing the module.

Code of Conduct

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

stanfordspezi / .github Goto Github PK

.github's People

Contributors

Stargazers

Watchers

Forkers

.github's Issues

Problem

Solution

Additional context

Code of Conduct

Use Case

Problem

Solution

Additional context

Code of Conduct

Problem

Solution

Code of Conduct

Problem

Solution

Related Issues

Additional context

Code of Conduct

Problem

Solution

Code of Conduct

Problem

Solution

Related Issues

Code of Conduct

Use Case

Problem

Solution

Additional context

Code of Conduct

Use Case

Problem

Solution

Alternatives considered

Additional context

Code of Conduct

Problem

Solution

Related Issues

Additional context

Code of Conduct

Use Case

Problem

Solution

Additional context

Code of Conduct

Problem

Solution

Code of Conduct

Problem

Solution

Additional context

Code of Conduct

Problem

Solution

Related Issues

Additional context

Code of Conduct

Use Case

Problem

Solution

Additional context

Code of Conduct

Problem

Solution

Additional context

Code of Conduct

Recommend Projects

Recommend Topics

Recommend Org

Jobs