DE19625841A1 - Medizinische Systemarchitektur, basierend auf Microsoft OLE/OCX und Automation, bzw. Atomic - Google Patents

Medizinische Systemarchitektur, basierend auf Microsoft OLE/OCX und Automation, bzw. Atomic

Info

Publication number
DE19625841A1
DE19625841A1 DE19625841A DE19625841A DE19625841A1 DE 19625841 A1 DE19625841 A1 DE 19625841A1 DE 19625841 A DE19625841 A DE 19625841A DE 19625841 A DE19625841 A DE 19625841A DE 19625841 A1 DE19625841 A1 DE 19625841A1
Authority
DE
Germany
Prior art keywords
system architecture
medical system
ocx
ole
architecture according
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
DE19625841A
Other languages
English (en)
Inventor
Karlheinz Dorn
Detlef Dipl Ing Becker
Dietrich Dipl Ing Quehl
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
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 AG filed Critical Siemens AG
Priority to DE19625841A priority Critical patent/DE19625841A1/de
Priority to JP17009397A priority patent/JPH1091401A/ja
Publication of DE19625841A1 publication Critical patent/DE19625841A1/de
Priority to US09/881,492 priority patent/US20020124054A1/en
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/543—User-generated data transfer, e.g. clipboards, dynamic data exchange [DDE], object linking and embedding [OLE]
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B6/00—Apparatus for radiation diagnosis, e.g. combined with radiation therapy equipment
    • A61B6/54—Control of apparatus or devices for radiation diagnosis
    • A61B6/548—Remote control of the apparatus or devices
    • 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/20—ICT specially adapted for the handling or processing of medical images for handling medical images, e.g. DICOM, HL7 or PACS
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Theoretical Computer Science (AREA)
  • Medical Informatics (AREA)
  • Software Systems (AREA)
  • Nuclear Medicine, Radiotherapy & Molecular Imaging (AREA)
  • Radiology & Medical Imaging (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Public Health (AREA)
  • Physics & Mathematics (AREA)
  • Primary Health Care (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Epidemiology (AREA)
  • Heart & Thoracic Surgery (AREA)
  • High Energy & Nuclear Physics (AREA)
  • Optics & Photonics (AREA)
  • Pathology (AREA)
  • Biomedical Technology (AREA)
  • Biophysics (AREA)
  • Molecular Biology (AREA)
  • Surgery (AREA)
  • Animal Behavior & Ethology (AREA)
  • Veterinary Medicine (AREA)
  • Stored Programmes (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Processing Or Creating Images (AREA)

Description

Die Erfindung betrifft eine medizinische Systemarchitektur mit einer Modalität zur Erfassung von Bildern, einer Vorrich­ tung zur Verarbeitung der Bilder und einer Vorrichtung zur Übertragung der Bilder, bei dem die Vorrichtung zur Verarbei­ tung ein digitales Bildsystem mit einem Rechner aufweist, der nach einem Verfahren zum Datenaustausch zwischen verschiede­ nen Anwendungsprogrammen (OLE) mit grafischen Steuerelementen und einem Standard für OLE Custom Controls (OCX) arbeitet, wobei jedem einzelnen durch Grenzen limitierten Prozeß ein OCX-Software-Baustein zugeordnet ist.
Medizinische Systeme werden immer komplexer, während der Erweiterungsgrad medizinischer Systeme im gleichen Verhältnis anwächst. Dadurch wird jedoch eine sehr flexible Architektur benötigt.
Die bisher bekannten Architekturen sind im wesentlichen ohne dezentraler Software und Software-Bausteinen entworfen wor­ den.
Weiterhin verhindert der einfache Einsatz von Class-Biblio­ theken trotz des Gebrauches von Objekt-Orientation die Kon­ struktion von flexiblen und wiederverwendbaren Komponenten, da Classes in Wirklichkeit in großem Maße nicht richtig wiederverwendbar sind.
Die Erfindung geht von der Aufgabe aus, Software-Bausteine (Objekte) zu konstruieren, die ein Verhalten aufweisen, das sich möglichst selbst trägt. Weiterhin sollten die Verbin­ dungen zwischen den Bausteinen im Verhältnis zum Ort dieser Bausteine (Objekte) unsichtbar sein, so daß sie entweder alle in einem Prozeß vereinigt oder über ein Netzwerk verteilt sein können.
Die Aufgabe wird erfindungsgemäß dadurch gelöst, daß die Systemarchitektur derart ausgebildet ist, daß die OCX-Soft­ ware-Bausteine mit einem Fernsteuerbaustein erweitert sind, damit die Vorrichtungen und Prozesse fernsteuerbar und die Limitierungen aufgehoben sind. Durch die Kombination von Software-Bausteinen (Objekten) und flexibel verteilten Ereignismechanismen ergibt sich eine gute Lösung dieser Aufgabe.
Es hat sich als vorteilhaft erwiesen, wenn der Fernsteuer­ baustein ein OLE-Automation-Interface ist und die Fernsteue­ rung nach dem OLE-Automation Standard erfolgt. Erfindungs­ gemäß kann der Fernsteuerbaustein ein Automation Interface Baustein ist.
Eine alternative vorteilhafte Lösung ergibt sich, wenn die Fernsteuerung mit Software-IC-Verbindungen beispielsweise nach dem ATOMIC-Standard erfolgt. Erfindungsgemäß kann in diesem Falle der Fernsteuerbaustein ein Connectable/Remote Interface Baustein ist.
Es hat sich als vorteilhaft erwiesen, wenn das Verfahren zum Datenaustausch der Microsoftstandard OLE und der Standard für OLE Custom Controls der Microsoftstandard OCX ist.
Erfindungsgemäß kann die medizinische Systemarchitektur Microsoft OCX zur Erstellung von Komponenten für grafische Benutzeroberflächen innerhalb eines Microsoft-Container-Pro­ zeß verwenden, wobei Microsoft OCX mit OLE-Automation oder mit Software-ICs (Atomic) zur verteilten Ausbreitung eines Ereignisses mit der Kontrollebene und zwischen der Kontroll­ ebene und der Serviceebene kombiniert werden kann.
Das wichtige neue Merkmal ist die Kombination von Microsoft OLE Custom Controls (OCX), einer neu entstandenen Software-Tech­ nologie, mit einem anderen generellen Microsoft-Scrip­ ting-Standard Interface, das als voll verteilungsfähiger netzwerkweiter Mechanismus zur Ausbreitung eines Ereignisses (Event Propagation Mechanismus) dient, sobald Rechner-dezen­ tralisiertes OLE erhältlich ist, um ein realistisches auf einer Systemarchitektur basierendes Model-View-Controller Konzept (MVC) zu erhalten.
Auch kann erfindungsgemäß Microsoft OCX zur Erstellung von Komponenten für grafische Benutzeroberflächen (Graphical User Interface (GUI) Components) innerhalb eines Microsoft-Con­ tainer-Prozeß verwendet werden. Dadurch erhält man wirklich binärkompatible, wiederverwendbare GUI-Komponenten.
Weiterhin läßt sich erfindungsgemäß Microsoft OCX mit OLE-Automation oder mit Software-IC-Verbindungen zur verteilten Ausbreitung eines Ereignisses (Event propagation) mit lokaler Optimierung mit der Kontrollebene und auch zwischen der Kon­ trollebene und der Serviceebene kombinieren. Dies gibt die Flexibilität zur möglichen Verbreitung von Komponenten mit binärkompatiblen Interface, basierend auf Shared Libraries. Dadurch erhält man nicht GUI-abhängige und verteilbare Objekte.
Diese Näherung ermöglicht es, Prozesse nicht durch Design, sondern hauptsächlich durch Konfiguration von gemeinsam genutzten Programmkomponenten (Shared Libraries (DLLs)) zu erstellen.
Die Erfindung ist nachfolgend anhand von in der Zeichnung dargestellten Ausführungsbeispielen näher erläutert. Es zeigen:
Fig. 1 ein vernetztes Datenbanksystem gemäß dem Stand der Technik,
Fig. 2 bis 5 eine Darstellung zur Erläuterung der erfindungs­ gemäßen Zusammenarbeit der Software-Bausteine nach einem ersten Ausführungsbeispiel und
Fig. 6 eine Darstellung zur Erläuterung der erfindungs­ gemäßen Zusammenarbeit der Software-Bausteine nach einem zweiten Ausführungsbeispiel.
In Fig. 1 ist die Systemarchitektur eines medizinischen Compu­ ternetzwerkes dargestellt. Zur Erfassung medizinischer Bilder dienen die Modalitäten 1 bis 4, die als bilderzeugende Systeme beispielsweise eine CT-Einheit 1 für Computertomo­ graphie, eine MR-Einheit 2 für Magnetische Resonanz, eine DSA-Einheit 3 für digitale Subtraktionsangiographie und eine Röntgeneinheit 4 für die digitale Radiographie 4 aufweisen kann. An diese Modalitäten 1 bis 4 können Workstations 5 bis 8 angeschlossen sein, mit denen die Modalitäten 1 bis 4 gesteuert und die erfaßten medizinischen Bilder verarbeitet und abgespeichert werden können. Eine derartige Workstation ist beispielsweise ein sehr schneller Kleincomputer auf der Basis eines oder mehrerer schneller Prozessoren.
Die Workstations 5 bis 8 sind mit einem Bildkommunikations­ netz 9 zur Verteilung der erzeugten Bilder und Kommunikation verbunden. So können beispielsweise die in den Modalitäten 1 bis 4 erzeugten Bilder in einem zentralen Bildspeicher 10 abgespeichert oder an andere Workstations 5 bis 8 weit er­ geleitet werden.
An dem Bildkommunikationsnetz 9 können weitere Workstations als Befundungskonsolen 11 und 12 angeschlossen sein, die mit einem lokalen Bildspeicher 13 und 14, beispielsweise einer Jukebox, verbunden sein können. In den Befundungskonsolen 11 und 12 können die erfaßten und im Bildspeicher 10 abgelegten Bilder nachträglich zur Befundung abgerufen und in dem lokalen Bildspeicher 13 und 14 abgelegt werden, von dem sie unmittelbar der an der Befundungskonsole 11 oder 12 arbei­ tenden Befundungsperson zur Verfügung stehen können.
Der Bild- und Datenaustausch über das Bildkommunikationsnetz 9 kann dabei nach dem DICOM-Standard erfolgen, einem Indu­ striestandard zur Übertragung von Bildern und weiteren medi­ zinischen Informationen zwischen Computern zur Ermöglichung der digitalen Kommunikation zwischen Diagnose- und Theraphie­ geräten unterschiedlicher Hersteller. An dem Bildkommunika­ tionsnetz 9 kann ein Netzwerk-Interface 15 angeschlossen sein, über das das interne Bildkommunikationsnetz 9 mit einem globalen Datennetz verbunden ist, so daß die standardisierten Daten mit unterschiedlichen Netzwerken weltweit ausgetauscht werden können.
In der Fig. 2 ist ein erstes Beispiel einer Software-Archi­ tektur nach dem MVC-Konzept (Model-View-Controller) darge­ stellt, bei dem die Bausteine View, Control und Model jeweils in einem Prozeß enthalten sind. In einer dynamischen Link-Bibliothek (DLL) eines In-Process Server 16, befindet sich der View-Bereich.
Eine dynamischen Link-Bibliothek (dynamic link library) ist eine Sammlung von Objektfiles, die zur Laufzeit (dynamisch) eines Prozesses diesem hinzugelinked (verfügbar gemacht) und von mehreren Prozessen gleichzeitig genutzt werden kann. Beim In-Process Server 16 ist die Implementierung eines Services derart realisiert, daß dieser Service immer im selben Prozeß ablaufen muß wie der Kunde (client), der diesen Service benö­ tigt. Hierzu eignen sich insbesondere DLLs, da sie den Ser­ vice dem Prozeß dynamisch bei Bedarf zur Verfügung stellen.
In dem Server 16 ist das Anwendungsprogramm 17 geladen, das mehrere OCX-Software-Bausteine 18 aufweist. An den OCX-Bau­ steinen 18 sind als Fernsteuerbausteine Automation Interface Bausteine 19 des OLE-Automation Standards angekoppelt. Auf­ grund dieser Bausteine wird es ermöglicht, mit anderen loka­ len Servern zu kommunizieren. So kann in einem zweiten loka­ len Server 20 ein Controller 21 zur Kopplung der View-Ebene mit der Model-Ebene gespeichert sein. Dieser Controller 21 ist ebenfalls mit einem entsprechenden Automation Interface Baustein 22 gekoppelt.
Der Controller 21 eine Komponente aus der Model-View-Control­ ler (MVC) Welt. Dabei repräsentiert der View eine Sichtweise auf das Model. Model und View sind über eine Controller Komponente gekoppelt. Diese Controller Komponente besteht zu wesentlichen Teilen aus einem Zustandsautomaten, einer sogenannten Finite State Machine (FSM).
Die Model Komponente kann in zwei weiteren lokalen Servern 23 und 24 enthalten sein, in denen die Service-Bausteine 25 und 26 über weitere Automation Interface Bausteine 27 bis 31 miteinander gekoppelt sind.
In den Fig. 3 bis 5 ist der Aufbau im wesentlichen der gleiche, lediglich die Prozeßaufteilung ist anders. Während im ersten Fall gemäß Fig. 2 alle MVC-Bausteine in jeweils einem getrennten Prozeß angeordnet sind, sind beim Beispiel gemäß Fig. 3 die Bausteine View und Control in einem Prozeß und die Model-Bausteine in getrennten Prozessen angeordnet. Das bedeutet, daß sich die Kontrollebene des Controllers 21 bereits in der gleichen dynamischen Link-Bibliothek (DLL) eines In-Process-Servers 32 wie das Anwendungsprogramm 17 der View-Komponente befindet.
Beim Gegenstand gemäß Fig. 4 sind die Bausteine Control und Model in einem Prozeß zusammengefaßt und befinden sich in der gleichen dynamischen Link-Bibliothek (DLL) des lokalen Ser­ vers 33. Erfindungsgemäß besteht auch die Möglichkeit, die Bausteine View, Control und Model gemäß Fig. 5 in einem Pro­ zeß in der dynamischen Link-Bibliothek (DLL) eines In-Pro­ cess-Servers 34 zu vereinen, wobei ein weiterer Service-Bau­ stein in einem weiteren lokalen Server 24 enthalten ist.
In der Fig. 6 ist ein zweites Beispiel nach dem MVC-Konzept (Model View Controller) dargestellt, das dem Beispiel gemäß Fig. 2 ähnlich ist. Auch hier befindet sich der View-Bereich wiederum in einer dynamischen Link-Bibliothek (DLL) des In- Process-Servers 16. An den OCX-Software-Bausteinen 18 des in dem Server 16 geladenen Anwendungsprogramm 17 sind sogenannte Software-IC-Verbindungen 35 (Connectable/Remote) als Fern­ steuerbausteine anstelle der Automation Interface Bausteine 19 angekoppelt. Mittels dieser Bausteine wird die Kommunika­ tion mit anderen lokalen Servern 20, 23 und 24 ermöglicht. So kann in dem lokalen Server 20 der Controller 21 zur Kopplung der View-Komponente mit der Model-Komponente sein. Dieser Controller ist ebenfalls mit entsprechenden Software-IC-Ver­ bindungen 36 und 37 gekoppelt. Die Model-Komponente ist in den lokalen Servern 23 und 24 angeordnet, in denen über wei­ tere Software-IC-Verbindungen 38 bis 41 die Service-Bausteine 25 und 26 enthalten sind.
Diese Connectable/Remote-Software-IC Fernsteuerbausteine sind voll-verteilungsfähige Eingangs/Ausgangs-Ereignisse, basie­ rend auf ein Ereignis kommunizierendes Netzwerk, daß dyna­ misch linkbar und durch Eingangs/Ausgangs-Verbindungspunkte konfigurierbar ist.
Der Vorteil dieses erfindungsgemäßen Vorschlages liegt in seiner Flexibilität und noch mehr in seiner Produktivität zur Erlangung von in verschiedenen medizinischen Systemprodukt­ architekturen wiederverwendbaren Software-Bausteinen.
Die Software-IC-Verbindungen erlauben eine wirkliche belie­ bige Verteilung der Komponenten in ablauffähigen Prozessen ohne in Verklemmungszustände zu geraten, wie dies bei anderen Kommunikationsmechanismen (z. B. Corba) der Fall sein kann, ohne Quellcode-Änderung. Die Komponenten können dadurch sogar zur Laufzeit beliebig kombiniert werden. Ein weiterer Vorteil ist, daß die Verbindungen n:m Verbindungen sein können, was bei herkömmlichen Systemen meist nicht möglich ist, wobei sich die Verbindungspartner anonym zur Laufzeit finden.
Zusätzlich unterscheiden sich die Komponentenverbindungen von herkömmlichen auch dadurch, daß auf den Verbindungen Ereig­ nis-Daten übertragen werden und keine entfernten Methoden gerufen werden.

Claims (12)

1. Medizinische Systemarchitektur mit einer Modalität (1 bis 4) zur Erfassung von Bildern, einer Vorrichtung (5 bis 8, 11, 12) zur Verarbeitung der Bilder und einer Vorrichtung (9) zur Übertragung der Bilder, bei dem die Vorrichtung (5 bis 8, 11, 12) zur Verarbeitung ein digitales Bildsystem mit einem Rechner aufweist, der nach einem Verfahren zum Datenaustausch zwischen verschiedenen Anwendungsprogrammen (OLE) mit grafi­ schen Steuerelementen und einem Standard für OLE Custom Con­ trols (OCX) arbeitet, wobei jedem einzelnen durch Grenzen li­ mitierten Prozeß ein OCX-Software-Baustein (18) zugeordnet ist, dadurch gekennzeichnet, daß die Systemarchitektur derart ausgebildet ist, daß die OCX-Software-Bausteine (18) mit einem Fernsteuerbaustein (19, 22, 27 bis 31, 35 bis 41) erweitert sind, damit die Vorrichtungen und Prozesse fernsteuerbar und die Limitierungen aufgehoben sind.
2. Medizinische Systemarchitektur nach Anspruch 1, da­ durch gekennzeichnet, daß der Fernsteu­ erbaustein ein OLE-Automation-Interface (19, 22, 27 bis 31) ist.
3. Medizinische Systemarchitektur nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die Fernsteuerung nach dem OLE-Automation Standard erfolgt.
4. Medizinische Systemarchitektur nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß der Fernsteuerbaustein ein Automation Interface Baustein (19, 22, 27 bis 31) ist.
5. Medizinische Systemarchitektur nach Anspruch 1, da­ durch gekennzeichnet, daß die Fernsteue­ rung mit Software-IC-Verbindungen (35 bis 41) erfolgt.
6. Medizinische Systemarchitektur nach Anspruch 1 oder 5, dadurch gekennzeichnet, daß die Fernsteuerung nach dem ATOMIC-Standard erfolgt.
7. Medizinische Systemarchitektur nach Anspruch 5 oder 6, dadurch gekennzeichnet, daß der Fernsteuerbaustein ein Connectable/Remote Interface Baustein (35 bis 41) ist.
8. Medizinische Systemarchitektur nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, daß das Verfahren zum Datenaustausch der Microsoftstandard OLE ist.
9. Medizinische Systemarchitektur nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, daß der Standard für OLE Custom Controls der Microsoftstan­ dard OCX ist.
10. Medizinische Systemarchitektur nach einem der Ansprüche 1 bis 9, gekennzeichnet durch die Verwendung von Microsoft OCX zur Erstellung von Komponen­ ten für grafische Benutzeroberflächen innerhalb eines Prozeß-Microsoft Containers.
11. Medizinische Systemarchitektur nach einem der Ansprüche 1 bis 10, gekennzeichnet durch die Kombination von Microsoft OCX mit OLE-Automation zur ver­ teilten Ausbreitung eines Ereignisses mit der Kontrollebene und zwischen der Kontrollebene und der Serviceebene.
12. Medizinische Systemarchitektur nach einem der Ansprüche 1 bis 11, gekennzeichnet durch die Kombination von Microsoft OCX mit Software-IC-Ver­ bindungen zur verteilten Ausbreitung eines Ereignisses mit der Kontrollebene und zwischen der Kontrollebene und der Ser­ viceebene.
DE19625841A 1996-06-27 1996-06-27 Medizinische Systemarchitektur, basierend auf Microsoft OLE/OCX und Automation, bzw. Atomic Ceased DE19625841A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE19625841A DE19625841A1 (de) 1996-06-27 1996-06-27 Medizinische Systemarchitektur, basierend auf Microsoft OLE/OCX und Automation, bzw. Atomic
JP17009397A JPH1091401A (ja) 1996-06-27 1997-06-26 医療システムアーキテクチャ
US09/881,492 US20020124054A1 (en) 1996-06-27 2001-06-14 Medical system architecture based on microsoft OLE/OCX and automation or, respectively, atomic

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE19625841A DE19625841A1 (de) 1996-06-27 1996-06-27 Medizinische Systemarchitektur, basierend auf Microsoft OLE/OCX und Automation, bzw. Atomic

Publications (1)

Publication Number Publication Date
DE19625841A1 true DE19625841A1 (de) 1998-01-02

Family

ID=7798236

Family Applications (1)

Application Number Title Priority Date Filing Date
DE19625841A Ceased DE19625841A1 (de) 1996-06-27 1996-06-27 Medizinische Systemarchitektur, basierend auf Microsoft OLE/OCX und Automation, bzw. Atomic

Country Status (2)

Country Link
JP (1) JPH1091401A (de)
DE (1) DE19625841A1 (de)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0838796A2 (de) * 1998-01-28 1998-04-29 Siemens Aktiengesellschaft Daten- bzw. Informationsübertragungssystem
DE19902321A1 (de) * 1999-01-21 2000-07-27 Siemens Ag Verfahren zum Bearbeiten von Bildern unterschiedlicher Bildformate
WO2002031610A2 (de) * 2000-10-04 2002-04-18 Syskron Gmbh Verfahren und vorrichtung zum erfassen von betriebsdaten einer produktionsanlage
DE10157633A1 (de) * 2001-11-26 2003-08-28 Siemens Ag Medizinische Systemarchitektur mit einer komponentenorientierten Architektur zur Befundung und Dokumentation
DE102008044843A1 (de) 2008-08-28 2010-04-22 Siemens Aktiengesellschaft Verfahren und System zum Verteilen von Applikationen
US8094909B2 (en) 2007-10-09 2012-01-10 Siemens Aktiengesellschaft Apparatus and method for remotely controlling in real time measurement parameters of a magnetic resonance (MR) scanner

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
LANG Eric: Software aus OCX-Komponenten, MicrosoftSystems Journal 1/95, 1995, S. 25-38 *
MORNEBURG, Heinz (Hrsg.): Bildgebende Systeme für die medizinische Diagnostik, Erlangen, Publics MCD Verlag, 3. Aufl., 1995, S. 680-697 *
ORFALI, Bob, HARKEY, Dan: Client/Server with Distributed Objects, Byte, April 1995, S. 151-162 *

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0838796A2 (de) * 1998-01-28 1998-04-29 Siemens Aktiengesellschaft Daten- bzw. Informationsübertragungssystem
EP0838796A3 (de) * 1998-01-28 1998-06-10 Siemens Aktiengesellschaft Daten- bzw. Informationsübertragungssystem
WO1999039251A1 (de) * 1998-01-28 1999-08-05 Siemens Aktiengesellschaft Daten- bzw. informationsübertragungssystem
US6883030B1 (en) 1998-01-28 2005-04-19 Siemens Aktiengesellschaft Data visualization with independent data-utilization and data-supplying components
DE19902321A1 (de) * 1999-01-21 2000-07-27 Siemens Ag Verfahren zum Bearbeiten von Bildern unterschiedlicher Bildformate
WO2002031610A2 (de) * 2000-10-04 2002-04-18 Syskron Gmbh Verfahren und vorrichtung zum erfassen von betriebsdaten einer produktionsanlage
WO2002031610A3 (de) * 2000-10-04 2003-06-26 Syskron Gmbh Verfahren und vorrichtung zum erfassen von betriebsdaten einer produktionsanlage
DE10157633A1 (de) * 2001-11-26 2003-08-28 Siemens Ag Medizinische Systemarchitektur mit einer komponentenorientierten Architektur zur Befundung und Dokumentation
US8094909B2 (en) 2007-10-09 2012-01-10 Siemens Aktiengesellschaft Apparatus and method for remotely controlling in real time measurement parameters of a magnetic resonance (MR) scanner
DE102008044843A1 (de) 2008-08-28 2010-04-22 Siemens Aktiengesellschaft Verfahren und System zum Verteilen von Applikationen

Also Published As

Publication number Publication date
JPH1091401A (ja) 1998-04-10

Similar Documents

Publication Publication Date Title
DE19781804B4 (de) Vorrichtung zur Simulation einer Echtzeit-Prozesssteuerung
DE10351351B4 (de) Verfahren und System zur dynamischen Generierung von User Interfaces
EP2990892B1 (de) Verfahren zum Verbinden einer Eingabe/Ausgabe-Schnittstelle eines für das Testen eines Steuergeräts eingerichteten Testgeräts
EP3495903B1 (de) Verfahren zum bedienen und beobachten einer zu steuernden technischen anlage sowie operator-system
DE102005031245A1 (de) Verfahren zum Test eines klinischen und/oder medizintechnischen Systems und Verfahren zur Steuerung medizintechnischer Untersuchungsabläufe in einem klinischen und/oder medizintechnischen System
EP3480672B1 (de) Verfahren zum erkennen und anzeigen von operator-zugriffen auf prozessobjekte sowie operator-system
DE69911986T2 (de) Einrichtung und verfahren zum ausgleichen und verteilen von steueralgorithmenlasten
DE102020213920A1 (de) MR-Scanner Steuerung
DE19625841A1 (de) Medizinische Systemarchitektur, basierend auf Microsoft OLE/OCX und Automation, bzw. Atomic
DE19625834A1 (de) Medizinische Systemarchitektur mit Scripting- oder Virtual-Code
DE102011001675A1 (de) Verfahren zur Verarbeitung radiologischer Bilder
DE19625835A1 (de) Medizinische Systemarchitektur mit Komponenten-Navigation
EP1217476A2 (de) Vorrichtung und Verfahren zur Inbetriebnahme und Diagnose von Steuerungssystemen
EP1092210B1 (de) Vorrichtung und verfahren zur erstellung eines virtuellen anlagenmodells
DE102017203048B3 (de) Verfahren zum Bestimmen eines Projektionsdatensatzes, Projektionsbestimmungssystem, Computerprogrammprodukt und computerlesbares Speichermedium
DE19625862A1 (de) Medizinische Systemarchitektur mit Komponenten-Navigation mit Hilfe von HTML
EP2672660B1 (de) Verfahren zur Beeinflussung der Buskommunikation eines Steuergeräts
EP3499324A1 (de) Verfahren zur modularen verifikation einer konfiguration eines geräts
DE19625839A1 (de) Medizinische Systemarchitektur mit WWW-Browser Dateiformat
EP3285162A1 (de) Verfahren zum projektieren eines projektes sowie anordnung zur durchführung des verfahrens
DE102020205034A1 (de) Verfahren zu einem Einstellen von zumindest einem Messparameter für ein Messprotokoll einer Magnetresonanzuntersuchung
DE19625842A1 (de) Medizinische Systemarchitektur, basierend auf Microsoft OCX-Technologie und dem medizinischen Bild-Standard DICOM
DE102015213269B4 (de) Modulares Baukastensystem für eine Steuereinrichtung einer Magnetresonanzeinrichtung und Verfahren zur Herstellung einer Steuereinrichtung einer Magnetresonanzeinrichtung
DE19625833A1 (de) Medizinische Systemarchitektur mit JAVA-Applets und Script
DE19625838A1 (de) Medizinische Systemarchitektur mit Komponenten-Navigation

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8120 Willingness to grant licences paragraph 23
8131 Rejection
8170 Reinstatement of the former position
8131 Rejection