Ensemble Best Practices
Design Model for a Routing Production
[Back] [Next]
Go to:

This chapter describes a design model that Ensemble customers have used successfully to build interface routing solutions. As such, it can be thought of as a collection of best practices for developing an Ensemble routing production.

This chapter describes only one approach. Other implementation strategies can be successful as well. Each organization has its own standards for writing code and conducting programming projects. This chapter simply describes those aspects of a routing production that are unique to Ensemble and that benefit from a carefully structured approach.
In general, the key to a good design is clarity and simplicity. Simplicity does not mean a small number of parts. Simplicity means that each part within the model has a clear function and is intuitively easy to find.
Configuration Items
An Ensemble production consists of configuration items. There are three types of configuration item:
The following figure expands the diagram of a routing process to show how it uses routing rules to direct the flow of information through the interface. The following figure includes details about the routing rules and data transformations that are only implied by the dotted circle in the diagram above.
A routing process has a routing rule set associated with it. Depending on how the rule set is defined, and depending on the type of message that arrives from the source application, the rule set identifies which of its rules should execute. More than one rule can execute, in sequence, but for simplicity the following figure shows the case where the rule set chooses only one rule. From this point, as shown, a rule can either delete the message or it can send the message to a destination within Ensemble. If this destination is a business operation, the message then leaves Ensemble on its way to the target application.
Application Specification
Ideally, a clinical application provides an HL7 application specification document, or implementation guide, that explains which types of HL7 event the application can send (or receive), and which message segments and pieces of each segment the application sends (or expects) for these events.
A formal document of this kind is extremely detailed, and extremely useful. If a specification document is available, the administrator for the clinical application can show it to you, and can explain to you which of the many possible events are actually in use in the enterprise. This is usually a small subset of the full list of events.
Even if there is no application specification document, there is usually some informal documentation. Ask the application administrator to see any notes that are available.
As an alternative to documentation, or to validate that the existing documentation is correct, you can examine the messages themselves to determine which types of HL7 event the application sends or expects to receive. Ask the application administrator to provide you with a sampling of the message data, saved in files.
Once you have the HL7 message files, you can use the Document Viewer to view and parse them using various schema definitions. In this way you can quickly determine whether or not the application is using a standard HL7 schema. If not, you can use the Message Viewer to refine and test a custom HL7 schema for the application.
Background information that supports these tasks can be found in subsequent chapters of this book, and in other books:
Production Spreadsheet
It is helpful to maintain a spreadsheet that organizes your information system, application by application. You can create the spreadsheet on paper, or using any software tool that you prefer.
As a general guideline, you should provide a row for each application that provides an incoming or outgoing data feed. In each row, the following columns are useful:
When you begin the project, your initial spreadsheet does not need to describe every application in the information system. You can add to the spreadsheet as you deploy each new interface.
Interface Design
This topic outlines an effective way to keep interface designs modular so that your Ensemble production remains easy to understand, scale, and maintain at each stage of its development:
The guiding principle is to keep your design modular. That is, develop one interface at a time and use one routing process for each interface. This contrasts with a model in which a single large routing process serves as the routing engine for all interfaces. There are a number of reasons why many routing processes are better than one:
Each configuration item in the production has a specific role to play. Keep each item to its role:
Naming Conventions
This topic explains the importance of naming conventions and provides examples.
Typically you will develop your Ensemble production incrementally, one interface at a time. There is a temptation to name items “as you go,” and to allow naming conventions to grow incrementally along with the project. InterSystems recommends you do not take this incremental approach to naming conventions.
Remember that a full HIS system can involve hundreds of interfaces. Anticipate the task of managing the routing production once all of these interfaces are included. The name of each component should clearly identify its purpose. This way, developers and system administrators can easily predict a component’s name based on its function.
InterSystems recommends that you establish a full set of naming conventions at the start of the project, and then stick with them. This alleviates the need to backtrack into your production configuration just to correct names.
Any convention that clearly identifies components by function is fine. The following is a full set of naming conventions that several Ensemble customers have used successfully:
For each element of the production, assemble a name from the segments that you have defined:
For more complex designs:
The following topics provide explanations and examples for these naming conventions.
Business Services
FromERChart, FromFineOR, FromDeskAdm
If you have decided to organize an interface so that one application sends messages into Ensemble via more than one business service, also include a keyword that classifies the MessageTypes that pass through each business service. A typical MessageTypes keyword uses the first three letters of the HL7 Version 2 message structure, such as ADT, ORM, or ORU. In this case the convention for the business service name is FromSourceAppNameMessageTypes.
FromERChartADT, FromERChartORM, FromERChartOther
Routing Processes
ERChartRouter, FineORRouter, DeskAdmRouter
If you have decided to organize an interface so that one application sends messages into Ensemble via more than one business service, also include a keyword that classifies the MessageTypes that pass through each business service to its routing process. In this case the format for the routing process name is as follows:
ERChartADTRouter, ERChartORMRouter, ERChartOtherRouter
Routing Rule Sets for HL7
Each routing process has an associated rule set whose rules determine message destinations. The rules direct the messages to data transformations or business operations based on message type, message contents, time of day, or other factors. Name each rule set to match its routing process. That is, for each SourceAppNameRouter, call the rule set SourceAppNameRules. For each SourceAppNameMessageTypesRouter, call the rule set SourceAppNameMessageTypesRules.
Business Operations
ToImagit, ToFineOR, ToPindex
If you have decided to organize an interface so that one application receives messages from Ensemble via more than one business operation, also include a keyword that classifies the MessageTypes that passes through each business operation. A typical MessageTypes keyword uses the first three letters of the HL7 Version 2 message structure, such as ADT, ORM, or ORU. In this case the convention for the business operation name is as follows:
ToMainLabADT, ToMainLabORM, ToMainLabOther
Data Transformations
Remember that the SourceMessageType and TargetMessageType may have the same name, but represent the same message structure in different schema categories.
ERChartADTA03ToMainLabADTA03, ERChartADTA02ToMainLabADTA01
Custom Schema Categories
The ApplicationName can represent a sending application or a receiving application.
ERChart2.2, Imagit2.3.1, OurFavorite2.5