1. Understanding of HL7 (Basic Concepts in HL7) (conceptual approach) __HL7

HL7 in chapter II (Control) defines some basic concepts as follows

1.trigger Events

The Standard is written from the assumption, the real world of healthcare
Creates the need for data to flow among systems. The Real-world event is called the
Trigger event. For example, the trigger event a patient be admitted may cause the need for
Data about that, patient to is sent to a number of the other systems. The trigger event, an
observation (e.g., a CBC result) for a patient be available, may cause the need
Observation to is sent to a number of the other systems. When the transfer of information is
Initiated by the application system which deals with the triggering event, the transaction
Is termed an unsolicited update

This standard, if created in a real healthcare world, requires the flow of its data between multiple systems. Real-world events are called triggering the world, for example, a patient's hospitalization triggering event may cause the hospitalization data to flow between multiple other systems, and this triggering event, by observing that a patient is available, may lead to the need to send its observations to other systems, when the transmission information is launched through the application system, This trigger event needs to be handled, which is defined as an active update;

Understanding: In embedded development, we always encounter interrupt events, when the interrupt event is produced, we will do some other operations, and this interrupt event is a trigger event, only the trigger of this interrupt event, may be the timer expiration, there may be an external interrupt, and in the HL7, The triggering event was caused by the creation of new data in the medical system.

Acknowledgments:original MoD

Confirmation: Original mode

When the unsolicited update are sent from one system to another, this acknowledgment mode
Specifies that it is acknowledged at the application level. The reasoning is, it is
Not sufficient to know the underlying communications system guaranteed delivery of the
Message. It is also necessary to know the receiving application processed the data
Successfully at a logical application level;

However, the active update is sent from one system to another, and the confirmation mode specifies that the active update message is confirmed in the application layer, and the sample set
The reason for this is not only to ensure the delivery of information in the basic communication system, but also to know that the receiver program succeeds on the logical application layer
To deal with the data.
Understanding: It means that when you receive the data that triggers the world, I need a response confirmation at the application level to ensure that the data is delivered successfully.

The acknowledgment may contain data of interest to the system that initiated the exchange.
For example, if a patient care system has processed the trigger event a lab test is ordered
For a patient, it could send a unsolicited update to a lab application identifying the
Patient, the test ordered, and various other information about the order. The ancillary
System'll acknowledge the order when it has processed it successfully. For some pairings
of patient care and ancillary department systems the acknowledgment may also include the
Ancillary identification number that is assigned. (HL7 does not require order Entry and
Results Reporting applications to interface into this manner, but it supports those.

The model uses data that is of interest to the system to begin information exchange. For example, a patient service system handles triggering events--patient bookings
A laboratory test, the system will send an active update (request) to the laboratory application to confirm the patient, as well as other scheduled information.
The secondary system will successfully process the check booking information. In some patient services and their ancillary systems, the validation model also includes system allocation
's confirmation number. (HL7 does not require the scheduled login and results reporting program to work in this way, but it supports this side

The HL7 Standard makes no assumptions about the ownership of data. It also makes no
Requirements of it own on the subsequent action of the recipient of data, nor does it
Any assumption about the design or architecture of the receiving application system. The
The scope of HL7 is restricted to the specification of messages between application systems,
And the events triggering them. HL7 does not explicitly support, but can is used with,
Systems that support store and forward and data broadcast facilities (the HL7
Implementation Support Guide
The L7 standard does not make any assumptions about the ownership of the data. Not only does it have no requirement for a series of behaviors to accept data, but it also
No provision is made for the design or construction of the receiving application system. The HL7 limits are limited to specific information exchanged between application systems and
The corresponding triggering event. HL7 does not have a clear support system, but it can be applied to systems that support storage, forwarding, and data disclosure. (see
HL7 application support refers to
The HL7 Standard makes no functional interpretation of the requirement that a system commit
The "data in a" to its database before acknowledging it. All this is required is
That's receiving system accept responsibility for the data, providing the same integrity
Test that it would apply to data from any source. To continue the prior example, the
Ancillary system may acknowledge the "order" after placing it in a input queue, expecting to
Fully process the order in its database at a future time. The only assumption was that
The input queue is maintained in the same level of integrity as the database
HL7 requires a system to submit data from the information to its database prior to the confirmation of the information, but this requirement has no functional
Explain. What is required is that the receiving system be responsible for the data and provide a holistic test to apply to any source of data. We're going to go before
Example: The auxiliary system can put the reservation request into an input queue sequence, and then confirm it, and deal with it in the future.
The predefined information in the database. The only assumption is that the input queue is preserved in the same layer as the database form, that is, in the same level as the entirety

acknowledgments:enhanced mode
Confirmation: Enhanced mode
He HL7 acknowledgment paradigm has been extended to distinguish both accept and
Application acknowledgments, as the conditions under which each are required. With a
Positive accept acknowledgment, the receiving system commits the message to safe storage in
A manner that releases the sending system from the need to resend the message. After the
Message has been processed by the receiving system, a application acknowledgment may
Used to return the resultant status to the sending system
7 The validation paradigm has been extended to distinguish between acceptance confirmation and application level validation, as well as the respective requirements. For a correct
Acceptance (information) confirms that the receiving system submits the information to the secure repository, which allows the sending system to be exempt from resending information. When
After the information has been processed by the system, application level confirmation will give the (information) sending system return processing result status

Querie
Query documentation including messages, segments, special protocols, implementation
Considerations and examples have been moved to Chapter 5. The unsolicited display messages
were also moved because their message syntax are query-like in nature

The query document includes information, information segments, specific protocols, implementation considerations, and examples (see chap. 5th). Unsolicited display information is also
Transfer because the syntax of the information is essentially consistent with the query