Skip to content
Harold Affo edited this page Nov 2, 2016 · 55 revisions

Welcome to the hit-base-tool wiki!

Overview

This wiki is for developer desiring to create an instance of the ONC MU-3 2015 Certification Program Validation Suites tool from the hit-base-tool.

Architecture (in progress)

The tool is developed using the following technologies:

Server Side

  • Spring 4

  • Hibernate

  • H2 DB

  • Maven for build and dependency management

Client Side:

  • Angular JS

  • Bower

  • Grunt

  • Twitter Bootstrap

How to configure ?

The base tool in itself is domain independent and is using maven to manage its build and dependencies. To configure the base the domain/format developer must:

  1. Fork the hit-base-tool repository

  2. Create a separate domain specific package (hit-elr, hit-lri etc...)

  3. Add the following project as dependencies to the domain specific package created en step 2

  4. Implement the following interfaces

    • gov.nist.hit.core.service.MessageValidator
    • gov.nist.hit.core.service.ProfileParser
    • gov.nist.hit.core.service.MessageParser
    • gov.nist.hit.core.service.ResourcebundleLoader
    • gov.nist.hit.core.service.ValidationReportGenerator (Optional, you can use ValidationReportGeneratorImpl)
  5. In the domain specific project create spring singleton beans of the implementations of

    • gov.nist.hit.core.service.MessageValidator
    • gov.nist.hit.core.service.ResourcebundleLoader
    • gov.nist.hit.core.service.ValidationReportGenerator
    • gov.nist.hit.core.service.MessageParser

This can be done by creating a configuration file with @Configuration. Here is an example for HL7v2 format:

@Configuration public class ToolWebBeanConfig {

  @Bean
  public ResourcebundleLoader resourcebundleLoader() {
      return new HL7V2ResourcebundleLoaderImpl();
  }

  @Bean
  public HL7V2ValidationReportGenerator hl7v2ValidationReportGenerator() {
      return new HL7V2ValidationReportGeneratorImpl();
  }

  @Bean
  public HL7V2MessageValidator hl7v2MessageValidator() {
     return new HL7V2MessageValidatorImpl();
  }

  @Bean
  public HL7V2MessageParser hl7v2MessageParser() {
     return new HL7V2MessageParserImpl();
  }

}

  1. Add the resource bundle package as dependency to the new package created en step 2

  2. Update the forked hit-base repository pom file to include the new package created en step 2 as a dependency.

Resource bundle Configuration

Please see the hit-example-resource-bundle for the structure of the resource bundle. The tool gets all its confiugration information from the resource bundle. The resource bundle is a maven dependency (jar) containing necessary resources. The structure of the resource bundle is as follow:

1. About
2. Contextbased

3. Contextfree

4. Documentation

   4.1 UserDocs

   4.2 KnownIssues

   4.3 ReleaseNotes 
  
   4.4 Downloads 

5. Global

   5.1 Global/Profiles

   5.2 Global/Constraints

   5.3 Global/Tables

   5.4 Global/Configs

About

This folder contains the;

  • MetaData.json: Information about tool.

{

"version"	: "1.0-beta",

"igVersion":"",

"name"	:"",

"domain"		:"",

"adminEmail"	:"",

"description"	:"",

"header" 	:""

}

  • Acknowledgment.html: Acknowledgment
  • Disclaimer.html: Disclaimer
  • Confidentiality.html: Confidentiality
  • Home.html: Home Page Info:
  • ValidationResultInfo.html: Validation Result Categories Descriptions

Contextbased

It contains the non-global context-based artifacts such as TestPlan, TestCaseGroup, TestCase, TestStep etc... The dependency is as follow:

 TestPlan

   TestCaseGroup[0..*]

     TestCaseGroup[0..*]

       TestCase[1..*]

          TestStep[1..*]

    TestCase[0..*]

       TestStep[1..*]

A TestPlan has a list of TestCaseGroups or TestCases. A TestCaseGroup can contain a list of TestCaseGroups or TestCases. A TestCase must contain at least one TestStep.

TestPlan

A TestPlan folder must contain all its test case and test case groups folder plus the descriptor file called TestPlan.json. The TestPlan is identified by its descriptor file TestPlan.json

TestPlan.json Example

{

"name" : "IZ_Admin_Child",

"description" : "IZ_Admin_Child"

}

TestCaseGroup

A TestCaseGroup folder is under a TestPlan folder and must contain all its test case or test case groups folder plus the descriptor file called TestCaseGroup.json. The TestPlan is identified by its descriptor file TestCaseGroup.json

TestCaseGroup.json Example

{

"name" : "Z41 Display Response Messages",

"description" : "Z41 Display Response Messages"

}

TestCase

A TestCase folder is under a TestPlan or TestCaseGroup folder and must contain all its test steps folder plus the following files:

  • TestCase.json: The descriptor file used to identify a TestCase folder and contains information related to the TestCase such as its name, description etc.

    • name: name of the test case

    • description: description of the test case

    • type: the type of testing. Possible values are ISOLATED, DATAINSTANCE. ISOLATED means communication based test case. DATAINSTANCE implies there is no communication involved.

    • documents: contains the documents of the test case

Example of TestCase.json:

{

"name" : "IZ_1_1_Admin_Child",

"description" : "IZ_1_1_Admin_Child",

"type":"ISOLATED"

}

  • TestStory.json:

Contains the story of the TestCase and its objectives. Its structure is as follow:

{ "teststorydesc" : " No Description",

      `"comments" : "No Comments",`

      `"preCondition" : "No PreCondition",`

      `"postCondition" : "No PostCondition",`

      `"testObjectives" : "No Test Objectives",`

      `"evaluationCriteria" : "No evaluation criteria",`

      `"notes" : "No Note"`

}

  • TestStory.pdf

  • TestStory.html

  • TestPackage.pdf

  • TestPackage.html

TestStep

A TestStep folder is under a TestCase folder and must contain the following files:

  • TestStep.json: The descriptor file used to identify a TestStep folder and contains information related to the TestStep such as its name, description, the profile, constraint and valueSet library it is linked to.
    • name: name of the test case

    • description: description of the test case

    • messageId: This is the id of a Conformance Profile from Global/Profiles (ConformanceProfile/Messages/Message/@ID)

    • valueSetLibraryId: This is the id of the Value Set Library from Global/Tables (ValueSetLibrary/@ValueSetLibraryIdentifier)

    • constraintId: This is the id of a constraint library from Global/Constraints

    • type: The type of testing. Possible values are:

      • TA_INITIATOR: This is to indicate that the test agent is initiating the communication at this step

      • TA_RESPONDER: This is to indicate that the test agent is responding to a communication initiated by the SUT or other agents at this step

      • SUT_INITIATOR: This is to indicate that the SUT is initiating the communication at this step

      • SUT_RESPONDER: This is to indicate that the SUT is responding to a communication initiated by a Test Agent at a previous step

      • SUT_MANUAL: This is to indicate a manual action is needed to be done by the SUT

      • TA_MANUAL: This is to indicate a manual action is needed to be done by a Test Agent.

      • DATAINSTANCE: This is to indicate that this a simple message validation with no communication involved.

#####Examples of TestStep.json

HL7V2

{

"name" : "Response-TC-1.0",

"description" : "Response-TC-1.0",

"hl7v2":{

 `"messageId":"dbf6c675-684b-4cb1-8250-5c88f8fdbfe5",`

 `"valueSetLibraryId":"IZ_ValueSetLibarary_Z22",`

 `"constraintId":"2c33463f-c04d-4564-a66d-f236bd0ef9d6"`

},

"type":"TA_INCOMING",

"position":"2"

}

EDI

{

"name" : "Response-TC-1.0",

"description" : "Response-TC-1.0",

"edi":{

 `"messageId":"dbf6c675-684b-4cb1-8250-5c88f8fdbfe5",`

 `"valueSetLibraryId":"IZ_ValueSetLibarary_Z22",`

 `"constraintId":"2c33463f-c04d-4564-a66d-f236bd0ef9d6"`,

},

"type":"TA_INCOMING",

"position":"2"

}

XML

{

"name" : "Response-TC-1.0",

"description" : "Response-TC-1.0",

"xml":{

 `"schemaPathList":"[schema1,schema2]",`

 `"schematronPathList":"[schematron1,schematron2]",`

},

"type":"TA_INCOMING",

"position":"2"

}

  • Message.text: An example of message

  • Constraints.xml: The constraint file specific to this test step

  • TestStory.[json/html/pdf]

  • MessageContent.[json/html/pdf]

  • TestDataSpecification.[json/html/pdf]

  • JurorDocument.[json/html/pdf]

  • TestPackage[.html/.pdf]

Contextfree

The Context-free test cases are found under Context-free. A Context-free test case folder is identifier by the TestObject.json descriptor file. The TestObject.json descriptor looks a lot like the TestStep.json descriptor file.

  • name: name of the test case

  • description: description of the test case

  • messageId: This is the id of a Conformance Profile from Global/Profiles (ConformanceProfile/Messages/Message/@ID)

  • valueSetLibraryId: This is the id of the Value Set Library from Global/Tables (ValueSetLibrary/@ValueSetLibraryIdentifier)

  • constraintId: This is the id of a constraint library from Global/Constraints

Example of TestObject.json: HL7V2

{

"name" : "Response-TC-1.0",

"description" : "Response-TC-1.0",

"hl7v2":{

 `"messageId":"dbf6c675-684b-4cb1-8250-5c88f8fdbfe5",`

 `"valueSetLibraryId":"IZ_ValueSetLibarary_Z22",`

 `"constraintId":"2c33463f-c04d-4564-a66d-f236bd0ef9d6"`

},

"type":"DATAINSTANCE",

"position":"2"

}

EDI

{

"name" : "Response-TC-1.0",

"description" : "Response-TC-1.0",

"edi":{

 `"messageId":"dbf6c675-684b-4cb1-8250-5c88f8fdbfe5",`

 `"valueSetLibraryId":"IZ_ValueSetLibarary_Z22",`

 `"constraintId":"2c33463f-c04d-4564-a66d-f236bd0ef9d6"`,

},

"type":"TA_INCOMING",

"position":"2"

}

XML

{

"name" : "Response-TC-1.0",

"description" : "Response-TC-1.0",

"xml":{

 `"schemaPathList":"[schema1,schema2]",`

 `"schematronPathList":"[schematron1,schematron2]",`

},

"type":"TA_INCOMING",

"position":"2"

}

A TestObject folder can contain others TestObject folders.

Documentation

UserDocs

This folder contain the users documentations such as user guides, tutorials, test procedures etc... The developer can provide a name to the document other than the file name by creating a configuration file called UserDocs.json file. The UserDoc element properties are the following:

  • title: title of the document
  • comments: commentsof the document
  • name: name of the document if no link property set. This property can contain a wilcard () (ex. Imm_Data_V1.0_) to indicate that we are only interested in the latest of this file. The tool will automatically sort the files and select only the most recent one.
  • link: external link of the document if no name property set.
  • date: date when the document is added to the resource bundle.
  • order: ordering number of the document in the list.

An example of UserDocs.json is as follow:

UserDocs.json

[ { "title":"Understanding LOI Testing", "name":"hl7guide-1-4-2012-08.pdf" "date":"06/27/2013", "order":1

		`},`
		`{`
		 `"title":"Addendum",`
		 `"link":"http://mylink.com/Immunization_Clarification_Addendum_R7.pdf"`,

"order":2 }, { "title":"Quick Guide", "comments":"Coming soon", "order":3 }, { "title":"Tutorial", "name":"NIST IZ_Tool_Tutorial.ppt", "order":4 }, { "title":"Spreadsheet Data", "name":"Imm_Data_V1.0_*", "order":5 }

]

KnownIssues

This folder contain the known issues files. The files can be either doc,docx or pdf. Developer must edit the configuration file KnownIssues.json to provide descriptive information about each know issue document. A KnownIssue element properties are the following:

  • description: description of the document
  • name: name of the document
  • version: version of the document.
  • date: date when the document is added to the resource bundle.

KnownIssues.json

[ {"version":"1.1.0", "date":"08/15/2013","comments":"IZ_Known_Issues 1.1.0.docx", "name":"IZ_Known_Issues_1_1_0.docx", "title":"Known Issues 1.1.0"}, {"version":"1.0.0", "date":"06/27/2013","comments":"IZ_Known_Issues 1.0.0.docx", "name":"IZ_Known_Issues 1.0.0.docx", "title":"Known Issues 1.0.0"} ]

ReleaseNotes

This folder can the releases notes. The files can be either doc,docx or pdf. User must edit the configuration file ReleaseNotes.json to provide descriptive information about each release. A ReleaseNote element properties are the following:

  • comments: comments on the document
  • name: name of the file
  • title: title of the document
  • version: version of the document.
  • date: date when the document is added to the resource bundle.

An example of ReleaseNotes.json is as folllow:

ReleaseNotes.json

[ {"version":"1.6.0", "date":"08/15/2013","comments":"IZ_Release_Notes 1.6.0.docx", "name":"IZ_Release_Notes_1_6_0.docx","title":"Release Notes 1.6.0 "}, {"version":"1.5.0", "date":"06/27/2013","comments":"IZ_Release_Notes 1.5.0.docx", "name":"IZ_Release_Notes 1.5.0.docx","title":"Release Notes 1.5.0 "}, {"version":"1.4.0", "date":"05/31/2013","comments":"IZ_Release_Notes 1.4.0.docx", "name":"IZ_Release_Notes 1.4.0.docx","title":"Release Notes 1.4.0 "}, {"version":"1.3.0", "date":"04/26/2013","comments":"IZ_Release_Notes 1.3.0.docx", "name":"IZ_Release_Notes 1.3.0.docx","title":"Release Notes 1.3.0 "}, {"version":"1.2.0", "date":"03/22/2013","comments":"IZ_Release_Notes 1.2.0.docx", "name":"IZ_Release_Notes 1.2.0.docx","title":"Release Notes 1.2.0 "}, {"version":"1.1.0", "date":"02/15/2013","comments":"IZ_Release_Notes.1.1.0.docx", "name":"IZ_Release_Notes.1.1.0.docx","title":"Release Notes 1.1.0 "}, {"version":"1.0.0", "date":"12/15/2012","comments":"Initial Release"} ]

Downloads

Contains Downloads.json which provide information to the war files and the installation guide. The installation guide file must be located in the "Downloads" folder.

Downloads.json

{ "installationGuide":{ "title":"Installation.Guide.-.NIST.HL7v2.Validation.Tools.v1-2.docx", "name":"Installation.Guide.-.NIST.HL7v2.Validation.Tools.v1-2.docx", "date":"12/07/2015" }, "downloads" : [ { "title":"iztool-1.0-beta", "link":"http://hit-testing2.nist.gov/wars/iztool-1.0-beta.zip", "date":"12/07/2015" } ] }

Global

Global/Profiles

This folder contains the list of integration profiles files (xml). It also contains the ProfileInfo.html file that describes each profile.

Example of ProfileInfo.html is:

<div style="font-size: 14px">

`<h4 class="page-header">Standard</h4>`

`<ul>`

	`<li>CDC HL7 Version 2.5.1 Implementation Guide for Immunization`

		`Messaging - Release 1.5 (10/01/2014)</li>`

	`<li>Immunization Clarification Addendum - 07/2015</li>`

`</ul>`

`<!--<p>CDC HL7 Version 2.5.1 Implementation Guide for Immunization Messaging</p>-->`

`<!--<p>Release 1.5 (10/01/2014)</p>-->`

</div>

<div style="font-size: 14px">

`<h4 class="page-header">Profiles</h4>`

`<ul>`

	`<li>Z22(VXU)- Send Immunization</li>`

	`<li>Z23(ACK)- Acknowledgement</li>`

	`<li>Z34(QBP)- Query: Complete Immunization History</li>`

	`<li>Z44(QBP)- Query: Evaluated Immunization History And Forecast`

	`</li>`

	`<li>Z31(RSP)- Response: List Of Candidates Profile</li>`

	`<li>Z32(RSP)- Response: Complete Immunization History</li>`

	`<li>Z33(RSP)- Response: Acknowledgement With No Person Records</li>`

	`<li>Z42(RSP)- Response: Evaluated History AND Forecast</li>`

`</ul>`

</div>

<div style="font-size: 14px">

`<h4 class="page-header">Pairs</h4>`

`<ul>`

	`<li>Z22:Z23 - Send Immunization/ACK</li>`

	`<li>Z34:Z31 - Query History/Respond Candidates</li>`

	`<li>Z34:Z32 - Query History/Respond History</li>`

	`<li>Z34:Z33 - Query History/Respond Person Not Found</li>`

	`<li>Z44:Z42 - Query History & Forecast/Respond History & Forecast`

	`</li>`

	`<li>Z44:Z33 - Query History & Forecast/Respond Person Not Found</li>`

`</ul>`

</div>

Global/Tables

This folder contains the list of value sets library files (xml). It also contains the Copyright.html for copyright information.

Global/Constraints
Global/Communication
  • Communication.json

This file contains information about the protocols fields supported. This is used to display the right html form based on the protocol selected. The content structure is as follow:

Coming soon.

{

"PROTOCOL_DOMAIN":[

"fields":[

  `{`

    `"name":""`

    `"children":[`

       `{`

         `"name":""`

         `"path":""`

       `}`

     `]`

  `},`

{

    `"name":""`

  `}`

]

]

}

Example for HL7V2 using MLLP is as follow:

{

"MLLP_HL7V2":[

"fields":[

  `{`

    `"name":"Application Name"`

    `"children":[`

       `{`

         `"name":"Namespace Id"`,

         `"path":"MSH.5.1"`

       `},`

       `{`

         `"name":"Namespace Id Type"`,

         `"path":"MSH.5.2"`

       `},`

       `{`
         `"name":"Namespace Id"`,

         `"path":"MSH.5.3"`

       `}  
   `
     `]`

  `},`

{

    `"name":"Facility Name"`,

    `"children":[`

       `{`
         `"name":"Namespace Id"`

         `"path":"MSH.6.1"`

       `},`

       `{`

         `"name":"Namespace Id Type"`

         `"path":"MSH.6.2"`

       `},`

       `{`

         `"name":"Namespace Id"`

         `"path":"MSH.6.3"`

       `}      

]`

  `},`

{

    `"name":"Host Name"`

  `},`

{

    `"name":"Port Number"`

  `}  `

]

]

}

How to build (in progress)

Fork the repo

For instructions: https://guides.github.com/activities/forking/

Install hit-core dependency

  • git clone https://github.com/haffo/hit-core.git hit-core

  • mvn install

Install hit-core-hl7v2 dependency (only for hl7 v2 domain)

* git clone https://github.com/haffo/hit-core-hl7v2.git hit-core-hl7v2

* mvn install

Add others domain specific dependencies

Ex. resource bundle etc... to the pom file of hit-base-web

Build client (optional)

  1. Install nodejs: https://nodejs.org/

  2. Install grunt and grunt-cli: http://gruntjs.com/getting-started

  3. Navigate to hit-base-tool/hit-base-web/client

  4. Run npm install

  5. Run bower install

  6. Run grunt build. This will build the client and export to hit-base-tool/hit-base-web/webapps/

Build tool war

  • Go to hit-base-tool root directory and

  • run mvn install to generate the war file.