XdsObjects is a toolkit to allow developers to develop applications using the IHE XDS and XDS-I profiles, with minimal investment in time and effort, since all the hard work of complying with the profile and ebXML rules is handled by the toolkit.
It provides both client and server support for all roles, including (as of version 6.1) for acting as a registry.
The best way to get started is to use the examples on the web at: http://www.medicalconnections.co.uk/xds-objects-net, but here is some general guidance about the structure of the objects:
This is the key to using XdsObjects, and hold vital global information such as:
- The registry URI
- The list of repositories and how they may map from their OIDs
- The audit repositories to use
- The "global" patient root OID
- The repository to submit newly created data to
Your main work will revolve around constructing an
XdsSubmissionSet object and populating with properly completed
XdsDocument objects, tthen using
XdsDomain.ProvideAndRegsiterDocumentSet to submit to the chosen repository.
Your main work will revolve around constructing
XdsQuerrequest objects and submitting them to the registry. It is important to have the OID to repository mappings completed for retrieval
Due to the way that Windows works, it is necessary to use 2 different classes to handle the incoming data -
- transactions with "bulk" data such as ProvideAndRegister uses the MTOM encoding, and you use the XdsMtomServer Class
- transactions without "bulk" data such as registry queries use the XdsSoapServer Class
Nauturally, this is a combination of the above
This is possible both as client and server, using the
XdsImagingClient Class and
XdsImagingServer Class respectively. See
Use With DicomObjects for details of how it may be handled with or without DicomObjects.
This is only a brief outline, and the examples ar ethe best starting point, but if you have any questions, contact support@medicalconnections.co.uk