In HL7 communication protocol, there are four basic terminology concepts:
★ Trigger event: When an event in the real world generates the demand for data flow between systems, it is called a trigger event.
★ Message: the smallest unit of data transmission between systems, consisting of a group of segments arranged in a specified order. Each message uses a message type to indicate its purpose.
★ Segment: a logical combination of data fields. Each segment is marked with a unique three-character code, which is called segment mark.
★ Field: it is a string and the smallest unit of a segment.
In the HL7 communication protocol, messages are the basic unit of data exchange between systems, and each message has its own message type (V2.4*** You 1 12), which is used to define the purpose of the message. There is a trigger event in the message type. A message consists of multiple segments, and each segment has a corresponding name, which is used to define its content or function (V2.4*** has 138 kinds).
A segment consists of multiple data fields. The first segment in a message is always the message header segment, which indicates the name of the sender and receiver, the message type and the unique message ID number. The composition of the next data segment is determined by the message type. For example, PID segment (patient identification data) includes name, address, social security number, etc. A data field can be composed of multiple parts. Some messages can be further subdivided by event codes. The following is an example of an HL7 message:
Actual information: The patient who was transferred to hospital, Wang Hai, was transferred from the emergency room of 30 1 hospital to the emergency surgery department of the Third Hospital of Beijing Medical University in the early morning of 2002. 30 1 The hospital referral system sends the patient referral information and basic information to the Third Hospital of Beijing Medical University: Zhang San, ID number1108197404012346, male, address: No.38 Fuxing Road, Haidian District. After converting to HL7 message:?
MSH|^？ ~ \ & amp| 005 Emergency Room | 0802 30 1 Hospital | 0052 Emergency Surgery | 080 1 Beijing Third Hospital?
PID ||| c |||| 330108197404012346 |||| Zhang San | 1974040 1| Male ||||| c | No.38 Fuxing Road, Haidian District
PV1||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |||| || || || | | | | | | | | | | | | | | | |
Where MSH is the message header.
EVN is an event type?
Is PID the patient's identification?
Is PV 1 a patient's visit?
& ltcr & gt； End a paragraph, the performer can't change it. The working principle of HL7 interface engine is shown in the figure on the right:
★ Sending/receiving module: TCP/IP communication protocol is supported, and the HIS system sends electronic medical record information to the data center, and the information format is a string format conforming to HL7 standard. The data center receives and parses the HL7 information, stores the parsed information in the database of the data center, and returns an ACK confirmation message to the sender after completion to confirm that the information was sent successfully.
★HL7 adapter module: realize the mutual conversion between string format data and XML format, check and verify the information format, and ensure the correctness and integrity of sending/receiving medical record data.
★HL7 API module: provides an application interface conforming to HL7 standard, and the medical application system can call the interface function and fill in the parameters according to HL7 standard format, thus sending data to other medical application systems. The module can also call the Windows component application program conforming to HL7 standard, and transmit the medical information data to the medical application system, so as to receive the data from other medical application systems.
★ HL7 resource module: supports various practical HL7 medical information events, such as checking doctor's orders and referring patients.
★ Mapping module: provides translation and comparison function, which can be customized according to medical application system.
The concept of HL7 interface engine can be understood as a set of procedure call functions or controls that support HL7 communication. The application program provides parameters according to the provisions of HL7 interface engine, and the communication between modules is completed by HL7 interface engine. In developed countries abroad, the mainstream medical information integration technology of 20 12 is "HL7/XML interface engine", which is a medical information integration technology integrating various technologies, and is used to translate the data of various hospital information systems into XML information formats conforming to HL7 standards, so as to realize information sharing and exchange among various medical and health information systems. To deeply understand the principle of HL7 interface engine, we have to study it from the perspective of data communication. In data communication, there are two levels of data exchange applications. The first level of data exchange application is to deal with the existing information and just "exchange" the information data existing in the existing system. The second level is based on the integration of data communication between different systems, aiming at realizing the seamless connection of data communication and data exchange applications between different systems. This level of data exchange should not only exchange all kinds of result information, but also exchange all kinds of process information, so as to achieve the purpose of interaction between systems. Based on the above two levels of data exchange, there are two ways of data exchange based on HL7. A "HL7 engine" mode, the main purpose of which is to make the irreplaceable system that users used to run have the communication ability of HL7. The other way is "HL7 Ready", that is, in the whole system, the interface protocol of HL7 has been designed and processed in each application terminal, and each terminal should be able to receive and process HL7 messages and carry out related processing. Theoretically, real-time interactive operation between systems can be realized, and each other can actively obtain the data information provided by the other party when needed. This organization and the provision of medical services are the result of information concentration. It is generally believed that the efficacy of medical operation is influenced by the automation degree of information management function. Many people think that if health care providers can't automate their information systems, they can't compete effectively in the medical market in the 1990s.
In the past 20 years, medical institutions, especially hospitals, have begun to realize the automation of information management. At first, it developed towards reducing paper handling, increasing capital flow and improving management decision-making. In the next few years, the focus of development will be to rationalize and transform clinical services and auxiliary services, including clinical (in hospitals and other inpatient environments) and patient-oriented (in non-fixed settings) systems. In recent years, the focus has been on the development and integration of all information related to the transmission of patients' life care information (such as electronic medical records). It is conceivable that all or part of electronic medical records will be electronically communicated at any time and place.
Now, general hospitals have installed computer systems, which can complete the functions of admission, discharge, transfer, clinical examination, radiation, billing and bookkeeping. These applications are usually developed by different suppliers or organizations, and each product of these suppliers or organizations has a very special information format. With the gradual expansion of hospital information management business, the key data sharing system came into being. Integrated systems made by selected suppliers are designed to realize most medical information management, even if they are not perfect. These systems can be designed as centralized or distributed structures. However, to some extent, such systems are complete, and their purpose is to reduce the need for external data exchange standards (such as HL7).
However, institutions that develop or acquire applications from a single department on a modular basis will be under great pressure. One of the sources of pressure is that a wide range of manufacturers can't provide the needs of some special departments (or all of them) well. On the other hand, the pressure is that the overall institutional environment of the hospital needs to be developed through a series of growth and the determination of various departments, rather than a single revolutionary acquisition. Stress will occur in an environment that contains an integrated system or a complete discrete system supplemented by various departments.
Network technology has become an available computer application program, which is closely related to functional synthesis and technological change in medical environment. But these applications are not developed through a similar logic system, but are determined by the market structure, so they are often very special. For the interface of these applications in the network environment, extended special positioning programming and program maintenance are necessary. This requires considerable expenses for users/buyers, which hinders the innovation of sellers' employees, such as the development of new products. If the network interface standard in medical environment is available and accepted by suppliers and users, the need for special address interface work can be greatly reduced.
Generally speaking, it is important that suppliers and users no longer face the problem of supporting inconsistent processing/communication structures. On the contrary, a framework of minimum incompatibility and maximum information exchange between systems is developed. It is suggested that HL7 should be built as the highest standard in these fields to promote public norms and normative methods. This is the real development and guarantee of computer application standard interface in medical institutions. The specifications of this standard are formulated according to the objectives specified a priori. Future extensions of standards should also support these goals.
The purpose of HL7 is to promote communication in the medical environment. The main goal is to provide standards for data exchange between medical computer applications, so as to eliminate or greatly reduce user interface programming and program maintenance, otherwise these programming and maintenance are essential. This main goal can be described by a series of goals:
A) This standard should support data exchange between systems used in a wide range of technical environments. Its implementation can be applied to many different programming languages and operating systems. It also supports communication in a variety of communication environments, and can support interconnection from a complete OSI and Layer 7 network stack to an incomplete environment, including basic point-to-point RS 232C, and data transmission through batch media (such as floppy disks and tapes).
B) Direct transmission of a single process and file transmission of multiple processes should be supported.
C) The maximum possible degree of standardization should be consistent with the use of changing positions and some data element formats. This standard should meet the needs of special address changes. This includes site-specific tables, code definitions, and possible special location information segments. (e.g. segment HL7 Z)
D) This standard must support the ever-increasing new requirements for validation. This includes supporting the introduction of extensions and publishing them in the existing operating environment.
E) This standard should be based on the experience of existing product agreements and accept a wide range of industry standard agreements. It should not support certain interests of a specific company to the detriment of other users. At the same time, HL7 seeks to retain such a unique feature that independent developers can bring to the market.
F) When it is useful and related to the hospital's internal information system, the long-term goal should be to define the formats and protocols of all applications in the medical environment.
G) The essence of different business processes in medical delivery system is to prevent the development of general programs or data models supporting HL7 target environment. In addition, HL7 does not preset the structure of medical information system, nor does it try to solve the structural differences between different medical information systems. At least for these reasons, HL7 can't be a real plug-and-play interface standard. These differences in HL7 are more like negotiation protocols.
H) h) The main interest of HL7 Working Group has shifted to the application of standards as far as possible. In order to achieve this, HL7 has also developed a grassroots organization that supports the unanimous voting process, and has been recognized by American National Standards Institute (ANSI) as an Authorized Standards Organization (ASO).
I) cooperation with other relevant medical standards (such as ACR/NEMA DICOM, ASC X 12, ASTM, IEEE/MED VII, NCPDP, etc.). ) has become a priority activity of HL7. Since the establishment of 1992, HL7 has been participating in the process of ANSI HISPP (Health Information System Planning Working Group). Since March 1987, HL7 working group has met about every three to four months to develop and discuss this specification. The working group added each functional interface under the development specified by the Committee, and also assisted the Committee in specifying all the control structures and different management of the Group. These committees are responsible for compiling and maintaining the chapters in the HL7 interface standard. In addition, different interest groups are often formed within HL7 to develop his ideas and launch some special views that are not involved in special committees. If a special interest group
If HL7' s action is approved, and it is considered necessary to add a new chapter after discussion, they can request the Chairman of HL7 Technical Committee and the Executive Committee to form a technical committee.
At the first three meetings, the draft of standard version 1.0 was prepared, covering the structure of all interfaces, ADT, doctor's advice input and display-oriented query. Although the patient payment system is considered to be very important, the time frame does not allow it to be introduced in the first draft. This draft appeared in the plenary meeting of 1987 10.08 held in Tai Sen, Virginia, and all groups attended.
Version 0 then prepared the plenary session of Cape Tai Sen, which appeared at the second plenary session in Tucson in September. 1988. Since the Second Plenary Session of the CPC Central Committee, the editing and revision of the three versions of 2. 1, 2.2 and 2.3 have never stopped, and the working group has grown to 300, far exceeding the original 12. The following contents are realized:
A) Detailed specifications of different functional ranges have been refined and expanded.
B) Established formal contact with several other standards: ANSI HISPP (Medical Information Standards Planning Group), which was responsible for coordinating medical standards, was later replaced by ANSI HISB (Medical Information Standards Committee); ASC X 12N team is responsible for external medical standards, ASTM E31.10 team is responsible for clinical data exchange standards, ACR/NEMA DICOM team is responsible for other standards related to radiological information systems, RIS), IEEE P 1 157.
C) Modify the general control structure on the basis of remarks to adapt to a wide range of different communication environments and promote cooperation with other standard groups.
d)。 Added a chapter to describe the interface of patient billing system.
E) Chapters describing auxiliary results, clinical trials, product experiences and waveform data reports have been compiled, which are coordinated with ASTM 1238-9 1 standard and directly and actively coordinated with committee members of ASTM E31.1.
f)。 Added processing set chapter supporting synchronous transmission of master files of related information systems.
g)。 Chapters on application program interface supporting medical record function, including copy management, chart positioning and tracking, lack of analysis, and content and information release.
h)。 Chapters on news have been added, and communication on various events has been supported through reservation service or resource utilization.
I). Related chapters have been added to define the message set of referral communication between independent medical entities.
j)。 Computerized data dictionaries and other information components have been created for all databases. Appendix A includes cross-references and other information generated from the electronic data dictionary.
K) Contradictions and errors found in previous versions 2.0 and 2. 1 have been marked and recorded in version 2.3.
L) It has been widely added in the chapters of doctor's advice)/login and clinical observation, including data elements, pharmacy doctor's advice, and directional results of management interface.
M) Message acknowledgements have been extended to include independent enhanced modes, which define acceptable acknowledgements. When this confirmation mode is allowed, it is obvious how HL7 can support any environment (such as store and forward service, "interface engine" other than execution service, etc.). When media exists in a network with inherent time delay. Direct acknowledgement is used in the sending system, which sends messages from request to retransmission.
There are differences between the definitions of HL7 abstract messages. This abstract definition fully conforms to the definition of the seventh layer (application layer), which is the HL7 coding rule, and is used to convert abstract messages into strings containing real information. In fact, these coding rules are a potential choice suggestion, which has been completely defined in the definition of the sixth layer (presentation layer). There is no definition of the sixth layer (such as ASN. 1 basic coding rules (BER) of ISO).