Tutorial Scenario |
In a typical real-world scenario, let's assume that you are receiving one data stream arriving over a network from ACME Medical. Your application is interested in some or all of the data encoded in the messages. However, your interface requirements have now changed. Your interface is now expected to handle data streams from two different hospitals: (1) Acme Medical and (2) another hospital called Magic Health Systems. The two types of messages you expect to receive are shown below.
Here is an SIU^S12 message:
MSH|^~\&|TPS||Acme||20010817100616||SIU^S12|5C31FEB1-AFBC-401d-9990-438FD7B8D482|P|2.3|||AL|AL SCH||1058|||CARDI2||DEF PID|||9300080|824210432|GOMEZ^AMALIA^SANCHEZ||19550512|F|||CL NUŅEZ ARENAS 17 3 B,.^^Mostoles^^28112^E||6964526||||||987908709872|324123424|||^^^|||||||no PV1||O|4621|DEF^|||33^LLANO^JOSE A.^MOLINERO|||CARCEX|||||||||1058|||||||||||||||||||||||||200107121310|200107121315 AIG||||||||19000101000000|||0|min |
And here is an ORM^O01 message:
MSH|^~\&|GUID|Magic|Radiology||20010817100616||ORM^O01|5C31FEB1-AFBC-401d-9990-438FD7B8D482|P|2.2| EVN|O01|20010812 PID|||9300080|824210432|GUTIERREZ^THOMAS^TYLER||19550512|F|||CL NU\XD1\EZ ARENAS 17 3 B,.^^^^28112^E||6964526||||||987908709872| PV1||O|4621||||33^LLANO^JOSE A.|||CARCEX|||||||||1058| |
Your interface has already been successfully handling SIU^S12 messages, so the goal is to be able to also parse ORM^O01 messages. As you can tell from the above examples, the two segment grammars are slightly different.
The table below describes three ways to implement this, along with their advantages and disadvantages:
| Option | Explanation | Advantages | Disadvantages |
|---|---|---|---|
| 1 | Create two VMD files. These files contain two different segment grammars but utilize the same tables. | It is very straightforward and easy to create two separate VMD files with different purposes. Since you would also not be modifying the tables, table grammar and messages, you would not have to regenerate the stubcode. | You would have to manually copy tables and would have to maintain two separate VMDs. |
| 2 | Create one VMD file with two different messages. | You would only have to create one VMD file. This would be very easy to set up. | You would have to regenerate your stubcode since you would be adding a message. This would also increase the amount of stubcode when generating your application, increasing your maintenance costs. You would also have to maintain and support two types of messages (or more, if the interface ever evolved and changed over time), instead of supporting only one message type. |
| 3 | The best option is to create a VMD file with multiple configurations with different segment grammars that utilize the same tables. You would not have to regenerate your stubcode, since you would not be modifying your messages, tables or table grammar. | When you generate the application in Chameleon, your application would use the same code but just select the configuration. That would be the only extra code you would have to write. | N/A |
This tutorial will show you how to implement Option 3: create a new configuration to accommodate the other message. The following specifications are assumed for the application:
- It should be able to parse SIU^S12 and ORM^O01 messages on the same port.
- When these types of messages are received, the following information will be extracted: MSH information, PID information and PV1 information. Any other data will be ignored.
- The extracted data will be processed. In your case, you will simply display the extracted data on the screen.
- The application will be written in C++. This choice is purely arbitrary and does not materially affect any of the design choices that are discussed.