Context: Archer was designed on the assumption that a human user is always running the system and can apply clinical and operational judgment when answering leading questions (e.g., "Was any medication taken? Yes / No"), which in turn determines whether subsequent questions should be asked. However, sponsors have indicated that Archer should enforce additional guardrails, preventing data transfer to certain questions when prerequisite conditions are not met, rather than relying solely on user judgment.

How will this be handled?

Mapping App: It will be possible to define dependencies between questions. The mapping analyst can specify which preceding question controls whether a given question or question group is enabled. They will also be able to define the expected value of that preceding question that must be met to enable the dependent questions.

Clinician App: When question enablement has been configured for a form, any question that depends on a previous question will display a label: "enabled if: [condition]". This label will appear at either the individual question level or the question group level, depending on how it was defined in the Mapping app.

If users select a predefined enablement option (e.g., "Were vital signs performed = yes"), they can see the data available for the questions enabled by that. If they select other options (e.g., "Were vital signs performed = no"), the data for the dependent questions is not displayed.

IgniteData Operations team needs to be able to check access of a user to a certain EDC study before going live and also to check if it is possible to integrate with the study.

In order to do so, there's usually a Postman request done "manually" by the team. With this ticket, we will enable the system to process this request before go-live.

Issue description: For Rave repeating question groups (tables) with default rows defined by DefaultValue, Archer was formerly using a Rave ItemGroupRepeatKey=@Context based approach to update or insert data into the table. If any row was missing on data export, it would cause the row order on the EDC to be switched up, often leading to situations where row entries seemed misplaced or duplicated.

Fix: The technical integration with tables using DefaultValue was modified, and Archer is no longer using @Context-based data export; instead, it relies on an index-based ItemGroupRepeatKey usage with a numeric value, resolving the above-described issue.

Before:

<!-- BEFORE -->
<FormData FormOID="VS1_1">
  <ItemGroupData ItemGroupOID="VS1_1_LOG_LINE"
    ItemGroupRepeatKey="@Context"
    TransactionType="Upsert">
    <ItemData ItemOID="VS1_1.VSTEST_2" TransactionType="Update" Value="C25299"/>
    <ItemData ItemOID="VS1_1.VSORRES" TransactionType="Update" Value="76"/>
  </ItemGroupData>
</FormData>

After:

<!-- NOW -->
<FormData FormOID="VS1_1">
  <ItemGroupData ItemGroupOID="VS1_1_LOG_LINE"
    ItemGroupRepeatKey="1"
    TransactionType="Upsert">
    <ItemData ItemOID="VS1_1.VSORRES" TransactionType="Update" Value="76"/>
  </ItemGroupData>
</FormData>

Implement the necessary endpoints to be able to integrate with Advarra API:

• Subject and Subject visit endpoints
• Clinical data export endpoints

FHIR resources can reference other FHIR resources. Until now, Archer was unable to retrieve data from a referenced resource, but this will now be possible. This enhancement will be useful in several scenarios, such as obtaining more accurate medication information.

Currently, Archer can transfer data through the MedicationRequest FHIR resource. Accessing the referenced Medication resource will allow retrieval of additional details such as the medication's form and all associated codes (e.g., RxNorm, ATC).

{
  "resourceType": "Medication",
  "id": "64f4bff3-0100-40a9-a26c-3daa3fdd1d9e",
  "code": {
    "coding": [
      {
        "system": "http://www.nlm.nih.gov/research/umls/rxnorm",
        "code": "596",
        "display": "alprazolam"
      }
    ]
  }
}

Enabling Archer to technically source data from the Medication FHIR resource, which is primarily used for the identification and definition of a medication, including ingredients, for the purposes of prescribing, dispensing, and administering a medication as well as for making statements about medication use.

Enabling Archer to technically source data from the DiagnosticReport FHIR resource, used for findings and interpretation of diagnostic tests performed on patients, groups of patients, products, substances, devices, and locations, and/or specimens derived from these.

Before: The dropdown of available study subjects, which is immediately opened when selecting a sponsor and site, was still displayed even after the user searched for a specific subject, which generated confusion.

New behavior: The dropdown will be filtered to only display the options that match the user search.

Note: Specific to Advarra.

Archer displays the Subject OID to clinician users as the EDC Subject Reference. This approach is not suitable for Advarra, as its OIDs are UUID-like and not human-readable identifiers at the study-site level. To address this, EDC subject names will replace the EDC Subject Reference across all systems. Archer users will see this change when linking a patient to a study subject.

Before: The EDC Subject column showed a UUID-style OID (e.g., 4EE350144EDFD7A2E0630100007FB372).

New behavior: The column now shows the human-readable subject name (e.g., AF7APR2699).

In the study selection "Select existing study" screen, the EDC site reference was previously displayed. It will now be replaced by the EDC site name.

Before: The EDC site reference (e.g., a long numeric or UUID string) was shown in the EDC Site column.

New behavior: The human-readable EDC site name (e.g., "Great Hospital") is displayed instead, reducing confusion for clinical staff.

Note: Specific to Advarra.

The form reference was removed from the Clinical Data Review page, as it did not add value to the user. The page header now shows only the visit path and form name without the EDC form reference code.

Before: Sometimes the order of visits (Screening, Visit 1, Visit 2, …) in Archer's Form Review Screen was not the same as in the EDC, which could generate confusion to users.

New behavior: The visits in Archer will always have the same order as in the EDC.