Integration story-essence of Integration

 
On a business trip, I bought a book for my lover who is keen on art design called "design in design ". The recursive form in the title of the book makes it easy for people familiar with programming to feel lost. The sentence in the preface is even more intriguing.

"It is not an understanding that can be defined or described in words. Instead, it is necessary to challenge the authenticity of known things before they can be further understood ." -- Original research zai

After several stories, the field of medical information system integration is no different from the tip of the iceberg. If the whole iceberg can be recorded one day, it cannot be known as understanding in the eyes of the design master. Maybe I can follow the method he recommended and try to make the integration uncertain to find its essence.

---

In the article "integration story-dynamic data migration", I mentioned that the dynamic data migration method was actually inspired by discussions with colleagues. I remember when we studied the his encoding system together, we found that it was very different from the encoding in RIS. In fact, RIS uses a field to represent the check method. It also contains the check position and position, and the check position and position information in his are split into two fields, that is to say, one of the RIS codes must correspond to the two his codes. Based on this fact, at least the LUT solution is theoretically feasible. Although the workload is surprising compared with the dynamic solution, the dynamic solution can solve the problem through static ing. As a result, I began to think about the extent to which the two heterogeneous systems are different. integration became impossible, or, in other words, what conditions were necessary for integration to become possible.

There is no need for much reasoning or verification. I can probably guess that the premise of integration should be a semantic similarity. This premise should exist no matter how large two interoperable systems are, or between a primary program and a subroutine. For example, to call a function, the caller must know what to pass to the called party, And the called party must also know what it will get. This is a bit like contract in SOA. Of course, the contract of SOA should be more specific and contain both syntax and semantics so as to meet the so-called "boundary clarity" requirement. Our usual integration work is actually about syntax conversion, which should be semantically immutable. For example, we extract the DICOM (,) field and place it in the patientname field of the HL7 message. The data representation method has changed, however, the image system knows that the patient name is stored in the DICOM field, and the clinical system assumes that it should be able to get the patient name from the HL7 field. As a semantic patient name, it will not change throughout the process, even if its syntax is changed from simplified to traditional Chinese, from Chinese characters to pinyin, even if the positions of surnames and names are reversed, the integration still uses the names of patients rather than gender, age, or others. Of course, there are also special cases. For example, in some systems, we can splice the age information into the name and send it together in a field, but this is what the users of this system expect. What they want to see on the interface is the patient name and age stored in two fields in the source system. Another special point is that, for example, to determine whether a source string contains a special character to trigger an event in the target system, the essence is the same, whether to trigger an event. If it can be defined as a Boolean value, people will explain this Boolean value, that is, semantics, it should be the same as people's explanation of "whether the source string contains this special character.

The initial motivation for syntax conversion is to make up for the Information difference between the two systems and transmit a certain information from the source system to the target system, syntax conversion is only a means to ensure normal transmission. This is data integration in the general sense. In this sense, other workflow integration and desktop integration should be built on the basis of data integration. They usually create time sequences on the original disordered data streams, or append some special semantics. The purpose is not simply to share data between multiple systems, but to make multiple systems work collaboratively, whether in a distributed environment, or on the same workstation.

---

So we were surprised to find that there seems to be no great distance between the broker and the workflow engine. In the traditional sense, brokers perform data format conversion, field ing, record, and merge splitting, all of which are data integration tasks. On this basis, the workflow engine may only need to add configurable state machines and configurable processing logic, and these will further enhance the broker's functions, such as performing routing, and distributed transactions. This is really an exciting thing.

However, it is frustrating that almost all of this can be found in the BizTalk Server, and we have to follow Microsoft in the end. Not long ago, Microsoft integrated the workflow engine and visualized process editor. net Framework 3.0, their demonstration at the Microsoft Technology Conference, can even provide an illusion that all program logic can be achieved by drawing a picture on Visio. Other software giants should also have EAI tools similar to BizTalk. I don't know much about it, but I think Microsoft should always be doing well in terms of simplicity and ease of use. So I still expect Microsoft to split up BizTalk er one day, so that we can write trivial XSLT files like drawing on Visio.

Recently I heard that in a file recently issued by a medical device management department, it seems that broker is also a medical device that needs to strictly verify its reliability. From the point of view of its important role in system integration, such a provision seems unreasonable. Nowadays, the whole human civilization is increasingly dependent on software. Software omissions may also lead to medical errors, such as broker accidentally increasing the dose of Radiotherapy by a factor of ten. It seems a bit alarmist. However, if a hospital wants to use BizTalk Server during integration, should Microsoft also use this giant object to the medical device management department for verification.