XDStarClient Presentation of a suite of tools developed by IHE Europe for healthcare community Abderrazek Boufahja Mai 25, 2012

Menu XDStar FunctionalityXDStar Functionality Systems ConfigurationSystems Configuration –Repositories configurations –Registries configurations –XCA RESP configurations epSOSepSOS –DispensationService:initialize() –ConsentService:put() –epSOS-1 transaction IHE /XDSIHE /XDS –Provide and register Set-b –Registry Stored Query –Retrieve Document Set –Cross Gateway Query –Cross Gateway Retrieve WS ValidationWS Validation –XDStar ws validation –EVSClient validation

XDStar functionality XDStarClient is a tool based on IHE / epSOS specifications for XDS transactionsXDStarClient is a tool based on IHE / epSOS specifications for XDS transactions Fonctionalities :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 configurationsRepositories configurations Registries configurationsRegistries configurations XCA Responding Gateway configurationsXCA 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 :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 :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 :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()How to access : menu  Simulators  epSOS  DispentationService:initialize() Configurations that can be selected : Repositories configurationsConfigurations that can be selected : Repositories configurations Optionality :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 :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 :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 validationsSending 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 messagesThe 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 :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 view the content of the metadatas sent, and the response of the repository validate the content of metadatas sent and validate the response validate the content of metadatas sent and validate the response There are three buttons on request/resp messages columns :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()How to access : menu  Simulators  ConsentService:put() Configurations that can be selected : Repositories configurationsConfigurations that can be selected : Repositories configurations Policy : Opt-in, Opt-outPolicy : Opt-in, Opt-out Optionality :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 :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 :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.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 :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.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.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 supportedAll 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]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.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 :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 addedTo 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.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.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”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 ExecuteTo 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.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.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].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 GUIThe 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 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 :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]How to access from menu : Simulators  IHE  ITI-43 [Retrieve Document Set] To execute the request you have to select a repository configurationTo 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 DocumentUniqueIdRetrieve Document Set is a simple request based on three parameters : HomeCommunityId, RepositoryUniqueId, and DocumentUniqueId ToTo To Execute the retrieve request, you have to click on ExecuteTo Execute the retrieve request, you have to click on Execute You can preview the message to be sent by clicking on PreviewYou can preview the message to be sent by clicking on Preview

Cross Gateway Query[1] Access from the menu : Simulators  IHE  Cross Gateway QueryAccess 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 executeFrom 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 GUIFor 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”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 RetrieveAccess 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.Cross Gateway retrieve is based on the transaction Retrieve Document Set. The GUI is almost the same.

WS Validation

Link : : Methods :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.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  validateThe 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.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 documentsAll 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