Best practices for VMD files
Contents
Use different VMD files for message and table mapping
We recommend using different VMD files for the message structure and the table mapping. It is best practice to use different VMD files to separate the message structure (VMD Message Grammar) and the database table mappings (VMD Table Grammar).
Many organizations need to map various different HL7 messages to a single database. Generally it is best practice to structure code to reflect business process. By using a separate table schema VMD and multiple HL7 messages VMDs (one for each message type) we create a structure that better reflects what the organization does. Also if some messages use different versions of HL7 you can tailor the VMDs to use that specific version of HL7.
How it Works
This example code uses the same VMD file for hl7.parse() and db.tables():
The resulting code would look something like this:
Another scenario would be migrating from a legacy system, in this case you have multiple databases and multiple messages. This example shows a single message mapped to two databases using a separate VMD file to map to the legacy system.
Using multiple VMD files to map to different databases [top]
An example of the power and flexibility of Iguana is that you can use different VMD files for hl7.parse() and db.tables(). In fact we recommend it as best practise to use different VMD files to separate the message structure (VMD Message Grammar) and the database table mappings (VMD Table Grammar) – particularly for more complex systems.
If you are introducing a new system and phasing out a legacy system with a different database structure you could use a second VMD file to map to the legacy system. This could all be achieved in a single channel with multiple calls to db.tables() and conn:merge().
This is the mapping for the new system:
This is the mapping for the (fictional) legacy system, which has a very dodgy database structure:
There are two conn:merge{} calls one for each database:
When the legacy system is no longer needed you can simply remove (or comment out) the second conn:merge{} call. If you like clean code like me you can remove every legacy reference, and still revert at anytime using the Iguana milestones.
This is not intended as a recipe, it is intended to hint at the potential of what you can do with Iguana when you start to think outside the box. I certainly find it to be a revolutionary product, I have not used anything else that combines such power, flexibility and ease of use.