Integration story-limited data traffic rules

 

In the era of cloud computing, centralization is widely used. Multiple hospitals have centralized appointments, centralized registration, centralized storage of clinical documents (indexes), and centralized management of referral services. When medical integration encounters regional applications, massive data exchange becomes the first challenge. Compared with traditional integration scenarios at the department or school level, the expansion of business units doubles the data volume. If reliability is taken into account, the data may need to be double, in this way, remote images and disaster recovery can be achieved through data redundancy. We are used to traditional integration solutions. Such integration solutions may make us feel overwhelmed.

However, after careful analysis, complex problems can be broken down into several simple small problems. As long as you divide the problem to the extent that the traditional solution can be used to solve the problem, and then combine many traditional solutions, you can solve the complicated problem at a lower cost, instead of re-designing an expensive solution to solve the problem. In fact, this is the essence of cloud computing.

Therefore, whether the problem itself can be simplified becomes an important prerequisite for the adoption of this policy. In the Medical Integration field, there may be a rule inherent in the industry. This rule ensures the simplification of large-scale information integration and workflow integration, and also provides the necessary theoretical support for large-scale data exchange. We now call this rule the "Traffic limit rule ":

The amount of data required to complete transactional business activities is always limited, or can be simplified. Only Analytical Business activities can require large-scale data.

The background of this rule is that the data processing capability of the human brain is limited within a certain period of time and space. Especially for roles that execute transactional business activities (doctors and nurses), they need to complete a medical activity within a short period of time. The information you provide is enough, if it is used up, it cannot be used up. Otherwise, it will occupy both computing resources and waste his time. For analytical business activities, such as health sector researchers, they may need a large amount of data, but often do not require results to be provided in a short time. For analytical services that require results to be provided in a short time, the mapreduce processing model has simplified. Finally, the results of the analysis activity must be provided for transactional activities. Therefore, from the perspective of data exchange between systems, the results of the analysis are compared with the raw data, the amount of data has been greatly reduced.

This rule has a typical case and is also a common principle of general information system design: the more results a query returns, the smaller the value it brings to the user. When the number of query results exceeds a certain number, the value of the query results is close to zero. If the user only cares about the number of items and does not care about the content, then only the number of items is returned instead of the content, so that the amount of data required by the user is smaller.

--

Inference/application of the limited data traffic rule in the integration engine: there is always a way to filter and distribute data traffic to different end users.

For centralized reservation, registration, and registration, although the data volume in the system responsible for centralized scheduling is large, the scheduling information required to perform a medical activity is always very limited. Simply put, you do not need to transmit all scheduling information from other medical activities to the terminal. Most of the time, you can always filter and distribute the traffic based on the different needs of the final medical activity performer by time, space, type, and other conditions, for example, only the current time (near this time point) some scheduling information of is provided to him. This shunting can be performed in a hierarchical or time-based manner to simplify the problem.

Recently, we have seen that some hospitals have applied this principle to the extreme. For example, in the radiology process containing technician workstations, technician workstations can not only perform information QA or image QA, you can also combine workload statistics with DICOM worklist generation. At least from the perspective of integration, this information is provided to the terminal only when the imaging device really needs this worklist. Even if this is only a department-level solution, it can also minimize unnecessary cross-system data exchanges.

Of course, Ihe's thinkers may disagree. They always feel that only mpps or images can actually express the workload of technicians, or there are such vulnerabilities or hidden dangers in the technician workstation process. However, I just want to use this case to explain that the amount of data required by the terminal is always limited within a certain period of time and space. You can use this rule to effectively reduce the cost of a solution while ensuring system availability.

--

Inference/application of limited data traffic rules in clinical portals: doctors do not need too much raw data. The value of portals is convenience, and intelligence. Both are indispensable.

In the various slides that promote medical integration, electronic medical records, and health records, everyone is desperately preaching the value of the portal. It seems that doctors cannot work without putting so much data on their desktops. But it is true that no one cares about you. In particular, when the hospital's economic benefits are not linked to the medical quality (or the opposite is involved), doctors do not need the following information: I just didn't get the X-ray you checked last time. I just took another picture.

Well, now we can only believe that everything will get better, and the hook will be hung up sooner or later, as well as the clinical portal. The doctor opened the patient's health archive, which was listed in all the medical documents from birth to the present. Is this really useful? Therefore, you will find that the value of the portal is convenient, that is, centralized display, and you do not need to find it in each system. The second is intelligence, that is, processing information in advance, instead of moving raw data out. Both are indispensable. The processed data, whether it is an evaluation report or a smart reminder, is limited in size, and the scale of the Data Exchange solution is controllable.

--

Therefore, for the query cases mentioned above, the control of query results can not only ensure the realization of user value, but also effectively reduce technical costs. Of course, to further increase user value, you can simplify user input and increase the hit rate. Relying on the search engine technology, you can achieve the ultimate in these aspects, and intelligence is also the key.

To promote it, "limited data traffic" not only reduces technical costs, but also improves user experience. There was a set of image diagnostic solutions. In order to highlight its powerful processing capabilities for a certain image, the original image was transmitted to the workstation for doctors to use this processing function to read the film. Indeed, this solution is supported by some enthusiasts, but more doctors accept another simpler one. The image has been using this cool feature before it reaches the desktop. Even if it is not so cool, it can be well processed with enough features, the output is an image that can be read without too many adjustments. Some argue that this may increase the rate of misdiagnosis and missed diagnosis. However, the market does not seem to care about this. Just like Apple MP3 users do not need to display the lyrics on the screen synchronously, because they only want to surround themselves with good music, instead of locking yourself with a small screen lock. Okay, it's far away.

--

Return to the Integration topic. At the BME Annual Meeting in China last year, I submitted a paper called "Preliminary Study on the integration mode of medical information systems", which summarizes the following design principles commonly used in these medical integration solutions. In fact, these items were all sorted out in the previous year, and they are a little old now. If you have the opportunity to update it, you can now add a "limited data traffic rule: An Optimization Design Strategy for the integration solution ".

1. replication and Migration: Problems Related to the basic data dependency of Medical Systems
2. indexing and information piles: for object reference and management problems between medical systems
3. Private ID: for the local and global problems of medical service entity identity
4. Validation and retry: Fault Tolerance for data in Integrated Medical Systems
5. Requests and notifications: Suggestions on selection of communication modes between systems with Weak Coupling
6. Plug-ins and hosts: A Flexible Assembly solution between Strongly Coupled Systems