The MD Link Integration Strategy

MD Link’s integration strategy can be summed up as:

• Support the widest possible range of data and network standards using Java technology
• Easy-to-use data mapping tools leverage the transformational power of XML
• Custom Interfaces support complex business logic
• Testing and debugging can be done without running the Service, via the Design Studio
• Interface-based licensing reduces cost for small to medium implementations

Easy-to-Design Interfaces

Systems Interface requirements are often more complex than simple point-to-point data feeds – many require query-response communication. MD Link’s mapping model lets designers handle their point-to-point or query-response needs within any Interface.

Java technology for portability, security and compatibility

The MD Link Design Studio

The MD Link Design Studio allows programmers and analysts to create Interfaces via a drag and drop graphical user interface. These Interfaces can be run as part of the MD Link Service, where they log their history. You can monitor this history from the visual MD Link Monitor.

Interfaces

Interfaces are the customized mapping of data, application and network resources. MD Link’s growing list of Interface adapters provide visual customization and data mapping. (See Interface Adapters)

Processes

Processes link Event, Task and Resource Interfaces to create active solution Services. (See Design Studio)

Data Mapping

Data mappings can be created between any two of an Interface’s Components using the drag and drop data mapping view. For advanced mappings, custom Python code is supported, as well as preset functions for math, text transformation, and date handling.

The MD Link Service

Any Interface created in the Design Studio can be loaded by the MD Link Service. The Service runs in the background, and is designed for production use, running all of your Interfaces in parallel.

The MD Link Monitor

The MD Link Monitor is a graphical user interface which connects to the MD Link Service. It shows each Interface and its Components, which are color coded by their status.

As each Component executes, logs are generated at the info, warning, error, and debug levels. These logs can each be filtered or disabled for maximum flexibility while troubleshooting.

Case 1: HL7 Patient Admission to Nursing

This case shows how to receive, parse, generate and send HL7 messages. The Interface monitors an admissions message queue using an HL7 Socket Event. It parses the message and generates a nursing HL7 record. Finally, an HL7 Socket Task sends the converted admission message to a Nursing System via a Web service.

The HL7 Generator Task shows:

• HL7 message version
• HL7 message type
• Using a standard message schema, as opposed to a custom one

The Data Mapping window shows:

• Source is ORU R01 (admission)
• Target is also ORU R01 (nursing)
• The mapping uses an XPath function which converts last names to upper case characters.

Case 2: Sending Spreadsheet Data as HL7 Messages

This case shows how to take patient data, stored in a non-HL7 format, and send it to a receiving system as an HL7 message. In the case shown, patient data is taken from .csv (spreadsheet) files.

The Interface’s workflow:

• A user moves the .csv files to an input directory
• A File Change Event (labeled here as “Detect Excel File”) sees each .csv file as it appears in the input directory, passing that file’s data down the chain.
• A Custom Task (labeled here as “Generate HL7 Message”) runs a Python script which creates an HL7 message out of the .csv file’s data.
• An HL7 Socket Task then sends the HL7 message to the receiving system.