Overview

The seca analytics 125 platform is an advanced software solution designed by seca, a leading provider of medical measuring systems and scales, to enhance the evaluation and management of patient data. This platform integrates seamlessly with seca's range of measurement devices, allowing healthcare professionals to collect, analyze, and interpret vital health statistics with precision. It offers comprehensive tools for the assessment of body composition, nutritional status, and overall health, thereby facilitating informed clinical decisions. Seca analytics 125 supports various functionalities, including trend analysis, graphical data representation, and customizable reporting, ultimately aiming to improve patient outcomes through detailed and accurate health insights.

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

Configuration

As noted above, SparkPlug must be fully configured with the required elements to enable interconnectivity via the seca API. Overall SparkPlug administration and configuration is outside of the scope of this document, but those configuration elements specific to the seca analytics 125 platform are detailed below:

API URL

The API URL to a valid seca analytics 125 endpoint must be configured in SparkPlug > Administration > Settings > seca > API URL. This URL is established & provided by seca.

Tenant Secrets

For each ClinSpark site that utilizes the seca analytics 125 integration, a valid Tenant ID must be established on the seca analytics 125 platform. A given ClinSpark Site ID can be determined by opening the site details in Administration > Sites and observing the Id displayed at the end of the URL.

In addition to seca establishing the Tenant, a public and private key pair are generated and provided. Both this seca Tenant name and the public and private key pair must be configured in SparkPlug > Interfaces > seca. When configuring the Tenant in SparkPlug, the tenant name entered must match the Tenant configured in seca.

Additionally, the Org URL for the site as configured in ClinSpark must be established in SparkPlug.

Collection Workflow & Forms

Form Design

Device Profile / Parameters

Clinical Parameters

Other Device Parameters

Data

Volunteer Monitoring Data

Study Form Data

Reports / Dashboards

Errors / Troubleshooting

Notes

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

Attach examples of input/output/ClinSpark files.