...
Due to limitations of race / ethnicity functionality within the seca analytics 125 platform, it was necessary to establish a hardcoded race mapping between the ClinSpark ‘Race Name’ and the seca provided ‘Ethnicity’ value. The mapping table is rules are presented below as a table.
ClinSpark Race | ClinSpark Ethnicity | Race Value Sent to seca |
ANY | Hispanic or Latino | Hispanic |
Hispanic | Not Hispanic or Latino | Hispanic |
Native Hawaiian or Other Pacific Islander | Not Hispanic or Latino | Other |
American Indian or Alaska Native | Not Hispanic or Latino | Other |
Asian | Not Hispanic or Latino | Asian |
North-East Asian | Not Hispanic or Latino | Asian |
South East Asian | Not Hispanic or Latino | Asian |
Black or African American | Not Hispanic or Latino | AfroAmerican |
White | Not Hispanic or Latino | Caucasian |
Other | Not Hispanic or Latino | Other |
Unknown | Not Hispanic or Latino | Other |
Device Invocation
Device enrollment & initialization is initiated via ClinSpark form by clicking on the seca analytics 125 button on an integration-enabled form. Once the button is clicked, the user is prompted to confirm their intent to begin enrollment / collection.
...
Device Selection
In the event that there is only a single seca device configured for the current ClinSpark site, the device will be readied for collection and values will be returned to the TENANT_ID, DEVICE_ID, and REQUEST_ID form items. In the event that the seca tenant has more than one device associated, SparkPlug will prompt the user to select the device on which the collection should be performed.
Errors During Enrollment / Initialization
For errors encountered during device enrollment / initialization, see https://foundryhealth.atlassian.net/wiki/spaces/DEV/pages/edit-v2/4646437132#Errors-%2F-Troubleshooting.
Form Design
...
Collection on Device
Once the device has been successfully enrolled / initialized, the device will be readied for collection, and the study participant will be welcomed on the device screen.
After the Study Participant stands on the device and collection begins, manually entry of waist circumference (and optionally height when the stadiometer is not connected) becomes possible.
After device collection and manual entry are completed on the device, the collection is complete and results will be returned to ClinSpark (see https://foundryhealth.atlassian.net/wiki/spaces/DEV/pages/edit-v2/4646437132#Data for details)
Form Design
As detailed in the description of collection workflows, the seca analytics 125 uses a single collection form to facilitate data collection. The form incorporates both clinical and ancillary device parameters that receive result data and enable further workflows.
...
| Note |
|---|
RAW_JSON_DATA is included to support seca’s Reporting Widgets and are not intended for inclusion on ClinSpark forms. |
Data
Volunteer Monitoring Data
Study Form Data
Reports / Dashboards
. |
Data
Volunteer Monitoring Data
Data collected on the device is return to ClinSpark as Volunteer Monitoring Data via SparkPlug. In addition to the parameterized results, raw JSON data is returned to enable seca Widget based reporting.
...
Study Form Data
After data is received from the seca analytics 125 platform as Volunteer Monitoring Data, an asynchronous job polling the database for new seca result data populates the data to the seca analytics 125 collection form’s Items as Study Form Data.
Reports / Dashboards
Transfer Data Report
Site Report
Bioimpedance Analysis Visualizations Dashboard (seca Widgets)
Errors / Troubleshooting
Demographics Errors
...
'Device Not Ready' Errors
...
seca Tenant Configuration Errors
Notes
Known Limitations
It is currently possible in ClinSpark to start a seca measurement on a form that already has a status of “Complete”, meaning measurement data has been populated via the async job. If a second measurement would be invoked from a “Complete” form, it's possible that the enrollment data (TENANT_ID, DEVICE_ID, & REQUEST_ID) would be inaccurate for the measurement data saved to the form. TENANT_ID would be the same because the data would be collected for the same site. And more than likely DEVICE_ID would match as well if the site only has a single device (as we expect in most cases). But certainly in this scenario, the REQUEST_ID would be wrong as it would reflect an identifier for requesting a measurement that has yet to be acquired.
-------
There is currently no solution to block this behavior. I even attempted setting the item group data and form data as locked. The best way to block this would be a ClinSpark code change to prevent invoking the device on the form once it’s "Complete". Can we please get this issue on the product backlog?
Currently, measurements that are “Weight Only” are not able to be sent / transferred through ClinSpark. These weight measurements would need to be manually captured on a scale independent of device invocation and entered onto the form manually.
The seca mBCA 554 device will timeout if a subject does not step on the platform within 5 minutes of measurement start. We set the threshold to 10 minutes to allow for a 5-minute grace period in the event a subject stands on the platform moments before timeout. Measurement acquisition should not take more than 5 minutes. This threshold is used to prevent processing records that are too old to be considered for data posting.
If a Volunteers Demographics are updated following a measurement all past measurements will retain the data as calculated prior to the change. As each invocation and measurement is sent to the seca analytics platform ClinSpark sends the volunteer details as a “snapshot in time” so retrospective data will not be updated within past forms collected via ClinSpark.
In scenarios where a scale is not reserved for a specific person / measurement prior to device invocation. In these cases, it has been noted that Date of Birth may be requested following the collection workflow. Seca calls this the anonymous workflow and confirmed that this can be caused by error conditions in pushing Demographics to the device. In these instances, the recommendation is to start the collection workflow again. If the condition is seen in numerous consecutive invocations, please review demographics and contact the help desk.
...