Online docking method and device for in-store medical service

Abstract

The invention relates to the technical field of data transmission and processing, is suitable for the field of medical treatment and health, and provides an online docking method and device for an in-store medical service, and the method comprises the steps: determining a medical service supply end set which can be used by a client based on a service arrangement request; acquiring a selection instruction of a client; in response to the selection instruction, sending a service arrangement request to the target supply end through the OpenAPI gateway, and obtaining a verification result for the service arrangement request from the target supply end through the OpenAPI gateway; if the verification result is that the service arrangement request is passed, obtaining a return result of the target supply end for the service arrangement request; and based on the business line corresponding to the target medical service and the return result, determining an execution result of the target supply end on the service arrangement request, and sending the execution result to the client. According to the technical scheme, full-process digital management from medical service reservation to performance is realized, and a set of efficient, safe and extensible medical service platform solution is formed.

Description

Technical field

[0001] The present application relates to the field of data transmission and processing technology, is applicable to the medical and health field, and particularly relates to an online docking method and device for in-store medical services. [Background Technology]

[0002] The current O2O in-store consumer healthcare service model faces numerous technical challenges and operational pain points that need to be addressed. Traditional service integration methods lack efficient and stable data exchange channels between the platform and supplier systems, resulting in significant lags in order status changes. Customer actions such as reservations, cancellations, or rescheduling cannot be synchronized to the supplier system in real time, and critical business data such as supplier fulfillment progress and sample testing results are also difficult to transmit back to the platform in a timely manner. This two-way information asymmetry not only creates inconsistencies between the platform's displayed information and the actual service status, but also leads to inefficient customer complaint handling, severely impacting user experience and service quality.

[0003] At the same time, existing technical solutions suffer from significant flaws at the system architecture level. They lack unified interface specifications and security authentication mechanisms, and they also lack effective support for the differentiated processes of different business lines. Regarding security, traditional integration methods struggle to prevent risks such as data tampering and unauthorized access, and the heterogeneous interface standards adopted by various vendors further complicate and cost system maintenance.

[0004] In addition, due to the inability to achieve visual tracking of the entire life cycle of an order, the platform can neither provide effective early warning and resource scheduling for concentrated fulfillment during peak periods such as sales meetings, nor can it conduct accurate operational analysis and decision optimization based on complete business data.

[0005] Therefore, how to build a unified online docking solution with full-process visualization, high security and easy scalability has become the most urgent technical problem that needs to be solved in current medical and health services. [Summary of the invention]

[0006] The embodiments of the present application provide an online docking method and device for in-store medical services, aiming to solve the technical problems in related technologies such as serious information silos, fragmented business processes, and insufficient security protection between medical service platforms and supplier systems.

[0007] In a first aspect, an embodiment of the present application provides an online docking method for in-store medical services, comprising:

[0008] Obtaining a service arrangement request from a client for a target medical service, wherein the service arrangement request is used to request an appointment, rescheduling, or cancellation of the target medical service;

[0009] Determining a set of medical service providers available to the client based on the service arrangement request;

[0010] Obtaining a selection instruction from the client for a target provider in the set of medical service providers;

[0011] In response to the selection instruction, sending the service arrangement request to the target supplier through the OpenAPI gateway, and obtaining a verification result of the service arrangement request from the target supplier through the OpenAPI gateway;

[0012] If the verification result is that the service arrangement request is passed, obtaining a response result from the target supplier regarding the service arrangement request;

[0013] Based on the business line corresponding to the target medical service and the returned result, the execution result of the target supplier on the service arrangement request is determined, and the execution result is sent to the client.

[0014] In one embodiment of the present application, optionally, determining a set of medical service providers available to the client based on the service arrangement request includes:

[0015] In response to the acquisition of the service arrangement request, acquiring physical store data of all medical service providers, wherein the physical store data includes: store latitude and longitude coordinates, business status, service hours, and real-time service arrangement space;

[0016] Based on the GEO hash algorithm, the longitude and latitude coordinates of each medical service provider store are converted into a string;

[0017] Divide the grid based on the character string of each medical service provider to determine the grid area corresponding to each medical service provider;

[0018] Performing a grid search with the user location provided by the client as the center to obtain a list of medical service providers from the user location in descending order;

[0019] A number of medical service providers that are adapted to the service arrangement request are determined in the medical service provider list as a set of medical service providers available to the client.

[0020] In one embodiment of the present application, optionally, determining a number of medical service providers that are adapted to the service arrangement request in the medical service provider list includes:

[0021] If the service period of the medical service provider includes the service arrangement time of the target medical service, and the business status of the medical service provider at the service arrangement time is available, and the medical service provider has a real-time service arrangement space for providing the target medical service, it is determined that the medical service provider adapts to the service arrangement request.

[0022] In one embodiment of the present application, optionally, sending the service arrangement request to the target supplier through the OpenAPI gateway includes:

[0023] Encrypting the service arrangement request by using a 3DES encryption method, and calculating a signature for the service arrangement request by using an HMAC-SHA1 algorithm to obtain first encrypted data;

[0024] The first encrypted data is sent to the OpenAPI gateway so that the OpenAPI gateway can verify the signature of the first encrypted data and decrypt the first encrypted data to obtain intermediate transmission data, and then call the internal dubbo interface to send the intermediate transmission data to the target supply end.

[0025] In one embodiment of the present application, optionally, obtaining, through the OpenAPI gateway, a verification result of the service arrangement request from the target supplier includes:

[0026] Obtaining second encrypted data after the OpenAPI gateway encrypts the verification result from the target supplier;

[0027] The second encrypted data is decrypted to obtain the verification result of the target supply end for the service arrangement request.

[0028] In one embodiment of the present application, optionally, the method further includes:

[0029] Set up an access whitelist for the OpenAPI gateway;

[0030] Before sending the service arrangement request to the target supplier through the OpenAPI gateway, the method further includes:

[0031] Determine whether the unique identity of the target supplier is in the access whitelist of the OpenAPI gateway;

[0032] If the unique identifier of the target supplier is in the access whitelist, the step of sending the service arrangement request to the target supplier through the OpenAPI gateway is allowed to be executed, wherein,

[0033] For each medical service provider, a unique identity is assigned to the medical service provider, and an accessible interface corresponding to the unique identity is determined in the interface list of the OpenAPI gateway.

[0034] In one embodiment of the present application, optionally, if the service arrangement request includes an appointment or rescheduling for the target medical service, obtaining a response result from the target provider in response to the service arrangement request includes:

[0035] Obtaining the execution result of the target medical service in the target supply end;

[0036] The determining, based on the business line corresponding to the target medical service and the returned result, the execution result of the target supplier on the service arrangement request includes:

[0037] Call the abstract parent class of the business line corresponding to the target medical service, and extract the public process code involved in the business line from the abstract parent class;

[0038] Based on the public process code, the corresponding public process is executed on the returned result, and in the process of executing the public process, the business line implementation class that inherits the abstract parent class is called to execute the individual process corresponding to the business line.

[0039] In a second aspect, an embodiment of the present application provides an online docking device for in-store medical services, including:

[0040] A service arrangement request acquiring unit, configured to acquire a service arrangement request from a client for a target medical service, wherein the service arrangement request is used to request an appointment, rescheduling, or cancellation of the target medical service;

[0041] a supplier set determining unit, configured to determine a set of medical service suppliers available to the client based on the service arrangement request;

[0042] A supplier selection unit, configured to obtain a selection instruction from the client for a target supplier in the set of medical service suppliers;

[0043] a gateway interaction unit, configured to send the service arrangement request to the target supplier through the OpenAPI gateway in response to the selection instruction, and obtain a verification result of the service arrangement request from the target supplier through the OpenAPI gateway;

[0044] A result feedback unit, configured to obtain a feedback result of the target supplier in response to the service arrangement request if the verification result is that the service arrangement request is passed;

[0045] A return result processing unit is used to determine the execution result of the target supplier on the service arrangement request based on the business line corresponding to the target medical service and the return result, and send the execution result to the client.

[0046] In one embodiment of the present application, optionally, the supply-side set determining unit includes:

[0047] a store data acquisition unit, configured to acquire, in response to the acquisition of the service arrangement request, the physical store data of all medical service providers, wherein the physical store data includes: store latitude and longitude coordinates, business status, service hours, and real-time service arrangement space;

[0048] A character string conversion unit, configured to convert the longitude and latitude coordinates of each medical service provider's store into a character string based on a GEO hash algorithm;

[0049] a grid division unit, configured to divide the grid based on the character string of each medical service provider to determine a grid area corresponding to each medical service provider;

[0050] A grid search unit, configured to perform a grid search with the user location provided by the client as the center, and obtain a list of medical service providers from the user location in descending order of proximity;

[0051] The grid screening unit is configured to determine a plurality of medical service providers that are adapted to the service arrangement request in the medical service provider list as a set of medical service providers available to the client.

[0052] In one embodiment of the present application, optionally, the grid screening unit is used to:

[0053] If the service period of the medical service provider includes the service arrangement time of the target medical service, and the business status of the medical service provider at the service arrangement time is available, and the medical service provider has a real-time service arrangement space for providing the target medical service, it is determined that the medical service provider adapts to the service arrangement request.

[0054] In one embodiment of the present application, optionally, the gateway interaction unit includes:

[0055] an encryption unit, configured to encrypt the service arrangement request by using a 3DES encryption method, and calculate a signature for the service arrangement request by using an HMAC-SHA1 algorithm to obtain first encrypted data;

[0056] A data upload unit is used to send the first encrypted data to the OpenAPI gateway, so that the OpenAPI gateway can verify the signature of the first encrypted data and decrypt the first encrypted data to obtain intermediate transmission data, and then call the internal dubbo interface to send the intermediate transmission data to the target supplier.

[0057] In one embodiment of the present application, optionally, the gateway interaction unit further includes:

[0058] A data downloading unit, configured to obtain second encrypted data obtained by encrypting the verification result from the target supplier by the OpenAPI gateway;

[0059] A decryption unit is configured to decrypt the second encrypted data to obtain the verification result of the target supply end for the service arrangement request.

[0060] In one embodiment of the present application, optionally, the device further includes:

[0061] A whitelist setting unit, configured to set an access whitelist for the OpenAPI gateway;

[0062] The device further comprises:

[0063] A whitelist checking unit is configured to determine whether the unique identity identifier of the target supplier is in an access whitelist of the OpenAPI gateway before the gateway interaction unit sends the service arrangement request to the target supplier through the OpenAPI gateway, wherein if the unique identity identifier of the target supplier is in the access whitelist, sending the service arrangement request to the target supplier through the OpenAPI gateway is allowed;

[0064] an identity identifier allocation unit, configured to allocate a unique identity identifier to each medical service provider;

[0065] An access interface allocation unit is used to determine the accessible interface corresponding to the unique identity in the interface list of the OpenAPI gateway.

[0066] In one embodiment of the present application, optionally, the result returning unit includes:

[0067] If the service arrangement request includes an appointment or rescheduling of the target medical service, obtaining an execution result of the target medical service from the target provider;

[0068] The return result processing unit includes:

[0069] Call the abstract parent class of the business line corresponding to the target medical service, extract the public process code involved in the business line in the abstract parent class, and execute the corresponding public process on the return result based on the public process code. In the process of executing the public process, call the business line implementation class that inherits the abstract parent class to execute the individual process corresponding to the business line.

[0070] In a third aspect, an embodiment of the present application provides a computer device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are configured to execute the method described in the first aspect above.

[0071] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are used to execute the method described in the first aspect above.

[0072] The above technical solution addresses the severe information silos, fragmented business processes, and inadequate security issues inherent in related technologies, such as severe information silos between medical service platforms and supplier systems. By combining a GEO hashing algorithm and a three-dimensional spatiotemporal resource assessment model, it enables intelligent recommendation and precise screening of suppliers, ensuring both convenient access to nearby healthcare and optimal allocation of service resources. Regarding secure communication, a dual-security mechanism, 3DES encryption and HMAC-SHA1 signatures, is employed to establish an end-to-end secure transmission channel, effectively preventing data leakage and tampering risks. The OpenAPI gateway, serving as the core hub, not only facilitates protocol conversion and seamless integration between internal and external systems but also simplifies the onboarding of multiple suppliers through unified interface specifications. In terms of business processing, the system, based on a factory pattern and abstract parent class design, standardizes common processes such as appointment booking and payment while flexibly adapting to the specialized needs of different business lines, enabling differentiated functionality expansion through polymorphism. This architectural design ensures high scalability, enabling rapid integration of new business lines by simply extending the corresponding implementation class, while maintaining the simplicity of the core code. The resulting closed-loop management system not only improves the accessibility and professionalism of medical services, but also provides complete data support for platform operations, achieving a comprehensive improvement in resource utilization, service quality, and operational efficiency.

Brief Description of the Drawings

[0073] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0074] Figure 1 A flowchart of an online docking method for in-store medical services according to an embodiment of the present application is shown;

[0075] Figure 2 A flowchart illustrating interaction between a third-party supplier and a platform using an OpenAPI gateway according to an embodiment of the present application is shown;

[0076] Figure 3 A block diagram of a computer device according to an embodiment of the present application is shown;

[0077] Figure 4 A block diagram of a computer device according to another embodiment of the present application is shown. [Specific implementation method]

[0078] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0079] Figure 1 A flowchart of an online docking method for in-store medical services according to an embodiment of the present application is shown.

[0080] like Figure 1 As shown, an online docking method for in-store medical services in one embodiment of the present application includes:

[0081] Step 102: Obtain a service arrangement request from the client for a target medical service, wherein the service arrangement request is used to request reservation, rescheduling, or cancellation of the target medical service.

[0082] The implementation entity of this technical solution is a platform that provides medical services from a medical service provider to clients. This platform can be a dedicated medical service platform or a comprehensive service platform that encompasses all medical services. As the interaction medium between the client and the medical service provider, the platform first receives a service arrangement request from the client for a target medical service. This service arrangement request reflects the client's desired target medical service's service recipient, service content, service time, and other characteristics. It includes, but is not limited to, rescheduling, rescheduling, or canceling the target medical service.

[0083] The current mainstream online appointment medical services mainly cover the following items. The first is oral diagnosis and treatment services, including professional dental projects such as ultrasonic teeth cleaning, initial orthodontic consultation, and dental implant consultation; the second is medical beauty services, which provide appointments for medical beauty projects such as skin laser treatment and injection-type micro-plastic surgery; the third category is health check-up services, which support online appointments for various physical examination projects such as pre-employment physical examination packages and early tumor screening; the fourth category is specialist diagnosis and treatment services, covering professional medical projects such as gastrointestinal endoscopy and tertiary expert consultation; the fifth category is traditional Chinese medicine conditioning services, which can make appointments for traditional Chinese medicine projects such as constitution identification and conditioning, Sanfu plaster treatment, etc.; the sixth category is vaccination services, which support online appointments for various vaccines; the seventh category is rehabilitation and physiotherapy services, including sports injury rehabilitation, spinal correction treatment and other projects; the eighth is special testing services, such as allergen testing, child care, non-invasive prenatal DNA testing and other special testing projects. Of course, the medical services applicable to this application include but are not limited to the above examples, and may also include any other reasonable and compliant medical services.

[0084] Step 104: Determine a set of medical service providers available to the client based on the service arrangement request.

[0085] The platform screens the set of medical service providers available to the client from all medical service providers based on the service object, service content, service time and other characteristics in the service arrangement request, achieving accurate matching of supplier resources, which can improve the accuracy of service recommendations and user satisfaction.

[0086] In a possible design, first, in response to obtaining the service arrangement request, the physical store data of all medical service providers are obtained.

[0087] The physical store data includes: store latitude and longitude coordinates, business status, service hours, and real-time service scheduling space. The store latitude and longitude coordinates reflect the degree of distance compatibility between the medical service provider and the client user. The business status and service hours reflect the degree of compatibility between the medical service provider's service supply time and the client user's service demand time. The real-time service scheduling space refers to the remaining inventory of the service, reflecting the medical service provider's actual ability to provide the target medical service. Overall, the medical service provider's physical store data reflects the feasibility of the medical service provider in providing the target medical service to the client user.

[0088] Next, based on the GEO hash algorithm, the longitude and latitude coordinates of each medical service provider's store are converted into a character string, and a grid is divided based on the character string of each medical service provider to determine a grid area corresponding to each medical service provider;

[0089] The GEO hash algorithm is a spatial indexing algorithm that encodes two-dimensional geographic coordinates into a one-dimensional string. This algorithm recursively divides a map into grid regions, enabling efficient storage and proximity lookups of geographic locations. Optionally, prefixes in the GEO hash string represent larger rectangular regions. For example, wtw3 covers the entire urban area of ​​city a, while wtw3sj corresponds to neighborhood b in city a.

[0090] Based on this, a grid search is performed with the client's provided user location as the center to obtain a list of medical service providers from the user's location in descending order. The search is gradually expanded outward from the client's provided user location, using a proximity grid algorithm to generate the search order. Databases (such as Redis GEO) or spatial index trees (such as R-tree) can also be used to accelerate the search.

[0091] Finally, several medical service providers that are adapted to the service arrangement request are determined in the medical service provider list as a set of medical service providers available to the client.

[0092] Among them, if the service time period of the medical service provider includes the service arrangement time of the target medical service, and the business status of the medical service provider at the service arrangement time is available, and the medical service provider has a real-time service arrangement space for providing the target medical service, it is determined that the medical service provider adapts to the service arrangement request.

[0093] That is to say, if the time when the client user needs to use the target medical service is during the business period of the medical service provider, and the current remaining inventory of the target medical service of the medical service provider is greater than or equal to the amount of the target medical service required by the client user, it means that the medical service supplier adapts to the service arrangement request and can be added to the set of medical service suppliers available to the client for selection by the client.

[0094] In another possible design, the platform first verifies whether the supplier's service hours meet the reservation requirements, ensuring time compatibility. Secondly, it confirms the supplier's operating status during the target period, eliminating abnormalities such as temporary closures. Finally, it monitors remaining service capacity in real time to avoid resource conflicts caused by overbooking. These three levels of verification are closely linked, forming a complete service quality assurance system.

[0095] The above technical solution utilizes a multi-dimensional screening mechanism to achieve precise matching and dynamic resource optimization of medical service providers. This allows the platform to conduct a comprehensive and dynamic evaluation of candidate providers based on three core indicators: service time matching, business status availability, and real-time service capacity. This effectively overcomes the resource mismatch issues inherent in traditional medical appointment systems. Furthermore, this solution integrates with the previous GEO hash geolocation search to achieve a comprehensive assessment of spatiotemporal matching, service capabilities, and resource availability. This fully considers users' need for convenient nearby medical care while ensuring the efficient and rational use of medical resources. This significantly improves the user experience while increasing access to medical services.

[0096] Step 106: Obtain a selection instruction from the client for a target provider in the set of medical service providers.

[0097] Based on the actual needs of its own users, the client automatically selects the target supplier from the set of medical service suppliers and generates corresponding selection instructions. Alternatively, the user selects the target supplier on the client, and the client receives the user's selection operation and generates a selection instruction for the target supplier.

[0098] Step 108: In response to the selection instruction, send the service arrangement request to the target supplier through the OpenAPI gateway, and obtain a verification result of the service arrangement request from the target supplier through the OpenAPI gateway.

[0099] The OpenAPI gateway plays a core hub role in unified access, protocol conversion, and security management, enabling secure and efficient data interaction between the platform and multi-vendor systems through standardized interfaces.

[0100] Specifically, in the process of sending the service arrangement request to the target supplier through the OpenAPI gateway, the service arrangement request can be encrypted using the 3DES encryption method, and the signature of the service arrangement request can be calculated using the HMAC-SHA1 algorithm to obtain the first encrypted data. The first encrypted data is then sent to the OpenAPI gateway for the OpenAPI gateway to verify the signature of the first encrypted data and decrypt the first encrypted data to obtain the intermediate transmission data. The internal dubbo interface is then called to send the intermediate transmission data to the target supplier. In the process of obtaining the verification result of the service arrangement request from the target supplier through the OpenAPI gateway, the second encrypted data obtained by encrypting the verification result from the target supplier is obtained, and the second encrypted data is decrypted to obtain the verification result of the target supplier for the service arrangement request.

[0101] 3DES (Triple Data Encryption Standard) encryption enhances security by performing three DES encryption operations on data, using a 56-bit x 3 key length to ensure the secure transmission of sensitive data. HMAC-SHA1 is a message authentication code mechanism based on the SHA-1 hash algorithm and a secret key. It verifies data integrity and authenticity by performing multiple hash operations on the secret key and the message. It is commonly used in security scenarios such as interface signature verification.

[0102] The above technical solution, through the dual security mechanisms of 3DES encryption and HMAC-SHA1 signature verification, establishes an end-to-end, bidirectional encrypted communication channel, ensuring the secure transmission and integrity of medical service data. The 3DES encryption algorithm uses a 168-bit key length to strongly encrypt service scheduling requests, ensuring data confidentiality during transmission and effectively preventing the leakage of sensitive medical information. The HMAC-SHA1 algorithm generates a unique digital signature for each service scheduling request for medical services, using a keyed hash verification mechanism to safeguard data integrity and authenticity, eliminating the risk of tampering during transmission. During the request phase, the 3DES encryption algorithm is used to strongly encrypt service scheduling requests, combined with the HMAC-SHA1 signature mechanism to ensure the data source is trusted and has not been tampered with, effectively preventing man-in-the-middle attacks and data leakage risks. The OpenAPI gateway, acting as a security hub, performs signature verification and decryption operations, securely forwarding the data to the target provider through the internal Dubbo interface. This maintains compatibility with external HTTP / HTTPS protocols while enabling seamless integration with the enterprise's internal Dubbo service architecture. During the response phase, an encrypted transmission mechanism is also used to process verification results on the supply side, forming a complete end-to-end security closed loop. This combined security solution is particularly important in medical data interaction scenarios. It not only meets the compliance requirements of medical privacy protection, but also significantly reduces the complexity of system integration through a standardized encryption and signature verification process, providing a unified and reliable security foundation for multi-supplier access.

[0103] In addition, if Figure 2 As shown, the process of interaction between a third-party supplier (i.e., the target supply side) and a consumer medical system (i.e., the platform) can also be implemented using an OpenAPI gateway.

[0104] Specifically, the third-party supplier uploads data to the consumer medical system through the OpenAPI gateway. This data may include characteristic information such as the third-party supplier's own store latitude and longitude coordinates, business status, service hours, and real-time service scheduling space. It may also include the return result of the third-party supplier's service scheduling request to the client, and may also include the medical service execution results after the third-party supplier provides medical services to the client. Of course, the data uploaded by the third-party supplier to the consumer medical system through the OpenAPI gateway is not limited to the above examples, and can also be any legal and compliant data that meets the interaction needs of both parties.

[0105] Before uploading data, the third-party supplier can encrypt the data using the 3DES encryption method, and calculate the signature for the data using the HMAC-SHA1 algorithm to obtain the third encrypted data, and then send the third encrypted data to the OpenAPI gateway for the OpenAPI gateway to verify the signature of the third encrypted data and decrypt the third encrypted data to obtain the intermediate transmission data, and then call the internal dubbo interface to send the intermediate transmission data to the consumer medical system. Then, the third-party supplier obtains the return result from the consumer medical system through the OpenAPI gateway, that is, obtains the feedback information of the consumer medical system for the data. In this process, before the third-party supplier obtains the return result from the consumer medical system through the OpenAPI gateway, the OpenAPI gateway encrypts the return result to obtain the fourth encrypted data. At this point, the content obtained by the third-party supplier is actually the fourth encrypted data encrypted by the OpenAPI gateway. Then, the third-party supplier decrypts the fourth encrypted data to obtain the feedback information of the consumer medical system for the data.

[0106] In short, the OpenAPI gateway can participate in the interaction between the medical service provider and the platform, as well as the interaction between the client and the platform. The three build a complete communication link through the OpenAPI gateway, realizing the safe and efficient flow of medical data and the seamless connection of business processes, and making up for the technical shortcomings of traditional medical service platforms in terms of system docking standardization, security management systematization, and service collaboration intelligence. Through the hub role of the OpenAPI gateway, not only the information barriers between the client, platform and supply side are broken down, but also a complete technical guarantee system with functions such as identity authentication, permission control, data encryption, and protocol conversion is established, which effectively solves the security, reliability and scalability issues in the interconnection of multiple systems in the medical and health field, and provides a solid technical foundation for the online medical services.

[0107] Step 110: If the verification result is that the service arrangement request is passed, obtain the response result of the target supply end for the service arrangement request.

[0108] Step 112: Based on the business line corresponding to the target medical service and the returned result, determine the execution result of the target supplier for the service arrangement request, and send the execution result to the client.

[0109] If the service arrangement request is a request to reserve or reschedule the target medical service, the target provider's response to the service arrangement request includes: a successful reservation or rescheduling, and the medical service result after the target medical service is performed. If the service arrangement request is a request to cancel the target medical service, the target provider's response to the service arrangement request indicates a successful cancellation.

[0110] Of course, if the verification result is to reject the service arrangement request, a rejection message is sent to the client, and the client displays that the service arrangement request has failed.

[0111] In one possible design, step 110 includes: obtaining the execution result of the target medical service in the target supply end; then step 112 includes: calling the abstract parent class of the business line corresponding to the target medical service, and extracting the public process code involved in the business line in the abstract parent class; executing the corresponding public process on the return result based on the public process code, and in the process of executing the public process, calling the business line implementation class that inherits the abstract parent class to execute the individual process corresponding to the business line.

[0112] A single business line has an abstract parent class as a unified base class. The abstract parent class predefines the common processing flow and standard interface specifications. The specific business line implementation class extends differentiated functions through the inheritance mechanism. The creation process begins with the business line enumeration definition. The platform dynamically initializes the corresponding implementation class based on the business line type bound when the supplier registers. The factory class automatically selects and returns the correct implementation class instance based on the business line identifier. When processing the execution results of the target medical service, the platform first calls the public process code encapsulated by the abstract parent class to perform basic verification and status synchronization, and then triggers the personalized processing logic of the specific business line implementation class to which the target medical service belongs through the polymorphic mechanism. For example, the dental business line will verify the dental film data and associate it with the diagnosis and treatment plan, while the cellular business line will track the sample storage status and cold chain data.

[0113] As a result, each business line perfectly adapts to the needs of professional fields while maintaining consistency in core processes. Public logic is uniformly managed through the abstract layer, and special functions are flexibly expanded using implementation classes. This not only avoids code duplication but also supports seamless addition of new business lines. All implementation classes interact with other modules of the platform through a unified interface, ensuring the high cohesion and low coupling characteristics of the architecture. The final processed standardized results are returned to the client via a secure channel, forming a complete business closed loop.

[0114] Taking the dental business line as an example, the supplier type is first identified as DENTAL through business line enumeration. The factory class instantiates the DentalServiceImpl dental-specific processor based on this. This implementation class inherits from an abstract parent class that contains public methods such as appointment verification and status synchronization, and extends professional functions such as dental image verification and orthodontic plan generation.

[0115] When processing the execution results of the teeth cleaning service, the platform first executes the general result parsing and customer notification process defined by the parent class, and then calls the dental implementation class-specific dental film quality assessment and treatment record association logic to automatically bind the X-ray film to the appointment form and push the postoperative care guide.

[0116] Taking the cell business line as an example, the platform initializes the CellServiceImpl instance. This implementation class implements unique methods such as sample coding rules and cold chain temperature control verification based on inheriting public processes.

[0117] When processing the results of the cell storage service, the parent class first completes the basic data verification and inventory update, and the cell implementation class continues to perform professional operations such as sample activity detection, storage location allocation, and cold chain logistics monitoring, tracking the status of the liquid nitrogen tank in real time and generating a biosafety report.

[0118] In the above example, both business lines create instances through the same factory mechanism and follow unified interface specifications. The dental implementation class focuses on diagnosis and treatment process management, while the cell implementation class focuses on biological sample management. Both can reuse the parent class's common functions such as appointment mechanisms and payment processing, and can also implement key differences within the professional fields of their own business lines by overriding the parent class's abstract methods. This design allows the platform to accurately support the specialized business processes of different medical specialties while maintaining a single public code base. When adding new business lines such as medical aesthetics, only the new implementation class needs to be expanded for rapid access. All business data is ultimately returned to the client through a unified encrypted channel, ensuring both the professionalism and accuracy of medical services and the cleanliness and scalability of the system architecture.

[0119] In summary, the technical solution of this application realizes the digital management of the entire process from service appointment to fulfillment. The platform first accurately matches available suppliers based on the GEO hash algorithm and multiple verification conditions, then realizes encrypted data transmission and protocol conversion through the OpenAPI gateway, and finally adopts the factory model to handle the differentiated processes of each business line, forming a set of efficient, secure and scalable medical service platform solutions, which significantly improves the matching efficiency of medical service resources and user experience.

[0120] Furthermore, the technical solution of the present application realizes the all-round optimization of the online docking of medical services. In the service matching stage, the platform combines the GEO hashing geographic location algorithm and the three-dimensional evaluation model of spatiotemporal resources to realize the intelligent recommendation and accurate screening of suppliers, which not only takes into account the convenience of users seeking medical treatment nearby, but also ensures the reasonable allocation of service resources. At the security communication level, the dual protection mechanism of 3DES encryption and HMAC-SHA1 signature is adopted to build an end-to-end secure transmission channel to effectively prevent data leakage and tampering risks. As the core hub, the OpenAPI gateway not only realizes the protocol conversion and seamless docking of internal and external systems, but also simplifies the multi-supplier access process through a unified interface specification. In the business processing link, based on the design of the factory pattern and abstract parent class, the system can not only standardize the processing of public processes such as appointments and payments, but also flexibly adapt to the professional needs of different business lines, and realize differentiated functional expansion through the polymorphic mechanism. This architectural design makes the system highly scalable. When adding a new business line, you only need to expand the corresponding implementation class to quickly access it, while maintaining the simplicity of the core code. The resulting closed-loop management system not only improves the accessibility and professionalism of medical services, but also provides complete data support for platform operations, achieving a comprehensive improvement in resource utilization, service quality, and operational efficiency.

[0121] Additionally, it should be noted that an access whitelist may be configured for the OpenAPI gateway. Thus, before sending the service arrangement request to the target supplier via the OpenAPI gateway, a determination may be made as to whether the target supplier's unique identifier is on the OpenAPI gateway's access whitelist. If the target supplier's unique identifier is on the access whitelist, the step of sending the service arrangement request to the target supplier via the OpenAPI gateway is permitted.

[0122] That is to say, before the OpenAPI gateway transmits the service arrangement request to the platform on behalf of the client, it first determines whether the target supplier selected by the client is a compliant medical service supplier in the whitelist. Only when the target supplier is in the whitelist is the OpenAPI gateway allowed to transmit the service arrangement request to the platform on behalf of the client.

[0123] The whitelist records the unique identity of the medical service provider. For each medical service provider, the platform can assign a unique identity to the medical service provider and determine the accessible interface corresponding to the unique identity in the interface list of the OpenAPI gateway.

[0124] It can be said that the platform assigns a unique identity to each medical service provider and maintains fine-grained access rights. The OpenAPI gateway performs double verification before forwarding the request. First, it verifies whether the supplier's identity exists in the whitelist to ensure basic access qualifications, and then checks the specific interface access rights corresponding to the identity to achieve fine-grained control.

[0125] As a result, the whitelist mechanism effectively blocks unauthorized access from suppliers, ensuring the security of the medical service platform from the very beginning. At the same time, by binding unique identifiers to interface permissions, precise control over the capabilities of different suppliers is achieved, preventing unauthorized operations. Furthermore, this mechanism complements existing security measures such as encrypted transmission and signature verification, jointly building a comprehensive security system encompassing identity authentication, permission control, and data protection. This ensures the compliance of medical data while providing a standardized and scalable security management framework for the platform's multi-supplier management.

[0126] The present application also provides an online docking device for in-store medical services, including:

[0127] A service arrangement request acquiring unit, configured to acquire a service arrangement request from a client for a target medical service, wherein the service arrangement request is used to request an appointment, rescheduling, or cancellation of the target medical service;

[0128] a supplier set determining unit, configured to determine a set of medical service suppliers available to the client based on the service arrangement request;

[0129] A supplier selection unit, configured to obtain a selection instruction from the client for a target supplier in the set of medical service suppliers;

[0130] a gateway interaction unit, configured to send the service arrangement request to the target supplier through the OpenAPI gateway in response to the selection instruction, and obtain a verification result of the service arrangement request from the target supplier through the OpenAPI gateway;

[0131] A result feedback unit, configured to obtain a feedback result of the target supplier in response to the service arrangement request if the verification result is that the service arrangement request is passed;

[0132] A return result processing unit is used to determine the execution result of the target supplier on the service arrangement request based on the business line corresponding to the target medical service and the return result, and send the execution result to the client.

[0133] In one embodiment of the present application, optionally, the supply-side set determining unit includes:

[0134] a store data acquisition unit, configured to acquire, in response to the acquisition of the service arrangement request, the physical store data of all medical service providers, wherein the physical store data includes: store latitude and longitude coordinates, business status, service hours, and real-time service arrangement space;

[0135] A character string conversion unit, configured to convert the longitude and latitude coordinates of each medical service provider's store into a character string based on a GEO hash algorithm;

[0136] a grid division unit, configured to divide the grid based on the character string of each medical service provider to determine a grid area corresponding to each medical service provider;

[0137] A grid search unit, configured to perform a grid search with the user location provided by the client as the center, and obtain a list of medical service providers from the user location in descending order of proximity;

[0138] The grid screening unit is configured to determine a plurality of medical service providers that are adapted to the service arrangement request in the medical service provider list as a set of medical service providers available to the client.

[0139] In one embodiment of the present application, optionally, the grid screening unit is used to:

[0140] If the service period of the medical service provider includes the service arrangement time of the target medical service, and the business status of the medical service provider at the service arrangement time is available, and the medical service provider has a real-time service arrangement space for providing the target medical service, it is determined that the medical service provider adapts to the service arrangement request.

[0141] In one embodiment of the present application, optionally, the gateway interaction unit includes:

[0142] an encryption unit, configured to encrypt the service arrangement request by using a 3DES encryption method, and calculate a signature for the service arrangement request by using an HMAC-SHA1 algorithm to obtain first encrypted data;

[0143] A data upload unit is used to send the first encrypted data to the OpenAPI gateway, so that the OpenAPI gateway can verify the signature of the first encrypted data and decrypt the first encrypted data to obtain intermediate transmission data, and then call the internal dubbo interface to send the intermediate transmission data to the target supplier.

[0144] In one embodiment of the present application, optionally, the gateway interaction unit further includes:

[0145] A data downloading unit, configured to obtain second encrypted data obtained by encrypting the verification result from the target supplier by the OpenAPI gateway;

[0146] A decryption unit is configured to decrypt the second encrypted data to obtain the verification result of the target supply end for the service arrangement request.

[0147] In one embodiment of the present application, optionally, the device further includes:

[0148] A whitelist setting unit, configured to set an access whitelist for the OpenAPI gateway;

[0149] The device further comprises:

[0150] A whitelist checking unit is configured to determine whether the unique identity identifier of the target supplier is in an access whitelist of the OpenAPI gateway before the gateway interaction unit sends the service arrangement request to the target supplier through the OpenAPI gateway, wherein if the unique identity identifier of the target supplier is in the access whitelist, sending the service arrangement request to the target supplier through the OpenAPI gateway is allowed;

[0151] an identity identifier allocation unit, configured to allocate a unique identity identifier to each medical service provider;

[0152] An access interface allocation unit is used to determine the accessible interface corresponding to the unique identity in the interface list of the OpenAPI gateway.

[0153] In one embodiment of the present application, optionally, the result returning unit includes:

[0154] If the service arrangement request includes an appointment or rescheduling of the target medical service, obtaining an execution result of the target medical service from the target provider;

[0155] The return result processing unit includes:

[0156] Call the abstract parent class of the business line corresponding to the target medical service, extract the public process code involved in the business line in the abstract parent class, and execute the corresponding public process on the return result based on the public process code. In the process of executing the public process, call the business line implementation class that inherits the abstract parent class to execute the individual process corresponding to the business line.

[0157] The device uses any one of the solutions in the above embodiments, and therefore has all the above technical effects, which will not be described in detail here.

[0158] In addition, in one embodiment, the present application provides a computer device, which may be a server, and its internal structure diagram may be as follows: Figure 3 As shown. The computer device includes a processor, memory, network interface and database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external client via a network connection. When the computer program is executed by the processor, it can implement the method described in any of the above embodiments.

[0159] In one embodiment, the present application further provides a computer device, which may be a client, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, memory, a network interface, a display screen, and an input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When executed by the processor, the computer program can implement the method described in any of the above embodiments.

[0160] Any of the aforementioned computer devices in the embodiments of the present application may exist in various forms, including but not limited to:

[0161] (1) Mobile communication devices: These devices are characterized by their mobile communication capabilities and are primarily designed to provide voice and data communications. These terminals include smartphones (e.g., iPhones), multimedia phones, feature phones, and low-end phones.

[0162] (2) Ultra-mobile personal computer devices: These devices fall under the category of personal computers, have computing and processing capabilities, and generally also have mobile Internet access. These terminals include PDAs, MIDs, and UMPCs, such as the iPad.

[0163] (3) Portable entertainment devices: These devices can display and play multimedia content. These devices include audio and video players (such as iPods), handheld game consoles, e-books, as well as smart toys, wearable devices, and portable car navigation devices.

[0164] (4) Server: A device that provides computing services. The server consists of a processor, hard disk, memory, system bus, etc. The server is similar to a general computer architecture, but because it needs to provide highly reliable services, it has higher requirements in terms of processing power, stability, reliability, security, scalability, and manageability.

[0165] (5) Other electronic devices with data interaction functions.

[0166] In addition, an embodiment of the present application provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are used to perform the following steps:

[0167] Obtaining a service arrangement request from a client for a target medical service, wherein the service arrangement request is used to request an appointment, rescheduling, or cancellation of the target medical service;

[0168] Determining a set of medical service providers available to the client based on the service arrangement request;

[0169] Obtaining a selection instruction from the client for a target provider in the set of medical service providers;

[0170] In response to the selection instruction, sending the service arrangement request to the target supplier through the OpenAPI gateway, and obtaining a verification result of the service arrangement request from the target supplier through the OpenAPI gateway;

[0171] If the verification result is that the service arrangement request is passed, obtaining a response result from the target supplier regarding the service arrangement request;

[0172] Based on the business line corresponding to the target medical service and the returned result, the execution result of the target supplier on the service arrangement request is determined, and the execution result is sent to the client.

[0173] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can refer to the relevant description in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0174] The above, in combination with the accompanying drawings, describes in detail the technical solution of this application. Through the technical solution of this application, digital management of the entire process from service appointment to fulfillment is realized. The platform first accurately matches available suppliers based on the GEO hash algorithm and multiple verification conditions, and then realizes encrypted data transmission and protocol conversion through the OpenAPI gateway. Finally, the factory model is adopted to handle the differentiated processes of each business line, forming a set of efficient, secure and scalable medical service platform solutions, which significantly improves the matching efficiency of medical service resources and user experience.

[0175] It should be understood that the term "and / or" as used herein is merely a description of the relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, the character " / " in this document generally indicates that the associated objects are in an "or" relationship.

[0176] It should be understood that although the terms "first," "second," etc. may be used to describe encrypted data in the embodiments of the present application, the encrypted data should not be limited to these terms. These terms are merely used to distinguish one encrypted data from another. For example, without departing from the scope of the embodiments of the present application, the first encrypted data may also be referred to as the second encrypted data, and similarly, the second encrypted data may also be referred to as the first encrypted data.

[0177] The word "if," as used herein, may be interpreted as "at the time of" or "when" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrases "if it is determined" or "if (stated condition or event) is detected" may be interpreted as "when it is determined" or "in response to the determination" or "when detecting (stated condition or event)" or "in response to detecting (stated condition or event)," depending on the context.

[0178] The terms used in the embodiments of the present application are for the purpose of describing specific embodiments only and are not intended to limit the present application. The singular forms "a", "an", "the" and "the" used in the embodiments of the present application and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise.

[0179] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed may be through some interface, indirect coupling or communication connection of the device or unit, which may be electrical, mechanical or other forms.

[0180] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0181] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0182] The embodiments described above are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention, and should all be included in the scope of protection of the present invention.

Claims

1. An online docking method for in-store medical services, characterized in that: include: Obtaining a service arrangement request from a client for a target medical service, wherein the service arrangement request is used to request an appointment, rescheduling, or cancellation of the target medical service; Determining a set of medical service providers available to the client based on the service arrangement request; Obtaining a selection instruction from the client for a target provider in the set of medical service providers; In response to the selection instruction, sending the service arrangement request to the target supplier through the OpenAPI gateway, and obtaining a verification result of the service arrangement request from the target supplier through the OpenAPI gateway; If the verification result is that the service arrangement request is passed, obtaining a response result from the target supplier regarding the service arrangement request; Based on the business line corresponding to the target medical service and the returned result, the execution result of the target supplier on the service arrangement request is determined, and the execution result is sent to the client.

2. The method according to claim 1, characterized in that The determining, based on the service arrangement request, a set of medical service providers available to the client, includes: In response to the acquisition of the service arrangement request, acquiring physical store data of all medical service providers, wherein the physical store data includes: store latitude and longitude coordinates, business status, service hours, and real-time service arrangement space; Based on the GEO hash algorithm, the longitude and latitude coordinates of each medical service provider store are converted into a string; Divide the grid based on the character string of each medical service provider to determine the grid area corresponding to each medical service provider; Performing a grid search with the user location provided by the client as the center to obtain a list of medical service providers from the user location in descending order; A number of medical service providers that are adapted to the service arrangement request are determined in the medical service provider list as a set of medical service providers available to the client.

3. The method according to claim 2, characterized in that The determining of the plurality of medical service providers adapted to the service arrangement request in the medical service provider list includes: If the service period of the medical service provider includes the service arrangement time of the target medical service, and the business status of the medical service provider at the service arrangement time is available, and the medical service provider has a real-time service arrangement space for providing the target medical service, it is determined that the medical service provider adapts to the service arrangement request.

4. The method according to claim 1, wherein The sending the service arrangement request to the target supplier through the OpenAPI gateway includes: Encrypting the service arrangement request by using a 3DES encryption method, and calculating a signature for the service arrangement request by using an HMAC-SHA1 algorithm to obtain first encrypted data; The first encrypted data is sent to the OpenAPI gateway so that the OpenAPI gateway can verify the signature of the first encrypted data and decrypt the first encrypted data to obtain intermediate transmission data, and then call the internal dubbo interface to send the intermediate transmission data to the target supply end.

5. The method according to claim 4, characterized in that The obtaining, through the OpenAPI gateway, a verification result of the service arrangement request from the target supplier, includes: Obtaining second encrypted data after the OpenAPI gateway encrypts the verification result from the target supplier; The second encrypted data is decrypted to obtain the verification result of the target supply end for the service arrangement request.

6. The method according to claim 5, characterized in that Also includes: Set up an access whitelist for the OpenAPI gateway; Before sending the service arrangement request to the target supplier through the OpenAPI gateway, the method further includes: Determine whether the unique identity of the target supplier is in the access whitelist of the OpenAPI gateway; If the unique identifier of the target supplier is in the access whitelist, the step of sending the service arrangement request to the target supplier through the OpenAPI gateway is allowed to be executed, wherein, For each medical service provider, a unique identity is assigned to the medical service provider, and an accessible interface corresponding to the unique identity is determined in the interface list of the OpenAPI gateway.

7. The method according to any one of claims 1 to 6, characterized in that If the service arrangement request includes an appointment or rescheduling for the target medical service, obtaining a response result from the target provider regarding the service arrangement request includes: Obtaining the execution result of the target medical service in the target supply end; The determining, based on the business line corresponding to the target medical service and the returned result, the execution result of the target supplier on the service arrangement request includes: Call the abstract parent class of the business line corresponding to the target medical service, and extract the public process code involved in the business line from the abstract parent class; Based on the public process code, the corresponding public process is executed on the returned result, and in the process of executing the public process, the business line implementation class that inherits the abstract parent class is called to execute the individual process corresponding to the business line.

8. An online docking device for in-store medical services, characterized in that: include: A service arrangement request acquiring unit, configured to acquire a service arrangement request from a client for a target medical service, wherein the service arrangement request is used to request an appointment, rescheduling, or cancellation of the target medical service; a supplier set determining unit, configured to determine a set of medical service suppliers available to the client based on the service arrangement request; A supplier selection unit, configured to obtain a selection instruction from the client for a target supplier in the set of medical service suppliers; a gateway interaction unit, configured to send the service arrangement request to the target supplier through the OpenAPI gateway in response to the selection instruction, and obtain a verification result of the service arrangement request from the target supplier through the OpenAPI gateway; A result feedback unit, configured to obtain a feedback result of the target supplier in response to the service arrangement request if the verification result is that the service arrangement request is passed; A return result processing unit is used to determine the execution result of the target supplier on the service arrangement request based on the business line corresponding to the target medical service and the return result, and send the execution result to the client.

9. A computer device, characterized in that: include: at least one processor; and, a memory communicatively coupled to the at least one processor; The memory stores instructions that can be executed by the at least one processor, and the instructions are configured to enable the processor to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that Computer-executable instructions are stored, and the computer-executable instructions are configured to execute the method according to any one of claims 1 to 7.

Images