Kudu Configure Your System
This page will describe the steps to follow for checking your configuration information in Kudu and confirming that it is correct. You are not done until you have confirmed all of the entries.
We collect all network/port configuration information in Kudu (from you) so that we can publish that information to all of your testing partners in advance of the event. We want you to spend your time at the Connectathon working on interoperability issues and not asking your neighbor What is the URL of your Repository?
- There is setup work that the Project Managers must complete in early December.
- There is configuration work your partners want to complete before they ship their equipment from Europe to Chicago. International shipping takes time. Be a good partner.
- Do not come to the Connectathon and tell us: Oh, yeah, we changed those. Sorry. You will be placed on the knucklehead list.
What If I Don't Know What Hardware I Will Bring?
Not everyone knows the exact equipment they will bring down to the service tag/serial number level. However, we assume that you have an idea of how you would normally ship to a customer site or what you would bring if you were going offsite for beta testing.
We purposely do not want your hostnames. Think abstractly about what you need to manage the connectathon, and ship the actual hardware when you decide which box to bring.
What Do I Do First?
- Understand the Connectathon network plan. You will bring N computers (N > 0). Those that need to be recognized by other test partners will be assigned an IP address by the Project Management (Dream) Team.
- Don't worry about IP addresses yet.
- Map the actor/profile pairs and services to the N computers you plan to bring.
- If a computer is a VM, that counts as part of your N. A VM that is visible to a partner is different than the base computer that hosts the VM. We will have to assign IP addresses to both base systems and VMs.
- If you split services for one actor across computers, that is OK. "My Registry accepts submissions on host1, but the queries go to host2."
- If you need more hosts/names than we have allocated for you, send a note to Steve Moore. Lynn and Bill cannot help you with this.
- Do NOT bring your own switch and do port forwarding.
Kudu -> Configuration -> Systems
When you select this page, you will see a drop down box that lists your systems (assuming you have more than 1). Complete the configuration for each system. In a large company, these are likely done by different people scattered across time zones. The modality group is not expected to know the configuration for the Document Registry.
When you select your system, you will see a page that lists your actor/profile pairs, System Configuration types, and IHE transactions to support. The configuration types are tailored to your registration. We do make mistakes. If something is missing, please let us know.
Open One of the Configuration Items
The example shown here is for HL7 V2 interfaces. In this particular example, you will see configuration parameters for both inbound and outbound connections. For inbound connections, we list a port number where your application accepts inbound connections. For outbound connections, no port number is listed. You will see a reference to a proxy port. That is explained below.
Modify the Configuration to Match What You Will Bring
In this example, activate the "Edit HL7 configuration" button, and you have a new display with a table you can edit. Keep these in mind
- We made our best guess on parameters. You are free to use the ones that are most common for your product. You do not need to use a specific port number just because that was our default.
- We assigned services to a hostname that is based on your company registration. That hostname is a placeholder for your computer.
- Do not ask us to change the hostname in our system. It is only a map. When it is assigned an IP address, you will configure your system to repond to that IP address. All other participants will know you as mir2.ihe.net. You will use whatever hostname you like, but will respond to the proper IP address.
- We assumed all of your services would be on one computer. If you need to split these across computers, you can do that in configuration.
- The Confirmed column lets you check off that individual rows are correct. You can use this or the larger validate button one page previous.
- You will find 3 icons in the action folder:
- Pencil: Edit, open a new page to modify this entry
- Red Circle with X: Delete, this row is not needed
- Clipboard: Copy and paste all in one motion: Make a copy of this row so you can have another entry. You might decide you want more inbound listeners.
When you select the pencil icon to edit one row, the display will be tailored to that protocol. This is an example HL7 V2 configuration page.
- You can move this service to a different host (see Hostname)
- You can change the input port if that is important.
- You can change HL7 V2 specific entries.
In my case, I changed an entry to use a different host.
Finish All Configuration
Review all configuration and confirm each entry. You can delete entries that do not apply. You are not done until the configuration page tells you that all of your configuration is confirmed.
If you think you have confirmed everything, and you still have the red notice, send us a note and we will investigate. We run into problems when participants drop profiles. That confuses our software and database tables (our problem, not yours).
What Is This Proxy Thing?
For Connectathons that use Kudu (not Gazelle), we use an HL7 V2 proxy (MIRTH) that is used to route HL7 V2 messages. Your servers listen on ports you configure. We place another server between the HL7 clients and your servers. MIRTH is configured to have one open port for each server port at the connectathon. Connectathon participants send HL7 V2 messages to the proxy. The proxy stores a copy of the message and relays that message (original) to your system. With our copy of the message, we can run some further validation and give users a web browsable interface to find lost messages.
You define the port where you will listen. We will map that to a MIRTH port.
How Do I Tell Kudu About OIDs and Other Identifiers?
That is a trick question. As the keepers of the Affinity Domain, the Project Managers define those values and give them to you. Your task in November is to review your assignments and make sure
- You understand them
- That we have not omitted something you need
The page to find this information is Kudu -> Configuration -> XDS Codes / OIDs
What Configuration Task Do I Perform in December?
At the end of November, we will have a database that lists the configuration information of all of the Connectathon participants. There is a Kudu page that summarizes that information by protocol (DICOM, HL7 V2 MLLP, Web Services) and a wiki page that lists OIDs and other related information. During the month of December, you should load the information of all potential peers into your system.
Load Network Parameters
- In Kudu, open Configuration -> Network / Summary of Configuration.
- The top of the page describes general network information. That information will be valid December 1.
- Further down the page, you will see System Configuration Summary. This section has three tabs for:
- DICOM Configuration
- HL7 Configuration
- Webservices Configuration
- You should extract the data you need and load it into your system (in December).
- This information is not valid until December 1 (after all participants have confirmed their configuration).
- The Webservices tag includes the endpoints for HL7 V3 communication, as well as XDS... and all other web service communication.
Load OIDs and XDS Affinity Domain Codes
- The Configuration menu in Kudu has an entry for XDS Codes / OIDs. Open that item, and you have links to wiki pages that list a number of different identifiers and code values that are needed to complete your configuration.
- Follow the links, and enter the appropriate data into your configuration software.