WO2015043640A1 - Verfahren und system zur verwaltung und bearbeitung von daten einer medizinischen einrichtung - Google Patents

Verfahren und system zur verwaltung und bearbeitung von daten einer medizinischen einrichtung Download PDF

Info

Publication number
WO2015043640A1
WO2015043640A1 PCT/EP2013/070097 EP2013070097W WO2015043640A1 WO 2015043640 A1 WO2015043640 A1 WO 2015043640A1 EP 2013070097 W EP2013070097 W EP 2013070097W WO 2015043640 A1 WO2015043640 A1 WO 2015043640A1
Authority
WO
WIPO (PCT)
Prior art keywords
memory area
data
application
cloud
app
Prior art date
Application number
PCT/EP2013/070097
Other languages
English (en)
French (fr)
Inventor
Karlheinz Dorn
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to US15/025,216 priority Critical patent/US11404160B2/en
Priority to PCT/EP2013/070097 priority patent/WO2015043640A1/de
Priority to CN201380079894.1A priority patent/CN105593859B/zh
Publication of WO2015043640A1 publication Critical patent/WO2015043640A1/de

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/248—Presentation of query results
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/50—Information retrieval; Database structures therefor; File system structures therefor of still image data
    • G06F16/51—Indexing; Data structures therefor; Storage structures
    • 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
    • G16H30/00—ICT specially adapted for the handling or processing of medical images
    • G16H30/40—ICT specially adapted for the handling or processing of medical images for processing medical images, e.g. editing
    • 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

  • the invention relates to a method for managing and processing data of a medical facility.
  • the invention further relates to a system for carrying out this method.
  • administration is here and below, in particular the archiving of the data (that is, the setting of the data in a persistent data storage), the playback (display) and the deletion of the data from the data memory and the sorting and finding certain Data from the data store according to predetermined criteria (browsing) understood.
  • processing is understood here and below to mean in particular the modification (editing / editing) of the data.
  • the medical institution's data to be managed and processed include, in particular, patient data, tasks (tasks) or task lists (worklists) for the patient
  • An information system includes regularly
  • SAN storage area network
  • a relational database implemented in a database server, and, as a rule, one or more additional servers in which methods for database access and data processing are implemented.
  • Different information systems have become established in the medical field for the different types of data.
  • a hospital information system (HIS) for the administration and processing of patient data
  • RIS radiology information system
  • a medical facility such as a hospital
  • the IT structure of a hospital generally comprises a so-called “Picture Archiving and Communication System” (PACS) for archiving and transmitting medical image data based on the DICOM standard as well as an “Avanced Visualization (AV) System”, which provides server-based functions for the visualization of volume data, in particular dynamic volume rendering.
  • PACS Picture Archiving and Communication System
  • AV Advanced Visualization
  • the server systems described above are generally present parallel to one another. This requires a high procurement and maintenance costs, which is difficult to manage especially for small medical facilities or other institution with relatively small financial volume.
  • PCs per- Computer
  • a “cloud” (“computer cloud”) is understood to be a data processing device that is made available and operated by a cloud operator ("cloud vendor”) independent of the user Hardware and, if applicable, the software of the Cloud as a service under a subscription (subscription) as a service.
  • cloud vendor a cloud operator
  • the software of the Cloud as a service under a subscription (subscription) as a service.
  • IaaS infrastructure as a Service
  • Cloud is made available while the user is fully responsible for the software operated in the cloud
  • PaaS Platform as a Service
  • Computer hardware is offered together with a programming and runtime environment based thereon, so that the user is responsible for the application software (applications) implemented in this programming and runtime environment, as well as
  • SaaS Software as a Service
  • multi-tenant This refers to the ability to keep data, user management and computational operations strictly separate for users with different subscriptions. Thus, a user of the public cloud can not look into the data, user management and arithmetic operations of another user with different subscriptions nor influence these data.
  • the invention has for its object to provide a method and a system for the management and processing of data of a medical device, which is particularly flexible, especially scalable.
  • a cloud storage ie the persistent storage
  • the data records stored in the respective storage area are stored in such a way that immediate access is provided to these records from the Internet.
  • lent is if there is a subscription associated with the memory area (ie if the accessing device is authorized to access in accordance with the subscription).
  • This access option is designed in particular such that it is compatible with the Internet standard REST.
  • REST Representational State Transfer
  • Each offered service is a unique address
  • the service accessible under an address can have different manifestations (representations).
  • a stateless client-server protocol is used, which allows different requests between clients and servers to be handled independently of each other.
  • the representation is preferably carried out according to the Internet standards XML (Extensible Markup Language), JSON (Java Script Object Notation) and / or ATOM.
  • ATOM is used here as an umbrella term for the Atom Syndication Format (ASF), which is an XML format for exchanging messages, and the ATOM Publishing Protocol (APP), which is a programming interface for creating and editing Web content.
  • ASF Atom Syndication Format
  • APP ATOM Publishing Protocol
  • the medical facility which is each assigned a subscription, is a clinic in the primarily intended use case. However, within the scope of the invention it is also conceivable that smaller units such as doctor's offices, individual departments of a clinic or even individual patients can acquire their own subscription for the administration of their own medical data and thus fully benefit from the method or system.
  • the system is "multi-tenant" through the use of the public cloud in the sense explained above Data, user management and arithmetic operations are thus kept strictly separate from each other for users with different subscriptions, so that an insight into or an influence on Data of external subscriptions is excluded.
  • an application for execution on a user or terminal device (hereinafter referred to as “device") is furthermore provided for each memory area, which is used for retrieving and / or displaying the data records contained in the associated memory area is set up.
  • Each application is assigned to one of the memory areas specifically and thus selectively and exclusively implements those functions for the management and processing of the records contained in the respective memory area.
  • the various types of data of the device include in particular
  • Patient data that includes personal and medical information about a particular patient of the institution, in particular details of the name, address, age, sex, previous diagnoses and treatments,
  • task / tasks tasks / tasks
  • task lists worklists
  • medical image data in particular two-dimensional images, two-dimensional image sequences (videos), volume data (for example computer tomograms) and / or temporal volume data sequences (4D data), but also key images,
  • Contextual information on medical image data in particular references to the storage location of image data records as well as optionally metadata to image data records such as e.g. the recording parameters underlying the respective image acquisition.
  • a "keyimage” is a snapshot, ie a section (processed or unprocessed) from a medical image or volume data set that is derived when this data is displayed in order to depict a medical finding. These key images are typically part of a medical image Report (reports) used.
  • the storage area of the cloud storage allocated to this resource is also referred to below as the “(resource) hub”.
  • the method and system preferably provide at least two of the (resource) hubs listed below in the cloud storage:
  • a patient memory area in which each (patient) record contains patient data of a particular patient
  • a task list memory area in which each record contains a task (work / task) or task list (worklist)
  • each (image) data set contains medical image or volume data or any other image, sound, graphics or text information (photos, videos, documents) and / or
  • each context record contains context information about an image data set, in particular a reference to the storage location of the respective image data record in the image hub and optionally metadata to the image data record.
  • each of the hubs described above is autonomously operable together with the application specifically assigned to it (ie, independently of the other hubs and their respective associated applications). Thus, none of the hubs described above and the associated applications for carrying out the method according to the invention or in the context of the inventive system is absolutely necessary. However, each of the hubs described above, together with the associated application, advantageously expands the functionality of the method or system.
  • the invention is based on the consideration that, for reasons of improved scalability for data management and processing in a medical device, a change from a classic client-server solution to a cloud-based solution makes sense. It is recognized that the problems described in the introduction are not solved satisfactorily by merely transferring the classically customary server systems to the cloud.
  • the relocation of the server, which is conventionally used in a medical facility, into the cloud does not simplify the complexity of the IT structure, but rather increases it, especially since the servers in a cloud are regularly operated in virtualized form, and thus to the unchanged complex server structure nor the virtualization software would be added.
  • it would be recognized that such a solution would incur high costs for cloud-based server performance, which would largely outweigh the benefits of using the cloud.
  • the servers operated virtualized in the cloud would still have to be administrated by the device itself, so that the associated effort would remain. Also in terms of scalability and reliability, such a solution would bring no significant improvement.
  • the medical facility benefits from the usual advantages of public cloud storage, namely almost unlimited scalability (ie the ability to efficiently handle almost any amount of data without qualitative changes to the IT structure worldwide availability of the data, extremely high security against failure and manipulation as well as an almost complete reduction of the in-house procurement and maintenance costs.
  • the invention provides a completely deviating from the usual in the medical field IT structure, which makes it possible to use the benefits of a public cloud over a conventional client-server solution efficiently, without having to accept significant disadvantages in purchasing.
  • the public cloud is preferably the "Windows Azure” service of Microsoft, but other public clouds can also be used within the scope of the invention, In particular, several Publics Clouds of possibly different “Cloud Vendors” can be managed simultaneously (simultaneously) the data of the institution.
  • the devices of the device involved in the implementation of the method can be of any composition for desktop PCs, but also for mobile devices such as notebooks.
  • the applications are configured to directly access the data sets contained in the respectively assigned hub. Additionally or alternatively, the applications are preferably set up to directly generate, edit and delete the data records contained in the respectively assigned hub.
  • the term "immediate” is used here and below in each case in the sense that the application executes the respective action independently under the exclusive use of cloud storage, without this - independent of the pure memory management (cloud storage) - computing power of the public cloud
  • At least one of the applications can be operated in two operating modes within the scope of the invention, namely
  • This - optionally switchable - cloud service mode is provided in particular in a so-called 3D viewing application, which is used for - particularly rchen elaboratesintensiven - representation of rendered views (scenes) of volume data.
  • the computing power is offered by the cloud vendor, in particular within the framework of a PaaS usage scheme, so that no separate administration costs are incurred for the operating system, drivers, an application server (app store) and the like.
  • the selection between the device-only mode and the cloud service mode is performed either automatically by the application (for example, depending on the quality of the network connection and / or the computing capacity of the device), - is determined interactively by the medical user, or
  • a table storage is created within at least one hub.
  • This is understood to mean a form of data storage offered by default, for example as part of the Windows Azure service from Microsoft, in which data entities are structured in a structured manner as table entries together with an index variable which uniquely identifies each data unit.
  • this index variable is composed of a so-called partition key and a so-called row key.
  • the partition key designates a physical partition of the cloud storage in which the respective table entry is stored so that table entries with different PartitionKey are stored in different physical partitions.
  • each of the records stored in each hub is associated with a table entry (hereafter referred to as "tweet")
  • each tweet may contain the associated record itself, so preferably each set of patient data of the patient hub is preferably a tweet of
  • the data set itself is stored outside the table (outside of a table storage), for example in a so-called blob storage (cloud storage) of the cloud Sto rage.
  • the tweet assigned to the data record contains an indication of the table-external storage location, for example in the form of a so-called "Uniform Resource Identifier" (URI) .
  • URI Uniform Resource Identifier
  • certain data blocks of a data record can be stored in the table memory as part of the tweet.
  • the actual image data is expediently stored in a blob storage of the image hub, while the associated metadata (eg, recording parameters and information about the patient) is stored within the context of the associated image data
  • Context information is stored in the table storage of the Context Hub as a blob storage, as it is also available in the context of "Windows Azure".
  • Service of the company Mircosoft is called a form of data storage, in which an unstructured storage of records occurs.
  • the content of the table memory can be searched directly by the application assigned to the hub (without the use of computing power of the public cloud, ie cloud computing services).
  • the application assigned to the hub without the use of computing power of the public cloud, ie cloud computing services.
  • selected tweets are extracted in the form of a result list, which is displayed by the application.
  • Such a result list is referred to below as "feed”.
  • the method is "externalized" by at least one of the applications of the feed extracted from the associated hub by the corresponding hub, that is to say from the public cloud storage into a local area. downloaded memory of the device, so that this feed and the tweets contained therein can be displayed by the application even without network connection to the public cloud, edited and / or transmitted to another instance of the same or another application.
  • This exchange mechanism (also referred to as "Exchangeboard”) enables particularly effective and flexible communication between different application instances, which in turn manages without the computing power of the public cloud, ie cloud computing services -Hub assigned to the URI of an image to be viewed, and to a separate viewing application of the same
  • Image Hub are transmitted so that the viewing application can then independently access the image searched for by the URI.
  • This exchange can also take place without difficulty between different devices, for example by sending the tweet associated with the image data record or the URI contained therein by email, instant message or Twitter.
  • modalities of the medical device are also enhanced for direct communication with the cloud storage.
  • a data record containing patient-specific image data is thus generated by a medical modality and stored directly in the allocated memory area (in particular the image hub) of the cloud storage.
  • This functionality for direct communication with the public cloud storage is implemented in particular in a storage driver, which is made available to the control software of the modality in the context of a user programming interface (API).
  • the storage driver can be integrated directly into the control software of the respective modality.
  • the storage driver forms an independent program component to which the control software of the modality accesses in the manner of a printer driver.
  • the system according to the invention for the administration and processing of data of a medical device is set up in circuit or program technology for carrying out the method described above.
  • it comprises at least two (resource) hubs of the previously described
  • a way of storing at least two resources ie, two different types of medical records
  • each hub being assigned exclusively to the records of a particular resource.
  • the data are stored in the respective hub in such a way that these data can be accessed directly from the Internet if a subscription assigned to the hub is present.
  • Each hub is assigned at least one application that is set up selectively for retrieving and displaying the data records contained in the associated hub.
  • the system according to the invention additionally comprises the cloud storage, which is a hardware storage with a cloud-internal management software running on it, and at least one device connected to the public Cloud storage is connected via the Internet.
  • the device is in particular a personal computer (PC), a notebook, a tablet computer or a smartphone.
  • FIG. 1 shows a schematic block diagram of a system for managing and processing data of a medical device, with a plurality of modalities and user or terminal devices (devices) and with a public cloud connected to the modalities and devices via the Internet
  • FIG schematic block diagram of the software architecture of the system according to which the system for each type of data of the medical device in a cloud storage of the public cloud each specifically assigned storage areas (hubs) has, namely a patient hub for
  • Image data sets is set up, in a schematic representation of a page of a user interface to a sequence on a
  • Smartphone provided application that is used to display a feed of each associated hub, in representation of FIG 3, another page of the user interface of the local application, which serves to display a tweet of the associated hub, in representation of FIG 3, a side of the user interface of the Associated with Image Hub applications, which is used to display the image information of an image data set, in representation of FIG 3 for running on a personal computer, notebook or tablet computer provided variant of the local application in which multiple pages of the user interface can be displayed simultaneously and in representation according to FIG. 6, a further side of the user interface which serves to display the image information of an image data record, in a schematic block diagram an alternative embodiment of the system, in which the viewing application assigned to the image hub has separate modules for displaying 2D image dataand volume data contains, in representation according to FIG. 8, a further embodiment of the system, the image hub being assigned two independent applications, namely a 2D viewing application for displaying
  • 2D images and a 3D viewing application for the visual display of volume data shows a further embodiment of the system in which a modality is equipped with a storage driver for the direct loading of image data into the image hub of the cloud storage.
  • FIG. 1 shows a schematic schematic simplification of a system 1 for the administration and processing of medical data of a medical device 2, which is, for example, a clinic.
  • the system 1 comprises a number of modalities 3, ie imaging, medical examination devices of the device 2.
  • the system 1 in the exemplary illustration according to FIG. 1 comprises a computer tomograph 4, a C-arm device 5 and a magnetic resonance tomograph 6.
  • Each modality 3 is assigned a (control and evaluation) computer 7.
  • the system 1 comprises on the hardware side a number of user or terminal devices (hereinafter devices 8) of the device 2, which serve to display and process data.
  • the devices 8 comprise a personal computer 9 with a connected screen 10, a tablet computer 11 and a smartphone 12.
  • the system 1 comprises a public cloud 13.
  • a public cloud 13 In the context of system 1, for example, the service offered by the company Microsoft under the name "Windows Azure" is used, but in the context of the invention, another public cloud or a combination of several public clouds (possibly also from different providers) may be used. be used as a public cloud 13.
  • the public cloud 13 is connected via a (data transmission) network 14 to the device-internal components of the system 1, that is to say the modalities 3 and devices 8.
  • This network connection is formed within the device 2 by an intranet 15 of the device 2, which is constructed, for example, as a so-called Local Area Network (LAN) based on wired Ethernet technology and / or as a wireless wireless local area network (WLAN).
  • LAN Local Area Network
  • WLAN wireless wireless local area network
  • the services provided by the public cloud 13 in the context of the system 1 are defined by a subscription contract 18.
  • the subscription 18 regulates which hardware and software components of the public cloud 13 are accessible to the device-internal components of the system 1.
  • the term subscription 18 is therefore used hereinafter to designate that part of the public cloud 13 which is assigned exclusively to the device 2 in the context of the system 1.
  • Other areas of the public cloud 13 can-as indicated in FIG. 1-be assigned within the scope of further subscriptions 18 'to further medical facilities 2'.
  • Each device 2, 2 ' has exclusive access to the data and services assigned to it according to its subscription 18, 18', but not to the data and services of other devices 2 or 2 '.
  • the public cloud 13 is in this sense "multi-tenant".
  • the system 1 of the device 2 is within the public cloud 13
  • cloud storage 19 a data storage referred to below as cloud storage 19,
  • App Store 20 An hereinafter referred to as App Store 20 designated memory for applications (application software) and
  • the cloud storage 19 is used for the persistent storage of the data of the device 2.
  • the App Store 20 provides applications, drivers and other peripheral software such as configuration files and templates that are available from the device-internal components of the system 1, ie the modalities 3 and the devices 8 can be downloaded and run during operation of the system 1 on the modalities 3 (more precisely, the associated computers 7) or on the devices 8.
  • the App Store 20 provides applications, drivers and other peripheral software such as configuration files and templates that are available from the device-internal components of the system 1, ie the modalities 3 and the devices 8 can be downloaded and run during operation of the system 1 on the modalities 3 (more precisely, the associated computers 7) or on the devices 8.
  • cloud compute services 21 are only optionally used for all arithmetic operations which are not performed on the modalities 3 or the devices 8 themselves.
  • the latter relates in particular to the computation-intensive processing of 3D image data (volume data) of the respective modality 3 for the storage (preprocessing) and / or the derivation of rendered views V (scenes or scene graphs) for the two-dimensional visualization (image synthesis, Volume Rendering) of such volume data.
  • the data to be managed and processed in the context of the device 2 comprise patient data sets P, tasks W, context data sets C and image data sets B, these data having in each case the contents explained in detail above.
  • Image datasets B can contain medical image data or volume data or any other image, sound, graphic or text information (photos, videos, documents).
  • a separate memory area is created for each of these different types of data (resources) within the cloud storage 19, which is referred to below as the (resource) hub.
  • the cloud storage 19 are thus
  • a (patient) hub 22 for storing the patient data sets P
  • a worklist hub 23 for storing tasks W
  • a (context) hub 24 for storing the context records C and
  • An (image) hub 25 for storing the image data sets B created.
  • Each of the hubs 22-24 each contains a table memory (hereinafter referred to as table storage 26).
  • table storage 26 As part of the system 1, a table entry is created for each stored data record in the table storage 26 of the respective associated hub 22-24, which is referred to below as Tweet 27.
  • Tweet 27 In the case of data records which by their nature consist of comparatively few, discrete indications, the entire data record is stored as Tweet 27 in the table storage 26 of the respective hub 22-24.
  • this relates to the patient data sets P, the tasks W, and the context data sets C.
  • the worklist hub 23 can store the tasks W according to a first-in-first-out principle also have a so-called queue storage.
  • a so-called blob storage 28 is provided in the image hub 25 instead of a table storage 26.
  • a context data record C in the form of a tweet 27 is respectively stored in the context hub 24.
  • This Tweet 27 contains at least one URI 29 (Uniform Resource Identifier), which designates the storage location of the image data record B in the blob storage 28 of the image hub 25.
  • URI 29 Uniform Resource Identifier
  • an application 31-34 is made available in the App Store 20, each of which is selectively available for displaying and processing the data assigned to it. Hub 22-25 stored records is used. Each of the applications 31-34 thus represents the associated hub 22-25 at the level of the device 8. The applications 31-34 are therefore - in accordance with the resource hubs - also referred to as "application hubs".
  • the applications made available in the App Store 20 thus include an application 31 for the administration and processing of the patient data sets P stored in the patient hub 22,
  • an application 34 for displaying and processing the image data sets B stored in the image hub 25 The applications 31-34 can be downloaded from the App Store 20 to each of the devices 8 and executed there. If the system 1 comprises different types of devices (eg personal computer 9, tablet computer 11 and / or smartphones 12), as shown in FIG. 1, different versions of the applications 31-34 are respectively opened in the app store 20 provided, which are adapted to the process on the respective device 8.
  • devices eg personal computer 9, tablet computer 11 and / or smartphones 12
  • the applications 31-34 are provided for execution on the tablet computer 11 and the smartphone 12 in the form of an app adapted to the respective device type, while the versions of the applications 31-34 provided for the personal computer 9 are available for the process is designed in an internet browser.
  • the patient hub 22 and the associated application 31 from the point of view of the user about the function of a conventional hospital information system (HIS).
  • the entire personal (and data protection relevant) patient data is recorded in the patient hub 22, which thus represents an electronic patient record for the individual patient.
  • the remaining hubs 23-25 preferably contain no information that could be assigned to a specific patient (privacy information).
  • the worklist hub 23 and the associated application 32 essentially present themselves to the user as a correspondence to a conventional radiology information system (RIS) by listing the tasks to be performed within the device 1 for execution.
  • RIS radiology information system
  • the context hub 24 and the associated application 33 perform the function of a conventional PACS by storing and retrieving the information required for the retrieval and processing of image data sets B.
  • the image hub 25 and the associated application 34 finally take over the function of a conventional AV system.
  • each of the hubs 22-25 together with the respective associated application 31-34 is independent of the respective other hubs 22-25 and their Applications 31-34 operable.
  • an image data record B contained in the image hub 25 can also be accessed without the associated context data record C of the context hub 24 if the application 34 associated with the image hub 25 makes the URI 29 of the image data record B to be displayed available in another way is, for example by e-mail, SMS or Twitter.
  • the patient data P can also be kept outside the public cloud 13 since the patient hub 22 is not required for the function of the remaining hubs 23-25 and the associated applications 32-34.
  • a core element of the application 31 assigned to the patient hub 22 is a so-called browsing function, which le storage 26 of the patient hub 22 searches for tweets 27 corresponding to a particular user-definable search term.
  • a result list which is subsequently referred to as feed 35 and contains the tweets 27 corresponding to the search query Q is returned to the application 31 in response to a query Q (FIG.
  • the application 31 displays the feed 35 obtained on the device 8 on a page 36 of a graphical user interface 37 shown by way of example in FIG.
  • the page 36 essentially has four display areas of different functions, namely a header 40, a search field 41, a display field 42 and a command bar 43.
  • the hub 22-24 is named by name the application 31 is assigned.
  • the header 40 is thus e.g.
  • header 2 is preferably designated as device 2 to which system 1 is assigned.
  • the search field 41 contains an input line 44, via which an alphanumeric search term can be entered, and a button 45, by means of which a user can start a search query Q on the basis of the search term previously entered in the input line 44.
  • the search field 41 contains a preselection field 46, via which one or more preset search terms can be selected by tapping (in the case of a touch-sensitive screen) or clicking with an optionally present pointer device.
  • the search terms that can be generated via the preselection field 46 are, in particular, frequently used search schemes.
  • the pre-selection field 46 allows a preselection as to whether - all tweets 27 ("all") or
  • the display 42 shows the feed 35 returned on the basis of a search query Q.
  • the display field 42 thus contains in the form of a list those tweets 27 which were found in the patient hub 22 on the basis of the search query Q of the application 31 For example, a reduced image 47 and / or a keyword 48 are displayed.
  • a reduced image of the patient as well as the name of the patient and optionally a patient identification number are preferably displayed for each displayed tweet 27.
  • the search query Q, and the feed 35 returned therefrom, may be interactively changed by a user.
  • the search is defined based on a syntax according to REST or OData (Open Data Protocol Standard). It is basically similar to a SQL standard WHERE clause, but unlike the latter, it does not rely on static reindexing. In particular, the tables of a hub do not require any index elements for the search, which is why no re-indexing is required, and correspondingly, no own data servers or database servers must be provided.
  • the command bar 43 contains a number of buttons 49 and 50, by the actuation of which user can perform elementary operations for controlling the user interface 37 and for managing and editing the displayed feed 35.
  • the application 31 is optimized in the version shown in FIG. 3 for display on the smartphone 12. In this case, only one single page 36 with a single feed 35 is displayed on the smartphone 12 at any time. However, multiple instances of page 36 or more
  • Instances of the entire application 31 are generated in parallel to each other, these instances are running concurrently on the smartphone 12 in the background of the display. Thus, in particular several search requests Q can be processed in parallel to each other.
  • the application 31 or optionally several instances of the application 31 preferably run in a generic frame module 51 (or container).
  • This frame module 51 can be implemented, for example, as a separate application or as a plug-in to a web browser. Alternatively, however, the application 31 may also be configured for immediate operation in a web browser, e.g. as an HTML5 application.
  • buttons 50 of the command bar 43 in this case allow a change between the running instances of the application 31 by hiding the displayed page 36 of the user interface 37 upon actuation of one of the buttons 50 and the corresponding page 36 of another instance of the application 31 is displayed.
  • buttons 49 of the command line 43 are assigned in particular to the following functions: "Create”: Upon actuation of the corresponding button 49, a new page 36 of the user interface 37, possibly together with a new instance of the application 31, is generated.
  • a further page 52 of the user interface 37 is opened, in which the data content of the selected tweet 27 is displayed for the purpose of mere viewing or modification also four areas, namely a header 60, a header field 61, a display panel 62 and a command bar 63.
  • the header 60 has - in analogy to the header 40 of page 36 - the associated hub 22-24 and the device 2 from.
  • the header field 61 identifies the type of the displayed data record and thus contains in the case of the application 31, for example, the word "patient” (or "patient entity").
  • the display field 62 the content of the selected Tweets 27 - in the case of the application 31 thus the content of the (patient) record - is displayed.
  • the field names 67 of the patient record for example “first name”, “last name”, “patient ID”, “age”, etc.
  • the display field 62 68 for example, the concrete first name, last name, the specific patient ID or the specific age of the patient shown.
  • the command line 63 contains buttons 64, which in particular are assigned the following functions: "Create”: Upon actuation of the corresponding button 64, a new instance of the page 52 is created to create a new tweet 27 and thus a new (patient) record P.
  • command line 63 includes a button 65, upon the actuation of which the application 31 closes the displayed page 52 without changing the tweet 27 and displays the underlying page 36 again.
  • the command lines 43 and 63 may have additional buttons for commands. Likewise, one or more of the functions described with reference to the buttons 49, 50, 64 and 65 can also be assigned to one of the optionally present electromechanical keys of the smartphone 12. The respective button is preferably removed from the command line 43 in this case.
  • the applications 32 and 33 each have a browsing function corresponding to the application 31.
  • the respective user interface 37 of the applications 32 and 33 also has the sides 36 and 52 described with reference to FIGS. 3 and 4.
  • the applications 32 and 33 access the
  • the tweets 27 displayed in the context of the application 33 contain the content of a context record C in each case, in particular information on the document type, storage location, data format and optionally acquisition parameters for an image data record B.
  • the application 34 serves to display ("view") the non-alphanumeric content of an image data set B stored in the image hub 25.
  • the graphical user interface 37 of the application 34 comprises a page 69 shown in FIG. 5.
  • page 69 also contains a header 70, a header field 71, a display field 72 and a command line 73.
  • the type of displayed image data record B is specified here (eg as "2D viewing”, 3D viewing ",” Media-Viewing ",” Document-Viewing ", etc.).
  • the display field 72 the visual content of the image data set B, so for example, the image, volume, video or text document displayed.
  • the command line 73 contains, in addition to the button 65, further buttons 74 for influencing the display, for example for enlarging or reducing the data content displayed in the display field 72, or for shifting a displayed image section.
  • a button 74 may be provided for deleting an image data set B.
  • the application 33 may also include various viewing pages, each of which is adapted to display a particular type of document (image, volume, video, text document, etc.).
  • the application 34 can be operated in two operating modes, namely in
  • the application 34 accesses the image data sets B stored in the blob storage 28 of the image hub 25 directly.
  • the image data B is processed by cloud computing services 21, with only the resulting two-dimensional views V being delivered from the cloud 13 to the application 34.
  • the application 34 works from scratch in the cloud service mode and only switches to the device-only mode when the network connection with the public cloud 13 falls below a predetermined minimum quality.
  • the application 34 additionally preferably contains functions for processing the image data, in particular for measuring and / or segmenting image structures and / or for introducing markings and / or annotations.
  • the application 34 also contains a function for establishing a so-called key image K (FIG. 2).
  • K key image
  • the application 34 is set up to store created key images K directly on the corresponding user command as an image data record B in the blob memory 28 of the image hub 25.
  • the applications 32-34 or possibly several instances of these applications 32-34 also preferably run in the frame module 51.
  • a common frame module 51 is provided for all applications 31-34.
  • each application 31-34 may be assigned its own frame module.
  • each of the hubs 22-25 and the respective assigned application 31-34 is designed to be in line with the one used in Internet traffic
  • REST Representational State Transfer
  • Image data B are stored in the image hub 25, in particular in JPEG format, volume data preferably in DICOM format.
  • the views V (scene graphs) of volume data optionally supplied by the public cloud 13 to the application 34 are preferably created in JPEG format.
  • each application 31-34 uses a multi-instantiable cloud driver that is in the form of a user programming interface (API).
  • API user programming interface
  • Each of the applications 31-33 is adapted to externalize feeds 35 on the instructions of the user from the associated hub 22-24 in a local memory of the device 8, so that this feed 35 and the tweets 27 contained therein through the application 31-33 can also be displayed and / or edited without network connection to the public cloud 13. Furthermore, each application 31-33 is adapted to transmit on an appropriate command of the user externalized feeds 35 or tweets 27 to another instance of the same or another application 31-34. For device-internal transmission of the feeds 35 or tweets 27, a local memory area designated as "Exchangeboard" is set up in the memory of the device 8, to which all instances of the application are assigned. NEN 31-34 together.
  • the exchanged feeds 35 or Tweets 27 are serialized in XML / JSON files, which are stored in the local memory of the device 8 and then deserialized again.
  • the applications 31-34 preferably have interfaces to Twitter or an e-mail program.
  • 6 shows a variant of the applications 31-33, in which the user interface 37 is optimized for display on a large-format screen, for example the screen 10 of the personal computer 9 or the screen of the tablet computer 11.
  • the user interface 37 according to FIG. 6 differs from the user interface 37 shown in FIGS. 3 and 4 in that a plurality of instances of the applications 31-33 and the corresponding sides 36 and / or 52 of the user interface 37 are arranged side by side (and thus simultaneously ) are visible.
  • the user interface 37 furthermore has additional navigation buttons 50, through the actuation of which, in turn, it is possible to scroll between the displayed pages 36 and / or 52.
  • the user interface 37 in addition to a menu line 80, can be changed by the operation between the various applications 31-34.
  • the menu line 80 is in particular part of a frame module 81 (or container) in which the existing instances of the applications 31-34 run.
  • FIG. 7 shows a version of page 69 of the application 34 optimized for display on a large-format screen, in which the display field 72 fills almost the entire screen area.
  • FIG. 8 shows a variant of the system 1 in which the application 34 for displaying 2D image data and volume data contains a (2D viewing) module 92 and a (3D viewing) module 93 independent therefrom.
  • the application 34 is here in a limited version with only one of the modules 92 and 93 executable.
  • the 2D viewing module 92 always accesses the blob storage 28 of the image hub 25 directly for downloading the image data set B to be displayed.
  • the 3D viewing module 93 either also directly accesses the volume data stored in the image hub 25 or makes use of the views V cloud compute services 21.
  • the associated Tweet 27 is determined, for example, by the application 33 assigned to the context hub 24 and transferred to the application 34 via the Exchangeboard. Based on the URI 29 contained in the transferred Tweet 27, the application 34 loads the image data record B from the image hub 25.
  • FIG. 9 shows a further variant of the system 1 in which the image hub 25 is assigned a 2D viewing application 94 and a 3D viewing application 95 independent of the single application 34.
  • each modality 3 of the system 1 is provided with a storage driver 100 implemented in the computer 7.
  • the memory driver 100 which is in the form of a user programming interface (API) for the control and evaluation software of the modality 3, is in this case configured to directly generate an image data set B generated by the modality 3 and transferred to the memory driver 100 (without using cloud computing services 21) to write to the blob storage 28 of the image hub 25.
  • the storage driver 100 creates an associated context record C as Tweet 27 in the table storage 26 of the context hub 24.
  • the memory driver 100 preferably converts the image data (at least insofar as the image data is 2D image data) into the JPEG format, provided that the modality 3 originally creates the image data in another data format. In the case of volume data, however, these are preferably stored in the DICOM format in the blob memory 28 of the image hub 25.
  • the memory driver 100 optionally performs further data preprocessing processes (preprocessing) before depositing the image data set in the image hub 25.
  • Appendix 1 An example code for the user interface of the frame 51 (App Hub Container GUI)
  • Appendix 2 An example code for the logic of the frame 51
  • Appendix 3 An example code for the storage driver 100
  • x: Class "AzureTableStore_CRUD_Sample.PivotMainPage”
  • xmlns "http: // schemas. microsoft .com / winfx / 2006 / xaml / ...
  • xmlns "http: // schemas .microsoft.com / winf ⁇ / 2006 / xaml”
  • xmlns: src "clr-namespace: AzureTableStore_CRUD_Sample; ...
  • Shell "clr-namespace: Microsoft. Phone. Shell; ...
  • xmlns: controls "clr-namespace: Microsoft. Phone. Controls; ...
  • Target Name ... "ContentPanel” storyboard.
  • TargetProperty ... "(UIElement, Projection). (...
  • TargetProperty ... "(UIElement, Projection). (...
  • TargetProperty ... "(UIElement, Projection). (...
  • AppFeed_All_StateStore "AppFeed_Apps”
  • private bool isNewPagelnstance false
  • CurrAppIndex i
  • Loaded + new RoutedEventHandler ((App .App.
  • CurrAppIndex i
  • Model as ViewModelBase General Selected ... Index
  • App. PreviousApp App. CurrentApp
  • Model as ViewModelBase GetExternalEntity ..
  • ToViewingApps ("/ ViewsViewing / Viewing ...
  • Model as ViewModelBase .GetExternalEntity .. FromSelectedIndex ⁇ Blob> ();
  • ToViewingApps ("/ ViewsViewing / Viewing ...
  • ToViewingApps ("/ ViewsViewing / Viewing ...
  • Model as ViewModelBase .GetExternalEntity .. FromSelectedIndex ⁇ Twitter> ();
  • ToViewingApps ("/ ViewsViewing / Viewing ...
  • ToViewingApps ("/ ViewsViewing / Viewing ...
  • App .Applnstances GetApplicationState ⁇ List ⁇ Appl ...
  • Appendix 3 An Example Code for the Storage Driver 100 (Di rect Storage Adapter)
  • IsolatedStorageFileStream myThumbnailFileStream
  • IsolatedStorageFileStream myKeylmageFileStream
  • IsoKeylmageFileName "tempKeyIma.jpg”
  • UploadDoneNotification (msg); storeKeylmagelnContextFolderT- ableStore (this. selected ...
  • Notification Delegate (string msg); private void doTableEntrvAndUploadDoneNotification (...
  • NotificationDelegate (TableEntry ... AndUploadDoneNotification), msg); ⁇
  • FolderBlobStore (Stream Video_Stream, ... string mTimeOutSeconds, bool mSas ... Expired, string mSasUrl)
  • DateTime CurrentTime System. DateTime. Now;
  • UploadStream (pathName, fileNameAndExt, Video_Stream, ...
  • UploadStream (pathName, fileName, keyIma_Stream, mTimeOut ...
  • cn.Thumb cn. ServerBaseUri + cn.DZInstDataRelPath +
  • Bitmap image bitMapImage new Bitmapimage ();
  • bitmap bitmap. Clear ();
  • bitmap null
  • EmbeddedResourceStream null
  • StorageFileStream (this.isoKeylmageFile.name, FileMode.Create, isolatedStore)) ⁇

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Theoretical Computer Science (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • Public Health (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Databases & Information Systems (AREA)
  • Primary Health Care (AREA)
  • Epidemiology (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Biomedical Technology (AREA)
  • Software Systems (AREA)
  • Nuclear Medicine, Radiotherapy & Molecular Imaging (AREA)
  • Radiology & Medical Imaging (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Measuring And Recording Apparatus For Diagnosis (AREA)

Abstract

Es werden ein Verfahren und ein System zur Verwaltung und Bearbeitung von Daten einer medizinischen Einrichtung (2,2`) angegeben. Dabei werden für mindestens zwei unterschiedliche Arten von medizinischen Datensätzen (P,W,C,B) jeweils separate Speicherbereiche (22-25) in einem Cloud Storage (19) einer Public Cloud (13) zur Verfügung gestellt. Die in dem jeweiligen Speicherbereich (22-25) gespeicherten Datensätze (P,W,C,B) werden jeweils derart vorgehalten, dass ein unmittelbarer Zugriff auf diese Datensätze (P,W,C,B) aus dem Internet (16) bei Vorliegen einer dem Speicherbereich (22-25) zugeordneten Subscription (18, 18`) möglich ist. Zudem wird für jeden Speicherbereich (22-25) mindestens eine spezifisch zugeordnete Applikation (31-34, 94, 95) zum Ablauf auf einem Nutzer-Gerät (8, 9, 11, 12) zur Verfügung gestellt, die zum Abruf und/oder zur Darstellung der in dem zugeordneten Speicherbereich (22-25) enthaltenen Datensätze (P,W,C,B) eingerichtet ist.

Description

Beschreibung
Verfahren und System zur Verwaltung und Bearbeitung von Daten einer medizinischen Einrichtung
Die Erfindung bezieht sich auf ein Verfahren zur Verwaltung und Bearbeitung von Daten einer medizinischen Einrichtung. Die Erfindung bezieht sich des Weiteren auf ein System zur Durchführung dieses Verfahrens .
Unter dem Begriff „Verwaltung" wird hier und im Folgenden insbesondere die Archivierung der Daten (das heißt die Einstellung der Daten in einen persistenten Datenspeicher) , die Wiedergabe (Anzeige) und das Löschen der Daten aus dem Daten- Speicher sowie das Sortieren und Auffinden bestimmter Daten aus dem Datenspeicher nach Maßgabe vorgegebener Kriterien (Browsing) verstanden.
Unter dem Begriff „Bearbeitung" wird hier und im Folgenden insbesondere die Änderung (Editierung / Aufbereitung) der Daten verstanden.
Die zu verwaltenden und zu bearbeitenden Daten der medizinischen Einrichtung umfassen insbesondere Patientendaten, Auf- gaben (Works/Tasks) oder Aufgabenlisten (Worklists) für das
Personal der medizinischen Einrichtung und medizinische Bilddaten .
Die Verwaltung solcher medizinischer Daten erfolgt in zuneh- mendem Maße computergestützt durch Server-Systeme, insbesondere sogenannte Informationssysteme. Ein Informationssystem umfasst regelmäßig
- einen oder mehrere Datenspeicher, beispielsweise in Form eines Storage Area Network (SAN) ,
- einen oder mehrere zugehörige Datenserver,
- mindestens eine relationale Datenbank, die in einem Datenbankserver implementiert ist, - sowie in der Regel einen oder mehrere weitere Server, in denen Methoden für den Datenbankzugriff und die Datenbearbeitung implementiert sind. Für die unterschiedlichen Datenarten haben sich im medizinischen Bereich unterschiedliche Informationssysteme etabliert. So werden im Umfeld einer medizinischen Einrichtung wie zum Beispiel einer Klinik regelmäßig ein „Krankenhaus-Informations-System" (Hospital Information System, HIS) für die Ver- waltung und Bearbeitung der Patientendaten und ein „Radiologie-Informations-System" (RIS) für die Terminplanung radiologischer Untersuchungen, die Unterstützung der Befundung medizinischer Bilddaten und die Dokumentation der Befunde eingesetzt. Daneben umfasst die IT-Struktur eines Krankenhauses in der Regel ein sogenanntes „Picture Archiving and Communicati- on System" (PACS) zur Archivierung und Übertragung von medizinischen Bilddaten auf Basis des DICOM-Standards sowie ein „Avanced Visualisation (AV) -System" , das servergestützte Funktionen zur Visualisierung von Volumendaten, insbesondere dy- namisches Volume Rendering, zur Verfügung stellt.
Die vorstehend bezeichneten Server-Systeme sind dabei in der Regel parallel zueinander vorhanden. Dies erfordert einen hohen Beschaffungs- und Wartungsaufwand, der insbesondere für kleine medizinische Einrichtungen oder sonstige Einrichtung mit vergleichsweise geringen Finanzvolumen kaum zu bewältigen ist .
Die vorstehend beschriebene, komplexe IT-Struktur einer mo- dernen medizinischen Einrichtung weist zudem nur vergleichsweise schlechte Skalierungseigenschaften auf. Eine Anpassung einer solchen IT-Struktur an größere Änderungen des zu verarbeitenden und zu archivierenden Datenvolumens und/oder der erforderlichen Rechenleistung ist somit meist nur mit sehr hohem Aufwand möglich.
Als Nutzer- oder Endgeräte (klassischerweise als Clients bezeichnet) einer solchen IT-Struktur werden überwiegende Per- sonal Computer (PCs) verwendet, wobei diese PCs oft als sogenannte „Thin Clients" ausgebildet sind, die einen Großteil der erforderlichen Rechenleistung von einem angeschlossenen Server beziehen.
Als Alternative zu herkömmlichen Client-Server-Architekturen haben sich in den vergangenen Jahren zunehmend sogenannte Cloud-Lösungen etabliert. Als „Cloud" („Rechnerwolke") wird dabei eine Datenverarbeitungseinrichtung verstanden, die von einem von dem Nutzer unabhängigen Cloud-Betreiber („Cloud Vendor") zur Verfügung gestellt und betrieben wird. Der „Cloud Vendor" stellt hierbei einer Vielzahl von Nutzern die Hardware und gegebenenfalls die Software der Cloud im Rahmen eines Nutzungsvertrags (Subscription) als Dienst zur Verfü- gung . Je nach dem Umfang der zur Verfügung gestellten Dienste unterscheidet man zwischen
- einem als „ Infrastructure as a Service" (IaaS) bezeichneten Nutzungsmuster, bei dem dem Nutzer lediglich Com- puterhardware (Rechner, Netzwerke und Speicher) der
Cloud zur Verfügung gestellt wird, während der Nutzer für die in der Cloud betriebene Software in vollem Umfang selbst verantwortlich ist,
- einem als „Platform as a Service" (PaaS) beschriebenen Nutzungsmuster, bei dem dem Nutzer aus der Cloud die
Computerhardware zusammen mit einer darauf aufbauenden Programmierungs- und Laufzeitumgebung angeboten wird, so dass der Nutzer nur für die in dieser Programmierungsund Laufzeitumgebung implementierte Anwendungssoftware (Applikationen) selbst verantwortlich ist, sowie
- einem als „Software as a Service" (SaaS) bezeichneten Nutzungsmuster, bei dem dem Nutzer darüber hinaus auch bestimmte Anwendungssoftware aus der Cloud zur Verfügung gestellt wird.
Je nach dem Nutzerkreis, an den die jeweilige Cloud adressiert ist, unterscheidet man des Weiteren zwischen - einer sogenannten Public Cloud, deren Dienste von jedem in Anspruch genommen werden können, und
- einer sogenannten Privat Cloud, die nur Nutzern einer bestimmten Organisation, insbesondere eines bestimmten Konzerns zugänglich ist.
Für jeden Nutzer einer Public Cloud sind die Zugriffsberechtigungen auf bestimmte Hardware- und Softwarebestandteile der Cloud durch die dem Nutzer zugeordnete Subscription geregelt. Public Clouds sind hierdurch regelmäßig „mandantenfähig"
(multi-tenant) . Dies bezeichnet die Fähigkeit, Daten, Benutzerverwaltung und Rechenoperationen für Nutzer mit verschiedener Subscription strikt getrennt zu halten. Ein Nutzer der Public Cloud kann also in die Daten, Benutzerverwaltung und Rechenoperationen eines anderen Nutzers mit unterschiedlicher Subscription keinen Einblick nehmen und diese Daten auch nicht beeinflussen.
Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren und ein System zur Verwaltung und Bearbeitung von Daten einer medizinischen Einrichtung anzugeben, das besonders flexibel einsetzbar, insbesondere besonders skalierbar ist.
Bezüglich des Verfahrens wird diese Aufgabe erfindungsgemäß gelöst durch die Merkmale des Anspruchs 1. Bezüglich des zugehörigen Systems wird die Aufgabe erfindungsgemäß gelöst durch die Merkmale des Anspruchs 9. Vorteilhafte und teils für sich gesehen erfinderische Ausgestaltungen und Weiterentwicklungen der Erfindung sind in den Unteransprüchen und der nachfolgenden Beschreibung dargelegt.
Erfindungsgemäß werden für mindestens zwei unterschiedliche Arten von Daten der medizinischen Einrichtung jeweils separate Speicherbereiche in einem Cloud Storage (also dem per- sistenten Speicher) einer Public Cloud zur Verfügung gestellt, wobei die in dem jeweiligen Speicherbereich gespeicherten Datensätze derart vorgehalten werden, dass ein unmittelbarer Zugriff auf diese Datensätze aus dem Internet mög- lieh ist, wenn eine dem Speicherbereich zugeordnete Subscrip- tion vorliegt (wenn also das zugreifende Gerät nach Maßgabe der Subscription zum Zugriff berechtigt ist) . Diese Zugriffsmöglichkeit ist dabei insbesondere derart gestaltet, dass sie mit dem Internet-Standard REST kompatibel ist. REST (Representational State Transfer) bezeichnet dabei ein Programmierparadigma für Internet-Anwendungen, das folgenden Prinzipien genügt:
- Jedem angebotenen Dienst ist eine eindeutige Adresse
(Uniform Resource Locator, kurz: URL) zugewiesen.
- Der unter einer Adresse zugängliche Dienst kann unter- schiedliche Erscheinungsformen (Repräsentationen) haben.
- Es wird ein zustandsloses (stateless) Client-Server- Protokoll verwendet, das es ermöglicht, verschiedene Anfragen zwischen Clients und Servern stets unabhängig voneinander zu behandeln.
- Auf alle Ressourcen muss eine vorgegebene Anzahl von
Operationen (nämlich insbesondere die vier Operationen GET, POST, PUT, DELETE) mit definierten Eigenschaften anwendbar sein.
- Sowohl für AnwendungsInformationen als auch für Zu- standsveränderungen wird multimedialer Hypertext (Hyper- media) benutzt.
Die Repräsentation erfolgt dabei vorzugsweise gemäß den Internet-Standards XML (Extensible Markup Language) , JSON (Java Script Object Notation) und/oder ATOM. ATOM ist hierbei als Überbegriff verwendet für das Atom Syndication Format (ASF) , das ein XML-Format für den Austausch von Nachrichten darstellt, sowie das ATOM Publishing Protocol (APP) , das eine Programmierschnittstelle zur Erzeugung und Bearbeitung von Webinhalten darstellt. Bei der medizinischen Einrichtung, der jeweils eine Subscription zugeordnet ist, handelt es sich in dem vorrangig anvisierten Anwendungsfall um eine Klinik. Allerdings ist im Rahmen der Erfindung auch denkbar, dass kleinere Einheiten wie zum Beispiel Arztpraxen, einzelne Abteilungen einer Klinik oder sogar einzelne Patienten zur Verwaltung der jeweils eigenen medizinischen Daten eine eigene Subscription erwerben und somit das Verfahren bzw. System in vollem Umfang nützen können .
Das System ist hierbei durch die Nutzung der Public Cloud in dem vorstehend erläuterten Sinne „mandantenfähig" (multi- tenant) . Daten, Benutzerverwaltung und Rechenoperationen werden für Nutzer mit verschiedener Subscription somit strikt getrennt voneinander gehalten, so dass ein Einblick in oder eine Beeinflussung von Daten fremder Subscriptions ausgeschlossen ist.
Im Rahmen des erfindungsgemäßen Verfahrens und Systems wird des Weiteren für jeden Speicherbereich eine Applikation zum Ablauf auf einem Nutzer- oder Endgerät (nachfolgend als „Device" bezeichnet) zur Verfügung gestellt, die zum Abruf und/oder zur Darstellung der in dem zugeordneten Speicherbereich enthaltenen Datensätze eingerichtet ist.
Jede Applikation ist dabei genau einem der Speicherbereiche spezifisch zugeordnet und implementiert somit selektiv und ausschließlich diejenigen Funktionen für die Verwaltung und Bearbeitung der in dem jeweiligen Speicherbereich enthaltenen Datensätze .
Die verschiedenen Arten von Daten der Einrichtung umfassen insbesondere
- Patientendaten, die persönliche und medizinische Angaben zu einem bestimmten Patienten der Einrichtung umfassen, insbesondere Angaben zum Namen, der Adresse, dem Alter, dem Geschlecht, früheren Diagnosen und Behandlungen,
- Aufgaben (Works/Tasks) und Aufgabenlisten (Worklists) , die von einem oder mehreren medizinischen Nutzern (Ärz- ten, medizinischen Assistenzkräften, Pflegern etc.) der medizinischen Einrichtung durchzuführen sind,
- medizinische Bilddaten, insbesondere zweidimensionale Bilder, zweidimensionale Bildsequenzen (Videos) , Volumendaten (z.B. Computertomogramme) und/oder zeitliche Volumendatensequenzen (4D-Daten) , aber auch Keyimages,
Photos, Dokumente und dergleichen, sowie
- Kontextinformation zu medizinischen Bilddaten, insbesondere Verweise auf den Speicherort von Bilddatensätzen sowie optional Meta-Daten zu Bilddatensätzen wie z.B. die der jeweiligen Bildaufnahme zugrundeliegenden Auf- nahmeparameter .
Als „Keyimage" wird hierbei ein Schnappschuss , d.h. ein (bearbeiteter oder unbearbeiteter) Ausschnitt aus einem medizi- nischen Bild- oder Volumendatensatz bezeichnet, der bei der Befundung dieser Daten zur Darstellung eines medinizischen Befundes abgeleitet wird. Solche Keyimages werden typischerweise als Bestandteil eines medizinischen Berichts (Reports) verwendet .
Jede dieser verschiedenen Datenarten wird nachfolgend auch als „Ressource" bezeichnet. Der dieser Ressource jeweils zugewiesene Speicherbereich des Cloud Storage wird nachfolgend auch als „ (Ressource- ) Hub" bezeichnet. In Zuordnung zu den oben beschriebenen Ressourcen werden im Rahmen des Verfahrens und Systems vorzugsweise mindestens zwei der nachfolgend aufgeführten (Ressource- ) Hubs im Cloud Storage zur Verfügung gestellt :
Ein Patienten-Speicherbereich (Patient-Hub), in dem jeder (Patienten- ) Datensatz Patientendaten eines bestimmten Patienten enthält, - ein Aufgabenlisten-Speicherbereich (Worklist-Hub) , in dem jeder Datensatz eine Aufgabe (Work/Task) oder Aufga- benliste (Worklist) enthält,
- einen Bilddaten-Speicherbereich ( Image-Hub) , in dem je- der (Bild- ) Datensatz medizinische Bild- oder Volumendaten oder eine sonstige Bild-, Ton-, Graphik- oder Textinformation (Photos, Videos, Dokumente) enthält und/oder
- einen Kontext-Speicherbereich (Context-Hub) , in dem jeder (Kontext- ) Datensatz Kontextinformation zu einem Bilddatensatz enthält, insbesondere einen Verweis auf den Speicherort des jeweiligen Bilddatensatzes im Image- Hub sowie optional Meta-Daten zu dem Bilddatensatz.
Jeder der vorstehend beschriebenen Hubs ist zusammen mit der ihm spezifisch zugeordneten Applikation selbstständig (d.h. unabhängig von den anderen Hubs und den diesen jeweils zugeordneten Applikationen) betreibbar. Somit ist keiner der vorstehend beschriebenen Hubs und der zugeordneten Applikationen zur Durchführung des erfindungsgemäßen Verfahrens oder im Rahmen des erfindungsgemäßen Systems zwingend notwendig. Jeder der vorstehend beschriebenen Hubs erweitert aber zusammen mit der zugeordneten Applikation die Funktionalität des Verfahrens bzw. Systems in vorteilhafter Weise. Die Erfindung geht von der Überlegung aus, dass aus Gründen einer verbesserten Skalierbarkeit für die Datenverwaltung und -bearbeitung in einer medizinischen Einrichtung ein Wechsel von einer klassischen Client-Server-Lösung hin zu einer cloud-basierten Lösung sinnvoll ist. Erkanntermaßen werden durch eine bloße Übertragung der klassischerweise gebräuchlichen Server-Systeme in die Cloud die eingangs beschriebenen Probleme aber nicht in befriedigender Weise gelöst. So wird durch die Verlagerung der herkömmlicherweise in einer medizinischen Einrichtung verwendeten Server in die Cloud die Kom- plexität der IT-Struktur nicht vereinfacht, sondern eher erhöht, zumal die Server in einer Cloud regelmäßig in virtuali- sierter Form betrieben werden, und somit zu der unverändert komplexen Serverstruktur noch die Virtualisierungs-Software hinzu käme. Zudem würden erkanntermaßen bei einer solchen Lösung hohe Kosten für die in der Cloud erbrachte Serverleistung (Cloud Virtual Server) anfallen, die die Vorteile einer Cloud-Nutzung weitgehend aufwiegen würden. Ferner müssten die virtualisiert in der Cloud betriebenen Server noch immer durch die Einrichtung selbst administriert werden, so dass der damit verbundene Aufwand bestehen bleiben würde. Auch hinsichtlich Skalierbarkeit und Ausfallsicherheit brächte eine solche Lösung keine wesentliche Verbesserung.
Eine solche Verbesserung wird allerdings durch die erfinderische Idee erzielt, die medizinischen Daten derart in dem Public Cloud Storage zu hinterlegen, dass auf diese Daten - insbesondere in REST-kompatibler Weise - über das Internet zuge- griffen werden kann. Dies ermöglicht es, zumindest einen
Großteil der zur Durchführung des Verfahrens erforderlichen Rechenleistung in den an der Verfahrensdurchführung beteiligten Devices selbst zu erbringen. Somit wird im Zuge des Verfahrens ausschließlich oder zumindest nahezu ausschließlich der - vergleichsweise preisgünstige - Cloud Storage der Public Cloud in Anspruch genommen, während die wesentlich teurere Rechenleistung der Public Cloud (Cloud-Compute-Dienste) nicht oder nur in geringem Maße in Anspruch genommen wird. Die ausschließliche oder zumindest nahezu ausschließliche Zu- Ordnung der Rechenleistung zu den Devices trägt auch zu einer wesentlich verbesserten Skalierbarkeit des Verfahrens und des zugeordneten Systems bei, da die cloud- seitig implementierten Strukturen an einen veränderten Bedarf an Rechenleistung nicht angepasst werden müssen. Insbesondere müssen keine vir- tuellen Server in der Cloud geschaffen und betreut werden. Vielmehr werden die optional in Anspruch genommenen Cloud- Compute-Dienste unmittelbar von dem Cloud-Provider im Sinne eines PaaS-Konzepts betreut und zur Verfügung gestellt. Die Verteilung der verschiedenen Ressourcen auf verschiedene, vollständig voneinander separierte Ressource-Hubs, und die Zurverfügungstellung der jeweils diesen Hubs spezifisch zugeordneten Applikationen ermöglicht dabei einen besonders fle- xiblen Einsatz des Verfahrens und des zugehörigen Systems, zumal verschiedene medizinische Einrichtungen die im Rahmen ihrer jeweiligen Subscription enthaltenen Hubs frei auswählen können, ohne gegenseitige Abhängigkeiten berücksichtigen zu müssen. Hierdurch sind für die medizinische Einrichtung wiederum die Kosten für den Betrieb des Verfahrens und des zugeordneten Systems flexibel regulierbar.
Durch die Nutzung der Public Cloud zur Archivierung und Vor- haltung der Daten profitiert die medizinische Einrichtung dabei von den üblichen Vorteilen eines Public Cloud Storage, nämlich einer nahezu unbegrenzten Skalierbarkeit (das heißt der Möglichkeit, nahezu beliebige Datenmengen ohne qualitative Änderungen der IT-Struktur effizient zu verwalten) , eine weltweite Verfügbarkeit der Daten, eine äußerst hohe Sicherheit gegen Ausfall und Manipulation sowie eine nahezu vollständige Reduzierung des einrichtungsinternen Beschaffungsund Wartungsaufwandes . Zusammenfassend wird durch die Erfindung eine im medizinischen Bereich vom Üblichen vollständig abweichende IT- Struktur angegeben, die es ermöglicht, die Vorteile einer Public Cloud gegenüber einer herkömmlichen Client-Server- Lösung effizient zu nutzen, ohne dafür nennenswerte Nachteile in Kauf nehmen zu müssen.
Als Public Cloud wird vorzugsweise der „Windows Azure"-Dienst der Fa. Microsoft genutzt. Andere Public Clouds können im Rahmen der Erfindung aber auch verwendet werden. Insbesondere können auch mehrere Publics Clouds von gegebenenfalls unterschiedlichen „Cloud Vendors" parallel (gleichzeitig) zur Verwaltung der Daten der Einrichtung herangezogen werden.
Bei den an der Verfahrensdurchführung beteiligten Devices der Einrichtung kann es sich in beliebiger Zusammensetzung um Desktop-PCs, aber auch um mobile Geräte wie Notebooks,
Tablet-Computer und Smartphones handeln. Vorzugsweise sind die Applikationen dazu eingerichtet, auf die in dem jeweils zugeordneten Hub enthaltenen Datensätze unmittelbar zuzugreifen. Zusätzlich oder alternativ sind die Applikationen vorzugsweise dazu eingerichtet, die in dem je- weils zugeordneten Hub enthaltenen Datensätze unmittelbar zu erzeugen, zu editieren und zu löschen. Der Begriff „unmittelbar" wird hier und im Folgenden jeweils in dem Sinne verwendet, dass die Applikation die jeweilige Aktion selbstständig unter ausschließlicher Nutzung des Cloud Storage ausführt, ohne dass hierfür - von der reinen Speicherverwaltung (Cloud Storage) unabhängige - Rechenleistung der Public Cloud
(Cloud-Compute-Dienste) in Anspruch genommen wird.
Abweichend ist im Rahmen der Erfindung aber vorzugsweise min- destens eine der Applikationen in zwei Betriebsmodi betreibbar, nämlich
- in einem „Device-Only-Modus " , in dem die Applikation
ausschließlich auf einem Device abläuft, unmittelbar auf den Cloud Storage zugreift und keine Cloud-Compute-
Dienste der Public Cloud in Anspruch nimmt, sowie
- in einem „Cloud-Service-Modus", in dem die Applikation zum Zugriff und/oder zur Darstellung der in dem Hub enthaltenen Datensätze zusätzlich Cloud-Compute-Dienste der Public Cloud heranzieht.
Dieser - optional zuschaltbare - Cloud-Service-Modus wird insbesondere bei einer sogenannten 3D-Viewing-Applikation vorgesehen, die zur - besonders rechenleistungsintensiven - Darstellung von gerenderten Ansichten (Szenen) von Volumendaten dient. Die Rechenleistung wird dabei von dem Cloud Vendor insbesondere im Rahmen eines PaaS-Nutzungsschemas angeboten, so dass für das Betriebssystem, Treiber, einen Applikationsserver (App-Store) und dergleichen keine separaten Adminis- trationskosten anfallen. Im Rahmen der Erfindung kann vorgesehen sein, dass die Auswahl zwischen dem Device-Only-Modus und dem Cloud-Service- Modus - entweder automatisch durch die Applikation vorgenommen wird (beispielsweise in Abhängigkeit der Qualität der Netzverbindung und/oder der Rechenkapazität des Device) , - interaktiv durch den medizinischen Nutzer bestimmt wird, oder
- durch Voreinstellung (Konfigurationsdaten) der Applikation festgelegt wird.
Vorzugsweise ist innerhalb mindestens eines Hubs ein Tabellenspeicher (Table Storage) angelegt. Hierunter wird eine - beispielsweise im Rahmen des „Windows Azure"-Dienstes der Firma Microsoft standardmäßig angebotene - Form der Datenspeicherung verstanden, in der Dateneinheiten (Data Entities) zusammen mit einer Index-Variable, die jede Dateneinheit eindeutig kennzeichnet, als Tabelleneinträge strukturiert abge- legt werden. Bei dem „Windows Azure"-Dienst setzt sich diese Index-Variable beispielsweise aus einem sogenannten Partiti- onKey sowie einem sogenannten RowKey zusammen. Der Partition- Key bezeichnet hierbei eine physikalische Partition des Cloud Storage, in der der jeweilige Tabelleneintrag abgelegt wird, so dass Tabelleneinträge mit verschiedenem PartitionKey in verschiedenen physikalischen Partitionen abgelegt werden.
Innerhalb des Table Storage ist jedem der in dem jeweiligen Hub gespeicherten Datensätze ein Tabelleneintrag (nachfolgend als „Tweet" bezeichnet) zugeordnet. Jeder Tweet kann hierbei den zugeordneten Datensatz selbst enthalten. So ist vorzugsweise jeder Satz von Patientendaten des Patient-Hubs vorzugsweise als Tweet des zugehörigen Tabellenspeichers hinterlegt. Alternativ hierzu (insbesondere bei Datensätzen mit großen und/oder nicht-alphanumerischen Datenblöcken wie z.B. medizinischen Bildern) ist der Datensatz selbst tabellenextern (außerhalb eines Table Storage) hinterlegt, beispielsweise in einem sogenannten Blob-Speicher (Blob Storage) der Cloud Sto- rage. Der dem Datensatz zugeordnete Tweet enthält in diesem Fall eine Angabe zu dem tabellenexternen Speicherort, beispielsweise in Form eines sogenannten „Uniform Ressource Identifier" (URI) . Wiederum alternativ hierzu können bestimm- te Datenblöcke eines Datensatzes im Rahmen des Tweets in dem Tabellenspeicher abgelegt sein, während mindestens ein weiterer Datenblock desselben Datensatzes tabellenextern gespeichert ist. So sind beispielsweise im Falle von medizinischen Bilddatensätzen zweckmäßigerweise die eigentlichen Bilddaten in einem Blob-Storage des Image-Hubs gespeichert, während die dazugehörigen Metadaten (z.B. Aufnahmeparameter und Angaben zum Patienten) im Rahmen der zugehörigen Kontextinformation im Table Storage des Context-Hubs hinterlegt sind. Als Blob- Storage, wie er ebenfalls im Rahmen des „Windows Azure"
Dienstes der Firma Mircosoft standardmäßig angeboten wird, wird eine Form der Datenspeicherung bezeichnet, bei der eine unstrukturierte Speicherung von Datensätzen erfolgt.
Verfahrensgemäß kann hierbei der Inhalt des Tabellenspeichers von der dem Hub zugeordneten Applikation unmittelbar (ohne Inanspruchnahme von Rechenleistung der Public Cloud, also Cloud-Compute-Diensten) durchsucht werden. Als Ergebnis dieser Suche werden hierbei ausgewählte Tweets in Form einer Ergebnisliste extrahiert, die von der Applikation angezeigt wird. Eine solche Ergebnisliste ist nachfolgend als „Feed" bezeichnet .
Die vorstehend beschriebene Ausgestaltung der Applikationen und des von diesem durchgeführten Verfahrens ermöglicht hier- bei ein effektives „Browsing", d.h. eine effektive Sortierung und Auffindung der in dem jeweiligen Hub gespeicherten Daten, ohne hierfür Rechenleistung der Public Cloud, also Cloud- Compute-Dienste in Anspruch zu nehmen. In einer besonders bevorzugten Ausgestaltungsvariante des
Verfahrens wird durch mindestens eine der Applikationen der von dieser aus dem zugehörigen Hub extrahierte Feed „externa- lisiert", das heißt aus dem Public Cloud Storage in einen lo- kalen Speicher des Device heruntergeladen, so dass dieser Feed und die darin enthaltenen Tweets durch die Applikation auch ohne Netzanbindung mit der Public Cloud angezeigt, bearbeitet und/oder an eine andere Instanz derselben oder einer anderen Applikation übermittelt werden können.
Durch diesen Austauschmechanismus (auch als „Exchangeboard" bezeichnet) wird eine besonders effektive und flexible Kommunikation zwischen verschiedenen Applikationsinstanzen ermög- licht, die wiederum ohne Rechenleistung der Public Cloud, also Cloud-Compute-Dienste auskommt. Beispielsweise kann auf diese Weise mittels einer dem Context-Hub zugeordneten Brow- sing-Applikation der URI eines anzuschauenden Bildes ermittelt und an eine davon separate Viewing-Applikation des
Image-Hub übermittelt werden, so dass die Viewing-Applikation dann selbständig anhand des URI auf das gesuchte Bild zugreifen kann. Dieser Austausch kann ohne Weiteres auch zwischen verschiedenen Devices erfolgen, beispielsweise indem der dem Bilddatensatz zugeordnete Tweet oder/oder die darin enthalte- ne URI per Email, Instant-Message oder Twitter versandt werden .
In einer weiteren vorteilhaften Weiterentwicklung des Verfahrens und des Systems sind auch Modalitäten der medizinischen Einrichtung (das heißt, die bildgebenden Geräte wie z.B. Computertomographen, Magnetresonanztomographen, etc.) zur unmittelbaren Kommunikation mit dem Cloud Storage ertüchtigt. Im Zuge des Verfahrens wird somit durch eine medizinische Modalität ein Datensatz, der patientenspezifische Bilddaten ent- hält, erzeugt und unmittelbar in dem zugeordneten Speicherbereich (insbesondere dem Image-Hub) des Cloud Storage abgelegt. Diese Funktionalität zur direkten Kommunikation mit dem Public Cloud Storage ist insbesondere in einem Speichertreiber implementiert, der der Steuersoftware der Modalität im Rahmen einer Anwender-Programmier-Schnittstelle (Application Programming Interface, kurz: API) zur Verfügung gestellt wird. Der Speichertreiber kann unmittelbar in die Steuersoftware der jeweiligen Modalität integriert sein. Alternativ hierzu bildet der Speichertreiber einen eigenständigen Programmbestandteil, auf den die Steuersoftware der Modalität nach Art eines Druckertreibers zugreift. Die vorstehend beschriebene Ausbildung einer Modalität zum unmittelbaren Laden der von der Modalität erzeugten Bilddatensätze in einen zugeordneten Speicherbereich (Image-Hub) eines Public Cloud Sto- rage wird als eigenständige Erfindung angesehen, die auch ohne die übrigen Merkmale vorstehend beschriebenen Verfahrens bzw. Systems vorteilhaft einsetzbar ist.
Das erfindungsgemäße System zur Verwaltung und Bearbeitung von Daten einer medizinischen Einrichtung ist schaltungs- oder programmtechnisch zur Durchführung des vorstehend beschriebenen Verfahrens eingerichtet. Es umfasst hierzu min- destens zwei (Ressource- ) Hubs der vorstehend beschriebenen
Art zur Speicherung mindestens zweier Ressourcen (d.h. zweier unterschiedlicher Arten von medizinischen Datensätzen) , wobei jeder Hub ausschließlich den Datensätzen einer bestimmten Ressource zugewiesen ist. Die Daten sind hierbei in dem je- weiligen Hub derart vorgehalten, dass auf diese Daten aus dem Internet unmittelbar zugegriffen werden kann, sofern eine dem Hub zugeordnete Subscription vorliegt. Jedem Hub ist hierbei mindestens eine Applikation zugeordnet, die selektiv zum Abruf und zur Darstellung der in dem zugeordneten Hub enthalte- nen Datensätze eingerichtet ist. Die vorstehend im Zusammenhang mit dem Verfahren beschriebenen Ausgestaltungsvarianten und die damit verbundenen Vorteile sind sinngemäß auf das erfindungsgemäße System zu übertragen. Im engeren Sinne umfasst das erfindungsgemäße System ausschließlich die genannten Speicherbereiche (Hubs) , die zugeordneten Applikationen sowie optional den vorstehend beschriebenen Speichertreiber. Das System ist in diesem Sinne ausschließlich aus Softwarekomponenten gebildet. In einem weiteren Sinne umfasst das erfindungsgemäße System zusätzlich den Cloud Storage, bei dem es sich um einen Hardware-Speicher mit einer darauf laufenden, cloud- internen Verwaltungssoftware handelt, sowie mindestens ein Device, das mit dem Public Cloud Storage über das Internet verbunden ist. Bei dem Device handelt es sich insbesondere um einen Personal -Computer (PC) , ein Notebook, einen Tablet-Computer oder ein Smartphone . Nachfolgend werden Ausführungsbeispiele der Erfindung anhand einer Zeichnung näher erläutert. Darin zeigen:
FIG 1 in einem schematischen Blockschaltbild ein System zur Verwaltung und Bearbeitung von Daten einer me- dizinischen Einrichtung, mit mehreren Modalitäten und Nutzer- oder Endgeräten (Devices) sowie mit einer mit den Modalitäten und Devices über das Internet verbundenen Public Cloud, FIG 2 in einem schematischen Blockschaltbild den softwaretechnischen Aufbau des Systems, wonach das System für verschiedene Arten von Daten der medizinischen Einrichtung in einem Cloud Storage der Public Cloud jeweils spezifisch zugeordnete Speicherberei- che (Hubs) aufweist, nämlich einen Patient-Hub für
Patientendatensätze, einen Worklist-Hub für Aufgaben, einen Context-Hub für Kontextdatensätze und einen Image-Hub für Bilddatensätze, und wobei das System auf jedem Device für jeden Hub eine zugeord- nete Applikation zum Zugriff auf die in diesem Hub gespeicherten Datensätze enthält, wobei in den drei erstgenannten Hubs jeweils ein Tabellenspeicher (Table Storage) angelegt ist, in dem zu jedem Datensatz des Hubs ein zugeordneter Tabelleneintrag (Tweet) enthalten ist, und wobei jede Applikation dazu eingerichtet, den Tabellenspeicher des zugehörigen Hubs zu durchsuchen (Browsing) und eine Ergebnisliste (Feed) ausgewählter Tweets zu extrahieren und anzuzeigen, und wobei die dem Image-Hub zu- geordnete Applikation zur Anzeige (Viewing) der
Bilddatensätze eingerichtet ist, in schematischer Darstellung eine Seite einer Benutzeroberfläche einer zum Ablauf auf einem
Smartphone vorgesehenen Applikation, die zur Anzeige eines Feeds des jeweils zugeordneten Hubs dient, in Darstellung gemäß FIG 3 eine weitere Seite der Benutzeroberfläche der dortigen Applikation, die zur Anzeige eines Tweets des zugehörigen Hubs dient , in Darstellung gemäß FIG 3 eine Seite der Benutzeroberfläche der dem Image-Hub zugeordneten Applikationen, die zur Darstellung der Bildinformation eines Bilddatensatzes dient, in Darstellung gemäß FIG 3 eine zum Ablauf auf einem Personal-Computer, Notebook oder Tablet- Computer vorgesehene Variante der dortigen Applikation, bei der mehrere Seiten der Benutzeroberfläche gleichzeitig darstellbar sind, und in Darstellung gemäß FIG 6 eine weitere Seite der Benutzeroberfläche, die zur Darstellung der Bildinformation eines Bilddatensatzes dient, in einem schematischen Blockschaltbild eine alternative Ausführung des Systems, bei dem die dem Image-Hub zugeordnete Viewing-Applikation getrennte Module zum Anzeigen von 2D-Bilddaten und Volumendaten enthält, in Darstellung gemäß FIG 8 eine weitere Ausführungsform des Systems, wobei dem Image-Hub zwei selbstständige Applikationen zugewiesen sind, näm- lieh eine 2D-Viewing-Applikation zum Anzeigen von
2D-Bildern und eine 3D-Viewing-Applikation zur visuellen Darstellung von Volumendaten, und FIG 10 in Darstellung gemäß FIG 8 eine weitere Ausführungsform des Systems, bei der eine Modalität mit einem Speichertreiber zum unmittelbaren Laden von Bilddaten in den Image-Hub des Cloud Storage aus- gestattet ist.
Einander entsprechende Teile und Größen sind in allen Figuren stets mit gleichen Bezugszeichen versehen. FIG 1 zeigt in grober schematischer Vereinfachung ein System 1 zur Verwaltung und Bearbeitung von medizinischen Daten einer medizinischen Einrichtung 2, bei der es sich beispielsweise um eine Klinik handelt. Hardwareseitig umfasst das System 1 eine Anzahl von Modalitäten 3, also bildgebenden, medizinischen Untersuchungsgeräten der Einrichtung 2. So umfasst das System 1 in der beispielhaften Darstellung gemäß FIG 1 einen Computertomographen 4, ein C-Bogengerät 5 und einen Magnetresonanztomographen 6. Je- der Modalität 3 ist ein (Steuer- und Auswerte- ) Rechner 7 zugeordnet .
Weiterhin umfasst das System 1 hardwareseitig eine Anzahl von Nutzer- oder Endgeräten (nachfolgend Devices 8) der Einrich- tung 2, die zur Anzeige und Bearbeitung von Daten dienen. In dem vereinfachten Beispiel gemäß FIG 1 umfassen die Devices 8 einen Personalcomputer 9 mit angeschlossenem Bildschirm 10, einen Tablet-Computer 11 sowie ein Smartphone 12. Als außerhalb der Einrichtung 2 angeordneten Bestandteil umfasst das System 1 eine Public Cloud 13. Als Public Cloud 13 wird im Rahmen des System 1 beispielsweise der von der Firma Microsoft unter der Bezeichnung „Windows Azure" angebotene Dienst genutzt. Abweichend hiervon können im Rahmen der Er- findung allerdings auch eine andere Public Cloud oder eine Kombination mehrerer Public Clouds (gegebenenfalls auch von unterschiedlichen Anbietern) als Public Cloud 13 herangezogen werden . ± g
Die Public Cloud 13 ist über ein (Datenübertragungs- ) etz 14 mit den einrichtungsinternen Komponenten des Systems 1, also den Modalitäten 3 und Devices 8 verbunden. Diese Netzverbin- dung ist innerhalb der Einrichtung 2 durch ein Intranet 15 der Einrichtung 2 gebildet, das beispielweise als sogenanntes Local Area Network (LAN) auf Basis kabelgebundener Ethernet- Technologie und/oder als kabelloses Wireless Local Area Network (WLAN) aufgebaut ist. Außerhalb der Einrichtung 2 ist das Netz 14 durch das Internet 16 gebildet. An der Schnittstelle zwischen dem Intranet 15 und Internet 16 ist in üblicher Weise eine Firewall 17 angeordnet.
Die von der Public Cloud 13 im Rahmen des Systems 1 zur Verfügung gestellten Dienste sind durch einen als Subscription 18 bezeichneten Nutzungsvertrag festgelegt. Die Subscription 18 regelt dabei, welche Hardware- und Softwarebestandteile der Public Cloud 13 den einrichtungsinternen Komponenten des Systems 1 zugänglich sind. Mit dem Begriff Subscription 18 wird daher nachfolgend derjenige Teil der Public Cloud 13 bezeichnet, der der Einrichtung 2 im Rahmen des Systems 1 exklusiv zugeordnet ist. Andere Bereiche der Public Cloud 13 können - wie in FIG 1 angedeutet - im Rahmen weiterer Subsc- riptions 18' weiteren medizinischen Einrichtungen 2' zugewiesen sein. Jede Einrichtung 2,2' hat hierbei ausschließlich Zugang zu den ihr gemäß ihrer Subscription 18,18' zugewiesenen Daten und Diensten, nicht aber zu den Daten und Diensten anderer Einrichtungen 2 bzw. 2'. Die Public Cloud 13 ist in diesem Sinne „mandantenfähig" (multi-tenant) .
Gemäß der Subscription 18 sind dem System 1 der Einrichtung 2 innerhalb der Public Cloud 13
- ein nachfolgend als Cloud Storage 19 bezeichneter Daten- Speicher,
- ein nachfolgend als App Store 20 bezeichneter Speicher für Applikationen (Anwendungssoftware) sowie
- Cloud-Compute-Dienste 21 zur Verfügung gestellt. Der Cloud Storage 19 dient zur persistenten Speicherung der Daten der Einrichtung 2. Der App Store 20 stellt Applikationen, Treiber und sonstige Periphe- riesoftware wie beispielsweise Konfigurationsdateien und Vorlagen (Templates) zur Verfügung, die von den einrichtungsinternen Komponenten des Systems 1, also den Modalitäten 3 und den Devices 8 heruntergeladen werden können und im Betrieb des Systems 1 auf den Modalitäten 3 (genauer gesagt den zuge- ordneten Rechnern 7) bzw. auf den Devices 8 ablaufen. Die
Cloud-Compute-Dienste 21 werden im Rahmen des Systems lediglich optional für alle Rechenoperationen herangezogen, die nicht auf den Modalitäten 3 oder den Devices 8 selbst vorgenommen werden. Letzteres betrifft insbesondere die rechen- leistungsintensive Aufbereitung von 3D-Bilddaten (Volumendaten) der jeweiligen Modalität 3 für die Speicherung (Prepro- cessing) und/oder die Ableitung von gerenderten Ansichten V (Szenen oder Scene-Graphs) für die zweidimensionale Visualisierung (Bildsynthese, Volume Rendering) solcher Volumenda- ten.
Die im Rahmen der Einrichtung 2 zu verwaltenden und zu bearbeitenden Daten umfassen gemäß FIG 2 Patientendatensätze P, Aufgaben W, Kontextdatensätze C und Bilddatensätze B, wobei diese Daten im Einzelnen jeweils die vorstehend näher erläuterten Inhalte haben. Bilddatensätze B können hierbei medizinische Bilddaten oder Volumendaten oder eine sonstige Bild-, Ton-, Graphik- oder Textinformation (Photos, Videos, Dokumente) enthalten.
Gemäß FIG 2 ist für jede dieser verschiedenen Datenarten (Ressourcen) innerhalb des Cloud Storage 19 jeweils ein separater Speicherbereich angelegt, der nachfolgend als (Ressource-) Hub bezeichnet ist. Im Einzelnen sind in dem Cloud Stora- ge 19 somit
- ein (Patient- ) Hub 22 zur Speicherung der Patientendatensätze P, - ein (Worklist- ) Hub 23 zur Speicherung der Aufgaben W,
- ein (Context- ) Hub 24 zur Speicherung der Kontextdatensätze C sowie
- ein ( Image- ) Hub 25 zur Speicherung der Bilddatensätze B angelegt.
Jeder der Hubs 22-24 enthält jeweils einen Tabellenspeicher (nachfolgend als Table Storage 26 bezeichnet) . Im Rahmen des Systems 1 wird für jeden gespeicherten Datensatz in dem Table Storage 26 des jeweils zugeordneten Hubs 22-24 ein Tabelleneintrag angelegt, der nachfolgend als Tweet 27 bezeichnet ist. Bei Datensätzen, die ihrer Natur nach aus vergleichsweise wenigen, diskreten Angaben bestehen, ist dabei der gesamte Datensatz als Tweet 27 im Table Storage 26 des jeweiligen Hubs 22-24 gespeichert. Dies betrifft im Beispiel gemäß FIG 2 die Patientendatensätze P, die Aufgaben W, sowie die Kontextda- tensätze C. Anstelle des Table Storage 26 kann der Worklist- Hub 23 zur Speicherung der Aufgaben W nach einem First-in- first-out-Prinzip allerdings auch einem sogenannten Queue- Storage aufweisen. Zur Speicherung der Bilddatensätze B, die in der Regel im Wesentlichen aus einem größeren und meist nicht-alphanumerischen Datenblock gebildet sind, ist im Image Hub 25 anstelle eines Table-Storage 26 ein sogenannter Blob-Storage 28 vorgesehen. Zu den in dem Image Hub 25 gespeicherten Bilddatensät- zen B ist in dem Kontext Hub 24 jeweils ein Kontextdatensatz C in Form eines Tweets 27 hinterlegt. Dieser Tweet 27 enthält zumindest einen URI 29 (Uniform Ressource Identifier) , der den Speicherort des Bilddatensatzes B im Blob-Storage 28 des Image Hubs 25 bezeichnet.
Für jeden der Hubs 22-25 wird im App Store 20 eine Applikation 31-34 zur Verfügung gestellt, die jeweils selektiv zur Darstellung und zur Bearbeitung der in dem jeweils zugeordne- ten Hub 22-25 gespeicherten Datensätze dient. Jede der Applikationen 31-34 repräsentiert somit den zugeordneten Hub 22-25 auf der Ebene des Devices 8. Die Applikationen 31-34 sind daher - in Anlehnung an die Ressource-Hubs - auch als „Applica- tions-Hubs" bezeichnet.
Im Einzelnen umfassen die im App Store 20 zur Verfügung gestellten Applikationen somit - eine Applikation 31 zur Verwaltung und Bearbeitung der in dem Patient-Hub 22 gespeicherten Patientendatensätze P,
- eine Applikation 32 zur Verwaltung und Bearbeitung von Aufgaben W,
- eine Applikation 33 zur Verwaltung und Bearbeitung von
Kontextdatensätzen C, sowie
- eine Applikation 34 zur Anzeige und Bearbeitung der in dem Image-Hub 25 gespeicherten Bilddatensätze B. Die Applikationen 31-34 können aus dem App Store 20 auf jedes der Devices 8 heruntergeladen und dort zur Ausführung gebracht werden. Sofern das System 1 - wie in FIG 1 dargestellt - unterschiedliche Arten von Devices (z.B. Personal -Computer 9, Tablet-Computer 11 und/oder Smartphones 12) umfasst, wer- den in dem App Store 20 jeweils verschiedene Versionen der Applikationen 31-34 zur Verfügung gestellt, die zum Ablauf auf dem jeweiligen Device 8 angepasst sind.
Beispielsweise werden die Applikationen 31-34 zum Ablauf auf dem Tablet-Computer 11 und dem Smartphone 12 in Form einer an den jeweiligen Gerätetyp angepassten App zur Verfügung gestellt, während die für den Personal -Computer 9 zur Verfügung gestellte Versionen der Applikationen 31-34 für den Ablauf in einem Internet-Browser konzipiert sind.
Im Vergleich zu einer herkömmlichen IT-Struktur für die Verwaltung von medizinischen Daten übernehmen der Patient Hub 22 und die zugeordnete Applikation 31 aus Sicht des Nutzers etwa die Funktion eines herkömmlichen Krankenhaus-Informationssystems (HIS) . Insbesondere sind die gesamten personenbezogenen (und datenschutzrelevanten) Patientendaten in dem Patient-Hub 22 aufgenommen, der somit für den einzelnen Patienten eine elektronische Patientenakte abbildet. Die übrigen Hubs 23-25 enthalten vorzugsweise keine Information, die aus sich heraus einem bestimmten Patienten zuordenbar wäre (Privacy Information) . Der Worklist-Hub 23 und die zugeordnete Applikation 32 stellen sich dem Nutzer im Wesentlichen als Ent- sprechung zu einem herkömmlichen Radiologie-Informationssystems (RIS) dar, indem sie die innerhalb der Einrichtung 1 zur Durchführung anstehenden Aufgaben auflisten. Der Context- Hub 24 und die zugeordnete Applikation 33 übernehmen aus Nutzersicht etwa die Funktion eines herkömmlichen PACS, indem dort die zur Auffindung und Verarbeitung von Bilddatensätzen B erforderliche Information hinterlegt und recherchierbar ist. Der Image-Hub 25 und die zugeordnete Applikation 34 übernehmen schließlich etwa die Funktion eines herkömmlichen AV-Systems .
Obwohl die in den Hubs 22-25 und den zugeordneten Applikationen 31-34 enthalten Funktionen hochgradig miteinander verknüpft sind, ist jeder der Hubs 22-25 zusammen mit der jeweils zugeordneten Applikation 31-34 auch unabhängig von den jeweils anderen Hubs 22-25 und deren Applikationen 31-34 betreibbar. So kann beispielsweise auf einen in dem Image-Hub 25 enthaltenen Bilddatensatz B auch ohne den zugehörigen Kontextdatensatz C des Context-Hubs 24 zugegriffen werden, wenn der dem Image-Hub 25 zugeordneten Application 34 der URI 29 des anzuzeigenden Bilddatensatzes B auf andere Weise verfügbar gemacht wird, z.B. per E-Mail, SMS oder Twitter. Ferner können die Patientendaten P auch außerhalb der Public Cloud 13 vorgehalten werden, da der Patient-Hub 22 für die Funktion der übrigen Hubs 23-25 und der zugeordneten Applikationen 32- 34 nicht erforderlich ist.
Ein Kernelement der dem Patienten-Hub 22 zugeordneten Applikation 31 ist eine sogenannte Browsing-Funktion, die den Tab- le Storage 26 des Patient-Hubs 22 nach Tweets 27 durchsucht, die einem bestimmten, von einem Nutzer vorgebbaren Suchbegriff entsprechen. Von dem Patient-Hub 22 wird hierbei auf eine Suchanfrage Q (FIG 2) der Applikation 31 hin eine nachfol- gend als Feed 35 bezeichnete Ergebnisliste, die die der Suchanfrage Q entsprechenden Tweets 27 enthält, an die Applikation 31 zurückgeliefert. Die Applikation 31 zeigt den erhaltenen Feed 35 auf dem Device 8 auf einer in FIG 3 exemplarisch dargestellten Seite 36 einer graphischen Benutzeroberfläche 37 an.
In der exemplarischen Ausführung gemäß FIG 3 weist die Seite 36 im Wesentlichen vier Anzeigebereiche unterschiedlicher Funktion auf, nämlich eine Kopfzeile 40, ein Suchfeld 41, ein Anzeigefeld 42 und eine Befehlsleiste 43. In der Kopfzeile 40 ist der Hub 22-24 namentlich benannt, dem die Applikation 31 zugeordnet ist. Im Beispiel der Applikation 31 ist die Kopf- zeile 40 somit z.B. mit dem Wort „Patient Hub" beschriftet. Des Weiteren ist in der Kopfzeile 40 vorzugsweise die Ein- richtung 2 benannt, der das System 1 zugeordnet ist.
Das Suchfeld 41 enthält eine Eingabezeile 44, über die ein alphanumerischer Suchbegriff eingegeben werden kann, sowie eine Schaltfläche 45, durch deren Betätigung von einem Nutzer eine Suchanfrage Q auf Basis des zuvor in der Eingabezeile 44 eingegebenen Suchbegriffs gestartet werden kann.
Zusätzlich oder alternativ enthält das Suchfeld 41 ein Vorauswahlfeld 46, über das ein oder mehrere voreingestellte Suchbegriffe durch Antippen (im Falle eines berührungssensitiven Bildschirms) oder Anklicken mit einem gegebenenfalls vorhandenen Zeigergerät ausgewählt werden können.
Bei den über das Vorauswahlfeld 46 generierbaren Suchbegrif- fen handelt es sich insbesondere um häufig verwendete Suchschemata. Beispielsweise ermöglicht das Vorauswahlfeld 46 im Falle der mit dem Patient-Hub 22 korrespondierenden Applikation 31 eine Vorauswahl dahingehend, ob - alle Tweets 27 („all") oder
- nur solche Tweets 27 zu Patienten, für die Untersuchungen angesetzt sind („ scheduled" ) oder
- nur solche Tweets 27 zu Patienten, bei denen die zurückliegenden Leistung bereits abgerechnet wurden („billed") als Feed 35 zurückgeliefert werden sollen. Optional ist vorgesehen, dass bei Generierung eines Suchbegriffs über das Vorauswahlfeld 26 eine alphanumerische Entsprechung dieses Suchbegriffs automatisch in der Eingabezeile 44 angezeigt wird. Im Anzeigefeld 42 wird der aufgrund einer Suchabfrage Q zurückgelieferte Feed 35 angezeigt. Das Anzeigefeld 42 enthält somit in Form einer Liste diejenigen Tweets 27, die aufgrund der Suchanfrage Q der Applikation 31 in dem Patient-Hub 22 gefunden wurden. Zu jedem Tweet 27 werden beispielsweise ein verkleinertes Bild 47 und/oder ein Schlagwort 48 angezeigt.
So werden bei der dem Patient-Hub 22 zugeordneten Applikation 31 zu jedem anzeigten Tweet 27 vorzugsweise ein verkleinertes Bild des Patienten sowie der Name des Patienten und optional eine Patientenidentifikationsnummer angezeigt. Die Suchanfra- ge Q, und der aufgrund dieser zurückgelieferte Feed 35 können von einem Nutzer interaktiv geändert werden.
Die Suche wird basierend auf einer Syntax gemäß REST bzw. OData (Open Data Protocoll Standard) definiert. Sie ist grundsätzlich ähnlich zu einer WHERE-Klausel nach dem SQL- Standard, ist jedoch im Gegensatz zu der letzteren nicht von einer statischen Re-Indexierung abhängig. Insbesondere benötigen die Tabellen eines Hubs keine Index-Elemente für die Suche, weshalb auch keine Re-Indexierung erforderlich ist, und entsprechend auch keine eigenen Daten-Server oder Datenbank-Server vorgehalten werden müssen. Durch einfaches Antippen oder Anklicken eines im Anzeigefeld 42 angezeigten Tweets 27 kann dieser Tweet 27 von einem Nutzer ausgewählt werden. Die Befehlsleiste 43 enthält eine Anzahl von Schaltflächen 49 und 50, durch deren Betätigung von einem Nutzer elementare Operationen zur Steuerung der Benutzeroberfläche 37 und zum Verwalten und Bearbeiten des angezeigten Feeds 35 vorgenommen werden können.
Die Applikation 31 ist in der in FIG 3 dargestellten Version für die Darstellung auf dem Smartphone 12 optimiert. Dabei wird auf dem Smartphone 12 zu jedem Zeitpunkt stets nur eine einzelne Seite 36 mit einem einzelnen Feed 35 angezeigt. Al- lerdings können mehrere Instanzen der Seite 36 oder mehrere
Instanzen der gesamten Applikation 31 parallel zueinander generiert werden, wobei diese Instanzen im Hintergrund der Anzeige nebenläufig auf dem Smartphone 12 ausgeführt werden. Somit können insbesondere mehrere Suchanfragen Q parallel zu- einander abgearbeitet werden. Die Applikation 31 oder gegebenenfalls mehrere Instanzen der Applikation 31 laufen hierbei vorzugweise in einem generischen Rahmenmodul 51 (oder Container) ab. Dieses Rahmenmodul 51 kann beispielsweise als separate Applikation oder als Plug-in zu einem Web-Browser imple- mentiert sein. Alternativ kann die Applikation 31 jedoch auch zum unmittelbaren Ablauf in einem Web-Browser ausgebildet sein, z.B. als HTML5 -Applikation .
Die Schaltflächen 50 der Befehlsleiste 43 ermöglichen hierbei einen Wechsel zwischen den laufenden Instanzen der Applikation 31, indem bei Betätigung einer der Schaltflächen 50 die angezeigte Seite 36 der Nutzeroberfläche 37 ausgeblendet und die entsprechende Seite 36 einer anderen Instanz der Applikation 31 angezeigt wird.
Die weiteren Schaltflächen 49 der Befehlszeile 43 sind insbesondere folgenden Funktionen zugeordnet: - „Create": Auf Betätigung der entsprechenden Schaltfläche 49 hin werden eine neue Seite 36 der Benutzeroberfläche 37, ggf. zusammen mit einer neuen Instanz der Applikation 31 erzeugt.
- „Delete": Auf Betätigung der entsprechenden Schaltfläche
49 hin werden die angezeigte Seite 36 der Benutzeroberfläche 37, ggf. zusammen mit der zugehörigen Instanz der Applikation 31 beendet,
- „Read": Auf Betätigung der entsprechenden Schaltfläche 49 hin wird eine - in FIG 4 schematisch dargestellte - weitere Seite 52 der Benutzeroberfläche 37 geöffnet, in der der Dateninhalt des ausgewählten Tweets 27 zur bloßen Ansicht oder zur Veränderung angezeigt wird. Die Seite 52 umfasst gemäß FIG 4 ebenfalls vier Bereiche, nämlich eine Kopfzeile 60, ein Überschriftenfeld 61, ein Anzeigefeld 62 sowie eine Befehlsleiste 63.
Die Kopfzeile 60 weist hierbei - analog zu der Kopfzeile 40 der Seite 36 - den zugeordneten Hub 22-24 und die Einrichtung 2 aus. Das Überschriftenfeld 61 kennzeichnet die Art des angezeigten Datensatzes und enthält somit im Falle der Applikation 31 beispielsweise das Wort „Patient" (oder „Patient En- tity") .
In dem Anzeigefeld 62 wird der Inhalt des ausgewählten Tweets 27 - im Falle der Applikation 31 somit der Inhalt des (Patienten- ) Datensatzes - dargestellt. In diesem Fall werden in dem Anzeigefeld 62 insbesondere die Feldnamen 67 des Patien- ten-Datensatzes (zum Beispiel „Vorname", „Nachname", „Patien- ten-ID", „Alter", ...) zusammen mit dem jeweiligen Feldinhalt 68 (zum Beispiel also dem konkreten Vornamen, Nachnamen, der konkreten Patienten- ID bzw. dem konkreten Alter des Patienten dargestellt) .
Die Befehlszeile 63 enthält Schaltflächen 64, denen insbesondere folgende Funktionen zugewiesen sind: - „Create": Auf die Betätigung der entsprechenden Schaltfläche 64 hin wird eine neue Instanz der Seite 52 zur Anlage eines neuen Tweets 27 und somit eines neuen (Patienten- ) Datensatzes P erzeugt.
- „Update": Auf die Betätigung der entsprechenden Schaltfläche 64 hin werden die - gegebenenfalls geänderten - Feldinhalte 68 gespeichert, indem die Applikation 31 den angezeigten Tweet 27 unmittelbar im Table Storage 26 des Patient-Hubs 22 mit den geänderten Angaben überschreibt. - „Delete": Auf die Betätigung der entsprechenden Schaltfläche 64 hin wird der angezeigte Tweet 27 durch die Applikation 31 unmittelbar im Table Storage 26 des Patient-Hubs 22 gelöscht; die angezeigte Seite 52 wird geschlossen .
Darüber hinaus enthält die Befehlszeile 63 eine Schaltfläche 65, auf deren Betätigung hin die Applikation 31 die angezeigte Seite 52 ohne Veränderung des Tweets 27 schließt und die zugrundeliegende Seite 36 erneut anzeigt.
Die Befehlszeilen 43 und 63 können weitere Schaltflächen für Befehle aufweisen. Ebenso können auch eine oder mehrere der anhand der Schaltflächen 49, 50, 64 und 65 beschriebenen Funktionen einem der gegebenenfalls vorhandenen elektromecha- nischen Tasten des Smartphones 12 zugeordnet sein. Die jeweilige Schaltfläche ist in diesem Fall vorzugsweise aus der Befehlszeile 43 entfernt.
Die Applikationen 32 und 33 haben jeweils eine der Applikati - on 31 entsprechende Browsing-Funktion . Insbesondere weist auch die jeweilige Benutzeroberfläche 37 der Applikationen 32 und 33 jeweils die anhand der FIG 3 und 4 beschriebenen Seiten 36 und 52 auf. Allerdings greifen die Applikationen 32 und 33 auf den
Worklist-Hub 23 bzw. auf den Context-Hub 24 zu, und sind entsprechend angepasst. So enthalten insbesondere - die im Rahmen der Applikation 32 angezeigten Tweets 27 Angaben zu einer bestimmten Aufgabe W (beispielsweise Angaben zu dem Einstellungsdatum der Aufgabe, der mit der Aufgabe betreuten Abteilung, sowie Angaben zu der Aufgabe selbst und dem Taskflow, in den diese Aufgabe gegebenenfalls eingebunden ist) , und
- die im Rahmen der Applikation 33 angezeigten Tweets 27 den Inhalt jeweils eines Kontext-Datensatzes C, insbesondere Angaben zum Dokumententyp, Speicherort, Daten- format sowie optional Aufnahmeparameter zu einem Bilddatensatz B.
Die Applikation 34 dient dagegen zur Anzeige („Viewing") des nicht-alphanumerischen Inhalts eines im Image-Hub 25 gespei- cherten Bilddatensatzes B. Hierfür umfasst die graphische Benutzeroberfläche 37 der Applikation 34 eine in FIG 5 dargestellte Seite 69. Ebenso wie die Seite 52 enthält auch die Seite 69 eine Kopfzeile 70, ein Überschriftenfeld 71, ein Anzeigefeld 72 und eine Befehlszeile 73. In dem Überschriften- feld 71 ist hierbei beispielsweise die Art des angezeigten Bilddatensatzes B spezifiziert (z.B. als „ 2D-Viewing" , 3D- Viewing", "Media-Viewing" , „Document-Viewing" , etc.) . Im Anzeigefeld 72 wird der visuelle Inhalt des Bilddatensatzes B, also beispielsweise das Bild, Volumen, Video oder Textdoku- ment angezeigt. Die Befehlszeile 73 enthält neben der Schaltfläche 65 weitere Schaltflächen 74 zur Beeinflussung der Anzeige, beispielsweise zum Vergrößern oder Verkleinern des im Anzeigefeld 72 angezeigten Dateninhalts oder um Verschieben eines angezeigten Bildausschnitts. Außerdem kann eine Schalt- fläche 74 zum Löschen eines Bilddatensatzes B vorgesehen sein .
Anstelle der gemeinsamen Seite 69 zur Anzeige unterschiedlicher Datentypen kann die Applikation 33 auch verschiedene Viewingseiten umfassen, die jeweils zur Anzeige eines bestimmten Dokumententyps (Bild, Volumen, Video, Textdokument, etc.) eingerichtet sind. Bezüglich der Anzeige von Volumendaten (3D-Viewing) ist die Applikation 34 in zwei Betriebsmodi betreibbar, nämlich in
- einem „Device-Only-Modus", in dem die für die Anzeige der Volumendaten auf dem zweidimensionalen Bildschirm erforderlichen Rechenschritte, insbesondere die Anfertigung von gerenderten Ansichten V, auf dem Device 8 selbst vorgenommen werden, sowie
- einem „Cloud-Service-Modus", in dem die Applikation 34 für diese Rechenoperationen durch eine entsprechende Anfrage R (FIG 2) Cloud-Compute-Dienste 21 anfordert.
Im Device-Only-Modus greift die Applikation 34 unmittelbar auf die im Blob-Storage 28 des Image-Hubs 25 gespeicherten Bilddatensätze B zu . Im Cloud-Service-Modus werden die Bilddaten B durch Cloud-Compute-Dienste 21 bearbeitet, wobei lediglich die resultierenden zweidimensionalen Ansichten V von der Cloud 13 an die Applikation 34 geliefert werden. Aufgrund entsprechender Voreinstellung arbeitet die Applikation 34 von Haus aus im Cloud-Service-Modus und schaltet nur dann in den Device-Only-Modus, wenn die Netzverbindung mit der Public Cloud 13 eine vorgebebene Mindestqualität unterschreitet.
Bevorzugt enthält die Applikation 34 zusätzlich Funktionen zur Bearbeitung der Bilddaten, insbesondere zur Vermessung und/oder Segmentierung von Bildstrukturen und/oder zur Einbringung von Markierungen und/oder Annotationen. Zur Unterstützung der medizinischen Befundung der angezeigten Bilddaten enthält die Applikation 34 ferner eine Funktion zur Er- Stellung eines sogenannten Keyimage K (FIG 2) . Wie verstehend erwähnt, handelt es sich hierbei um einen Schnappschuss , also eine Kopie der Bildinformation des angezeigten Bildausschnitts. Die Applikation 34 ist hierbei dazu eingerichtet, erstellte Keyimages K auf entsprechenden Nutzerbefehl direkt als Bilddatensatz B in dem Blob-Speicher 28 des Image-Hubs 25 zu hinterlegen. Die Applikationen 32-34 oder gegebenenfalls mehrere Instanzen dieser Applikationen 32-34 laufen ebenfalls bevorzugt in dem Rahmenmodul 51. Vorzugsweise ist hierbei - wie schematisch in FIG 2 angedeutet - ein gemeinsames Rahmenmodul 51 für alle Applikationen 31-34 vorgesehen. Alternativ kann aber auch jeder Applikation 31-34 ein eigenes Rahmenmodul zugeordnet sein .
Die Kommunikation zwischen jedem der Hubs 22-25 und der je- weils zugewiesenen Applikation 31-34 ist so gestaltet, dass sie mit dem im Internet-Datenverkehr gebräuchlichen
REST (Representational State Transfer) -Prinzip kompatibel ist. Insbesondere genügen die zwischen den Hubs 22-25 und der jeweiligen Applikation 31-34 ausgetauschten Daten den Standards XML, JSON und ATOM. Bilddaten B sind im Image-Hub 25 insbesondere im JPEG-Format hinterlegt, Volumendaten vorzugsweise im DICOM-Format . Die gegebenenfalls von der Public-Cloud 13 an die Applikation 34 gelieferten Ansichten V (Scene-Graphs) von Volumendaten werden vorzugsweise im JPEG-Format erstellt.
Für den unmittelbaren Zugriff auf die in dem jeweiligen Hub 22-25 gespeicherten Daten nutzt jede Applikation 31-34 einen mehrfach instantiierbaren Cloud-Treiber, der in Form einer Anwender-Programmier-Schnittstelle (API) vorliegt.
Jede der Applikationen 31-33 ist dazu eingerichtet, Feeds 35 auf Anweisung des Nutzers aus dem zugehörigen Hub 22-24 in einen lokalen Speicher des Device 8 zu externalisieren, so dass dieser Feed 35 und die darin enthaltenen Tweets 27 durch die Applikation 31-33 auch ohne Netzanbindung mit der Public Cloud 13 angezeigt und/oder bearbeitet werden können. Weiterhin ist jede Applikation 31-33 dazu eingerichtet, auf entsprechenden Befehl des Nutzers externalisierte Feeds 35 oder Tweets 27 an eine andere Instanz derselben oder einer anderen Applikation 31-34 zu übermitteln. Für die geräteinterne Übermittlung der Feeds 35 oder Tweets 27 ist im Speicher des Device 8 ein als „Exchangeboard" bezeichneter lokaler Speicherbereich eingerichtet, auf den alle Instanzen der Applikatio- nen 31-34 gemeinsam zugreifen. Zum Austausch über das Exchangeboard werden die auszutauschenden Feeds 35 oder Tweets 27 in XML/JSON-Files serialisiert , die im lokalen Speicher des Devices 8 abgelegt und anschließend wieder deserialisiert werden. Zum Austausch von Feeds 35 und Tweets 27 zwischen verschiedenen Devices 8 weisen die Applikationen 31-34 bevorzugt Schnittstellen zu Twitter oder einem E-Mail -Programm auf . FIG 6 zeigt eine Variante der Applikationen 31-33, bei der die Benutzeroberfläche 37 für die Anzeige auf einem großformatigen Bildschirm, beispielsweise dem Bildschirm 10 des Personal-Computers 9 oder dem Bildschirm des Tablet-Computers 11 optimiert ist. Die Benutzeroberfläche 37 gemäß FIG 6 unter- scheidet sich von der in den FIG 3 und 4 gezeigten Benutzeroberfläche 37 im Wesentlichen dadurch, dass mehrere Instanzen der Applikationen 31-33 und die entsprechenden Seiten 36 und/oder 52 der Benutzeroberfläche 37 nebeneinander (und somit gleichzeitig) sichtbar sind.
In der Darstellung gemäß FIG 6 weist die Benutzeroberfläche 37 weiterhin zusätzliche Navigations-Schaltflächen 50 auf, durch deren Betätigung wiederum zwischen den angezeigten Seiten 36 und/oder 52 geblättert werden kann.
Außerdem weist die Benutzeroberfläche 37 zusätzlich eine Menüzeile 80 auf, durch deren Betätigung zwischen den verschiedenen Applikationen 31-34 gewechselt werden kann. Die Menüzeile 80 ist dabei insbesondere Bestandteil eines Rahmenmo- duls 81 (oder Containers) , in dem die bestehenden Instanzen der Applikationen 31-34 ablaufen.
FIG 7 zeigt eine zur Anzeige auf einem großformatigen Bildschirm optimierte Version der Seite 69 der Applikation 34, bei der das Anzeigefeld 72 nahezu die gesamte Bildschirmfläche ausfüllt. FIG 8 zeigt eine Variante des Systems 1, bei der die Applikation 34 zum Anzeigen von 2D-Bilddaten und Volumendaten ein (2D-Viewing- ) Modul 92 und ein hiervon unabhängiges (3D- Viewing- ) Modul 93 enthält. Die Applikation 34 ist hierbei in einer eingeschränkten Version auch mit lediglich einem der Module 92 bzw. 93 lauffähig. Das 2D-Viewing-Modul 92 greift hierbei zum Herunterladen des anzuzeigenden Bilddatensatzes B stets unmittelbar auf den Blob-Storage 28 des Image-Hubs 25 zu. Das 3D-Viewing-Modul 93 greift entweder ebenfalls unmit- telbar auf die im Image-Hub 25 gespeicherten Volumendaten zu oder nimmt zur Erstellung der Views V Cloud-Compute-Dienste 21 in Anspruch.
Um einen bestimmten Bilddatensatz B mittels der Applikation 34 anzuzeigen, wird zum Beispiel von der dem Kontext-Hub 24 zugeordneten Applikation 33 der zugehörige Tweet 27 ermittelt und über das Exchangeboard an die Applikation 34 übergeben. Anhand des in dem übergebenen Tweet 27 enthaltenen URI 29 lädt die Applikation 34 den Bilddatensatz B aus dem Image-Hub 25.
FIG 9 zeigt eine weitere Variante des Systems 1, bei der dem Image-Hub 25 anstelle der einzigen Applikation 34 eine 2D- Viewing-Applikation 94 und eine hiervon unabhängige 3D- Viewing-Applikation 95 zugeordnet sind.
Gemäß FIG 10 ist jede Modalität 3 des Systems 1 mit einem in dem Rechner 7 implementierten Speichertreiber 100 versehen. Der Speichertreiber 100, der in Form einer Anwender-Program- mier-Schnittstelle (API) für die Steuer- und Auswertesoftware der Modalität 3 vorliegt, ist hierbei dazu eingerichtet, einen von der Modalität 3 erzeugten und an den Speichertreiber 100 übergebenen Bilddatensatz B unmittelbar (ohne Inanspruchnahme von Cloud-Compute-Diensten 21) in den Blob-Storage 28 des Image-Hubs 25 zu schreiben. Weiterhin legt der Speichertreiber 100 einen zugehörigen Kontextdatensatz C als Tweet 27 in dem Table Storage 26 des Context-Hubs 24 an. Der Speichertreiber 100 wandelt die Bilddaten dabei vorzugsweise (jedenfalls sofern es sich bei den Bilddaten um 2D- Bilddaten handelt) in das JPEG-Format um, sofern die Modalität 3 die Bilddaten ursprünglich in einem anderen Datenformat erstellt. Im Falle von Volumendaten werden diese dagegen bevorzugt im DICOM-Format im Blob-Speicher 28 des Image-Hubs 25 abgelegt .
Ferner nimmt der Speichertreiber 100 optional weitere Datenaufbereitungsprozesse (Preprocessing) vor, bevor er den Bilddatensatz in dem Image-Hub 25 ablegt.
Die Erfindung wird an den vorstehend beschriebenen Ausführungsbeispielen besonders deutlich, ist gleichwohl auf diese aber nicht beschränkt. Vielmehr können weitere Ausführungsformen der Erfindung aus der vorliegenden Beschreibung und den Ansprüchen abgeleitet werden. Insbesondere können die anhand der Ausführungsbeispiele beschriebenen Einzelmerkmale der Erfindung auch in anderer Weise kombiniert werden, ohne von der Erfindung abzuweichen.
Als Anlagen beigefügt sind:
- Anlage 1: Ein Beispiel -Code für die Benutzeroberfläche des Rahmens 51 (App-Hub Container-GUI)
- Anlage 2: Ein Beispiel -Code für die Logik des Rahmens 51
(App-Hub Container Code)
- Anlage 3: Ein Beispiel -Code für den Speichertreiber 100
(Direct Storage Adapter) Anlage 1: Ein Beispiel -Code für die Benutzeroberfläche des Rahmens 51 (App-Hub Container-GUI)
<phone : PhoneApplicationPage
x : Class= "AzureTableStore_CRUD_Sample . PivotMainPage" xmlns= "http : //schemas . microsoft . com/winfx/2006/xaml/ ...
presentation"
xmlns : x= "http : //schemas .microsoft . com/winfχ/2006/xaml " xmlns : src= "clr-namespace :AzureTableStore_CRUD_Sample ; ...
assembly=AzureTableStore_CRUD_Sample"
xmlns : phone= "clrnamespace : Microsoft . Phone . Controls ; ...
assembly=Microsoft . Phone"
xmlns : Shell= "clr-namespace : Microsoft . Phone . Shell ; ...
assembly=Microsoft . Phone"
xmlns : controls= "clr-namespace : Microsoft . Phone . Controls ; ...
assembly=Microsoft . Phone . Controls " xmlns : d= "http : //schemas .microsoft . com/expression/...
blend/2008"
xmlns : mc= "http : //schemas . openxmlformats . org/...
markup-compatibility/2006 "
FontFamily= " { StaticResource PhoneFontFamilyNormal } "
FontSize= " {StaticResource PhoneFontSizeNormal } "
Foreground= " {StaticResource PhoneForegroundBrush} "
SupportedOrientations= " Portrait " Orientation= " Portrait " mc : Ignorable="d" d : DesignHeight= " 696 " d : DesignWidth= "480 " Shell : SystemTray . IsVisible= "True" >
<phone : PhoneApplicationPage . Resources>
<Storyboard x : ame= "ResetPageTransitionList "...
Completed= "OnResetPageTransitionList_Completed" >
<DoubleAnimationUsingKeyFrames Storyboard . TargetName=...
"ContentPanel " Storyboard . TargetProperty=...
" (UIElement . Proj ection) . (...
PlaneProj ection . RotationY) ">
<EasingDoubleKeyFrame KeyTime= " 00 : 00 : 00 "
Value="0" />
</DoubleAnimationUsingKeyFrames>
<DoubleAnimationUsingKeyFrames Storyboard . TargetName=... "ContentPanel " Storyboard . TargetProperty=... " (UIElement . Proj ection) . (...
PlaneProj ection . CenterOfRotationX) " >
<EasingDoubleKeyFrame KeyTime= " 00 : 00 : 00"...
Value="0" />
</DoubleAnimationUsingKeyFrames>
/Storyboard>
Storyboard x : ame= " PageTransitionList " Completed=...
"OnPageTransitionList_Completed" > <DoubleAnimationUsingKeyFrames Storyboard . TargetName
"ContentPanel " Storyboard . TargetProperty=... " (UIElement . Proj ection) . (...
PlaneProj ection . RotationY) ">
<EasingDoubleKeyFrame KeyTime= " 00 : 00 : 00 " Value="0" <EasingDoubleKeyFrame KeyTime="00 : 00 : 00.3 "...
Value="90">
<EasingDoubleKeyFrame . EasingFunction>
<CircleEase EasingMode= "Easeln" />
</EasingDoubleKeyFrame . EasingFunction>
</EasingDoubleKeyFrame>
</DoubleAnimationUsingKeyFrames>
<DoubleAnimationUsingKeyFrames Storyboard . TargetName
"ContentPanel " Storyboard . TargetProperty=... " (UIElement . Proj ection) . (...
PlaneProj ection . CenterOfRotationX) " >
<EasingDoubleKeyFrame KeyTime="00 : 00 : 00"
Value="0" />
<EasingDoubleKeyFrame KeyTime="00 : 00 : 00.3 "
Value="0">
<EasingDoubleKeyFrame . EasingFunction>
<CircleEase EasingMode= "Easeln" />
</EasingDoubleKeyFrame . EasingFunction>
</EasingDoubleKeyFrame>
</DoubleAnimationUsingKeyFrames>
/Storyboard>
hone : PhoneApplicationPage . Resources>
<Grid x:Name="LayoutRoot" Background= "Transparent " > Grid x:Name="ContentPanel" Grid.Row="l" Margin=...
"12, 0, 12, 0">
Grid . Proj ection>
<PlaneProj ection />
/Grid . Proj ection>
<controls : Pivot x : ame= "MainPivot " Title= "AppTitl
<controls : Pivot . Items>
</controls : Pivot . Items>
</controls : Pivot>
<StackPanel Grid.Row="l" Margin= " 12 , 0 , 12 , 0 "...
Orientation= "Vertical " VerticalAlignment=... "Bottom" >
<TextBlock Height= "Auto" HorizontalAlignment= " Margin="15, 2, 0, 0" Text= " {Binding Message,... Mode=TwoWay} " TextWrapping= "Wrap" />
<ProgressBar Height="20" Islndeterminate= "True" Visibility= " {Binding IsWorking, Converter= {StaticResource VisibilityConverter}}" /> </StackPanel>
</Grid>
/Grid> phone : PhoneApplicationPage .ApplicationBar>
<shell :ApplicationBar IsVisible= "True" >
<!-- will be set at runtime in view model -- <Shell :ApplicationBar . Menultems>
<!-- will be set at runtime in view model
</Shell :ApplicationBar . Menultems>
</shell :ApplicationBar>
/phone : PhoneApplicationPage .ApplicationBar> </phone : PhoneApplicationPage> Anlage 2: Em Beispiel -Code für die Logik des Rahmens 51 (App-Hub Container Code)
#define _VIEWING using System;
using System . Collections .Generic;
using System. Linq;
using System. Net;
using System . Windows ;
using System . Windows . Controls ;
using System . Windows . Documents ;
using System . Windows . Input ;
using System . Windows . Media ;
using System . Windows .Media .Animation;
using System . Windows . Shapes ;
using Microsoft . Phone . Controls ;
using Microsoft . Samples . WindowsPhoneCloud . Storage...
Client . Credentials ;
using Microsoft . Samples . WindowsPhoneCloud . StorageClient ; using System. Globalization;
using System . Windows . Controls . Primitives ;
using System . Windows .Navigation;
using Microsoft . Phone . Shell ;
using Microsoft . Samples . Data . Services . Client ;
using Microsoft . Samples . Data ;
using Microsoft . Samples . Data . Services . Common;
namespace AzureTableStore_CRUD_Sample
{
public partial class PivotMainPage : PhoneApplicationPage,
IMainPage
{
//
// VIEW GUI Page variables
// private string CurrentViewModel_StateStore =...
"CurrentViewModel_Normal_App" ;
private string AppFeed_All_StateStore = "AppFeed_Apps " ; private bool isNewPagelnstance = false;
private int externalNavigateToCounter = 0 ;
private string storedRequester = "";
private AppHubMainInternalApps internalApps ;
// constructor
public PivotMainPage ( )
{
InitializeComponent ( ) ;
// -- 19 -- CreateAppFeed ( ) ;
}
public void CreateAppFeed ( )
{
IsNewPagelnstance = true;
if (App .Applnstances . Count == 0)
{
MessageBox . Show ( "CreateAppFeed : there are no...
Applnstances available - there might be... network problems ...? Stop the program!"); return;
}
App .Applnstances [0] .0_CurrentViewModel = null; for (int i = 0; i < App .Applnstances . Count ; i++)
{
App . CurrAppIndex = i ;
switch (App .Applnstances [i] .M_Model)
{
case "Patient":
App .Applnstances [i] .0_AppFeed_Pivot =...
new AppFeed<Patient , PivotMainPage> (this , i) ; this.Loaded += new RoutedEventHandler ( (App .App... Instances [i] .0_AppFeed_Pivot as AppFeed<... Patient, PivotMainPage>) . OnPage_Loaded) ;
break; case "Worklist" :
App .Applnstances [i] .0_AppFeed_Pivot =...
new AppFeed<Worklist , PivotMainPage> (this , ... i) ;
this.Loaded += new RoutedEventHandler ( (App .App...
Instances [i] .0_AppFeed_Pivot as AppFeed<...
Worklist, PivotMainPage>) . OnPage_Loaded) ; break; case "Context " :
App .Applnstances [i] .0_AppFeed_Pivot =...
new AppFeed<Context , PivotMainPage> (this , i) ; this.Loaded += new RoutedEventHandler ( (App .App...
Instances [i] .0_AppFeed_Pivot as AppFeed<... Context, PivotMainPage>) . OnPage_Loaded) ;
break; ase "Score" :
App .Applnstances [i] .0_AppFeed_Pivot =...
new AppFeed<Score , PivotMainPage> (this , this.Loaded += new RoutedEventHandler ( (App .App.
Instances [i] .0_AppFeed_Pivot as AppFeed<.
Score, PivotMainPage>) . OnPage_Loaded) ; break; case "Kalle":
App .Applnstances [i] .0_AppFeed_Pivot =...
new AppFeed<Kalle , PivotMainPage> (this , i) ; this.Loaded += new RoutedEventHandler ( (App .App...
Instances [i] .0_AppFeed_Pivot as AppFeed<... Kalle, PivotMainPage>) . OnPage_Loaded) ; break; case "Sampletable" : App .Applnstances [i] .0_AppFeed_Pivot =...
new AppFeed<Sampletable , PivotMainPage>... (this, i) ;
this.Loaded += new RoutedEventHandler ( (App .App...
Instances [i] .0_AppFeed_Pivot as AppFeed<... Sampletable , PivotMainPage>) . OnPage_Loaded) ; break; se "Blob" :
App .Applnstances [i] .0_AppFeed_Pivot =...
new AppFeed<Blob, PivotMainPage> (this , i) ; this.Loaded += new RoutedEventHandler ( (App .App...
Instances [i] .0_AppFeed_Pivot as AppFeed<...
Blob, PivotMainPage>) . OnPage_Loaded) ;
break; se "QueueMessage" :
App .Applnstances [i] .0_AppFeed_Pivot =...
new AppFeed<QueueMessage , PivotMainPage>... (this, i) ;
this.Loaded += new RoutedEventHandler ( (App .App...
Instances [i] .0_AppFeed_Pivot as AppFeed<... QueueMessage, PivotMainPage>) . OnPage_Loaded) break; se "File" :
App .Applnstances [i] .0_AppFeed_Pivot =...
new AppFeed<File , PivotMainPage> (this , i) ; this.Loaded += new RoutedEventHandler ( (App .App...
Instances [i] .0_AppFeed_Pivot as AppFeed<...
File, PivotMainPage>) . OnPage_Loaded) ;
break; se "Twitter" :
App .Applnstances [i] .0_AppFeed_Pivot =...
new AppFeed<Twitter, PivotMainPage> (this , i) this.Loaded += new RoutedEventHandler ( (App .App...
Instances [i] .0_AppFeed_Pivot as AppFeed<... Twitter, PivotMainPage>) . OnPage_Loaded) ; break; case "ApplHub" :
App .Applnstances [i] .0_AppFeed_Pivot =...
new AppFeed<ApplHub, PivotMainPage> (this , this. Loaded += new RoutedEventHandler ( (App .App.
Instances [i] .0_AppFeed_Pivot as AppFeed<.
ApplHub, PivotMainPage>) . OnPage_Loaded) ; break; case "ApplFeed" :
App .Applnstances [i] .0_AppFeed_Pivot =...
new AppFeed<ApplFeed, PivotMainPage>... (this, i) ;
this. Loaded += new RoutedEventHandler ( (App .App.
Instances [i] .0_AppFeed_Pivot as AppFeed<. ApplFeed, PivotMainPage>) . OnPage_Loaded) break; default :
MessageBox . Show ( "CreateAppFeed : wrong M_Model=.
" + App .Applnstances [i] .M_Model + " used. in AppConfig . xml , stop working!");
return;
-- 20 --
public void LoadAppFeedItems (bool createFlag)
{
if (App .Applnstances . Count == 0)
{
MessageBox . Show ( "AppConfig . xml not loaded
stop processing! !") ;
return; this . MainPivot . Items . Clear ( ) ; int cnt = App .Applnstances . Count ;
for (int i = 0 ; i < cnt; i++)
{
App . CurrAppIndex = i ;
switch (App .Applnstances [i] .M_Model)
{
case "Patient" :
(App .Applnstances [i] .0_AppFeed_Pivot as AppFeed<...
Patient, PivotMainPage>) . Loadltem (...
createFlag, i) ;
break; case "Worklist" :
(App .Applnstances [i] .0_AppFeed_Pivot as AppFeed<...
Worklist, PivotMainPage>) . Loadltem (...
createFlag, i) ;
break; case "Context " :
(App .Applnstances [i] .0_AppFeed_Pivot as AppFeed<...
Context, PivotMainPage>) . Loadltem (...
createFlag, i) ;
break; case "Score" :
(App .Applnstances [i] .0_AppFeed_Pivot as AppFeed<.
Score, PivotMainPage>) . Loadltem (... createFlag, i) ;
break; case "Kalle":
(App .Applnstances [i] .0_AppFeed_Pivot as AppFeed<...
Kalle, PivotMainPage>) . Loadltem (... createFlag, i) ; break; case "Sampletable" :
(Ap .Applnstances [i] .0_AppFeed_Pivot as AppFeed<.
Sampletable, PivotMainPage>) . Loadltem (... createFlag, i) ;
break; case "Blob" :
(App .Applnstances [i] .0_AppFeed_Pivot as AppFeed<.
Blob, PivotMainPage>) . Loadltem (...
createFlag, i) ;
break; case "QueueMessage" :
(App .Applnstances [i] .0_AppFeed_Pivot as AppFeed<.
QueueMessage, PivotMainPage>) . Loadltem (... createFlag, i) ;
break; case "File" :
(App .Applnstances [i] .0_AppFeed_Pivot as AppFeed<.
File, PivotMainPage>) . Loadltem (...
createFlag, i) ;
break; case "Twitter" :
(App .Applnstances [i] .0_AppFeed_Pivot as AppFeed<.
Twitter, PivotMainPage>) . Loadltem (... createFlag, i) ;
break; case "ApplHub" :
(App .Applnstances [i] .0_AppFeed_Pivot as AppFeed<.
ApplHub, PivotMainPage>) . Loadltem (... createFlag, i) ;
break; 4.5 r
case "ApplFeed" :
(App .Applnstances [i] .0_AppFeed_Pivot as AppFeed< ApplFeed, PivotMainPage>) . Loadltem (...
createFlag, i) ;
break; default :
MessageBox . Show ( "LoadAppFeedltems : wrong M_Model
" + App .Applnstances [i] .M_Model + " used... in AppConfig . xml , stop working ! " ) ;
return;
}
}
} public bool IsNewPagelnstance
{
get { return isNewPagelnstance ; }
set { isNewPagelnstance = value; }
} public void DoSetPageTransitionList ( )
{
// -- 17 -- PageTransitionList . Begin ( ) ;
} public void DoResetPageTransitionList ( )
{
// -- 22, 23 --
ResetPageTransitionList . Begin ( ) ;
} private void OnNavigatedToUs ( int Selectedlndex)
{
// -- 21 -- if (App.PageTransitions.ToUpper () == "ON"
App . PageTransitions . ToUpper ( ) != null] {
DoResetPageTransitionList ( ) ;
}
eise
{
this . RestorePage (0) ;
}
} protected override void OnNavigatedTo (Navigation...
EventArgs e)
{
if ( (e . IsNavigationlnitiator == false)
(e . NavigationMode == System. Windows .Naviga.. tion . NavigationMode . Back) )
{
if ( storedRequester == "ChooserAndLauncher" )
{
externalNavigateToCounter++ ;
if (externalNavigateToCounter < 3)
{
return;
}
eise
{
externalNavigateToCounter = 0 ;
storedRequester = " " ;
}
}
}
// -- 21 -- base . OnNavigatedTo (e) ; // base.
if (App. PageTransitions. ToUpper () == "ON"
App . PageTransitions . ToUpper ( ) != null)
{
DoResetPageTransitionList ( ) ; eise
{
this . RestorePage (0) ;
}
} protected override void OnNavigatedFrom (NavigationEvent.
Args e)
{
if ( storedRequester == "ChooserAndLauncher" )
{
return;
}
base . OnNavigatedFrom (e) ; if (e . NavigationMode != System . Windows . Nävi...
gation . NavigationMode . Back)
{
this . SaveGuiState ( ) ;
}
}
//
// VIEW GUI Page GoBack Handling
//
protected override void OnBackKeyPress (System. Component.
Model . CancelEventArgs e)
{
string req = GetApplicationState<string> (...
"CurrentRequest " ) ;
string rsp = GetApplicationState<string> (...
"CurrentResponse" ) ;
if (((req == "Add") || (req == "Update")) && ( (...
rsp == "Save") | | (rsp == "Cancel") | | (. rsp == "Delete") ) )
return;
CallPreviousAppPage (0) ;
e. Cancel = true; } public void RestorePage ( int Applndex)
{
// -- 25 -- if (this . IsNewPagelnstance)
{
if ((Applndex < 0) | | (App .Applnstances [App...
Index] .0_CurrentViewModel == null))
{
if (this . State . Count > 0)
{
this . RestoreGuiState ( ) ;
}
eise
{
this . LoadAppFeedltems (true) ;
}
}
}
this . IsNewPagelnstance = false;
(App .Applnstances [0] .0_CurrentViewModel as ViewModelBase..
) . OnNavigatedTo ( ) ;
(App .Applnstances [0] .0_CurrentViewModel as ViewModelBase.
) .ViewUpdateApplicationBarButtons (...
this .ApplicationBar, new[] { "logout" }... ) ; // this. }
//
// VIEW GUI Call Hierarchical Details Page Handling
// public void CallDetailPage ( )
{
if (App . avigationUri == "" | | App . avigationUri == null) {
(Ap .Applnstances [0] .0_CurrentViewModel as ViewModelBase..
) .ApplicationBarIconButton_...
UPDATE_ENTITY_Click() ;
}
eise
{
int selectedlndex= (App .Applnstances [0] .0_CurrentView...
Model as ViewModelBase) . GeneralSelected... Index;
CallNextAppPage (selectedlndex) ;
}
} //
// VIEW GUI App Navigation Logic (Hierarchical Next App-...
Hub Page Handling)
// public void CallNextAppPage ( int Selectedlndex)
{
storedRequester = " " ;
if (Selectedlndex < -1000)
{
storedRequester = "ChooserAndLauncher" ;
externalNavigateToCounter = 0 ;
switch (Selectedlndex)
{
case -1001: // send email
if (internalApps == null) internalApps =...
new AppHubMainlnternalApps ( ) ;
internalApps . takeSelectedListltemSelect...
ErnailAdrAndSendViaEmail () ;
break;
-1002: // send sms
(internalApps == null) internalApps
new AppHubMainlnternalApps ( ) ; internalApps . takeSelectedListltemSelect. PhoneNrAndSendViaSms ( ) ;
break;
return;
// the regulär App-Feed processing comes here int maxAppIndexAvail = App .Appslnstances . Count
App . PreviousApp = App . CurrentApp ;
switch (App .Applnstances [0] .V_NextAppNavUri)
{
case "Application 0": // ApplHub
App . CurrentApp = 0 ;
break; ase "Application
App . CurrentApp
break; ase "Application
App . CurrentApp
break; ase "Application // Worklist
App . CurrentApp
break; ase "Application // Context
App . CurrentApp
break; case "Application 5": // Iso-FileViewer
App . CurrentApp = 5 ;
break; case "Application 6": // Azure-Blob-Viewer
App . CurrentApp = 6 ;
break; case "Application 7": // Azure-Queue-Viewer
App . CurrentApp = 7 ;
break; case "Application 8": // ???
App . CurrentApp = 0;
break; case "Application 9":
NavigateToViewingApp ( ) ;
return; default :
if ( (App .Applnstances [0] .V_NextAppNavUri == "*'
&& (App . CurrentApp == 0) && (...
Selectedlndex == -1))
App . CurrentApp = 2 ;
eise
App . CurrentApp = Selectedlndex + 1;
break;
}
CreateAppFeed ( ) ;
OnNavigatedToUs (Selectedlndex) ;
} public void CallPreviousAppPage ( int Selectedlndex) {
int maxAppIndexAvail = App .Appslnstances . Count - 1; App . PreviousApp = App . CurrentApp ;
switch (App . CurrentApp)
{
case 0: // ApplHub
App . CurrentApp = 0 ;
break; r„
52
case 1: // Twitter
Ap . CurrentApp = 0 ;
break; case 2 : // Patient
App . CurrentApp = 0 ;
break; case 3: // Worklist --> goto Patient
App . CurrentApp = 2 ; ! !
break; case 4: // Context --> goto Worklist App . CurrentApp = 3;
break; case 5: // Iso-FileViewer
App . CurrentApp = 0 ;
break; case 6 : // Azure Blob-Viewer
App . CurrentApp = 0 ; ! !
break; case 7: // Azure Queue-Viewer
App . CurrentApp = 0;
break; case 8: // ????
App . CurrentApp = 0 ;
break; case 9: // Viewing-App
App . CurrentApp = 0 ;
break; default : Ap . CurrentApp = 0 ;
break;
}
CreateAppFeed ( ) ;
OnNavigatedToUs (Selectedlndex) ;
} private void NavigateToViewingApp ( )
{
#if _VIEWING
try
{
string currentltemType = (App.App...
Instances[0] .0_CurrentViewModel as
ViewModelBase) . GetltemTypeFrom...
Selectedlndex ( ) ;
if (currentltemType == "File")
{
var c = (App .Applnstances [0] .0_CurrentView...
Model as ViewModelBase) . GetExternalEntity..
FromSelectedIndex<File> ( ) ;
if ( (c as Context) != default (Context) )
{
NavigationService . Navigate (App . PrepareNavigate...
ToViewingApps ("/ViewsViewing/Viewing...
Page . xaml " , (Context) c, " " ) ) ;
}
}
eise if (currentltemType == "Blob")
{
var c = (App .Applnstances [0] .0_CurrentView...
Model as ViewModelBase) .GetExternalEntity.. FromSelectedIndex<Blob> ( ) ;
if ( (c as string) != "")
{
NavigationService . Navigate (App . PrepareNavigate ...
ToViewingApps ( " /ViewsViewing/Viewing...
Page. xaml", null, c as string)); }
}
eise if (currentltemType == "Message")
{
var c = (App .Applnstances [0] .0_CurrentView...
Model as ViewModelBase) . GetExternalEntity... FromSelectedIndex<QueueMessage> () ; if ( (c as string) != "")
{
NavigationService . Navigate (App . PrepareNavigate...
ToViewingApps ( " /ViewsViewing/Viewing...
Page . xaml " , null, c as string));
}
}
eise if (currentltemType == "Twitter")
{
var c = (App .Applnstances [0] .0_CurrentView...
Model as ViewModelBase) .GetExternalEntity.. FromSelectedIndex<Twitter> ( ) ;
if ( (c as string) ! = " " )
{
NavigationService . Navigate (App . PrepareNavigate...
ToViewingApps ( " /ViewsViewing/Viewing...
Page . xaml " , null, c as string));
}
}
eise
NavigationService . Navigate (App . PrepareNavigate...
ToViewingApps ( " /ViewsViewing/Viewing...
Page, xaml", (App .Applnstances [0] .0_Current..
ViewModel as ListViewModel<Context>...
) .Selectedltem, "") ) ;
}
catch
{
// do nothing here
}
#endif rivate void NavigateToAp ( int Selectedlndex) f (App . DesignerMode == null)
App . SetDefaultAppSettings ( ) ;
f (App . DesignerMode == null | | ...
App.DesignerMode.ToUpper () == "NORMAL App . DesignerMode . ToUpper ( ) == "")
NavigationService . Navigate (new Uri ( " /Views/...
NormalMainPage .xaml?selectedltem=" +... Selectedlndex, UriKind . Relative) ) ; return; f (App.DesignerMode.ToUpper () == "PIVOT")
NavigationService . Navigate (new Uri ( " /Views/...
PivotMainPage .xaml?selectedltem=" +... Selectedlndex, UriKind . Relative) ) ; return; f (App.DesignerMode.ToUpper () == "PANORAMA")
NavigationService . Navigate (new Uri ( " /Views/...
PanoramaMainPage . xaml?selectedltem= " Selectedlndex, UriKind . Relative) ) ; return;
}
//
// VIEW GUI save/restore State
// public void SaveGuiState ( )
{
SetApplicationState (AppFeed_All_StateStore , .
App .Applnstances) ; }
// neu: from AppFeed.cs
public void RestoreGuiState ( )
{
App .Applnstances = GetApplicationState<List<Appl...
FeedData>> (AppFeed_All_StateStore) ;
} //
// VIEW Application State Handling
// public void SetApplicationState ( string key, object...
value)
{
if (PhoneApplicationService . Current . State . Contains...
Key (key) )
{
PhoneApplicationService . Current . State . Remove (key) ;
}
PhoneApplicationService . Current . State .Add (key, ...
value) ;
} public F GetApplicationState<F> (string key)
{
if ( ! PhoneApplicationService . Current . State . Contains...
Key (key) )
{
return default (F);
} return (F) PhoneApplicationService . Current . State [key] ; } public void RemoveApplicationState ( string key)
{ If (PhoneApplicationService . Current . State . Contams...
Key (key) )
{
PhoneApplicationService . Current . State . Remove (key) ;
}
}
//
// VIEW GUI Page Storyboard Transition Handling
// public void OnPageTransitionList_Completed (obj ect...
sender, EventArgs e)
{
// -- 18 -- this . CallDetailPage ( ) ;
} public void OnResetPageTransitionList_Completed (...
obj ect sender, EventArgs e)
{
// -- 24 -- this .RestorePage (0) ;
}
Anlage 3: Ein Beispiel -Code für den Speichertreiber 100 (Di rect Storage Adapter)
#define UPLOAD
#define _KeyImageWatermarkUsed
using System;
using System . Collections .Generic;
using System. Linq;
using System. Net;
using System . Windows ;
using System . Windows . Controls ;
using System . Windows . Documents ;
using System . Windows . Input ;
using System . Windows . Media ;
using System. Windows .Media .Animation;
using System . Windows . Shapes ;
using System . Windows .Navigation;
using Microsoft . Phone . Controls ;
using Microsoft . Phone . Shell ;
using System . Text . RegularExpressions ;
using System . Windows . Interop ;
using System . Windows . Media . Imaging ;
using System . Windows . Resources ;
using System . Diagnostics ;
using System . Threading ;
using System. Xml;
using System. Xml . Linq;
using System . ComponentModel ;
using System. Globalization;
#if UPLOAD
using SLBlobUploader . Code ;
using SLBlobUploader . Code .Abstract ;
using SLBlobUploader . Code . Infrastructure ;
using SLBlobUploader . Code . StorageClient ;
using System.10;
using System.10. IsolatedStorage ;
using System . Collections ; using System . Windows . Threading ;
#endif namespace AzureTableStore_CRUD_Sample
{
public class UploadKeylmage : INotifyPropertyChanged
{
// State indication to GUI progressbar (ViewModel)
private string message;
private bool isWorking = false;
// Uploader parameters
private const long MaxFileSizeKb = Constants . MaxFileSizeKB ; private const string UploadButtonText = "Upload" ;
private const string CancelButtonText = "Cancel";
private const long BytesPerKb = 1024;
private List<UserFile> files = null;
private string sasUrl = string . Empty;
private string timeOutSeconds = string . Empty;
private bool sasExpired = false;
private DateTime operationStartTime ;
private UserFile userFile = null;
// contextfolder object in use
Context selectedContextObj ect ;
// sync to main thread
private Dispatcher Dispatcher; // State
private String State = "Idle";
private string KeylmagefileNameWithoutExt = "";
private string _TimeOutSeconds ;
private bool _SasExpired;
private string _SasUrl ;
IsolatedStorageFileStream myThumbnailFileStream;
IsolatedStorageFileStream myKeylmageFileStream;
private string IsoKeylmageFileName = ""; private string IsoKeylmageThumbnailFileName = " " ;
private string CloudPathName = " " ;
// owner
ViewingPage owner;
//
// Constructor
// public UploadKeylmage ( )
{
} public UploadKeylmage (ViewingPage parent)
{
owner = parent ;
TextBox tb = new TextBox ( ) ;
private void ClearNotificationMesssageArea ( )
{
this. Message = " " ;
this . IsWorking = false;
} //
// 0) API-Call - SAVE screen captured "Keyimages" to...
cloud storage
//
public string DoKeylmaUpload (Context SelContextFolder...
Object, WriteableBitmap KeylmaBitmap, ... string mTimeOutSeconds , ...
bool mSasExpired, string mSasUrl)
{
if (State == "Idle")
{
State = "Blocked part 1";
UploadDoNotification ( ) ;
this . selectedContextObj ect = SelContextFolderObj ect ; this ._TimeOutSeconds = mTimeOutSeconds;
this ._SasExpired = mSasExpired;
this._SasUrl = mSasUrl ;
this . IsoKeylmageFileName = "tempKeyIma.jpg";
this . IsoKeylmageThumbnailFileName =...
" tempKeylmaThumbnail .jpg" ;
saveKeylmagesInlsoStore (KeylmaBitmap) ;
var myStore = IsolatedStorageFile . GetUserStore...
ForApplication ( ) ;
this . myThumbnailFileStream = myStore . OpenFile ( IsoKeylmage...
ThumbnailFileName , FileMode . Open, ...
FileAccess . ReadWrite) ; this . KeylmagefileNameWithoutExt = storeKeylmageThumbnailln- ContextFolderBlobStore (myThumbnailFileStream,
mTimeOutSeconds, mSasExpired, mSasUrl) ;
return ( " Idle" ) ;
}
return State;
}
private void UploaderDoneNotiflcation ( string msg)
{
if (State == "Blocked part 1")
{
this . myThumbnailFileStream . Close ( ) ;
var myStore = IsolatedStorageFile . GetUser...
StoreForApplication ( ) ; this . myKeylmageFileStream = myStore . OpenFile (this . IsoKey...
ImageFileName , FileMode . Open, ...
FileAccess . ReadWrite) ;
storeKeylmagelnContextFolderBlobStore (this . Keylmagefile...
NameWithoutExt , myKeylmageFileStream, this ._TimeOutSeconds , this ._Sas...
Expired, this . SasUrl) ; State = "Blocked part 2";
#if early
UploadDoneNotification (msg) ; storeKeylmagelnContextFolderT- ableStore (this . selected...
ContextObj ect , this . CloudPathName , ... this . KeylmagefileNameWithoutExt) ;
// filenames of destination in cloud! this . myKeylmageFileStream. Close ( ) ;
State = "Idle";
/ * S S S S S S S S S S UploaderDoneNotification only called once ! ! ! try to evaluate why and then reenable this path
again! ! Sc Sc Sc Sc Sc Sc * /
#else
} eise if (State == "Blocked part 2")
{
doTableEntryAndUploadDoneNotification (msg) ;
}
eise
{
MessageBox . Show ( "Uploaded Keyimage ended abnormal!");
}
#endif
} private void TableEntryAndUploadDoneNotification ( string msg) {
storeKeylmagelnContextFolderTableStore (this . selected...
ContextObj ect , this .CloudPathName,... this . KeylmagefileNameWithoutExt) ;
this .myKeylmageFileStream. Close ( ) ;
UploadDoneNotification (msg) ;
State = "Idle";
}
private delegate void doUploadDoneNotificationDelegate (... string msg) ; private void doUploadDoneNotification ( string msg)
{
bool isDispatcherThread = this . Dispatcher . CheckAccess () ; if (isDispatcherThread == true)
{
UploadDoneNotification (msg) ;
}
eise
{
this . Dispatcher . Beginlnvoke (new doUploadDoneNotification..
Delegate (UploadDoneNotification) , .. msg) ;
private delegate void doTableEntryAndUploadDone...
NotificationDelegate (string msg); private void doTableEntrvAndUploadDoneNotification (...
string msg)
{
bool isDispatcherThread = this . Dispatcher . CheckAccess () ; if (isDispatcherThread == true)
{
TableEntryAndUploadDoneNotification (msg) ;
}
eise
{
this . Dispatcher . Beginlnvoke (new doTableEntryAndUploadDone.
NotificationDelegate (TableEntry... AndUploadDoneNotification) , msg) ; }
}
// // 1) Save stored iso Thumbnail-image as jpeg in "uploads"...
Container of azure blob störe
//
private string storeKeylmageThumbnaillnContext...
FolderBlobStore (Stream Video_Stream, ... string mTimeOutSeconds , bool mSas... Expired, string mSasUrl)
{
try
{
string pathName = " " ;
DateTime CurrentTime = System . DateTime . Now;
string fileNameWithoutExt = "keylma_" +
String . Format ("{ 0 : s} " , CurrentTime) + "_" + Guid . NewGuid ( ) ; string fileNameAndExt = fileNameWithoutExt +...
"_thumbnail .jpg" ;
using (Stream stream = new MemoryStream ( ) )
{
stream. Position = 0 ;
UploadStream (pathName , fileNameAndExt , Video_Stream, ...
mTimeOutSeconds, mSasExpired, mSasUrl) ;
}
return fileNameWithoutExt ;
}
catch
{
string IblMessage = "Keyimage-Thumbnail cannot be saved,...
lease timeout?";
UploaderDoneNotification (IblMessage) ;
return (null) ;
}
}
//
// 2) Save stored iso keylmage-image as jpeg in "uploads"...
Container of azure blob störe //■ private void storeKeylmagelnContextFolderBlobStore (...
string fileNameWithoutExt , Stream key.. Ima_Stream, string mTimeOutSeconds , ... bool mSasExpired, string mSasUrl)
{
try
{
string pathName = " " ;
string fileName = fileNameWithoutExt + ".jpg
using (Stream stream = new MemoryStream ( ) )
{
stream. Position = 0 ;
UploadStream (pathName , fileName, keyIma_Stream, mTimeOut...
Seconds, mSasExpired, mSasUrl) ;
}
}
catch
{
string lblMessage = "Keyimage cannot be saved, lease...
timeout? " ;
UploaderDoneNotification (lblMessage) ;
}
}
//
// 3) Save stored keylmage as tweet in "contectfolder"...
table of azure table störe
//
private void storeKeylmagelnContextFolderTableStore (...
Context selectedContextObj ect , ...
string path, string filename)
{
Context cn = (Context) selectedContextObj ect . DeepCopy () ; cn . PartitionKey = selectedContextObj ect . PartitionKey;
cn.RowKey = System . Guid . NewGuid (). ToString () ; cn . ServerBaseUri = "htt : //singapore4. lo . core . Windows . net " ; if (path == "")
cn.DZInstDataRelPath = "/" + "uploads" + "/" + filename;
eise
cn.DZInstDataRelPath = "/" + "uploads" + "/" + path + "/" + filename ;
cn.Thumb = cn . ServerBaseUri + cn.DZInstDataRelPath +
"_thumbnail .jpg" ;
cn.DZInstDataRelPath += ".jpg"; // trick 5
cn.DZMetaDataRelPath = "jpeg";
cn.DZMHDDataRelPath = "None";
cn.ARegion = "Keyimage";
cn.StorageFormat = "JPEG";
cn . StorageHostVolumeSeries2dAnz = "1";
if ( ( (App .Applnstances [0] .0_CurrentViewModel as Listview...
Model<Context>) . Driver . Item...
Type == "Twitter") || ((App.App...
Instances [0] .0_CurrentViewModel as ...
ListViewModel<Context>) . Driver . Item...
Type == "Unknown"))
{
return;
}
(App .Applnstances [0] .0_CurrentViewModel as ListView- Model<Context>) .AddEntity (cn) ;
}
//
private void saveKeylmagesInlsoStore (WriteableBitmap ...
Keylma_bitmap)
{
try
{
#if _KeyImageWatermarkUsed
StreamResourcelnfo streamlnfo = Application . GetResource.
Stream(new Uri ( " /AzureTable... Store_CRUD_Sample ; component/images/...
KeylmageAsRedWhite .png" , UriKind...
. Relative) ) ;
Stream EmbeddedResourceStream = streamlnfo . Stream;
if (EmbeddedResourceStream != null)
{
Bitmapimage bitMapImage = new Bitmapimage () ;
bitMapImage . SetSource (EmbeddedResourceStream) ;
WriteableBitmap bitmap = new WriteableBitmap (bitMapImage) ; Keylma_bitmap = ApplyKeylmageWithWatermark (Keylma_bitmap, ...
bitmap) ; bitmap . Clear ( ) ;
bitmap = null;
EmbeddedResourceStream. Close ( ) ;
EmbeddedResourceStream. Dispose () ;
EmbeddedResourceStream = null;
bitMapImage = null;
}
#endif
using ( IsolatedStorageFile isolatedStore = IsolatedStorage...
File . GetUserStoreForApplication ( ) ) {
if (isolatedStore . FileExists (this . IsoKeylmageFileName) ) {
isolatedStore . DeleteFile (this . IsoKeylmageFileName) ;
}
if (isolatedStore . FileExists (this . IsoKeylmageThumbnail...
FileName) )
{
isolatedStore . DeleteFile (this . IsoKeylmageThumbnailFileName) ; }
using (MemoryStream streamKeylma = new MemoryStream ( ) )
{
JPGUtil . EncodeJpg (Keylma_bitmap, streamKeylma) ;
streamKeylma . Position = 0; using ( IsolatedStorageFileStream stream = new Isolated...
StorageFileStream (this . IsoKeylmageFile. Name, FileMode . Create, isolatedStore) ) {
streamKeylma . Position = 0 ;
streamKeylma . CopyTo (stream) ;
stream. Close ( ) ;
}
}
using (MemoryStream streamThumbnail = new MemoryStream ( ) ) {
Keylma_bitma . SaveJpeg ( streamThumbnail , 120, 120, 0, 80); streamThumbnail . Position = 0 ;
using (IsolatedStorageFileStream stream = new
IsolatedStorageFileStream (this . IsoKeylmageThumbnailFile...
Name, FileMode . Create, isolatedStore))
{
streamThumbnail . Position = 0 ;
streamThumbnail . CopyTo ( stream) ;
stream. Close ( ) ;
}
}
isolatedStore . Dispose ( ) ;
}
}
catch (IsolatedStorageException e)
{
string lblMessage = "Keyimage cannot be saved in ISO störe.
temporarily: " + e. Message ;
UploaderDoneNotification (lblMessage) ;
}
Keylma_bitmap . Clear ( ) ;
Keylma_bitmap = null;
}
#if _KeyImageWatermarkUsed
public WriteableBitmap ApplyKeylmageWith... Watermark (WriteableBitmap input , ...
WriteableBitmap Watermark)
{
var w = Watermark . PixelWidth;
var h = Watermark . PixelHeight ;
var result = input . Clone () ;
var position = new Rect ( input . PixelWidth - w - 40,...
input . PixelHeight - h - 40, w, h) ; result . Blit (position, Watermark, new Rect(0, 0, w, h) ) ; return result;
}
#endif private void old_saveStreamAsIsoFile (Stream str,...
string isoFileName)
{
try
{
using ( IsolatedStorageFile isStore = IsolatedStorage...
File. GetUserStoreForApplication () )
{
if (isStore . FileExists (isoFileName) )
{
isStore .DeleteFile (isoFileName) ;
}
using ( IsolatedStorageFileStream targetStream =...
isStore . OpenFile (isoFileName , File... Mode . CreateNew, FileAccess . Write) )
{
byte[] readBuffer = new byte[4096];
int bytesRead = -1;
while ((bytesRead = str . Read (readBuffer, 0, readBuffer . Length) ) > 0)
{
targetStream. Write (readBuffer, 0, bytesRead);
}
}
} }
catch
{
string lblMessage = "Keyimage, error saving " + isoFile...
Name + " in ISO störe temporarily!";
UploaderDoneNotification (lblMessage) ;
}
} private void saveStreamAsIsoFile (Stream incoming...
Stream, string isoFileName)
{
try
{
using ( IsolatedStorageFile isolatedStore = IsolatedStorage.
File . GetUserStoreForApplication ( ) )
{
// Delete file if it exists
if (isolatedStore . FileExists (isoFileName) )
{
isolatedStore .DeleteFile (isoFileName) ;
}
using (var stream = new IsolatedStorageFileStream ( iso...
FileName, FileMode . CreateNew, ...
isolatedStore) )
{
incommingStream . Position = 0 ;
incommingStream . CopyTo (stream) ;
}
}
}
catch (IsolatedStorageException ise)
{
string lblMessage = "Keyimage, error saving " + isoFile...
Name + " in ISO störe temporarily!";
UploaderDoneNotification (lblMessage) ;
}
} private void UploadStream ( string pnam, string fnam,...
Stream stream, string mTimeOutSeconds,... bool mSasExpired, string mSasUrl)
{
string lblMessage = "undefined" ;
bool initOk = initBlobUploader (mTimeOutSeconds , mSas...
Expired, mSasUrl) ;
if (initOk)
{
UploadStreamToCloudFile (pnam, fnam, stream);
}
eise
{
lblMessage = "File not saved, init error, lease timeout?"; UploaderDoneNotification (lblMessage) ;
}
} public bool initBlobUploader ( string mTimeOutSeconds,...
bool mSasExpired, string mSasUrl)
{
timeOutSeconds = mTimeOutSeconds;
sasExpired = mSasExpired;
sasUrl = mSasUrl ;
if (sasExpired)
{
if (this .userFile != null)
{
this .userFile . CancelUpload ( ) ;
}
return false;
}
return true;
} private bool UploadStreamToCloudFile ( string pnam,...
string fnam, Stream stream)
{
string lblMessage = "undefined" ;
if (this.files == null)
{
this.files = new List<UserFile> ( ) ;
}
this .userFile = new UserFile ();
this . userFile . PathName = pnam;
this . userFile . FileName = fnam;
this . userFile . FileStream = stream;
this .userFile . StreamBytes = stream. Length;
this .userFile . UIDispatcher = this . Dispatcher ;
this .userFile . UploadContainerUrl = new Uri (this . sasUrl) ; this . userFile . UploadCompletedEvent += new EventHan- dler<UploadCompletedEventArgs> (this . OnUpload...
Completed) ;
if ( (this .userFile . FileStream. Length / BytesPerKb)...
<= MaxFileSizeKb && this.user...
File . FileStream . Length > 0)
{
this . files .Add (this .userFile) ;
}
eise
{
lblMessage = this .userFile . FileStream. Length > 0 ?
string. Format ( " IllegalMaxFileSize : {0} in KB", MaxFile...
SizeKb / BytesPerKb) : string . Format (... "IllegalMinFileSize : {0} in KB",...
MaxFileSizeKb / 1024) ;
MessageBox. Show ("UploadStreamToCloudFile: " + lblMessage); return false;
}
this . operationStartTime = DateTime .Now;
if (this.files != null)
{
foreach (var file in this.files) {
file .Upload (string . Empty) ;
}
}
eise
{
lblMessage = "no files to transfer ! " ;
MessageBox. Show ("UploadStreamToCloudFile: " + lblMessage); return false;
}
this. files = null;
lblMessage = "done";
return true;
}
private bool CancelUpload ( )
{
string lblMessage = "done";
this .userFile . CancelUpload ( ) ;
this. files = null;
MessageBox. Show ("CancelUpload: " + lblMessage);
return true;
} private void OnUploadCompleted (obj ect sender, Upload...
CompletedEventArgs e)
{
string lblMessage = "undefined" ;
{
if (this .userFile != null)
{
switch (e.Reason)
{
case Constants . UploadCompleteReason . UploadCommitted :
var duration = DateTime . ow - this . operationStartTime ;
var fileSizelnKB = (float) this .userFile . StreamBytes / Bytes...
PerKb;
var fileSizeMessage = fileSizelnKB > BytesPerKb ? string...
. Concat (( (float) fileSizelnKB / Bytes... PerK ) .ToString () , " MB") : string . Concat ( fileSizelnKB . ToString ( ) , " KB");
lblMessage = string . Format ( "upload ok in {0} seconds",...
duration . TotalSeconds) ;
this .userFile = null;
UploaderDoneNotification (lblMessage) ;
break;
case Constants . UploadCompleteReason . ErrorOccurred :
lblMessage = string . Format ( "upload error: {θ}", e. Error...
Message) ;
this .userFile = null;
UploaderDoneNotification ( "Upload Finished: " + lblMessage); break;
case Constants . UploadCompleteReason . UserCancelled :
if ( ! sasExpired)
{
lblMessage = string . Format ( "upload cancelled");
}
this .userFile = null;
UploaderDoneNotification ( "Upload Finished: " + lblMessage); break;
default :
lblMessage = string . Format ( "upload : unknown error occured"); this .userFile = null;
UploaderDoneNotification ( "Upload Finished: " + lblMessage); break;
}
}
}
}
#endif
}
} Bezugszeichenliste
1 System
2, 21 (medizinische) Einrichtung
3 Modalität
4 Computertomograph
5 C-Bogengerät
6 Magnetresonanztomograph
7 (Steuer- und Auswerte- ) Rechner
8 Device
9 Personal -Computer
10 Bildschirm
11 Tablet-Computer
12 Smartphone
13 Public Cloud
14 (Datenübertragungs- ) etz
15 Intranet
16 Internet
17 Firewall
18, 181 Subscription
19 Cloud Storage
20 App Store
21 Cloud-Compute-Service
22 (Patient- ) Hub
23 (Worklist-)Hub
24 (Context-)Hub
25 (Image- ) Hub
26 Table-Storage
27 Tweet
28 Blob-Storage
29 URI
31 Applikation
32 Applikation
33 Applikation
34 Applikation
35 Feed
36 Seite
37 (graphische) Benutzeroberfläche r
/ 6
40 Kopfzeile
41 Suchfeld
42 Anzeigefeld
43 Befehlsleiste
44 Eingabezeile
45 Schaltfläche
46 Vorauswahlfeld
47 Bild
48 Schlagwort
49 Schaltfläche
50 Schaltfläche
51 Rahmen
52 Seite
60 Kopfzeile
61 Überschrift
62 Anzeigefeld
63 Befehlszeile
64 Schaltfläche
65 Schaltfläche
67 Feldnamen
68 Feldinhalt
69 Seite
70 Kopfzeile
71 Überschrift
72 Anzeigefeld
73 Befehlszeile
74 Schaltfläche
80 Menüzeile
81 Rahmen
92 (2D-Viewing- ) Modul
93 (3D-Viewing- ) Modul
94 (2D-Viewing- ) Applikation
95 (3D-Viewing-) Applikation 100 Speichertreiber P Patientendatensatz w Aufgabe
c Kontextdatensatz
B Bilddatensatz
V Ansicht
Q Suchanfrage
R Anfrage
K Keyimage

Claims

Patentansprüche
1. Verfahren zur Verwaltung und Bearbeitung von Daten einer medizinischen Einrichtung (2, 2'),
- bei welchem für mindestens zwei unterschiedliche Arten von medizinischen Datensätzen (P,W,C,B) jeweils separate Speicherbereiche (22-25) in einem Cloud Storage (19) einer Public Cloud (13) zur Verfügung gestellt werden, wobei die in dem jeweiligen Speicherbereich (22-25) gespeicherten Daten- sätze (P,W,C,B) derart vorgehalten werden, dass ein unmittelbarer Zugriff auf diese Datensätze (P,W,C,B) aus dem Internet (16) bei Vorliegen einer dem Speicherbereich (22-25) zugeordneten Subscription (18, 18 möglich ist,
- bei welchem für jeden Speicherbereich (22-25) mindestens eine spezifisch zugeordnete Applikation (31-34,94,95) zum
Ablauf auf einem Nutzer-Gerät (8,9,11,12) zur Verfügung gestellt wird, die zum Abruf und/oder zur Darstellung der in dem zugeordneten Speicherbereich (22-25) enthaltenen Datensätze (P,W,C,B) eingerichtet ist.
2. Verfahren nach Anspruch 1,
bei welchem mindestens zwei der nachfolgend aufgezählten Speicherbereiche zur Verfügung gestellt werden:
- ein Patienten-Speicherbereich (22), in dem jeder Datensatz (P) persönliche und medizinische Daten über einen bestimmten Patienten enthält,
- ein Arbeitslisten-Speicherbereich (23), in dem jeder Datensatz eine von einem medizinischen Nutzer zu erledigende Aufgabe (W) oder Aufgabefolge enthält,
- ein Bilddaten-Speicherbereich (25), in dem jeder Datensatz
(B) Bilddaten enthält und/oder
- ein Kontext-Speicherbereich (24), in dem jeder Datensatz
(C) Kontextinformation zu einem Bilddatensatz (B) insbesondere einen Verweis (29) auf den Speicherort des Bilddaten- satzes (B) enthält.
3. Verfahren nach Anspruch 1 oder 2 ,
bei welchem mittels mindestens einer der Applikationen (31- 34,94,95) auf einen in dem zugeordneten Speicherbereich (22- 25) enthaltenen Datensatz (P,W,C,B) unmittelbar zugegriffen wird.
4. Verfahren nach einem der Ansprüche 1 bis 3,
bei welchem mittels mindestens einer der Applikationen (31- 34) ein in dem zugeordneten Speicherbereich (22-25) enthalte- ner Datensatz (P,W,C,B) unmittelbar erzeugt, editiert und gelöscht wird.
5. Verfahren nach einem der Ansprüche 1 bis 4,
bei welchem mindestens eine der Applikationen (34) sowohl ei- nem Device-Only-Modus als auch in einem Cloud-Service-Modus betrieben werden kann, wobei
- in dem Device-Only-Modus der Zugriff und die Darstellung der in dem zugeordneten Speicherbereich (25) enthaltenen Datensätze (B) ausschließlich von der Applikation (34) vor- genommen wird,
- in dem Cloud-Service-Modus zum Zugriff und/oder zu Darstellung der in dem zugeordneten Speicherbereich (25) enthaltenen Datensätze (B) Rechenleistung (21) der Public Cloud (13) herangezogen wird.
6. Verfahren nach einem der Ansprüche 1 bis 5,
- bei welchem innerhalb mindestens eines Speicherbereichs
(22-24) ein Tabellenspeicher (26) zur Verfügung gestellt wird, wobei innerhalb des Tabellenspeichers (26) jedem in dem Speicherbereich (22-24) gespeicherten Datensatz (P,W,C) ein Tabelleneintrag (27) zugeordnet ist, der den zugeordneten Datensatz (P,W,C) enthält, und
- bei welchem der Inhalt des Tabellenspeichers (26) von der dem Speicherbereich (22-24) zugeordneten Applikation (31- 33) zur Extraktion von ausgewählten Tabelleneinträgen (27) in einer Ergebnisliste (35) unmittelbar durchsuchbar ist.
7. Verfahren nach Anspruch 6 ,
bei welchem mittels mindestens einer Applikation (31-33) die Ergebnisliste (35) derart aus dem zugeordneten Speicherbereich (22-24) der Public Cloud (13) in einen lokalen Speicher des Nutzer-Geräts (8,9,11,12) externalisiert wird, dass diese Ergebnisliste (35) durch die Applikation (31-33) auch ohne Netzverbindung mit der Public Cloud (13) angezeigt, bearbeitet und/oder an eine andere Instanz derselben Applikation (31-33) oder einer anderen Applikation (31-34,94,95) übermit- telt werden kann.
8. Verfahren nach einem der Ansprüche 1 bis 7,
bei welchem durch eine medizinische Modalität (3-6) ein patientenspezifische Bilddaten enthaltender Bilddatensatz (B) er- zeugt und unmittelbar in dem zugeordneten Speicherbereich (25) des Cloud Storage (19) ablegt wird.
9. System (1) zur Verwaltung und Bearbeitung von Daten einer medizinischen Einrichtung (2,2 ,
- mit mindestens zwei in einem Cloud Storage (19) einer Public Cloud (13) angelegten Speicherbereichen (22-25) zur Speicherung mindestens zweier unterschiedlicher Datenarten von medizinischen Datensätzen (P,W,C,B), wobei jeder Speicherbereich (22-25) einer bestimmten Datenart (P,W,C,B) zu- gewiesen ist, und wobei die in dem jeweiligen Speicherbereich (22-25) gespeicherten Datensätze (P,W,C,B) derart vorgehalten sind, dass ein Zugriff auf diese Datensätze (P,W,C,B) aus dem Internet (16) bei Vorliegen einer dem Speicherbereich (22-25) zugeordneten Subscription (18,18λ) möglich ist, und
- mit mindestens einer Applikationen (31-34,94,95) für jeden Speicherbereich (22-25) zum Ablauf auf einem Nutzer-Gerät (8,9,11,12), die zum Abruf und zur Darstellung der in dem zugeordneten Speicherbereich (22-25) enthaltenen Datensätze (P,W,C,B) eingerichtet ist.
10. System (1) nach Anspruch 9,
bei dem die mindestens zwei Speicherbereiche umfassen: - einen Patienten-Speicherbereich (22), in dem jeder Datensatz (P) persönliche und medizinische Daten über einen bestimmten Patienten enthält,
- einen Arbeitslisten-Speicherbereich (23), in dem jeder Da- tensatz eine von einem medizinischen Nutzer zu erledigende
Aufgabe (W) oder Aufgabefolge enthält,
- einen Bilddaten-Speicherbereich (25), in dem jeder Datensatz (B) Bilddaten enthält, und/oder
- einen Kontext-Speicherbereich (24), in dem jeder Datensatz (C) Kontextinformation zu einem Bilddatensatz (b) , insbesondere einen Verweis (29) auf den Speicherort des Bilddatensatzes (B) enthält.
11. System (1) nach Anspruch 9 oder 10,
bei welchem mindestens eine der Applikationen (31-34,94) dazu eingerichtet ist, auf die in dem zugeordneten Speicherbereich (22-25) enthaltenen Datensätze (P,W,C,B) unmittelbar zuzugreifen .
12. System (1) nach einem der Ansprüche 9 bis 11,
bei welchem mindestens eine der Applikationen (31-34) dazu eingerichtet ist, die in dem zugeordneten Speicherbereich (22-25) enthaltenen Datensätze (P,W,C,B) unmittelbar zu erzeugen, zu editieren und zu löschen.
13. System (1) nach einem der Ansprüche 9 bis 12,
bei welchem mindestens eine der Applikationen (34) sowohl einem Device-Only-Modus als auch in einem Cloud-Service-Modus betreibbar ist, wobei
- in dem Device-Only-Modus der Zugriff und die Darstellung der in dem zugeordneten Speicherbereich (25) enthaltenen Datensätze (B) ausschließlich von der Applikation (34) vorgenommen wird,
- in dem Cloud-Service-Modus zum Zugriff und/oder zu Darstel- lung der in dem zugeordneten Speicherbereich (25) enthaltenen Datensätze (B) Rechenleistung (21) der Public Cloud (13) herangezogen wird.
14. System (1) nach einem der Ansprüche 9 bis 13,
- bei welchem mindestens ein Speicherbereich (22-24) einen Tabellenspeicher (26) umfasst, wobei innerhalb des Tabellenspeichers (26) jedem in dem Speicherbereich (22-24) ge- speicherten Datensatz (P,W,C) ein Tabelleneintrag (27) zugeordnet ist, der den zugeordneten Datensatz (P,W) enthält, und
- bei welchem der Inhalt des Tabellenspeichers (26) von der dem Speicherbereich (22-24) zugeordneten Applikation (31- 33) zur Extraktion von ausgewählten Tabelleneinträgen (27) in einer Ergebnisliste (35) unmittelbar durchsuchbar ist.
15. System (1) nach Anspruch 14,
bei welchem mindestens eine der Applikationen (31-33) dazu eingerichtet ist, die Ergebnisliste (35) derart aus dem zugeordneten Speicherbereich (22-24) des Cloud Storage (19) in einen lokalen Speicher des Nutzer-Geräts (8,9,11,12) zu ex- ternalisieren, dass diese Ergebnisliste (35) durch die Applikation (31-33) auch ohne Netzverbindung mit der Public Cloud (13) angezeigt, bearbeitet und/oder an eine andere Instanz derselben Applikation (31-33) oder einer anderen Applikation (31-34,94,95) übermittelt werden kann.
16. System (1) nach einem der Ansprüche 9 bis 15,
mit einem in einer medizinischen Modalität (3-6) implementierten oder implementierbaren Speichertreiber (100) , der dazu eingerichtet, einen von der Modalität (3-6) erzeugten, patientenspezifische Bilddaten enthaltenden Bilddatensatz (B) unmittelbar in dem zugeordneten Speicherbereich (25) der Pub- lic Cloud (13) abzulegen.
PCT/EP2013/070097 2013-09-26 2013-09-26 Verfahren und system zur verwaltung und bearbeitung von daten einer medizinischen einrichtung WO2015043640A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US15/025,216 US11404160B2 (en) 2013-09-26 2013-09-26 Method and system for managing and editing data of a medical device
PCT/EP2013/070097 WO2015043640A1 (de) 2013-09-26 2013-09-26 Verfahren und system zur verwaltung und bearbeitung von daten einer medizinischen einrichtung
CN201380079894.1A CN105593859B (zh) 2013-09-26 2013-09-26 用于管理和处理医学机构的数据的方法和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2013/070097 WO2015043640A1 (de) 2013-09-26 2013-09-26 Verfahren und system zur verwaltung und bearbeitung von daten einer medizinischen einrichtung

Publications (1)

Publication Number Publication Date
WO2015043640A1 true WO2015043640A1 (de) 2015-04-02

Family

ID=49301463

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2013/070097 WO2015043640A1 (de) 2013-09-26 2013-09-26 Verfahren und system zur verwaltung und bearbeitung von daten einer medizinischen einrichtung

Country Status (3)

Country Link
US (1) US11404160B2 (de)
CN (1) CN105593859B (de)
WO (1) WO2015043640A1 (de)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11461010B2 (en) * 2015-07-13 2022-10-04 Samsung Electronics Co., Ltd. Data property-based data placement in a nonvolatile memory device
US10282324B2 (en) 2015-07-13 2019-05-07 Samsung Electronics Co., Ltd. Smart I/O stream detection based on multiple attributes
US10509770B2 (en) 2015-07-13 2019-12-17 Samsung Electronics Co., Ltd. Heuristic interface for enabling a computer device to utilize data property-based data placement inside a nonvolatile memory device
CN106815469A (zh) * 2016-12-25 2017-06-09 东莞市讯易机电科技有限公司 一种医院放射科移动医疗通讯存储系统
EP3503113B1 (de) 2017-12-22 2024-02-21 Siemens Healthineers AG Cloudbasierte mr-bildgebung
US10790056B1 (en) * 2019-04-16 2020-09-29 International Medical Solutions, Inc. Methods and systems for syncing medical images across one or more networks and devices
CN111399756B (zh) * 2019-09-29 2024-01-02 杭州海康威视系统技术有限公司 一种数据存储方法、数据下载方法及装置
DE102020206726A1 (de) * 2020-05-28 2021-12-02 Siemens Healthcare Gmbh Verfahren zur Verarbeitung eines medizinischen Datensatzes durch eine Edge-Anwendung auf der Basis einer cloudbasierten Anwendung
US11538578B1 (en) 2021-09-23 2022-12-27 International Medical Solutions, Inc. Methods and systems for the efficient acquisition, conversion, and display of pathology images

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100036879A1 (en) * 2008-05-08 2010-02-11 Thomas Friese Method, computer-readable medium, and system for storing, allocating and retrieving medical image data in a distributed computerized system of a clinical facility.
US20100049740A1 (en) * 2008-08-21 2010-02-25 Akio Iwase Workflow template management for medical image data processing
US20100332401A1 (en) * 2009-06-30 2010-12-30 Anand Prahlad Performing data storage operations with a cloud storage environment, including automatically selecting among multiple cloud storage sites
US20120233668A1 (en) * 2011-03-08 2012-09-13 Rackspace Us, Inc. Pluggable Allocation in a Cloud Computing System
US20130208966A1 (en) * 2012-02-14 2013-08-15 Tiecheng Zhao Cloud-based medical image processing system with anonymous data upload and download

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130006865A1 (en) * 2011-06-29 2013-01-03 Mckesson Financial Holdings Limited Systems, methods, apparatuses, and computer program products for providing network-accessible patient health records
KR101597250B1 (ko) * 2011-07-20 2016-02-25 네이버 주식회사 메모 데이터의 동기화를 위한 메모 동기화 시스템, 모바일 시스템 및 메모 동기화 방법
US20130185331A1 (en) * 2011-09-19 2013-07-18 Christopher Conemac Medical Imaging Management System
CN102831561A (zh) 2012-09-05 2012-12-19 重庆中迪医疗设备有限公司 医疗云存储系统
CN102982245A (zh) * 2012-12-06 2013-03-20 常州普适信息科技有限公司 基于云平台的远程医疗系统
EP2911054A1 (de) * 2014-02-20 2015-08-26 Siemens Aktiengesellschaft System zur Verwaltung und Bearbeitung von Daten einer medizinischen Einrichtung

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100036879A1 (en) * 2008-05-08 2010-02-11 Thomas Friese Method, computer-readable medium, and system for storing, allocating and retrieving medical image data in a distributed computerized system of a clinical facility.
US20100049740A1 (en) * 2008-08-21 2010-02-25 Akio Iwase Workflow template management for medical image data processing
US20100332401A1 (en) * 2009-06-30 2010-12-30 Anand Prahlad Performing data storage operations with a cloud storage environment, including automatically selecting among multiple cloud storage sites
US20120233668A1 (en) * 2011-03-08 2012-09-13 Rackspace Us, Inc. Pluggable Allocation in a Cloud Computing System
US20130208966A1 (en) * 2012-02-14 2013-08-15 Tiecheng Zhao Cloud-based medical image processing system with anonymous data upload and download

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
BAHGA ARSHDEEP ET AL: "A Cloud-based Approach for Interoperable Electronic Health Records (EHRs)", IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, IEEE, PISCATAWAY, NJ, USA, vol. 17, no. 5, 1 September 2013 (2013-09-01), pages 894 - 906, XP011525485, ISSN: 2168-2194, [retrieved on 20130830], DOI: 10.1109/JBHI.2013.2257818 *
BENJAMIN M ET AL: "From shared data to sharing workflow: Merging PACS and teleradiology", EUROPEAN JOURNAL OF RADIOLOGY, ELSEVIER SCIENCE, NL, vol. 73, no. 1, 1 January 2010 (2010-01-01), pages 3 - 9, XP026832170, ISSN: 0720-048X, [retrieved on 20091114] *
PATEL G: "DICOM Medical Image Management the challenges and solutions: Cloud as a Service (CaaS)", COMPUTING COMMUNICATION&NETWORKING TECHNOLOGIES (ICCCNT), 2012 THIRD INTERNATIONAL CONFERENCE ON, IEEE, 26 July 2012 (2012-07-26), pages 1 - 5, XP032443043, DOI: 10.1109/ICCCNT.2012.6396083 *

Also Published As

Publication number Publication date
CN105593859A (zh) 2016-05-18
US20160239615A1 (en) 2016-08-18
US11404160B2 (en) 2022-08-02
CN105593859B (zh) 2019-07-12

Similar Documents

Publication Publication Date Title
WO2015043640A1 (de) Verfahren und system zur verwaltung und bearbeitung von daten einer medizinischen einrichtung
EP2911054A1 (de) System zur Verwaltung und Bearbeitung von Daten einer medizinischen Einrichtung
EP3008614B1 (de) Produktivitätsunterstützung in sozialen netzwerken
EP3066596B1 (de) System zur anzeige und bearbeitung von daten einer medizinischen einrichtung
JP4425348B2 (ja) 複合ドキュメント・フレームワーク
AU2014202725B2 (en) Methods and apparatus for translating forms to native mobile applications
CN110311973B (zh) 一种面向多租户的影像云服务系统及方法
DE112016001737T5 (de) Systeme und Verfahren für die Benachrichtigung von Benutzern über Änderungen an Dateien in cloudbasierten Dateispeichersystemen
DE112009000293T5 (de) Automatische Verbindungen zwischen Anwendungskomponenten
US8862600B2 (en) Content migration tool and method associated therewith
US8875057B2 (en) Document management framework
US9202007B2 (en) Method, apparatus and computer program product for providing documentation and/or annotation capabilities for volumetric data
DE102006046310A1 (de) System zur Erzeugung und zum Betrieb einer Softwareapplikation für medizinische Bildgebung
US10430504B1 (en) Presenting document versions
US20180211062A1 (en) Selectively obscuring representative attributes of files
Lebre et al. An accounting mechanism for standard medical imaging services
EP3791250B1 (de) Verfahren und elektronische vorrichtung zum auswählen von dateien in einem dateisystem
Tsyganov et al. The Research Data Management System at the University of Groningen (RUG RDMS): architecture, solution engines and challenges
Inamdar et al. A Web Architecture for E-Health Applications Supporting the Efficient Multipath Transport of Medical Images
EP3502982A1 (de) Erkennung und analyse aufkommender probleme
O'Connor et al. How to prepare neuroanatomical image data
JP2015121941A (ja) 情報処理装置、その制御方法及びプログラム
Pohlmann Migrating the Thunar File Manager to the Extensible Asynchronous Virtual File System Layer GIO
DE202013012497U1 (de) Wiedergabe
DE202011110313U1 (de) Vorrichtung für dynamische Endpunktgeneratoren und dynamisches Entdecken und Brokerage von Remote Objekten

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15025216

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

Country of ref document: EP

Kind code of ref document: A1