1 / 35

XDStarClient

XDStarClient. Presentation of a suite of tools developed by IHE Europe for healthcare community Abderrazek Boufahja Mai 25, 2012. Menu. XDStar Functionality Systems Configuration Repositories configurations Registries configurations XCA RESP configurations epSOS

lev
Télécharger la présentation

XDStarClient

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 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

  4. Systems Configuration

  5. 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

  6. Repositories configurations • Repositories can be configured by going to the menu : • SUT Configurations  Repositories configurations • To add a new configuration, you have to login

  7. Registries configurations • Registries can be configured by going to the menu : • SUT Configurations  Registries configurations • To add a new configuration, you have to login

  8. 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

  9. epSOS

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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.

  17. 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 affinityDomainepSOS. To create the request, you have to fill some metadatas, and that depend to the transaction used.

  18. 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

  19. IHE / XDS

  20. 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 :

  21. 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”

  22. 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.

  23. Registry Stored Query [1] • Access from the menu : Simulators IHE  ITI-18 [RegistryStoredQuery]. • The registrystoredqueryis a set of messages types, thatcanbeselectedfrom the GUI

  24. 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 :

  25. 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

  26. 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

  27. 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

  28. 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”

  29. Cross Gateway Retrieve • Access from the menu : Simulators  IHE Cross Gateway Retrieve • Cross Gateway retrieveisbased on the transaction Retrieve Document Set. The GUI isalmost the same.

  30. WS Validation

  31. 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.

  32. 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

  33. EVSClient Validation [2] • The validation of the metadata contains two level : schema validation and content validation, based on model driven constraints.

  34. 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

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

More Related