Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 10 Current »

This document describes the requirements for the MyCogMobile (MCM) study. This study is expected to launch in mid-July.

Requirements:

  1. MCM is iOS only

  2. ETL/parquet/scoring not required

  3. A desired study schedule for QA study(ies) will be provided by NU. Sage will construct QA studies

  4. NU will construct studies that will be used for live participants

  5. This measure will NOT be upgradeable to use a self-referencing schema

  6. We will need a completion time estimate of ~25 minutes for the entire measure (one long battery) on the live study

  7. The assessment identifier should be “MyCogMobileV1”

 Acceptance criteria:

  1. One .json file will be produced for the one MCM assessment. The .json file will contain the aggregated MyCogMobileTaskResult

  2. ….

Schema implementation description from Northwestern:

MyCogMobile task result data is expected to validate against the shared schema.

MyCogMobile does not include a “self referencing” schema, but should be validated using the mechanism outlined at https://sagebionetworks.jira.com/wiki/spaces/BD/pages/2883715106/Self-Referencing+Data#Support-for-self-referencing-data .

 

The approach that Northwestern took:

create a MyCogMobileSubTaskStep which conforms to RSDSubtaskStep and could represent a “submeasure” such as the MyCogMobile specific Memory For Sequences.  That enabled us to include entries in our MyCogMobile step description JSON which delegated to other step description JSON files like this:

    {
      "identifier": "MyCogMobileMFS",
      "type": "subTaskStep"
    },

When the measure encounters something like this, then it essentially loads the MyCogMobileMFS measure. However, at the end of MyCogMobile all of the data across the “submeasures” is aggregated into a single MyCogMobileTaskResult which will validate against the shared schema.

 

Risks: new features has been implemented with this build on the iOS Sage side:

DECISION- Only include MCM data with 1.6.0 build and DO NOT include any additional features.

Question

Answer

Next steps

When will Shannon get a release candidate of the framework with this measure?

 MobileToolbox 1.6.0 for iOS has been released as

a swift source package: https://github.com/MobileToolbox/MobileToolbox/releases/tag/1.6.0

 TestFlight - Mobile Toolbox App v1.6.0, Build 119

TestFlight version was rolled back to v1.5.0 Build 116 so no additional features will be included.

What are the icons, colors, labels, etc. needed to add this as a shared assessment?

 

 

Why are they aggregating the result file rather than adding multiple files (one for each sub-assessment) with a schema for validating that assessment?

Is NU aware that their study launch date of Mid-July is put at risk by QA of their assessment (and framework) because of work we had put off doing to limit the QA for the ICAR measures?

With the focus on a speedy ICAR release, we held features back from the standard release cadence. This MCM study would run with the same known production state that we already have in our live studies – ie without the planned improvements unless we coordinate the release cadence timeline and build. Additionally, it means that current live studies would also not have the planned improvements

Weigh the pros and cons to build the release timeline

Discussion results in returning to normal cadence to have the correct build information for both NU and Sage features and bug fixes. Release notes will be drafted during this window to begin on June 28, 2023

There are already two identifiers in the v1.5.0, build 117 app.

MyCogMobileV1

MyCogMobileShortV1

Why are they changing the identifier?

The assessment identifier should be “MyCogMobileV1”

What changes to the frameworks (other than the task identifier) are planned between now (June 13) and study launch in mid-July?

Today’s 1.6.0 release incorporates all of the known feedback from the scientific owners. There’s nothing else planned and of course we don’t yet know about anything unplanned

Why aren’t they using the shared app code (v1.5.0) to release a version of the app where they can control the release cycle?

See first question answered with next steps. We will use v1.5.0.116 for MCM release

What is the total number of estimated participants and duration of the study

End goal is identification of correct battery as one long study or multiple assessments is more productive.

  • No labels