WO2015137646A1 - 대상체의 의료 정보를 생성하는 방법 및 장치 - Google Patents

대상체의 의료 정보를 생성하는 방법 및 장치 Download PDF

Info

Publication number
WO2015137646A1
WO2015137646A1 PCT/KR2015/001851 KR2015001851W WO2015137646A1 WO 2015137646 A1 WO2015137646 A1 WO 2015137646A1 KR 2015001851 W KR2015001851 W KR 2015001851W WO 2015137646 A1 WO2015137646 A1 WO 2015137646A1
Authority
WO
WIPO (PCT)
Prior art keywords
filter
cloud
task
content
external
Prior art date
Application number
PCT/KR2015/001851
Other languages
English (en)
French (fr)
Inventor
최승욱
Original Assignee
(주)아이알엠
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
Priority claimed from KR1020140109953A external-priority patent/KR101633911B1/ko
Application filed by (주)아이알엠 filed Critical (주)아이알엠
Priority to US15/111,830 priority Critical patent/US20160350485A1/en
Publication of WO2015137646A1 publication Critical patent/WO2015137646A1/ko
Priority to US17/308,513 priority patent/US11901075B2/en

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
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records

Definitions

  • a method and apparatus for generating medical information of a subject More specifically, the present invention relates to a method and apparatus for forming a filter for generating medical information of an object by performing a predetermined task. The present invention also relates to a method and apparatus for generating medical information of an object using a workflow designed with at least one filter for performing a predetermined task.
  • Cloud Computing refers to a computing environment based on the Internet or a network.
  • the program infrastructure is built on data servers existing on the Internet, and users can use the programs stored in the data servers through computers, mobile phones, etc. when they want to use them.
  • computing resources such as hardware and / or software that exist in an intangible form, such as a cloud, can be accessed by a user through a terminal (terminal or client) such as a computer or a mobile phone.
  • a method and apparatus for generating medical information of a subject are disclosed.
  • the present invention provides a computer-readable recording medium having recorded thereon a program for executing the method on a computer.
  • the technical problem to be solved is not limited to the above technical problems, and other technical problems may exist.
  • a method of generating information on a filter includes: setting at least one filter class corresponding to a task for generating medical information of an object; Setting at least one filter included in the filter class to perform the task; And setting at least one condition required for the operation of the filter.
  • a computer-readable recording medium includes a recording medium recording a program for executing the above-described method on a computer.
  • an apparatus for generating information about a filter includes a filter class setting unit configured to set at least one filter class corresponding to a task for generating medical information of an object; A filter setting unit included in the filter class and setting at least one filter to perform the task; And a filter condition setting unit that sets at least one condition required for the operation of the filter.
  • a method of generating medical information of an object may include receiving at least one or more first contents from at least one of external devices connected to a cloud; Selecting a first filter that performs an operation based on the first content among filters included in each of a plurality of filter classes; And performing a preset operation by the first filter.
  • a computer-readable recording medium includes a recording medium recording a program for executing the above-described method on a computer.
  • an apparatus included in a cloud system for generating medical information of an object may include an interface unit configured to receive at least one or more first contents from at least one of external devices connected to the cloud; And a filter selector configured to select a first filter that performs a preset task based on the first content among filters included in each of the plurality of filter classes.
  • medical information of the object may be generated without user intervention.
  • the medical information of the object since the medical information of the object may be generated and provided based on an open platform, the medical information of the object may be provided without limitation of time and space.
  • medical information of the object may be generated without user intervention.
  • FIG. 1 is a conceptual diagram illustrating an example of a medical information providing system according to an exemplary embodiment of the present invention.
  • FIG. 2 is a block diagram illustrating an example of a medical information providing system according to an exemplary embodiment of the present invention.
  • FIG. 3 is a flowchart illustrating an example in which the medical information providing system according to an embodiment of the present invention operates.
  • FIG. 4 is a diagram illustrating an example of a workflow according to an embodiment of the present invention.
  • FIG. 5 is a view for explaining an example of an external filter according to an embodiment of the present invention.
  • FIG. 6 is a view for explaining an example of a communication protocol used in the medical information providing system according to an embodiment of the present invention.
  • FIG. 7 is a diagram illustrating an example of an apparatus for generating information about a filter according to an embodiment of the present invention.
  • FIG. 8 is a flowchart illustrating an example of a method of generating information about a filter according to an embodiment of the present invention.
  • FIG. 9 is a block diagram illustrating an example of an apparatus for generating medical information of an object according to an embodiment of the present invention.
  • FIG. 10 is a flowchart illustrating an example of a method of generating medical information of an object according to an exemplary embodiment.
  • FIG. 1 is a conceptual diagram illustrating an example of a medical information providing system 100 according to an embodiment of the present invention.
  • the medical information providing system 100 includes a cloud 110 and a user 130.
  • FIG. 1 illustrates the user 130 for convenience of explanation, the user 130 is a concept that includes an external device that can be connected to the cloud 110 as a device used by the user 130.
  • the cloud 110 may be implemented as a predetermined server to which one or more external devices can be connected through wired or wireless communication.
  • the medical information providing system 100 refers to a system for forming medical information of an object based on the cloud 110 and providing the same to the user 130.
  • the subject may be a patient requiring diagnosis, but is not limited thereto.
  • the medical information providing system 100 may form medical information of the object based on an open platform and provide the same to the user 130.
  • the medical information providing system 100 searches, stores, transmits, inquires, and exchanges medical information based on medical information standards such as IHE, DICOM, and HL7 and international standards such as W3C and ISO.
  • the service 120 provided by the medical information providing system 100 may include providing or processing medical information, a tele-medicine service, a clinical decision supporting system service, and medical information. Storage or sharing services, server-side computing services, social networking services, and the like.
  • the present invention is not limited to the above-described services, and if the service is about an action that can be performed by the user using medical information, the service 120 provided by the medical information providing system 100 according to an embodiment of the present invention may be provided. It can be applied without limitation.
  • FIG. 2 is a block diagram illustrating an example of a medical information providing system 200 according to an embodiment of the present invention.
  • the architecture 230 includes an infrastructure 2310, an internal filter 2320, a data store 2330, a controller 2340, a platform-level API 2350, and a service specific API. specific API) 2360 and user interface 2370.
  • the control unit 2340 includes a data set handler 2341, a workflow manager 2342, a patient manager 2343, a user manager 2344, a group manager 2345, and a condition manager 2346. ) Is included.
  • the controller 2340 further includes a filter manager.
  • the type of service 210 is as described above with reference to FIG. Therefore, detailed description is omitted below.
  • the external filter 220 refers to a filter that operates outside of the cloud.
  • the external filter 220 performs an operation outside the database of the cloud.
  • the external filter 220 may be included in at least one or more of the external devices connected to the cloud.
  • the information on the external filter 220 may be generated, set, changed, or deleted in the filter manager of the architecture 230 and transmitted to the external device, or may be created, set, changed, or deleted in the external device.
  • the architecture 230 illustrated in FIG. 2 corresponds to an example that may be implemented in the cloud 110 of FIG. 1. Accordingly, it will be understood by those skilled in the art that other general purpose components may be further included in addition to the components shown in FIG. 2.
  • the infrastructure 2310, the data store 2330, the controller 2340, the platform level API 2350, the service specific API 2360, and the user interface 2370 included in the architecture 230 illustrated in FIG. 2. May correspond to one or a plurality of processors.
  • the processor may be implemented as an array of multiple logic gates, or may be implemented as a combination of a general purpose microprocessor and a memory storing a program that may be executed on the microprocessor.
  • the present embodiment may be implemented in other forms of hardware.
  • the data store 2330 stores and manages all kinds of content that the cloud can process.
  • the content refers to all kinds of documents including text, images, and videos.
  • the content includes all kinds of documents that can be processed in common computing devices such as images, waveforms, measured values. Therefore, content and document in one embodiment of the present invention are described in the same concept.
  • one document may be included in zero or more document sets (hereinafter, DocSets).
  • a document may not be included in a document set or may be included in one or more document sets.
  • certain documents must belong to one group.
  • the group may mean a group in a physical organization such as a hospital, a department, or a department, or may mean a virtual set of users. Details of the group will be described later.
  • an ID for identifying each document is assigned. Types and definitions of IDs associated with documents according to an embodiment of the present invention are shown in Table 1 below.
  • Table 1 Type Justice Document UID Unique ID of the document, unique within the specific group that created the document.
  • Document UUID A unique ID, separate from the Document UID, that is unique within the entire document. For example, there is one Document UID of the first document, but the Document UUID may be changed every time the first document is transmitted (or processed).
  • Filter UID ID representing the filter that created the document.
  • Patient Id ID representing the patient associated with the document.
  • Each document according to an embodiment of the present invention has a unique ID (UID), which ensures that the UID is unique only within a specific group.
  • UUID unique ID
  • each and every document has a unique UUID separate from the UID, which ensures that it is unique within the entire document.
  • Documents in the cloud according to an embodiment of the present invention correspond to Document Entry in the IHE XDS concept.
  • the data set handler 2341 manages a document set.
  • the dataset handler 2341 may generate, set, change, or delete a document set.
  • DocSet means a virtual set of actual documents. All processing in the cloud is done in document sets. In addition, a particular document set must belong to one group. In the cloud, an ID for identifying each document set is assigned. Types and definitions of IDs associated with a document set according to an embodiment of the present invention are shown in Table 2 below.
  • DocSet UID Unique ID of a document set, unique within the specific group that created the document set.
  • DocSet UUID Unique ID, separate from the DocSet UID, that is unique within the entire document set. For example, the DocSet UID of the first document set is one, but the DocSet UUID may be different each time the first document set is transmitted (or processed).
  • DocSet Class UID A type of document set that is used to specify the filter's input and output format.
  • DocSet Group UID Used to express associations between document sets. Filter UID Represents the filter that created the document set. Patient Id Represents a patient associated with a set of documents.
  • a document set in the cloud corresponds to a submission set in the IHE XDS concept.
  • a document set necessarily has one DocSet Class.
  • the document set class means a class of document set.
  • the document set class is used to specify the input and output types of the filter and is represented by a DocSet Class UID that is unique within the cloud.
  • Workflow manager 2342 manages workflows operating within the cloud.
  • the workflow manager 2342 performs creation, setting, modification, and deletion of the workflow.
  • a specific example of a workflow according to an embodiment of the present invention will be described later with reference to FIG. 4.
  • the patient manager 2343 manages information about the patient.
  • the patient manager 2343 generates, sets, changes, and deletes patient information.
  • a patient means an owner of medical information or health information, and is distinguished from a user, which is another subject using medical information.
  • patients are given different patient numbers for each institution (eg hospital or government).
  • patients may be represented by different patient numbers in multiple groups and may represent the same patient in association with each other.
  • the user manager 2344 manages information about the user.
  • the user manager 2344 generates, sets, changes, and deletes user information.
  • management includes all of creation, modification and deletion of patient information.
  • the user refers to a user who uses a cloud service, and is distinguished from a patient. For example, users are often medical staff such as doctors and nurses, but may also be government officials.
  • One user can belong to zero or more groups. In other words, a user may not belong to a group or may belong to one or more groups. If a user belongs to more than one group, the user may be given group administrator authority. The authority for searching and inquiring the above-described document set may be granted to an individual user.
  • a user according to an embodiment of the present invention may be authenticated through a method of the medical information providing system 200 itself, or may be authenticated through a provider that provides other authentication services.
  • the group manager 2345 manages information about the group.
  • the group manager 2345 generates, sets, changes, and deletes group information.
  • a group means a set of users.
  • the group may mean a group of physical organizations such as a hospital, a department / division, or a virtual set of users.
  • Groups can be organized as independent groups or beneath one parent group.
  • a group can encompass multiple users.
  • a group can grant administrator authority to manage a group to a specific user.
  • the management rights of the group are also inherited by subgroups of the group.
  • an administrator of a specific group can also manage subgroups of the group.
  • the authority to search and search the document set can be indirectly granted through the group to which the user belongs. However, the authority to search and search the document set is valid only for the designated group and is not propagated to the subgroups of the group.
  • the condition manager 2346 manages conditions set on the medical information providing system 200.
  • the condition manager 2346 generates, sets, changes, and deletes conditions.
  • the condition may correspond to a document set condition (DocSet rule) and / or a filter condition (filter rule).
  • the filter condition may be created, set, changed, or deleted by the condition manager 2346, or may be created, set, changed, or deleted by the filter manager.
  • the document set condition refers to a condition used when automatically granting a user the right to search and inquire about a specific document set.
  • the filter condition refers to a condition that the operation of the filter is performed automatically.
  • the filter according to an embodiment of the present invention may include an internal filter 2320 or an external filter 220.
  • the internal filter 2320 refers to a filter that operates inside the cloud.
  • the internal filter 2320 performs an operation inside a database of the cloud.
  • the information on the internal filter 2320 is generated, set, changed, and deleted in the filter manager of the architecture 230.
  • a filter class refers to a class of a filter and expresses an input / output format by a document set class.
  • One filter class may correspond to multiple filters. That is, there may be various filters having the same input / output format and function.
  • Inputs and outputs of filters can be represented by zero or more document set classes.
  • the filter may receive one document set and output one document set, but may receive a plurality of document sets and generate a plurality of output document sets. It is also possible to filter only inputs without inputs or filters without inputs.
  • the internal filter 2320 may be a filter for performing an operation in a database of the cloud, and may be implemented as a stored function of the database of the infrastructure 2310.
  • the external filter 220 refers to a filter that performs work outside the cloud database, and may be implemented using APIs 2350 and 2360 provided by the cloud.
  • a filter represents an instance of a filter and represents an actual instance of a filter represented by a filter class. All filters with the same filter class UID perform substantially the same function.
  • a default group a default patient, and the like may be differently specified.
  • the filter manager can automatically set document groups and document groups generated by the filter through default group designation.
  • the filter manager may automatically set the patient of the document set and documents generated by the filter through the default patient designation.
  • the filter condition means at least one or more conditions required for the operation of the filter, and the filter automatically performs a task when the filter condition is satisfied. If a plurality of document sets are required for one filter to operate, a condition may be set for each document set.
  • a specific date and time that is absolutely specified for example, April 5, 2014 at 3:00 pm
  • the condition is met after 0 o'clock the day after the condition is met (e.g., April 5, 2014, at 3 pm After 5 hours)
  • the filter manager (or condition manager 2346) registers a filter to perform a task and necessary document sets in a filter queue, and specifies a time for the filter to perform the task. If the filter execution time is not specified, the filter performs the task immediately.
  • the filter queue means a waiting queue for the operation of the filter.
  • the contents of the filter queue are processed at a designated time interval (for example, 60 seconds).
  • the external filter 220 processes the contents of the filter queue according to the FilterProc module setting.
  • the filter log means a log related to the processing (operation) of the internal filter 2320.
  • the user interface 2370 refers to a user interface for managing the cloud, searching for information, and searching.
  • the user interface 2370 may be a web based interface.
  • the platform level API 2350 refers to a collection of APIs implemented for a direct interface between the cloud and external devices.
  • the service level API 2360 is a collection of APIs implemented based on the platform level API 2350 for a specific service (for example, service A) among the services 210 provided by the medical information providing system 200. Means.
  • the infrastructure 2310 means an infrastructure for all the cloud services described above to operate.
  • the infrastructure 2310 may correspond to an Amazon Web Services cloud service, but is not limited thereto.
  • the cloud implemented with the architecture 230 described above may generate and provide medical information of an object (eg, a patient) based on an open platform, and thus provide medical information of the object to a user without limitation of time and space. can do.
  • an object eg, a patient
  • the cloud implemented with the architecture 230 described above may generate and provide medical information of an object (eg, a patient) based on an open platform, and thus provide medical information of the object to a user without limitation of time and space. can do.
  • FIG. 3 is a flowchart illustrating an example in which the medical information providing system according to an embodiment of the present invention operates.
  • an example in which the medical information providing system operates includes the steps of time-series processing in the medical information providing system 100 or 200 or the cloud 110 illustrated in FIGS. 1 and 2. Therefore, even if omitted below, the information described above with respect to the medical information providing system or cloud 110 shown in FIGS. 1 and 2 may be applied to an example in which the medical information providing system of FIG. 3 operates. Can be.
  • the performing agent of each step illustrated in FIG. 3 is described as 'cloud 110'.
  • the subject of performing the steps illustrated in FIG. 3 may be any one of the components included in the architecture 230 illustrated in FIG. 2. .
  • step 310 the cloud 110 generates and sets group information.
  • the cloud 110 creates a group (hereinafter, referred to as a master group) representing an institution to establish a service based on an external signal input from a user.
  • a master group representing an institution to establish a service based on an external signal input from a user.
  • institutions such as actual hospitals can be created.
  • the cloud 110 may create a group as shown in Table 3 below.
  • the cloud 110 creates a radionet master group (Radionet), and actual medical institutions such as Seoul National University Hospital (SNUH), Democratic Hospital (CMC), and Guro Clinic are radionet master groups. You can create it as a child group below.
  • the cloud 110 may organize actual medical institutions into groups, and then register the departments as another child group (Radiology, Cardiology) within the medical institution.
  • Table 4 An example of a database table structure for storing group information is shown in Table 4 below.
  • Group Id ID of the group, and assigning_authority_id which is one of three elements constituting the patient number, is set to Group Id.
  • the ISO OID may be used, but is not limited thereto. For example, if a medical institution code is given in the form of 82999, this means hospital No. 999 in Korea 82.
  • Group Id Type It means the type of ID of group, and assigning_authority_id_type, which is one of three elements constituting patient number, is set as Group Id Type. If the group ID is registered in ISO OID format, ISO must be specified. Otherwise, it can be used by itself. For example, Group Id Type can be set as “BIS-CLOUD”.
  • Group name Means the name of a group that people can recognize. For example, it may be set as an official name of a medical institution.
  • Group type It means the item to indicate the type of group. For example, it can be set to “HOSPITAL” in the case of a hospital and “CLINIC” in the case of a doctor.
  • Parent group Means parent group.
  • step 320 the cloud 110 generates and sets user information.
  • the cloud 110 creates a user (hereinafter referred to as a master manager) to manage the master group based on an external signal input from the user. In addition, the cloud 110 grants the master manager the management right for the master group.
  • a master manager a user has a management right for a group (that is, a group manager)
  • a subgroup of the group may be managed.
  • having a master manager have control over a master group means that the master manager can create multiple groups under the master group. Only group administrators can add users or patients to the group and its child groups.
  • Radionet bioadmin Group SNUH bioadmin , snuhadmin Group: Radiology bioadmin , snuhadmin , snuhradioadmin Group: CMC bioadmin , cmcadmin Group: Cardiology bioadmin , cmcadmin Group: GuroClinic bioadmin , gurocadmin
  • the master manager bioadmin can manage both Radionet groups and child groups.
  • group administrator snuhadmin can manage the SNUH group and its child group, the Radiology group. If a separate administrator is needed for the Radiology group, a group administrator named snuhradioadmin may be additionally designated as shown in Table 6 above.
  • a user may belong to several groups. At this time, if a user belongs to a specific group and is given administrative rights, the user becomes an administrator for the group, otherwise, the user becomes a general user. After the group manager is created, the cloud 110 creates as many general users as necessary and associates them with the group.
  • inquiry right is not inherited.
  • the group manager snuhadmin can manage the SNUH group and the Radiology group, but cannot query the documents of the Radiology group.
  • snuhadmin In order for the user snuhadmin to view documents in the Radiology Group, snuhadmin must also belong to the Radiology Group.
  • a user can have multiple authentication methods. For example, the user may log in through self-authentication of the medical information providing system, or may log in through another authentication account (eg, a Google account).
  • another authentication account eg, a Google account.
  • Table 8 An example of the database table structure for setting a relationship between a group and a user is shown in Table 8 below.
  • step 330 the cloud 110 generates and sets patient information.
  • the cloud 110 may generate and set patient information based on an external signal input from a user.
  • the patient may have attributes such as patient number, name, gender, date of birth, and the like.
  • the patient number is composed of three parts such as (patient_id_value, assigning_authority_id, assigning_authority_id_type).
  • assigning_authority_id and assigning_authority_id_type correspond to Group Id and Group Id Type of a group
  • patient_id_value indicates a patient number in the corresponding group. Therefore, in the medical information providing system according to an embodiment of the present invention, the patient necessarily belongs to only one group.
  • Patient_id_value which is the first of three parts of the patient number.
  • Patient Name It means the patient's name. For example, it may be input in the HL7 manner (Last name ⁇ First name ⁇ Middle name ⁇ Suffix ⁇ Prefix).
  • Patient birthdate It means the date of birth of the patient.
  • the medical information providing system creates a patient for each medical institution.
  • the patient attribute in the medical information providing system has a property called Related Patient, and may be connected to other patient information.
  • the cloud 110 may find and connect information about the same patient dispersed in each medical institution by using the Related Patient attribute.
  • step 340 the cloud 110 designs the workflow based on an external signal input from the manager of the cloud 110.
  • Workflows represent the flow of at least one filter of a medical information providing system to perform a task.
  • the medical information system according to an embodiment of the present invention generates medical information of an object (eg, a patient) according to a workflow and provides the same to a user.
  • an example of a workflow will be described with reference to FIG. 4.
  • FIG. 4 is a diagram illustrating an example of a workflow 400 according to an embodiment of the present invention.
  • FIG. 4 illustrates an example of a workflow 400 designed by the cloud 110. 4 is only shown for convenience of description, and the workflow 400 designed by the cloud 110 is not limited to that shown in FIG. 4. In other words, any workflow that can generate medical information of an object (eg, a patient) by using at least one filter set or at least one filter belonging to a single filter set, and provide the same to a user may be provided. It can fall in the range of.
  • an object eg, a patient
  • a portion shown in a circle means a document set class (DSC). At least one document may be included in one document set. Therefore, although each document prototype class is described in each of the prototypes of FIG. 4, it can be easily understood by those skilled in the art that other documents belonging to the document set may also be applicable. A detailed description of the document set class, the document set, and the document is the same as described above with reference to FIG. 2, and will be omitted below.
  • the portion illustrated in a rectangle means a filter class FC and a filter FU included in the filter class.
  • One filter class may include at least one filter. Therefore, although each specific filter class and filter are described in each of the quadrangular shapes of FIG. 4, it may be easily understood by those skilled in the art that other filters included in the filter class may also be applicable. Detailed descriptions of the filter class and the filter are the same as described above with reference to FIG.
  • Filter 4.1 410 an instance of filter class 3.1, generates one or more of four kinds of document sets: EKG 411, Holter 412, Event Recorder 413, and DICOM 414.
  • the filter 4.1 410 may be an external filter for generating a document set, or may be an internal filter for generating a document set by using a signal received from an external device.
  • the EKG document set 411, represented by document set class 5.1, may be stored in the data store 2330.
  • Filter 4.2.1 (420), an instance of filter class 3.2.1, receives a Holter document set (document set class 5.2) 412 and outputs a CDSS result report document set (document set class 5.2.1) 421. do.
  • Filter 4.2.2 (450), which is an instance of filter class 3.2.2, integrates the original Holter document set (412) and the CDSS result report document set (421) to create a new document set (document set class 5.2.2) (451). Create The generated document set 451 may be stored in the data store 2330.
  • Filter 4.2 430 which is an instance of filter class 3.2, incorporates an Event Recorder document set 413, represented by document set class 5.3.
  • Filter 4.4.1 440 which is an instance of filter class 3.4.1, provides an external device with a DICOM document set 414, represented by document set class 5.4.
  • the external device displays the DICOM document set 414 on the screen.
  • the displayed document set 441 may be identified by the cloud 110.
  • the cloud 110 sets a document set class.
  • the cloud 110 sets a document set class necessary to operate the workflow 400 designed in step 340.
  • the cloud 110 assigns a UID to each document set and filter, and sets it in the medical information providing system.
  • the filter class 3.1 410 and the document set class 5.1 411 illustrated in FIG. 4 may be expressed as UIDs such as 1.2.410.200054.3.1 and 1.2.410.200054.5.1, respectively.
  • the setting of the document set class is completed by specifying the UID and the name of the document set class.
  • DocSet Class UID Refers to the UID of the document set class. Each document class is assigned a unique UID.
  • DocSet Class Type Refers to the type of document set class and is used for reference only.
  • DocSet Class Name Represents the name of a document set class.
  • step 360 the cloud 110 sets a filter class.
  • the cloud 110 sets a filter class necessary for the workflow 400 designed in step 340 to operate.
  • the cloud 110 needs some additional attributes as follows to set the filter class.
  • Filter Class UID Each filter class is given a unique UID as the UID of the filter class.
  • Filter Class Type This indicates the type of filter class, indicating whether it is an internal filter (I) or an external filter (E).
  • Filter Proc Name The name of a database procedure, set only in an internal filter. Filter Proc Args Set only in internal filters, which are arguments to database procedures.
  • DocSet Type Indicates whether the specified document set is an input (I) or output (O) of the filter.
  • DocSet Class UID Specifies the input or output document set of the filter.
  • the cloud 110 sets an input document set and an output document set that each filter class can process.
  • the cloud 110 may set a filter class as shown in Table 16 below.
  • step 370 the cloud 110 sets a filter.
  • the cloud 110 sets a filter necessary to operate the workflow 400 designed in step 340.
  • Filter UID Represents a filter's UID, which is unique for each filter.
  • Filter Class UID Sets the filter class UID to indicate the type of filter.
  • Filter name The filter name.
  • Filter Proc Args Override the arguments of the database procedure used by the internal filter.
  • Default Group A group that is set automatically when there is no group information in the document set processed by the filter.
  • Default Patient The patient is automatically set when there is no patient information in the document set processed by the filter.
  • the cloud 110 may set a filter as shown in Table 19 below.
  • step 380 the cloud 110 sets filter conditions.
  • the filter condition consists of i) setting part for the filter to be performed and ii) setting part of the input condition for the filter to perform the work.
  • Table 21 property Explanation Filter Rule Name Name of the filter rule. Filter Select the filter to be performed.
  • Scheduled Time Specifies the absolute time the filter will run, at which time the filter will do its job. Absolute time specification takes precedence over relative time specification below.
  • Scheduled Delay Specify the relative time at which the filter is to be performed, in which case the filter is performed after the specified time from the current time in a) mode, or at the specified time after 0 o'clock tomorrow in mode b. If the month 5 is 18:00 and the Scheduled Delay property is 3:00, a) In mode, the filter is performed on February 5, 2014 21:00. b) In mode, the filter is performed at 3:00 February 6, 2014.
  • Table 23 property Explanation Filter rule Select the filter condition.
  • DocSet Class UID Set which document set should be prepared for the filter to be performed.
  • Filter Set which filter should be the above document set.
  • Group Set which group the above document set should belong to.
  • Patient Set which patient should be the above document set.
  • workflow settings are only required for Holter document 412 and DICOM document 414. This may be implemented by setting the cloud 110 as shown in Table 24 below.
  • the FilterRule_apply () function is called automatically.
  • the cloud 110 searches for a filter condition to search whether there is a filter to be applied to the newly generated document set, and records the result in the filter queue. If the input condition of the filter condition is composed of only one document set, the filter condition is applied as soon as the corresponding document set satisfying the condition is generated. However, if the input condition of the filter condition is composed of several document sets (that is, a filter that needs to process several document sets at once), the filter condition is applied when all the document sets necessary to perform the filter are ready. do.
  • Filter Rule “HolterExport rule” is the filter 1.2.410.200054.4.2.1 is executed immediately when the document set for document set class 1.2.410.200054.5.2 is prepared.
  • the filter rule “Merger rule” performs filter 1.2.410.200054.5.2.2 when all document sets for document set classes 1.2.410.200054.5.2 and 1.2.410.200054.5.2.1 are prepared.
  • a filter queue is created.
  • the filter queue is created as a result of applying the filter condition, not setting, and stores information about the filter to be performed and the result of performing the filter.
  • the filter queue consists of i) a section for storing information about the filter to be performed and ii) a section for storing information about the document set to be input to the filter.
  • Table 26 property Explanation Filter Queue UUID UUID for the filter queue, which is used to process filter operations in an XDS manner. Filter Specifies the filter to be performed. Filter Result Text The result of the filter is shown. Filter Result Code Shows the result code of the filter. Scheduled Time Indicate the time the filter will be performed. Performed Time Indicates the time the filter was performed.
  • the filter when information on a filter to be performed is stored in the filter queue, the filter performs the operation according to the type of the filter as follows.
  • An internal filter performs a job by a job manager of a database.
  • the database task manager periodically calls the FilterQueue_execute () function, which finds an internal filter in the contents of the filter queue and causes the database task manager to perform the task at the time the filter should perform the task.
  • the external filter works by FilterProc.
  • the FilterProc program refers to an interface module for implementing an external filter.
  • an external filter will be described in detail with reference to FIG. 6.
  • FIG. 5 is a view for explaining an example of the external filter 541 according to an embodiment of the present invention.
  • a cloud 510 and external devices 520, 530, and 540 connected to the cloud 510 are illustrated.
  • the cloud 510 and the external devices 520, 530, and 540 may be connected to each other by wire or wireless communication.
  • the cloud 510 and the external devices 520, 530, and 540 may be connected through an IHE XDS or MHD standard protocol, but are not limited thereto.
  • An example of a communication protocol to which the cloud 510 is connected to the external devices 520, 530, and 540 will be described later with reference to FIG. 6.
  • each of the external devices 520, 530, and 540 may correspond to a medical device, a PC, or a mobile terminal for acquiring diagnostic information about a patient, but is not limited thereto.
  • the external filter 541 may be included in at least one of the external devices 520, 530, and 540.
  • the external filter 541 and the cloud 510 may transmit and receive a job through the FilterProc program.
  • the FilterProc program retrieves the filter tasks to be processed by using the designated Filter UID, downloads the input document sets, performs the filter processing, and then uploads the generated result documents in the form of new document sets and uploads them again. Do it.
  • the setting of the FilterProc program will be described later with reference to FIG. 6.
  • FIG. 6 is a view for explaining an example of a communication protocol used in the medical information providing system according to an embodiment of the present invention.
  • programs 620 and 630 installed in each of the cloud 610 and external devices included in the medical information providing system 600 is illustrated.
  • the programs 620 and 630 may be any program, without limitation, as long as the program can be connected to the cloud 610 through wired or wireless communication.
  • the BioPump 620 and the cloud 610 which transmits the biosignal information 621 to the cloud 610, are integrated with the Healthcare Enterprise (IHE) Cross-Enterprise Document Sharing (XDS) or Mobile-HDHD. communication using the access to Health Document protocol.
  • IHE Healthcare Enterprise
  • XDS Cross-Enterprise Document Sharing
  • MHD MHD Put Document Dossier protocol
  • an IHE MHD protocol specialized for a mobile environment may be used.
  • the MHD protocol means a simplified version of the XDS protocol to fit the mobile environment.
  • the protocol used between cloud 610 and external filters 650 and 660 may also be the IHE XDS protocol.
  • the cloud 610 and the external filters 650 and 660 may communicate using XDS Registry Stored Query, XDS Retrieve Document Set, and XDS Provide and Register Document Set protocols.
  • Medical information providing system 600 may use a universal communication standard protocol. Therefore, if the standard protocol used in the medical information providing system 600 is implemented, any API can be linked with the cloud 610.
  • Table 30 XDS / MHD submission Set Key Explanation entryUUID UUID of the document set, which must be completely unique throughout. The symbolic name may be used instead of the UUID for the first transmission.
  • contentTypeCode Code that represents the contents of a document set, which internally corresponds to the Document Set Class UID.
  • patientId Patient number is displayed.
  • sourceId Represents the source that generated the document set, which internally corresponds to the Filter UID.
  • submissionTime Indicates the date and time when the document set was sent. title The title of the document set. uniqueId UID of the document set, must be unique within the group.
  • IHE XDS / MHD standard Document Entry, submission Set, Folder, Association object are used to implement document, document set, folder, etc. and express relationship.
  • An example of a database table structure for storing the objects in the cloud 610 is shown in Tables 31 to 36 below.
  • the external filter (650, 660) performs a task through a total of five steps. Five steps that the external filters 650 and 660 undergo while performing the operation are as follows.
  • a job to be performed in the external filters 650 and 660 is generated. Specifically, when a filter operation is required by the filter condition, the cloud 610 generates FilterQueue UUID and FilterQueueInput UUID in the filter queue (that is, the tables described in Tables 25 and 27), respectively.
  • a job to be performed in the external filters 650 and 660 is searched for.
  • the search for the work to be performed in the external filters 650 and 660 may be implemented by extending the XDS Registry Stored Query method.
  • a stored query called FindFilterJobs may return a filter job in the form of an association list as shown in Table 41 below.
  • a work list to be performed in the external filters 650 and 660 is prepared.
  • the Association list for retrieved filter jobs composes a FilterJob list in FilterProc as shown in Table 42 below.
  • the FilterProc program refers to an interface module for implementing the external filters 650 and 660.
  • FilterProc is required for the implementation of external filters 650 and 660 operating on the medical information providing system, and specifies a processing method for a specific filter / document set.
  • FilterProc connects to the cloud using the specified server and port information and performs the specified operation according to the contents stored in the configuration file.
  • query file is specified other than the configuration file, it is specified to act as a filter specified in the filterUID of the configuration file. If there is additionally specified query file, filter processing is performed based on the contents specified in the query file.
  • OFF ERROR WARN INFO (default) DEBUG serverHost Address of an XDS / MHD server in the cloud.
  • workingDir Specify a working directory. filenameFormat You can use the following keywords to specify the file name of the documents to download. % uid: replaced by the document's UID. % dttm: replaced with the date of creation of the document. % seq: replaced with an automatically assigned serial number. retrieveSetCount Shows the size of the bundle when downloading the document. Larger will reduce HTTP overhead, but too large can cause the download itself to fail due to exceeding buffer capacity.
  • the default value is 1. preprocessor After downloading all the document sets, you can specify when preprocessing is needed. You can use the following keywords: % inDocSetDir: Replaced with the folder name of the input document set. % inDocSetPathList: Replaced with the full pathname list of all document files contained in the input document set. % inDocSetFileList: Replaced with a list of filenames of all documents in the input document set. % outDocSetDir: Replaced with the folder name of the output document set. processor By specifying the path name and arguments of the external processor to be called for the document or document set, the following keywords can be used in addition to the keywords specified in the preprocessor above.
  • % inDocFile Replaced with the filename of the individual input document.
  • % inJobDir If more than one input document set is needed for the filter processing, it is replaced with the name of the entire working folder.
  • % inJobPathList Replaced with the full pathname list of all input document files contained in the job folder.
  • % inJobFileList Replaced with a list of filenames of all input documents contained in the job folder.
  • % outDocFile Replaced with the name of an individual output document file.
  • % outJobDir Replaced with the name of the output job folder.
  • filterUID Specifies the filter's UID.
  • groupIdType It represents the Group Id Type.
  • BIS-Cloud should use “BIS-CLOUD” unless there is a specific reason.
  • docsetClassUID The class UID value for generated document sets. docsetTitle This is the default title for generated document sets. docsetComments Basic description of the document sets created. mimeType MIME type required to upload the generated document. rename Specifies whether to move or delete the documents used in the job. True to move, false to delete. The default value is false (delete). repeat Specifies whether to repeat. The default value is false (no repetition). repeatInterval Specifies the repeat period. For example, it may be designated as 300 (seconds).
  • FilterProc creates a working folder with the structure shown in Table 47 under the folder designated as workingDir. FilterProc can specify that the contents of the working folder will be deleted later.
  • the external filters 650 and 660 transmit the result of performing the work to the cloud 610.
  • the external filters 650 and 660 transmit the association information as shown in Table 45 below before transmitting the document set that is the result of the work to the cloud 610.
  • the HolterCDSS 650 is one of the external filters implemented in the cloud 610, and uses the HolterExport.exe or Holter.exe program to perform a CDSS (Clinical Decision Supporting System) process after downloading a Radionet Holter file from the cloud 610. To perform.
  • the HolterCDSS 650 uploads the automatic diagnosis result files in the JPEG form generated as a result of the execution of the program to the cloud 650 again.
  • HolterCDSS 650 is a batch file created based on FilterProc. Specifically, the HolterCDSS 650 is composed of a FilterProc.jar module for communicating with the cloud and a HolterExport.exe or Holter.exe module for actual CDSS processing. .
  • EventMerge 660 is one of the external filters implemented for the cloud 610, downloads the Event Recorder signal files stored in the cloud 610, integrates, converts them and delivers them to the Holter.exe program as input.
  • EventMerge 660 is a batch file created based on FilterProc. Specifically, EventBuild.jar, a preprocessor for integrating Event Recorder signal files, and Holter.exe, which processes actual Holter information. Consists of.
  • queryType should be specified as GetSubmissionSetAndContents
  • docsetUID should specify the UID of the document set containing the Event Recorder files to be integrated.
  • FIG. 7 is a diagram illustrating an example of an apparatus 700 for generating information about a filter according to an embodiment of the present invention.
  • an apparatus 700 for generating information about a filter includes a filter class setting unit 710, a filter setting unit 720, and a filter condition setting unit 730. Only the components related to the present embodiment are shown in the apparatus 700 shown in FIG. Therefore, it will be understood by those skilled in the art that other general purpose components may be further included in addition to the components illustrated in FIG. 7.
  • the filter class setting unit 710, the filter setting unit 720, and the filter condition setting unit 730 of the apparatus 700 illustrated in FIG. 7 may correspond to one or a plurality of processors.
  • the processor may be implemented as an array of multiple logic gates, or may be implemented as a combination of a general purpose microprocessor and a memory storing a program that may be executed on the microprocessor.
  • the present embodiment may be implemented in other forms of hardware.
  • the apparatus 700 illustrated in FIG. 7 may be included in the medical information providing system or the cloud illustrated in FIGS. 1, 2, 5, and 6. Therefore, even if omitted below, it can be seen that the above description of the medical information providing system or cloud shown in FIGS. 1, 2, 5, and 6 also applies to the apparatus 700 of FIG. 7. .
  • the filter class setting unit 710 sets at least one filter class corresponding to a task for generating medical information of the object.
  • the subject may mean a patient, but is not limited thereto.
  • the filter class refers to the class of the filter and represents the input / output format by the document set class.
  • One filter class may correspond to multiple filters. That is, various filters having the same input / output format and functions may exist.
  • the filter setting unit 720 is included in the filter class and sets at least one filter for performing a task.
  • the type of filter includes an internal filter or an external filter.
  • the internal filter refers to a filter that performs work in a database of the cloud, and may be implemented as a stored function of a database of an infrastructure.
  • the external filter refers to a filter that performs work outside the cloud database, and may be implemented using an API provided by the cloud.
  • a filter represents an instance of a filter and represents an actual instance of a filter represented by a filter class. All filters with the same filter class UID perform substantially the same function.
  • the operation performed by the filter corresponds to any one of converting at least one or more input contents into at least one or more output contents, storing the contents, providing the contents to another device, and generating the contents.
  • another device provided with the content refers to a device that consumes the content in various ways, such as a device displaying the provided content.
  • Content refers to all kinds of documents including text, images, and video.
  • the content includes all kinds of documents that can be processed in common computing devices such as images, waveforms, measured values.
  • content is expressed in the same concept as a document.
  • the condition setting unit 730 sets at least one condition required for the operation of the filter.
  • the condition setting unit 730 sets a filter to perform an operation, and sets a time condition corresponding to information required for the operation of the filter and / or a time point at which the filter performs the operation.
  • the time condition is based on the condition under which the filter performs an operation when information is input to the filter, the condition under which the filter performs an operation after a predetermined time has elapsed after the information is input, and the next hour at 0 o'clock when the information is input. For example, when a predetermined time has elapsed, any one of the conditions under which the filter performs an operation may correspond.
  • FIG. 8 is a flowchart illustrating an example of a method of generating information about a filter according to an embodiment of the present invention.
  • the method for generating information on a filter includes an apparatus 700 for generating information on a medical information providing system, a cloud, or a filter illustrated in FIGS. 1, 2, 5, 6, and 7. Consists of steps processed in time series. Therefore, even if omitted below, the contents described above with reference to FIGS. 1, 2, 5, 6, and 7 may also be applied to the method for generating information on the filter of FIG. 8.
  • the cloud sets at least one filter class corresponding to a task for generating medical information of the object.
  • step 820 the cloud is included in the filter class and sets at least one filter to perform a task.
  • step 830 the cloud sets at least one condition required for the operation of the filter.
  • FIG. 9 is a block diagram illustrating an example of an apparatus for generating medical information of an object according to an embodiment of the present invention.
  • the apparatus 900 for generating medical information of an object includes an interface unit 910, a filter selector 920, and a plurality of internal filters 931, 932, and 933.
  • at least one of the filters may be present as an external filter 934 not included in the device 900.
  • the device 900 shown in FIG. 9 only components related to the present embodiment are shown. Therefore, it will be understood by those of ordinary skill in the art that other general-purpose components may be further included in addition to the components illustrated in FIG. 9.
  • the interface unit 910 and the filter selector 920 included in the apparatus 900 illustrated in FIG. 9 may correspond to one or a plurality of processors.
  • the processor may be implemented as an array of multiple logic gates, or may be implemented as a combination of a general purpose microprocessor and a memory storing a program that may be executed on the microprocessor.
  • the present embodiment may be implemented in other forms of hardware.
  • the apparatus 900 illustrated in FIG. 9 may be included in the medical information providing system or cloud shown in FIGS. 1, 2, 5, and 6. Therefore, even if omitted below, it can be seen that the above description of the medical information providing system or cloud shown in FIGS. 1, 2, 5, and 6 also applies to the apparatus 900 of FIG. 7. .
  • the interface unit 910 receives at least one or more contents from at least one of the external devices connected to the cloud.
  • the content refers to all kinds of documents including text, images, and videos.
  • the content includes all kinds of documents that can be processed in common computing devices such as images, waveforms, measured values.
  • content is expressed in the same concept as a document.
  • the filter selector 920 selects a filter that performs a preset task based on the content received by the interface unit 910 from among the filters included in each of the plurality of filter classes.
  • the filter class refers to the class of the filter, and represents the input and output format by the document set class.
  • One filter class may correspond to multiple filters. That is, various filters having the same input / output format and functions may exist.
  • the type of filter includes an internal filter or an external filter.
  • the internal filter refers to a filter that performs work in a database of the cloud, and may be implemented as a stored function of a database of an infrastructure.
  • the external filter refers to a filter that performs work outside the cloud database, and may be implemented using an API provided by the cloud.
  • the preset operation performed by the filter selected by the filter selector 920 may include converting input content into output content, providing a content to at least one of the devices connected to the cloud, and combining two different contents. This means any one of generating a new content and storing a content.
  • the device provided with the content refers to a device that consumes the content in various ways, such as a device displaying the provided content.
  • the filter selector 920 may select a filter for performing a task based on a result of performing a preset task among the filters included in each of the plurality of filter classes. In other words, as in the workflow described above with reference to FIG. 4, the filter selector 920 may select another filter that performs another task using the result of the operation performed by one filter.
  • each of the internal filters 931, 932, 933 and the external filters 934 is set to a time condition corresponding to the information required for the operation of the filter and / or the time when the filter performs the operation.
  • the time condition is based on the condition under which the filter performs an operation when information is input to the filter, the condition under which the filter performs an operation after a predetermined time has elapsed after the information is input, and the next hour at 0 o'clock when the information is input. For example, when a predetermined time has elapsed, any one of the conditions under which the filter performs an operation may correspond.
  • FIG. 10 is a flowchart illustrating an example of a method of generating medical information of an object according to an exemplary embodiment.
  • a method of generating information about a filter includes a medical information providing system, a cloud, or an apparatus 900 for generating medical information of an object illustrated in FIGS. 1, 2, 5, 6, and 9. Consists of steps processed in time series. Therefore, even if omitted below, the contents described above with reference to FIGS. 1, 2, 5, 6, and 9 may be applied to the method of generating medical information of the object of FIG. 10.
  • the cloud receives at least one or more contents from at least one of the external devices connected to the cloud.
  • step 1020 the cloud selects a filter that performs an operation based on the received content among the filters included in each of the plurality of filter classes.
  • step 1030 the selected filter performs a preset task.
  • the above-described method can be written as a program that can be executed in a computer, it can be implemented in a general-purpose digital computer to operate the program using a computer-readable recording medium.
  • the structure of the data used in the above-described method can be recorded on the computer-readable recording medium through various means.
  • the computer-readable recording medium may include a storage medium such as a magnetic storage medium (eg, ROM, RAM, USB, floppy disk, hard disk, etc.), an optical reading medium (eg, CD-ROM, DVD, etc.). do.

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (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)

Abstract

필터에 대한 정보를 생성하는 방법은 대상체의 의료 정보를 생성하기 위한 작업에 대응하는 적어도 하나 이상의 필터 클래스를 설정하는 단계; 상기 필터 클래스에 포함되고, 상기 작업을 수행하는 적어도 하나 이상의 필터를 설정하는 단계; 및 상기 필터의 동작에 요구되는 적어도 하나 이상의 조건을 설정하는 단계;를 포함한다. 대상체의 의료 정보를 생성하는 방법은 클라우드와 연결된 외부 장치들 중 적어도 어느 하나로부터 적어도 하나 이상의 제 1 컨텐츠를 수신하는 단계; 복수의 필터 클래스들 각각에 포함된 필터들 중에서 상기 제 1 컨텐츠에 기반하여 작업을 수행하는 제 1 필터를 선택하는 단계; 및 상기 제 1 필터에 의하여 기 설정된 작업을 수행하는 단계;를 포함한다.

Description

대상체의 의료 정보를 생성하는 방법 및 장치
대상체의 의료 정보를 생성하는 방법 및 장치에 관한다. 보다 구체적으로, 기 설정된 작업을 수행함으로써 대상체의 의료 정보를 생성하는 필터를 형성하는 방법 및 장치에 관한다. 또한, 기 설정된 작업을 수행하는 적어도 하나 이상의 필터로 설계한 워크플로우를 이용하여 대상체의 의료 정보를 생성하는 방법 및 장치에 관한다.
클라우드 컴퓨팅(Cloud Computing)은 인터넷 또는 네트워크를 기반으로 하는 컴퓨팅 환경을 말한다. 인터넷 상에 존재하는 데이터 서버에 프로그램 인프라를 구축하고, 사용자가 이용하고자 할 때 컴퓨터, 휴대폰 등을 통해 데이터 서버에 저장된 프로그램들을 이용할 수 있도록 한다. 다시 말하면, 구름(Cloud)과 같이 무형의 형태로 존재하는 하드웨어 및/또는 소프트웨어 등의 컴퓨팅 자원을 사용자가 컴퓨터, 휴대폰과 같은 단말기(Terminal 또는 Client)를 통해 이용할 수 있다.
한편, 의학 기술 및 통신 기술이 발달함에 따라, 근래에는 의료 산업과 통신 산업을 융합하려는 시도가 활발히 진행되고 있다. 특히, 대상체(예를 들어, 환자)의 진단 결과를 가공함으로써 원하는 유형의 의료 정보를 생성하고, 이를 격지자 간에 공유할 수 있는 기술에 대한 연구가 진행되고 있다.
대상체의 의료 정보를 생성하는 방법 및 장치를 개시한다. 또한, 상기 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체를 제공하는 데 있다. 해결하려는 기술적 과제는 상기된 바와 같은 기술적 과제들로 한정되지 않으며, 또 다른 기술적 과제들이 존재할 수 있다.
일 측면에 따른 필터에 대한 정보를 생성하는 방법은 대상체의 의료 정보를 생성하기 위한 작업에 대응하는 적어도 하나 이상의 필터 클래스를 설정하는 단계; 상기 필터 클래스에 포함되고, 상기 작업을 수행하는 적어도 하나 이상의 필터를 설정하는 단계; 및 상기 필터의 동작에 요구되는 적어도 하나 이상의 조건을 설정하는 단계;를 포함한다.
다른 측면에 따른 컴퓨터로 읽을 수 있는 기록매체는 상술한 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 기록매체를 포함한다.
또 다른 측면에 따른 필터에 대한 정보를 생성하는 장치는 대상체의 의료 정보를 생성하기 위한 작업에 대응하는 적어도 하나 이상의 필터 클래스를 설정하는 필터 클래스 설정부; 상기 필터 클래스에 포함되고, 상기 작업을 수행하는 적어도 하나 이상의 필터를 설정하는 필터 설정부; 및 상기 필터의 동작에 요구되는 적어도 하나 이상의 조건을 설정하는 필터 조건 설정부;를 포함한다.
또 다른 측면에 따른 대상체의 의료 정보를 생성하는 방법은 클라우드와 연결된 외부 장치들 중 적어도 어느 하나로부터 적어도 하나 이상의 제 1 컨텐츠를 수신하는 단계; 복수의 필터 클래스들 각각에 포함된 필터들 중에서 상기 제 1 컨텐츠에 기반하여 작업을 수행하는 제 1 필터를 선택하는 단계; 및 상기 제 1 필터에 의하여 기 설정된 작업을 수행하는 단계;를 포함한다.
또 다른 측면에 따른 컴퓨터로 읽을 수 있는 기록매체는 상술한 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 기록매체를 포함한다.
또 다른 측면에 따른 대상체의 의료 정보를 생성하는 클라우드 시스템에 포함된 장치는 상기 클라우드와 연결된 외부 장치들 중 적어도 어느 하나로부터 적어도 하나 이상의 제 1 컨텐츠를 수신하는 인터페이스부; 및 복수의 필터 클래스들 각각에 포함된 필터들 중에서 상기 제 1 컨텐츠에 기반하여 기 설정된 작업을 수행하는 제 1 필터를 선택하는 필터 선택부;를 포함한다.
상술한 바에 따르면, 기 설정된 동작을 수행하는 필터를 형성함으로써 사용자의 개입 없이 대상체의 의료 정보를 생성할 수 있다. 또한, 개방형 플랫폼에 기반하여 대상체의 의료 정보를 생성하고 제공할 수 있는바, 시간 및 공간의 제약 없이 대상체의 의료 정보를 제공할 수 있다. 또한, 기 설정된 동작을 수행하는 적어도 하나 이상의 필터를 이용하여 워크플로우를 설계함으로써 사용자의 개입 없이 대상체의 의료 정보를 생성할 수 있다.
도 1은 본 발명의 일 실시예에 따른 의료 정보 제공 시스템의 일 예를 도시한 개념도이다.
도 2는 본 발명의 일 실시예에 따른 의료 정보 제공 시스템의 일 예를 설명하기 위한 구성도이다.
도 3은 본 발명의 일 실시예에 따른 의료 정보 제공 시스템이 동작하는 일 예를 설명하기 위한 흐름도이다.
도 4는 본 발명의 일 실시예에 따른 워크플로우의 일 예를 도시한 도면이다.
도 5는 본 발명의 일 실시예에 따른 외부 필터의 일 예를 설명하기 위한 도면이다.
도 6은 본 발명의 일 실시예에 따른 의료 정보 제공 시스템에서 사용되는 통신 프로토콜의 일 예를 설명하기 위한 도면이다.
도 7은 본 발명의 일 실시예에 따른 필터에 대한 정보를 생성하는 장치의 일 예를 도시한 구성도이다.
도 8은 본 발명의 일 실시예에 따른 필터에 대한 정보를 생성하는 방법의 일 예를 도시한 흐름도이다.
도 9는 본 발명의 일 실시예에 따른 대상체의 의료 정보를 생성하는 장치의 일 예를 나타내는 구성도이다.
도 10은 본 발명의 일 실시예에 따른 대상체의 의료 정보를 생성하는 방법의 일 예를 나타내는 흐름도이다.
이하에서는 도면을 참조하여 본 발명의 실시예들을 상세히 설명한다. 본 발명의 하기 실시예는 본 발명을 구체화하기 위한 것일 뿐 본 발명의 권리 범위를 제한하거나 한정하지 않는다. 또한, 본 발명의 상세한 설명 및 실시예로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 용이하게 유추할 수 있는 것은 본 발명의 권리범위에 속하는 것으로 해석된다.
도 1은 본 발명의 일 실시예에 따른 의료 정보 제공 시스템(100)의 일 예를 도시한 개념도이다.
도 1을 참조하면 의료 정보 제공 시스템(100)은 클라우드(110) 및 사용자(130)를 포함한다. 도 1에서는 설명의 편의를 위하여 사용자(130)를 도시하였으나, 여기에서 사용자(130)는 사용자(130)가 이용하는 장치로서 클라우드(110)에 접속이 가능한 외부 장치를 포함하는 개념이다. 또한, 클라우드(110)는 하나 이상의 외부 장치가 유무선 통신을 통하여 접속할 수 있는 소정의 서버로 구현될 수 있다.
본 발명의 일 실시예에 따른 의료 정보 제공 시스템(100)은 클라우드(110)에 기반하여 대상체의 의료 정보를 형성하고, 이를 사용자(130)에게 제공하는 시스템을 의미한다. 여기에서, 대상체는 진단이 요구되는 환자(patient)가 해당될 수 있으나, 이에 제한되지 않는다.
구체적으로, 의료 정보 제공 시스템(100)은 개방형 플랫폼에 기반하여 대상체의 의료 정보를 형성하고 이를 사용자(130)에게 제공할 수 있다. 예를 들어, 의료 정보 제공 시스템(100)은 IHE, DICOM, HL7과 같은 의료정보 표준 및 W3C, ISO와 같은 국제표준에 근거하여 의료정보를 검색, 저장, 전송, 조회, 교환하는 등의 다양한 서비스(120)를 제공하는 플랫폼을 포함한다.
예를 들어, 의료 정보 제공 시스템(100)이 제공하는 서비스(120)에는 의료 정보의 제공 또는 가공 서비스, 원격 진료(tele-medicine) 서비스, 의료 결정 지원 시스템(clinical decision supporting system) 서비스, 의료 정보의 저장 또는 공유 서비스, 서버 사이드 컴퓨팅(server-side computing) 서비스, 소셜 네트워킹(social networking) 서비스 등을 포함할 수 있다. 그러나, 상술한 서비스들에 한정되지 않고, 의료 정보를 이용하여 사용자가 수행할 수 있는 행위에 대한 서비스라면 본 발명의 일 실시예에 따른 의료 정보 제공 시스템(100)이 제공하는 서비스(120)에 제한 없이 해당될 수 있다.
이하, 도 2를 참조하여 의료 정보 제공 시스템(200)의 일 예를 설명한다.
도 2는 본 발명의 일 실시예에 따른 의료 정보 제공 시스템(200)의 일 예를 설명하기 위한 구성도이다.
도 2에는 의료 정보 제공 시스템(200)에서 제공하는 서비스(210), 외부 필터(220) 및 클라우드의 아키텍쳐(230)가 도시되어 있다. 아키텍쳐(230)에는 하부구조(infrastructure)(2310), 내부 필터(2320), 데이터 저장소(2330), 제어부(2340), 플랫폼 레벨 API(platform-level API)(2350), 서비스 특정 API(servie-specific API)(2360) 및 사용자 인터페이스(2370)가 포함된다. 여기에서, 제어부(2340)에는 데이터셋 핸들러(handler)(2341), 워크플로우 매니저(manager)(2342), 환자 매니저(2343), 사용자 매니저(2344), 그룹 매니저(2345), 조건 매니저(2346)가 포함된다. 또한, 도 2에는 도시되지 않았으나, 제어부(2340)에는 필터 매니저가 더 포함된다.
서비스(210)의 종류는 도 1을 참조하여 상술한 바와 같다. 따라서, 이하에서는 자세한 설명을 생략한다.
외부 필터(220)는 클라우드의 외부에서 동작하는 필터를 의미한다. 구체적으로, 외부 필터(220)는 클라우드의 데이터베이스 외부에서 작업을 수행한다. 예를 들어, 외부 필터(220)는 클라우드와 연결된 외부 장치들 중 적어도 하나 이상의 장치들에 포함될 수 있다. 이때, 외부 필터(220)에 대한 정보는 아키텍쳐(230)의 필터 매니저에서 생성, 설정, 변경, 삭제되어 외부 장치로 전송될 수도 있고, 또는 외부 장치에서 생성, 설정, 변경, 삭제될 수도 있다. 본 발명의 일 실시예에 따른 외부 필터(220)에 대한 구체적인 설명은 도 5 내지 도 6을 참조하여 후술한다.
도 2에 도시된 아키텍쳐(230)는 도 1의 클라우드(110)에 구현될 수 있는 일 예에 해당된다. 따라서, 도 2에 도시된 구성요소들 외에 다른 범용적인 구성요소들이 더 포함될 수 있음을 본 실시예와 관련된 기술분야에서 통상의 지식을 가진 자라면 이해할 수 있다.
또한, 도 2에 도시된 아키텍쳐(230)에 포함된 하부구조(2310), 데이터 저장소(2330), 제어부(2340), 플랫폼 레벨 API(2350), 서비스 특정 API(2360) 및 사용자 인터페이스(2370)는 하나 또는 복수 개의 프로세서에 해당할 수 있다. 프로세서는 다수의 논리 게이트들의 어레이로 구현될 수도 있고, 범용적인 마이크로 프로세서와 이 마이크로 프로세서에서 실행될 수 있는 프로그램이 저장된 메모리의 조합으로 구현될 수도 있다. 또한, 다른 형태의 하드웨어로 구현될 수도 있음을 본 실시예가 속하는 기술분야에서 통상의 지식을 가진 자라면 이해할 수 있다.
데이터 저장소(2330)는 클라우드가 처리할 수 있는 모든 종류의 컨텐츠를 저장 및 관리한다. 여기에서, 컨텐츠는 텍스트, 이미지, 동영상을 포함하는 모든 종류의 문서(document)를 의미한다. 다시 말해, 컨텐츠는 영상(image), 파형(waveforms), 측정값(measured values) 등 일반적인 연산 장치에서 처리될 수 있는 모든 종류의 문서를 포함한다. 따라서, 본 발명의 일 실시예에서의 컨텐츠와 문서는 동일한 개념으로 기술한다.
본 발명의 일 실시예에 따른 의료 정보 제공 시스템(200)에서, 하나의 문서는 0개 이상의 문서집합(document set; 이하 DocSet)에 포함될 수 있다. 다시 말해, 문서는 문서집합에 포함되지 않을 수도 있고, 하나 이상의 문서집합에 포함될 수도 있다. 또한, 특정 문서는 반드시 1개의 그룹에 속해야 한다. 여기에서, 그룹은 병원, 부서/과 등의 실체적 조직상의 그룹을 의미할 수도 있고, 가상적인 형태의 사용자 집합을 의미할 수도 있다. 그룹에 대한 구체적인 내용은 후술한다. 클라우드에서는 각각의 문서를 식별하기 위한 ID가 부여된다. 본 발명의 일 실시예에 따른 문서와 관련된 ID의 종류와 이에 대한 정의는 아래의 표 1과 같다.
표 1
ID 종류 정의
Document UID 문서의 고유 ID로서, 문서를 생성한 특정 그룹 내에서 고유하다.
Document UUID Document UID와는 별개의 고유 ID로서, 전체 문서들 내에서 고유하다. 예를 들어, 제 1 문서의 Document UID는 하나이나, 제 1 문서가 전송(또는 처리)되는 경우마다 Document UUID는 달라질 수 있다.
Filter UID 문서를 생성한 필터를 나타내는 ID이다.
Patient Id 문서와 관련된 환자를 나타내는 ID이다.
본 발명의 일 실시예에 따른 모든 문서들 각각은 고유한 ID (Unique ID; 이하 UID)를 갖는데, 이 UID는 특정 그룹 내에서만 고유함을 보장한다. 또한, 모든 문서들 각각은 UID와는 별도로 고유의 UUID를 갖는데 이는 전체 문서 내에서 고유함을 보장한다. 본 발명의 일 실시예에 따른 클라우드에서의 문서는 IHE XDS 개념에서의 Document Entry와 대응된다.
데이터셋 핸들러(2341)는 문서집합을 관리한다. 구체적으로, 데이터셋 핸들러(2341)는 문서집합의 생성, 설정, 변경, 삭제를 수행한다. 여기에서, 문서집합(DocSet)은 실제 문서(Document)들의 가상적인 집합을 의미한다. 클라우드 내에서의 모든 처리는 문서집합 단위로 이루어진다. 또한, 특정 문서집합은 반드시 1개의 그룹에 속해야 한다. 클라우드에서는 각각의 문서집합을 식별하기 위한 ID가 부여된다. 본 발명의 일 실시예에 따른 문서집합과 관련된 ID의 종류와 이에 대한 정의는 아래의 표 2와 같다.
표 2
ID 종류 정의
DocSet UID 문서집합의 고유 ID로서, 문서집합을 생성한 특정 그룹 내에서 고유하다.
DocSet UUID DocSet UID와는 별개의 고유 ID로서, 전체 문서집합 내에서 고유하다. 예를 들어, 제 1 문서집합의 DocSet UID는 하나이나, 제 1 문서집합이 전송(또는 처리)되는 경우마다 DocSet UUID는 달라질 수 있다.
DocSet Class UID 문서집합의 종류를 나타내는 것으로 필터(Filter)의 입출력 형식을 지정하는데 사용된다.
DocSet Group UID 문서집합들 사이에서 연관 관계를 표현하는데 사용된다.
Filter UID 문서집합을 생성한 필터를 나타낸다.
Patient Id 문서집합과 관련된 환자를 나타낸다.
본 발명의 일 실시예에 따른 클라우드에서의 문서집합은 IHE XDS 개념에서의 Submission Set과 대응된다.
또한, 문서집합은 반드시 1개의 문서집합 클래스(DocSet Class)를 갖는다. 여기에서, 문서집합 클래스는 문서집합의 클래스를 의미한다. 문서집합 클래스는 필터(filter)의 입출력 형식을 지정하는데 사용되며, 클라우드 내에서 고유한 DocSet Class UID로 표현된다.
워크플로우 매니저(2342)는 클라우드 내에서 동작하는 워크플로우를 관리한다. 구체적으로, 워크플로우 매니저(2342)는 워크플로우의 생성, 설정, 변경, 삭제를 수행한다. 본 발명의 일 실시예에 따른 워크플로우의 구체적인 일 예는 도 4를 참조하여 후술한다.
환자 매니저(2343)는 환자에 대한 정보를 관리한다. 구체적으로, 환자 매니저(2343)는 환자 정보의 생성, 설정, 변경, 삭제를 수행한다. 환자는 의료 정보 또는 건강 정보의 소유자를 의미하며, 의료 정보를 이용하는 다른 주체인 사용자(user)와는 대별된다. 현실에서, 환자는 기관(예를 들어, 병원 또는 정부)별로 서로 다른 환자번호를 부여받는다. 따라서, 클라우드 내에서 환자는 여러 개의 그룹에서 서로 다른 환자번호로 표현될 수 있으며, 서로 연관 지어 같은 환자를 나타낼 수 있다.
사용자 매니저(2344)는 사용자에 대한 정보를 관리한다. 구체적으로, 사용자 매니저(2344)는 사용자 정보의 생성, 설정, 변경, 삭제를 수행한다. 여기에서, 관리는 환자 정보의 생성, 변경, 삭제를 모두 포함한다. 사용자는 클라우드 서비스를 이용하는 사용자를 의미하는 것으로 환자와는 대별된다. 예를 들어, 사용자는 주로 의사, 간호사 등의 의료진인 경우가 많으나 정부 관계자 등이 될 수도 있다.
하나의 사용자는 0개 이상의 그룹에 속할 수 있다. 다시 말해, 사용자는 그룹에 속하지 않을 수도 있고, 하나 이상의 그룹에 속할 수도 있다. 만약, 사용자가 하나 이상의 그룹에 속할 경우, 사용자는 그룹 관리자 권한을 부여받을 수도 있다. 상술한 문서집합을 검색, 조회하는 권한은 개별 사용자에게 부여될 수 있다. 본 발명의 일 실시예에 따른 사용자는 의료 정보 제공 시스템(200) 자체의 방식을 통해 인증될 수도 있고, 기타 인증 서비스를 제공하는 사업자를 통해 인증될 수도 있다.
그룹 매니저(2345)는 그룹에 대한 정보를 관리한다. 구체적으로, 그룹 매니저(2345)는 그룹 정보의 생성, 설정, 변경, 삭제를 수행한다. 그룹은 사용자들의 집합을 의미한다. 구성하기에 따라, 그룹은 병원, 부서/과 등의 실체적 조직상의 그룹을 의미할 수도 있고, 가상적인 형태의 사용자 집합을 의미할 수도 있다.
그룹은 독립 그룹으로 구성되거나 또는 1개의 상위 그룹 아래 구성될 수 있다. 또한, 그룹은 다수의 사용자를 포괄할 수 있다. 그룹은 소속된 특정 사용자에게 그룹을 관리하는 관리자 권한을 부여할 수 있다. 이때, 그룹의 관리권은 해당 그룹의 하위 그룹들에도 상속된다. 다시 말해, 특정 그룹의 관리자는 해당 그룹의 하위 그룹도 관리할 수 있다.
문서집합을 검색, 조회하는 권한을 사용자가 속한 그룹을 통해 간접적으로 부여할 수 있다. 다만, 문서집합을 검색, 조회하는 권한은 지정된 그룹에만 유효할 뿐이고, 해당 그룹의 하위 그룹들에 전파되지는 않는다.
조건 매니저(2346)는 의료 정보 제공 시스템(200) 상에 설정된 조건들을 관리한다. 구체적으로, 조건 매니저(2346)는 조건의 생성, 설정, 변경, 삭제를 수행한다. 여기에서, 조건은 문서집합 조건(DocSet rule) 및/또는 필터 조건(filter rule)이 해당될 수 있다. 한편, 필터 조건은 조건 매니저(2346)에 의하여 생성, 설정, 변경, 삭제될 수도 있고, 필터 매니저에 의하여 생성, 설정, 변경, 삭제될 수도 있다.
구체적으로, 문서집합 조건은 특정 문서집합의 검색, 조회권을 어떤 사용자에게 자동으로 부여할 때 사용되는 조건을 의미한다. 또한, 필터 조건은 필터의 작업이 자동으로 수행되도록 하는 조건을 의미한다. 본 발명의 일 실시예에 따른 필터에는 내부 필터(2320) 또는 외부 필터(220)가 포함될 수 있다.
내부 필터(2320)는 클라우드 내부에서 동작하는 필터를 의미한다. 구체적으로, 내부 필터(2320)는 클라우드의 데이터베이스 내부에서 작업을 수행한다. 이때, 내부 필터(2320)에 대한 정보는 아키텍쳐(230)의 필터 매니저에서 생성, 설정, 변경, 삭제된다.
필터와 관련된 필터 클래스(filter class), 필터 조건(filter rule), 필터 큐(filter queue) 및 필터 로그(filter log) 각각에 대한 구체적인 설명은 아래와 같다.
먼저, 필터 클래스(Filter Class)는 필터의 클래스를 의미하며, 문서집합 클래스에 의해 입출력 형식을 표현한다. 하나의 필터 클래스는 다수의 필터에 대응될 수 있다. 즉, 같은 입출력 형식 및 기능을 갖는 다양한 필터가 존재할 수 있다.
필터의 입력 및 출력은 0개 이상의 문서집합 클래스로 표현될 수 있다. 구체적으로, 필터는 1개의 문서집합을 입력받아 1개의 문서집합을 출력할 수 있으나, 복수의 문서집합을 입력받아 복수의 출력 문서집합을 생성할 수도 있다. 또한, 입력 없이 출력만 가능한 필터 또는 출력 없이 입력만 가능한 필터도 가능하다.
내부 필터(2320)는 클라우드의 데이터베이스 내에서 작업을 수행하는 필터를 의미하며, 하부 구조(2310)의 데이터베이스의 저장 함수(stored function)으로 구현될 수 있다. 한편, 외부 필터(220)는 클라우드 데이터베이스 외부에서 작업을 수행하는 필터를 의미하며, 클라우드가 제공하는 API(2350, 2360)를 이용하여 구현될 수 있다.
필터(Filter)는 필터의 인스턴스(instance)를 나타내는 것으로 필터 클래스로 표현된 필터의 실제 인스턴스를 나타낸다. 동일한 필터 클래스 UID를 갖는 모든 필터들은 실질적으로 동일한 기능을 수행한다.
다만, 각각의 필터에 따라 기본 그룹(default group), 기본 환자(default patient) 등을 서로 다르게 지정될 수 있다. 예를 들어, 필터 매니저는 기본 그룹 지정을 통해 해당 필터가 생성하는 문서집합 및 문서의 그룹을 자동 설정할 수 있다. 또한, 필터 매니저는 기본 환자 지정을 통해 해당 필터가 생성하는 문서집합 및 문서의 환자를 자동 설정할 수 있다.
필터 조건은 필터의 동작에 요구되는 적어도 하나 이상의 조건을 의미하며, 필터 조건이 만족될 경우 필터는 자동으로 작업을 수행한다. 만약, 하나의 필터가 동작하기 위하여 다수의 문서집합이 필요한 경우, 각각의 문서집합 별로 조건이 설정될 수 있다.
예를 들어, 필터가 작업을 수행하는 시간을 다음과 같이 지정할 수 있다.
일 예로, 절대적으로 지정된 특정 일시(예를 들어, 2014년 4월 5일 오후 3시)
다른 예로, 필터 조건의 충족 시점을 기준으로 일정 시간 이후(예를 들어, 필터 조건이 충족되고 5시간 이후)
또 다른 예로, 조건 충족 시점의 다음 날 0시를 기준으로 일정 시간 이후(예를 들어, 2014년 4월 5일 오후 3시에 조건이 충족되었다면, 2014년 4월 6일 오전 0시를 기준으로 5시간 이후)
필터 조건이 충족되면, 필터 매니저(또는, 조건 매니저(2346))는 작업을 수행할 필터와 필요한 문서집합들을 필터 큐에 등록하고, 필터가 작업을 수행할 시간을 지정한다. 만약, 필터 수행 시간을 특정되지 않으면, 필터는 즉시 작업을 수행한다.
필터 큐는 필터의 동작을 위한 대기 큐를 의미한다. 내부 필터(2320)의 경우, 지정된 시간 간격(예를 들어, 60초)으로 필터 큐의 내용을 처리한다. 한편, 외부 필터(220)의 경우 FilterProc 모듈 설정에 따라 필터 큐의 내용을 처리한다.
필터 로그는 내부 필터(2320)의 처리(동작)에 관한 로그를 의미한다.
본 발명의 일 실시예에 따른 내부 필터(2320) 및 외부 필터(220)에 대한 구체적인 설명은 도 5 내지 도 6을 참조하여 후술한다.
사용자 인터페이스(2370)는 클라우드의 관리, 정보의 검색 및 조회를 위한 사용자 인터페이스를 의미한다. 예를 들어, 사용자 인터페이스(2370)는 웹(web) 기반의 인터페이스가 될 수 있다.
플랫폼 레벨 API(2350)는 클라우드와 외부 장치들 사이의 직접적인 인터페이스를 위하여 구현된 API 모음을 의미한다. 또한, 서비스 레벨 API(2360)는 의료 정보 제공 시스템(200)이 제공하는 서비스(210) 중 특정 서비스(예를 들어, service A)를 목적으로 플랫폼 레벨 API(2350)에 기반하여 구현된 API 모음을 의미한다.
하부 구조(2310)는 상술한 모든 클라우드 서비스가 동작하기 위한 하부 구조를 의미한다. 예를 들어, 하부 구조(2310)에는 Amazon Web Services 클라우드 서비스가 해당될 수 있으나, 이에 한정되지 않는다.
상술한 아키텍쳐(230)로 구현된 클라우드는 개방형 플랫폼에 기반하여 대상체(예를 들어, 환자)의 의료 정보를 생성하고 제공할 수 있는바, 시간 및 공간의 제약 없이 사용자에게 대상체의 의료 정보를 제공할 수 있다.
도 3은 본 발명의 일 실시예에 따른 의료 정보 제공 시스템이 동작하는 일 예를 설명하기 위한 흐름도이다.
도 3을 참조하면, 의료 정보 제공 시스템이 동작하는 일 예는 도 1 및 도 2 에 도시된 의료 정보 제공 시스템(100, 200) 또는 클라우드(110)에서 시계열적으로 처리되는 단계들로 구성된다. 따라서, 이하에서 생략된 내용이라 하더라도 도 1 및 도 2에 도시된 의료 정보 제공 시스템 또는 클라우드(110)에 관하여 이상에서 기술된 내용은 도 3의 의료 정보 제공 시스템이 동작하는 일 예에도 적용됨을 알 수 있다.
이하에서는 설명의 편의를 위하여, 도 3에 도시된 각 단계들의 수행 주체는 '클라우드(110)'인 것으로 기재한다. 다만, 도 3에 도시된 각 단계들의 수행 주체는 도 2에 도시된 아키텍쳐(230)에 포함된 구성들 중 어느 하나가 될 수 있음은 당해 기술 분야에서 통상의 지식을 가진 자라면 쉽게 이해할 수 있다.
310 단계에서, 클라우드(110)는 그룹 정보의 생성 및 설정을 수행한다.
먼저, 클라우드(110)는 사용자로부터 입력된 외부 신호에 기초하여, 서비스를 개설하려는 기관을 대표하는 그룹(이하, 마스터 그룹이라 부르기로 한다)을 생성한다. 마스터 그룹 아래에는 실제 병원들과 같은 기관들이 생성될 수 있다. 예를 들어, 클라우드(110)는 아래의 표 3과 같이 그룹을 생성할 수 있다.
표 3
그룹 계층Group: Radionet 최상위 그룹: 마스터 그룹 Group: SNUH 1차 자식 그룹: 의료기관 Group: Radiology 2차 자식 그룹: 의료기관 내 부서 Group: CMC 1차 자식 그룹: 의료기관 Group: Cardiology 2차 자식 그룹: 의료기관 내 부서 Group: GuroClinic 1차 자식 그룹: 의료기관
상기 표 3을 참조하면, 클라우드(110)는 라디오넷 마스터 그룹(Radionet)을 생성하고, 서울대병원(SNUH), 카톨릭병원(CMC), 구로의원(Guro Clinic) 등의 실제 의료기관들을 라디오넷 마스터 그룹 아래에 자식 그룹으로 생성할 수 있다. 또한, 클라우드(110)는 실제 의료기관들을 그룹으로 구성한 후, 의료기관 내에 부서들을 또 다른 자식 그룹(Radiology, Cardiology)으로 등록할 수 있다.
그룹 정보의 저장을 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 4와 같다.
표 4
Table "VGroup"Column Type Modifiers----------------------------------------------------------------------vgroup_key integer not null PKvgroup_id character varying(64) not null UKvgroup_id_type character varying(16) not null UKvgroup_name character varying(256)vgroup_type character varying(64)parent_vgroup_key integer FKcreated_dttm timestamp without time zone not nulldeleted_dttm timestamp without time zone
상기 표 4의 테이블 구조에 포함된 속성들의 구체적인 설명은 아래의 표 5와 같다.
표 5
속성 설명
Group Id 그룹의 ID를 의미하며, 환자번호를 구성하는 3개 요소 중의 하나인 assigning_authority_id를 Group Id 로 설정한다. ISO OID를 사용해서 표기할 수도 있으나, 이에 제한되지 않는다.예를 들어, 82999와 같은 형태로 의료기관 코드가 부여되었다면, 이것은 한국(82)에 있는 999번 병원을 의미하는 것이다.
Group Id Type 그룹의 ID의 형태를 의미하며, 환자번호를 구성하는 3개 요소 중의 하나인 assigning_authority_id_type을 Group Id Type으로 설정한다. 그룹 ID가 ISO OID 형식으로 등록되어 있을 경우에는 ISO를 지정해야 하지만, 그렇지 않은 경우에는 자체적으로 정해서 사용할 수 있다.예를 들어, Group Id Type는 “BIS-CLOUD”와 같이 설정될 수 있다.
Group Name 사람이 알아볼 수 있는 그룹의 이름을 의미한다. 예를 들어, 의료기관의 공식이름으로 설정될 수 있다.
Group Type 그룹의 형태를 나타내기 위한 항목을 의미한다.예를 들어, 병원의 경우 “HOSPITAL”, 의원의 경우 “CLINIC"으로 설정될 수 있다.
Parent Group 부모 그룹을 의미한다.
320 단계에서, 클라우드(110)는 사용자 정보의 생성 및 설정을 수행한다.
클라우드(110)는 사용자로부터 입력된 외부 신호에 기초하여, 마스터 그룹을 관리할 사용자(이하, 마스터 관리자)를 생성한다. 그리고, 클라우드(110)는 마스터 관리자에게 마스터 그룹에 대한 관리권을 부여한다. 본 발명의 일 실시예에 따른 의료 정보 제공 시스템에서는 일 사용자가 어떤 그룹에 대해 관리권을 갖고 있다면 (즉, 그룹 관리자라면), 해당 그룹의 하위 그룹도 관리할 수 있다. 따라서, 마스터 관리자가 마스터 그룹에 대해 관리권을 갖고 있다는 것은 결국 마스터 관리자가 마스터 그룹 아래에 여러 그룹을 생성할 수 있다는 것을 의미한다. 그룹 관리자만이 해당 그룹 및 해당 그룹의 자식 그룹들에 사용자 또는 환자를 추가할 수 있다.
예를 들어, 그룹에 따른 그룹 관리자가 설정된 일 예는 아래의 표 6과 같다.
표 6
그룹 계층 그룹 관리자Group: Radionet bioadmin Group: SNUH bioadmin, snuhadmin Group: Radiology bioadmin, snuhadmin, snuhradioadmin Group: CMC bioadmin, cmcadmin Group: Cardiology bioadmin, cmcadmin Group: GuroClinic bioadmin, gurocadmin
상기 표 6을 참조하면, 마스터 관리자 bioadmin은 Radionet 그룹 및 자식 그룹들을 모두 관리할 수 있다. 한편, 그룹 관리자 snuhadmin은 SNUH 그룹 및 이것의 자식 그룹인 Radiology 그룹을 관리할 수 있다. 만약, Radiology 그룹에 대해 별도의 관리자가 필요하다면, 상기 표 6과 같이 snuhradioadmin이라는 그룹 관리자가 추가로 지정될 수 있다.
본 발명의 일 실시예에 따른 의료 정보 제공 시스템에서 사용자는 여러 개의 그룹에 소속될 수 있다. 이때, 사용자가 특정 그룹에 소속되어 관리권을 부여받으면 해당 그룹에 대한 관리자가 되고, 그렇지 않으면 일반 사용자가 된다. 그룹 관리자가 생성된 이후에는 클라우드(110)는 필요한 만큼의 일반 사용자를 생성하고 이들을 그룹에 소속시킨다.
다만, 권한이 상속되는 관리권과는 달리 조회권은 상속되지 않는다. 즉, 어떤 그룹에 대한 문서를 조회하려면 반드시 해당 그룹에 소속된 사용자이어야만 한다. 예를 들어, 상기 표 6을 참조하면, 그룹 관리자 snuhadmin은 SNUH 그룹과 Radiology 그룹을 관리할 수는 있지만, Radiology 그룹의 문서를 조회할 수는 없다. 사용자 snuhadmin이 Radiology 그룹의 문서를 조회하려면, snuhadmin 역시 Radiology 그룹에 소속되어야 한다.
사용자는 여러 개의 인증 방법을 가질 수 있다. 예를 들어, 사용자는 의료 정보 제공 시스템의 자체 인증을 통해 로그인할 수도 있고, 기타 인증 계정(예를 들어, 구글 계정)을 통해 로그인할 수도 있다.
사용자 정보 저장을 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 7과 같다.
표 7
Table "Users"Column Type Modifiers----------------------------------------------------------------------user_key integer not null PKuser_name character varying(256) not nullcreated_dttm timestamp without time zone not nulldeleted_dttm timestamp without time zone
그룹과 사용자 간의 관계 설정을 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 8과 같다.
표 8
Table "VGroupUser"Column Type Modifiers----------------------------------------------------------------------vgroup_user_key integer not null PKvgroup_key integer not null FKuser_key integer not null FKadmin_role Boolean default false
330 단계에서, 클라우드(110)는 환자 정보의 생성 및 설정을 수행한다.
클라우드(110)는 사용자로부터 입력된 외부 신호에 기초하여, 환자 정보를 생성하고 설정할 수 있다. 본 발명의 일 실시예에 따른 의료 정보 제공 시스템에서 환자는 환자번호, 이름, 성별, 생년월일 등의 속성을 가질 수 있다. 이 중에서, 환자번호는 (patient_id_value, assigning_authority_id, assigning_authority_id_type)과 같이 3개의 부분으로 구성된다. 이때, assigning_authority_id, assigning_authority_id_type는 그룹의 Group Id, Group Id Type에 대응하는 것이고, patient_id_value가 해당 그룹에서의 환자번호를 나타낸다. 따라서, 본 발명의 일 실시예에 따른 의료 정보 제공 시스템에서 환자는 반드시 1개의 그룹에만 속하게 된다.
환자 정보 저장을 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 9와 같다.
표 9
Table "Patient"Column Type Modifiers----------------------------------------------------------------------patient_key integer not null PKvgroup_key integer not null FKpatient_id_value character varying(64) not nullpatient_name character varying(256) not nullpatient_sex character varying(1)patient_birth_dttm timestamp without time zonerelated_patient_key integer FKcreated_dttm timestamp without time zone not nulldeleted_dttm timestamp without time zone
상기 표 9의 테이블 구조에 포함된 속성들의 구체적인 설명은 아래의 표 10과 같다.
표 10
속성 설명
Patient Id Value 환자번호를 구성하는 3개 부분 중 첫 번째인 patient_id_value를 의미한다.
Patient Name 환자이름을 의미한다. 예를 들어, HL7 방식(Last name^First name^Middle name^Suffix^Prefix)으로 입력될 수 있다.
Patient Sex 환자성별을 의미한다. 예를 들어, 'M=남성, F=여성, O=기타, U=모름'과 같이 입력될 수 있다.
Patient Birthdate 환자의 생년월일을 의미한다.
Related Patient 다른 환자정보와 연결을 의미한다.
동일한 환자라 하더라도 여러 개의 의료기관을 이용할 수 있다. 이 경우, 동일한 환자에 대해서 의료기관별로 서로 다른 환자번호가 부여될 수 있다. 따라서, 본 발명의 일 실시예에 따른 의료 정보 제공 시스템은 의료기관별로 환자를 생성한다. 다만, 의료 정보 제공 시스템에서의 환자 속성에는, 상기 표 10에 기재한 바와 같이 Related Patient라는 속성이 있는바, 다른 환자정보와 연결할 수 있다. 다시 말해, 클라우드(110)는 Related Patient 속성을 이용하여 각각의 의료기관에 분산된 동일한 환자에 대한 정보들을 찾아 연결할 수 있다.
340 단계에서, 클라우드(110)는 클라우드(110)의 관리자로부터 입력된 외부 신호에 기초하여 워크플로우를 설계한다.
워크플로우는 의료 정보 제공 시스템의 적어도 하나 이상의 필터가 작업을 수행하는 흐름을 나타낸다. 본 발명의 일 실시예에 따른 의료 정보 시스템은 워크플로우에 따라 대상체(예를 들어, 환자)의 의료 정보를 생성하고, 이를 사용자에게 제공한다. 이하, 도 4를 참조하여 워크플로우의 일 예를 설명한다.
도 4는 본 발명의 일 실시예에 따른 워크플로우(400)의 일 예를 도시한 도면이다.
도 4에는 클라우드(110)가 설계한 워크플로우(400)의 일 예가 도시되어 있다. 도 4는 설명의 편의를 위하여 도시된 것일 뿐, 클라우드(110)가 설계하는 워크플로우(400)는 도 4에 도시된 것에 한정되지 않는다. 다시 말해, 적어도 하나 이상의 필터집합 또는 단일 필터집합에 속한 적어도 하나 이상의 필터를 이용하여 대상체(예를 들어, 환자)의 의료 정보를 생성하고, 이를 사용자에게 제공할 수 있는 워크플로우라면 제한 없이 본 발명의 범위에 속할 수 있다.
도 4의 워크플로우(400)에서 원형상으로 도시된 부분은 문서집합 클래스(DSC)를 의미한다. 하나의 문서집합 내에는 적어도 하나 이상의 문서가 포함될 수 있다. 따라서, 도 4의 원형상들 각각에는 특정 문서집합 클래스가 기재되어 있으나, 문서집합에 속한 다른 문서도 해당될 수 있음은 당해 기술분야에서 통상의 기술을 가진 자라면 쉽게 이해할 수 있다. 문서집합 클래스, 문서집합 및 문서에 대한 구체적인 설명은 도 2를 참조하여 전술한 바와 같으므로, 이하에서는 생략한다.
또한, 도 4의 워크플로우(400)에서 사각형상으로 도시된 부분은 필터 클래스(FC) 및 필터 클래스에 포함된 필터(FU)를 의미한다. 하나의 필터 클래스에는 적어도 하나 이상의 필터가 포함될 수 있다. 따라서, 도 4의 사각형상들 각각에는 특정 필터 클래스 및 필터가 기재되어 있으나, 필터 클래스에 포함된 다른 필터도 해당될 수 있음은 당해 기술분야에서 통상의 기술을 가진 자라면 쉽게 이해할 수 있다. 필터 클래스 및 필터에 대한 구체적인 설명은 도 2를 참조하여 전술한 바와 같으므로, 이하에서는 생략한다.
또한, 도 4에 기재된 문서집합 클래스, 필터 클래스 및 필터의 구체적인 명칭은 편의상 부가한 것이므로, 이에 한정되지 않는다.
필터 클래스 3.1의 한 인스턴스인 필터 4.1(410)은 EKG(411), Holter(412), Event Recorder(413), DICOM(414)의 4가지 종류의 문서집합 중 하나 이상을 생성한다. 여기에서, 필터 4.1(410)은 문서집합을 생성하는 외부필터가 될 수도 있고, 외부 장치로부터 수신된 신호를 이용하여 문서집합을 생성하는 내부필터가 될 수도 있다. 문서집합 클래스 5.1로 표현된 EKG 문서집합(411)은 데이터 저장소(2330)에 저장될 수 있다.
필터 클래스 3.2.1의 한 인스턴스인 필터 4.2.1(420)은 Holter 문서집합(문서집합 클래스 5.2)(412)을 입력받아 CDSS 결과보고서 문서집합(문서집합 클래스 5.2.1)(421)을 출력한다.
필터 클래스 3.2.2의 한 인스턴스인 필터 4.2.2(450)는 원본 Holter 문서집합(412)과 CDSS 결과보고서 문서집합(421)을 통합하여 새로운 문서집합(문서집합 클래스 5.2.2)(451)을 생성한다. 생성된 문서집합(451)은 데이터 저장소(2330)에 저장될 수 있다.
필터 클래스 3.2의 한 인스턴스인 필터 4.2(430)는 문서집합 클래스 5.3으로 표현된 Event Recorder 문서집합(413)을 통합한다.
필터 클래스 3.4.1의 한 인스턴스인 필터 4.4.1(440)은 문서집합 클래스 5.4로 표현된 DICOM 문서집합(414)을 외부 장치에 제공한다. 그리고, 외부 장치는 DICOM 문서집합(414)을 화면에 디스플레이한다. 디스플레이된 문서집합(441)은 클라우드(110)에 의하여 확인될 수 있다.
다시 도 3을 참조하면, 350 단계에서, 클라우드(110)는 문서집합 클래스를 설정한다. 다시 말해, 클라우드(110)는 340 단계에서 설계한 워크플로우(400)가 동작하기 위하여 필요한 문서집합 클래스를 설정한다.
클라우드(110)는 각 문서집합 및 필터에 UID를 부여하고, 이를 의료 정보 제공 시스템에 설정한다. 예를 들어, 도 4에 도시된 필터 클래스 3.1(410), 문서집합 클래스 5.1(411)은 각각 1.2.410.200054.3.1, 1.2.410.200054.5.1와 같은 UID로 표현될 수 있다. 문서집합 클래스의 설정은 상기 UID와 문서집합 클래스의 이름이 지정되는 것으로 완료된다.
문서집합 클래스 정보의 저장을 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 11과 같다.
표 11
Table "DocSetClass"Column Type Modifiers----------------------------------------------------------------------docset_class_uid character varying(64) not null PKdocset_class_type character varying(10) not nulldocset_class_name character varying(256) not null
상기 표 11의 테이블 구조에 포함된 속성들의 구체적인 설명은 아래의 표 12와 같다.
표 12
속성 설명
DocSet Class UID 문서집합 클래스의 UID를 의미하며, 각 문서집합 클래스에는 고유한 UID가 부여된다.
DocSet Class Type 문서집합 클래스의 형태를 의미하는 것으로 참고용으로만 사용된다.
DocSet Class Name 문서집합 클래스의 이름을 나타낸다.
360 단계에서, 클라우드(110)는 필터 클래스를 설정한다. 다시 말해, 클라우드(110)는 340 단계에서 설계한 워크플로우(400)가 동작하기 위하여 필요한 필터 클래스를 설정한다.
클라우드(110)가 필터 클래스를 설정하기 위해서는 필터 클래스 UID 및 필터 클래스 이름 뿐만 아니라 다음과 같이 몇 가지 추가 속성이 더 필요하다.
필터 클래스 정보의 저장을 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 13 및 표 14와 같다.
표 13
Table "FilterClass"Column Type Modifiers----------------------------------------------------------------------filter_class_uid character varying(64) not null PKfilter_class_name character varying(256) not nullfilter_type character varying(10) not nullfilter_proc_name character varying(256)filter_proc_args character varying(256)
표 14
Table "FilterInOut"Column Type Modifiers----------------------------------------------------------------------filter_class_uid character varying(64) not null PK, FKdocset_type character varying(1) not null PKdocset_class_uid character varying(64) not null PK, FK
상기 표 13 및 표 14의 테이블 구조에 포함된 속성들의 구체적인 설명은 아래의 표 15와 같다.
표 15
속성 설명
Filter Class UID 필터 클래스의 UID로서 각 필터 클래스에 고유한 UID가 부여된다.
Filter Class Name 필터 클래스의 이름을 나타낸다.
Filter Class Type 필터 클래스의 형태를 의미하는 것으로 내부필터(I)인지, 외부필터(E)인지 나타낸다.
Filter Proc Name 내부 필터에서만 설정되는 것으로 데이터베이스 프로시저의 이름이다.
Filter Proc Args 내부 필터에서만 설정하는 것으로 데이터베이스 프로시저의 인자들이다.
DocSet Type 지정된 문서집합이 필터의 입력(I)인지 출력(O)인지 나타낸다.
DocSet Class UID 필터의 입력 또는 출력 문서집합을 지정한다.
또한, 클라우드(110)는 각각의 필터 클래스가 처리할 수 있는 입력 문서집합 및 출력 문서집합을 설정한다.
예를 들어, 클라우드(110)는 아래의 표 16과 같이 필터 클래스를 설정할 수 있다.
표 16
filter_class_uid filter_class_name type filter_proc_name docset_type docset_class_uid----------------------------------------------------------------------1.2.410.200054.3.1 data uploader E O 1.2.410.200054.5.1 O 1.2.410.200054.5.2 O 1.2.410.200054.5.3 O 1.2.410.200054.5.41.2.410.200054.3.2 Holter data creator E I 1.2.410.200054.5.31.2.410.200054.3.2.1 CDSS caller E I 1.2.410.200054.5.2 O 1.2.410.200054.5.2.11.2.410.200054.3.2.2 data merger I FilterQueue_bypass I 1.2.410.200054.5.2 I 1.2.410.200054.5.2.1 O 1.2.410.200054.5.2.21.2.410.200054.3.4.1 DICOM viewer E I 1.2.410.200054.5.4 O 1.2.410.200054.5.4.1
370 단계에서, 클라우드(110)는 필터를 설정한다. 다시 말해, 클라우드(110)는 340 단계에서 설계한 워크플로우(400)가 동작하기 위하여 필요한 필터를 설정한다.
필터 정보의 저장을 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 17과 같다.
표 17
Table "Filter"Column Type Modifiers----------------------------------------------------------------------filter_key integer not null PKfilter_uid character varying(64) not null UKfilter_class_uid character varying(64) not null FKfilter_name character varying(256) not nullfilter_proc_args character varying(32)default_vgroup_key integer FKdefault_patient_key integer FKuser_key integer FKcreated_dttm timestamp without time zone not nulldeleted_dttm timestamp without time zone
상기 표 17의 테이블 구조에 포함된 속성들의 구체적인 설명은 아래의 표 18과 같다.
표 18
속성 설명
Filter UID 필터의 UID를 나타내는 것으로 각각의 필터마다 고유한 값이다.
Filter Class UID 필터의 종류를 나타내는 것으로 필터 클래스 UID를 설정한다
Filter Name 필터 이름을 의미한다.
Filter Proc Args 내부 필터에서 사용하는 데이터베이스 프로시저의 인자를 재정의한다.
Default Group 필터가 처리하는 문서집합에 그룹정보가 없을 때 자동으로 설정되는 그룹을 의미한다.
Default Patient 필터가 처리하는 문서집합에 환자정보가 없을 때 자동으로 설정되는 환자를 의미한다.
예를 들어, 클라우드(110)는 아래의 표 19와 같이 필터를 설정할 수 있다.
표 19
filter_uid filter_class_uid filter_name----------------------------------------------------------------------1.2.410.200054.4.1.2.152.82.177.100.84.74.1598 1.2.410.200054.3.1 Bioroid02(ejoonie)1.2.410.200054.4.1.2.152.82.177.100.84.74.1582 1.2.410.200054.3.1 Bioroid1.2.410.200054.4.1.2.20.137.253.246.167.124.1347 1.2.410.200054.3.1 Bioroid1.2.410.200054.4.1.2.152.82.177.100.84.74.2289 1.2.410.200054.3.1 Bioroid1.2.410.200054.4.1.2.20.137.253.246.167.124 1.2.410.200054.3.1 Bioroid1.2.410.200054.4.1 1.2.410.200054.3.1 BioPump1.2.410.200054.4.1.2.152.82.177.100.84.74 1.2.410.200054.3.1 Bioroid (ejoonie)1.2.410.200054.4.1.2.12.223.164.47.47.236 1.2.410.200054.3.1 Bioroid1.2.410.200054.4.1.2.8.212.43.25.38.81 1.2.410.200054.3.1 Bioroid1.2.410.200054.4.2 1.2.410.200054.3.2 EventMerge1.2.410.200054.4.2.1 1.2.410.200054.3.2.1 HolterExport1.2.410.200054.4.2.2 1.2.410.200054.3.2.2 SimpleMerge1.2.410.200054.4.4.1 1.2.410.200054.3.4.1 ezDICOM
380 단계에서, 클라우드(110)는 필터 조건을 설정한다.
만약, 클라우드(110)가 필터 조건을 설정하지 않으면 문서집합들은 단순히 저장하는 것만이 가능할 뿐이고, 도 4에 도시된 워크플로우(400)는 구현될 수 없다. 필터 조건은 i) 작업을 수행해야 할 필터에 대한 설정 부분과, ii) 필터가 작업을 수행하기 위한 입력조건을 설정하는 부분으로 구성된다.
먼저, 필터의 입력조건이 만족되었을 때, 필터가 수행할 작업의 정보를 저장하기 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 20과 같다.
표 20
Table "FilterRule"Column Type Modifiers----------------------------------------------------------------------filter_rule_key integer not null PKfilter_key integer not null FKfilter_rule_name character varying(256)scheduled_dttm timestamp without time zonescheduled_delay integercreated_dttm timestamp without time zone not nulldeleted_dttm timestamp without time zone
상기 표 20의 테이블 구조에 포함된 속성들의 구체적인 설명은 아래의 표 21과 같다.
표 21
속성 설명
Filter Rule Name 필터 룰의 이름을 나타낸다.
Filter 수행되어야 할 필터를 선택한다.
Scheduled Time 필터가 수행될 절대시간을 지정하는 것으로, 지정된 시간에 필터가작업을 수행한다. 절대시간 지정은 아래의 상대시간 지정보다 우선한다.
Scheduled Delay 필터가 수행될 상대시간을 지정하는 것으로, a) 모드에서는 현재시점으로부터 지정된 시간 이후에, 또는 b) 모드에서는 내일 0시 이후 지정된 시간에 필터가 수행된다.예를 들어, 현재시점이 2014년 2월 5일 18:00이고 Scheduled Delay 속성이 3:00 이라면, a) 모드에서는 2014년 2월 5일 21:00에 필터가 수행된다. b) 모드에서는 2014년 2월 6일 3:00에 필터가 수행된다.
다음으로, 필터의 입력조건의 설정을 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 22와 같다.
표 22
Table "FilterRuleInput"Column Type Modifiers----------------------------------------------------------------------filter_rule_input_key integer not null PKfilter_rule_key integer not null FK, UKdocset_class_uid character varying(64) not null FK, UKfilter_key integer FK, UKvgroup_key integer FK, UKpatient_key integer FK, UK
상기 표 22의 테이블 구조에 포함된 속성들의 구체적인 설명은 아래의 표 23과 같다.
표 23
속성 설명
Filter Rule 필터 조건을 선택한다.
DocSet Class UID 어떤 문서집합이 준비되어야 필터가 수행될 것인지를 설정한다.
Filter 위의 문서집합이 어떤 필터가 생성한 것이어야 하는지 설정한다.
Group 위의 문서집합이 어떤 그룹에 속한 것이어야 하는지 설정한다.
Patient 위의 문서집합이 어떤 환자의 것이어야 하는지 설정한다.
도 4에 도시된 워크플로우(400)를 참조하면, Holter 문서(412)와 DICOM 문서(414)에 대해서만 워크플로우 설정이 필요하다. 이는, 클라우드(110)가 아래의 표 24와 같이 설정함으로써 구현될 수 있다.
표 24
filter_rule_name filter_uid scheduled_dttm delay docset_class_uid filter vgroup patient----------------------------------------------------------------------HolterExport rule 1.2.410.200054.4.2.1 1.2.410.200054.5.2Merger rule 1.2.410.200054.4.2.2 1.2.410.200054.5.2 1.2.410.200054.5.2.1ezDICOM rule 1.2.410.200054.4.4.1 1.2.410.200054.5.4
새로운 문서집합이 생성될 경우, 자동으로 FilterRule_apply() 함수가 호출된다. 이때, 클라우드(110)는 필터 조건을 검색하여 새로 생성된 문서집합에 적용할 필터가 있는지를 검색하고, 그 결과를 필터 큐에 기록한다. 만약, 필터 조건의 입력조건이 하나의 문서집합으로만 구성되어 있을 경우에는, 조건을 만족하는 해당 문서집합이 생성되는 즉시 필터 조건이 적용된다. 그러나, 필터 조건의 입력조건이 여러 개의 문서집합으로 구성되어 있는 경우에는(즉, 여러 개의 문서집합을 한꺼번에 처리해야 하는 필터라면), 필터 수행에 필요한 모든 문서집합이 준비 완료되었을 때에 필터 조건이 적용된다.
상기 표 24의 내용을 설명하면 아래와 같다.
1) 필터 룰 “HolterExport rule”은 문서집합 클래스 1.2.410.200054.5.2에 대한 문서집합이 준비되면 필터 1.2.410.200054.4.2.1이 즉시 수행된다.
2) 필터 룰 “Merger rule”은 문서집합 클래스 1.2.410.200054.5.2 및 1.2.410.200054.5.2.1에 대한 문서집합이 모두 준비될 때 필터 1.2.410.200054.5.2.2가 수행된다.
3) 필터 룰 “ezDICOM rule”은 문서집합 클래스 1.2.410.200054.5.4에 대한 문서집합이 준비될 때 필터 1.2.410.200054.4.4.1이 수행된다.
390 단계에서, 필터 큐가 생성된다. 필터 큐는 설정하는 것이 아니라 필터 조건을 적용한 결과로서 생성되는 것으로, 작업을 수행해야 할 필터에 대한 정보들과 필터의 작업 수행 결과를 저장한다.
필터 큐는 i) 작업을 수행할 필터에 대한 정보를 저장하는 부분과, ii) 필터의 입력으로 들어갈 문서집합에 대한 정보를 저장하는 부분으로 구성된다.
먼저, 작업을 수행할 필터에 대한 정보를 저장하기 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 25와 같다.
표 25
Table "FilterQueue"Column Type Modifiers----------------------------------------------------------------------filter_queue_key integer not null PKfilter_queue_uuid uuid not null UKfilter_key integer not null FKfilter_result_text textfilter_result_code integerscheduled_dttm timestamp without time zoneperformed_dttm timestamp without time zonecreated_dttm timestamp without time zone not null
상기 표 25의 테이블 구조에 포함된 속성들의 구체적인 설명은 아래의 표 26과 같다.
표 26
속성 설명
Filter Queue UUID 필터 큐에 대한 UUID로서, 필터 작업을 XDS 방식으로 처리할 때 사용된다.
Filter 수행될 필터를 지정한다.
Filter Result Text 필터의 수행 결과를 나타낸다.
Filter Result Code 필터의 수행 결과코드를 나타낸다.
Scheduled Time 필터가 수행될 시간을 나타낸다.
Performed Time 필터가 수행된 시간을 나타낸다.
다음으로, 필터의 입력으로 들어갈 문서집합에 대한 정보를 저장하기 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 27과 같다.
표 27
Table "FilterQueueInput"Column Type Modifiers----------------------------------------------------------------------filter_queue_input_key integer not null PKfilter_queue_input_uuid uuid not null UKfilter_queue_key integer not null UK2docset_key integer not null UK2created_dttm timestamp without time zone not null
상기 표 27의 테이블 구조에 포함된 속성들의 구체적인 설명은 아래의 표 28과 같다.
표 28
속성 설명
Filter Queue Input UUID 필터 큐 입력에 대한 UUID로서, 필터 작업을 XDS 방식으로 처리할 때 사용된다.
Filter Queue 필터 큐를 지정한다.
DocSet 문서집합을 지정한다.
상술한 바와 같이 필터 큐에 작업을 수행할 필터의 정보들이 저장되면, 필터의 형태에 따라 다음과 같이 필터가 작업을 수행한다.
1) 내부필터는 데이터베이스의 작업 관리자(job manager)에 의해 작업을 수행한다. 데이터베이스 작업 관리자는 주기적으로 FilterQueue_execute() 함수를 호출하는데, 이 함수는 필터 큐의 내용 중에서 내부필터를 찾은 후 필터가 작업을 수행하여야 할 시간에 데이터베이스 작업 관리자가 해당 필터가 작업을 수행하도록 한다.
2) 외부필터는 FilterProc에 의해 작업을 수행한다. 여기에서, FilterProc 프로그램은 외부필터를 구현하기 위한 인터페이스 모듈을 의미한다. 이하, 도 6을 참조하여 외부 필터에 대하여 구체적으로 설명한다.
도 5는 본 발명의 일 실시예에 따른 외부 필터(541)의 일 예를 설명하기 위한 도면이다.
도 5를 참조하면, 클라우드(510) 및 클라우드(510)와 연결된 외부장치들(520, 530, 540)이 도시되어 있다. 이때, 클라우드(510)와 외부장치들(520, 530, 540)은 유선 또는 무선 통신에 의하여 서로 연결될 수 있다. 예를 들어, 클라우드(510)와 외부장치들(520, 530, 540)은 IHE XDS 또는 MHD 표준 프로토콜을 통하여 연결될 수 있으나, 이에 한정되지 않는다. 클라우드(510)와 외부장치들(520, 530, 540)이 연결되는 통신 프로토콜의 일 예는 도 6을 참조하여 후술한다.
외부장치는 다른 외부장치 또는 클라우드(510)와 통신이 가능한 장치라면 제한없이 해당될 수 있다. 예를 들어, 외부장치들(520, 530, 540) 각각은 환자에 대한 진단 정보를 획득하는 의료 장비, PC 또는 모바일 단말기 등이 해당 될 수 있으나, 이에 제한되지 않는다.
외부필터(541)는 외부장치들(520, 530, 540) 중 적어도 어느 하나에 포함될 수 있다. 이때, 외부필터(541)와 클라우드(510)는 FilterProc 프로그램을 통하여 작업을 송수신할 수 있다. FilterProc 프로그램은 지정된 Filter UID를 이용하여 자신이 처리해야 할 필터 작업들을 검색한 후 입력 문서집합들을 다운로드하고, 필터 처리를 수행한 후, 생성된 결과 문서들을 새로운 문서집합 형태로 구성하여 다시 업로드하는 역할을 한다. FilterProc 프로그램의 설정에 대해서는 도 6을 참조하여 후술한다.
도 6은 본 발명의 일 실시예에 따른 의료 정보 제공 시스템에서 사용되는 통신 프로토콜의 일 예를 설명하기 위한 도면이다.
도 6을 참조하면, 의료 정보 제공 시스템(600)에 포함된 클라우드(610) 및 외부장치들 각각에 설치된 프로그램(620, 630)의 일 예가 도시되어 있다. 여기에서, 프로그램(620, 630)은 유무선 통신을 통하여 클라우드(610)와 연결될 수 있는 프로그램이라면, 제한 없이 해당될 수 있다.
예를 들어, 생체 신호 정보(621)를 클라우드(610)로 전송하는 프로그램인 BioPump(620)와 클라우드(610)는 IHE(Integrating the Healthcare Enterprise) XDS (Cross-Enterprise Document Sharing) 또는 MHD (Mobile-access to Health Document) 프로토콜을 사용하여 통신할 수 있다. 구체적으로, BioPump(620)와 클라우드(610)의 통신에는 XDS Provide and Register Document Set 프로토콜 또는 MHD Put Document Dossier 프로토콜이 사용될 수 있다.
또한, Event Recorder에서 생체 신호 정보를 수신(622)하여 이를 클라우드(610)로 재전송해주는 Bioroid(630)에서는 모바일 환경에 특화된 IHE MHD 프로토콜이 사용될 수 있다. 여기에서, MHD 프로토콜은 XDS 프로토콜을 모바일 환경에 맞도록 간략화한 것을 의미한다.
클라우드(610)와 외부 필터(650, 660) 사이에서 사용되는 프로토콜 역시 IHE XDS 프로토콜이 될 수 있다. 구체적으로, 클라우드(610)와 외부 필터(650, 660)는 XDS Registry Stored Query, XDS Retrieve Document Set, XDS Provide and Register Document Set 프로토콜을 사용하여 통신할 수 있다.
본 발명의 일 실시예에 따른 의료 정보 제공 시스템(600)은 범용 통신 표준 프로토콜을 사용할 수 있다. 따라서, 의료 정보 제공 시스템(600)에서 사용되는 표준 프로토콜을 구현한 것이라면, 어떤 API이든 클라우드(610)와 연동이 가능하다.
외부장치에 설치된 프로그램(620, 630)이 XDS 또는 MHD 프로토콜을 이용하여 클라우드(610)와 통신할 때 사용되는 주요 키(Key) 값들의 일 예는 아래의 표 29 및 표 30과 같다.
표 29 XDS/MHD Document Entry
Key 설명
entryUUID 문서의 UUID로서, 전체적으로 완전히 고유하여야 한다. 최초 전송할 때에는 UUID 대신에 symbolic name을 사용할 수도 있다.
classCode 문서의 클래스 코드이다.
creationTime 문서의 생성 일시이다.
formatCode 문서의 포맷 코드이다.
mimeType 문서의 MIME 타입을 나타낸다.
patientId 환자번호를 나타낸다.
serviceStartTime 서비스가 시작된 시간을 나타낸다.
sourcePatientInfo 환자이름, 성별, 생년월일, 주소를 나타낸다.
title 문서의 제목이다.
typeCode 문서의 타입 코드이다.
uniqueId 문서의 UID로서, 그룹 내에서 고유하여야 한다.
표 30 XDS/MHD Submission Set
Key 설명
entryUUID 문서집합의 UUID로서, 전체적으로 완전히 고유하여야 한다. 최초 전송할 때에는 UUID 대신에 symbolic name을 사용할 수도 있다.
contentTypeCode 문서집합의 내용을 나타내는 코드로서, 내부적으로는 Document Set Class UID에 대응된다.
patientId 환자번호를 나타낸다.
sourceId 문서집합을 생성한 소스를 나타내는 것으로, 내부적으로는 Filter UID에 대응된다.
submissionTime 문서집합을 전송한 일시를 나타낸다.
title 문서집합의 제목이다.
uniqueId 문서집합의 UID로서, 그룹 내에서 고유하여야 한다.
IHE XDS/MHD 표준에서는 Document Entry, Submission Set, Folder, Association 객체를 이용하여 문서, 문서집합, 폴더 등을 구현하고 관계를 표현한다. 상기 객체들을 클라우드(610)에 저장하기 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 31 내지 표 36과 같다.
표 31
Table "Document"Column Type Modifiers----------------------------------------------------------------------document_key integer not null PKvgroup_key integer not null FK, UKdocument_uid character varying(64) not null UKrepository_uid character varying(64) not null UK location_type character varying(4)location_root character varying(256)location_path character varying(256)document_size integerdocument_hash character varying(256)filter_key integer not null FKpatient_key integer FKcreated_dttm timestamp without time zone not nulldeleted_dttm timestamp without time zone
표 32
Table "XDSDocument Column Type Modifiers--------------------------------------------------------------------------xds_document_key integer not null PKdocument_key integer not null FKmetadata_xml xmlmime_type character varying(128) not nulldocument_uuid uuid not null UKdocument_uid character varying(64) not nullrepository_uid character varying(64) not nulldocument_status character varying(1) not null default 'A'patient_id personid_tsource_patient_id personid_tdocument_title character varying(128)document_comments character varying(4000)author_id personid_tauthor_name character varying(64)class_code codeinfo_tformat_code codeinfo_th_f_type_code codeinfo_tlanguage_code character varying(256)practice_code codeinfo_ttype_code codeinfo_tservice_start_dttm timestamp without time zoneservice_stop_dttm timestamp without time zonecreated_dttm timestamp without time zone not nulldeleted_dttm timestamp without time zonepatient_name character varying(256)patient_sex character varying(1)patient_birth_dttm timestamp without time zonepatient_address character varying(256)
표 33
Table "DocSet"Column Type Modifiers----------------------------------------------------------------------docset_key integer not null PKvgroup_key integer not null FK, UKdocset_uid character varying(64) not null UKdocset_class_uid character varying(64) not null FKdocset_group_uid character varying(64) not nullfilter_key integer not null FKpatient_key integer FKcreated_dttm timestamp without time zone not nulldeleted_dttm timestamp without time zone
표 34
Table "XDSDocSet"Column Type Modifiers----------------------------------------------------------------------xds_docset_key integer not null PKdocset_key integer not null FKmetadata_xml xmldocset_uuid uuid not null UKdocset_uid character varying(64) not nullsource_id character varying(64) not nullpatient_id personid_tcontent_type_code codeinfo_tdocset_status character varying(1) not null default 'A'docset_title character varying(128)docset_comments character varying(4000)submit_dttm timestamp without time zonecreated_dttm timestamp without time zone not nulldeleted_dttm timestamp without time zone
표 35
Table "XDSFolder"Column Type Modifiers----------------------------------------------------------------------xds_folder_key integer not null PKmetadata_xml xmlfolder_uuid uuid not null UKfolder_uid character varying(64) not nullpatient_id personid_tcode_list codeinfo_t[]folder_status character varying(1)folder_title character varying(128)folder_comments character varying(4000)update_dttm timestamp without time zonecreated_dttm timestamp without time zone not nulldeleted_dttm timestamp without time zone
표 36
Table "XDSAssociation"Column Type Modifiers----------------------------------------------------------------------xds_association_key integer not null PKmetadata_xml xmlassociation_uuid uuid not null UKassociation_kind character varying(4) not nullassociation_type character varying(16) not nullsource_uuid uuid not nulltarget_uuid uuid not nullcreated_dttm timestamp without time zone not null
상기 표 31 내지 표 36의 테이블들과 IHE XDS/MHD 객체들과의 대응 관계는 아래의 표 37 내지 표 40과 같다.
표 37
IHE XDS/MHD 클라우드 데이터베이스
DocumentEntry.entryUUID XDSDocument.document_uuid
DocumentEntry.uniqueId XDSDocument.document_uidDocument.document_uid
DocumentEntry.hash Document.hash
DocumentEntry.size Document.size
DocumentEntry.repositoryUniqueId XDSDocument.repository_uid
DocumentEntry.patientId XDSDocument.patient_idDocument.patient_keyDocument.vgroup_key
DocumentEntry.mimeType XDSDocument.mime_type
DocumentEntry.status XDSDocument.document_status
DocumentEntry.title XDSDocument.document_title
DocumentEntry.comments XDSDocument.document_comments
DocumentEntry.author XDSDocument.author_idXDSDocument.author_name
DocumentEntry.sourcePatientId XDSDocument.source_patient_id
DocumentEntry.sourcePatientInfo XDSDocument.patient_nameXDSDocument.patient_sexXDSDocument.patient_birth_dttmXDSDocument.patient_address
DocumentEntry.classCode XDSDocument.class_code
DocumentEntry.formatCode XDSDocument.format_code
DocumentEntry.healthcareFacilityTypeCode XDSDocument.h_f_type_code
DocumentEntry.languageCode XDSDocument.language_code
DocumentEntry.practiceSettingCode XDSDocument.practice_code
DocumentEntry.typeCode XDSDocument.type_code
DocumentEntry.creationTime XDSDocument.created_dttm
DocumentEntry.serviceStartTime XDSDocument.service_start_dttm
DocumentEntry.serviceStopTime XDSDocument.service_stop_dttm
Document Document.location_typeDocument.location_rootDocument.location_path
표 38
IHE XDS/MHD 클라우드 데이터베이스
SubmissionSet.entryUUID XDSDocSet.docset_uuid
SubmissionSet.uniqueId XDSDocSet.docset_uidDocSet.docset_uid
SubmissionSet.patientId XDSDocSet.patient_idDocSet.patient_keyDocSet.vgroup_key
SubmissionSet.sourceId XDSDocSet.source_idDocSet.filter_key
SubmissionSet.contentTypeCode XDSDocSet.content_type_codeDocSet.docset_class_uid
SubmissionSet.status XDSDocSet.docset_staus
SubmissionSet.title XDSDocSet.docset_title
SubmissionSet.comments XDSDocSet.docset_comments
SubmissionSet.submissionTime XDSDocSet.submit_dttm
표 39
IHE XDS/MHD 클라우드 데이터베이스
Folder.entryUUID XDSFolder.folder_uuid
Folder.uniqueId XDSFolder.folder_uid
Folder.patientId XDSFolder.patient_id
Folder.status XDSFolder.folder_status
Folder.title XDSFolder.folder_title
Folder.comments XDSFolder.folder_comments
Folder.codeList XDSFolder.code_list
Folder.lastUpdateTime XDSFolder.update_dttm
표 40
IHE XDS/MHD 클라우드 데이터베이스
Association.uuid XDSAssociation.association_uuid
Association.sourceObject XDSAssociation.source_uuid
Association.targetObject XDSAssociation.target_uuid
Association.associationType XDSAssociation.association_type HAS: hasMember APND: append RPLC: replace XFRM: transform XFRM_RPLC: transformWithReplace SIGNS: signs
XDSAssociation.association_kind SD: SubmissionSet - Original Document SE: SubmissionSet - Existing Document SF: SubmissionSet - Folder FD: Folder - Document DD: Document - Document JS: FilterJob - SubmissionSet JD: FilterJob - Document
한편, 외부필터(650, 660)는 총 5 단계들을 거쳐 작업을 수행한다. 외부필터(650, 660)가 작업을 수행하면서 거치는 5단계는 아래와 같다.
제 1 단계로, 외부필터(650, 660)에서 수행될 작업을 생성한다. 구체적으로, 필터 조건에 의하여 필터 작업이 필요한 경우, 클라우드(610)는 필터 큐(즉, 표 25 및 표 27에 기재된 테이블)에 각각 FilterQueue UUID, FilterQueueInput UUID를 생성한다.
제 2 단계로, 외부필터(650, 660)에서 수행될 작업을 검색한다. 예를 들어, 외부필터(650, 660)에서 수행될 작업의 검색은 XDS Registry Stored Query 방식을 확장하여 구현할 수 있다. 구체적으로, FindFilterJobs라고 하는 Stored Query는, 아래의 표 41과 같이, 필터 작업을 Association의 리스트 형태로 반환할 수 있다.
표 41
클라우드 데이터베이스 IHE XDS/MHD
FilterQueueInput.filter_queue_input_uuid Association.uuid
FilterQueue.filter_queue_uuid Association.sourceObject
XDSDocSet.docset_uuid Association.targetObject
제 3 단계로, 외부필터(650, 660)에서 수행될 작업 리스트를 준비한다. 예를 들어, 검색된 필터 작업들에 대한 Association 리스트는 FilterProc 내에서 아래의 표 42와 같이 FilterJob 리스트를 구성한다.
표 42
IHE XDS/MHD FilterProc.FilterJob
Association.uuid FilterJob.docsetList.subjobUUID= FilterQueueInput.filter_queue_input_uuid
Association.sourceObject FilterJob.jobUUID= FilterQueue.filter_queue_uuid
Association.targetObject FilterJob.docsetList.docsetUUID= XDSDocSet.docset_uuid
여기에서, FilterProc 프로그램은 외부필터(650, 660)를 구현하기 위한 인터페이스 모듈을 의미한다. 다시 말해, FilterProc은 의료 정보 제공 시스템 상에서 동작하는 외부필터(650, 660)의 구현을 위해 필요한 것으로 특정 필터/문서집합에 대한 처리 방법을 지정한다. FilterProc은 지정된 서버, 포트 정보를 이용하여 클라우드에 접속한 후 설정 파일에 저장된 내용에 따라 지정된 동작을 수행한다.
만약, 설정 파일 이외에 추가로 지정된 쿼리 파일이 없으면, 설정 파일의 filterUID에서 지정된 필터의 역할을 하도록 특정된다. 만약, 추가로 지정된 쿼리 파일이 있을 경우, 쿼리 파일에서 지정한 내용으로 필터 처리를 수행한다.
FilterProc 설정 파일에서 사용할 수 있는 키 값들 및 이에 대한 설명은 아래의 표 43과 같다.
표 43
Key 설명
logLevel 로그 레벨을 나타내는 것으로 다음 값들 중의 하나를 지정한다. OFF ERROR WARN INFO (default) DEBUG
serverHost 클라우드의 XDS/MHD 서버의 주소이다.
serverPort 클라우드의 XDS/MHD 서버의 포트번호이다.
workingDir 작업 디렉토리를 지정한다.
filenameFormat 다운로드할 문서들의 파일 이름을 지정하는 것으로 다음과 같은 키워드를 사용할 수 있다. %uid: 문서의 UID로 치환된다. %dttm: 문서의 생성일시로 치환된다. %seq: 자동으로 부여되는 일련번호로 치환된다.
retrieveSetCount 문서를 다운로드할 때의 묶음 크기를 나타낸다. 클수록 HTTP 오버헤드는 줄어들지만 너무 크면 버퍼 용량 초과로 다운로드 자체가 실패할 수 있다. 기본값은 1이다.
preprocessor 문서집합을 모두 다운로드한 후 전처리가 필요할 때 지정하는 것으로 다음과 같은 키워드를 사용할 수 있다. %inDocSetDir: 입력 문서집합의 폴더 이름으로 치환된다. %inDocSetPathList: 입력 문서집합 내에 포함된 모든 문서 파일들의 전체 경로명 리스트로 치환된다. %inDocSetFileList: 입력 문서집합 내에 포함된 모든 문서들의 파일 이름 리스트로 치환된다. %outDocSetDir: 출력 문서집합의 폴더 이름으로 치환된다.
processor 문서 또는 문서집합을 대상으로 호출되는 외부 처리기의 경로명 및 인자들을 지정하는 것으로 위의 preprocessor에서 지정된 키워드 이외에 다음과 같은 키워드를 추가로 사용할 수 있다. %inDocFile: 개별 입력 문서의 파일 이름으로 치환된다. %inJobDir: 필터 처리를 위해 2개 이상의 입력 문서집합이 필요한 경우 전체 작업 폴더의 이름으로 치환된다. %inJobPathList: 작업 폴더 내에 포함된 모든 입력 문서 파일들의 전체 경로명 리스트로 치환된다. %inJobFileList: 작업 폴더 내에 포함된 모든 입력 문서들의 파일 이름 리스트로 치환된다. %outDocFile: 개별 출력 문서 파일의 이름으로 치환된다. %outJobDir: 출력 작업 폴더의 이름으로 치환된다.
postprocessor 문서집합의 처리가 모두 완료된 후 후처리가 필요할 때 지정하는 것으로 사용할 수 있는 키워드는 preprocessor에서와 같다.
filterUID 필터의 UID를 지정한다.
UIDPrefix 메타데이터를 위해 생성되는 UID들을 위한 접두어를 의미한다.
groupIdType Group Id Type을 나타내는 것으로 특별한 사유가 없는 한 BIS-Cloud에서는 “BIS-CLOUD”를 사용하도록 한다.
docsetClassUID 생성된 문서집합들을 위한 클래스 UID 값을 의미한다.
docsetTitle 생성된 문서집합들에 대한 기본 제목이다.
docsetComments 생성된 문서집합들에 대한 기본 설명이다.
mimeType 생성된 문서를 업로드할 때 필요한 MIME 타입이다.
rename 작업에 사용된 문서들을 이동할지 삭제할지 지정한다. 이동하려면 true를, 삭제하려면 false를 지정한다. 기본값은 false(삭제)이다.
repeat 반복 여부를 지정한다. 기본값은 false(반복없음)이다.
repeatInterval 반복 주기를 지정한다. 예를 들어, 300(초)로 지정될 수 있다.
FilterProc은 workingDir로 지정된 폴더 아래에 표 47과 같은 구조로 작업 폴더를 생성한다. FilterProc은 작업 폴더의 내용들이 추후 삭제되도록 지정할 수 있다.
표 44
Folder / Filename 설명
{workingDir}/FJ-xxxx 입력 작업 폴더
{workingDir}/FJ-xxxx/output 출력 작업 폴더
{workingDir}/FJ-xxxx/DS-yyyy 입력 문서집합 폴더
{workingDir}/FJ-xxxx/DS-yyyy/output 출력 문서집합 폴더
{workingDir}/FJ-xxxx/DS-yyyy/zzzz 입력 문서 파일
{workingDir}/FJ-xxxx/DS-yyyy/zzzz.xml 입력 문서 메타데이터 (XDS Document Entry)
{workingDir}/FJ-xxxx/DS-yyyy/zzzz.output 출력 문서 파일
{workingDir}/FJ-xxxx/DS-yyyy/DS.xml 입력 문서집합 메타데이터 (XDS Submission Set)
제 4 단계로, 외부필터(650, 660)는 작업의 수행 결과를 클라우드(610)로 전송한다. 이때, 외부필터(650, 660)는 작업의 수행 결과인 문서집합을 클라우드(610)로 전송하기 전에, 아래의 표 45와 같은 Association 정보를 전송한다.
표 45
FilterProc.FilterResult IHE XDS/MHD
Auto-generated Association.uuid
Created XDSDocSet.docset_uuid 또는 XDSDocument.document_uuid Association.sourceObject
FilterJob.docsetList.subjobUUID= FilterQueueInput.filter_queue_input_uuid Association.targetObject
APND Association.associationType
“FilterJobStatus” Association.slotName
“SubmissionSet” 또는 “DocumentEntry” Association.slotValue
제 5 단계로, 외부필터(650, 660)는 작업의 수행을 완료한다. 본 발명의 일 실시예에 따른 클라우드(610)의 XDSServer는 보통의 DocumentEntry, SubmissionSet, Folder 및 Association 객체들을 데이터베이스에 저장하기 전에 Association.slotName=”FilterJobStatus”인 Association 들을 먼저 데이터베이스에 저장한다. 이때, Association.slotValue에 따라 XDSAssociation 테이블의 association_kind 컬럼 값이 결정된다. 그러면, XDSServer는 이러한 Association 객체의 속성들을 데이터베이스에 저장함과 동시에 최종적으로 FilterQueue_update() 함수를 호출하여 필터 작업 완료를 기록한다. 일 예는 아래의 표 46과 같다.
표 46
IHE XDS/MHD 클라우드 데이터베이스
Association.uuid XDSAssociation.association_uuid
Association.sourceObject= Created XDSDocSet.docset_uuid / XDSDocument.document_uuid XDSAssociation.source_uuid
Association.targetObject= FilterJob.docsetList.subjobUUID = FilterQueueInput.filter_queue_input_uuid XDSAssociation.target_uuid
Association.associationType= “APND” XDSAssociation.association_type
Association.slotName= “FilterJobStatus”
Association.slotValue = “SubmissionSet” = “DocumentEntry” XDSAssociation.association_kind JS (FilterJob - SubmissionSet) JD (FilterJob - Document)
HolterCDSS(650)는 클라우드(610) 내에 구현된 외부 필터의 하나로서 클라우드(610)로부터 라디오넷 홀터 파일을 다운로드한 후 CDSS(Clinical Decision Supporting System) 처리를 수행하도록 HolterExport.exe 또는 Holter.exe 프로그램을 수행한다. 그리고, HolterCDSS(650)는 프로그램의 수행 결과로 생성된 JPEG 형태의 자동진단 결과 파일들을 다시 클라우드(650)에 업로드하는 역할을 한다.
HolterCDSS(650)는 FilterProc에 기반하여 작성된 일괄처리 파일(batch file)로서, 구체적으로는 클라우드와 통신을 담당하는 FilterProc.jar 모듈 및 실제 CDSS 처리를 담당하는 HolterExport.exe 또는 Holter.exe 모듈로 구성된다.
본 발명의 일 실시예에 따른 HolterCDSS(650)의 구성 예 및 설정 예는 각각 아래의 표 47 및 표 48과 같다.
표 47 구성: HolterCDSS.bat
@ECHO OFFSET BIS_DIR=C:\OPHIESSET LIB_DIR=%BIS_DIR%\libSET CONFIG_FILE=%BIS_DIR%\bin\HolterCDSS.confjava -jar %LIB_DIR%\FilterProc.jar -conf %CONFIG_FILE% %1
표 48 설정 예제: HolterCDSS.conf
{ "FilterProc" : { "logLevel" : "INFO", "serverHost" : "54.238.177.162", "serverPort" : "8080", "workingDir" : "C:/OPHIES/work", "filenameFormat" : "%uid", "retrieveSetCount" : "3", "preprocessor" : "", "processor" : "\"C:\\Program Files\\RADIONET\\Holter\\Holter.exe\" -hrw2jpg %inDocFile %outJobDir", "postprocessor" : "", "filterUID" : "1.2.410.200054.4.2.1", "UIDPrefix" : "1.2.410.200054", "groupIdType" : "BIS-CLOUD", "docsetClassUID" : "1.2.410.200054.5.2.1", "docsetTitle" : "HolterExport Results", "docsetComments" : "%cmdline", "mimeType" : "image/jpeg", "rename" : "false", "repeat" : "true", "repeatInterval" : "60", }}
EventMerge(660)는 클라우드(610)를 위해 구현된 외부 필터의 하나로서, 클라우드(610) 내에 저장된 Event Recorder 신호 파일들을 다운로드한 후 이를 통합, 변환하여 Holter.exe 프로그램에 입력으로 전달한다.
EventMerge(660)는 FilterProc에 기반하여 작성된 일괄처리 파일(batch file)이며, 구체적으로는 Event Recorder 신호 파일들을 통합하기 위한 전처리기(preprocessor)인 EventBuild.jar와 실제 홀터 정보를 처리하는 Holter.exe로 구성되어 있다.
EventMerge(660) 수행을 위해서는 반드시 아래 예제에서와 같은 쿼리 파일을 생성하여 인자로 전달해 주어야 한다. 이때, queryType은 GetSubmissionSetAndContents로 지정하여야 하고, docsetUID에는 통합할 Event Recorder 파일들을 담고 있는 문서집합의 UID를 지정해 주어야 한다. 이러한 쿼리 파일들은 웹 브라우저(640)의 문서집합 리스트 상에서 다운로드하여 얻을 수 있다.
본 발명의 일 실시예에 따른 EventMerge(660)의 구성 예 및 설정 예는 각각 아래의 표 49 및 표 50과 같다.
표 49 구성: EventMerge.bat
@ECHO OFFSET BIS_DIR=D:\OPHIESSET LIB_DIR=%BIS_DIR%\libSET CONFIG_FILE=%BIS_DIR%\bin\EventMerge.confjava -jar %LIB_DIR%\FilterProc.jar -conf %CONFIG_FILE% %1
표 50 설정 예제: EventMerge.conf
{ "FilterProc" : { "logLevel" : "INFO", "serverHost" : "54.238.177.162", "serverPort" : "8080", "workingDir" : "D:/Temp", "filenameFormat" : "%dttm.raw", "retrieveSetCount" : "3", "preprocessor" : "java -jar D:/OPHIES/lib/EventBuild.jar %inDocSetDir", "processor" : "\"C:\\Program Files\\RADIONET\\Holter\\Holter.exe\" -evt %inDocSetDir", "rename" : "false", }}
도 7은 본 발명의 일 실시예에 따른 필터에 대한 정보를 생성하는 장치(700)의 일 예를 도시한 구성도이다.
도 7을 참조하면 필터에 대한 정보를 생성하는 장치(700)는 필터 클래스 설정부(710), 필터 설정부(720) 및 필터 조건 설정부(730)를 포함한다. 도 7에 도시된 장치(700)에는 본 실시예와 관련된 구성요소들만이 도시되어 있다. 따라서, 도 7에 도시된 구성요소들 외에 다른 범용적인 구성요소들이 더 포함될 수 있음을 본 실시예와 관련된 기술분야에서 통상의 지식을 가진 자라면 이해할 수 있다.
또한, 도 7에 도시된 장치(700)의 필터 클래스 설정부(710), 필터 설정부(720) 및 필터 조건 설정부(730)는 하나 또는 복수 개의 프로세서에 해당할 수 있다. 프로세서는 다수의 논리 게이트들의 어레이로 구현될 수도 있고, 범용적인 마이크로 프로세서와 이 마이크로 프로세서에서 실행될 수 있는 프로그램이 저장된 메모리의 조합으로 구현될 수도 있다. 또한, 다른 형태의 하드웨어로 구현될 수도 있음을 본 실시예가 속하는 기술분야에서 통상의 지식을 가진 자라면 이해할 수 있다.
또한, 도 7에 도시된 장치(700)는 도 1, 도 2, 도 5 및 도 6에 도시된 의료 정보 제공 시스템 또는 클라우드에 포함될 수 있다. 따라서, 이하에서 생략된 내용이라 하더라도 도 1, 도 2, 도 5 및 도 6에 도시된 의료 정보 제공 시스템 또는 클라우드에 관하여 이상에서 기술된 내용은 도 7의 장치(700)에도 적용됨을 알 수 있다.
필터 클래스 설정부(710)는 대상체의 의료 정보를 생성하기 위한 작업에 대응하는 적어도 하나 이상의 필터 클래스를 설정한다. 여기에서, 대상체는 환자를 의미할 수 있으나, 이에 제한되지 않는다. 필터 클래스는 필터의 클래스를 의미하며, 문서집합 클래스에 의해 입출력 형식을 표현한다. 하나의 필터 클래스는 다수의 필터에 대응될 수 있다. 즉, 동일한 입출력 형식 및 기능을 갖는 다양한 필터가 존재할 수 있다.
필터 설정부(720)는 필터 클래스에 포함되고, 작업을 수행하는 적어도 하나 이상의 필터를 설정한다. 여기에서, 필터의 종류에는 내부 필터 또는 외부 필터가 있다. 내부 필터는 클라우드의 데이터베이스 내에서 작업을 수행하는 필터를 의미하며, 하부 구조의 데이터베이스의 저장 함수(stored function)으로 구현될 수 있다. 한편, 외부 필터는 클라우드 데이터베이스 외부에서 작업을 수행하는 필터를 의미하며, 클라우드가 제공하는 API를 이용하여 구현될 수 있다.
필터(Filter)는 필터의 인스턴스(instance)를 나타내는 것으로 필터 클래스로 표현된 필터의 실제 인스턴스를 나타낸다. 동일한 필터 클래스 UID를 갖는 모든 필터들은 실질적으로 동일한 기능을 수행한다.
여기에서, 필터가 수행하는 작업은 적어도 하나 이상의 입력 컨텐츠를 적어도 하나 이상의 출력 컨텐츠로 변환하는 작업, 컨텐츠를 저장하는 작업, 컨텐츠를 다른 장치에 제공하는 작업, 컨텐츠를 생성하는 작업 중 어느 하나에 해당될 수 있다. 여기에서, 컨텐츠가 제공되는 다른 장치는 제공된 컨텐츠를 디스플레이하는 장치 등 컨텐츠를 다양한 방법으로 소비하는 장치를 의미한다.
컨텐츠는 텍스트, 이미지, 동영상을 포함하는 모든 종류의 문서(document)를 의미한다. 다시 말해, 컨텐츠는 영상(image), 파형(waveforms), 측정값(measured values) 등 일반적인 연산 장치에서 처리될 수 있는 모든 종류의 문서를 포함한다. 도 1 내지 도 6을 참조하여 상술한 내용에서는 컨텐츠를 문서와 동일한 개념으로 표현하였다.
조건 설정부(730)는 필터의 동작에 요구되는 적어도 하나 이상의 조건을 설정한다. 구체적으로, 조건 설정부(730)는 작업을 수행할 필터를 설정하고, 필터의 동작에 요구되는 정보 및/또는 필터가 동작을 수행하는 시점에 대응하는 시간 조건을 설정한다. 여기에서, 시간 조건은 필터에 정보가 입력되는 때에 필터가 동작을 수행하는 조건, 정보가 입력된 후 소정의 시간이 경과된 후에 필터가 동작을 수행하는 조건 및 정보가 입력된 익일 0 시를 기준으로 일정 시간이 경과된 경우에 필터가 동작을 수행하는 조건 중 어느 하나가 해당될 수 있다.
도 8은 본 발명의 일 실시예에 따른 필터에 대한 정보를 생성하는 방법의 일 예를 도시한 흐름도이다.
도 8을 참조하면, 필터에 대한 정보를 생성하는 방법은 도 1, 도 2, 도 5, 도 6 및 도 7에 도시된 의료 정보 제공 시스템, 클라우드 또는 필터에 대한 정보를 생성하는 장치(700)에서 시계열적으로 처리되는 단계들로 구성된다. 따라서, 이하에서 생략된 내용이라 하더라도 도 1, 도 2, 도 5, 도 6 및 도 7을 참조하여 이상에서 기술된 내용은 도 8의 필터에 대한 정보를 생성하는 방법에도 적용됨을 알 수 있다.
810 단계에서, 클라우드는 대상체의 의료 정보를 생성하기 위한 작업에 대응하는 적어도 하나 이상의 필터 클래스를 설정한다.
820 단계에서, 클라우드는 필터 클래스에 포함되고, 작업을 수행하는 적어도 하나 이상의 필터를 설정한다.
830 단계에서, 클라우드는 필터의 동작에 요구되는 적어도 하나 이상의 조건을 설정한다.
도 9는 본 발명의 일 실시예에 따른 대상체의 의료 정보를 생성하는 장치의 일 예를 나타내는 구성도이다.
도 9를 참조하면 대상체의 의료 정보를 생성하는 장치(900)는 인터페이스부(910), 필터 선택부(920) 및 복수의 내부 필터들(931, 932, 933)을 포함한다. 또한, 필터들 중 적어도 하나 이상은 장치(900)에 포함되지 않은 외부 필터(934)로 존재할 수 있다. 도 9에 도시된 장치(900)에는 본 실시예와 관련된 구성요소들만이 도시되어 있다. 따라서, 도 9에 도시된 구성요소들 외에 다른 범용적인 구성요소들이 더 포함될 수 있음을 본 실시예와 관련된 기술분야에서 통상의 지식을 가진 자라면 이해할 수 있다.
또한, 도 9에 도시된 장치(900)에 포함된 인터페이부(910), 필터 선택부(920)는 하나 또는 복수 개의 프로세서에 해당할 수 있다. 프로세서는 다수의 논리 게이트들의 어레이로 구현될 수도 있고, 범용적인 마이크로 프로세서와 이 마이크로 프로세서에서 실행될 수 있는 프로그램이 저장된 메모리의 조합으로 구현될 수도 있다. 또한, 다른 형태의 하드웨어로 구현될 수도 있음을 본 실시예가 속하는 기술분야에서 통상의 지식을 가진 자라면 이해할 수 있다.
또한, 도 9에 도시된 장치(900)는 도 1, 도 2, 도 5 및 도 6에 도시된 의료 정보 제공 시스템 또는 클라우드에 포함될 수 있다. 따라서, 이하에서 생략된 내용이라 하더라도 도 1, 도 2, 도 5 및 도 6에 도시된 의료 정보 제공 시스템 또는 클라우드에 관하여 이상에서 기술된 내용은 도 7의 장치(900)에도 적용됨을 알 수 있다.
인터페이스부(910)는 클라우드와 연결된 외부 장치들 중 적어도 어느 하나로부터 적어도 하나 이상의 컨텐츠를 수신한다. 여기에서, 컨텐츠는 텍스트, 이미지, 동영상을 포함하는 모든 종류의 문서(document)를 의미한다. 다시 말해, 컨텐츠는 영상(image), 파형(waveforms), 측정값(measured values) 등 일반적인 연산 장치에서 처리될 수 있는 모든 종류의 문서를 포함한다. 도 1 내지 도 6을 참조하여 상술한 내용에서는 컨텐츠를 문서와 동일한 개념으로 표현하였다.
필터 선택부(920)는 복수의 필터 클래스들 각각에 포함된 필터들 중에서 인터페이스부(910)가 수신한 컨텐츠에 기반하여 기 설정된 작업을 수행하는 필터를 선택한다. 여기에서, 필터 클래스는 필터의 클래스를 의미하며, 문서집합 클래스에 의해 입출력 형식을 표현한다. 하나의 필터 클래스는 다수의 필터에 대응될 수 있다. 즉, 동일한 입출력 형식 및 기능을 갖는 다양한 필터가 존재할 수 있다.
또한, 필터의 종류에는 내부 필터 또는 외부 필터가 있다. 내부 필터는 클라우드의 데이터베이스 내에서 작업을 수행하는 필터를 의미하며, 하부 구조의 데이터베이스의 저장 함수(stored function)으로 구현될 수 있다. 한편, 외부 필터는 클라우드 데이터베이스 외부에서 작업을 수행하는 필터를 의미하며, 클라우드가 제공하는 API를 이용하여 구현될 수 있다.
필터 선택부(920)에 의하여 선택된 필터가 수행하는 기 설정된 작업은 입력 컨텐츠가 출력 컨텐츠로 변환되는 작업, 클라우드와 연결된 장치들 중 적어도 어느 하나에 컨텐츠가 제공되는 작업, 서로 다른 두 컨텐츠들을 조합함으로써 새로운 컨텐츠를 생성하는 작업 및 컨텐츠를 저장하는 작업 중 어느 하나를 의미한다. 여기에서, 컨텐츠가 제공되는 장치는 제공된 컨텐츠를 디스플레이하는 장치 등 컨텐츠를 다양한 방법으로 소비하는 장치를 의미한다.
또한, 필터 선택부(920)는 복수의 필터 클래스들 각각에 포함된 필터들 중에서 기 설정된 작업의 수행 결과에 기반하여 작업을 수행하는 필터를 선택할 수 있다. 다시 말해, 도 4를 참조하여 전술한 워크플로우와 같이, 필터 선택부(920)는 일 필터에 의하여 작업이 수행된 결과를 이용하여 다른 작업을 수행하는 다른 필터를 선택할 수 있다.
한편, 내부 필터들(931, 932, 933) 및 외부 필터(934)들 각각은 필터의 동작에 요구되는 정보 및/또는 필터가 동작을 수행하는 시점에 대응하는 시간 조건이 설정된다. 여기에서, 시간 조건은 필터에 정보가 입력되는 때에 필터가 동작을 수행하는 조건, 정보가 입력된 후 소정의 시간이 경과된 후에 필터가 동작을 수행하는 조건 및 정보가 입력된 익일 0 시를 기준으로 일정 시간이 경과된 경우에 필터가 동작을 수행하는 조건 중 어느 하나가 해당될 수 있다.
도 10은 본 발명의 일 실시예에 따른 대상체의 의료 정보를 생성하는 방법의 일 예를 나타내는 흐름도이다.
도 10을 참조하면, 필터에 대한 정보를 생성하는 방법은 도 1, 도 2, 도 5, 도 6 및 도 9에 도시된 의료 정보 제공 시스템, 클라우드 또는 대상체의 의료 정보를 생성하는 장치(900)에서 시계열적으로 처리되는 단계들로 구성된다. 따라서, 이하에서 생략된 내용이라 하더라도 도 1, 도 2, 도 5, 도 6 및 도 9를 참조하여 이상에서 기술된 내용은 도 10의 대상체의 의료 정보를 생성하는 방법에도 적용됨을 알 수 있다.
1010 단계에서, 클라우드는 클라우드와 연결된 외부 장치들 중 적어도 어느 하나로부터 적어도 하나 이상의 컨텐츠를 수신한다.
1020 단계에서, 클라우드는 복수의 필터 클래스들 각각에 포함된 필터들 중 수신된 컨텐츠에 기반하여 작업을 수행하는 필터를 선택한다.
1030 단계에서, 선택된 필터는 기 설정된 작업을 수행한다.
한편, 상술한 방법은 컴퓨터에서 실행될 수 있는 프로그램으로 작성 가능하고, 컴퓨터로 읽을 수 있는 기록매체를 이용하여 상기 프로그램을 동작시키는 범용 디지털 컴퓨터에서 구현될 수 있다. 또한, 상술한 방법에서 사용된 데이터의 구조는 컴퓨터로 읽을 수 있는 기록매체에 여러 수단을 통하여 기록될 수 있다. 상기 컴퓨터로 읽을 수 있는 기록매체는 마그네틱 저장매체(예를 들면, 롬, 램, USB, 플로피 디스크, 하드 디스크 등), 광학적 판독 매체(예를 들면, 시디롬, 디브이디 등)와 같은 저장매체를 포함한다.
본 실시예와 관련된 기술 분야에서 통상의 지식을 가진 자는 상기된 기재의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 방법들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.

Claims (36)

  1. 대상체의 의료 정보를 생성하기 위한 작업에 대응하는 적어도 하나 이상의 필터 클래스를 설정하는 단계;
    상기 필터 클래스에 포함되고, 상기 작업을 수행하는 적어도 하나 이상의 필터를 설정하는 단계; 및
    상기 필터의 동작에 요구되는 적어도 하나 이상의 조건을 설정하는 단계;를 포함하는 필터에 대한 정보를 생성하는 방법.
  2. 제 1 항에 있어서,
    상기 작업은 적어도 하나 이상의 제 1 컨텐츠를 적어도 하나 이상의 제 2 컨텐츠로 변환하는 제 1 작업, 제 3 컨텐츠를 저장하는 제 2 작업, 제 4 컨텐츠를 다른 장치에 제공하는 제 3 작업, 제 5 컨텐츠를 생성하는 제 4 작업 중 어느 하나를 포함하는 방법.
  3. 제 2 항에 있어서,
    상기 컨텐츠는 텍스트, 이미지, 동영상, 파형 및 일반 문서 중 어느 하나를 포함하는 방법.
  4. 제 1 항에 있어서,
    상기 조건을 설정하는 단계는
    상기 작업을 수행할 상기 필터를 설정하는 단계; 및
    상기 필터의 동작에 요구되는 정보 및/또는 상기 필터가 상기 동작을 수행하는 시점에 대응하는 시간 조건을 설정하는 단계;를 포함하는 방법.
  5. 제 4 항에 있어서,
    상기 시간 조건은 상기 필터에 상기 필터의 동작에 요구되는 정보가 입력되는 경우 상기 동작이 수행되는 제 1 조건, 상기 필터의 동작에 요구되는 정보가 입력된 후 소정의 시간이 경과된 경우 상기 동작이 수행되는 제 2 조건 및 상기 필터의 동작에 요구되는 정보가 입력된 익일 0 시를 기준으로 소정의 시간이 경과된 경우 상기 동작이 수행되는 제 3 조건 중 어느 하나를 포함하는 방법.
  6. 제 1 항에 있어서,
    상기 필터는 상기 대상체의 의료 정보를 생성하는 클라우드의 내부에서 동작하는 내부 필터 또는 상기 클라우드와 연결된 외부 장치들 중 적어도 하나에서 동작하는 외부 필터인 방법.
  7. 제 6 항에 있어서,
    상기 외부 필터는 상기 클라우드로부터 상기 외부 필터에서 수행될 작업 리스트를 수신하고, 상기 작업 리스트에 포함된 적어도 하나 이상의 작업의 수행 결과를 상기 클라우드로 전송하는 필터인 방법.
  8. 제 7 항에 있어서,
    상기 작업 리스트는 상기 클라우드가 상기 외부 필터에서 수행될 작업을 생성하고, 상기 생성된 작업을 상기 클라우드가 데이터베이스에서 검색함으로써 구성되는 방법.
  9. 제 1 항의 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체.
  10. 대상체의 의료 정보를 생성하기 위한 작업에 대응하는 적어도 하나 이상의 필터 클래스를 설정하는 필터 클래스 설정부;
    상기 필터 클래스에 포함되고, 상기 작업을 수행하는 적어도 하나 이상의 필터를 설정하는 필터 설정부; 및
    상기 필터의 동작에 요구되는 적어도 하나 이상의 조건을 설정하는 필터 조건 설정부;를 포함하는 필터에 대한 정보를 생성하는 장치.
  11. 제 10 항에 있어서,
    상기 작업은 적어도 하나 이상의 제 1 컨텐츠를 적어도 하나 이상의 제 2 컨텐츠로 변환하는 제 1 작업, 제 3 컨텐츠를 저장하는 제 2 작업, 제 4 컨텐츠를 다른 장치에 제공하는 제 3 작업, 제 5 컨텐츠를 생성하는 제 4 작업 중 어느 하나를 포함하는 장치.
  12. 제 11 항에 있어서,
    상기 컨텐츠는 텍스트, 이미지, 동영상, 파형 및 일반 문서 중 어느 하나를 포함하는 방법.
  13. 제 10 항에 있어서,
    상기 필터 조건 설정부는
    상기 작업을 수행할 상기 필터를 설정하고, 상기 필터의 동작에 요구되는 정보 및/또는 상기 필터가 상기 동작을 수행하는 시점에 대응하는 시간 조건을 설정하는 장치.
  14. 제 13 항에 있어서,
    상기 시간 조건은 상기 필터에 상기 필터의 동작에 요구되는 정보가 입력되는 경우 상기 동작이 수행되는 제 1 조건, 상기 필터의 동작에 요구되는 정보가 입력된 후 소정의 시간이 경과된 경우 상기 동작이 수행되는 제 2 조건 및 상기 필터의 동작에 요구되는 정보가 입력된 익일 0 시를 기준으로 소정의 시간이 경과된 경우 상기 동작이 수행되는 제 3 조건 중 어느 하나를 포함하는 장치.
  15. 제 10 항에 있어서,
    상기 필터는 상기 대상체의 의료 정보를 생성하는 장치가 포함된 클라우드의 내부에서 동작하는 내부 필터 또는 상기 클라우드와 연결된 외부 장치들 중 적어도 하나에서 동작하는 외부 필터인 장치.
  16. 제 15 항에 있어서,
    상기 외부 필터는 상기 클라우드로부터 상기 외부 필터에서 수행될 작업 리스트를 수신하고, 상기 작업 리스트에 포함된 적어도 하나 이상의 작업의 수행 결과를 상기 클라우드로 전송하는 필터인 장치.
  17. 제 16 항에 있어서,
    상기 작업 리스트는 상기 클라우드가 상기 외부 필터에서 수행될 작업을 생성하고, 상기 생성된 작업을 상기 클라우드가 데이터베이스에서 검색함으로써 구성되는 장치.
  18. 대상체의 의료 정보를 생성하는 방법에 있어서,
    클라우드와 연결된 외부 장치들 중 적어도 어느 하나로부터 적어도 하나 이상의 제 1 컨텐츠를 수신하는 단계;
    복수의 필터 클래스들 각각에 포함된 필터들 중에서 상기 제 1 컨텐츠에 기반하여 작업을 수행하는 제 1 필터를 선택하는 단계; 및
    상기 제 1 필터에 의하여 기 설정된 작업을 수행하는 단계;를 포함하는 방법.
  19. 제 18 항에 있어서,
    상기 기 설정된 작업은 상기 제 1 컨텐츠가 제 2 컨텐츠로 변환되는 제 1 작업, 상기 클라우드와 연결된 장치들 중 적어도 어느 하나에 상기 제 1 컨텐츠가 제공되는 제 2 작업, 상기 제 1 컨텐츠와 제 3 컨텐츠를 조합함으로써 제 4 컨텐츠를 생성하는 제 3 작업 및 상기 제 1 컨텐츠를 저장하는 제 4 작업 중 어느 하나를 포함하는 방법.
  20. 제 19 항에 있어서,
    상기 제 1 컨텐츠 내지 제 4 컨텐츠는 텍스트, 이미지, 동영상, 파형 및 일반 문서 중 어느 하나인 방법.
  21. 제 18 항에 있어서,
    상기 복수의 필터 클래스들 각각에 포함된 필터들 중에서 상기 기 설정된 작업의 수행 결과에 기반하여 작업을 수행하는 제 2 필터를 선택하는 단계; 및
    상기 제 2 필터에 의하여 상기 제 2 필터에 기 설정된 작업을 수행하는 단계;를 더 포함하는 방법.
  22. 제 18 항에 있어서,
    상기 필터 클래스는 동일한 유형의 작업을 수행하는 필터들이 포함된 그룹을 의미하는 방법.
  23. 제 21 항에 있어서,
    상기 제 1 필터 및 상기 제 2 필터는 상기 제 1 필터 및 상기 제 2 필터 각각의 동작에 요구되는 정보 및/또는 상기 제 1 필터 및 상기 제 2 필터 각각이 상기 동작을 수행하는 시점에 대응하는 시간 조건이 설정된 필터인 방법.
  24. 제 21 항에 있어서,
    상기 제 1 필터 및 상기 제 2 필터 각각은 상기 클라우드의 내부에서 동작하는 내부 필터 또는 상기 외부 장치들 중 적어도 어느 하나에서 동작하는 외부 필터인 방법.
  25. 제 24 항에 있어서,
    상기 외부 필터는 상기 클라우드로부터 상기 외부 필터에서 수행될 작업 리스트를 수신하고, 상기 작업 리스트에 포함된 적어도 하나 이상의 작업의 수행 결과를 상기 클라우드로 전송하는 필터인 방법.
  26. 제 25 항에 있어서,
    상기 작업 리스트는 상기 클라우드가 상기 외부 필터에서 수행될 작업을 생성하고, 상기 생성된 작업을 상기 클라우드가 데이터베이스에서 검색함으로써 구성되는 방법.
  27. 제 18 항의 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체.
  28. 대상체의 의료 정보를 생성하는 클라우드 시스템에 포함된 장치에 있어서,
    상기 클라우드와 연결된 외부 장치들 중 적어도 어느 하나로부터 적어도 하나 이상의 제 1 컨텐츠를 수신하는 인터페이스부; 및
    복수의 필터 클래스들 각각에 포함된 필터들 중에서 상기 제 1 컨텐츠에 기반하여 기 설정된 작업을 수행하는 제 1 필터를 선택하는 필터 선택부;를 포함하는 장치.
  29. 제 28 항에 있어서,
    상기 기 설정된 작업은 상기 제 1 컨텐츠가 제 2 컨텐츠로 변환되는 제 1 작업, 상기 클라우드와 연결된 장치들 중 적어도 어느 하나에 상기 제 1 컨텐츠가 제공되는 제 2 작업, 상기 제 1 컨텐츠와 제 3 컨텐츠를 조합함으로써 제 4 컨텐츠를 생성하는 제 3 작업 및 상기 제 1 컨텐츠를 저장하는 제 4 작업 중 어느 하나를 포함하는 장치.
  30. 제 29 항에 있어서,
    상기 제 1 컨텐츠 내지 제 4 컨텐츠는 텍스트, 이미지, 동영상, 파형 및 일반 문서 중 어느 하나인 방법.
  31. 제 28 항에 있어서,
    상기 필터 선택부는 상기 복수의 필터 클래스들 각각에 포함된 필터들 중에서 상기 기 설정된 작업의 수행 결과에 기반하여 작업을 수행하는 제 2 필터를 선택하고,
    상기 제 2 필터는 상기 제 2 필터에 기 설정된 작업을 수행하는 장치.
  32. 제 28 항에 있어서,
    상기 필터 클래스는 동일한 유형의 작업을 수행하는 필터들이 포함된 그룹을 의미하는 장치.
  33. 제 31 항에 있어서,
    상기 제 1 필터 및 상기 제 2 필터는 상기 제 1 필터 및 상기 제 2 필터 각각의 동작에 요구되는 정보 및/또는 상기 제 1 필터 및 상기 제 2 필터 각각이 상기 동작을 수행하는 시점에 대응하는 시간 조건이 설정된 필터인 장치.
  34. 제 31 항에 있어서,
    상기 제 1 필터 및 상기 제 2 필터 각각은 상기 클라우드의 내부에서 동작하는 내부 필터 또는 상기 외부 장치들 중 적어도 어느 하나에서 동작하는 외부 필터인 장치.
  35. 제 34 항에 있어서,
    상기 외부 필터는 상기 클라우드로부터 상기 외부 필터에서 수행될 작업 리스트를 수신하고, 상기 작업 리스트에 포함된 적어도 하나 이상의 작업의 수행 결과를 상기 클라우드로 전송하는 필터인 장치.
  36. 제 35 항에 있어서,
    상기 작업 리스트는 상기 클라우드가 상기 외부 필터에서 수행될 작업을 생성하고, 상기 생성된 작업을 상기 클라우드가 데이터베이스에서 검색함으로써 구성되는 장치.
PCT/KR2015/001851 2014-03-10 2015-02-26 대상체의 의료 정보를 생성하는 방법 및 장치 WO2015137646A1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US15/111,830 US20160350485A1 (en) 2014-03-10 2015-02-26 Method and apparatus for generating medical information of object
US17/308,513 US11901075B2 (en) 2014-03-10 2021-05-05 Method and apparatus for generating medical information of object

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
KR10-2014-0027953 2014-03-10
KR20140027953 2014-03-10
KR10-2014-0109954 2014-08-22
KR10-2014-0109953 2014-08-22
KR1020140109953A KR101633911B1 (ko) 2014-03-10 2014-08-22 대상체의 의료 정보를 생성하는 방법 및 장치.
KR1020140109954A KR102382313B1 (ko) 2014-03-10 2014-08-22 대상체의 의료 정보를 생성하는 방법 및 장치.

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US15/111,830 A-371-Of-International US20160350485A1 (en) 2014-03-10 2015-02-26 Method and apparatus for generating medical information of object
US17/308,513 Division US11901075B2 (en) 2014-03-10 2021-05-05 Method and apparatus for generating medical information of object

Publications (1)

Publication Number Publication Date
WO2015137646A1 true WO2015137646A1 (ko) 2015-09-17

Family

ID=54072036

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2015/001851 WO2015137646A1 (ko) 2014-03-10 2015-02-26 대상체의 의료 정보를 생성하는 방법 및 장치

Country Status (1)

Country Link
WO (1) WO2015137646A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001290890A (ja) * 2000-04-04 2001-10-19 Terumo Corp 医療情報検索システム及びその制御方法、記憶媒体
JP2002083058A (ja) * 2000-09-06 2002-03-22 Yokogawa Electric Corp 広域医療情報システム
JP2004113730A (ja) * 2002-09-25 2004-04-15 Terarikon Inc コンピュータ読影支援システム
JP2010267042A (ja) * 2009-05-14 2010-11-25 Konica Minolta Medical & Graphic Inc 医療データ管理システム
JP2012226632A (ja) * 2011-04-21 2012-11-15 Seikatsu Kyodo Kumiai Coop Sapporo 患者情報提供サーバ、及び患者情報提供処理プログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001290890A (ja) * 2000-04-04 2001-10-19 Terumo Corp 医療情報検索システム及びその制御方法、記憶媒体
JP2002083058A (ja) * 2000-09-06 2002-03-22 Yokogawa Electric Corp 広域医療情報システム
JP2004113730A (ja) * 2002-09-25 2004-04-15 Terarikon Inc コンピュータ読影支援システム
JP2010267042A (ja) * 2009-05-14 2010-11-25 Konica Minolta Medical & Graphic Inc 医療データ管理システム
JP2012226632A (ja) * 2011-04-21 2012-11-15 Seikatsu Kyodo Kumiai Coop Sapporo 患者情報提供サーバ、及び患者情報提供処理プログラム

Similar Documents

Publication Publication Date Title
EP3563280B1 (en) Malware detection and content item recovery
WO2015041494A1 (ko) 무선 통신 시스템에서 어플리케이션 실행 방법 및 장치
WO2016171401A1 (ko) 공동 편집 문서를 공유하는 방법 및 장치
WO2014126335A1 (ko) 클라우드 컴퓨팅 기반의 데이터 관리 방법, 이를 위한 시스템 및 장치
WO2018016726A1 (en) Schedule management method and electronic device adapted to the same
WO2010147362A2 (en) Widget activation and communication method
WO2015174777A1 (ko) 단말 장치, 클라우드 장치, 단말 장치의 구동방법, 데이터 협업처리 방법 및 컴퓨터 판독가능 기록매체
WO2016032287A1 (en) Method for providing additional functions based on information
WO2016003219A1 (en) Electronic device and method for providing content on electronic device
WO2012124985A2 (en) Method and apparatus for synchronizing personal inforamtion
WO2018128432A1 (ko) 전자 장치 간 콘텐츠 공유 시스템 및 전자 장치의 콘텐츠 공유 방법
EP3539046A1 (en) Electronic device and method for managing data in electronic device
WO2016190680A1 (ko) 선박 데이터 통합 관리 방법 및 장치
US20060265762A1 (en) Server apparatus and control method
WO2015147599A1 (en) Data sharing method and electronic device thereof
WO2021141441A1 (ko) 스크래핑 기반 서비스 제공 방법 및 이를 수행하는 어플리케이션
WO2013027879A1 (en) Content device and control method thereof
WO2015137646A1 (ko) 대상체의 의료 정보를 생성하는 방법 및 장치
WO2020149655A1 (ko) 장치 속성에 기반한 공유 데이터의 제공 방법 및 그 전자 장치
WO2019245247A1 (en) Method for object management using trace identifier, apparatus for the same, computer program for the same, and recording medium storing computer program thereof
WO2016117818A1 (ko) 효율적인 리타겟팅을 제공하는 방법 및 장치
KR101945993B1 (ko) 대상체의 의료 정보를 생성하는 방법 및 장치.
Wollatz et al. Curation of image data for medical research
JP6617456B2 (ja) 情報処理システム、情報処理装置、及びプログラム
WO2022004906A1 (ko) 환자 트랜스퍼 중개 서비스 제공장치 및 방법

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: 15761476

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15111830

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15761476

Country of ref document: EP

Kind code of ref document: A1