SODA - Service Oriented Integration of Medical Devices in Hospitals

Question

In this thread I will write about my dissertation project. It addresses the problem of the integration of medical devices with their proprietary interfaces and data models into the existing hospitals´ IT infrastructure.
Interoperability is an almost non-existent feature of medical devices. The consequences of non-interoperable devices in hospitals are manifold. Medical data produced by devices cannot be directly integrated into hospital information systems for medical documentation. Thus, important data will be lost and examinations have to be repeated if required information is not available due to incomplete documentation. In addition, the documentation quality is affected by human errors due to manual nonelectronic steps and media discontinuities. Another example is maintenance. Medical devices have to be maintained at regular intervals. Thus, an inventory of all devices, their status and maintenance intervals is needed for generating a maintenance manual. Currently there is usually no possibility for automatically getting a detailed inventory of all medical devices in a hospital (or section of a hospital).
The market size in conjunction with a multitude of companies and products (the DIMDI information system contains data about 60,000 medical devices) results in challenges concerning interoperability due to different proprietary hard- and software interfaces, data structures and semantical interpretations. Initiatives like IHE (Integrating the Healthcare Enterprise) are trying to push standardization in the medical sector. However u2013 as mentioned above - the current situation is still unsatisfying and increasingly getting worse due to the continuously growing number of medical devices and associated interfaces.
A promising approach for overcoming interoperability issues is the service oriented device integration, also known as SODA (Service Oriented Device Architecture). The basic concept is the encapsulation of devices as services, analogous to enterprise services in service oriented architectures (SOA). An enterprise service is a software component that offers a business functionality on a highly semantical level by specifying the interface in a standardized way (e.g. by the Webservice Description Language u2013 WSDL). Highly semantical level especially means, that a service is self-descriptive in a way that it can be consumed dynamically and loosely coupled by other components with a consistent understanding of shared data. In the medical domain a device service for instance could offer functionality for measuring the current blood pressure of a patient. Based on such basic services more complex services (like a patient monitoring system) can be realized.
The main advantage of the service oriented approach is that the manufacturer-specific device interface does not have to be known by the service consumer and by the programmer respectively, as it is encapsulated by a standardized service interface. This enables the extension of IT supported medical processes by devices, e.g. by using the Business Process Execution Language (BPEL). In addition new functionalities could be added to the device service that are logically related to the device but not offered by the device itself (e.g. tracking & tracing functionalities); so the device service can be considered as a virtual device. Therefore software maintenance will become easier, because the service interface remains unchanged in case of a device exchange or device interface changes. In my dissertation project I will explore the advantages and obstacles of the SODA concept in comparison to existing approaches for integrating medical devices in hospitals.
The SODA approach is in accordance with the SAP Enterprise SOA (ESOA) strategy. For instance, the scope of the Healthcare Community Definition Group is to further enhance the Enterprise Services (ES) Bundles Patient Administration and Medical Activities, Patient Billing and Invoicing and to define a new ES Bundle on Medical Documentation. SODA projects define services for devices. These services can use or combined with Enterprise Services, e.g., for Patient Administration. In the EU funded project SOCRADES, SAP Research explores the SODA approach in other domains, especially industrial automation.

Answer 1

Hmm, perhaps your other discovery settings are configured that it'll get the OOB OU because you're OOB OU is under some other OU that's configured to be discovered and you have the recursive and group settings turned on, CHECK this first.
Remove the OOB from your discovery. For testing purposes, remove (delete) one or more machine objects from the ConfigMgr console, wait a while and then run the AD System Discovery again and check what object gets there. AD system discovery shouldn't look
objects from other OUs than the ones you've specified in the discovery settings.
I'm not that familiar with vPro, so the behavior you're seeing might well be the default, but I doubt that.. Doen't make sense that you control your computer objects.
For more information you could also post adsysdis.log from the configmgr server.