We've had several requests for a new data type to store medical images and we are now at a point in our research and design that we'd like to hear from our larger HealthVault community.  We've found that DICOM is the generally accepted format for storing medical images today so we've designed this data type to include structural and metadata similaities while limited the exposed data to what we believe is the most consumer friendly.

If you use DICOM today, those same images can be added to HealthVault in their native format using this data type.  All the metadata stored in a DICOM file remains intact for all systems to reuse with this approach.  By adding a level of structured XML that exposes some of this data, it allows for new and existing HealthVault applications to use the data without needing to fully parse the DICOM file or files.

There are a few scenarios we've targeted in the design of this data type:

  1. Systems generating medical images can now store those images in a patient's HealthVault record instead of creating a DVD, CD or other portable media. Today, when a patient requests a copy of their medical images from a CT, MRI, mamogram, etc, those images are burned to portable media which gets added to the shoebox of all the other studies the patient has requested.  The intent of this data type is to help replace that shoebox full of discs.
  2. The shoebox full of discs serves a purpose of being an electronic history of various studies that can be taken for a second opinion or further analysis.  For systems that understand medical images, they should also be able to understand medical images stored in HealthVault. 
  3. The consumer should be able to accurately transfer their existing medical images to their HealthVault record.  This new data type should be capable of storing all existing medical images that can be uploaded by a consumer.

We fully expect consuming applications to crack open the actual image files to get all the details of the study, series, but we hope that the defined schema will help make the decision on what to open a bit easier. 

The image data stored using this data type will be large in both quantity and size and our current XML storage approach doesn't optimize for binary content like images. To help mitigate this, HealthVault provides seperate binary storage we call blob storage (blobs).  Each instance of data in HealthVault can also include a blob of additional data and with the introduction of this data type, the HealthVault platform will support multiple named blobs per data instance. You'll find in this data type that we use blobs in a few places.  Specifically, blobs are used to store the set of medical images, a directory listing all blob names for the original images, a collection of key images, and a preview image for a study, series, and images. 

We have a few specific questions that we'd like your help in answering: 

  • The first is around the use of c-FIND.  In our research, we found that there are additional required elements for c-FIND that are perhaps less meaningful for consumers. If you use c-FIND today and/or have scenarios where it applies to HealthVault data, please let us know. We expect consuming applications to crack open the actual image files to get all the details of the study, series, but we hope that the defined schema will help make the decision on what to open a bit easier.
  • The second question is around XDS-i support.  We would like to hear from you if you currently use XDS-i and how you would plan to use this element in your HealthVault connected scenarios.
  • The last is whether the list of elements we have defined is the right set.  We've picked the ones we think are meaningful for consumers and that represent the data being stored.

Take a look and let us know what you think by using the Data Types forum

 

Medical Image Study type

A collection of medical images.  DICOM data is stored in the named blob portion of the data type, and it is recommended that normal DICOM conventions are used for naming. An application may store XDS-i manifest information in XML format in the xds-i element.

Element

Type

Occurrence

Description

when

date-time

1

The date and time the study was created. DICOM tags (0008,0020) and (0008,0030)

patient-name

string

0..1

The name of the patient as contained in the medical image. DICOM tag (0010,0010)

description

string

0..1

A description of the study. DICOM tag (0008,1030)

series

medical-image-study-series

1..N

A collection of series.

reason

codable-value

0..1

The reason for the study.  DICOM tag (0032,1030)

preview-blob-name

string

0..1

The name of the blob holding a smaller version of the image suitable for web viewing or email. For example jpeg.

key-images

medical-image-study-series-image

0..N

The important images in the study.

study-instance-uid

string

0..1

The study instance UID.  DICOM tag (0020,000D)

Medical Image Study Series

The details describing a specific series of images.

Element

Type

Occurrence

Description

acquisition-datetime

date-time

1

The date and time that the image was acquired. DICOM tag: (0008,0022), (0008,0032)

description

string

0..1

A description of the series. DICOM tag (0008,103E)

images

medical-image-study-series-image

1..N

The collection of images.

institution-name

organization

0..1

The name of the institution where the images were acquired. DICOM tag (0008,0080)

referring-physician

person

0..1

The physician who ordered the study. DICOM tag (0008,0090)

modality

codable-value

0..1

The method (or modality) in which the images were acquired. DICOM tag (0008,0060)

body-part

codable-value

0..1

The body part that was imaged. DICOM tag (0018,0015)

preview-blob-name

string

0..1

The name of the blob holding a smaller version of the image suitable for web viewing or email. For example jpeg.

series-instance-uid

string

0..1

The series instance UID.  DICOM tag (0020, 000E)

 

Medical Image Study Series Image

Information about a single image in a series.

Element

Type

Occurrence

Description

image-blob-name

string

1

The name of the blob holding the original data for this image.  DICOM tag (0008, 0018)

image-preview-blob-name

string

0..1

The name of the blob holding a smaller version of the image suitable for web viewing or email. For example jpeg.