WO2014071799A1 - 医疗信息交互传输框架系统 - Google Patents

医疗信息交互传输框架系统 Download PDF

Info

Publication number
WO2014071799A1
WO2014071799A1 PCT/CN2013/085633 CN2013085633W WO2014071799A1 WO 2014071799 A1 WO2014071799 A1 WO 2014071799A1 CN 2013085633 W CN2013085633 W CN 2013085633W WO 2014071799 A1 WO2014071799 A1 WO 2014071799A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
transaction
job
unit
framework system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2013/085633
Other languages
English (en)
French (fr)
Inventor
郭威
张士玉
李理
王晓晖
杜刚
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Mindray Bio Medical Electronics Co Ltd
Original Assignee
Shenzhen Mindray Bio Medical Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Mindray Bio Medical Electronics Co Ltd filed Critical Shenzhen Mindray Bio Medical Electronics Co Ltd
Publication of WO2014071799A1 publication Critical patent/WO2014071799A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation

Definitions

  • the present invention relates to the field of medical devices and medical information systems, and more particularly to a medical information interactive transmission framework system.
  • a medical information interactive transmission framework system includes:
  • An application interface module for receiving data and function requests and forwarding the data and function requests in a common data structure
  • a task management module configured to organize the function request and application data into a transaction, manage the transaction, and perform execution scheduling on the job
  • a protocol implementation module configured to complete information interaction based on an information interaction standard
  • a platform abstract interface module for defining functionality with platform dependencies as a set of abstract interfaces.
  • the application interface module includes:
  • a data incoming unit for constructing and managing the received data into an application data set
  • a task control unit for implementing a commit, cancel, and retry operation of a transaction
  • An information feedback unit for implementing active query and registration notification.
  • the data incoming unit defines an application data set construction method and a data control interface
  • the data element representation method in the application data set construction method defines a set of data types that the transport module can process, wherein Each data element has a unique identifier, the identifier can be customized, each data element has a unique data type
  • the data tree construction method in the application data set construction method defines the data tree node type and the data tree node can be attached Data element; adding, querying, and deleting data operations to the data tree node through the data control interface.
  • data is shared within the same transaction.
  • the task management module includes:
  • An application data management unit for creating and managing an application data tree
  • a multi-tasking data sharing unit for storing application data in a memory and a file during data preparation for use in a job execution process
  • Multitasking parallel control scheduling unit for transaction creation, execution, and scheduling
  • the information query unit is configured to respond to the information query request feedback information.
  • the transaction creation includes: creating a transaction, setting a behavior configuration parameter of the transaction, binding the transaction and the application data tree; and the transaction execution includes: committing the transaction execution, parsing the transaction, creating the job, and submitting the job execution
  • the transaction scheduling adopts a parallel scheduling method.
  • the multitasking parallel control scheduling unit includes a job manager and a job executor, the transaction creating one or more jobs and being submitted to the job manager for unified scheduling, the job execution
  • the device is responsible for completing the execution of the job, each job executor encapsulating a thread, and the scheduling and execution of the job is implemented using multi-threading technology.
  • the save and restore unit sets the transport module implemented by the framework system to a pause state, saves the framework configuration parameters and the transaction serialization when the save is needed, and reads when the recovery is needed.
  • the framework configures parameters and transaction data and deserializes them, and sets the transport module to a pause state.
  • the information query unit provides two types of information query methods: active query and registration update.
  • the protocol implementation module includes:
  • a data conversion unit for converting data into a syntax format specified by an information interaction standard, and converting the received data into an internal format of the framework system
  • the data transceiver unit is configured to implement an underlying message exchange mechanism defined by the information interaction standard, transmit the application data, and receive the incoming data.
  • the medical information interaction transmission framework system is based on analyzing and combing the commonality of information interaction requirements in different application scenarios, and encapsulating various general and abstract system logics in the framework system, and multiplexing in different medical devices and information systems in a framework manner. To support the development of complex medical equipment and information systems, to simplify the development process, reduce development complexity, and improve system quality.
  • FIG. 1 is a block diagram of a medical information interactive transmission framework system
  • FIG. 2 is a block diagram of an application interface module
  • Figure 3 is a schematic diagram of a typical data tree
  • FIG. 4 is a block diagram of a task management module
  • Figure 5 is a block diagram of a protocol implementation module.
  • the medical information interactive transmission framework system is applied in medical equipment and information systems, and the medical information transmission module can be realized after adaptive development for different systems. Based on the analysis and combing of the commonality of information interaction requirements in different application scenarios, various general and abstract system logics are encapsulated in the framework system, and are reused in different medical devices and information systems in a framework manner for complex medical devices and information. System development provides support to simplify the development process, reduce development complexity, and improve system quality.
  • Application modules refer to functional modules that implement problem domain logic control, data display, etc. in medical devices and medical information systems, such as application modules in ultrasound devices, application modules in monitoring devices, or application modules in image archiving and communication systems, etc. .
  • a transaction is a composite information interaction service request, including configuration information and application data, bound to an application data tree.
  • the same transaction can only be bound to one application data tree.
  • a transaction can include multiple jobs.
  • the configuration information contains interaction parameters of relevant standards that the information interaction process needs to comply with, for example DICOM (Digital Imaging and Communications in Medicine), HL7 (Health) Level 7, Health Information Exchange Standard), ASTM (American Society for Testing and Related parameters of standards such as Materials, American Society for Testing and Materials.
  • Job A unit that performs an information interaction service (such as a DICOM service).
  • a transaction can create one or more jobs based on configuration information, and each job corresponds to an interaction process.
  • configuration information of a transaction can be described as requiring an ultrasound image to be stored on servers A and B, and printing through printer C.
  • the transaction will create three jobs, which are completed with A, B, and C, respectively.
  • Interaction. Jobs contained in the same transaction will share application data, such as pixel data in a DICOM service.
  • the medical information interaction transmission framework system (hereinafter referred to as the framework system) includes an application interface module 110, a task management module 120, a protocol implementation module 130, and a platform abstract interface module 140.
  • the application interface module 110 is configured to receive data and function requests and forward the data and function requests in a common data structure.
  • the application interface module 110 is at the outermost layer and is an interface for the application module to access the framework system, and defines the functions and usage modes that the framework system can provide.
  • the application module uses various functions by calling interfaces in the application interface module 110.
  • the application interface module 110 does not have the actual function, but invokes various functional modules of the task management module 120 in a common data structure, and forwards various types of data and function requests transmitted by the application module to the task management module 120.
  • the application interface module 110 is composed of a set of abstract interfaces, and provides a function access interface to the application module.
  • the application interface module 110 defines the interaction behavior and data structure of the application module and the transmission module implemented by the framework system, and the application module and the transmission module are standardized.
  • the cooperation process hides the implementation details of the transmission module, so that the implementation on both sides of the application interface module 110 can be independently changed, the coupling degree is reduced, and the reusability of the framework system is ensured.
  • the application interface module 110 includes a data incoming unit 112, a task control unit 114, and an information feedback unit 116.
  • the data incoming unit 112 is configured to construct the received data into an application data set and manage it. Specifically, the data incoming unit 112 defines an application data set construction method and a data control interface.
  • the data element representation method in the application data set construction method defines a collection of data types that the transport module can handle, where each data element has a unique identifier that can be customized, each data element having a unique data type.
  • the framework system provides basic data elements in the field of medical information and allows users to add custom data elements.
  • the data tree construction method in the application data set construction method defines the data tree node type and the data elements that can be hooked on the data tree node, wherein the data tree node type is divided into a root node, a patient information node, a check information node, a sequence information node, Image information node and file information node.
  • the data tree node can be hooked up to a complete tree as needed by the application.
  • the data tree model is based on an information model in the DICOM standard, and a file information node is added. An example of a typical data tree is shown in the figure. 3 is shown. Add, query, and delete data operations on data tree nodes through the data control interface.
  • the task control unit 114 is configured to implement commit, cancel, and retry operations on transactions, including a transaction commit interface, a cancel interface, and a retry operation interface.
  • the application module provides a transaction commit interface to commit the transaction, cancels the transaction by canceling the interface, and retry the transaction by retrying the operation interface.
  • the information feedback unit 116 is configured to implement active query and registration notification, including an active query interface and a registration update interface.
  • the active query means that the application module queries related information according to the ID of the transaction or the job;
  • the registration update refers to the information that the application module subscribes to the interest type during the lifetime of the job, and when the related interest information is updated during the execution of the job, the order is notified through the callback notification.
  • the task management module 120 implements and encapsulates the general logic by abstracting the task management flow and provides access methods to the changeable parts. When the user develops based on the framework system, the user can directly reuse this part of the function logic, and implement various changes according to different requirements of the application scenario.
  • the task management module 120 organizes the function request and application data into transactions, the transaction including a number of jobs, wherein the function request is expressed by the configuration information.
  • the task management module 120 manages transactions and performs scheduling of jobs. Share application data within the same transaction.
  • the execution of each job invokes the service function of the corresponding information interaction standard (eg, DICOM) of the protocol implementation module 130.
  • DICOM information interaction standard
  • the task management module 120 includes an application data management unit 121, a multitasking data sharing unit 123, a multitasking parallel control scheduling unit 125, a save and restore unit 127, and an information query unit 129.
  • the application data management unit 121 is used for creation and management of an application data tree.
  • the application data management unit 121 implements a data control interface defined by the data incoming unit 112 in the application interface module 110 to perform an operation of adding, querying, and deleting data to the data tree node.
  • Application data includes patient information, examination information, sequence information, image information, and pixel information.
  • Each application data tree contains several nodes, and the application data is stored on different nodes according to the type. The process of node creation, data addition, and node hooking are performed separately and independently of each other.
  • Multitasking data sharing unit 123 (Share Data) is used to save application data in memory and files during data preparation and to provide shared access methods for use during job execution. Different jobs may be executed in parallel, sharing access to shared data.
  • the transaction creates jobs based on the data transfer targets contained in the configuration information, and each job completes the transfer of data to a target.
  • Application data is shared by multiple jobs within the same transaction.
  • the abstract factory pattern is a factory pattern used when there are multiple abstract roles.
  • Multitasking parallel control scheduling unit 125 (Task Control) is used for the creation, execution, and scheduling of transactions.
  • the transaction creation includes: creating a transaction, setting a behavior configuration parameter of the transaction, binding the transaction and the application data tree; and performing the transaction includes: committing the transaction execution, parsing the transaction, creating the job, and submitting the job execution; and the transaction scheduling adopts the parallel scheduling method.
  • the multitasking parallel control scheduling unit 125 includes a job manager and a job executor.
  • a transaction creates one or more jobs and is submitted to the job manager for unified scheduling.
  • the job executor is responsible for completing the execution of the job, and each job executor encapsulates one thread.
  • the job manager uses the policy mode to select a scheduling policy.
  • Different scheduling strategies select different number of job executors, and each job executor corresponds to a job queue to be processed.
  • the scheduling process is activated, the job to be executed is selected from the queue, submitted to the job executor for execution, and the execution ends or When suspended, the next executable job will be looked up from the queue until there are no pending jobs, the job executor goes to sleep and waits for the next activation. Maintain your own status information during job scheduling.
  • the specific job execution logic in the extended job executor can also be supported in the framework system through the abstract factory pattern.
  • the scheduling and execution of the job is implemented using a multi-threading technique.
  • the data transfer task is submitted using a synchronous interface, while the transfer execution uses an asynchronous process that allows the transfer task to execute in the background.
  • the application module does not need to block to wait for execution results, and other functions can be performed after the transfer task is submitted.
  • the framework system feeds back information through the registration and callback mechanism, and implements the registration notification function of the information feedback unit 116.
  • Multi-threaded implementations make more efficient use of system resources and improve overall performance. Programming is more complex than single-threaded approach.
  • the extension of the job scheduling logic can also be supported in the framework system through the policy mode.
  • the strategy pattern defines a set of algorithms and encapsulates each algorithm so that they can also be replaced.
  • the save and restore unit 127 is used to save and restore framework configuration parameters and transactions.
  • the save and restore unit 127 sets the transport module implemented with the framework system to a pause state, serializing the information, including framework configuration parameters (eg, shared memory size of the framework system, scheduling policy, etc.) and transactions.
  • framework configuration parameters eg, shared memory size of the framework system, scheduling policy, etc.
  • serialization of transactions includes configuration information, application data, and serialization of jobs.
  • Job serialization is to pause the job being executed and save the status information, execution parameter information, and so on.
  • Recovery is a deserialization process that reads frame configuration parameters and transaction information from a file, sets up the transport module implemented by the framework system based on the configuration information, and reconstructs the transaction.
  • the reconstruction of the transaction includes parameter configuration and job rebuilding, and the job is suspended after the job is rebuilt.
  • the information query unit 129 is configured to respond to the information query request feedback information, such as the request of the response information feedback unit 116.
  • the information query unit 129 provides two types of information query methods: active query and registration update. Active query means that the application module queries related information according to the ID of the transaction or job; the registration update mode refers to the application module ordering information of a certain interest type to the job during the lifetime of the job, and the callback notification is notified when the interest related information is updated during the execution of the job. Subscriber.
  • the protocol implementation module 130 is an implementation of an information interaction standard (eg, DICOM, HL7, or ASTM) that completes information interaction based on information interaction standards.
  • the protocol implementation module 130 implements a data transmission process based on the information interaction standard.
  • the protocol implementation module 130 includes a service unit 132, a data conversion unit 134, and a data transceiving unit 136.
  • the service unit 132 implements the transmission service flow specified by the information interaction standard, processes the application data according to the standard, and processes the received data.
  • Application data is data used by application modules that require conversion to interact or be processed by the framework system; data received is data that conforms to information interaction standards (such as DICOM, HL7, or ASTM).
  • the service unit 132 implements a transport service flow specified by the DICOM standard. Since the abstract service description is defined in the framework system, the corresponding transmission control process can be implemented according to the specific information interaction standard, such as extending to the HL7 standard.
  • the data conversion unit 134 converts the data into a syntax format specified by the information interaction standard, and converts the received data into an internal format of the framework system. In the present embodiment, the data conversion unit 134 converts the data into a syntax format specified by the DICOM standard. Since the abstract data conversion interface is defined in the framework system, users can implement specific data format conversion according to the information interaction standard, such as extending to the HL7 standard.
  • the data transceiving unit 136 implements an underlying message exchange system defined by the information interaction standard based on the network function interface and the file system function interface, etc., transmits the application data, and receives the incoming data.
  • the data transceiving unit 136 can also allow the user to expand the read and write logic and buffer logic in the process of transceiving data.
  • the platform abstraction interface module 140 defines a functionality with platform dependencies as a set of abstract interfaces.
  • An application system using the framework system implements specific functions according to the abstract interface, such as threads, file systems, underlying transport (network/serial port), semaphores, and compression algorithms.
  • the specific functions of these abstract interfaces are implemented in different application environments according to the requirements of different platforms for use by the framework system.
  • the user must fully implement all the abstract interfaces defined by the platform abstract interface module 140, and must conform to the data structure and function description in the interface definition.
  • the transport module based on the framework system is made platform-independent by the platform abstract interface module 140.
  • the platform abstract interface module 140 implements encapsulation of operating system related functions and is an external dependency of the framework system.
  • the application module needs to implement specific functions according to the abstract interface defined by the platform abstract interface module 140.
  • the function interface of the platform abstract interface module 140 is invoked as needed to access the function implementation provided by the application module.
  • the medical device system medical information system obtained after adaptive development using the medical information interactive transmission frame system still has the framework structure of the above medical information interactive transmission frame system, and therefore still belongs to the protection scope of the present invention.

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Biomedical Technology (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种医疗信息交互传输框架系统，包括：应用接口模块，用于接收数据和功能请求并以通用的数据结构转发所述数据和功能请求；任务管理模块，用于将所述功能请求和应用数据组织成事务，并对所述事务进行管理，对作业进行执行调度；协议实现模块，用于完成基于信息交互标准的信息交互；平台抽象接口模块，用于将具有平台相关性的功能定义为一组抽象接口。上述医疗信息交互传输框架系统通过在医疗信息交互传输框架系统中封装数据传输过程中的数据结构、任务管理和控制等逻辑，提供复用信息交互通用功能的方法，可以简化开发过程，降低开发复杂度，提高产品质量。

Description

医疗信息交互传输框架系统
【技术领域】
本发明涉及医疗设备和医疗信息系统领域，特别是涉及医疗信息交互传输框架系统。
【背景技术】
随着医疗信息电子化的发展，基于传统介质的信息交互手段无法满足信息交互的需求，医疗设备和信息系统间需要进行大量电子化信息的交互，例如在各种图像获取设备、检验设备、监护设备、HIS系统（Hospital Information System，医院信息系统）、PACS系统（Picture Archiving and Communication Systems，影像归档和通信系统）和CMIS系统（Clinical Monitoring Information Station，临床监护信息系统）间传递病人相关信息，包括病人姓名、病人ID等人口统计学信息和检查图像等。信息的内容复杂，数据格式各异，不同设备间软硬件差别较大。在信息交互过程需要遵守相关标准，如DICOM（Digital Imaging and Communications in Medicine，医疗图像传输标准）、HL7（Health Level 7，卫生信息交换标准）、ASTM（American Society for Testing and Materials，美国实验与材料协会标准）等。
各种医疗设备和医疗信息系统的实现中都需要包括符合相应传输标准的数据传输模块。随着应用层复杂性的增长，需要完成的数据传输任务逐步增多。通常，用户希望能够在提交传输任务后继续其他操作，并且能够提交多个任务，在任务执行完成后获得执行结果信息。
这就要求系统具备后台处理信息交互任务的能力，并实现多交互任务并行执行的管理和调度方法，以避免用户长时间等待。一般不同的系统需要按照不同的传输标准和具体的应用需求来实现类似的任务管理和数据传输模块，逻辑复杂度高，开发难度大。
【发明内容】
基于此，有必要针对一般不同的系统需要按照不同的传输标准和具体的应用需求来实现类似的任务管理和数据传输模块，逻辑复杂度高，开发难度大的问题，提出一种集成简单、功能完善的医疗信息交互传输框架系统。
一种医疗信息交互传输框架系统，包括：
应用接口模块，用于接收数据和功能请求并以通用的数据结构转发所述数据和功能请求；
任务管理模块，用于将所述功能请求和应用数据组织成事务，并对所述事务进行管理，对作业进行执行调度；
协议实现模块，用于完成基于信息交互标准的信息交互；
平台抽象接口模块，用于将具有平台相关性的功能定义为一组抽象接口。
在其中一个实施例中，所述应用接口模块包括：
数据传入单元，用于将接收的数据构建成应用数据集并对其进行管理；
任务控制单元，用于实现对事务的提交、取消和重试操作；
信息反馈单元，用于实现主动查询和注册通知。
在其中一个实施例中，所述数据传入单元定义了应用数据集构建方法和数据控制接口，所述应用数据集构建方法中的数据元素表示方法定义传输模块能够处理的数据类型的集合，其中每个数据元素具有唯一标识，所述标识可自定义扩展，每个数据元素具有唯一的数据类型；应用数据集构建方法中的数据树构建方法定义数据树节点类型及数据树节点上可挂接的数据元素；通过所述数据控制接口对数据树节点进行添加、查询和删除数据操作。
在其中一个实施例中，在同一事务内部共享数据。
在其中一个实施例中，所述任务管理模块包括：
应用数据管理单元，用于对应用数据树的创建和管理；
多任务数据共享单元，用于在数据准备过程中将应用数据保存在内存和文件中，供作业执行过程中使用；
多任务并行控制调度单元，用于事务的创建、执行和调度；
保存和恢复单元，用于保存和恢复框架配置参数和事务；
信息查询单元，用于响应信息查询请求反馈信息。
在其中一个实施例中，所述事务创建包括：创建事务、设置事务的行为配置参数、绑定事务与应用数据树；所述事务执行包括：提交事务执行、解析事务，创建作业、提交作业执行；所述事务调度采用并行调度方法。
在其中一个实施例中，所述多任务并行控制调度单元包括作业管理器和作业执行器，所述事务创建一个或多个作业并被提交给所述作业管理器进行统一调度，所述作业执行器负责完成作业的执行，每个作业执行器封装一个线程，所述作业的调度和执行采用多线程技术实现。
在其中一个实施例中，所述保存和恢复单元在需要保存时，将用该框架系统实现的传输模块设置为暂停状态，将框架配置参数和事务序列化实现保存；在需要恢复时，读取框架配置参数和事务数据并进行反序列化，并将传输模块设置为暂停状态。
在其中一个实施例中，所述信息查询单元提供主动查询和注册更新两种信息查询方式。
在其中一个实施例中，所述协议实现模块包括：
服务单元，用于实现信息交互标准规定的传输服务流程；
数据转换单元，用于将数据转换为信息交互标准规定的语法格式，并将收到的数据转换为框架系统内部格式；
数据收发单元，用于实现信息交互标准定义的底层消息交换机制，将应用数据传输出去，并接收传入的数据。
上述医疗信息交互传输框架系统基于对不同应用场景下信息交互需求共性的分析和梳理，在框架系统中封装各种通用和抽象的系统逻辑，以框架的方式在不同医疗设备和信息系统中复用，为复杂医疗设备和信息系统的开发提供支持，达到简化开发过程，降低开发复杂度，提高系统质量的目的。
【附图说明】
图1为医疗信息交互传输框架系统的模块图；
图2为应用接口模块的模块图；
图3为一个典型的数据树的示意图；
图4为任务管理模块的模块图；
图5为协议实现模块的模块图。
【具体实施方式】
以下通过附图和具体实施例对导电元件及其制备方法做进一步说明。
医疗信息交互传输框架系统应用在医疗设备和信息系统中，针对不同系统进行适应性开发后即可实现医疗信息传输模块。基于对不同应用场景下信息交互需求共性的分析和梳理，在框架系统中封装各种通用和抽象的系统逻辑，以框架的方式在不同医疗设备和信息系统中复用，为复杂医疗设备和信息系统的开发提供支持，达到简化开发过程，降低开发复杂度，提高系统质量的目的。
在以下实施方式中：
应用模块是指医疗设备和医疗信息系统中实现问题域逻辑控制、数据显示等的功能模块，例如超声设备中的应用模块、监护设备中的应用模块或影像归档和通信系统中的应用模块等等。
事务是指一个复合的信息交互服务请求，包括配置信息和应用数据，与某个应用数据树绑定，同一事务只能与一个应用数据树绑定。事务可包括多个作业。配置信息包含信息交互过程需要遵守的相关标准的交互参数，例如 DICOM （ Digital Imaging and Communications in Medicine，医疗图像传输标准 ）、 HL7 （Health Level 7，卫生信息交换标准）、ASTM（American Society for Testing and Materials，美国实验与材料协会标准）等标准的相关参数。
作业：执行信息交互服务（例如DICOM服务）的单元。由事务创建，事务可以根据配置信息创建一个或多个作业，每个作业对应一个交互过程。例如，一个事务的配置信息中可以描述为要求一张超声图像存储到服务器A和B上，并通过打印机C进行打印，此时，该事务将创建三个作业，分别完成与A、B和C的交互。同一事务包含的作业将共享应用数据，例如DICOM服务中的像素数据。
如图1所示，医疗信息交互传输框架系统（以下简称框架系统）包括应用接口模块110、任务管理模块120、协议实现模块130及平台抽象接口模块140。
应用接口模块110用于接收数据和功能请求，并以通用的数据结构转发所述数据和功能请求。应用接口模块110处于最外层，是应用模块访问本框架系统的接口，定义了框架系统能够提供的功能和使用方式。应用模块通过调用应用接口模块110中的接口使用各种功能。应用接口模块110本身不具备实际功能，而是以通用的数据结构，调用任务管理模块120的各个功能模块，将应用模块传入的各类数据和功能请求转发给任务管理模块120。应用接口模块110由一组抽象接口组成，向应用模块提供功能访问接口，应用接口模块110定义了应用模块与由该框架系统实现的传输模块的交互行为和数据结构，规范了应用模块与传输模块的协作过程，隐藏了传输模块的实现细节，使应用接口模块110两侧的实现可以独立变化，降低了耦合度，保证了框架系统的可重用性。
本实施例中，如图2所示，应用接口模块110包括数据传入单元112、任务控制单元114和信息反馈单元116。
数据传入单元112用于将接收的数据构建成应用数据集并对其进行管理。具体来说，数据传入单元112定义了应用数据集构建方法和数据控制接口。应用数据集构建方法中的数据元素表示方法定义传输模块能够处理的数据类型的集合，其中每个数据元素具有唯一标识，该标识可自定义扩展，每个数据元素具有唯一的数据类型。框架系统提供医疗信息领域基本的数据元素，并允许用户添加自定义数据元素。应用数据集构建方法中的数据树构建方法定义数据树节点类型及数据树节点上可挂接的数据元素，其中数据树节点类型分为根节点、病人信息节点、检查信息节点、序列信息节点、图像信息节点和文件信息节点。数据树节点可按照应用需要挂接为一颗完整的树。本实施例中，该数据树模型基于DICOM标准中的信息模型，并增加了文件信息节点，一个典型的数据树的例子如图 3所示。通过数据控制接口对数据树节点进行添加、查询和删除数据操作。
任务控制单元114用于实现对事务的提交、取消和重试操作，包括事务提交接口、取消接口、重试操作接口。应用模块提供事务提交接口提交事务，通过取消接口取消事务，通过重试操作接口进行事务的重试。
信息反馈单元116用于实现主动查询和注册通知，包括主动查询接口和注册更新接口。主动查询指应用模块根据事务或作业的ID查询相关信息；注册更新指应用模块在作业生存期内向作业订购某兴趣类型的信息，当作业执行中该类兴趣相关信息更新时，将通过回调通知订购者。
任务管理模块120通过对任务管理流程的抽象，实现并封装了通用逻辑，并提供对可变化部分的访问方法。用户基于该框架系统开发时，能够直接重用这部分功能逻辑，并根据应用场景的不同需求来实现各种变化。任务管理模块120将功能请求和应用数据组织成事务，事务包括若干作业，其中功能请求通过配置信息表达。任务管理模块120对事务进行管理，对作业进行执行调度。在同一事务内部共享应用数据。每个作业的执行，都会调用协议实现模块130的相应的信息交互标准（例如DICOM）的服务功能。
如图4所示，本实施例中，任务管理模块120包括应用数据管理单元121、多任务数据共享单元123、多任务并行控制调度单元125、保存和恢复单元127和信息查询单元129。
应用数据管理单元121用于对应用数据树的创建和管理。应用数据管理单元121实现了应用接口模块110中的数据传入单元112定义的数据控制接口对数据树节点执行添加、查询和删除数据操作。应用数据包括病人信息、检查信息、序列信息、图像信息和像素信息等。每棵应用数据树包含若干节点，应用数据根据类型分别保存在不同节点上。节点创建、数据添加和节点挂接的过程分别进行，彼此独立。
多任务数据共享单元123（Share Data）用于在数据准备过程中将应用数据保存在内存和文件中，并提供共享访问的方法，供作业执行过程中使用。不同作业可能并行执行，将互斥访问共享数据。事务根据配置信息中包含的数据传输目标来创建作业，每个作业完成向一个目标的数据传输。在同一事务范围内的多个作业共享应用数据。框架系统中，还可以通过抽象工厂模式支持扩展事务内共享数据的保存和读取逻辑。抽象工厂模式是指当有多个抽象角色时，使用的一种工厂模式。
多任务并行控制调度单元125（Task Control）用于事务的创建、执行和调度。事务创建包括：创建事务、设置事务的行为配置参数、绑定事务与应用数据树；事务执行包括：提交事务执行、解析事务，创建作业、提交作业执行；事务调度采用并行调度方法。多任务并行控制调度单元125包括作业管理器和作业执行器。事务创建一个或多个作业并被提交给作业管理器进行统一调度。作业执行器负责完成作业的执行，每个作业执行器封装一个线程。作业管理器采用策略模式选定调度策略。不同调度策略选择不同数量的作业执行器，每个作业执行器对应一个待处理的作业队列，当激活调度过程时，将从队列中选择待执行的作业，提交给作业执行器执行，执行结束或被暂停时，将从该队列中寻找下一个可执行的作业，直至没有任何待执行作业，则作业执行器进入休眠状态，等待下次激活。作业调度过程中维护自身的状态信息。框架系统中还可以通过抽象工厂模式支持扩展作业执行器中具体的作业执行逻辑。
本实施例中，作业的调度和执行采用多线程技术实现。数据传输任务的提交采用同步接口，而传输执行采用异步过程，允许传输任务在后台执行。应用模块不需要阻塞来等待执行结果，在提交传输任务后，可以执行其他功能。框架系统通过注册和回调机制来反馈信息，实现信息反馈单元116的注册通知功能。多线程的实现方式能够更有效的利用系统资源，提高整体性能，与单线程方式相比，编程也更复杂。框架系统中还可以通过策略模式支持作业调度逻辑的扩展。策略模式定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。
保存和恢复单元127用于保存和恢复框架配置参数和事务。保存和恢复单元127将用该框架系统实现的传输模块设置为暂停状态，将信息序列化，包括框架配置参数（例如框架系统的共享内存大小、调度策略等）和事务。其中，事务的序列化包括配置信息、应用数据和作业的序列化。作业序列化是将正在执行的作业暂停，并将状态信息和执行参数信息等保存。恢复是一个反序列化过程，从文件中读取框架配置参数和事务信息，根据配置信息设置框架系统实现的传输模块，并重建事务。事务的重建包括参数配置和作业重建，作业重建后处于暂停状态。
信息查询单元129用于响应信息查询请求反馈信息，例如响应信息反馈单元116的请求。信息查询单元129提供主动查询和注册更新两种信息查询方式。主动查询指应用模块根据事务或作业的ID查询相关信息；注册更新方式指应用模块在作业生存期内向作业订购某兴趣类型的信息，当作业执行中该类兴趣相关信息更新时，将通过回调通知订购者。
协议实现模块130是对信息交互标准（例如DICOM、HL7或ASTM）的实现，完成基于信息交互标准的信息交互。协议实现模块130实现了基于信息交互标准的数据传输流程，如图5所示，包括服务单元132、数据转换单元134及数据收发单元136。
服务单元132实现信息交互标准规定的传输服务流程，按照标准规定处理应用数据，并处理收到的数据。应用数据是应用模块使用的数据，需要转换才能进行交互或是由框架系统处理；收到的数据是符合信息交互标准（例如DICOM、HL7或ASTM）的数据。本实施例中，服务单元132实现DICOM标准规定的传输服务流程。由于框架系统中定义了抽象的服务描述，根据具体采用的信息交互标准可以实现相应的传输控制流程，如扩展到HL7标准等。
数据转换单元134将数据转换为信息交互标准规定的语法格式，并将收到的数据转换为框架系统内部格式。本实施例中，数据转换单元134将数据转换为DICOM标准规定的语法格式。由于框架系统中定义了抽象的数据转换接口，用户可以根据信息交互标准来实现具体的数据格式转换，如扩展到HL7标准。
数据收发单元136基于网络功能接口和文件系统功能接口等，实现信息交互标准定义的底层消息交换机制，将应用数据传输出去，并接收传入的数据。数据收发单元136还可以允许用户扩展收发数据过程中的读写逻辑和缓冲逻辑。
平台抽象接口模块140将具有平台相关性的功能定义为一组抽象接口。使用所述框架系统的应用系统根据所述抽象接口实现具体功能，例如线程、文件系统、底层传输（网络/串口）、信号量和压缩算法等。在不同应用环境中依据不同平台的要求实现这些抽象接口的具体功能，供框架系统使用。本实施例中，用户必须完全实现平台抽象接口模块140定义的所有抽象接口，并且必须符合接口定义中的数据结构和功能描述。通过平台抽象接口模块140使基于框架系统实现的传输模块具有平台无关性。具体来说，平台抽象接口模块140实现了对操作系统相关功能的封装，是本框架系统对外部的依赖。应用模块需要根据平台抽象接口模块140定义的抽象接口实现具体功能。在任务管理模块120和协议实现模块130中会根据需要，调用平台抽象接口模块140的功能接口，访问应用模块提供的功能实现。
容易理解，采用上述医疗信息交互传输框架系统进行适应性开发后获得的医疗设备系统医疗信息系统由于仍然具备上述医疗信息交互传输框架系统的框架结构，因此仍然属于本发明的保护范围。
以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (16)

  1. 一种医疗信息交互传输框架系统，其特征在于，包括：
    应用接口模块，用于接收数据和功能请求并以通用的数据结构转发所述数据和功能请求；
    任务管理模块，用于将所述功能请求和应用数据组织成事务，并对所述事务进行管理，对作业进行执行调度；
    协议实现模块，用于完成基于信息交互标准的信息交互；
    平台抽象接口模块，用于将具有平台相关性的功能定义为一组抽象接口。
  2. 根据权利要求1所述的医疗信息交互传输框架系统，其特征在于，所述应用接口模块包括：
    数据传入单元，用于将接收的数据构建成应用数据集并对其进行管理；
    任务控制单元，用于实现对事务的提交、取消和重试操作；
    信息反馈单元，用于实现主动查询和注册通知。
  3. 根据权利要求2所述的医疗信息交互传输框架系统，其特征在于，所述数据传入单元定义了应用数据集构建方法和数据控制接口，所述应用数据集构建方法中的数据元素表示方法定义传输模块能够处理的数据类型的集合，其中每个数据元素具有唯一标识，所述标识可自定义扩展，每个数据元素具有唯一的数据类型；应用数据集构建方法中的数据树构建方法定义数据树节点类型及数据树节点上可挂接的数据元素；通过所述数据控制接口对数据树节点进行添加、查询和删除数据操作。
  4. 根据权利要求1所述的医疗信息交互传输框架系统，其特征在于，在同一事务内部共享数据。
  5. 根据权利要求2所述的医疗信息交互传输框架系统，其特征在于，在同一事务内部共享数据。
  6. 根据权利要求1所述的医疗信息交互传输框架系统，其特征在于，所述任务管理模块包括：
    应用数据管理单元，用于对应用数据树的创建和管理；
    多任务数据共享单元，用于在数据准备过程中将应用数据保存在内存和文件中，供作业执行过程中使用；
    多任务并行控制调度单元，用于事务的创建、执行和调度；
    保存和恢复单元，用于保存和恢复框架配置参数和事务；
    信息查询单元，用于响应信息查询请求反馈信息。
  7. 根据权利要求2所述的医疗信息交互传输框架系统，其特征在于，所述任务管理模块包括：
    应用数据管理单元，用于对应用数据树的创建和管理；
    多任务数据共享单元，用于在数据准备过程中将应用数据保存在内存和文件中，供作业执行过程中使用；
    多任务并行控制调度单元，用于事务的创建、执行和调度；
    保存和恢复单元，用于保存和恢复框架配置参数和事务；
    信息查询单元，用于响应信息查询请求反馈信息。
  8. 根据权利要求6所述的医疗信息交互传输框架系统，其特征在于，所述事务创建包括：创建事务、设置事务的行为配置参数、绑定事务与应用数据树；
    所述事务执行包括：提交事务执行、解析事务，创建作业、提交作业执行；所述事务调度采用并行调度方法。
  9. 根据权利要求7所述的医疗信息交互传输框架系统，其特征在于，所述事务创建包括：创建事务、设置事务的行为配置参数、绑定事务与应用数据树；所述事务执行包括：提交事务执行、解析事务，创建作业、提交作业执行；所述事务调度采用并行调度方法。
  10. 根据权利要求6所述的医疗信息交互传输框架系统，其特征在于，所述多任务并行控制调度单元包括作业管理器和作业执行器，所述事务创建一个或多个作业并被提交给所述作业管理器进行统一调度，所述作业执行器负责完成作业的执行，每个作业执行器封装一个线程，所述作业的调度和执行采用多线程技术实现。
  11. 根据权利要求7所述的医疗信息交互传输框架系统，其特征在于，所述多任务并行控制调度单元包括作业管理器和作业执行器，所述事务创建一个或多个作业并被提交给所述作业管理器进行统一调度，所述作业执行器负责完成作业的执行，每个作业执行器封装一个线程，所述作业的调度和执行采用多线程技术实现。
  12. 根据权利要求6所述的医疗信息交互传输框架系统，其特征在于，所述保存和恢复单元在需要保存时，将用该框架系统实现的传输模块设置为暂停状态，将框架配置参数和事务序列化实现保存；在需要恢复时，读取框架配置参数和事务数据进行反序列化，并将传输模块设置为暂停状态。
  13. 根据权利要求7所述的医疗信息交互传输框架系统，其特征在于，所述保存和恢复单元在需要保存时，将用该框架系统实现的传输模块设置为暂停状态，将框架配置参数和事务序列化实现保存；在需要恢复时，读取框架配置参数和事务数据进行反序列化，并将传输模块设置为暂停状态。
  14. 根据权利要求6所述的医疗信息交互传输框架系统，其特征在于，所述信息查询单元提供主动查询和注册更新两种信息查询方式。
  15. 根据权利要求7所述的医疗信息交互传输框架系统，其特征在于，所述信息查询单元提供主动查询和注册更新两种信息查询方式。
  16. 根据权利要求1所述的医疗信息交互传输框架系统，其特征在于，所述协议实现模块包括：
    服务单元，用于实现信息交互标准规定的传输服务流程；
    数据转换单元，用于将数据转换为信息交互标准规定的语法格式，并将收到的数据转换为框架系统内部格式；
    数据收发单元，用于实现信息交互标准定义的底层消息交换机制，将应用数据传输出去，并接收传入的数据。
PCT/CN2013/085633 2012-11-08 2013-10-22 医疗信息交互传输框架系统 Ceased WO2014071799A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201210444250.5 2012-11-08
CN201210444250.5A CN103810362B (zh) 2012-11-08 2012-11-08 医疗信息交互传输框架系统

Publications (1)

Publication Number Publication Date
WO2014071799A1 true WO2014071799A1 (zh) 2014-05-15

Family

ID=50684035

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2013/085633 Ceased WO2014071799A1 (zh) 2012-11-08 2013-10-22 医疗信息交互传输框架系统

Country Status (2)

Country Link
CN (1) CN103810362B (zh)
WO (1) WO2014071799A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111476533A (zh) * 2020-03-05 2020-07-31 武汉和悦数字科技有限公司 一种基于信息交互的互联网管理平台

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105306561B (zh) * 2015-10-13 2018-12-25 上海联影医疗科技有限公司 医学成像系统的服务请求处理方法及医学成像系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101063990A (zh) * 2006-04-30 2007-10-31 迈世亚（北京）科技有限公司 医疗信息处理系统及方法
CN101599110A (zh) * 2009-04-30 2009-12-09 北京大学人民医院 紧急医学救援无线移动信息管理方法及平台
US20110119088A1 (en) * 2009-07-21 2011-05-19 Shane Gunn Cloud-based healthcare information exchange
CN102185898A (zh) * 2011-04-14 2011-09-14 中山爱科数字科技有限公司 一种多协议的医疗数据共享和服务集成系统及实现方法
CN101937489B (zh) * 2010-08-26 2012-03-21 无锡北邮感知技术产业研究院有限公司 基于事件驱动的导医信息服务系统及其工作方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1598858A (zh) * 2004-05-13 2005-03-23 郑州市疾病预防控制中心 数字化医院信息一体化管理系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101063990A (zh) * 2006-04-30 2007-10-31 迈世亚（北京）科技有限公司 医疗信息处理系统及方法
CN101599110A (zh) * 2009-04-30 2009-12-09 北京大学人民医院 紧急医学救援无线移动信息管理方法及平台
US20110119088A1 (en) * 2009-07-21 2011-05-19 Shane Gunn Cloud-based healthcare information exchange
CN101937489B (zh) * 2010-08-26 2012-03-21 无锡北邮感知技术产业研究院有限公司 基于事件驱动的导医信息服务系统及其工作方法
CN102185898A (zh) * 2011-04-14 2011-09-14 中山爱科数字科技有限公司 一种多协议的医疗数据共享和服务集成系统及实现方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111476533A (zh) * 2020-03-05 2020-07-31 武汉和悦数字科技有限公司 一种基于信息交互的互联网管理平台

Also Published As

Publication number Publication date
CN103810362A (zh) 2014-05-21
CN103810362B (zh) 2017-02-22

Similar Documents

Publication Publication Date Title
JP2677744B2 (ja) 分散メモリ式デジタル計算システム
CN102456052B (zh) 一种嵌入式设备与数据库数据同步方法
CN101950300A (zh) 一种分层结构、分布式搜索引擎系统及其实现方法
CN116383175B (zh) 一种数据加载方法、装置、设备及计算机可读介质
CN102185898B (zh) 一种多协议的医疗数据共享和服务集成系统及实现方法
CN114430535A (zh) 一种基于5g移动通信的picu数字化病房系统
Xu et al. Integration of medical applications: the ‘mediator service’of the SynEx platform
WO2014071799A1 (zh) 医疗信息交互传输框架系统
CN101779985A (zh) 医疗设备集成装置及系统
CN102411502B (zh) 一种组件式传感节点及其构造方法
CN107729470A (zh) 一种图像数据处理方法及装置
CN109445966A (zh) 事件处理方法、装置、介质和计算设备
Brettlecker et al. Hyperdatabases for peer-to-peer data stream processing
CN112887227A (zh) 一种固态硬盘中的报文接收方法、系统及相关装置
US20080133271A1 (en) Job dispatcher for medical intelligent server architecture
Hristidis et al. A flexible approach for electronic medical records exchange
CN117130802A (zh) 面向智能化无人飞行器的分布式资源协同调度方法
JP3182800B2 (ja) 分散処理システム
CN115858203A (zh) 异构功能交互信息翻译系统及方法
US9124648B2 (en) Soft type binding for distributed systems
CN119363821B (zh) 存储系统的通信方法、装置和计算机设备
CN113761246A (zh) 数据获取方法、装置、电子设备和存储介质
WO2022016560A1 (zh) 一种紧凑型的医疗影像智能存储服务系统
CN116594784B (zh) 一种边边调度方法、装置、系统和可读存储介质
CN201919015U (zh) 数字家庭的服务总线系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13852558

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205N DATED 15/07/2015)

122 Ep: pct application non-entry in european phase

Ref document number: 13852558

Country of ref document: EP

Kind code of ref document: A1