|
|
 |
| DICOM Validation: |
|
|
It is often important to make sure that one can inspect the actual information that is
exchanged ("Seeing is believing"), which is a requirement in case there indeed is a
particular connectivity issue that needs to be addressed. That leads us to the so-called
Validation. In this case, a test tool or suite that allows the information to be inspected,
captures the output of the device. There are two methods: visual inspection and automatic
inspection. The automatic inspection checks the information as sent with the requirements
in the standard, it is an automatic "DICOM checker". Items that are being checked are the
presence of all required information, the validity of attributes according to the DICOM
specification such as length, format, etc. A visual inspection is usually recommended
as well, because the DICOM checker is not always full proof, i.e. even if it passes the
checker, there can be some hidden issues. A good example is the format of the
Patient Name, one can fill in the first name and last name as one unit (e.g. Smith, John),
which is legal according to DICOM, which could be encoded as a last name without a
separator. A query to a database for last name "Smith" would not match on this specific
record with as (incorrect) last name "Smith, John". The information for this visual
inspection is therefore printed or displayed in a readable format so that an experienced
person can verify the information.
Validation services are available from our consultants, we can dial in remotely to your
institution to perform the validation, or do it on-site. This is recommended when there
is "fingerpointing" between vendors to solve a particular interface issue, or as part of
an acceptance test procedure for new purchases. We also license our test suite and can
train you how to use it yourself ,so you can perform your in-house testing and validation.
In most cases, these users have a retainer contract with us for back-up technical support
and difficult questions and issues.
|
| |
| |
| DICOM Verification: |
 |
|
This is what is its title says: it is the verification of the DICOM conformance specification
of a specific device with another device, or against a set of requirements such as
published by the DOD, VA or OTech/SG&A; Consulting. This method is well suited for a first
pass, i.e. to determine whether or not there are some major issues. For example, if a
device is required to use DICOM Print using a networked connection, this will be clearly
specified in the conformance statement. If this is a requirement for your institution,
this can be clearly identified based in the documentation available. In addition,
details such as, for example, the availability of specific image header attributes that
might be important for your institution such as the Patient Birth Date or Radiology order
(Accession number) can be identified as well.
A comprehensive analysis of your installed base, and/or potential new purchases, based on
your specific requirements, is called a DICOM "Gap-analysis", and can also be provided
by our consultants.
|
| |
| |
| DICOM Conformance: |
|
|
(Please click here to go to our DICOM Conformance Database page.)
Each institution has its own specific requirements. Conformance can be defined according
to "use profiles" based on certain use and functionality. For example, a device in an
outpatient clinic might only be sending its mages to the main hospital, without ever needing
to review any of the previous exams, and/or having to ever print images using a networked
printer. In that specific case, the so-called Basic use profile might be sufficient. Other
institutions who use a digital modality, such as a CT or MRI, in its main radiology
department which needs to be totally integrated with their PACS/imaging system, want to
make sure all the patient information can be automatically retrieved, status information
with the PACS system be exchanged, images printed to a networked printer, etc. In that case,
a different, more extended, use profile is required.
There are DICOM conformance requirements available from the Department of Veterans Affairs
(VA) for digital modalities, Department of Defense, for a PACS system, and generic
requirements from OTech/SG&A; consulting.
Using a generic set of requirements is not necessarily the most effective. It is highly
recommended to develop and specify the specific requirements for your institution so they
can be used as the basis for future PACS/modality equipment, contact us if you like
additional information on how we can help you generating yours.
|
| |
| |
|
|
