This post details the medical device directory I built demonstrating the concept of a knowledge base and expert system that would assist a healthcare organization in their medical device integration efforts. My idea was to input into an expert system (or reasoner) with an associated knowledge base a medical device inventory with the result of the expert system providing a list of the devices that are already integrate-able, need network transformation, and are not integrate-able. As a secondary output, I wanted to list the available sensor and setting outputs available for the interface broker to the EHR. As detailed in the previous blog post, some other possible approaches for this knowledge are that the devices could report their status and information via publish/subscribe functionality/capability with interface managing that, however, would still need a device directory or device knowledge base.

As a preparatory task, I did a search for any currently available knowledge bases and ontologies that could assist me in this project. The results showed that a medical device integration system implementation spans different nomenclature and ontological domains, some of which compete across the nomenclature and ontological areas. This meant that I had to build the device ontology from ‘scratch’ and in the end was not able to incorporate any of the ontologies or nomenclatures that were available.

As part of this project, I also reviewed available knowledge base and expert system applications that could be used for my knowledge base. I wanted to use an ontologically based system that was open source, free, currently available, currently supported and able to output the knowledge base and any results in a standard format. In the end, I chose Protégé Desktop version 5.2.0-win to build the ontology and knowledge base and used its reasoner extension to mimic an expert system interface. This did change the project scope such that feeding the expert system a medical device inventory list was not possible; instead, queries were constructed against the knowledge base so that specific devices having the query characteristics were retrieved.


I had several project constraints: limited time (7.5 weeks) to a build proof of concept system, limited availability of knowledge base and expert system products, limited to no ontologies to inherit or incorporate into the medical device ontology, and limited access to publicly available information on medical devices and their characteristics. For example, the knowledge base lacks specific units to be associated with the sensor readings. Unfortunately, an open source effort to build units (QUDT, 2017) for clinical and device use had not developed the ontology for the units used in medical devices yet.

As another example, access to medical device specifications and manuals is limited, so only those that were openly available via the internet could be used for building the ontology and knowledge base and these tended to be of older ‘legacy’ devices. Lastly, due to the time constraints, I was only able to model several medical device types and instances in the knowledge base. There are thousands of different medical devices available on the market and used by healthcare organizations, so ‘building out’ the knowledge base would take much more time than was available for this project and would need to be an ongoing effort which incorporated medical devices as they were released onto the market.

Ontology and Knowledge Base

I built the general medical device ontology by class and characteristic, incorporated specific medical device instances and then built queries as proof that the knowledge base was constructed appropriately for the task of identifying device characteristics key for integration. Several screenshots of the final ontology, knowledge base and query results are shown below. Figure 1 shows the basic ontology to include the classes (left side of figure) and object properties (right side of figure). In the Protégé approach to ontologies and knowledge bases, the classes are shown as a hierarchy. As shown in Figure 2, the classes of device, device component, Hospital, ModelID, Network Protocol, Organization, Quality, etc., are on an equal level of the hierarchy. Moreover, the device class is further subdivided into the device types: aggregation and clinical. Lastly, the clinical device class is further divided into device types and then specific models of those device types. Figure 3 shows some of the other classes and subclasses hierarchies in more detail.

The object properties can be thought of as actions or capabilities that can be assigned to the different classes and/or establish relationships between the classes. In the case of this ontology, object properties of aggregates, networks, and measures (see right side of Figure 1) are key object properties that were used to establish the key class characteristics and relationships required for medical device integration and query development. All figures can be clicked to enlarge.

Figure 1. Medical Device Class Hierarchy and Object Properties (image courtesy of Bridget Moorman)

Figure 2. Medical Device Subclasses Hierarchy (image courtesy of Bridget Moorman)


Figure 3: Quality (Sensor and Setting Readings) Class and Subclass Hierarchy (image courtesy of Bridget Moorman)

Figure 4 below demonstrates how the classes and object properties are used to build characteristics and relationships with an example of a specific blood pressure model and its characteristics. It inherits some characteristics from a general blood pressure monitor, however, in this case the object property of networks is unique to this specific vendor model of blood pressure monitor so the affiliation is made at the model level and not the general device type class level.

Figure 4: Omron Blood Pressure Monitor Characteristics (image courtesy of Bridget Moorman)

In Figure 5 below, another example of a device class is shown: the aggregation device. This device is the aggregator and interface point for all of the medical device data to the interface broker or EHR. As seen below the object property of aggregates is used to identify and affiliate which devices the aggregation device can aggregate. In this case the Qualcomm2Net is shown to aggregate two devices: the Omron blood pressure monitor and the Nonin pulse oximeter. This particular device is actually used in a patient home to aggregate medical device data from personal devices that might be used in remote monitoring programs for patients with chronic diseases. It was included in the proof of concept to show that the ontology and knowledge base design need not apply to only model hospital based scenarios.

Figure 5: Qualomm2Net Aggregation Device Characteristics (image courtesy of Bridget Moorman)

Expert System Simulation: Queries

Figures 6 through 8 below show the results of four specific queries that demonstrate the key information that would be valuable when implementing a medical device implementation system. Figure 6 shows a query of the knowledge base about which medical devices have the wireless networking capability. In Protege one can also have specific instances of a class and in this case, dummy serial numbers were used to assign instances so that the proof of concept could show that the query would also retrieve the actual devices that have this capability and not just the model.

Figure 6: Query Result for Wireless (image courtesy of Bridget Moorman)

Figure 7 shows a query of the knowledge base to determine what type of medical devices have DB9 network connectors. This question is an indirect way to determine if a network transformation is needed for the medical device to connect to the network and integrate its data to an EHR. In Figure 2, there is a subclass hierarchy of network dongle that could also be queried to determine if there is a network transformation dongle available for that medical device.

Figure 7: Query Results of DB9 Network Connector (image courtesy of Bridget Moorman)

Figure 8 below demonstrates the secondary object of the project to show what sensor and setting outputs are available with a medical device inventory by showing the query results of which medical devices in the knowledge base measure blood pressure. As the results window shows, there are three devices which offer that sensory information for aggregation and integration.

Figure 8: Query Results for Medical Devices that Measure Blood Pressure (image courtesy of Bridget Moorman)

Conclusion, Possible Improvements and Future Directions

The purpose of this project was to build a proof-of-concept knowledge base and expert system to assist in implementing a medical device integration system to an interface broker or EHR and in a rudimentary way, the ontology and knowledge base built demonstrated the concept. Due to the project constraints, Protégé was used to build a medical device integration knowledge base by constructing an ontology with specific medical device model information needed for medical device integration. For the expert system functionality the reasoner function extension to Protégé was used to query the knowledge base. This knowledge base is missing the location information ontology and units ontology: those ontologies need to be designed and implemented within the project as there was no complete ontology representing the attributes correctly that could be inherited into the medical device integration ontology and knowledge base. For the location ontology, specific reference to healthcare organizations and care locations would be necessary.

When designing the medical device integration ontology, I named the generic medical device classes. In the future, some of the specific nomenclatures already developed (FDA-UDI) could be used for those generic names. Other nomenclatures that could possibly be used in the quality class for sensor and setting names are the data standard nomenclatures developed by IEEE and LOINC. In addition, the prototype could be more robust with the addition of more specific medical device model knowledge. Moreover, the ontology could include the data types that are available in a standard configuration versus in a vendor proprietary configuration. Lastly, an expert system ‘front-end’ could be developed that would allow comparison of a healthcare organization’s medical device inventory with the knowledge base to automatically determine the ‘integrate-ability’ status of their medical device inventory.

During the preparation and implementation of this project, I wondered why this particular type of knowledge base had not been developed before. Upon completion of the proof-of-concept, I realized that it was a knowledge base that needed to be built, populated with the knowledge and most importantly, maintained to add, sunset and modify any device knowledge changes. It is not a static knowledge base and to be truly valuable should be linked to other ontologies and knowledge bases to be robust. Building this knowledge base is one of the more tedious and difficult aspects of medical device integration (whether it is on paper, in an ontological frame or a database frame). Nevertheless, if the ideas and benefits promulgated for interoperability and integration are to come to fruition, this hard work needs to be done.

Lastly, it was very enlightening to see what has happened in the last ten years in this area of medical device integration to EHRs both in industry and in research. There is still a gap between those two areas with regard to solutions with the software middle solutions pacing ahead of the end solutions or relying upon knowledge and capabilities of medical devices that are not yet widely available.   It certainly will be interesting to see what the next ten years will bring about for medical device connectivity and integration.

I’d like to thank Davide Sottara, PhD, Arizona State University and Mayo Institute, for his guidance and assistance in building this prototype.