
CEO Robert Connely of Novo Innovations is both convinced and convincing: the approaches traditionally taken to connect physician systems with hospital systems are wrong. Novo’s grid technology, based on intelligent software agents, makes it fast and inexpensive to connect those systems in ways that portals and RHIOs can only dream of. Maybe you’re not a believer yet, but consider this: the company has an all-green KLAS score, including a 100% “Would Buy Again” customer score.
Tell me about Novo Innovations.
Novo was founded in late 2003. My founding partner, Alok Mather, and I came from a large healthcare IT company. We felt that there were emerging technologies that could address the problems related to moving and integrating information between hospitals and physician practices, primarily to physician office EMRs. We saw an opportunity to apply a new way of thinking to this problem, to focus on the workflow aspects of information exchange instead of the information aspects common with most conventional approaches.
Our first customer site went live in Atlanta in February 2004. We’ve been building on our solution ever since and the healthcare market has rapidly embraced our approach. Novo now serves hundreds of hospitals and physician practices, everything from small community hospitals to the largest health systems in the country. We are helping hospitals improve how they exchange information, and thus improving the quality of patient care, while saving physician practices hours of valuable staff time per day.
The Novo Grid helps hospitals exchange information with physician practices. Tell me how it works.
The Novo Grid is based on the idea of using distributed software agents to exchange information between people and applications across a community. Agents are small but powerful software programs that can be installed in hospital data centers, physician practices and other locations. Once installed, agents can interact with their local environment to extract and insert information and exchange the information with other agents to automate workflow tasks.

For example, an agent installed on a server in the hospital’s data center can listen for HL7 result messages from the hospital’s interface engine. It has the intelligence to examine each one and determine a course of action based on hospital and ordering physician’s preferences. It can transform the messages if required, then encrypt and distribute them to agents in the ordering physician’s practice over the grid.
To distribute the data, the grid provides a messaging “post office” that allows agents to send information from one to another, much like people use e-mail today. Messages are highly encrypted using a combination of symmetric, asymmetric, and SSL encryption. When a new organization joins the grid, a unique mailbox is created for the practice on the post office. Agents in the practice can then upload information to be put into the mailbox of receiving agents. Agents regularly connect to the post office to check for messages received in their mailbox to download.
Using this mechanism, the agent in the practice downloads the message from its mailbox, decrypts it, formats it if required, and automatically inserts it into the physician’s EMR interface. If an EMR were not present, the agent in the practice could also hold the results for printing or saving to a file.
In this example, agents are effectively doing the work of people who collect paper reports and results from fax machines to scan into their EMRs or file in paper charts. Agents have shown to save hours of staff labor per day.
Why is that better than a Web portal or a traditional RHIO architecture?
It really depends on what you’re trying to do. If you’re trying to build a system to provide a single view of information across multiple applications in an enterprise, accessible from anywhere, a portal is the ideal choice. If you’re trying to create an aggregated view of information about a patient collected across a community, the RHIO approaches may be the way to go. If however, your goal is to automate the exchange of information between a hospital and a remote physician EMR, neither portals nor RHIO architectures are good choices simply because it’s not what they were designed to do.
To solve that problem, you require some type of intelligence to interface to applications installed on private, inaccessible networks managed by different organizations, built using a variety of technologies and standards. You must be able to securely distribute information from one private network to another. Also, because you must install software in remote locations across the community, whatever you choose must be remotely managed and highly scalable. This is what the Novo Grid was designed to do.
It is important to point out that the Novo Grid is very compatible with portals and RHIOs. Portals can extend their reach by using a grid to collect data from external sources or by using agents to automate the collection of particular types of information.
RHIOs also require a basic plumbing infrastructure. Today, RHIO infrastructures are focused on providing information management functions to identify, locate, and aggregate information from many applications and sources across the community. A grid approach offers an alternative to the RHIO that is not based on building an information management infrastructure from the onset, but rather to incrementally expanding the grid to constituents based on the value proposition of automating and improving common workflow tasks. This type of automation may drive the sustainable business value that RHIOs are looking for.
Interestingly, once organizations are on a grid, achieving the original goals of aggregating and accessing information can be done as by-products of the workflow exchanges, practically for free. This is a radical shift in thinking, but it addresses many of the primary problems RHIO wrestle with today. Ultimately, I think ours, or a technology like ours, will provide a key component of the RHIO platform of the future.
Who is the target audience?
We sell the Novo Grid primarily to hospitals. Hospitals provide our solution to their affiliated practices. Most see Novo as a means of providing a higher level of service and a competitive advantage over other competing service providers, such as the national reference labs. Within the hospital, it’s the CIO who generally drives the relationship with Novo, although we are seeing more interest from CEOs who are looking to improve the relationship with their physicians.
Physicians are growing as an audience as they look to improve the way they exchange information with others in their communities. We have seen many cases where physicians will be the introduction into hospitals simply to solve their problems. Some of our greatest evangelists are the physicians that use our system.
What feedback are you getting from customers?
The overall response from our hospital customers has been very positive. To them, we effectively offload a problem from the CIO and their staff - namely, integrating the EMRs of their most visible and often most vocal physicians. As we came to realize this, we evolved Novo from being primarily a technology company to a service company specializing in integrating EMRs, practices and hospital systems using our technology.
Our physician customers give us excellent feedback not only in appraising the current state of the system, but also in recommending future enhancements. We actually focus on the needs of the physician’s staff, and not necessarily on the physicians themselves. Because of this focus and feedback, we often see an immediate reduction in labor and a positive, bottom line impact to each practice that connects to their hospital’s grid.
Of course we also hear that we could do things better, like documentation. That specific request has led to enhancements that embedded context-driven documentation into the agents themselves instead of producing unwieldy product manuals.
What has been the response from EMR vendors?
For the most part, the response has been very positive. If a hospital uses the Novo Grid, the EMR vendors don’t have to spend time working with the various departmental systems of the hospital to integrate their EMR. Instead, Novo engineers work with the EMR vendor’s interface team to make sure the vendor receives the information, often HL7 messages, in the format the vendor expects, not what the hospital originates. We have heard from some EMR vendors that we represent a significant reduction in the amount of time and effort they expend to interface to a hospital. Because of this, some EMR vendors have embraced the Novo model, reduced their hospital interface costs and recommend it to their customers as a means of integrating their EMRs to the local hospitals.
Some vendors are moving towards an exchange hub model that they see as the means of interfacing hospital data to their EMRs in that particular community. I imagine that some of these vendors would see Novo as competitive, but I know of few hospitals that hold this view. This is due to the fact that vendor-based hubs only address the needs of physicians that use that particular product. To a hospital, this means a strategy of interfacing and supporting a variety of hubs in their local area, which is really no different than directly interfacing to an EMR to the hospital. To the hospital, Novo handles this challenge, regardless if the vendor uses a hub, or direct HL7 interfaces to the EMR itself.
What are the future plans for the product?
From a technology perspective, we have continued to evolve the capabilities of our agents to automate basic healthcare workflows, including the delivery of results, reports, and admission face sheet data to practices.
We have recently gone live with an agent that can collect orders from doctor’s EMRs. It also creates a new type of outreach solution for practices without an EMR. Using an agent for this purpose offers exciting possibilities. For example, an agent can utilize the hospital’s entire lab catalog to assist practices in placing orders, as opposed to a form-based approach. Agents can learn practice patterns over time including favorite tests, diagnoses, and other elements to make the ordering process more efficient over time. This helps to ensure adoption by the practices.
Agents are also being used to refer patients between providers in a community, which will also work in environments with and without EMRs. An agent can collect the referral information from an EMR or from documents generated by a paper-based practice and then send it to an agent in the referred practice. The agents assist with the registration and scheduling of the patient, and then collaborate by returning the consult letter to the referring physician.
Perhaps most exciting plan is to use the Novo Grid to create a new type of personal health record. Instead of a PHR being a collection of information about a person, a grid establishes a dynamic, private community around a person and their care team. This model views the PHR is a team of agents collaborating across the patient community, automatically updating the PHR when events occur in the community such as the availability of a new test result, the prescribing of a new medication, or the referral of the patient to a new provider. This type of PHR, which we call a Personal Health Journal, serves as an active PHR, keeping critical information about a particular person in sync across the variety of systems that the data resides in.
We will continue to work with our customers to extend the use of our technology and services to continue to pioneer exciting new uses of our unique technology.
Fast Facts
Product
Novo Agent Grid
Company
Novo Innovations
3600 Mansell Road Suite 225
Alpharetta, GA 30022
888.325.NOVO
www.novoinnovations.com
Notable Customers
Adventist Health System, Catholic Health System, Northside Hospital, Spectrum Health, CHRISTUS Health, UPMC
The Bottom Line
- 100% of customers “would buy again.” What’s left to know?
- Novo’s solution for connecting hospitals to physicians is affordable, innovative, and fast to implement.
- For hospitals, get that strategic physician connectivity project done fast without diverting IT resources.
Article Reprint
Download a reprint of this article.
No comments yet.