While reading a couple of articles in the healthcare IT industry, several statements stood out as they highlighted some of the issues with EHRs, the data they collect, and how useful that data is to clinicians. In a recent Healthcare IT news article Dr Anders of Medicomp stated with regard to his desire to follow a diabetic patient that, "I have to click on six different places to see if the patient's renal condition is getting better or worse." In another article, InterMountain announced that they were working with Clinical Architecture to develop a “clinigraphic technology, which leverages ontologies developed using Clinical Architecture’s terminology management tools”...and that “finding relevant patient data faster allows clinicians to make better decisions at the point of care, avoid medical errors, and improve healthcare quality and outcomes.”
Those quotes segue very nicely into the subject of this blog post, i.e., it’s really all about the data and how you use it. I discuss this with Tracy Rausch, CEO of DocBox. She is doing something similar with her product, however, at a different point in the technology chain and workflow. We will cover what DocBox is as well as some thoughts on medical device connectivity.
I met Tracy over 10 years ago when we were both employed by a large integrated healthcare system as clinical system engineers. We worked on clinical system integration projects requiring multi-disciplinary knowledge across the engineering, information technology, clinical and project management domains. Since then, Tracy, as CEO of DocBox, has been developing a comprehensive device connectivity product which has evolved into a distributed platform integrating data from the bedside and other hospital information systems which when combined become knowledge for improvements in clinical care as well as operational efficiency.
Bridget Moorman: Tell me about DocBox and your product: what it does, where are you installing it, how you want it to evolve?
Tracy Rausch: DocBox is a distributed platform that integrates medical device and other hospital information technology data for improvements in clinical care as well as operational efficiency. We provide clinical decision support (CDS) as well as operational efficiency reports using data visualization and predictive analytics. We are also aiming in the future for automation with these processes.
We are currently deploying internationally in India, Africa and southwest Asia with a planned launch in the United States in Q4 of this year. We hope for FDA approval of our device by the end of 2017.
Our product consists of hardware and software. The hardware suite has a bedside solution comprised of a touchscreen device and medical device adapter boxes (a mini-PC). We also have a cluster server at the enterprise level for data storage and hospital-wide analytics support. Our software essentially builds a data bus with which we aggregate the medical device data and other hospital-based data (example: electronic medical record (EMR) data; admit, discharge and transfer (ADT) data; and laboratory data) into our information model. From there we can provide data visualization as well as decision support based on analysis of the aggregated data.
Bridget Moorman: What do you mean by an information model? One definition is:
… an information model is usually an abstract, formal representation of entity types that may include their properties, relationships and the operations that can be performed on them. The entity types in the model may be kinds of real-world objects, such as devices in a network, or occurrences, or they may themselves be abstract, such as for the entities used in a billing system. Typically, they are used to model a constrained domain that can be described by a closed set of entity types, properties, relationships and operations. An information model provides formalism to the description of a problem domain without constraining how that description is mapped to an actual implementation in software.
Tracy Rausch: Our information model is a patient-centric one, i.e. all of the data entities in our information model are based on their relationship to the patient regardless of where the data was originally obtained. We use internationally established open data standards to store and manipulate the data in our model. These standards are IEEE 11073 for medical device data, SNOMED for clinical terms, LOINC for lab data, ISO 18104 for nursing documentation and FHIR for resource management.
Bridget Moorman: I notice that you have several data standards and only one messaging standard in that list. I also notice that you are using FHIR, which is a draft standard for technical use (DSTU) and not an official standard. Why so many data standards and not messaging standards? Also, what is it about FHIR that you like?
Tracy Rausch: First, our information model is patient data-centric not message-centric. That drives us to use data and not messaging standards. We had a challenge in that not one data standard could cover all of the data items in our information model. Nurses are one of the main users of our product and yet many of the data standards listed did not support the data they generate when charting, hence our inclusion of the nursing informatics standard. We like FHIR and use it mainly for two reasons. First, it allows us to break down any messages into data objects using their ‘data-finder’ functionality. Second, it also defines a communication protocol between disparate systems. So we are essentially using the data handling aspect of FHIR and not the messaging aspect.
Bridget Moorman: Please expand a bit more on the information model, the data and what it means.
Tracy Rausch: We are gathering data into our information model that is patient-centric and time-based from many different medical device and health information systems. This data can be directly attributed to the patient or provide contextual awareness in real-time, near-real-time or retrospectively, providing a time-track of available data about and around the patient. Essentially, we aggregate data from different sources, place them in our information model and then present the different data items in a way that is usable or actionable to the user. The main limitation to our system being truly real-time is ‘infrastructure friction’ or transmission delay, however, as a demonstration of our granularity and time sensitivity, we can recreate an EKG waveform on our platform almost simultaneously to the time the data source displays it, which approximates real-time with the proper networking infrastructure. Additionally, we can provide ‘secondary or tertiary ’ data validation of information gleaned from data items and meta-data from disparate systems. We are combining primary, secondary and tertiary data source information to build a trustworthy knowledge-base for the end-user to access and build their own view of the data.
Bridget Moorman: When we last spoke a few years ago, you had some interesting ideas regarding interoperability and standards. I can see that you believe data standards are important, can you elaborate?
Tracy Rausch: With regard to standards and interoperability, as you can see, we’ve moved to focusing on data and not systems interoperability. Actually, we are interested in data portability. With regard to standards, in our work, we’ve noticed that over the years, vendors have built identical code sets for the same item for marketing differentiation. It has been a challenge to define and bring clarity to the nomenclature and we are working with the data standards organizations to try and resolve this. For example, we are using IEEE 11073 and their information model as published; however, the nomenclature used in physiology can have many terms which are used to describe the same thing. We have needed to map the nomenclature from vendor-to-vendor.
Bridget Moorman: You mentioned you are rolling out your product in India, Southwest Asia and Africa. You also mentioned that you are working on FDA approval of your device. What have been the barriers to your product development and FDA approval? For example, I’ve always heard a rule-of-thumb that it takes 7-10 years to manage the regulatory aspect of medical device development in the USA.
Tracy Rausch: Our product has evolved from just providing a medical device connectivity solution to being a data platform. We have not really considered the regulatory framework as our main barrier but the ability to build a platform for innovation using data as our biggest challenge because we have spent a considerable amount of effort building a system with the risk mitigation requirements at the core of the platform. We built our platform to allow aggregation of the patient data into useful different views based on the particular need at the time. With the infrastructure in place, we can more rapidly innovate on the clinical decision support (CDS) function of our product. With better data visualization and CDS solutions, we can go back to the bedside for feedback. We want to provide better data visualization and feedback to the different systems with a future aim to automation. A good example would be a ventilator loops and sepsis alarms; we could provide feedback to the devices possibly changing a setting to ensure better care. This would be done based on the clinician ‘prescription’ and direction for care.
Bridget Moorman: So, if I understand correctly, you take the data and meta-data and use them as building blocks, similar to Legos, to build another visual perspective of the patient, or in essence a “virtual medical device?” And what do you mean by risk mitigation?
Tracy Rausch: Yes, that’s what we are developing with our platform. We break up the device data and other information system data into pieces. The basic raw data becomes the building material for new devices. Our building tool allows us to determine multiple things with the same pieces of data. The meta- and clinical components or data items can be re-assembled virtually into another more complex device, or intelligence with another context. We are also able to provide other visualization products using a combination of the data from the disparate sources which becomes richer and more reliable due to validation from other sources. For example, we can provide a bed utilization report that is more accurate and discrete. This is usually done with ADT system data, but when augmented with additional data from the medical device, (is there a heart rate signal from that bed, i.e. is there actually a patient in the bed?), the bed utilization information becomes more accurate time-wise and can be acted on more quickly. The ADT system data input for a bed utilization report may lag actual bed ‘state’ due to workflow inefficiencies. Using the combination of data from different systems can highlight areas for resource efficiency or operational analytics.
As for risk mitigation, when you have a distributed system, managing the risk becomes intractable because it comes from everywhere. For example, what if the data from the EMR is stale, or what if the device communication is lost and the application needs that data? The concept of separating everything into “Lego” blocks simplifies this because I can manage the ins and outs of the blocks. So when an application using my platform/data bus combines the blocks, the risk has already been mitigated. The platform/application manages the input and output to the bus, not the risk that the EMR loses connection, the Lab system is offline, or a device fails. All the application knows is if there is data available. If so, then the data can be used. If not, then data can be obtained elsewhere. The example described above of using data from a patient monitor to determine bed availability would be an example of using another piece of data to mitigate that an ADT interface was unavailable.
Bridget Moorman: I see that you are branching out to CDS. How do you provide that practically? What do you consider some of the challenges?
Tracy Rausch: We are not a business rule based system, we are a platform which integrates data from medical device systems and other healthcare systems as described above. We are taking data items and re-assembling them into custom virtual devices which can be used for decision support. The decision support is practically provided by building the applications or devices on the platform for each type of desired CDS. This supports continuous data driven decisions from a clinical aspect. With our infrastructure in place, a customer or third party can more rapidly innovate for CDS. The main pitfall we’ve found is with the innovation cycle. To address this we’ve developed our platform using open data standards as described above and will be opening our platform up to third-party developers to build their own devices using our platform and data items. We can never predict what might be needed, so we want to provide the raw material and allow for creativity.
Other challenges we’ve found have centered on the data management. We are generating 2GB of data per patient per day, so storage and management of that data becomes important. Cyber-security is also important and we have protocols in place that protect the data, platform and all source systems from each other or third-party interaction. It is as important to protect a legacy medical device as well as the network and other systems sending/receiving data.
Bridget Moorman: What do you see as the future for device connectivity?
Tracy Rausch: The future of medical device connectivity will be between biomedical sensors, actuators and software. The aggregator and decision support analytics will end up being the ‘medical device’ that we think of now.
Bridget Moorman: Thank you, Tracy, and best of luck to you for your product roll-outs.
Tracy Rausch and the DocBox product will be at HIMSS 2017 in the Intel Booth #2661 as well as speaking at Clinical and Business Intelligence area (#6779) Tuesday Feb 21, 4:00 – 4:30pm.
Bridget Moorman will also be at HIMSS 2017. If you are interested in meeting with her, just email at [email protected].
Recent Comments