...

The seca analytics 125 platform is interfaced with ClinSpark via SparkPlug. The interface is delivered transparently through the ClinSpark core application with all device interactions taking place via a ClinSpark forms. The device follows an Initiate Collection > Collect on Device > Upload Results workflow with a single ClinSpark form facilitating all of the required steps.

Installation

SparkPlug 24.2 (or later) and ClinSpark 24.2 (or later) is required for the seca analytics 125 device integration. All of the required software to interface with the seca mBCA 554 device is included in the SparkPlug installation and no additional installation or software is required.

The device profile must be provisioned into the target ClinSpark environment. Both the seca analytics 125 platform and SparkPlug must be configured correctly (detail below) to enable the two systems to connect and exchange data. Additionally, the asynchronous job to populate received data as study form data must be added to Administration > Support > Async Job Management in the target environment. AdditionallyLastly, the seca device should be configured to allow manual entry of Waist Circumference due to current limitations of the provided seca API.

...

1. The device is successfully enrolled and data collection is initiated in ClinSpark by invoking the seca analytics 125 platform via a ClinSpark form containing the minimum required parameters (see https://foundryhealth.atlassian.net/wiki/spaces/

...

1. DOCS/pages/edit-v2/4646437132#Form-Design) and having the prerequisite subject demographics included as part of the request.

2. The study participant is welcomed on the screen of the scale and steps on to perform the collection.

3. Waist circumference and height (when stadiometer is not connected) values are manually entered on the device during collection.

4. Data is returned to ClinSpark as Volunteer Monitoring Data.

5. Data populated as Volunteer Monitoring Data is asynchronously returned to the study form as Study Form Data.

Device Enrollment / Initialization

...

Prior to invocation, the seca analytics 125 platform requires a set of input demographics and study metadata be established to support the generation, processing and analysis of seca data as well as customization of the welcome message presented to the study participant. The required demographics that must be established prior to invocation are DOB, Race, Sex, Ethnicity (optional, see https://foundryhealth.atlassian.net/wiki/spaces/DEVDOCS/pages/edit-v2/4646437132#Race-Mapping below).

...

For errors encountered during device enrollment / initialization, see https://foundryhealth.atlassian.net/wiki/spaces/DEVDOCS/pages/edit-v2/4646437132#Errors-%2F-Troubleshooting.

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 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/DEVDOCS/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.

...

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.

...

• 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. But 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.

• 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 “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.

---------------------START OLD--------------------

Inputs

Describe how the interface (Agent, Mobile, SparkPlug, etc) interacts with device output to convert to ClinSpark inputs ie JSON → Object IDs and data, etc. Include the file types and any other pertinent info to the process ie directories, etc.

Describe any User Inputs needed for process to be invoked ie Study, Form, Subject Setup, etc.

Outputs

Describe the output to ClinSpark once the device captures data. This should include output file types ie. JSON converted to XML/PDF, etc.

Describe the interface process to grab the output files. This should include directories in which files are saved, etc.

Describe how the Clinspark application/client uses the output files and populates data/forms/etc.

Architecture Diagram

Create an architecture diagram. See example of below.

...

Workflow

Create a workflow to summarize the info and process. See example workflow below:

1. The ClinSpark Agent receives messages from the ClinSpark Client (in JSON structure, sent after "Invoke Device" has been clicked) containing relevant information for the ECG order.

2. The Agent generates an XML file ("input XML") with this information, and locates input and output directories in Device.

3. The Agent then locates Device EXE, and sends the input XML to the Device input directory. Then the Device executable is run.

4. Device begins running simultaneously as the Agent clears any and all files in the input directory (to ensure only one order can ever be processed at a time).

5. Device runs and functions based on user input. Device, upon completion (and termination), stores output PDF and XML files in its output directory.

6. The Agent pulls in the most recently time stamped XML and PDF files, and clears out any additional files in this output directory (this is done to minimize the possibility of the Agent picking up the wrong output file, and causing error in the whole of the system when future ECG tests are run). 

7. The Agent then parses the XML data into JSON, and sends all relevant information back to the ClinSpark app for ECG form population (including the PDF file).

8. The Agent then saves the XML and PDF files to Device's "Processed" folder, or the configured Archive Directory (ArchiveDir). This Archive Directory can include a local drive, or a shared network drive.

Data

Describe the data types and names included in output data files received by ClinSpark. The should include examples and locations of the data types within the output files. See example of Device below.

Data included in the output XML file, and received by ClinSpark

• PR (ms)

• QRS (ms)

• QT (ms)

• QTc (ms)

• QTcF (ms)

• QTcB (ms)

• RATE (BPM)

• RR (ms)

• P_Axis (degrees)

• QRS_Axis (degrees)

• T_Axis (degrees)

• EGTXT (this is an auto-interpretation of ECG results by Device)

• EGDTC (DDMMMYYYY HH:MM:SS)

• EGPDF (PDF Document).

Where in the XML is this Data?

Found in the <ECG> section at the top of the XML Doc

• RATE (labeled "VENT_RATE")

• RR (labeled "AVERAGE_RR")

• EGDTC (labeled "ACQUISITION_TIME_XML")

...

Found in the "Typical Cycle" section of the XML Doc

• PR (labeled "PR_DURATION")

• QRS (labeled "QRS_DURATION)

• QT (labeled "QT"), QTc (labeled "QTC")

• QTcF (labeled "QTCF"), QTcB (labeled "QTCB")

• P_Axis (labeled "P_AXIS")

• QRS_Axis (labeled "QRS_AXIS")

• T_Axis (labeled "T_AXIS")

...

EGTXT

Contents are found in the <Automatic_Interpretation.../> section, and the <Interpretation.../> section of the XML Doc.

...

EGPDF

Located at the very bottom of the XML Doc, in the section <Associated_REPORT_DOCUMENT.../>. This points to the directory in which the PDF is saved.

...

The ClinSpark Agent is responsible for sending both the XML and the PDF to the ClinSpark Application.

Reports/Dashboards

List all reports and dashboards that can be used “off the shelf” with this device.

Supported Devices / Models / Hardware

List all device / models supported by this integration and any other additional hardware requirements.

Notes

Include any relevant notes that you may reference above.

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 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.

Example Files

...

• .