Http://dejarnette.com
A frequently asked customer question is, “how does xDL handle non-DICOM data?” The answer
is both simple and complex. The simple answer is that xDL will handle any non-DICOM data
from the perspective of an archive.
Non-DICOM data is any medical data that can be considered part of the electronic medical record. There are two problems with this type of data, how it is transported across a network and how the data is associated with information already existing in the archive so that it can be accessed and used logically.
There is no general purpose standard for communicating and requesting the storage and retrieval of medical documents other than XDS, which is not widely used today. As a consequence, the approach taken with xDL is to offer a number of options for the interface of such data producers and consumers. There are currently large numbers of systems in the field which provide for scanned documents encapsulated in a DICOM object. Similarly a common mechanism amongst hospital IT departments is to use HL7 to communicate “documents” that are outside the normal workflow. Both of these mechanisms require agreement between the different vendors providing systems to the customer as they are non-standard usages, generally. The xDL allows the use of all three of these transport methodologies XDS, HL7 and DICOM to provide the most compatibility with today’s existing equipment.
The use of the transports mandates data that allows the archive to associate the medical data with existing data within the archive. Patient level data is the minimum required by the archive to associate data and this is the minimum provided by all of the aforementioned transports. It should be noted that simple file transport methodologies such as CIFS or NFS do provide a common transport methodology but they do not allow any metadata to be associated with the storage. This is acceptable for a simple archive but not acceptable for an archive that is designed to associate like data together.
Non-DICOM data can be presented to the xDL for storage as a DICOM encapsulated document, a document presented within an HL7 message or an XDS document. Non-DICOM data today can be retrieved as a DICOM encapsulated document, a document within an HL7 message or as an XDS document. All non-DICOM data, unless it is presented as an XDS document, is stored as a DICOM object. Sufficient context information must be supplied via DICOM or HL7, to associate the document with a patient. XDS is guaranteed to provide sufficient context information.
As an XDS Repository any XDS document can be stored to and retrieved from xDL. The xDL does not need to interpret or “understand” this data in order to store it. Today, there are few devices that support the XDS profile, but that list will grow in the future. If the XDS document is a DICOM document then it is also possible to retrieve it via DICOM or HL7, to the extent that retrieval makes sense.
xDL also has the ability to store and retrieve non-DICOM data that is included as part of an HL7 message. For instance it is possible to store PDF, JPEG, TIFF and other image types in the xDL via HL7. This is a particularly flexible method to store non-DICOM data as the core of the company’s HL7 messaging technology is the ERI. ERI (external record interface) is a general purposes message parsing and generation facility that is driven by a customization file. The customization file allows for customization through “scripting”. The ERI is built upon the company’s 20+ years of experience in providing HL7 interfaces to the medical imaging world. It is possible to not only perform text data manipulation but also image format conversion.1
Non-DICOM data is any medical data that can be considered part of the electronic medical record. There are two problems with this type of data, how it is transported across a network and how the data is associated with information already existing in the archive so that it can be accessed and used logically.
There is no general purpose standard for communicating and requesting the storage and retrieval of medical documents other than XDS, which is not widely used today. As a consequence, the approach taken with xDL is to offer a number of options for the interface of such data producers and consumers. There are currently large numbers of systems in the field which provide for scanned documents encapsulated in a DICOM object. Similarly a common mechanism amongst hospital IT departments is to use HL7 to communicate “documents” that are outside the normal workflow. Both of these mechanisms require agreement between the different vendors providing systems to the customer as they are non-standard usages, generally. The xDL allows the use of all three of these transport methodologies XDS, HL7 and DICOM to provide the most compatibility with today’s existing equipment.
The use of the transports mandates data that allows the archive to associate the medical data with existing data within the archive. Patient level data is the minimum required by the archive to associate data and this is the minimum provided by all of the aforementioned transports. It should be noted that simple file transport methodologies such as CIFS or NFS do provide a common transport methodology but they do not allow any metadata to be associated with the storage. This is acceptable for a simple archive but not acceptable for an archive that is designed to associate like data together.
Non-DICOM data can be presented to the xDL for storage as a DICOM encapsulated document, a document presented within an HL7 message or an XDS document. Non-DICOM data today can be retrieved as a DICOM encapsulated document, a document within an HL7 message or as an XDS document. All non-DICOM data, unless it is presented as an XDS document, is stored as a DICOM object. Sufficient context information must be supplied via DICOM or HL7, to associate the document with a patient. XDS is guaranteed to provide sufficient context information.
As an XDS Repository any XDS document can be stored to and retrieved from xDL. The xDL does not need to interpret or “understand” this data in order to store it. Today, there are few devices that support the XDS profile, but that list will grow in the future. If the XDS document is a DICOM document then it is also possible to retrieve it via DICOM or HL7, to the extent that retrieval makes sense.
xDL also has the ability to store and retrieve non-DICOM data that is included as part of an HL7 message. For instance it is possible to store PDF, JPEG, TIFF and other image types in the xDL via HL7. This is a particularly flexible method to store non-DICOM data as the core of the company’s HL7 messaging technology is the ERI. ERI (external record interface) is a general purposes message parsing and generation facility that is driven by a customization file. The customization file allows for customization through “scripting”. The ERI is built upon the company’s 20+ years of experience in providing HL7 interfaces to the medical imaging world. It is possible to not only perform text data manipulation but also image format conversion.1
Through “scripting”2, data manipulation and format conversion can occur either on the way into
xDL or the way out of xDL.
Table 1 below shows the various combinations of how non-DICOM data can be acquired, stored and retrieved.
Table 1
Today, most non-DICOM document interfaces are achieved through the described methods. It is envisioned that improved workflow and data quality can be achieved by more tightly coupling the xDL to non-DICOM data producers. For this reason, the company is to bring to market a general purpose non-DICOM Document Acquisition/QC station. The company has in the past developed and marketed acquisition stations for acquiring non-DICOM images and conversion to DICOM or other imaging standards.
Table 1 below shows the various combinations of how non-DICOM data can be acquired, stored and retrieved.
Table 1
Today, most non-DICOM document interfaces are achieved through the described methods. It is envisioned that improved workflow and data quality can be achieved by more tightly coupling the xDL to non-DICOM data producers. For this reason, the company is to bring to market a general purpose non-DICOM Document Acquisition/QC station. The company has in the past developed and marketed acquisition stations for acquiring non-DICOM images and conversion to DICOM or other imaging standards.
Storage Method
|
Storage Format
|
Retrieval Method
|
|||
DICOM
|
HL73
|
XDS
|
WADO
|
||
DICOM Encapsulation
|
DICOM
|
Y
|
Y
|
Y
|
Y
|
XDS DICOM Document
|
DICOM
|
Y
|
Y
|
Y
|
Y
|
XDS non-DICOM
Document
|
XDS
|
N
|
N
|
Y
|
N
|
HL74
|
DICOM
|
Y
|
Y
|
Y
|
Y
|
1 As xDL projects are deployed, the number and type of “off the shelf” data conversions increases. The development of these conversions is driven entirely by sales. Development and deployment of these conversion scripts are generally quick and safe, with regards to effect on the rest of the xDL system.
2 Perl is the primary scripting language used by the ERI. 3 Data manipulation is available at time of retrieval.
4 Data manipulation is available at time of storage.
2 Perl is the primary scripting language used by the ERI. 3 Data manipulation is available at time of retrieval.
4 Data manipulation is available at time of storage.
No comments:
Post a Comment