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
We made a template a few weeks ago with the purpose of capturing ECG from devices. This summer we will have a few students doing a project on integrating ECG from watches with our openEHR backend. The template is a first version for them to use: Archetype Designer
As you can see in the template we are using a CLUSTER archetype to carry the raw data.
BTW: We should workout a pattern for multimedia resources. It might even be as part of the RM since a multimedia resources is widely used within health and care.
1 Like
The archetype Heather mentioned is currently that pattern. Itās now called just āMedia fileā, and will be sent out for review soon, probably within the next couple of weeks: https://ckm.openehr.org/ckm/archetypes/1013.1.1800
3 Likes
Thatās great. Letās have the review and collect feedbacks. It would be nice if SEC members also get involved in that review - like @birger.haarbrandt , @thomas.beale , @Seref , @sebastian.iancu , @sebastian.garde , @matijap - to also get an implementer view on this.
Not an expert in cardiology, but to me this poses an interesting challenge for validation or use of this measurement for creating derived values. For example, do we want to check if the values are in a given (normal/plausible) range? if thatās the case either we go to Thomas proposal and then derive the serialized form from it or we are very clever with the validation (or create a new kind of validation for these DV_MULTIMEDIAā¦)
Looks like there are two aspects discussed here. @bonian modelling experts would probably like to hear how you modelled that raw data. I did not see that detail in this thread.
How you model that data will potentially imply the way it is handled. It is more than storage youāll have to think about. Say you used DV_MULTIMEDIA. It is less likely that youāll allow that archetype path to have an optional existence than having it mandatory if youāre using openEHR to handle that raw data in the first place.
So you now dictated to your software devs that data should be in the COMPOSITION they send to the backend. How it is stored is not your concern from a modellerās perspective (this being the clinical list). Thatās an implementation detail, and youāre welcome to relevant group to discuss that 
If you use an RM type in your archetype that hints at the data being elsewhere, thatāll tell the developers that data is either put there by another channel, or they need to make sure that it exists before pushing the COMPOSITION.
So Iād kindly suggest untangling your question into two questions:
- How should we handle raw data in our backend ? (a discussion for a more tech category)
- Based on the decision from the first Q: how should we model our archetypes to guide developers ? (experts in this list would tell you what your options are)
This is how Iād approach the question if an Ocean customer came up with it. Hope it makes sense, feel free to tell me if it does not.
Ugh, @thomas.beale, I would hate to see raw measurements (in volts, in this case) in the EHR as quantities. Thereās nothing useful that can be done with it within the EHR, and even conversion to any useful form would be inefficient; itās an ideal use-case of data that needs to be externalised and only linked from within the EHR. Assessment/categorisation of the ECG signal is what belongs into the EHR; both the one done by the machine itself (which they do), and the manual one done by the cardiology specialist.
2 Likes
I agree - I wasnāt promoting the idea, just saying objectively how you would have to do it if you really wanted to. The sensible approach is storing whatever compressed multimedia file makes sense within this domain and processing that when needed with the right specialist software / tools.
1 Like