open-discussion > HealthVault Data Types : Microsoft feedback
Showing 1-1 of 1 posts
Jul 22, 2009 01:07 PM | Luis Ibanez
HealthVault Data Types : Microsoft feedback
Subject: Medical Image Data Type in HealthVault - looking for feedback
Date: Mon, 13 Jul 2009 18:04:22 -0700
From: Khan Siddiqui
To: Khan Siddiqui
Hi,
The HealthVault team has posted the initial draft design for medical image data type to their data type blog. Please visit http://blogs.msdn.com/healthvaultdatatyp... and give them feedback.
Regards,
Khan
Khan M. Siddiqui, MD | Principal Program Manager | Medical Imaging
Health Solutions Group | Microsoft Corporation
5404 Wisconsin Ave | Suite 600 | Chevy Chase, MD, 20815
Office: (301) 771-8568 | Mobile: (443) 847-5106 | Fax: (301) 771-8184
[cid:image001.png@01CA03F0.24921BF0]
khan.siddiqui@microsoft.com | http://www.microsoft.com/hsg
-------------------------------------------------
For Review: Medical Image Study
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.
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. The data type design below includes a single element for all XDS-i information you might want to include with a medical image study. It uses the anyType definition so you are not limited to a single schema. We would like your feedback on how you are planning to use this element in your scenario so we can better determine if this design is sufficient.
*
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.
http://social.msdn.microsoft.com/Forums/...