IT-Architecture for a Boundaryless Hospital

IT-Architecture for a Boundaryless Hospital

Dr. Jörg Caumanns, Christian Giertz, Anne Grohnert, Ben Kraufmann
Prof. Dr. Dr. Kurt J.G. Schmailzl, Franziska Thomas

Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS
ccc. Center for Connected Health Care UG

The metaphor of a Boundaryless Hospital refers to a patient- rather than hospital-centered care structure, implemented by "digital" and "analogue companions" for an aging population. While the management of care is still organized in top-down manner from the hospital via connected regional care provider organization to the patient, the medical care processes are reorganized bottom-up; large parts of diagnostics and therapy take place in the home environment of the patient. Via a monitoring structure, information about the current state of the patient flows back to the hospital via the regional care level, which, based on the image of a control loop, can use this information for continuously adjusting the procedures and goals of care and treatment.
The backbone of the Boundaryless Hospital is thus no longer a conventional architecture made of concrete, steel and glass, but an IT architecture that provides a wide variety of bidirectional communication and data flows along a hierarchy of decentralized care levels. Compared with established approaches to regional care networks [1], the implementation of a Boundaryless Hospital poses additional challenges that arise primarily from the requirement of a seamless integration of digital and analogue processes.

Endpoint Heterogenity

Core elements of the digilog concept are the use of medical devices and medTech devices in the home environment as well as the use of miniaturized, sensors at the patient (or at least the patient’s site) to protect high-risk patients, but also to make preventive measures more effective. The use of these devices is always bound to a specific care goal and purpose: the foundation is always an order for long-term observation or diagnostics, which is triggered by a doctor and performed through a dedicated eHealth Center. Based on this requirement, the eHealth Center defines the patient data to be processed and selects the devices best suitable for the patient for this purpose. The patient’s family doctor or appropriately trained nursing staff (eg agneszwei-Nurses) will then put them to operations within the home environment of the patient. The data collected via the devices flow back to the attending physician and the eHealth Center via an IT infrastructure.
In digilog, the outlined interaction of orders, required monitoring data and used devices was modelled as a semantic network (see figure). This network forms both the basis of device management (which patient was given which device for capturing which data) as well as authorization and access control (which data are collected through which devices for what purpose). From the semantic network, all necessary forms of consent to be given by the patient are personalized by the given order and the specifically recorded data at the time the device is handed over to the patient. Because the data capturing devices devices are always related to a concrete order, it can be technically ensured that only the data required for the specific purpose is recorded and processed. As a result, the earmarking of data protection is directly linked to medical necessity [2].
The linking of patients and devices is managed via the master patient index of the digilog platform. Using the IHE PIX integration profile [3], this is implemented in such a way that the device numbers of the devices issued can be used by all connected systems as pseudonymous patient IDs. As a result, one authorized doctors are able to combine the data recorded with a patient and stored under the respective device numbers.

Gerätelogistik

Endpoint Heterogenity

The digilog model goes far beyond the "classic" monitoring of patients using portable medical devices by as well including diagnostic and therapeutic procedures performed in the patient's immediate environment. Examples are mobile laboratory diagnostics or the use of portable radiological equipment. In addition, data from typical lifestyle devices such as SmartWatches can be captured and used to validate or even supplement medical data.
To meet this heterogeneity of data-collecting endpoints, digilog relies on an equally heterogeneous, distributed architecture of data stores:

  • Registering, querying and retrieving data via transactions defined in the IHE Cross-Enterprise Document Sharing (XDS) integration profile [3]: data is stored as documents in a standard IHE XDS platform;
  • providing and retrieving data as HL7 FHIR Observation Resources [4]: ​​An IoT hub and standardized REST interfaces allow granular data (eg single lab values) to be written to a standard FHIR store;
  • Linking existing IHE XDS Document Repositories: Existing data stores can be connected transparently, given that the data is registered to the digilog Document Registry. This method is currently being used to make key sequences of ultrasound exams from GE-hosted cloud storage available to digilog.

A special feature of the digilog platform is that access to the data is always possible via the interfaces of the FHIR store as well as the XDS document management, even if the requested data has been stored in the respective other storage system. Examples for the benefits of using such an abstraction of storage and access logic are:

  • The results of a long-term ECG are written as a structured document to the XDS document managing system. Physicians can retrieve generated findings as PDF files via the XDS interface. Via the FHIR interface, the individual measurements coded in the document can be queried and subsequently correlated with other data. Renderings of specific forms of presentation can also be realized in this way (see graphic below for the representation of an ECG in the digilog doctors’ cockpit);
  • Data from personal medical devices are written to the FHIR store via the IoT hub. Such data are stored as individual values ​​and can be queried as such from the FHIR store via REST interfaces. Existing hospital information systems acting in the role of an IHE Document Consumer can also retrieve this data via the IHE interface as a dynamically generated PDF or structured CDA document.

All software modules developed for digilog run within their own Docker containers. This makes it easy to deploy the same component either within the eHealth center, an external data center, or a cloud infrastructure, without affecting any other systems within the digilog ecosystem.

CDA-Dokument

strukturiertes CDA-Dokument abrufen.

References

[1] Witting K, Moehrke J: Health Information Exchange – Enabling Document Sharing Using IHE Profiles. IHE IT Infrastructure White Paper. Januar 2012.
[2] Caumanns J: Datenschutz und Datennutz bei elektronischen Patientenakten. Datenschutz und Datensicherheit 37 (2013), Nr.3, S.137-142
[3] IHE IT Infrastructure Technical Framework: www.ihe.net
[4] HL7 Fast Healthcare Interoperability Resources (FHIR): www.hl7.org

passbild_jc
en_GBEnglish
de_DEGerman en_GBEnglish