Storing patient care data: ECG, ventilators, blood pressure, etc - DICOM

This is a discussion on Storing patient care data: ECG, ventilators, blood pressure, etc - DICOM ; In our healthcare facility, we have been asked to give a solution to store patient care data (e.g. ECG, ventilators, blood pressure, etc), since we already store radiology and pathology images in our PACS. As far as I have seen, ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Storing patient care data: ECG, ventilators, blood pressure, etc

  1. Storing patient care data: ECG, ventilators, blood pressure, etc

    In our healthcare facility, we have been asked to give a solution to
    store patient care data (e.g. ECG, ventilators, blood pressure, etc),
    since we already store radiology and pathology images in our PACS.

    As far as I have seen, dicomizing ECG is possible, but other signals
    look more complicated (no SOP Classes defined in DICOM).

    On the other hand, I see in "IHE Patient Care Device Technical
    Framework" that HL7 is the proposed system to communicate.

    How is one expected to store the data? Is DICOM/PACS a good idea?

    I don't know much about XDS, but it looks the right direction.

    Any recommended reading is welcome.

    Thanks in advance,
    ivan


  2. Re: Storing patient care data: ECG, ventilators, blood pressure, etc


    ivanet@gmail.com wrote:
    > In our healthcare facility, we have been asked to give a solution to
    > store patient care data (e.g. ECG, ventilators, blood pressure, etc),
    > since we already store radiology and pathology images in our PACS.
    >
    > As far as I have seen, dicomizing ECG is possible, but other signals
    > look more complicated (no SOP Classes defined in DICOM).


    There are native representations of ECG/EKG data in DICOM (waveform SOP
    Classes) but there is also now SOP class for DICOM encapsulation of
    PDF documents. So, literally any content which can be put into PDF,
    scanned paper, pdf'ed word documents, video and audio files, etc can be
    encapsulated into a DICOM wrapper. So what does this do for you? It
    puts a DICOM SOP instance UID on the PDF file, allows association
    with other , related digital content objects thru Series and Study
    instance UIDs, provide searchable holder for patient id and
    demographics data , and allows storage into a DICOM based PACS. Once in
    a DICOM PACS, it can be queried and retrieved as is currently possible
    with radiology, cardiology, pathology images. Also the IHE XDS-i
    registration and retrieval methods come into play. The PDF
    encapsulation has been around for a year or so now. I would expect to
    start seeing it in commercial PACS products DICOM conformance
    statements soon.

    Of more interest to me is seeing how the de-encapsulation process is
    going to work in DICOM viewers. If you think about it, encapsulating
    PDF inside of DICOM is sort of like putting a bicycle inside a formula
    one race car (ok maybe more like in a NASCAR vehicle). The point being,
    anybody can read PDF with a free and ubiquitious viewing app (acrobat
    reader). The acrobat reader in turn honors the MIME encoding of data it
    encapsulates. So, if a PDF has a quicktime or MP3 or AVI datastream
    encapsulated in it, the acrobat reader will attempt to invoke the
    MIME controls available on the viewing workstation to view the data.
    Although there are lots of public domain/open source DICOM viewers out
    there, most DICOM viewers, free or commercial, have yet to build that
    sort of "open on the inside" logic. Instead, DICOM content is presumed
    to be handled by the DICOM viewer. Definition of the DICOM
    encapsulation of PDF will speed that along, at least to the extent that
    a specific MIME encoding internal to the object (application\pdf) will
    need to be supported. Once the launch of a PDF control is supported,
    presumably PDF will then be able to do the same thing for any
    additional MIME content encode internal to the PDF wrapper. I've just
    yet to see it. Will be one of the things I'm looking for at RSNA this
    year.


  3. Re: Storing patient care data: ECG, ventilators, blood pressure, etc

    Eric,

    I see that encapsulating a PDF allows storing any kind of content which
    will be easily human readble. That solves a big part of the problem.

    But I have a doubt: how will a computer access to these data for
    processing? PDF is not precise enough, is it?

    Is there a way of storing HL7 communications in a PACS, ("IHE Patient
    Care Devices Technical Framework") ?

    Thanks a lot,
    ivan

    eric.goodall@gmail.com wrote:
    > ivanet@gmail.com wrote:
    > > In our healthcare facility, we have been asked to give a solution to
    > > store patient care data (e.g. ECG, ventilators, blood pressure, etc),
    > > since we already store radiology and pathology images in our PACS.
    > >
    > > As far as I have seen, dicomizing ECG is possible, but other signals
    > > look more complicated (no SOP Classes defined in DICOM).

    >
    > There are native representations of ECG/EKG data in DICOM (waveform SOP
    > Classes) but there is also now SOP class for DICOM encapsulation of
    > PDF documents. So, literally any content which can be put into PDF,
    > scanned paper, pdf'ed word documents, video and audio files, etc can be
    > encapsulated into a DICOM wrapper. So what does this do for you? It
    > puts a DICOM SOP instance UID on the PDF file, allows association
    > with other , related digital content objects thru Series and Study
    > instance UIDs, provide searchable holder for patient id and
    > demographics data , and allows storage into a DICOM based PACS. Once in
    > a DICOM PACS, it can be queried and retrieved as is currently possible
    > with radiology, cardiology, pathology images. Also the IHE XDS-i
    > registration and retrieval methods come into play. The PDF
    > encapsulation has been around for a year or so now. I would expect to
    > start seeing it in commercial PACS products DICOM conformance
    > statements soon.
    >
    > Of more interest to me is seeing how the de-encapsulation process is
    > going to work in DICOM viewers. If you think about it, encapsulating
    > PDF inside of DICOM is sort of like putting a bicycle inside a formula
    > one race car (ok maybe more like in a NASCAR vehicle). The point being,
    > anybody can read PDF with a free and ubiquitious viewing app (acrobat
    > reader). The acrobat reader in turn honors the MIME encoding of data it
    > encapsulates. So, if a PDF has a quicktime or MP3 or AVI datastream
    > encapsulated in it, the acrobat reader will attempt to invoke the
    > MIME controls available on the viewing workstation to view the data.
    > Although there are lots of public domain/open source DICOM viewers out
    > there, most DICOM viewers, free or commercial, have yet to build that
    > sort of "open on the inside" logic. Instead, DICOM content is presumed
    > to be handled by the DICOM viewer. Definition of the DICOM
    > encapsulation of PDF will speed that along, at least to the extent that
    > a specific MIME encoding internal to the object (application\pdf) will
    > need to be supported. Once the launch of a PDF control is supported,
    > presumably PDF will then be able to do the same thing for any
    > additional MIME content encode internal to the PDF wrapper. I've just
    > yet to see it. Will be one of the things I'm looking for at RSNA this
    > year.



  4. Re: Storing patient care data: ECG, ventilators, blood pressure, etc

    Hi, Ivan -

    Unlike DICOM object instances, HL7v2 messages are not *persistent*;
    i.e., they convey data from one application to another, but once the
    data is received there is no expectation that there is any storage of
    the message itself.

    HL7v3 does have a persistent information object format, the Clinical
    Document Architecture (CDA). While the "attested content" of a CDA
    doument is human readable text, the format allows discrete data
    elements (e.g., numeric or coded obsevations) to be included. This
    would satisfy your requirement for computer access to the data
    elements. You could therefore capture your HL7v2 messages and
    transcode them into an appropriate CDA document for persistent storage.

    However, unlike PACS for DICOM, there is not a well developed market
    for devices that will archive and manage CDA documents. On the bleeding
    edge there are IHE XDS repostories and registries, which could be used
    inside your institution (rather than in the cross-enterprise
    environment). And you asked specifically about storing this data in
    your PACS.

    There is a DICOM Supplement just finishing Public Comment (Supplement
    114) that provides for encapsulation of CDA documents in a DICOM
    wrapper, simiar to encapsulation of PDF documents. Using that
    capability, the HL7v2 data would be transcoded into a CDA, then
    encapsulated in a DICOM wrapper, and stored in the PACS. As Eric
    noted, it will be interesting to see how PACS and DICOM workstations
    will handle the display of such encapsulated documents, but such
    capability should come to market fairly soon.

    I should mention two other alternatives. First, rather than
    transcoding the HL7v2 data to CDA, you could transcoded it into a DICOM
    Structured Report (SR) object (using a private template, since there is
    no standard template for this function). Each HL7 OBX should be able
    to be transcoded to an SR Content Item, perhaps with auxiliary
    Observation Context Content Items when needed. The SR objects could
    then be managed in the PACS like other SR evidence documents (see the
    IHE Evidence Documents Profile).

    A second alternative would be to stuff the HL7 message (without
    transcoding) into a private data element in a DICOM Raw Data object.
    This will allow your PACS to store the data, but since there is no
    inherent interoperability with private data elements, you would need
    to write any applications needed to process the data on retrieval from
    the PACS. With SR, Encapsulated CDA, or Encapsulated PDF, there is at
    least the possibility of multiple suppliers of display and processing
    applications.

    - Harry Solomon
    GE Healthcare

    ivanet@gmail.com wrote:
    > Eric,
    >
    > I see that encapsulating a PDF allows storing any kind of content which
    > will be easily human readble. That solves a big part of the problem.
    >
    > But I have a doubt: how will a computer access to these data for
    > processing? PDF is not precise enough, is it?
    >
    > Is there a way of storing HL7 communications in a PACS, ("IHE Patient
    > Care Devices Technical Framework") ?
    >
    > Thanks a lot,
    > ivan
    >



  5. Re: Storing patient care data: ECG, ventilators, blood pressure, etc

    Ivan -

    Sorry, in rereading your original post, it seems you are not even at
    the point of having the patient care data exchanged using HL7 messages.
    HL7 is indeed the standard for exchange of this data, but as I noted
    in my previous post, this is not a persistent format that could be
    readily stored in a PACS.

    - Harry


+ Reply to Thread