Overview
Documents how to customize the index viewer for terminologies other than ICD10.
General Info
The index viewer implementation is specifically designed to work with ICD10 and also can easily be customzied for ICD10CM. A review of the Index Viewer Tools page is recommended to learn how the various tools work.
The map tool dynamically checks to see whether index data for a desired target terminology is available so building and packaging the data is all that is needed.
Index viewer data could only be built for terminologies that have an index that is released in addition to the terminology itself - otherwise, there would be no starting point. This functionality was specifically built for ICD10 and ICD10CM, so terminologies beyond these may not be appropriate, even if they have indexes.
In the event that index viewer data is not needed at all, there is a default, empty, index viewer data artifact that comes with the project (in config/empty). It has essentially the top-level directory and then no contents. This artifact can be used in any installation where index viewer data is not needed.
Process
The basic process for customizing index viewer is this:
- Convert indexes to the XML format used by the tooling (this is essentially the XML format of the ICD10CM index). Each index file must be individually converted.
For ICD10, this is done using the AscToXmlMojo which coverts the .ASC ICD10 index files into the XML format of the ICD10CM indexes. e.g.
<?xml version="1.0" encoding="UTF-8"?> <ICD10.index> <version>0</version> <title>Alphabetical index to diseases and nature of injury</title> <letter> <title>A</title> <mainTerm> <title>Aarskog's syndrome</title> <code>Q87.1</code> </mainTerm> ... <mainTerm> <title>Abdomen, abdominal </title> <seeAlso>condition</seeAlso> <term level="1"> <title>acute</title> <code>R10.0</code> </term> ...
- For other terminologies, a simliar custom converter would need to be created.
- Convert the XML representation of index data into HTML files and Lucene indexes. This must also be done for each index
- IndexXmlToHtmlMojo is used to convert XML to HTML.
- IndexXmlToLuceneMojo is used to generate Lucene indexes from the XML.
Once HTML and Lucene indexes have been generated, all of the data should be packaged into a maven artifact with a structure like this:
- indexViewerData
- <terminology> (e.g. ICD10)
- <terminologyVersion> (e.g. 2010)
- asc - for ICD10, the original index files
- html - location of the HTML files created by the mojo
- TEIL1 - for ICD10, this is the name of one of the indexes. For another terminology, this would be something different.
- TEIL2
- TEIL3
- lucene - location of the Lucene index created by the mojo
- TEIL1
- TEIL2
- TEIL3
- xml - the XML representation of the index files
- <terminologyVersion> (e.g. 2010)
- <terminology> (e.g. ICD10)
NOTE, in the example above "asc" is specifically for ICD10 and other terminologies would not require this directory. Another important point is that while "asc" and "xml" are not technically needed to deploy the index viewer data, it is recommended that all of the files related to indexes and index viewer data be kept together so that a single maven artifact can contain everything that is needed.
Configuring the Build
When building a server for deployment, a configuration project is included by virtue of the use of these three paramaters (which have defaults in the webapp/pom.xml file)
- config.groupId
- config.artifactId
- config.version
To include your custom index viewer data, simply follow the dev-windows example (described in Index Viewer page) and point your configuration project to your custom index viewer data. Then build the server with the three parameters above specified to point to refer to your config project.
Combining Indexes From Multiple Terminologies
The build only supports configuration of a single index viewer data artifact. Thus, if a custom installation needs index viewer data from multiple terminologies, this requires creating a project/maven artifact having all of the data from the multiple repositories. It is recommended that you architect this to keep individual index viewer data artifacts separate from each other and then have a secondary project that combines the data from multiple terminologies as needed. Then, that secondary artifact is the one used to configure the final build.
ICD10CM Example
A good example of an alternative index viewer data artifact would be one for ICD10CM. here, the index files come in the natural format used by the index viewer. The 2015 distribution contains 4 index files
- FY15_Drug.xml
- FY15_E-Index.xml
- FY15_Index.xml
- FY15_Neoplasm.xml
As there are four indexes, the final artifact would have four sub-directories for "html" and "lucene", one for each index. The artifact built by a custom index viewer data project for ICD10CM 2015 would have the following structure:
- indexViewerData
- ICD10CM
- 2015
- html
- Drug
- E-Index
- Index
- Neoplasm
- lucene
- Drug
- E-Index
- Index
- Neoplasm
- xml
- FY15_Drug.xml
- FY15_E-Index.xml
- FY15_Index.xml
- FY15_Neoplasm.xml
- html
- 2015
- ICD10CM
Here, the contents of "html" and "lucene" would be created by multiple invocations of the IndexXmlToHtmlMojo and IndexXmlToLuceneMojo admin tools.
References/Links