...
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 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:
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.
The Agent generates an XML file ("input XML") with this information, and locates input and output directories in Device.
The Agent then locates Device EXE, and sends the input XML to the Device input directory. Then the Device executable is run.
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).
Device runs and functions based on user input. Device, upon completion (and termination), stores output PDF and XML files in its output directory.
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).
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).
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
...
.