We are two graduate students from Aalborg University, Denmark, taking our
master in Biomedical Engineering and Informatics. In this semester our
finale, we are working with complex data interoperability to an Electronic
Health Record (EHR). We are following the openEHRs EHR architecture standard,
and therefore also working with archetypes.
We have a few questions we would like you to help us deal with.
- What we are trying to investigate is how to represent a recorded ECG-signal
in an archetype, and therefore we are wondering what the status is on dealing
with ECG-signals as an archetype? So far we havent been able to locate an ECG-
archetype, only the description of it as an observation-entry.
- We have described workflows and clinical information guidelines for the
observation and clinical evaluation of an incoming ECG-signal, but we are a
bit confused on how to map the clinical information guidelines to an
archetype. Can anyone give us an example on how this mapping is done?
Best regards
Mie Færch Nielsen og Louise Pape Sørensen
Aalborg University, Denmark,
Master in Biomedical Engineering and Informatics,
10th semester
Reply-email: 06gr956d@miba.auc.dk
-1- I assume that you want to store all ECG measurements and not only the statement from the person that analysed the ECG.
-2-
My advice is to study what is available in the medical device sector.
Melvin is convenor in CEN/tc251 among other things. He can point you to relevant standards.
-3-
Study the relevant ECG standard.
-4-
And then you know what has/can be stored in the EHR.
Gerard
– –
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
This did make me wonder if it is always appropriate to create a detailed archetype for this kind of biomedical data, or should it perhaps simply be stored/referenced as a blob or link.
If the detailed data can be made sense of by another
application with much ado it make sense (in principle) to
"create a detailed archetype".
If it only really makes sense to the originating application
(the ECG software of the company in this case) it doesn't
make much sense to go beyond storing it as a blob and
handing it out to the original application on demand.
Now, of course, *any* data can be made sense of given
appropriate specs. Also, that's the whole purpose of
archetypes - to make data self-descriptive and
self-consistent. And in an ideal world one would want to map
the original data into a perfect ECG archetype and map it
back into whatever interpreter of such information is the
target.
But one also sometimes needs to walk the path of pragmatism.
OTOH it may be useful to have a detailed ECG archetype to
encourage direct use of it in *future* applications.
We are looking to get on this road ourselves. I believe we need to handle one or more MIME blobs but also the detailed measurements of the critical attributes (pr interval, qrs duration etc). The MIME blobs may be jpg or binary data for a common application. Does anyone know of any software standards in this space.
Remember that the ECG report will be a document (or at least a section) and contain an evaluation of the clinical implications - differential diagnosis etc and will include more archetypes than the straight physiology and decision support data.
HL7 has a datatype suitable for the raw data (SLIST)
Or you could just dump an image in DV_MULTIMEDIA (png
would be appropriate, but any image format would be ok)
pr, qrs etc, would be archetype entries - so you'd have
data as a DV_MULTIMEDIA or an SLIST and then the derived
useful values as additional archetype entries.
I hope you guys are not considering "yet another standard" for
the encoding of bulk ECG data (as opposed to referencing it
or wrap it as a blob).
ECG's are analogous to images from radiology; large amounts
of bulk data, highly specific meta-data of little or no interest
to non-image aware applications and well-standardized already
by DICOM.
Unfortunately, ECG device and distribution vendors have been
slower to adopt standards than the medical imaging device
vendors, and so there are a plethora of them, SCP-ECG,
DICOM waveforms, HL7 V2 waveforms, and the FDA HL7-CDISC XML
submission standard, not to mention just storing a picture
of the ECG in a PDF file (the IHE consensus solution).
These standards also address the annotation of the waveforms
and the conclusions drawn from them by the acquisition device,
and it is probably only the latter that would be relevant to
be extracted into the EHR.
David
PS. As to the wrapping versus referencing question for the bulk
binary data, I just got through sending a 1.4GB 2,600 slice
cardiac CT angiogram to a colleague, which I presume nobody
would be crazy enough to base-64 encode and embed in an XML
document, for example. The point being that wrapping things
is not a scalable solution.
Absolutely not - what we need are readers that can make sense of data as a blob and get these specified as suitable for use in an EHR. Do you recommend any very good or very widely used specs which have readers that are publicly available?
David,
FYI, There are forthcoming recommendations on including binary data in XML without using base-64. I expect that these would be used when available in implementation.
Thank you for all the interesting replies on the request on ECG-archetypes.
To clarify what our efforts in making an ECG-archetype are;
We have, as part of our thesis, examined the standards; SCP-ECG, aECG (FDA-XML)
and DICOM for storing and exchanging raw ECG and metadata.
In the thesis the main focus is designing an ECG archetype based on the openEHR
framework (CEN EN13606), more specifically we are handling ECG-samples from
heart patients monitored in their own homes (tele-homecare patients). The ECG-
samples consist of ECG-signals from an electronic patch containing two leads
and a reference lead, furthermore we are receiving blood pressure, weight and
pulse from the patient.
Dealing with blood pressure, weight and pulse should be straight forward due to
the archetypes already specified in openEHR-context. Therefore we are examining
the ECG-metadata (i.e. this could be some of the header information in the SCP-
ECG standard) appropriate for storage in the EHR versus for example at a
service provider. Together with the ECG-metadata we are also interested in
storage and presentation of the state of the patient, location of the patient
and activity-level of the patient at the time of the ECG-recording.
We have been in close contact with various clinicians to hear their statements
on what they need of information from the ECG-data. However due to the fact
that we are students and among other things lack experience in designing and
developing archetypes and complex data we turn to you for insight on how to
address the problem of how the segmentation of ECG-metadata should (or could)
be solved and furthermore where to store it.
The Multimedia element is available in both ENTRY, CLUSTER and STRUCTURE
classes - it is not directly visible from the Ocean Archetype Editor
interface, but click on the '+' button > New element > select 'Multimedia' >
check the options that you need to make available in the archetype.
For example, the imaging OBSERVATION -
openEHR-EHR-OBSERVATION.imaging.v1.adl - contains a multimedia element
called 'Image' which permits inclusion of .cgm, gif, png, tiff, jpeg and
dicom files.
Not sure what format you need for the ECG - DICOM is clearly there.
I was involved with a Cardiology IS project back in 2002 and remember some standardization survey we had done on this. At that time there were two alternatives for structured electronic representation of ECG: an US FDA-XML standard and an EU standard.
Just for curiosity I did a quick search and now an initiative from EU called openECG is very active. But the FDA stuff had merged with HL7 so it is also very dominant.
Below is the copy & paste from openECG site:
In 1993 it became a European ENV, later positively balloted within AAMI (AAMI EC71), and is currently a new work item proposal to IEC TC/SC 62 WG1 and ISO TC215.
What is OpenECG?
OpenECG is a European initiative with world-wide impact to promote interoperability and open standards in electrocardiography. The OpenECG portal provides up-to-date information, assistance, open source tools, data sets, conformance validation, and interoperability testing.
What is SCP-ECG?
SCP-ECG is a European standard (EN1064:2005) for high quality ECG specific compression, storage, and communication. SCP-ECG files of ~10Kb are excellent for health cards and micro-sensors. SCP-ECG is the result of an EU-driven effort with participation of American and Japanese manufacturers.
Are there other ECG data formats?
There are many proprietary data formats for ECGs. Well-known open ECG formats are aECG adopted in HL7 v3 (mainly for clinical trials), DICOM waveform (mainly for image and waveform time synch), and MFER, a Japanese format for time-series data.
The openECG URL: http://www.openecg.net
Absolutely not - what we need are readers that can make sense of data as a blob and get these specified as suitable for use in an EHR. Do you recommend any very good or very widely used specs which have readers that are publicly available?
Cheers, Sam
Also regarding ECG viewers, I know of a number of them - all commercial though. I have read on openECG site that some members might have some freely available apps.
Info about a suite (commercial - including a viewer) I am aware of complying with EU SCP ECG standard is at: http://www.tepa.com.tr/PDFs/EKG-MasterUSB.pdf (I have no relation with this company and mentioning only to give information).
As a last comment, I agree with Sam that we can design archetypes with fair bit of structure information inside and the biosignal part probably in native format complying with those standards, we may be able to share ECG data. I was wondering if integration archetypes can be used to map/convert one ECG standard into another? If not I have a proposal! Any comments?
Just a few comments from a non-expert in this field:
1) ECG and EEG has multi-channel biosignals in classical waveform,
whereas EMG was single channel at the time of my medical education
(10-15 years)
2) I guess the only way of storing it together with some context
information is definitely DICOM
3) However when you want to embed this onto openEHR or some other
alternative (such as HL7, openSDE, Protege or other) I guess the only
current way is the flat binary data form as you propose.
4) However I remember, though not so sure, some people from openEHR were
discussing about a similar issue whether to leave them as is or chop
into structural elements and store that way.
5) My personal idea is to leave such complex data structures as is but
find a method to extract key information stored in a widely accepted
standard such as DICOM and be able to represent as simple standard data
types in the archetype instances.
Just a few comments from a non-expert in this field:
1) ECG and EEG has multi-channel biosignals in classical waveform,
whereas EMG was single channel at the time of my medical education
(10-15 years)
2) I guess the only way of storing it together with some context
information is definitely DICOM
3) However when you want to embed this onto openEHR or some other
alternative (such as HL7, openSDE, Protege or other) I guess the only
current way is the flat binary data form as you propose.
4) However I remember, though not so sure, some people from openEHR were
discussing about a similar issue whether to leave them as is or chop
into structural elements and store that way.
5) My personal idea is to leave such complex data structures as is but
find a method to extract key information stored in a widely accepted
standard such as DICOM and be able to represent as simple standard data
types in the archetype instances.
that would be exactly my suggestion as well. From a large image set on a
PACS, a small diagnostic section might be extracted, converted to some
time-series samples (most likely at reduced resolution) and then both
items are put into the EHR - the URI to the PACS originals and the small
extract. The same idea would be used for any images - a computable or
even just .jpg 'thumbnail' can be stored in the EHR, with a link to the
originals on some dedicated database.
The only reason to do this is when some version of the original data
need to be computable directly in the EHR; the requirement need to be
thought out in each case. The advantage of doing it is that the record
contains the 'full information' (including biosignals, image sets etc)
but at reduced resolution, which is say appropriate for 95% of the users
of the EHR. The other 5% corresponds to users of the originals (usually
the people who make the images and the people who make diagnoses from
the images).
