XDStarClient
Presentation of a suite of tools
developed by IHE Europe for
healthcare community
Abderrazek Boufahja
Mai 25, 2012
Menu
•
•
XDStar Functionality
Systems Configuration
–
–
–
•
epSOS
–
–
–
•
DispensationService:initialize()
ConsentService:put()
epSOS-1 transaction
IHE /XDS
–
–
–
–
–
•
Repositories configurations
Registries configurations
XCA RESP configurations
Provide and register Set-b
Registry Stored Query
Retrieve Document Set
Cross Gateway Query
Cross Gateway Retrieve
WS Validation
–
–
XDStar ws validation
EVSClient validation
XDStar functionality
• XDStarClient is a tool based on IHE / epSOS specifications
for XDS transactions
• Fonctionalities :
– Simulation of epSOS transactions (PatientService, OrderService,
ConsentService, IdentificationService)
– Simulation of IHE / XDS transactions (Provide and Register Set-b,
Registry Stored Query, Retrieve Docuement Set, Cross Gateway
Query, Cross Gateway Retrieve)
– Validation of all transactions done by the tool
– WS validation of epSOS/ IHE XDS metadatas
Systems Configuration
Systems configurations
There are three type of configurations supported by
XDStar :
• Repositories configurations
• Registries configurations
• XCA Responding Gateway configurations
The configurations of Document recipient for XDR
profile are integrated to the repositories
configurations
Repositories configurations
• Repositories can be configured by going to the menu :
– SUT Configurations  Repositories configurations
– To add a new configuration, you have to login
Registries configurations
• Registries can be configured by going to the menu :
– SUT Configurations  Registries configurations
– To add a new configuration, you have to login
XCA RESP configurations
• Registries can be configured by going to the menu :
– SUT Configurations  XCA-Responding-Gateway-Configurations
– To add a new configuration, you have to login
epSOS
DispensationService:initialize()[1]
•
How to access : menu  Simulators  epSOS 
DispentationService:initialize()
•
•
Configurations that can be selected : Repositories configurations
Optionality :
–
–
Upload files to register : upload one or many dispensation document to be sent to the
repository
Generate file to register : use a preloaded document from the server, and sent it to the
repository
DispensationService:initialize()[2]
• Metadatas :
–
–
–
–
XDSSubmissionSet.author
XDSSubmissionSet.contentTypeCode
XDSSubmissionSet.patientId
XDSSubmissionSet.sourceId : its value is defined as a parameter of the
application
– XDSSubmissionSet.uniqueId : a unique id generated by the application for
the SubmissionSet
• For this transaction, this simulator support :
– XUA : insert of assertions
– ATNA : secure communication
DispensationService:initialize()[3]
• Sending of the documents : you can send your documents by
clicking on the button Execute. The execution generate a
message that contains the date of execution, the transaction
name, the affinity domain, the message type, the response
code, the responder name, and finally the request and the
response and their validations
• The list of validated message can be found on the menu :
messages  Provide and Register Set-b messages
DispensationService:initialize()[4]
•
There are two buttons that can be used, on the column action :
view the content of the metadatas sent, and the response of the repository
validate the content of metadatas sent and validate the response
•
There are three buttons on request/resp messages columns :
– Validation is not well, there are errors on validation
– Validation is well done, no errors on the validation
– There are no validation done, if you want you can do one, by clicking here
ConsentService:put()[1]
•
•
•
•
How to access : menu  Simulators  ConsentService:put()
Configurations that can be selected : Repositories configurations
Policy : Opt-in, Opt-out
Optionality :
– Upload files to register : upload one or many consent document to be sent
– Generate file to register : use a preloaded document from the server, and sent it
ConsentService:put()[2]
• Metadatas :
–
–
–
–
XDSSubmissionSet.author
XDSSubmissionSet.contentTypeCode
XDSSubmissionSet.patientId
XDSSubmissionSet.sourceId : its value is defined as a parameter of the
application
– XDSSubmissionSet.uniqueId : a unique id generated by the application for
the SubmissionSet
• For this transaction, this simulator support :
– XUA : insert of assertions
– ATNA : secure communication
ConsentService:put()[3]
• As for DispensationService:initialize(), the
ConsentService:put() has the same behavior for executing
the sent of the message to the repository, the GUI of the
messages sent and received. We can also validate these
messages using the button validate from the action
column.
epSOS-1 transaction [1]
• epSOS-1 transaction is composed from 4 types of message types :
–
–
–
–
OrderService:list
OrderService:retrieve
PatientService:list
PatientService:retrieve
• OrderService:list and PatientService:list are the transaction ITI-38
on the affinityDomain epSOS. To create the request, you have to
fill some metadatas, and that depend to the transaction used.
epSOS-1 transaction [2]
• On the PatientService:retrieve and the OrderService:retrieve,
the user have to fill the homeCommunityId, the repositoryId, and
the uniqueId of the document to retrieve.
• All the four messageType support XUA and ATNA, secured
endpoint are supported
IHE / XDS
Provide and register Set-b[1]
• How to access from menu : Simulators  IHE  ITI-41 [Provide
and Register Set-b]
• The aim of this page is to provide for the user a tool to submit
folders and XDSDocuments to a repository with the correct
association between SubmissionSet, folders, && documents.
• After selecting a repository, a tree representing the content of
the submission appears in the GUI :
Provide and register Set-b[2]
•
To add document to a submissionSet or to a folder, you have to click
on the button . This will update the GUI and view a list of metadatas
related to the XDSDocumentEntry added
•
To add a new folder to a submissionSet, you have to click on the button
. This will update the GUI with metadatas of the XDSFolder added.
•
The list of metadatas that the user can choose are uploaded by the tool
from the SVS repository of IHE europe.
•
To add optional metadatas, you have to click on the button “Add
Optional Metadata”
Provide and register Set-b[3]
• To execute the submissionSet, you have to click on the button
Execute
• The result of the execution appears on the GUI as a table
containing the request, the response, and the response code.
• To validate the request || the response, you have to click on the
button validate on the action column. A popup will show the
result of the validation.
Registry Stored Query [1]
• Access from the menu : Simulators IHE  ITI-18 [Registry
Stored Query].
• The registry stored query is a set of messages types, that can
be selected from the GUI
Registry Stored Query [2]
• To create an ITI-18 query, the user have to fill the list of
metadata generated from the messageType selected :
• To add optional parameter to the request, you have to click on
the button addOptionalParameter :
Retrieve Document Set[1]
• How to access from menu : Simulators  IHE  ITI-43
[Retrieve Document Set]
• To execute the request you have to select a repository
configuration
Retrieve Document Set[2]
• Retrieve Document Set is a simple request based on three
parameters : HomeCommunityId, RepositoryUniqueId, and
DocumentUniqueId
• To
• To Execute the retrieve request, you have to click on Execute
• You can preview the message to be sent by clicking on Preview
Cross Gateway Query[1]
•
•
Access from the menu : Simulators IHE  Cross Gateway Query
From the GUI, we have to select first the registry configuration, then we
have to select the message type to execute
Cross Gateway Query[2]
• For each messageType, a list of required metadatas are
rendered on the GUI
• To add optional metadata, you have to click on the button “Add
Optional Parameter”
Cross Gateway Retrieve
•
•
Access from the menu : Simulators  IHE Cross Gateway Retrieve
Cross Gateway retrieve is based on the transaction Retrieve Document
Set. The GUI is almost the same.
WS Validation
WS Validation
• Link :http://gazelle.ihe.net/XDStarClientWS/XDSMetadataValidatorWS?wsdl
•
Methods :
–
–
–
–
•
validateXDStarMetadata : validate a text document using a type of validator
validateXDStarMetadataB64 : validate a base 64 document using a type of validator
getListEPSOSValidator : return a list of validators for epSOS domain
getListIHEValidator : return a list of validator for IHE domain
Technologies : XDS validation is based on model driven architecture. We
define a model to describe the content of the XDS metadata document, then
we populate the model by UML constraints, using OCL language (Object
Constraint language). Constraints are extract from the TF of IHE && epSOS.
EVSClient Validation [1]
•
The WS of XDStarClient is used by EVSClient to validate epSOS / IHE
XDS metadata. To Access to this validator from EVSClient menu, you
have to go to XDS  epSOS / IHE  validate
EVSClient Validation [2]
• The validation of the metadata contains two level : schema
validation and content validation, based on model driven
constraints.
EVSClient Validation [3]
• All validated metadata request / response are stored on the
database. An advanced search tool is implemented for users for
dynamic search of already validated documents
XDStarClient
Presentation of a suite of tools
developed by IHE Europe for
healthcare community
Abderrazek Boufahja
Mai 25, 2012