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

Medical Image Study Series

The details describing a specific series of images.

Medical Image Study Series Image

Information about a single image in a series.