Navigation path

GITB TRR

(
 
)
5/5 | 3 votes

Available Translations

Available Translations:

Description

The Test Registry and Repository (TRR) is aimed at supporting Test Beds for managing, archiving and sharing distributed Test Artefacts. The TRR is also used as a long-term archival platform for Test Resources.

 

The TRR contains Test Resources that are:

  • Actual Test Artefacts
  • References to Test Artefacts contained in other systems (for example in instances of Test Bed, or in instances of other repositories)
  • References to Test Beds and Test Tools 

In Joinup, a Test Resource is a particular Interoperability Solution and can be of one of the following types.

Type of Test Resource

Short description

Test Bed

consists of a test execution environment for Test Suites and the functionalities required for conformance and/or interoperability testing
Test Case
an executable unit of verification and/or of interaction with an SUT, corresponding to a particular testing requirement, as identified in an eBusiness Specification
Test Suite
defines a workflow of Test Case executions and/or Document Validator executions
Test Assertion 
a testable or measurable expression - usually in plain text or with a semi-formal representation - for evaluating the adherence of an implementation (or part of it) to a normative statement in a specification
Document Assertion Set a package of artefacts used to validate a Business Document, typically including one or more of the following: a schema (XML), consistency rules, codelists, etc. These artefacts are generally machine-processable
Messaging Adapter
specialized for messaging protocol stacks such as ebXML Messaging, Web Services with SOAP or REST, AS2, and the underlying transports: SMTP, HTTP, etc.
Document Validator
responsible for validating the content of the documents retrieved from the Messaging Adapters in terms of both structure and semantic such as EDI: ANSI, EDIFACT, XML

 

The TRR features are similar to the features of a registry and a repository, where storage, retrieval and search are the main features. In the TRR, actual Test Resources and their reference can be created, modifed and deleted as well as they can be searched. 

 

A typical search to which the TRR will answer is:

  • Which Test Resources are available for a specific context and a specific testing purpose?

  • Context = Industry A, Country B, e-business specification C, role D (an actor in the e-business specification)

  • Testing purpose = validation or simulation

Available documentation:


Interoperability SolutionsHide more information

The objective of this Test Scenario is to ensure the Sender Access Point (the System Under Test) is capable of querying both SML and SMP as well as submitting a conformant PEPPOL BIS 4A electronic invoice to a Receiver Access Point using the AS2 protocol. Then submitted document is validated by UBL 2.1 schema and PEPPOL Schematron rules.

The objective of this Test Scenario is to ensure the Sender Access Point (the System Under Test) can submit a conformant PEPPOL BIS 3A electronic order to a Receiver Access Point using the AS2 protocol. Then submitted document is validated by Validex.

The objective of this Test Scenario is to ensure the Sender Access Point (the System Under Test) can submit a conformant PEPPOL BIS 4A electronic despatch advice to a Receiver Access Point using the AS2 protocol. Then submitted document is validated by Validex.

The objective of this Test Scenario is to ensure the EDI Receiver (the System Under Test) can receive a default conformant EDI Invoice from a simulated EDI Sender over the OFTP2 protocol.

The objective of this Test Scenario is to ensure the EDI Receiver (the System Under Test) can receive an uploaded EDI Invoice document over the OFTP2 protocol.

The application External Validation Service Front-End can be used for validating the following objects:

  • HL7 CDA files
  • HL7v2.x and HL7v3 messages
  • HPD messages
  • SVS messages
  • DSUB metadata
  • SAML assertions
  • Audit messages
  • Certificates
  • DICOM objects
  • PDF files
  • XD* messages (metadata)
  • XDW documents

GazelleHL7Validator is dedicated to the validation of HL7 message through SOAP web service calls. For further information read documentation at http://gazelle.ihe.net/content/GazelleHL7v2Validator

If you'd like to perform the validation of HL7 messages through a web interface, please visit http://gazelle.ihe.net/EVSClient

 

Gazelle CDA Validation Service offers a web service for the validation of CDA document according to the definition of CDA document in the Realm of IHE,  epSOS, and various national projects

 

The web services url is : http://131.254.209.20:8080/CDAGenerator-CDAGenerator-ejb/CDAValidatorWS?wsdl

Gazelle Test Management is a web application for the management of Interoperability Test Session. 

The test bed is used by IHE for the Connectathon, by epSOS for the projectathon. 

Many users in Europe, US and Asia

Many regional/national projects worldwide are deploying/specifying the sharing of medical document using an infrastructure based on the IHE XDS.b suite of profiles. We are proposing in this test suite to share the tests artifacts that could be common for all these projects, the XDS.b part of the exchange.
 
Bourquard Karima
Posted by Bourquard Karima on October 13, 2015 at 9:58
"

Very useful tools for those are implementing XDS, Patient Summaries and other medical documents based on CDA without forgetting other messages !

Gazelle management tool is also very efficient for test sessions.

Metadata

Type: Repository
Owner:
Metadata upload module: Manual
Date created: 17 Aug 2015 - 08:19
Date last modification: 9 Nov 2015 - 16:23
Validate:

Statistics & Metrics

  • Reads:
  • 1896
  • Members:
  • 2
  • Solutions:
  • 40
  • Communications:
  • 1
  • Downloads:
  • 28