Software Design Model in the Medical Information Field

If the previous discussion on the reliability of medical information still leaves some commercial taste (although it is nominal to return to the technology, it still involves some business issues); then, this article intends to continue with the technical aspects, discuss the design model, and:

-To discuss the design patterns in the integration field, we should start from the software perspective of the entire medical industry, but not embedded systems;
-These are common technical solutions that are not necessarily optimal or involve any trade secrets, because some public publications and network communities have descriptions.
-These technical solutions will not be clearly classified or comprehensive. Most of them are just impressive in their memory. After all, they are just essays, not papers.

It should be noted that the other side of these information systems is to be examined. This side shows only technical abstraction and does not have a complete business landscape.

--

Before entering the topic, I still can't help complaining about the impetuousness of the industry, but also my own warnings.

I recently attended a lecture called a software architecture master. I had doubts when I saw the lecture. I listened to the lecture for five minutes and verified this question, after the lecture, I heard comments from my colleagues, which strengthened my judgment. However, I only listened to the audience for five minutes, but it was not easy to comment. I just felt that the metaphor used in the speech almost covered up engineering practices. Software is a metaphor for the proliferation of fields, from building a house to making movies, from aircraft design to automobile factories, everything is related to software withdrawal. Is the status of software so low that it is necessary to use so many things to support the facade? This time, even Chinese culture is involved.

In fact, I have not heard many lectures on software architecture, and I cannot make a comprehensive comparison. I just feel that Mr. Wen has better integrated the design theory with engineering practices, it is also enlightening. I recommend Yu Qiuyu to listen to Chinese culture. If Mr. Yu was talking about the software architecture one day, I 'd like to hear about it.

Another aspect of the industry's impetuousness mainly occurs between sales and technical personnel. This should be a common topic in the programmer's circle. I can't help but stir up the old meal. In short, the sales staff always think that the technical staff is too idealistic, and the technical staff think that the sales staff is too realistic. Generally, the sales staff can say the same thing, and they are more aggressive. Most of the technical staff have not said this, people are also nice, and the results of this debate can be imagined.

This phenomenon may be more obvious in China. After all, China is still at the low end of the IT industry. The situation outside China is unclear, but there are at least some high-end technical forums, so that the technical staff can talk to themselves. However, it is widely accepted that Western culture is more respectful of technological innovation, and eastern culture is more important to interpersonal communication. The founders of many American companies (such as Kodak, GE, and Ms) are first technicians, some even technically savvy technicians (many internal documents may show that billgates is not a technical genius, but it is only a result of his transformation into a business employee ), it was when these people were technicians who created these commercial platforms, and then the commercial staff finally made these platforms a success.

However, in a technology-based company I once worked for, both technology and market strategy are right, and even relatively leading in China, the correctness of some ideas has also been proved by the development of the industry. However, when implementing specific sales strategies and solutions, they have met almost crazy competitors who provide free software to customers. Note that this is different from the Internet industry. This free service is not an innovation of the business model, but a hell of a low service quality and high political return for the entire market. This is the reality that many sales people talk to us all day. These sales staff like to study the relationship between insiders and people in Party A's organization, rather than studying how the technology they are selling will change the world: This kind of trade-offs just creates their impressive performance, and our living salary.

Another interesting phenomenon is that sales staff and it pro (O & M personnel) are extremely sensitive to numbers. The former pays special attention to the amount of money, and the latter pays special attention to the parameters of equipment, there is usually a natural ing between the two numbers, so these two kinds of people are often quite connected. Occasionally, they will discuss technology. Every time they talk about it, they will say, hi, these are the lives of programmers.

However, all the people mentioned above are indispensable in every successful organization. The role of the team is to make all sorts of strange people work together, the final result is 1 + 1 greater than N.

To sum up, everyone should do their best. Everyone should respect the work of others, especially innovative work.

--

We should start with front-end applications, such as various workstations.

Not long ago, we had to develop a technical solution to support availability. I checked the SEI book (although somewhat academic suspect ), the architecture design decisions used to support availability are closely related to modifications (Application flexibility) to a certain extent. The assumption is that after the program is written, the user and UI Designer frequently request to modify the user interface. In retrospect, it really makes sense. In the early days, the user interface of many industrial software was finalized basically at the stage of custom development. Therefore, some companies will also allow engineers to stay in the hospital at a certain stage of the project. Although this method will increase the difficulty of quality control and project management to a certain extent, it is the best way for engineers to acquire domain knowledge.

The well-known MVC is one of the most common design patterns used to support availability. Later, it was developed into MVP and mvvm, and their core ideas have not changed, both allow the interface and logic to be separated as much as possible. Many of the technologies we see are based on this idea, such as the document view model of MFC and the code behind of ASP. NET. Of course, there are also some best practices in interface design, such as necessary support information, organized interface partitions, and step by step operations, these are usually considerations for detailed design.

If you continue to study the availability, you need to go out of the computer screen frame and consider it from the perspective of the doctor's entire working environment. For example, many imaging diagnostic workstations provide a display combination of 1 + N, while many clinical workstations dig holes in the doctor's desk to embed the display inside, the doctor is working on a glass plate he is used. This creates an interesting result. Some doctors always look up, while others keep their heads down. In the past, a radiology doctor complained to me that the vertical screen display was too high and it would have been cervical spondylosis for a long time. However, we could not sell him a higher chair.

If many people prefer MVC as an architecture mode, the state mode should be one of the typical design modes used for front-end applications. Especially for some complex user interfaces or communication interfaces, such as the mouse control on the Image view interface of the image workstation, and the network communication module that implements the DICOM protocol. The implementation details will not be further discussed here. In short, the state machine implemented in the State mode has a major benefit: when there is a new State or new changes need to be added, it is very convenient to modify the code. The principle is that the complex conditional judgment statement is replaced by a virtual function table. In addition, the performance provided by the state mode can meet the needs of this field. In other fields, such as embedded devices, the object-oriented State mode may seem bloated; in computer games, some people may prefer decision trees rather than state machines. When it comes to user interfaces, many people will think of command mode and Strategy Mode. Of course, they are also very useful. In many cases, we may use them accidentally. But in fact, the Undo function seems to be a stunt for many workstations. I have seen many doctors use the habit of directly pressing the reset key to return to the initial state if the image is disordered, then start the call again. Of course, more often, they don't want to adjust it at all. The patient traffic is too large. Just look at it with the default ww/WC or curve. After all, doctors are doctors, not flat designers.

On the his or lis workstation, which is dominated by text processing, the state mode is useless. Maybe these front-end applications need some implementation modes instead of the design mode. For example, when loading large-scale data, the background thread is used to achieve interactive interface interaction. There is no complicated thread synchronization problem here, note that Gui objects cannot be accessed across threads. Therefore, avoiding multithreading as much as possible is the most basic and difficult-to-follow design principle. At least, if it is in the window loading stage, you can put the data loading work into a timer event. After the window is painted in a few seconds at, load the data and constantly update the interface, in this way, the user may feel better. However, in most other cases, the background thread is still required, and now there are more and more dual-core computers. It is a bit difficult to open a few threads.

In early applications, MFC provided natural convenience for interaction between different modules in the interface program. It mainly relies on the message loop of windows to serialize interaction processing, instead of using VB and winform, programmers are accustomed to more direct and crude synchronous calls. WPF goes further in this regard. It uses the so-called dispatcher to replace winform invoke. It is said that it can avoid searching the control tree for faster calls. At present, I still have a superficial understanding of WPF. I just heard that the entire window only occupies one handle no matter how many controls are in it, and allows developers to make full use of Asynchronization (that is, multithreading) achieve better interaction. This avoids calling doevent to process interface response during long-time processing like winform.

I used to encounter a depressing problem when using winform, which is related to doevent. The radiology domain usually has objects of patient, examination, sequence, and image levels. On the user interface, you usually need to display these objects in a multi-level list, generally, we do not use tree views too much on the doctor's interface, because it is easy to use a list when operating large-scale data. In this classification list, a common interface logic is to show the patient's health check in the examination list when selecting a patient in the patient list, when a check is selected, the sequence list is refreshed, and so on. Because most early PACS servers do not support multi-level queries, these objects can only be expanded at the first level. Therefore, a network communication occurs each time the next level of data is loaded, it takes a little time. To maintain interface response during this period, we initially called doevent every time we load an object to distribute all accumulated messages in the current message loop. This method has a serious consequence. If the user selects another patient immediately after selecting a patient, then the two patients will repeat the exam in an unpredictable way in the exam list. Because doevent is called before the first patient is processed, the mouse event of the selected second patient is processed.

There are many solutions. Pessimistic approach: Do not use doevent, so that doctors can endure it when the network speed is slow. Rogue method: instead of using doevent, the server is allowed to support multi-level queries. The first query is a little slow and starts quickly. Because doctors generally do not set too broad query conditions (generally in recent days, or specify an ID), they do not feel slow queries. Most PACS use centralized storage, that is, the collected images are collected to the PACS server with the same advanced technology. These servers generally support multi-level query; if the doctor has to direct the query destination to a device or server of another vendor, the ball can be kicked. A truly responsible method: You can use doevent, but you need to queue the selected event with the mouse on the list in some way. There are many queuing methods and you can write them by yourself, you can also use a thread pool. Sometimes. NET provides methodimploptions. Synchronized Locking can also be used as an easy-to-use queuing mechanism.

As mentioned above, some desktop application models should not be forgotten. So far, regional medical care has not been popularized, and the focus of Medical informatization is still on enterprise-level applications in hospitals. In addition, most of the user interfaces in the medical field have complex interaction functions, whether doctors write medical records, take medical orders, watch images, or register doctors to input patient information, it seems difficult for a web-based stateless infrastructure to build a user interface. In the hospital system, web is usually used in several aspects. One is to let the director and others look at the report, or let the irrelevant persons in other departments look at the report or doctor's advice to handle the progress; the other one is to let the Web carry some ActiveX controls with complex functions, or be responsible for the deployment of front-end programs, and call it smart clients. These are actually extensions of desktop applications.

Now, the tide of SaaS and cloud computing is pushing traditional enterprise applications to the Internet, the software industry had to make a major adjustment in the business model and Technical Architecture (see the previous articles ). In this wave, the technology rookie in the front-end application field should not belong to Ria. I remember when I was writing "integration story-desktop integration", I once expressed my views on ASP. net's PostBack and Ajax have different opinions. So far, I have insisted on my own views, and I deeply feel the painstaking efforts of WPF to return to the DOM programming model. For many years, this implementation mode exists in non-mainstream browser scripts (that is, the script is displayed on the tag interface, and the Code for implementing the function is connected by onclick and other methods ), it may become the basis of our next-generation user interface. The deployment mode of RIA perfectly matches this implementation mode. It runs the original rich client program host in the browser and has local memory, in addition, it can interact with backend services in a variety of ways and is easier to deploy than smart clients. On the other hand, Ria will prompt the Web to return to its true source, while PostBack and Ajax will face a survival crisis.

--

Now let's take a look at the backend applications. Here we use the frontend and backend, instead of the server and the client, as a distinction, mainly because the former seems to be more logical layer, and the latter prefers physical tier. Many medical applications, such as the stand-alone workstations and small-scale solutions that many domestic PACS vendors rely on in recent years, the concept of tier is far from obvious.

However, no matter how big or small the PACS is, as long as we look at the front-end interface and the back-end side is a little more forward, we will inevitably encounter a common problem, that is, how to manage these huge image data is so huge that you must consider every aspect of its transmission chain, from video storage, to memory, to disks, to networks, to the server, to raid, to the optical disc tower or tape library. Therefore, a complete PACS technical solution is usually completed by the collaboration of experts from various aspects, including displays, servers, networks, storage devices, printing devices, and software. Software developers usually focus on two issues: how to respond to complex user operations on the front-end interface, and manage these images in the memory, disk, and network based on the semantics of these operations. One is on the backend transmission chain, how to Implement the image prefetch logic, which is usually driven by signals related to some business processes of RIS, allows images to flow intelligently between the online, nearline, and offline storage of local disks, networks, and servers.

Someone has done some systematic research on the Resource Management Mode in PACS, and wrote a book called pattern-Oriented Software Architecture: Patterns for resource management. Unfortunately, I have never had time to study it carefully. It seems that I remember the proxy-like mode mentioned in it, effectively managing the relationship between the preview image and the real image on the user interface. There should be other models in the book, so you can try again later. There are also some simple implementation modes that have been used before. These modes are usually related to the image type. Some early PACs were sold together with devices. These PACs are usually called minipacs to distinguish them from department-level and full-hospital PACS. The workstations developed by PACS vendors that started from General devices are used to open CT/MR tomography, sometimes very slow. Because there are usually not many images in a general-purpose exam, and each image is huge, the doctor thinks waiting for a few seconds is not a big problem, therefore, they usually load the entire image to facilitate the application of the hanging Protocol. However, for the faulty image, the doctor will certainly want to start displaying it when loading it to the first image, then, you can browse the background and load it. After loading all the data, click the button to select a specific suspension protocol. Because the fault image is very small, there is basically no latency on the interface. On the other hand, for workstations developed by PACS vendors that develop tomography images, ww/WC adjustments are sometimes very slow when the mouse is used to adjust the general image, I feel that the screen is shaking, and no matter how it is adjusted, it is better than other workstations. In fact, when other workstation uses the mouse to adjust the ww/WC, it adjusts and displays an image with a slightly lower resolution, so that when you adjust a large image, user response is better, and for some general images, the curve (LUT) instead of the linear ww/WC for display and adjustment, the image quality may be much better. In addition to these models closely related to the medical field, as long as they are used for image display and processing, they will all use implementation models unrelated to some fields, for example, the dual-buffer is used to avoid screen flickering during refresh caused by Direct Screen Writing.

In addition, as the number of CT rows increases, sometimes (for example, during consultation) the size of images to be loaded on the workstation will far exceed the physical memory, at this time, you need to consider how to manage this part of data that exceeds the physical memory (rather than ideally reducing the front-end pressure through a complex process based on key objects ). For some non-displayed Fault Images, temporarily release them from the memory (or do not load them at all ), it may be better than leaving them in virtual memory (a disk area managed by the operating system). It seems that the cache of the file system will also help us reduce the time to reload images. However, this will lead to new problems. How can we maintain the display status of images temporarily released? Can the cache of a file system ensure sufficient performance for a dozen images?

In the end, it is difficult to reconcile the differences between loading and browsing methods of different types of images and the differences between doctors in different medical fields on the use of the same types of images. Therefore, we can only do some decomposition to reduce the technical coupling of some unrelated business factors. Specifically, different types of images are placed in separate modules. Each module has its own loading, display, processing, memory management logic, and special browser/report tools. Then, these modules are assembled into the basic framework of the workstation as plug-ins. In this way, the basic framework can encapsulate shared modules, such as network communication logic and the frontend Implementation of the Hierarchical Storage logic mentioned above, so as to improve the development efficiency of new functions. In terms of business, it can meet more image display and processing requirements, so that workstations can be used in different fields, not just radiology, there are also orthopedic, surgical operating rooms, consulting centers, and even special clinics (such as dental or veterinary, medical staff in different fields can also use modules tailored for their fields.

Not long ago, when I saw the DICOM supplement 118 (application hosting) being discussed, I was very touched. I remember writing an article a few years ago, an open architecture for medical image workstation, Spie Conference 2005, which said similar things. At that time, We imitated syngo.

Application hosting is an interesting thing. It looks a bit like ccow at first. In fact, it is more like an interface standard specially designed for image workstations, so that different vendors can even work collaboratively in the same process. What does it mean for us if it turns into chapter 5 of DICOM? First, the competition among mainstream PACS vendors will focus on the platform, rather than a single product. The overall solution is no longer a simple combination of several products, but an integrated platform that extends from the back-end cloud to the front-end plug-in framework, and the modules provided by various downstream vendors running on this platform for specific technologies or business fields. At that time, there will even be some module marketplaces in the medical imaging field like Apple's App Store on the Internet. developers and users can directly trade on them, just like in the vegetable market.

Here, the same debate begins again. Realistic people may ask, are these things good, but can your business survive the day when these things can sell money? The idealist responds. Well, you can continue to spoof your users with solutions that you think are sufficient. Maybe one day, you will be able to mix up on the vegetable market. With the continuous development of technology, this debate will continue, and there will be no winners in the end. The real winner has no time to compete with you.

Of course, I am willing to conservatively believe that the traditional business model and technical architecture based on independent solutions will still exist for a long time. Especially in China, this traditional model is not even completely mature, and single-host workstations are still popular. In many traditional industries, including medical care, people are even wondering if the software is worth so much money, can services be sold.

--

In some complex layered architectures, we can usually separate the interface logic from the business logic. The former processes the interaction with the verification interface, and the latter implements the core business process. According to this definition, it is time for us to focus on business logic. Of course, in terms of interface logic, in addition to those complex Image Browsing and display functions on the PACS workstation, there are also some text processing-based workstations (such as registration workstation and doctor workstation ), they also have complicated operation control and information display and input logic. From the technical implementation perspective, it seems that they are not very different from other industrial applications. However, when it comes to usability design, there will still be some very different aspects in the medical field, such as the support for emergency procedures, How to Use templates to improve the efficiency of writing medical orders, medical records and reports, how to prevent medical errors is not discussed here. In fact, these fields can also explore some important design patterns and experiences.

In addition, some technical enthusiasts will also say that there can be an interface layer between the interface logic and the business logic, which is used as a facade to encapsulate business services. We don't have to drill down this layer. If you really need to use it, consider it.

Business Logic is the core value of the information system, but in our opinion, it seems that it is only a direct ing of system requirements, not much technical content. In fact, this is only because people have developed various mature methods to implement them. Some methods are too mature, so that we don't even feel them can be summarized as models.

In general, for small systems, many business logic is more than enough to implement in the stored procedure, so that they do not seem to have much technical content, just some customized database management systems. I have seen a radiology department develop an access-based report system, and they create some forms and queries (access is equivalent to a stored procedure with a user interface ), even through file sharing, the distributed architecture has achieved some doctoral papers or senior titles.

In a slightly larger system, some business logic is put into the application code, and there is a distinction between the business logic and the data access logic (the latter is mainly completed by the storage process ), it is also known as a multi-layer architecture. In fact, when you look into the code, this distinction is not obvious, and the business logic is still scattered in the Code and stored procedures. In this regard, some people (such as customer engineers in resident hospitals) think that the logic in the stored procedure is easy to modify and it provides convenience for customization; some people (such as loyal believers in project management specifications and software engineering processes) Think That scripts in stored procedures are difficult to manage and are potential trouble makers; some (such as database experts) the existence of the stored procedure increases the system's dependence on the database, which is not conducive to database transplantation. Some people (such as compilation language lovers) therefore, we firmly believe that stored procedures can greatly improve data access performance. It's hard to make everyone speak. Architects must make rational choices in those hot and noisy debates.

In a larger system, the business logic as the middle layer may depend on more important implementations. In 1990s, Microsoft focused on the information system architecture called Windows DNA, and the intermediate layer mainly relied on COM +. Currently, various distributed technologies, including DCOM, have been integrated into WCF, and WCF Service/was has replaced COM +/MTS and become an object container in the. NET era. Regardless of the container, its functions are similar, that is, to provide some so-called enterprise-level service quality for business logic implementation, such as security, transactions, messages, sessions, and single-point logon. Of course, according to Microsoft's style, these infrastructures are implemented in different products. They have a unified term called. NET Enterprise Servers.

For larger systems, especially cross-department or cross-organization systems, the BizTalk Server in the. NET Enterprise Server can be used. We can use visual tools to define some coarse-grained cross-department/organization business processes on BizTalk (of course, first of all, we will typically ideally follow the SOA style, requires the coarse-grained encapsulation of the systems of various departments or organizations based on their business responsibilities ). In terms of medical industry habits, BizTalk is an interface engine, or an integrated platform, which also includes the HL7 suite for Enterprise Application Integration in the medical field. In fact, there are many other interface engines in the medical industry, some of which are even customized for the medical industry. However, in China, these large interface engines, including BizTalk, are not widely used. In most hospitals, the degree of Informatization does not seem to be sufficient for large-scale middleware application. The integration of many hospital systems remains at the level of simple information conversion and document sharing. Usually, custom engineers directly modify the code to directly access third-party databases; more advanced, some small interface engines are used for standardized communication with third-party systems based on HL7 and DICOM. integration can be implemented through configuration rather than directly modifying code, most of these applications are currently in the field of standardized compliance.

In traditional enterprise-level information systems, many people divide integration into two stages: information/data integration and Business/workflow integration. The former is relatively simple, and the latter is somewhat like BPM or BPR. In fact, as far as I know, there is no big difference in technical implementation between the two. To achieve flexible configuration, both of them can rely on the routing mechanism built on the workflow engine (with the popularization of workflow technology, some complex business systems also use the workflow engine for business process customization ). The only difference may be that data integration focuses more on the conversion between complex data formats, while workflow integration needs to consider more complex workflow models such as compensation and retry. However, to ensure reliable data transmission in Distributed Data streams, it is impossible for us to use the traditional transaction model too much, so mechanisms such as compensation and retry are also necessary. In any case, integration and interoperability are increasingly regarded as one of the core technologies of medical information systems.

Some models of medical integration have been described in a large number in the previous article, so we will not repeat them here. If there is anything worth emphasizing, there are a lot of things in enterprise integration model and IHE technical framework. The latter provides the best business model description for medical integration so far. In fact, both IHE, HL7, and DICOM documents imply a large number of business-layer descriptions. They can not only be used as the work manuals of integrated service engineers, it can also serve as the basis for developing medical information system requirements and standardizing system design.

--

Finally, we finally reached the end of the information system software, the data and data access layer.

Many people will think that the implementation technology at this layer seems to be the least characteristic of the medical industry. Regardless of the business entity in the industry, the relational model or object-oriented model can be achieved in the end, and then stored and queried. The design patterns in this layer are similar to those in other industries to support scalability and achieve better performance. However, the key to the application of these models lies in the understanding of medical services. I have seen people in the Console software of the Architecture radiation device (due to the need for powerful image operations, such control software is generally running on desktops rather than embedded systems, it was designed to facilitate database transplantation in the data access layer (that is, to support SQL Server for today and Oracle for tomorrow ).

Of course, there are also some positive examples of applying models in other industries to the medical field. For example, we need to provide a solution to ensure that the system can smoothly pass the regular business traffic peaks in hospitals. There is no doubt that it is a huge waste to solve the problem from the aspect of hardware investment. No adaptive policies can be found in common database performance tuning solutions, message Queue and asynchronous processing may be the only method. Another example is to provide a solution to support the custom stage to easily add fields without modifying or re-compiling the code. There are also many ways to achieve this. In summary, there are two main strategies: dynamically adding columns during running, or converting column access into line access. Of course, the latter may be more suitable for the ORM-based data access layer. In any case, this is often a comprehensive solution from database and data access to the user interface, and it is even more powerful in combination with some data binding policies on the user interface.

In fact, some common design goals of the backend system, such as reliability, performance and scalability, disaster backup and recovery, are largely achieved by the selection of hardware systems, common terms include web farm, dual-host Hot Standby, Server Load balancer, raid, NAS, San, optical disc tower, and tape library. In terms of software design, we usually only need to pay attention to one point, that is, scalability. In the traditional multi-view architecture, this design is usually reflected through the planning of threads and processes in the process view or running view. To make the system scale-out, when designing backend services that require high throughput, a common principle is to divide threads and processes according to the business processing steps, different steps are called asynchronously through the queuing mechanism, instead of dividing threads and processes based on requests; A better practice is to make full use of the thread pool to reduce the loss of system resources during process creation and destruction. For business processing that requires support for Hot Standby, you can only use processes instead of threads as the host, and save related statuses to shared storage, such as raid.

--

Finally, I would like to cite a passage in the book "application framework in specific fields: framework system of the industry" as a summary. This book has very few introductions about the medical industry. There is only one so-called "plug-in", and the technology mentioned in this section may seem a little outdated, but in my opinion, it can be used as a summary, it is related to the framework.

The framework is perhaps one of the most important and popular architecture models in the software industry. What is different from the traditional component and class library of building blocks or prefabricated boards is that the framework provides a semi-finished product with foundation, beams, and columns, even some commonly used walls and roofs are reserved for this semi-finished product, so the development efficiency of products and even product lines can be improved to a greater extent. Of course, the only thing that remains unchanged is that the software industry emphasizes the most, that is, reuse. Only components and class libraries focus on the reuse of functions and code, while frameworks focus on the reuse of logic and design. Therefore, the design points embodied in Application Frameworks for specific industries can better represent the most typical and commonly used models and experiences in software design in this industry.

Generally, a framework architecture can be divided into multiple latitudes, such as the frontend and backend, that is, the technical latitude, or the application latitude for different users, or for different key quality attributes, that is, the quality latitude. The following paragraph is mentioned in terms of technology.

"The message-oriented framework supports message customization and exchange at the Application Server (or database) end. It can use the Object Request proxy technology (such as CORBA or ActiveX) to send messages. The service-oriented framework supports the development of medical application services. These services can fully utilize the Object Request proxy architecture and existing distributed computing service tools. The visual integration framework focuses on desktop automation. These frameworks are constantly evolving along with market changes and technological advances ."

In addition, the three frameworks here are message-oriented frameworks, service-oriented frameworks, and visual integration frameworks, which are considered by the authors to be applicable to backend, intermediate layer, and front-end frameworks respectively. As predicted by the author, today, technologies used to build these frameworks have been greatly developed, as described above.

--

Looking back, from the beginning of the Medical Integration story to the present, we have also written a lot of things. There is not much integration in these irrelevant texts, because some ongoing work is absolutely impossible to say here. In fact, the main purpose of talking to myself here is to summarize and sort out my own ideas, especially my understanding of software development in the medical industry. After all, this industry is too large. At present, there are too few opportunities to access, and your memory is relatively poor, for fear that some segments will not be able to touch each other for several years. As a result, what can be accumulated is even more.