table lookup

[johnjohn]

I want to convert the provider from one value to another. What is the most efficient way to do it? (I have 600 providers to convert in different segments too) I am using Mirth 3.03. Thanks

[johnjohn]

I think I am going to use the hashmap approach.

[glenn71]

load your hashmap in the deploy script

[narupley]

In 3.1 you'll also be able to use the configuration map to do things like this. It's basically a map you can edit directly in the Administrator, or load from an external properties file. It's meant to replace having to load properties files into maps in deploy scripts, which I know a lot of users currently do.

[johnjohn]

Can you walk me through how to build the configuration map in the administrator? Thanks,

[narupley]

Can you walk me through how to build the configuration map in the administrator? Thanks,

That will only be available as of 3.1, which will be released soon. If you're a support customer you can view our demo of it here: http://www.mirthcorp.com/protected-c...eveloper-qa-72

[Klima]

In 3.1 you'll also be able to use the configuration map to do things like this. It's basically a map you can edit directly in the Administrator, or load from an external properties file. It's meant to replace having to load properties files into maps in deploy scripts, which I know a lot of users currently do.

Is there a limit? I need to perform a translation table for the insurance segments in our ADTs and we have something like 5,000 insurances.

I'm looking for the best way to accomplish this goal and this seems promising though we are currently on Mirth Connect Server 3.0.0.6931.

Matt

[narupley]

Is there a limit? I need to perform a translation table for the insurance segments in our ADTs and we have something like 5,000 insurances.

I'm looking for the best way to accomplish this goal and this seems promising though we are currently on Mirth Connect Server 3.0.0.6931.

Matt

No limit per se, but unfortunately it may become cumbersome to manage when you have thousands of such values. There's an open issue to address that though: MIRTH-3459

[Klima]

No limit per se, but unfortunately it may become cumbersome to manage when you have thousands of such values. There's an open issue to address that though: MIRTH-3459

So if you had to translate the IN segments from one system to another (essentially rebuilding the entire IN1 segments):

begin e.g.

IN1|1|CP30|3002|...

IN1.3 is the insurance carrier ID in system A. I need to look up what 3002 = in system B and then rebuild the IN segments to reflect that information

end e.g.

would this be the way to do it? I understand there are some issues with it but ultimately it seems like the way to do this in Mirth.

Matt

[narupley]

Yes, so in that case you could create an entry in the configuration map with the key "3002" and the value of whatever it should be in System B.

However, when you're talking about a large amount of values like that, you may find it better and more maintainable in the long-run if you store that data in a database. Then in your global deploy script you can query that database and build up a map. Something like this:

var dbConn;
var result;

try {
	dbConn = DatabaseConnectionFactory.createDatabaseConnection('driver', 'address', 'username', 'password');
	result = dbConn.executeCachedQuery('expression');

	var map = new java.util.HashMap();
	// Populate map however you want with values from the result set
	globalMap.put('insuranceCodes', map);
} finally {
	if (dbConn) {
		dbConn.close();
	}
}

Obviously if and when MIRTH-3459 gets done then you can more easily use and maintain those values using the configuration map.

[Klima]

Yes, so in that case you could create an entry in the configuration map with the key "3002" and the value of whatever it should be in System B.

However, when you're talking about a large amount of values like that, you may find it better and more maintainable in the long-run if you store that data in a database. Then in your global deploy script you can query that database and build up a map. Something like this:

var dbConn;
var result;

try {
	dbConn = DatabaseConnectionFactory.createDatabaseConnection('driver', 'address', 'username', 'password');
	result = dbConn.executeCachedQuery('expression');

	var map = new java.util.HashMap();
	// Populate map however you want with values from the result set
	globalMap.put('insuranceCodes', map);
} finally {
	if (dbConn) {
		dbConn.close();
	}
}

Obviously if and when MIRTH-3459 gets done then you can more easily use and maintain those values using the configuration map.

Great, thanks! I will definitely pursue the map since I'm guessing that works in my current version 3.0.0.6931 ?

[narupley]

Yep, populating a map and storing it in the global map will definitely work in all versions.

[Klima]

Yep, populating a map and storing it in the global map will definitely work in all versions.

Excellent, thanks.

My only issue now is that I need to store more than a pair of data values.

I have to rebuild the entire insurance segments which, for some reason, contain all the info of the insurance. E.g., Street Address, Phone number, etc etc.

A hashmap seems good if I just wanted to store Insurance ID A and translate to Insurance ID B. If I want to be able to have all the Insurance data fields available to me in a map-like format, do I need to build an array instead?

Here is a made-up IN1 segment

IN1|1||1234|Medicare Box 1234^Medicare|PO Box 1234^^Blahsville^STATE^90210^USA||(555)8675309^^^^ ^555^8675309||||||||Medicare|Doe^John|Self|1900101 0||||||||||||||||||12345678A|||||||M|^^^|||||

I will need to lookup IN1.3 and match that to a number in another system and then populate IN1.4, IN1.5.1, IN1.5.3, IN1.5.4, IN1.5.5, IN1.5.6, IN1.7.1, IN1.7.6, IN1.7.7, and a few others in there.

This is more than a hashmap can do, correct?

It seems that I need to just query the DB every time an ADT goes through the system and fill in the values from the query.

Matt