Stream: implementers
Topic: ECG
Borut Fabjan (Sep 28 2016 at 14:24):
We came across the EKG example for FHIR Resource Observation content in: https://www.hl7.org/fhir/observation-example-sample-data.json.html
While we are familiar with the ECG signal (DCM & SCP ECG) and most of the given objects in the example, we would like to make sure we understand thoroughly the data object, its units and additional data.
1. We assume that the data object defines the EKG electric potential for leads I, II and III in integer units. Also, we assume that the origin (2048) and factor (1.612) were used to translate (using the origin) and scale (using the factor) the electric potential in physical units (volts or millivolts) to the final integer values.
Are our assumptions correct? If not, how do we obtain physical units of the given ECG record?
2. What are the units of the period object (10)? Milliseconds?
3. Are there any more of ECG/FHIR examples available?
Thanks in advance!
Brian Nantz (Sep 28 2016 at 15:20):
I have a proposal for an FHIR ECG Waveform that I am working with the FHIR implementers on and started to introduce at the Baltimore WG meeting. I do not believe an ECG should be just an observation for several reasons. For example, ECG’s require more meta-data to display and interpret properly than most observation discreet data. Rather I think ECG should stand alone (similar to how imaging is working with the FHIR WG). If you look at the precedent set by other standards such as DICOM-WS 30 (aka DICOM ECG) and HL7 v3 aECG, then I believe that FHIR should strongly consider my ECG Waveform proposal.
Elliot Silver (Sep 28 2016 at 15:40):
@Brian Nantz Have you considered just using DICOM ECG, and making the waveform available via ImagingStudy? Is there an advantage to having the information "native" in FHIR?
John Moehrke (Sep 28 2016 at 15:44):
Elliot, the advantage is more broad accessibility of the data. Specifically the FHIR search and access model; and full data accessibility in json.
Eric Haas (Sep 28 2016 at 15:54):
.. period Σ 1..1 decimal Number of milliseconds between samples
Brian Nantz (Sep 28 2016 at 15:58):
@Elliot Silver John has some great points about the technology and architecture style of REST that FHIR offers. Additionally, FHIR would strengthen integrations with EHR vendors which many of our customers are requesting.
Brian Nantz (Sep 28 2016 at 15:59):
@Eric Haas I'm not sure what you are proposing exactly could you elaborate? ECG requires more information than just the sample data to display and interpret properly.
Eric Haas (Sep 28 2016 at 16:01):
answer to 2) above period = number of milliseconds between samples
Elliot Silver (Sep 28 2016 at 16:03):
If "ECGs require more metadata to display and interpret properly than most observation discrete data," then one could argue that making sense of the information requires a specialized understanding anyhow, so whether the data is accessible via FHIR or DICOM isn't really the roadblock. And we have a mechanism for making DICOM information accessible in FHIR: ImagingStudy.
John Moehrke (Sep 28 2016 at 16:08):
Elliot, that would argue that all data that is not in 'core' should not be in FHIR. That seems like a null argument. There are many domain specific Resources (Specimen, Sequence, and a whole family of Financial). There are existing standards for moving ECG in the level of detail Brian proposed including inside DICOM, inside HL7 v2, HL7 v3, and CDA. So why not FHIR?
Brian Nantz (Sep 28 2016 at 16:10):
I would also content that creating a resource for the ECG modality will improve interoperability by including it in the default profile for FHIR.
Eric Haas (Sep 28 2016 at 16:17):
re 1) yes your assumptions are correct
3) this is the only one we have that use the sampled datatype - more examples would be great...
Eric Haas (Sep 28 2016 at 16:23):
I am interested to see the propose EKG resource
Brian Nantz (Sep 28 2016 at 16:52):
The proposal is very preliminary but we do at least have a prototype implementation to vet it out. I would love your feedback on improving it.Waveform-FHIR-v1.7.pdf
John Moehrke (Sep 28 2016 at 16:56):
I have it prototyped in a personal build, using current standard abstract model used by IEEE, HL7, DICOM.... (I am a FHIR editor, and former GE employee with ECG experience). But I need some workgroup to express interest before I can push it into the continuous build. Once pushed into the it can be reviewed, improved, and/or discarded. -- Brian just showed the PDF from that build.
Brian Nantz (Sep 28 2016 at 16:58):
@John Moehrke thank you for your help preparing that in a digestible format!
Elliot Silver (Sep 28 2016 at 16:59):
@John Moehrke , I don't have a strong opinion about whether ECG should have a FHIR-native representation or not, I was more pushing to see if there is a reason why existing mechanisms are not sufficient, or if there is a gap in the imaging resources.
@Brian Nantz I'll have a look at the proposal.
John Moehrke (Sep 28 2016 at 17:00):
@Elliot Silver sorry if you got negative impression. I was responding to what I perceived as constructive criticism, expressing knowledge that might not be known to all.
Elliot Silver (Sep 28 2016 at 17:02):
No problem. Your response was what I was looking for.
Brian Nantz (Sep 28 2016 at 17:11):
@Elliot Silver I have more detailed information if you have more questions please let me know.
Jason Walonoski (Sep 30 2016 at 13:41):
It wasn't clear to me from the PDF where in the waveform the actual ECG data was located... just seemed like metadata. Did I miss something?
John Moehrke (Sep 30 2016 at 14:41):
the Waveform.data holds the data. One for each set of data. The Waveform.data.value holds the values for that set of data. I have an example, but it is 2Meg in size.
Jason Walonoski (Sep 30 2016 at 14:44):
Ah, I see it now. The value didn't register before. Thanks.
John Moehrke (Sep 30 2016 at 14:46):
Yes, sorry. Explaining this through a PDF is difficult.
Brian Nantz (Sep 30 2016 at 20:55):
I can answer any detailed questions you have. The example I provided John included the Waveform resource in the same bundle as the Patient, DiagnosticReport and DiagnosticOrder resources for a full ECG report. One compelling reason for creating a Waveform resource (rather than embedding within another resource) is that a resource (e.g. DiagnosticReport) can reference it!
Mahmoud Alakraa (Dec 15 2016 at 23:28):
@Brian Nantz Thank you for your mention , this look very interesting , i reviewed the report , if we want to include the type name of using compression algorithm like AZTEC, SAPA, TP, CORTES, SPHIT, etc where we will mention that ?
Brian Nantz (Dec 16 2016 at 16:30):
Great question Mahmoud! The Waveform.data.encoding field is for just that use. You can send the raw data or you can specify the compression used there.
Mahmoud Alakraa (Dec 16 2016 at 18:20):
because if we want to reconstruct the ECG in the server side, we have to use specific compression algorithm and mention it in the resource , also your idea to create a resource just for ECG is very good because if there is some thing for image study in FHIR , it should be some thing similar for ECG, EEG , etc
Pranitha Sruthi (Jul 19 2017 at 05:11):
Hi all, I have to create a profile for ECG. I presume that the resource would be the DiagnosticReport and the result element which refers to Observation resource has to be sliced to obtain the findings namely area affected,hypertrophy , rate and rhythm. Is this a correct approach? Or please suggest me any other alternative. Thank you
John Moehrke (Jul 19 2017 at 13:54):
@Brian Nantz might have something...
Brian Nantz (Jul 21 2017 at 16:18):
@Pranitha Sruthi Are you sending samples periodically or do you want to send all the data at once?
Pranitha Sruthi (Jul 24 2017 at 11:05):
@Brian Nantz I did not get you. Could you please elaborate?
John Moehrke (Jul 24 2017 at 12:45):
Resting-ECG or Stress-ECG are historic objects, taken at a specific time. vs a continuous feed of current real-time waveform data from a bedside monitor.
Brian Nantz (Jul 25 2017 at 14:24):
Thanks for the clarification on that John! If you are streaming out real-time waveform data then using an Observation is a viable approach. However, in my opinion, using an Observation for an ECG that has been analyzed by an algorithm on the device is not a sustainable approach. Here are some data fields, off the top of my head, that other ECG standards can model but the Observation in FHIR cannot:
- Multiple related channels of data (leads) synchronized in time, labelled by lead label.
- Derived rhythm lead data for III, aVR, aVL, aVF
- Medians that are derived from sample data
- Meta-data including sample rate, filtering, etc.
- Annotation markers on the data for certain measurements
- Pacemaker markers
John Moehrke (Jul 25 2017 at 14:50):
Brian, do you have a proposed approach? Is this a new kind of FHIR Resource? Or is this a use of the Sequence resource? http://build.fhir.org/sequence.html
Eric Haas (Jul 27 2017 at 02:05):
sequence is specifically for genomics?
Pranitha Sruthi (Jul 27 2017 at 12:32):
@Brian Nantz Thank you
Brian Nantz (Jul 28 2017 at 14:47):
@John Moehrke I am still working on a proposal that will easily be referenced within the DiagnosticReport. The DR has everything an ECG needs (Orders, Demographics, etc...) except a way to reference the processed signal data. I will review what the DICOM/Imaging team is working on as well because they will need the same thing. I agree with @Eric Haas in that sequence is mainly meant for genomics and not a perfect fit. I know that other device manufacturers will want a way to send processed signal data (aka Waveform) even outside of ECG such as SPO2 and EEG - really any device were the algorithms are run locally on the device and the results need to be sent along. This is a little different use case than an Observation.
Lloyd McKenzie (Jul 28 2017 at 16:03):
Do you want the processed signal data as parsed elements or would a binary attachment do? We do have SampledData as a data type, but my understanding was that the work group was looking at this being yanked and replaced with a full-on resource.
Eric Haas (Jul 29 2017 at 18:21):
Do you mean send as a binary or do you mean to create some new structure in FHIR to represent this? I would need to see an example of the data to really understand it though.
Eric Haas (Jul 29 2017 at 18:22):
Lloyd read my mind
Pranitha Sruthi (Sep 08 2017 at 05:03):
Hi all, I have created a profile for ECG using the resource DiagnosticReport and sliced the 'result' element to obtain the findings namely rate, and all types of hypertrophy, blocks and rhythm. Is it a good practice to attach a large number of observations to the result element? Does it pose negative impact on the performance of the server? Thank you
Pranitha Sruthi (Sep 08 2017 at 07:22):
Can I create valuesets for different types of hypertrophy, blocks and rhythm, bind them to the extensions in the ECG profile(DiagnosticReport)?
Eric Haas (Sep 09 2017 at 00:01):
Can I create valuesets for different types of hypertrophy, blocks and rhythm, bind them to the extensions in the ECG profile(DiagnosticReport)?
yes see how binding valuesets to extensions is done here: http://build.fhir.org/ig/Healthedata1/IG-Template/StructureDefinition-template-basic.html#profile
Eric Haas (Sep 09 2017 at 00:02):
Hi all, I have created a profile for ECG using the resource DiagnosticReport and sliced the 'result' element to obtain the findings namely rate, and all types of hypertrophy, blocks and rhythm. Is it a good practice to attach a large number of observations to the result element? Does it pose negative impact on the performance of the server? Thank you
Yes the results cardinality is 0..* for that reason
Pranitha Sruthi (Sep 09 2017 at 05:32):
What about the performance of the server?
Pranitha Sruthi (Oct 03 2017 at 12:13):
Hi all, how can I attach 'Compare with previous ECG', 'Tilt' and 'Levels of Exertion' to my ECG (DiagnosticReport) profile? Thank you
Lloyd McKenzie (Oct 03 2017 at 19:14):
Those sound like they'd be Observation.components of the ECG observations. They wouldn't make sense in isolation and help in the qualification/interpretation of the ECG results.
John Moehrke (Oct 03 2017 at 20:51):
@Pranitha Sruthi these are all attributes of IEEE 11073 model for ECG. There are efforts by @Brian Nantz and @Paul Schluter to bring into FHIR a fully capable ECG model aligned with IEEE 11073 model. They should really participate in this discussion.
Eric Haas (Oct 04 2017 at 01:14):
@John Moehrke These efforts have been ongoing for a quite some time now - do we have a status update?
John Moehrke (Oct 04 2017 at 13:31):
I agree Eric. I was not saying one should stop progressing without them. But more that they need to step up or not. I modeled the IEEE 11073 model in a FHIR resource two years ago (exactly), prior to my layoff from GE. It is easy, but is a standalone Resource that holds all the ECG evidence, while using Observation for what Observation is good at. I would love to submit it... (It likely needs a bit of alignment to current FHIR build) -- that said, the consensus process of HL7 is what must be followed. Consensus means involvement, and progress based on who participates.
Pranitha Sruthi (Oct 10 2017 at 06:28):
Hi all, how can I capture the combination or group of leads i.e., chest leads V1 to V6, inferior leads I,II and aVF, anterior leads V3 and V4 etc in the ECG profile?
Last updated: Apr 12 2022 at 19:14 UTC
