It is RIDICULOUS to come up with another image format rather than support DICOM. What in the world is "Consumer Friendly." This is nonsense. WE DO NOT NEED ANOTHER PROPRIETARY FORMAT. It will only set back progress made in this field.

Can you please provide a visual model of how data might flow from PACS to Healthvault to PACS using DICOM? Thanks?

Keep the DICOM format it has the advantage to be universal

Would you propose a new format to take the jpeg place format for photographies ?

This looks like a good beginnning for handling the images.  But I would caution that any uptake/downloading/importing applications you design for the system just parse the DICOM header to fill in the blanks of you schema as it archives the images.  Making sure the DB you're using can keep the elmenents tracked is the basic essentials to any image management system.   It is possible to have such structured data only visible on the application layer to the consumer.  However, if a consuming system does request an image, it should be able to perform the same operation on the DICOM object for itself. Send the image, not the data type. This new data type should only be for functional operations w/in health vault and maintain the fidelity of the original objects.

DICOM overall is very robust in handling imaging sets. Don't reinvent this structure wheel that we're continuing to make improvements on.

If I understand the issue at hand here, your new data type is orthogonal to the issue of bandwidth and query performance. A lean and mean DICOM IOD can be defined for your uses.

Is Microsoft working on .NET assemblies to make development for HL7/DICOM much more developer friendly? If not, I would love to see this happen.

That looks like what Oracle people are doing with there DICOM object:

http://www.oracle.com/technology/obe/11gr1_db/datamgmt/dicom/dicom.htm

I would avoid copying DICOM fields other than UIDs fields as copying field imply you are actually able to read & interpret DICOM data properly, which can be tricky for DA type (think of old ACR NEMA 10byte DA field vs DICOM V3 8byte DA type).

Patient Name is also a pretty bad idea as it is a Type 1C in most SOP (read: it can be empty !). Worse in typical clinical trial environment it is being anonymized thus those system would not be able to cope with identical SOP Instance UID with different Patient Name.

I would only use UID to build a graph of relation (think PS object), I think Patient Name can only be used in some restricted environment type.

There is a lot of current software for visualizing DICOM images which is very useful. I use several daily in my practice. They usually work if the DICOM images are stored in a subdirectory as individual DICOM files and fail if not. All this software would have to re-written to use a CD/DVD created in your system which creates a new type of blob with the image directory to be parsed before these images can be viewed. This is a step backwards in terms of compatibility. DO NOT TRY TO SAVE SPACE WITH A BLOB. DISK SPACE IS CHEAP THESE DAYS. KEEP A SEPARATE DIRECTORY WITH ALL THE IMAGES IN ORIGINAL DICOM FORMAT.

DICOM WG27 is working right now on an extension to WADO, in order it to work as a web service. Other complementary web services will be defined for query and notification.

DICOM WG27, too, is defining a subset of atributes for easy reference to the binary information of the images.

Please contact Emmanuel Cordonnier, chair of this workgroup, in order to eventually reach a common subset used by WADO and by healthvault.

Are you planning on providing an integrated viewer that can parse and properly represent the original DICOM SOP classes? If so, will it support IHE CPI and GSPS and how will you deal with visualizing large data sets? If not, what is the good of storing the DICOM data in the first place if consumers cannot view it?

Storage is cheap, healthvault is envisioning an exceptionally large data, but this whole topic is orthogonal to the issue at hand. Data types are an engineering design decision, and generally have nothing to do with storage requirements.

DICOM dood raised the most important question - why store the images? Of course for viewing (by doctors). So why not just implement a scalable PACS with extensive access control management? you can then front end it with your "patient friendly" web pages, while maintain industry standard PACS access mechanisms.

In what format will you use for patient name?  

Will you support non-ASCII character sets?

If you support non-ASCII character sets, will HealthVault convert the name to UCS-16 or will the application be responsible for decoding it?

If the application is responsible will you also include the Specific Character Set tag (0008,0005) or will applications have to read the DICOM file to determine the patient name? (which will also affect other string parameters)

What about  East Asian character sets that also have ideographic and phonetic representations?

Are you only planning on storing images?  What about Structured Reports, GSPS?

Finally, I would recommend looking at what is stored in a DICOMDIR for the list of tags to replicate in your  study.  This will be what many viewers already support, and what users expect to find when selecting studies to open.

I would agree with Peter - DICOMDIR is probably a good place to start. Maybe ingest (or even create from scratch?) the DICOMDIR structure and find a way to create easy mapping between the blob name and the actual image file name? This could open the door for many viewers out there to be adapted to work with HealthVault with somewhat modest changes.