The first important piece of functionality I need to implement is the DICOM Verification Service Class (sect. A of PS3.4). This is a simple feature so this post won't go into too much depth. This service is used to verify DICOM connectivity between application entities by using the C-ECHO message. This "DICOM ping" differs from a normal ping in that the Application Entity Title is included as well as the IP and port.
Throughout my project, I will need to use emulated modalities to test functionality between clients and the PACS. By the end of the project deadline I will hopefully have implemented the REST based services which should allow me to pull scheduled procedures to my phone, acquire an image, and then push the image and associated procedure information back to the PACS. As I can't yet guarantee those features will be implemented for the submission I will instead (for now) opt to create a WPF application as the majority of my UI experience has been with this technology allowing me to quickly develop the clients necessary for testing.
As I'm only testing verification at this point, the only fields my mock modality require are IP, port, local AET, and remote AET. Testing my own client against my own server wouldn't be appropriate as a mistake in both applications could result in me wrongly assuming correct behaviour. Medical Connections provide a free DICOM server for developers to test DICOM conformance so I have used this to test my client.
Once the client functionality was verified, I then created my initial PACS service. For now I'm running the service from a console application which allows me to quickly see debug logs without needing to setup proper logging. Once I had the service created I tested using my client again, verifying conformance from both the client and server.
Throughout my project, I will need to use emulated modalities to test functionality between clients and the PACS. By the end of the project deadline I will hopefully have implemented the REST based services which should allow me to pull scheduled procedures to my phone, acquire an image, and then push the image and associated procedure information back to the PACS. As I can't yet guarantee those features will be implemented for the submission I will instead (for now) opt to create a WPF application as the majority of my UI experience has been with this technology allowing me to quickly develop the clients necessary for testing.
As I'm only testing verification at this point, the only fields my mock modality require are IP, port, local AET, and remote AET. Testing my own client against my own server wouldn't be appropriate as a mistake in both applications could result in me wrongly assuming correct behaviour. Medical Connections provide a free DICOM server for developers to test DICOM conformance so I have used this to test my client.
 |
| Results of verification client test |
Comments
Post a Comment