Add sensor specifications linked to measure data types

[Whathecode]

It is often relevant to know fixed sensor specifications of sensors used to collect data. E.g., a PPG sensor may specify the wavelength of the LEDs, which impacts how deep light penetrates the skin, and thus also impacts the collected data.

The original design of CARP anticipated to include such information in DeviceRegistration:

A DeviceRegistration uniquely identifies a DeviceConfiguration once it is deployed in a study, contains the necessary details for the client on how to connect to the device, and stores device specifications which may be relevant to the researcher when interpreting collection data, such as brand/model name and operating system version.

The question then arises how to best store this data. Considering the PPG example, different sensors (i.e., different DeviceConfigurations) may collect PPG. It would be a duplication of efforts to replicate the sensor specification for each corresponding DeviceRegistration. Are sensor specifications tightly coupled to measure data types?

If so, sensor specifications could become part of the abstract DeviceRegistration implementation. And, the coupling could be implemented by specifying the expected sensor specification in DataTypeMetaData as registered in CarpDataTypes.

However, a thorough analysis is needed whether such a tight coupling in fact exists. For example, originally, we believed there to be a tight coupling between data types and sampling schemes. This turned out to be a mistake, i.e., the same data type which a DeviceConfiguration specifies can be collected on it may have different SamplingSchemes (options to configure SamplingConfiguration). The current decoupling we have offers much needed flexibility. We need to make sure not to fall into the same trap.

[Whathecode]

Example: a PPG specification could hold a list of LightSources:

/**
 * Describes a light source used as part of collecting [PPG] data.
 */
@Serializable
data class LightSource(
    /**
     * Uniquely identifies the light source among multiple available light sources on the sensor, set by the client.
     */
    val name: String,
    /**
     * The wavelength in nanometers of the light source, if known; null otherwise.
     */
    val waveLengthNm: Int?
)

[bardram]

In terms of hardware sensors (incl. the ones on the phone), I think the most important part is to store device information like serial numbers, model names, OS versions, hardware IDs, etc. This will uniquely identify the hardware details of a sensor, like sampling rate, wavelength, etc. which is to be looked up in the manufactures tech docs.

You will not be able to collect such information (like wavelength) directly from the sensor/phone anyway. And hence, this information is not relevant (or available) during data sampling.

So - IMO - the present model of adding sensor details to the device registrations still holds. This will support what I'm doing with the Polar device right now. I can specify that I want a polar HR measure. But in different deployments on phone, different Polar devices can be found and used (both H9, H10, Sense, and a watch). In the device registration I just need to specify which device is used for a particular patient/deployment.

[Whathecode]

In terms of hardware sensors (incl. the ones on the phone), I think the most important part is to store device information like serial numbers, model names, OS versions, hardware IDs, etc. This will uniquely identify the hardware details of a sensor, like sampling rate, wavelength, etc. which is to be looked up in the manufactures tech docs.

Correct. These indirectly provide access to the same information. This would be a good first step to include, and probably takes precedence.

So far, it hasn't been included as separate more formalized fields since I did not make time to determine what these should be or where they should be defined. Are these additional fields on the abstract DeviceRegistration or on extending classes? E.g., for smartphones we want to know the device model and OS. But, is "device model" generic enough to be applied to the base class, and does it add value over the current deviceDisplayName?

But in different deployments on phone, different Polar devices can be found and used (both H9, H10, Sense, and a watch). In the device registration I just need to specify which device is used for a particular patient/deployment.

deviceDisplayName in DeviceRegistration already provides the option to include this information.

/**
 * An optional concise textual representation for display purposes describing the key specifications of the device.
 * E.g., device manufacturer, name, and operating system version.
 */

It is the most "generic" semantically meaningful field I could come up with that makes sense for any DeviceRegistration. It provides no guarantees whatsoever on what is contained in it, though.