Stream: implementers
Topic: Biosignals
Mahmoud Alakraa (Dec 09 2016 at 02:41):
Hello
What is the best place to include bio-signals like ECG, EEG ,..,is it the observation resource and in which element exactly and in which format?
Grahame Grieve (Dec 09 2016 at 02:43):
can you give me some sample data? I've been meaning to build examples for these two things...
Mahmoud Alakraa (Dec 09 2016 at 02:48):
i have some examples but in the European Data Format (EDF) format , is it ok ?
Grahame Grieve (Dec 09 2016 at 02:50):
sure. send them to me by private message
Grahame Grieve (Dec 10 2016 at 21:06):
can you clarify your intent here, @Mahmoud Alakraa - do you want to avoid using EDF? or thumbnail this into FHIR? EDF is specialised at this purpose, so FHIR isn't going to be better than EDF
Grahame Grieve (Dec 10 2016 at 22:06):
anyway, here's a candidate for us to discuss:
Grahame Grieve (Dec 10 2016 at 22:06):
<Observation xmlns="http://hl7.org/fhir">
<status value="final"/>
<code>
<coding>
<system value="http://loinc.org"/>
<!-- if this is the correct code -->
<code value="75918-3"/>
<display vlaue="Bispectral index Cerebral cortex Electroencephalogram (EEG)"/>
</code>
</code>
<subject>
<reference value="Patient/NA02702"/>
</subject>
<effectiveDateTime value="1999-12-18T21.55.53Z"/>
<!-- first component, source -->
<component>
<code>
<text value="source"/>
</code>
<valueAttachment>
<contentType value="application/edf"/> <!-- well, application/edf is unused, though there is no formal assignment -->
<url value="https://drive.google.com/file/d/0B6FsEVwOXvl1bTQ0Wnh1LTRHTU0/view?usp=sharing"/>
</valueAttachment>
</component>
<!--
now follows a series of components, one for each signal.
In theory, the SampledData type allows for this to be a single
component, with 14 dimensions, but EDF - and this example - has different metrics
for the different dimensions. So it has to be a different components. Con: this
does lose the interlacing, which may be useful (streaming live observation?)
-->
<component>
<extension url="http://hl7.org/fhir/StructureDefinition/observation-component-device"> <!-- I made this up for this example -->
<valueReference>
<display value="Transducer: gold"/>
</valueReference>
</extension>
<code>
<text value="EEG C3-A2 [C3A2]"/>
</code>
<valueSampledData>
<!-- for this one, I'm representing the raw data directly -->
<origin>
<value="0"/>
<system value="http://unitsofmeasure.org"/>
<code value="uV"/>
</origin>
<period value="3.906"/>
<factor value="1"/>
<dimensions value="1"/>
<data value="11.462675 4.787573 12.937697 23.887864 23.212854 15.787741 11.81268 12.937697 16.087745 28.21293 42.238145 40.688121 18.437781 11.387674 29.312947 29.012943 14.287718 11.887681 11.78768 5.562585 -4.087562 -0.937514 9.937652 19.237794 34.363024 30.487965 16.987759 19.762802 19.6878 12.262687 15.687739 21.062821 13.712709 4.437568 15.73774 30.112959 36.68806 38.288084 21.237824 5.712587 9.987652 15.462736 14.787726 11.662678 8.087623 11.562676 13.887712 20.187808 28.037928 30.362963 33.838016 31.087974 23.387857 32.362994 28.787939 12.412689 6.5626 14.012714 21.837833 25.687892 27.937926 29.437949 18.587784 8.937636 12.362689 13.937713 6.587601 19.01279 30.687968 4.262565 -11.287672 5.362582 11.16267 2.312535 5.812589 14.287718 17.362765 20.087807 27.162914 31.862986 31.387979 30.16296 32.11299 27.912926 14.337719 3.737557 5.23758 15.762741 11.612677 10.137655 20.96282 15.08773 3.037546 14.312718 34.938033 35.688045 26.712908 15.437736 3.387552 10.037653 18.212778 12.337688 14.637723 26.312902 21.337826 13.937713 26.362902 30.587967 20.887819 15.862742 11.237671 5.387582 18.187778 32.537996 32.913002 28.287932 25.612891 22.887849 27.912926 35.713045 28.737939 25.187884 30.562966 38.713091 33.738015 10.837665 -4.387567 0.162502 6.412598 6.487599 10.812665 32.537996 40.313115 24.412873 17.087761 25.637891 34.588028 36.088051 37.663075 45.488194 38.113082 19.337795 16.537752 23.962866 36.463056 47.363223 43.088157 29.48795 19.312795 23.187854 33.713014 40.338116 34.08802 17.362765 10.362658 10.737664 9.987652 14.262718 18.512782 24.787878 36.538058 35.36304 30.262962 31.387979 29.037943 30.987973 34.863032 43.388162 40.988125 8.362628 ..."/>
</valueSampledData>
</component>
<!-- 2nd component, I applied a factor for efficient representation -->
<component>
<extension url="http://hl7.org/fhir/StructureDefinition/observation-component-device"> <!-- I made this up for this example -->
<valueReference>
<display value="Transducer: gold"/>
</valueReference>
</extension>
<code>
<text value="EEG O1-A2 [O1A2]"/>
</code>
<valueSampledData>
<origin>
<value="0"/>
<system value="http://unitsofmeasure.org"/>
<code value="uV"/>
</origin>
<period value="3.906"/>
<factor value="0.025"/> <!-- this is what it looked like based odd the EDF headers, but the numbers don't work out quite right, so I expect I misunderstood something in the format -->
<dimensions value="1"/>
<data value="raw 772 659 614 899 1104 962 1033 845 818 1117 1277 1339 1035 938 1376 1428 1289 913 568 644 504 554 681 542 668 575 764 1091 979 928 646 413 784 1078 1376 1270 792 871 901 730 730 780 740 430 285 624 471 538 930 1085 1069 835 869 1119 743 597 611 585 822 1005 1141 1060 782 876 873 1089 1199 923 895 705 700 1086 1118 1274 1367 1242 1580 2028 2020 1776 1694 1860 1582 1447 1646 1360 1233 1485 1384 1342 1479 1644 1688 1490 1589 1634 1552 1626 1331 1459 1754 1179 916 1305 1462 1307 1539 1816 1335 967 1430 1319 1136 1385 1569 1708 1711 1972 2018 1712 2344 2371 718 11 553 843 572 722 1219 931 687 1647 2218 2094 1556 1358 1807 1959 2006 2274 1964 1382 1300 1736 1958 1653 1822 1911 1334 1026 1400 2282 2449 1518 1130 1331 1517 1441 1332 1892 2302 1884 1788 1708 1337 1044 1168 1631 1641 1543 1466 1190 1409 1564 1381 1447 1555 1598 1252 891 1189 1476 1663 1675 1389 1358 1302 1271 1874 1768 871 468 1009 1692 1224 821 1320 1304 960 788 776 1182 1304 1241 1102 931 887 361 484 1162 1221 1195 1093 1046 1259 991 852 1120 1199 1633 1616 1109 973 1075 1363 1209 1152 1637 1591 1157 643 318 431 354 354 834 924 596 252 360 918 806 494 634 663 520 412 665 855 588 720 719 59 -217 -129 7 288 ..."/>
</valueSampledData>
</component>
</Observation>
Grahame Grieve (Dec 10 2016 at 22:06):
@Rob Hausam @Eric Haas for your attention too
Mahmoud Alakraa (Dec 11 2016 at 00:49):
@Grahame Grieve thank you , it is so useful , i just try to thumbnail this into FHIR , i will try to use this and see the results
Rob Hausam (Dec 11 2016 at 02:28):
this is interesting, and we need to handle these observsations - I hadn't heard of EDF until today, so I probably need to look into it a bit more
I'm not quite grasping yet why the the interlacing (synchronization?) is lost - I think we need that
Grahame Grieve (Dec 11 2016 at 09:24):
the synchronization is still there; you can reassemble the data correctly
Grahame Grieve (Dec 11 2016 at 09:24):
but the interlacing in the format is lost because each signal has to be it's own component
Grahame Grieve (Dec 11 2016 at 09:25):
to carry the metadata, and because each signal can have it's own factor and offset. SampledData allows for multiple signals but no metadata per signal, and all of the signals must have the same factor
Eric Haas (Dec 11 2016 at 19:11):
I thought this extensions allowed for the interlacing. http://build.fhir.org/extension-observation-time-offset.html Its been a while and I forgotten most of the details but I remember having this conversation before.
Grahame Grieve (Dec 11 2016 at 19:59):
the intent of that would appear to be to not use SampledData. I cannot imagine having a component for every 10000000 numbers in that data sample
Eric Haas (Dec 11 2016 at 20:28):
that was not the intent. your datastream contains abcabcabc... three signals on the same channel. you want to represent the a's the b's and the c's that was the intent. Are we talking about the same thing?
Eric Haas (Dec 11 2016 at 20:29):
it implies three components for each channel repeating the datastream.
Eric Haas (Dec 11 2016 at 20:30):
Pretty inelegant - probably a better way
Grahame Grieve (Dec 11 2016 at 20:32):
well sampled data is the most effective way that we can describe data - a single observation with multi-channels. But I don't see how that extension gits into use of SampledData
Grahame Grieve (Dec 11 2016 at 20:35):
maybe we need
SampledData
dimension
code - identifies the particular dimension
origin - same as now, but dimension specific
factor - same as now, but dimension specific
timeOffset - number of milliseconds this comes after main period
lowerLimit - same as now, but dimension specific
upperLimit - same as now, but dimension specific
period
data
Grahame Grieve (Dec 11 2016 at 20:36):
+ notion that N means No Measure for this period (s well as E L U currently defined)
Eric Haas (Dec 11 2016 at 20:42):
That is better. so for sake or argument - period = 1 sec and:
-
dimension a
** timeoffset = 0 s -
dimension b
** timeoffset 0 .33 s -
dimension c
** timeoffset = .66 s
But what is component.code? Channel 1? how do I search for lead 3 on on a 12 lead EKG using 4 interlaced channels.
Grahame Grieve (Dec 11 2016 at 20:44):
well, there'd be some conceptual overlap between SampledData.dimension.code and component.code, but since there's only one value, and the data is buried inside SampledData.data, there's really no point searching for lead 3. You just search for the 12 lead EKG, and then you figure out which dimension is lead 3 by reading the codes in SampledData.dimension.code
Eric Haas (Dec 11 2016 at 20:46):
so you have code= 12 lead ekg
4 component.code ( one for each channel)
each with 3 dimensions in component.valuesampleddata
Eric Haas (Dec 11 2016 at 20:47):
tracker to get rid the extension and enhance SampledData ?
Grahame Grieve (Dec 11 2016 at 20:48):
no components. just observation.code and observation.valueSampleData
Grahame Grieve (Dec 11 2016 at 20:49):
and drop SampledData as a choice from component.value[x]
Eric Haas (Dec 11 2016 at 20:51):
I thought the use case I saw a while back there where multiple streams of data each one interlaced. I need to go back and research that. So a 12 lead ekg was split into 3 or 4 datastreams.
Eric Haas (Dec 11 2016 at 20:51):
for that I would imagine needing component to represent the datastreams
Grahame Grieve (Dec 11 2016 at 20:52):
ok you do the research and then we'll talk more
Rob Hausam (Dec 12 2016 at 04:54):
I'm reasonably up to speed on the general notions of signal processing and sampled data representation (I'm a EE, after all) - but I haven't looked into this situation enough yet
I took what I thought might be a good guess about what you've been referring to as "interlacing", @Grahame Grieve , but I think I need additional and probably more specific explanation/examples to be sure that I'm thinking of the same thing that you are
Grahame Grieve (Dec 12 2016 at 06:10):
say you have 3 channels
channel #1 #2 #3 signal 1 min 0.1 0.7 1.3 2 min 0.2 0.6 1.0 3 min 0.3 0.5 1.2
Grahame Grieve (Dec 12 2016 at 06:11):
normal presentation might be
#1: 0.1 0.2 0.3
#2 0.7 0.6 0.5
#3 1.3 1.0 1.2
Grahame Grieve (Dec 12 2016 at 06:11):
interlaced is
1/2/3: 0.1 0.7 1.3 0.2 0.6 1.0 0.3 0.5 1.2
Grahame Grieve (Dec 12 2016 at 06:12):
which is what SampledData is
John Moehrke (Dec 12 2016 at 14:54):
Why are we trying to 'hack' something in at this point? It seems to me that multi-lead waveforms are distinct use-case that should have their own Resource. I have modeled it, based on the IEEE encoding that we use in HL7 v2. We just need a sponsor to promote it as a work item.
Grahame Grieve (Dec 12 2016 at 19:41):
well, they don't currently. And I'm not entirely sure they should. But since they don't, Observation. As for SampledData... where else would it be used?
Eric Haas (Dec 12 2016 at 19:52):
see http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=5665 for a discussion of using multiple interlaced channels. so for a 12 lead ekg you would have:
channel 1: 1/2/3: 0.1 0.7 1.3 0.2 0.6 1.0 0.3 0.5 1.2
channel 2: 4/5/6 more data...
channel 3: 7/8/9 more data...
channel 4: 10/11/12 more data...
I think component is still in play but that adds and extra layer of codes.
Grahame Grieve (Dec 12 2016 at 19:53):
why would you split it up like that/
Eric Haas (Dec 12 2016 at 20:01):
I am just a messenger for this use case. Need to ask the EE :-)
Rob Hausam (Dec 12 2016 at 21:13):
@Grahame Grieve thanks, that makes sense regarding interlacing
I don't see interlacing in the GF#5665 example, though
I'm also not sure why you would split up the 12 lead ecg into 4 channels with 3 interlaced leads per channel as in @Eric Haas's description - you could do it that way, but I'm not seeing the rationale for doing it
Eric Haas (Dec 12 2016 at 22:23):
RE:"I don't see interlacing in the GF#5665 example, though" it is there, and I would hesitate to say what is rationale.
Brian Nantz (Dec 15 2016 at 16:29):
I find it interesting that this topic keeps coming up (see https://chat.fhir.org/#narrow/stream/implementers/topic/ECG)! It’s almost like many consider FHIR a perfect protocol for sending a complete ECG report :)
While sending the data as part of an observation may work for situations like Patient Monitoring where small slices of the data are sent periodically, there are several challenges to this approach when sending an entire diagnostic quality ECG including:
*Multiple related channels of data (leads) synchronized in time, labelled by lead label.
*High sample rate of 500 samples/sec for 10 secs
*Derived rhythm lead data for III, aVR, aVL, aVF
*Medians that are derived from sample data
*Meta-data including sample rate, filtering, gain, etc..
*Annotation markers on the data for certain measurements
*Pacemaker markers
So @Mahmoud Alakraa I am working with the Devices on FHIR group to create a proposal for ECG which could also work for EEG, etc.. I would appreciate if you would review and give feedback on the proposal!
Grahame Grieve (Dec 15 2016 at 17:54):
where's the proposal?
Reinhard Egelkraut (Jan 15 2017 at 22:25):
Hi there,
I was wondering which one of the working groups has currently the lead when it comes to biosignals and FHIR? Out of the existing zulip discussions on this topic it was not really clear to me (next to this one there are also https://chat.fhir.org/#narrow/stream/implementers/topic/ECG and
https://chat.fhir.org/#narrow/stream/implementers/topic/EEG.20Data).
The reason for my question is that in Austria there are currently projects ongoing which would have the need to communicate various biosignals via FHIR (like ECG, EMG, EEG, EOG, ENG). The responsible people would be interested to participate in the discussions and work on the according resources, so I wanted to know to whom I can turn to.
Grahame Grieve (Jan 15 2017 at 22:41):
Imaging is working on a proposal for a WaveSignal resouce. It would be a souped up version of SampledData (and Sampled Data would be withdrawn, probably)
Reinhard Egelkraut (Jan 15 2017 at 22:59):
@Grahame Grieve thanks for the info. I will ask the imaging group, Elliot Silver and Brad Genereaux have the lead there, correct?
Grahame Grieve (Jan 15 2017 at 23:21):
yes: @Elliot Silver @Brad Genereaux @John Moehrke are your contacts
John Moehrke (Jan 16 2017 at 13:44):
I would expect this topic to be covered in the Devices workgroup. They are responsible for this topic in v2, and have SME. It is true that DICOM has an object definition in DICOM format, not heard it was a HL7 FHIR topic in Imaging.. @Brian Nantz @Todd Cooper @John Rhoads @Chris Courville @John Garguilo
Maksym Bodnarchuk (Jan 19 2017 at 16:38):
Hello
What is the best way to store Oxygen Saturation measurement.
There can be up to 86K data points every 12 hours.
So storing them in separate observations is too verbose.
At the same time storing 86K points in single observation feels like bad idea.
Eric Haas (Jan 19 2017 at 20:03):
by store what do you mean? FHIR is among other things an interoperability spec, although you can persist the data as a FHIR resource as well. But a couple of option I can imagine is to use the Observation.valueAttachment element to retrieve a binary. It sounds like its streamed so - check out the valueSampledData element which is available now. See above discussion for other stuff being proposed.
Brad Genereaux (Jan 19 2017 at 20:43):
Is this something for DICOM waveforms? If you create it that way, you can still deliver the reference via FHIR ImagingStudy. http://dicom.nema.org/medical/Dicom/2015b/output/chtml/part03/sect_C.10.9.html @Elliot Silver
John Moehrke (Jan 19 2017 at 22:23):
Proposal discussed in hallway is to use Observation for core of ECG with waveforms represented in Sequence(s). This uses the current Resources, and exposes the information in a FHIR friendly way, while also keeping the waveform sequences in independent instances that would only need to be retrieved when needed. It seems no progress was made this week, so a community of interested people need to come together and force something to be developed. Use of the DICOM ECG format would be a stop-gap, but is not a FHIR friendly mechanism. Third option is to use Observation pointing at a DocumentReference pointing at the PDF formatted ECG; this would only work if further evaluation/serial-compare need to be done on the waveform.
Brad Genereaux (Jan 19 2017 at 22:41):
My general comments without understanding your use cases at all :) Use of DICOM ECG may also depend on the broader use case (i.e., if the ECG is tied to the same study with a cardio ultrasound series - it may not be in the best interest to separate these across different systems, or it may, it depends). Also given that there is market penetration of DICOM ECG already, there would hopefully be some effort to figure out how to translate/map them should an additional standard be made. This may also require significant input / investment from the modality/cart vendors too.
John Moehrke (Jan 19 2017 at 23:06):
I know that any modeling of ECG into FHIR would need to map to the abstract model defined in IEEEE. That IEEEE model is the parent of the current HL7 v2, HL7 v3, and the DICOM ECG. @Brian Nantz and @Paul Schluter are the SME.
Mahmoud Alakraa (Jan 19 2017 at 23:54):
@Reinhard Egelkraut did you find the correct group? if yes which one? i am working in same things and i am interested to know more about the updates
thanks
Eric Haas (Jan 21 2017 at 05:29):
@John Moehrke I think you might have meant SampledData data type instead of the "Sequence" resource which for representing genomic data. :-)
Alois Schloegl (Feb 02 2017 at 20:06):
Dear all,
I'm new to HL7, but work now for more than 20 years in the area of biomedical signal.
I'm also part of the Austrian Initiative mentioned before by Reinhard Egelkraut,
and I'm coordinator of "Biosig - A free software library for biomedical signal processing" [1]. I'm interested in getting biosignals better supported in clinical environent, and I think HL7 FHIR seems a very promising platform.
Biosig supports reading of about 50 different biosignal data formats (including EDF, SCP-ECG, HL7aECG, MFER, GDF, and many more).
Keeping the sample data in a binary format makes certainly sense, you do not want to handle 8 hours of sleep recordings as ASCII data, you really want to keep this in binary format and use . Biosignals are a own class of data. Biosignals are somewhere in between (in terms of size) of imaging data, and laboratory data, and they require and ask for its own tools (e.g. viewer) and analysis methods.
In order to analyze and view the sample data, Biosig provides a number of bindings to programming platforms that can handle signal data very well (e.g. matlab, octave, R, python, ...), and "libbiosig" is also included in viewers like sigviewer or stimfit.
The project "Biosig" provides tools to wrap biosignal data into HL7 FHIR binary templates [2], and to extract the header information (i.e. meta-information) in JSON, XML or ASCII format. For more information, you can use the biosig command line tools "save2gdf" and "biosig_fhir". There are also examples how to use them from within perl and php.
We define a common data structure (meta-, or headerinformation, data samples, events and annotations) for biosignals, the serialized format is defined in [3], and can be extracted with the Biosignal tools mentioned above [1]. If need help with "biosig", or if you have comments how biosignals are stored, do not hesitate to contact me by email at <alois.schloegl@gmail.com>. I'm wondering what need to be done to get better support of biosignals ina clinical environment.
[1] http://biosig.sf.net
[2] http://www.hl7.org/FHIR/binary.html
[3] K2204:2015 "GDF - A general data format for biomedical signals.", Austrian Standardization Institute, 2016
Best regards,
Alois
Essien (Aug 25 2017 at 08:39):
@Brian Nantz Hi Brian, I'm interest in this proposal. Can you tell me where it can found? Thanks.
Brian Nantz (Sep 06 2017 at 14:33):
@Essien Attached is the original proposal Waveform-FHIR-v1.7.pdf. Would you be willing to work with me on a formal proposal for the upcoming meeting? I think the idea of using a resource to represent Digital SIgnal data is a strong idea, but I need to polish the proposal.
John Moehrke (Sep 06 2017 at 14:39):
Brian, You are going too deep too soon. First you need to write a Resource Proposal. A Resource Proposal does NOT need to have any details of what the Resource would look like. It needs to focus on what is the space you intend to address, and why the existing resources are insufficient to address that need. see http://wiki.hl7.org/index.php?title=Category:FHIR_Resource_Proposal for example the Sequence resource proposal is http://wiki.hl7.org/index.php?title=Sequence_FHIR_Resource_Proposal. The kind of detail you are currently focused on is the kind of thing that will evolve once you get a Resource into the build, and others can review/prototype with it --- aka Standard for Trial Use (STU)... --- I am happy to help.
John Moehrke (Sep 06 2017 at 14:43):
You do need to also crate a Project Scope Statement (PSS) that you get some workgroup to own. Likely Devices.. right? Note this new Resource proposal might fit inside of the general FHIR PSS that devices already has open... http://wiki.hl7.org/index.php?title=FHIR_Device-Related_Resources
Lloyd McKenzie (Sep 06 2017 at 15:04):
It's perfectly fine to put together a draft of the resource before writing the proposal. Doing some initial fleshing out often helps confirm that a resource is necessary and shapes the proposal.
Last updated: Apr 12 2022 at 19:14 UTC
