Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Overview:

This project is used for testing Document Query (DQ) service in multiple scenarios by passing document entry (Stable,Dynamic,Both or None ) in XDSDocEntryType, Invalid creation time in XDSDocumentEntryCreationTimeFrom and  XDSDocumentEntryCreationTimeTo of request message. It is accomplished by processing Document Query request message by passing test case specific home community id in NHIN target communities.  In order to do DQ, it is required to have patient correlation and aa_to_home_community mapping entry in database. There is a script in each test case which will clear and insert required test data in patientcorrelationdb.correlatedidentifiers , assigningauthoritydb.aa_to_home_community_mapping tables. Each On-Demand document entry describes what type of content will be returned in response. Below described briefly about On-Demand document entry types.

Testing will be done in standard mode.  

XDS Document Entry Types :

There are two XDS document entry types that can be passed as part of Document Query request in XDSDocumentEntryType slot element.

  • XDS Stable Document Entry: A stable document entry contains metadata about an already created document available for retrieval. This document is stable because the contents have been effectively combined in the exact representation that will be returned in a Retrieve Document Set. OnDemand flag set to "0" for stable documents in docrepository.document table.
  • XDS On-Demand Document Entry: An On-demand document entry contains metadata describing the characteristics of a set of on-demand content and a unique identifier which can be used to create a document which collects the latest, most recent available information at the time of retrieval. OnDemand flag set to "1" for dynamic documents in docrepository.document table.

NOTE:  In order to target endpoints and make configuration settings to the gateway, the NwHIN config directory in the server must be known to the test project. This information is captured in a custom SoapUI property at the project level: GatewayPropDir. Alternatively, as of CONNECT 4.6.0, you can set the GatewayPropDir key/value pair in the global SoapUI properties. 

Test Case Details: 

NOTE: Test case description data example is based on CONNECT-4.6 populateTestData.sql 

  • DQ - XDSDocEntryType Not Set:


    This test case is used to test DQ service without setting XDSDocEntryType.  First, script will clear correlation and add correlation, aa_to_home_community mapping in database for the home community that is passed in NHIN target communities. When DQ request is processed, it is expected to get all the documents that are present for the patientID which is passed in DQ request message from the responding gateway (ex: 2.2). This test case is for testing without XDSDocEntryType slot value and by default CONNECT uses stable entry type. Since there is no entry type passed in this test case, though there are more than 2 rows with same patientId (ex: D123401) in responding gateway, DQ request response shows two extrinsic objects (onDemand=0) in AdhocQueryResponse message. Using assertions, script will verify documentId and number of extrinsic objects matches to the expected count in returned response. 

  • DQ - XDSDocEntryType Both Set:


    This test case is used to test DQ service by passing both(Stable and Dynamic)  values in XDSDocEntryType.  First, script will clear correlation table and  add correlation, one aa_to_home_community mapping in database for the home community that is passed in NHIN target communities. When DQ request is processed, it is expected to return all the documents that are present for the patientID (passed in DQ request) with entry type as Stable are Dynamic from the responding gateway (ex: 2.2). DQ request response shows three extrinsic objects in AdhocQueryResponse message (2 stable, 1 dynamic). Using assertions, script will verify documentId and number of extrinsic objects matches to the expected count in returned response. 

  • DQ - XDSDocEntryType Stable Set:


    This test case is used to test DQ service by passing XDSDocEntryType as stable document .  First, script will clear correlation table and add correlation, one aa_to_home_community mapping in database for the home community that is passed in NHIN target communities. When DQ request is processed, it is expected to return all the documents that are present for the patientID (passed in DQ request) with entry type as Stable from the responding gateway (ex: 2.2). DQ request response shows two extrinsic objects in AdhocQueryResponse message. Using assertions, script will verify documentId and number of extrinsic objects matches to the expected count in returned response.

  • DQ - XDSDocEntryType Dynamic Set:


    This test case is used to test DQ service by passing XDSDocEntryType as dynamic document .  First, script will clear correlation table and add correlation, one aa_to_home_community mapping in database for the home community that is passed in NHIN target communities. When DQ request is processed, it is expected to return all the documents that are present for the patientID (passed in DQ request) with entry type as Dynamic from the responding gateway (ex: 2.2). DQ request response shows one extrinsic objects in AdhocQueryResponse message. Using assertions, script will verify documentId and number of extrinsic objects matches to the expected count in returned response.

  • DQ - Both Set, Invalid Creation Time To:


    This test case is used to test DQ service by passing both (Stable and Dynamic) entries in XDSDocEntryType along with Invalid Creation time to inXDSDocumentEntryCreationTimeTo slot element.  First, script will clear correlation table and add correlation, one aa_to_home_community mapping in database for the home community that is passed in NHIN target communities. When DQ request is initiated, it is expected to return all the documents that are present for the patientID (passed in DQ request) whose documents creation time is not in the range of creation time to and below. (Ex: If creation time to is 2000-09-11 04:00:00 then results will have all the documents from this time to above for this test case). Using assertions, script will verify documentId and number of extrinsic objects matches to the expected count in returned response. NOTE: CreationTimeTo is from given time to below.

  • DQ - Both Set, Invalid Creation Time From:


    This test case is used to test DQ service by passing both (Stable and Dynamic) entries in XDSDocEntryType along with Invalid Creation time from in XDSDocumentEntryCreationTimeFrom slot element.  First, script will clear correlation table and add correlation, one aa_to_home_community mapping in database for the home community that is passed in NHIN target communities. When DQ request is initiated, it is expected to return all the documents that are present for the patientID (passed in DQ request) whose documents creation time is not in the range of creation time to and above. (Ex: If creation time to is 2015-09-11 04:00:00 then results will have all the documents from this time to below for this test case). Using assertions, script will verify documentId and number of extrinsic objects matches to the expected count in returned response. NOTE: CreationTimeFrom is from given time to above.

Preparation & Execution:

  • Make sure to copy CONNECT common  properties from   \\CONNECT\Product\Production\Common\Properties\src\main\resources to application server properties folder. (If using WildFly 8.2.1 , copy into  \\wildfly-8.2.1.Final\modules\system\layers\base\org\connectopensource\configuration\main).
  • Make sure to enable Standard mode for DQ service in gateway.properties. Note: By default all services will be in Standard mode in gateway.properties as of CONNECT-4.6  release.
  • Restart application server.
  • Deploy CONNECT ear (mvn clean  install -P AD,PD,DQ,DR,DS).
  • In SoapUI, make sure to have GatewayPropDir value set either by using global SOAPUI properties  or by setting custom SOAPUI property at the project level.
  • In SoapUI, load  DocQueryOnDemand project and execute.
  • Make sure all test cases are passed and green.
  • No labels