DM Software HL7 Specification 1.0

DM Software HL7 Specification 1.0 Sep 2008 By Gene 1 What is HL7? HL7 is a standard for exchanging information between medical applications and i...
Author: Johnathan Bruce
27 downloads 3 Views 375KB Size
DM Software HL7 Specification 1.0

Sep 2008

By Gene

1

What is HL7? HL7 is a standard for exchanging information between medical applications and is an abbreviation of "Health Level Seven". "Level Seven" refers to the seventh OSI layer

protocol for the health environment. In general terms, HL7 is a protocol for data

exchange. It defines the format and the content of the messages that applications must use when exchanging data with each another in various circumstances.

Hospitals and other medical institutions typically use many different types of systems to communicate with one another. Everything, from patient records to billing

information, is tracked and recorded in computer systems. In order for these different types of systems to communicate with each other, they use a standard like HL7.

In the computer world, a protocol is a formal, well-defined standard for exchanging information between computer applications.

HL7 Protocol Characteristics HL7 is a structured protocol that is used as a means of communicating between

healthcare applications. The following descriptions provide an outline that define the characteristics of the HL7 protocol:

Event-Driven: Real-world events, such as the admission of a patient, cause

messages to flow between applications. In other words, an application that encounters a real-world event sends a message to other applications that need to be aware of this event.

Application-to-Application: It defines a communication between two independent applications, rather than between closely coupled, client/server applications. The

scope of interest for HL7 is the message exchange between the applications, rather

than the specific role of each application in the healthcare delivery process. If you want to learn more about application roles in the healthcare delivery, refer to the IHE framework.

Point-to-Point: HL7 is a messaging format that is independent of its transport

method. However, it is typically used in a client/server environment for employing some form of a point-to-point protocol.

2

For instance, HL7 can use the LLP Transport method to transfer messages between a client and a server. However, since a client must establish a connection to a server

before a message can be sent, the client must have prior knowledge about the server. It is not normal for HL7 messages to use a non point-to-point protocol, where the client listens for 'broadcasts' from a particular server. OSI Level 7:

indicates that HL7's scope is the format and content of the data

exchanged between the applications, rather than how the messages are transmitted

between computers or networks. In other words, HL7 does not specify how messages will be delivered between the applications. Usually a TCP/IP connection or FTP file

transfer is used to deliver a message. However, within local area networks, the de facto standard is the Lower Layer Transport Protocol.

Data Exchange: HL7 specifies the way data exchange between applications will be

accomplished. It does not specify how applications store or process this data. It would

be advantageous for an application developer if their application's database structure coincided with HL7 message definitions, but it's not mandatory.

Standard: When you create a proprietary, non-standard link between two systems, a message exchange that better suits your personal needs and better fits the data

structure of your application can be created. Although this can be done, the efforts invested in this link are useless when considering a connection to other third-party

systems. Using HL7 means that your initial development effort can be reused again and again.

Versions of the HL7 Standard In this section you will learn about the various versions of the HL7 standard. Standards are developed by Health Level 7 (HL7), an ANSI-accredited health information

standards organization and are used as messaging specifications for exchanging data between health information systems. HL7 Version 2.X The HL7 standard is in a constant evolutionary process. To date, the HL7 committee has released six versions of the HL7 standard: 2.1 2.2 2.3

2.3.1 2.4 2.5

3

Version 3.0 is currently still in development and has been since 1997. In the beginning of its development, it was decided that version 3.0 would not be backwards compatible

with version 2.X. This means that early adopters of the version 3 standard will have to create interfaces that can communicate with both version 2.X and 3.0 interfaces. Version 3.0's lack of backward compatibility has two main consequences:

It may not be economically feasible for organizations to employ two types of

interfaces (one to communicate with 2.X versions and one for 3.0 versions).

Organizations may not want to switch to the version 3.0 standard until it is more widely adopted.

In contrast, each 2.X version of the standard is designed to be backwards compatible

with the previous version. The version number of the HL7 flavor you are using is often not that relevant. In typical cases, it is the vendor flavor that is of more importance

with regard to how each message is populated. The next section discusses backward compatibility.

HL7 2.X Backward Compatibility HL7 2.X is designed to be backwards compatible. This means that fields are only added to HL7 2.X, never deleted.

To illustrate this, consider the Patient ID field in a PID segment. Early versions of HL7 declared the Patient ID to be just a simple, one-field identifier such as:

|PatientID| With more recent versions, the Patient ID has become more embellished with composite data types:

|PatientID^Check Digit^Assigning Authority NameSpace&...| Ordinarily, extra fields are optional in HL7 2.X. When additional fields are not present, the trailing delimiters do not need to be displayed. For example,

|234324^^^| is equivalent to:

4

|234324| which is the same as the earlier format of HL7. What this amounts to is that you can have an HL7 parser that is set up to read Version 2.4 of HL7, and it will have no trouble parsing a message that was created with Version

2.1. The parsing engine will just assume that the extra fields that exist in Version 2.4 are empty.

Backward compatibility issues with HL7 XML formats are less straightforward. HL7 Version 3.0 Since 1997, the HL7 organization has been developing version 3.0 of the protocol. Unlike 2.X versions, HL7 3.0 is based largely on a single formal model called the

Reference Information Model, or RIM for short. The goal of RIM is to reduce the implementation costs of HL7-enabled solutions and further standardize the HL7 communication specifications between healthcare systems.

HL7 3.0 is a complete redefinition of the HL7 standard that is intended to try and

overcome some of the issues with the current standard. Version 3 will change not only the content of the messages and fields, but also the encoding rules, LLP (low level communication protocols), base data types and even the roles of the applications

participating in HL7 communications. XML is the planned medium for HL7 interchange instead of the simple ASCII text that is currently in use.

Since HL7 3.0 is based largely on one model using a consistent methodology it should

be less ambiguous, making it easier to implement in the future. This should also make updates to the standard more simple, largely due to its improved development methodology.

Although version 3.0 is said to be the standard of the future, its shortcomings should not go unmentioned, especially when comparing it to current 2.X standards. For

example, version 3.0 has been in development since 1997. That is ten years after the

start of development, with no clearly-defined resolution in sight. In addition, because the standard is not "official", there is a shortage of healthcare facilities (labs, hospitals, etc.) that want to be the first ones to migrate to version 3.0. After all, interfacing

between version 2.X and 3.0 is currently impossible, as HL7 3.0 offers no compatibility

with version 2 standards. As a result, healthcare applications will need to support both version 2.X and 3 in the foreseeable future.

In comparison to version 3.0, 2.X versions offer many current advantages. For

instance, version 2.X of the standard is still widely used and implemented in various

healthcare facilities worldwide. Moreover, since the version 2 standards were designed

5

with backward compatibility in mind, interoperability across existing healthcare

applications that utilize different versions is relatively simple. Furthermore, although version 2 standards were not initially designed to work with XML, there are HL7 specifications available that make this possible.

All in all, although the healthcare industry will eventually move towards the adoption of HL7 3.0 in the future, the widespread use of version 2.X continues to grow and remains the popular choice among healthcare facilities and vendors alike.

Common HL7 Transports This section describes the most common transport used to send HL7 messages, called

the Lower Layer Protocol (LLP). A less common transport called the Hybrid Lower

Layer Protocol (HLLP) is also briefly discussed. Although HL7 messages are sent via a variety of TCP/IP transports, including FTP, SOAP and SMTP, LLP is the most common method.

LLP - Lower Layer Protocol The Lower Layer Protocol (LLP), sometimes referred to as the Minimal Lower

Layer Protocol (MLLP), is the absolute standard for transmitting HL7 messages via TCP/IP. Since TCP/IP is a continuous stream of bytes, the wrapping protocol (i.e.

headers and trailers) is required for communications code to be able to recognize the start and the end of each message. The Lower Layer Protocol is the most common

mechanism for sending unencrypted HL7 via TCP/IP over a local area network, such as those found in a hospital.

An HL7 message must be wrapped using a header and trailer (also called footer) to

signify the beginning and end of a message. These headers and footers are typically non-printable characters that would not be shown in the actual content of an HL7 message.

The typical structure of an HL7 message being sent via LLP is described in the table below. It contains four parts:

Header Vertical tab

character (0x0B)

HL7 Message The HL7 message is wrapped using a header and trailer (immediately followed by a carriage return):

MSH|^~\&||.|||199908180016||ADT^A04|ADT.1.1698593|P|2.1

PID|1||000395122||LEVERKUHN^ADRIAN^C^^^||19880517180606|M|

Trailer Field

separator character (0x1C)

6

Carriage Return

Carriage return

(0x0D)

Moreover, you must also ensure that each segment is terminated by an 0x0D carriage

return. This is mandated by the standard, but often HL7 log data can be received via FTP or email where the segment separators have been transformed into 0x0A characters, etc.

TCP/IP Basics In this section you will learn about the basics of TCP/IP based communication. This

section will also discuss the roles of the client and server when implementing an HL7 interface, as well as the limits of TCP/IP. Client or Server When implementing an HL7 interface, your interface will either be acting as a Client or a Server.

TCP/IP Server A TCP/IP server is a program that listens on a TCP/IP port number receiving

connections from clients. For instance, a web server is a special type of TCP/IP server that listens on port number 80. A TCP/IP server can have many different TCP/IP clients connected to it.

TCP/IP Client A TCP/IP client is a program that connects to a TCP/IP server. For instance,

Netscape and Internet Explorer are TCP/IP client programs that connect to

web servers. A TCP/IP client must specify both the host address or IP address, as well as the port number that it wants to connect to. TCP/IP Server Usage Example A typical example of where you might want to implement an HL7 server is when you want to receive an ADT (Admit/Discharge/Transfer) feed to extract, for

instance, patient demographics. Typically, you would write your interface as a TCP/IP server. You would then listen on a port number that you could negotiate with your counterparty, and the device sending you the ADT messages will

connect to your server. This means you need to give the host and port number that you are listening on to the administrator of the ADT feed so they know how to connect to you. TCP/IP Client Usage Example A typical example of where you might want to implement an HL7 client is when you want to send lab results to a HIS (Health Information System). The

7

administrator of the HIS system would need to give you the host or IP address of their HL7 server and the port number that it is listening on. ACKnowledgment Messages One final point that confuses many people is how HL7 ACKnowledgment

messages should be sent. It is important to understand that when a TCP/IP

connection is established, it is a two-way channel of communication. When a

client establishes a connection to a server there is one channel on which the

client can send data to the server, and another on which the server can send data back to the client. This latter channel should be used to send ACK messages.

Sometimes it is necessary to implement both a client and a server component for your product's HL7 interface. Avoid the temptation to follow some creative members of the computer community who use the client component to send back all the ACK messages. Your creativity will be someone else's problem. This certainly happens in the real world, but if you have the choice, make use of the fact that you can use the second channel of communication to send back ACK messages, as this is a much cleaner design.

Hybrid Lower Layer Protocol (HLLP) The Hybrid Lower Layer Protocol (HLLP) is a variation of the more widely used

Lower Layer Protocol. Like LLP, HLLP uses TCP/IP as its transport but incorporates

error detection and verification via the use of checksums at the end of messages. The checksums are used to verify that no data was corrupted. Checksums are typically computed for each block of data that is sent for the sending application and then verified for accuracy at the receiving application.

The checksums used in HLLP are non-standard, meaning they may vary from implementation to implementation.

A common type of checksum used in HLLP is called BCC (Block Character Check), which is the sum of all characters in a block. The BCC checksum is considered a weak checksum since it may be easy to find different blocks that generate the same block checksum. Although the BCC checksum is relatively easy to

implement, it may not meet the commuication standards of most companies.

In practice most vendors choose to use TCP/IP over LLP, rather than HLLP. LLP is a

very simple protocol to incorporate and can be used instead of HLLP since the TCP/IP

8

channel provides all of the services necessary for the error-free delivery of HL7 messages. This includes:

1. Connection Handshaking The process by which two systems initiate communication. Start and end control characters are used to start/stop the transmission of data.

2. Full Duplex Data Transfer The process by which a system transmits and bi-directionally receives data simultaneously.

3. Error Detection and Retransmission The process by which the transport layer detects segments that fail transmission and retransmits them, if necessary.

4. Flow Control The process by which the flow of messages between systems is managed by TCP through the use of ACKs and NACKs. Through the use of ACKs/NACKs and

other built-in mechanisms in an HL7 application, you can manage the flow of data to ensure that messages are transferred efficiently and reliably. 5. Connection Termination The process by which a connection is ended independently by each system via a handshake.

In most cases, HLLP is an unnecessary requirement as long as the two communicating health systems are using a reliable OSI transport layer since the transmission of

messages, as well as the integrity of messages, is already verified by the underlying OSI protocols.

Hybrid LLP is only used for unreliable transports (e.g. transporting messages via a serial cable) and is considered unnecessary by most vendors.

With TCP/IP, checksums over data and headers are already inherent to the

protocol. This means that the protocol will detect checksum errors and request the retransmission of data, if necessary. What this means is that a secondary

checksum associated with HLLP will not further guarantee data delivery but just adds to transport overheads.

9

Advantages and Disadvantages of HL7 Open Systems vs. Closed Systems Following a standard protocol provides you with an advantage of connecting to any system that supports this particular part of the standard, both now and in the

future. For example, Internet Explorer or Netscape can connect to any existing and

future web server using HTTP and HTML standard protocols.

Adhering to a standard protocol is called "open system architecture". Anybody can interface with an open system using appropriate protocols, independent of its vendor. When using HL7, the interface allows for numerous systems to be added to a single HL7 feed. New systems can be added without having to modify the original source system as demonstrated in the following diagram:

HL7 Interface Model Now consider the proprietary system model:

10

Proprietary Interface Model "Closed" and "Proprietary" are used interchangeably throughout this section to mean that characteristics of the system are hidden by the vendor from public domain. Although the closed-system model is easier to design and initially costs less to

implement, closed systems have greater reliability on single vendors and more reliance on specific applications and technologies.

Although the worldwide trend is to follow an open-system architecture, there are still

tradeoffs in following a standard protocol when developing interfaces. For instance, a greater initial investment is required. Time and money must be spent to understand

the standard and create the infrastructure required to support the standard, such as a parsing framework and networking code.

However, the benefits are abundant. For example, it will be easier to answer user

requirements because HL7 is considered the standard for exchanging data between

healthcare systems. In addition, because HL7 is the standard, it will be easier to create a system that can interface with an open system now and in the future. Using Cost-Effective HL7 Tools Fortunately, the clear advantage of standards is that you do not have to develop the infrastructure for it from scratch. Standards create markets for tools, which means that you can buy generic tools to make your implementation easier.

When developing for a standard protocol such as HL7 and XML, there are many

cost-effective, easy-to-use tools and programming components. These help to avoid

low level creation, parsing and network communication of HL7 and XML messages over the network. Using standard tools can save you up to 90 percent of the low level work that would otherwise be required.

11

Is HL7 Plug-and-Play? Unlike many other standard protocols, HL7 is not really plug-and-play. For historical

reasons, each vendor implements the same HL7 messages in slightly different ways.

As a result, if you design your HL7 interface yourself, you will have to modify the HL7 parser and the application for each new installation. Why is HL7 Not Plug-and-Play? The following table explains why HL7 is not plug-and-play:

Reason Missing Fields Same Data in

Description Some vendors tend to omit fields in the message instead of leaving them empty. This will change the number of every subsequent field from the start of the message.

The same information may be located in other fields - and

Different Fields even in different segments - in various HL7 implementations. Same Data in Different Formats

Different Versions

Missing Values (including

mandatory fields)

Invalid

Segment

Grammar

The same data may come in different formats. For example, timestamp

information

should

appear

as

19991231100000.000, but some vendors divide the date

and time into different sub-fields: 19991231^100000.000. This is only one example of the possible mis-formats.

The existence of a number of different versions allows data exchange only between applications that support the same version of HL7.

Although the standard requires only a limited set of values to

be present (95 percent of the fields are optional), some vendors omit even those with required values.

There is a lack of adherence to the segment grammar that is required by the standard. Some expected segments may be missing, while other unexpected segments may appear.

In this environment it is important to be equipped with tools that were created to deal with the diversity of HL7 implementations, standards and versions. More Information About HL7 If you want to read more about the HL7 organization and standard, please visit the official HL7 website at http://www.hl7.org.

12

Understanding HL7 Messages In this section you will learn about the components of an HL7 message and delimiter characters, including escape sequences and delimiter redefinitions. This will provide

you with a general understanding of HL7 messages that will assist you when creating your own HL7 interface through the use of third-party tools, or developing it from scratch.

Components of an HL7 Message HL7 has a message-oriented architecture, as opposed to a Client-Server or Document architecture. It means that the application in which an event occurs will send a message to other applications rather than serving a request.

Throughout this document, the application that issues the message will be called Sender or Sending Application, and the addressee of the message will be called Receiver or Receiving Application.

Overview The structure of an HL7 message is as follows: Message --> Segments --> Composites --> Other composites or primitive data types. You will encounter the generic term 'field' that will usually refer to either a whole

composite or to a sub-field (single value). In this document, a whole composite is

referred to as a field (...|DOE^JOHN^^^^MD|...) and a single value is referred to

as a sub-field (...^JOHN^...).

Development Tip If you decided to implement your HL7 connectivity without any tools, your HL7 parser will detect each field according to its number from the start of the appropriate segment. If you need a patient name, count five "|" (pipe) characters from the start of the PID segment:

PID||0475^^^2^ID1|45||DOE^JOHN^^^^MD| You need to be careful about doing this since some vendors tend to omit a number of fields, especially in very long segments. Do not hard-code field

13

numbers in your parser. In practice it may vary although it is strictly prohibited by the standard.

Messages Let's take a look at a typical HL7 ADT^A04 message. This message is sent when a new patient arrives at the hospital. The patient's demographics are entered into a HIS

(hospital information system), and then the information is communicated to all the other systems to avoid multiple entries of the patient's demographic information.

MSH|^~\&|EPIC|EPICADT|SMS|SMSADT|199912271408|CHARRIS|ADT^A04|1817457|D|2.3| EVN|A04|199912271408|||CHARRIS PID||0493575^^^2^ID 1|454721||DOE^JOHN^^^^|DOE^JOHN^^^^|19480203|M||B|254 E238ST^^EUCLID^OH^44123^USA||(216)731-4359|||M|NON|400003403~1129086| NK1||CONROY^MARI^^^^|SPO||(216)731-4359||EC||||||||||||||||||||||||||| PV1||O|168 ~219~C~PMA^^^^^^^^^||||277^ALLEN FADZL^BONNIE^^^^|||||||||| ||2688684|||||||||||||||||||||||||199912271408||||||002376853 Example Message HL7 Messages are ASCII messages (unlike protocols such as DICOM), and the

standard requires that they be "human readable". This is acceptable if you don't mind counting pipe characters.

Message Definition Messages are a defined sequence of segments and/or segment groups. Each segment, group or message set within a message can be optional and/or repeating.

Each message consists of the segments that are delimited by "carriage return" characters ("\r" or 0x0D). Each segment is placed on a different line.

14

Segments Each line in a message is referred to as a Segment, with each one having its own

semantic purpose. This means that it contains information of a specific type. For example:

MSH segment contains information about the Sender and Receiver of the message, the type of the message, a time stamp, etc.

EVN contains information about the type of message; for example, A04

(Register a patient). Information contained in EVN is duplicated in MSH, so

starting from HL7 version 2.3 this segment is excluded from all message definitions.

PID contains demographic information about the patient such as name, id codes, address, etc.

PV1 contains information regarding the patient's stay in the hospital, such as location assigned, referring doctor, etc.

As you can see, the sample message in the previous section contains MSH, EVN, PID,

NK1 and PV1 segments. There are more then 120 segments defined in version 2.3 of the standard.

Segment Definition Segments are the units that comprise a message. A segment is defined as a

sequence of fields that also may or may not repeat. An HL7 message definition also states whether each segment is mandatory or not.

Segments consist of fields that are composites. Composites are delimited by "|" (pipe)

characters. Each field has its own unique purpose and is defined by the HL7 standard for each segment.

The PID segment in HL7 version 2.3 consists of thirty composite fields. Only two of

them are mandatory: Patient Name and Patient ID. As you can see, some fields consist of a single value (e.g. field 8), while the other fields consist of a number of values delimited by ^ (e.g. field 5, patient name).

In order to be as flexible as possible and achieve a consensus, the HL7

15

committees were forced to define many fields as optional. The downside of this

decision is that you cannot be certain that particular information will be present

in a given message. This is one of the reasons why the same message may vary significantly from vendor to vendor.

Composites Composites are the building blocks of segments. Composites may be either a primitive

data type (string, number, etc.), or in turn be made up of other composites. Composites cannot have a recursive reference to themselves.

The components of each composite are separated by ^ characters, and the

sub-components of these components themselves can be delimited using & characters. Sometimes this can cause problems in non-compliant systems where a & character is entered by a user into a field. This is when the Delimiter Escape Sequences should be

used.

An example of a composite is XPN, which stands for Extended Person Name. This is

used to give a patient name in field 5 of a PID segment. A typical example would be |Slater^Bruce^M^Mr|. The fields have the following meanings:

#

Name

1 Family Name 2 Given Name 3 Middle Initial or Name 4 Suffix 5 Prefix 6 Degree 7 Name Type Code

HL7 Delimiter Characters An important part of the HL7 protocol is the use of delimiter characters. This section will explain what delimiter characters are used in HL7, how to escape delimiter characters and how to define new delimiters. Delimiter Characters The following table lists the delimiter characters used in HL7:

16

Character 0x0D

Purpose Marks the end of each segment.

|

Field delimiter.

^

Subfield delimiter.

&

Sub-subfield delimiter.

~

Used to separate repeating fields.

\

Escape character.

Delimiter Escape Sequences Some user data may contain these special delimiter characters. For this reason, HL7 has a system for escaping them. The system is a little bit unusual in that unlike a language like C, each character has a unique escape sequence.

The following table shows the escape sequences for each of the different characters:

Character

Escape Sequence

&

\T\

^

\S\

|

\F\

~

\R\

\

\E\

Unprintable Hex Characters

\Xxx..\

You will notice that even the escape character itself has an escape sequence. Special Escape Sequences There are some special escape sequences that are validated and passed through without escaping or unescaping:

Sequence/Type Highlighting Sequences

Format \H\ \N\

17

\.br\ \.fi\

\.nf\

Formatting Sequences (starting with a period)

\.sp\ \.in\ \.ti\

\.sk\ \.ce\ \Cxxyy\ (single-byte)

Character Set Codes

\Mxxyy\, \Mxxyyzz\ (multi-byte)

Delimiter Redefinitions If you are new to HL7, one thing that can be really confusing is the fact that delimiter characters can be redefined on the fly in the MSH segment of each message. Each HL7 message starts with a MSH segment, much like the following:

MSH|^~\&|...^...| It is at this point in the message that some HL7 implementations choose to use different delimiter characters. For example:

MSH$%#!($...%...$

ACK Protocol An important part of the HL7 standard is the ACKnowledgment protocol. Every time an application accepts a message and consumes the data, it is expected to send an

ACKnowledgment message back to the sending application. The sending application is expected to keep on sending a message until it has received an ACK message.

If you do not follow this rule then data may be lost in the transmission. If you always follow it then you will never lose HL7 data. Message Control ID

18

The key concept in the ACK protocol is the Message Control ID. This is a unique

number that every HL7 message has in field 10 of its MSH segment. A valid HL7 ACK will echo this ID back in the second field of its MSA segment. This diagram show a typical ACK message with the important fields labelled:

ACK Message You will notice that it consists of two segments: MSH segment

MSA segment MSH Segments The MSH segment is the MeSsage Header segment. Every HL7 message starts with an MSH segment. This segment has the header information about the sending and

receiving application and facility. It also contains the version of each message. More

importantly, it has the Message Control ID of the message, which is the unique ID of each message. For the inbound parsing of each message you want to acknowledge, it is important to store the message control ID and possibly other parameters like the sender, version etc. MSA Segments The MSA segment needs to have the message control ID of the message being

ACKnowledged in the second field. The first field should be a constant, AA, meaning a

positive acknowledgement without errors.

19

DM Software HL7 Manual Page 1. Setting up HL7 (Web Php)…………………………………………………………………...21 2. Setting up an SQL-type database (optional)……………………………………….23 3. Using a Barcode Scanner to input patient information……………………….25 4. Saving to HL7 Server…………………………………………………………………………….26

20

1. Setting up HL7 (Web PHP) There are 2 files that define the HL7 input address and output format, located in the software installation folder:

Software installation \ gdt.ini

\ HL7Format.txt

Gdt.ini 1.A To enter the URL of the HL7(Web Php) input address:

The patient information in the PHP database must be stored using the GDT standard. 1. 2. 3.

4.

Find the line starting with: WQUERY_WEB_ADDRESS=

Delete everything after the equal sign (=), and input the URL of the PHP

database.

When finished, it should look something like this:

WQUERY_WEB_ADDRESS=http://eaz.medinn.med.uni-muenchen.de/demo/ish.php?

Click File -> Save, then close the file.

1.B To change the HL7 PDF output directory:

Before sending in a patient file to the HL7 database, a PDF file of the report must be created first. You can choose the directory where the PDF files will be saved to. 1. 2.

3. 4.

Find the line starting with: HL7PDFLocation=

Delete everything after the equal sign (=), and input the directory you wish to

save the PDF files to, followed by a backslash (\). When finished, it should look something like this:

HL7PDFLocation=C:\CarSc12\HL7PDF\

Click File -> Save, then close the file.

21

HL7Format.txt This file defines the output in HL7 format, here is an example: MSH|^~\&|Holter|[HL7_MSH_FACILITY_NAME]|||[HL7_MSH_CREATE_TIME]||ORU^R01|MSG[HL 7_MSH_MESSAGE_ID]|P|2.4

EVN|A01|[HL7_SOFTWARE_RECORDER_TIME]

PID|||[HL7_SOFTWARE_PATIENTID]||[HL7_SOFTWARE_LAST_NAME]^[HL7_SOFTWARE_FIRST_ NAME]|||[HL7_SOFTWARE_SEX]|||||||||||

PV1|1|a|||||||||||||||||[HL7_SOFTWARE_CASEID]||

OBR|1||[HL7_SOFTWARE_RECORDER_TIME]||||[HL7_SOFTWARE_RECORDER_TIME1] OBX|1|TX|SR Text||[HL7_SOFTWARE_CONCLUSION]||||||F|||||| OBX|1|RP|||[HL7_SOFTWARE_PDF_FILENAME]||||||F||||||

You can modify this file to fit your needs, the words between [] cannot be modified, the software will automatically replace those fields with the actual information.

22

2. Setting up an SQL-type database (optional) Note: This step is only necessary if you intend to use an SQL-type database for your

patient data input instead of HL7 (Web Php).

This interface will support all of the database using ODBC connection, we will give a example using SQL server.

Setup a data source to your database server

Start MenuSettingsControl PanelAdministrative ToolsData Sources (ODBC). Double click Data Sources (ODBC), Add a data source to your Database, Here is a

example to connect to the SQL server.

After you connect to database successful. You need do some setup work.

23

Open C:\Resting12Lead\SetSQLInfo.ini [DB_INFO]

DataSource=SQLDatabase DBUserID= Password=

TableName=Patient [KEY_FIELD]

CASE_ID=Case_ID [OTHER_FIELD] PatID=ID

First_Name=First_Name

Middle_Name=Middle_Name Last_Name=Last_Name Sex=Sex

Height=Height Weigh=Weight Age=Age

DOBYear=DOBYear

DOBMonth=DOBMonth DOBDay=DOBDay

24

3. Using a Barcode Scanner to input patient information 3.1 To automatically input patient information by using a barcode scanner, run

CardioScan Premier, go to System Settings -> Other A tab. Under “Auto Fill Patient Info”, there is a drop-down box that lets you select the desired method.

3.2 After making your selection, click the OK button. 3.3 You can now go into the “New Patient” menu and scan the barcode, or manually

enter the number under “Case #” and press Enter. The patient data will be filled in for you automatically.

25

4. Saving to HL7 Server 4.1 Open the patient file which you want to send to the HL7 server. From the Data Access Choices menu, click “Report”.

4.2 From the Report menu, click “Write to HL7”.

4.3 If you have already registered for HL7 input and output, you can skip to step 4. If

not, you will be prompted to enter your registration code. Fill in your Facility Name and then phone or E-Mail your “DEVICE ID” and “Facility Name” to your dealer. If you click on “Send Information”, the program will create a text file called DMSInfo.txt on your desktop which you can attach to an E-Mail.

Once you have entered in your registration code, click “Register”.

26

4.4

4.5

The “Send HL7” window will appear. Enter the HL7 Server IP and Port at the bottom,

and click “Send”.

Once you get a confirmation message that it was sent successfully, click “OK”. The

patient data has now been saved to the HL7 server.

27