Best way to handle raw ECG signal data from apple watch

Hey, we are using the ecg of apple watches and would like to store the raw signal data on our openEHR server. We are not sure if a seperation of openEHR data and the raw signal data in a additional DB would make more sense. Does someone have any experience in handling openEHR and raw ecg? Thanks!

3 Likes

Following this thread! I’m not sure what the raw signal would look like, but I’m assuming it’d be something like a stream of electrical amplitude measured in milliVolts, on a timescale of milliseconds?

We currently have the ECG result archetype which is focussed on the operationalisation of that stream into clinically relevant concepts, but I suspect we’d need a completely new archetype to store the raw data.

2 Likes

The multimedia datatype seems to be an appropriate choice. Though internally inside the openEHR Server this should be stored into a dedicated storage like MinIO. Within EHRbase we do not have the separation implemented at the moment but this is on the roadmap

3 Likes

@siljelb : I saw the result type, this could be used in the future by a analytic middelware to write calculations to (e.g. QRS), but at the moment its only about data handling. The data looks something like this comming as FHIR msg:

<Observation>
<component>
                    <code>
                        <coding>
                            <system value="http://unitsofmeasure.org" />
                            <code value="uV" />
                            <display value="microvolt" />
                        </coding>
                    </code>
                 <valueSampledData>
                        <origin>
                            <value value="0" />
                        </origin>
                        <period value="1.95434646654159" />
                        <dimensions value="1" />
                        <data value="-70.865 -78.445 -85.417 -91.786 -97.616 -102.869 -107.346 -110.99 -113.907 -116.063 -117.366 -117.702 -116.813 -114.797 -112.172 -109.258 -106.207 -103.297 -100.767 -98.955 -98.42 -99.223 -100.89 -103.123 -105.722 -108.452 -111.205 -113.72 -115.508 -116.469 -116.89 -116.952 -116.808 -116.556 ... />

@birger.haarbrandt thanks for the info! As i would have thought seperate DB makes sense at the moment, but nice to know this issue is on your roadmap

2 Likes

I am not the most experienced person when it comes to the backends, but wouldnt the goal be to store the data in openEHR natively? In that regard multimedia slot would be what I’d suggest as well. One would create an appropriate cluster archetype, I guess?
What would be the reason to not store the data in openEHR, just curious?

3 Likes

Just to discuss the options here, one could also be making an e.g. template and referencing the inital DICOM data of the EKG in another system. So it acts more like a link. Nevertheless i don’t think this is an option for what your trying here.

3 Likes

If by this you mean storing the signal file(s) as DV_MULTIMEDIA instances, you still have the choice of representing inline (data field) or as a link (uri). The model can be seen here.

A more ‘native’ representation would be as an OBSERVATION whose data field contains a HISTORY where each EVENT carries a DV_QUANTITY representing a voltage, and also the time-point. Given that you’d probably have thousands (or O(10k)?) samples, this might not be super-efficient, but would give you direct access to the time-domain waveform that you can easily convert to an array of time-stamped real numbers for each lead, to run cardiology, DSP etc algorithms on. I don’t know if there is any advantage in doing this, versus just sticking with the native signal format (of which I see there are many, so no standard there) and using whatever library to interpret those files.

A quick browse online tells me that most people doing interesting things with ECG data first convert to some intermediate format that looks more like a time-stamped uV values. I see matlab file formats, .ecg file formats etc. It’s not clear to me from a cursory look whether any such format is preferred. The HISTORY structure is the best we could do in openEHR right now.

If we were to define a true native format in openEHR I imagine it would be just adding one of these published intermediate formats (i…e not raw device data, which is usually some differentially encoded or otherwise compressed signal data) into the openEHR type system.

2 Likes

The ‘Digital representation’ SLOT carries the ‘Media capture’ archetype. It is intended for the purpose of holding this kind of data in an openEHR system, if needed - https://ckm.openehr.org/ckm/archetypes/1013.1.1800

It has just been revamped, previous known as CLUSTER.multimedia. If anyone’s interested to take a look, now is a good time to make some change requests.

4 Likes