In my recent blog about the Standards Work Ahead in 2012, I called DICOM a non-standard standard.
This generated numerous email messages, phone calls, and blog comments.
Let me clarify what I meant.
DICOM is a great standard that has unified many processes within organizations, linking radiology modalities and PACS systems.
Why do I believe additional work is needed?
In December, my wife visited a hospital near our home for a diagnostic mammogram. It was clear she needed followup care with a cancer care team. We decided that Beth Israel Deaconess would be ideal because of its electronic health records and personal health records that would help Kathy coordinate her care. We asked for the images to be transmitted to BIDMC and we were told that we needed to visit the radiology department Monday-Friday 9am-5pm for a CD to be created so that Kathy could drive is 20 miles to BIDMC. The CD contained a proprietary viewer that required Windows and hence was not visible on our home computers (all Mac OSX).
What would have happened in an ideal world?
1. An implementation guide for DICOM would specify required vendor neutral content - a basic set of metadata (patient identifiers, name of the radiology study, imaging techniques used etc.) that would work with any viewer - Siemens, Agfa, Philips, GE, Kodak, etc. Any vendor specific/proprietary metadata would be stored separately from the required basic content, so that extensions do not impact generic viewers. CDs with proprietary viewers and media formats should become a thing of the past.
2. DICOM combines content and transport in a single standard. Although that is create for communication within an organization, it is not sufficient for a healthcare information exchange world that uses the Direct implementation guide (SMTP/SMIME, XDR) for content exchange among organizations. The fact that vendors such as LifeImage, Accelarad, and Merge Healthcare have created their own image sharing networks suggests that more standards work is needed to create an open ecosystem of image sharing among organizations.
3. We should not require organizations who want to receive images to have PACS systems. Instead, EHRs with vendor neutral DICOM viewers should be able to incorporate DICOM content sent via Direct into patient records.
Thus our work on imaging standards should build upon the DICOM foundation we have today, but eliminate optionality for a basic set of metadata, ensure that any proprietary extensions to metadata do not interfere with vendor-neutral viewing, embrace simple transport approaches for cross organizational exchange, and enable even the simplest of EHRs to be participants in image exchange.
We'll do this work in the Healthcare IT Standards Committee from April to June, engaging the industry experts who have worked so hard on DICOM to date.
I hope that makes sense!
This generated numerous email messages, phone calls, and blog comments.
Let me clarify what I meant.
DICOM is a great standard that has unified many processes within organizations, linking radiology modalities and PACS systems.
Why do I believe additional work is needed?
In December, my wife visited a hospital near our home for a diagnostic mammogram. It was clear she needed followup care with a cancer care team. We decided that Beth Israel Deaconess would be ideal because of its electronic health records and personal health records that would help Kathy coordinate her care. We asked for the images to be transmitted to BIDMC and we were told that we needed to visit the radiology department Monday-Friday 9am-5pm for a CD to be created so that Kathy could drive is 20 miles to BIDMC. The CD contained a proprietary viewer that required Windows and hence was not visible on our home computers (all Mac OSX).
What would have happened in an ideal world?
1. An implementation guide for DICOM would specify required vendor neutral content - a basic set of metadata (patient identifiers, name of the radiology study, imaging techniques used etc.) that would work with any viewer - Siemens, Agfa, Philips, GE, Kodak, etc. Any vendor specific/proprietary metadata would be stored separately from the required basic content, so that extensions do not impact generic viewers. CDs with proprietary viewers and media formats should become a thing of the past.
2. DICOM combines content and transport in a single standard. Although that is create for communication within an organization, it is not sufficient for a healthcare information exchange world that uses the Direct implementation guide (SMTP/SMIME, XDR) for content exchange among organizations. The fact that vendors such as LifeImage, Accelarad, and Merge Healthcare have created their own image sharing networks suggests that more standards work is needed to create an open ecosystem of image sharing among organizations.
3. We should not require organizations who want to receive images to have PACS systems. Instead, EHRs with vendor neutral DICOM viewers should be able to incorporate DICOM content sent via Direct into patient records.
Thus our work on imaging standards should build upon the DICOM foundation we have today, but eliminate optionality for a basic set of metadata, ensure that any proprietary extensions to metadata do not interfere with vendor-neutral viewing, embrace simple transport approaches for cross organizational exchange, and enable even the simplest of EHRs to be participants in image exchange.
We'll do this work in the Healthcare IT Standards Committee from April to June, engaging the industry experts who have worked so hard on DICOM to date.
I hope that makes sense!
Comments
Post a Comment