Recapping NEC-Sponsored Meet Up: ‘Leveraging Technology and Innovation for Proactive Healthcare’

In September, NEC Corporation of America (NEC) sponsored a meet up, “Leveraging Technology and Innovation for Proactive Healthcare,” at the Plug and Play Tech Center in Sunnyvale, CA. The panel was moderated by Charlene Yu Vaughn, CEO, The Algonquin Group, and consisted of Dr. Andrew Auerbach, MD, MPH, director of innovation at the Center for Digital Health Innovation, and Professor of Medicine in Residence at UCSF; Drew Schiller, CTO and founder of Validic; Jason Roos, CTO, Stanford Medical Center; Matt Sarrel, MPH, technology analyst, epidemiologist, and founder of Sarrel Group; and Calvin Togashi, SVP/partner, Assigncorp/HealthQEC, formerly with Kaiser Permanente. More than 100 people attended the event.

The panel convened to discuss healthcare innovations and trends in healthcare-related product and service development. Panelists began with a discussion of the types of problems found in healthcare that can be solved by technology. Mr. Roos spoke about being “on the cutting edge, not the bleeding edge” and how the innovation center needs to evaluate technology solutions and how they work at scale, and whether the manufacturer/solution provider will support the solution for a long time. Dr. Auerbach spoke about governance and problem solving using technology. UCSF is particularly interested in technology that automates processes and saves the time of the physicians, administrators, and nurses. Mr. Togashi talked about the challenges faced when trying to introduce new technologies into a healthcare enterprise and how Kaiser placed an emphasis on always trying to improve patient care. Mr. Schiller talked about the need for entrepreneurs to constantly be working to solve problems with innovative solutions and the need for an agile development process that can constantly evolve.

The conversation then turned to streamlining provider-patient communication. Mr. Togashi talked about the projects he worked on at Kaiser where they targeted specific high-risk populations and found that good, timely communication could positively impact treatment outcomes. Dr. Auerbach discussed the need to communicate with patients across different communications methods, such as telephone, email, mail, and Facebook. Patients need access to their care team in flexible ways. At this point, Mr. Sarrel commented that it might be appropriate to compare patient-provider communications to retail communications in that they are omni-channel and systems should be designed to facilitate communication the way that the patient (or customer) wants it. The ultimate goal is to improve treatment outcomes so organizations should do whatever it takes to get helpful communication flowing back and forth between providers and patients.

Any discussion of provider-patient communication must involve discussing the role of care plans in patient care. The panel discussed different ways to use technology to communicate care plans to patients and their families who may be involved in care. This creates a need to communicate across different vectors and is typically asynchronous. Particular care needs to be paid to ensuring that care continues after the patient is discharged. Do patients know what to do once they leave the hospital? Where can they turn for additional information? Providers need to communicate effectively and efficiently.

The conversation continued and the panelists discussed the role of wearables in patient health. With more and more sensors on fitness bands and smart watches, there’s a growing need to gather and analyze data from wearables. The panel agreed that there’s a huge potential in wearables because they give the provider a chance to see a complete picture of the health of the patient. Most of the face to face time between providers and patients is spent communicating so if wearables can gather diagnostic information in advance of the visit then this can streamline and improve patient-provider communications.

The panel then took questions from the audience. Questions ranged from how IT can help providers and patients communicate better to what kinds of products we might see coming on the market in the near future. One question that was interesting was how technology could improve access to healthcare in underserved populations. The panel responded with mentions of telemedicine, patient portals, and communication via SMS. It’s important to bring patients and their families into the discussion with providers.

Overall, it was an informative panel with a free-ranging and comfortable discussion. The panelists concluded by thanking NEC, the sponsor of the discussion. NEC’s IERS database is a high performance, elastically scalable key value store with a SQL interpreter and Hadoop connectors. IERS is currently being used to improve patient-provider communication as the foundation of the Prompt Outreach patient messaging system.

Matt Sarrel *Matt Sarrel is a leading tech analyst and writer providing guest content for NEC.

IERS is Built for Elasticity

If you stop to think about it, the relational database (RDBMS) is a pretty remarkable piece of technology. Can you name another product category that has remained essentially unchanged since it was first introduced roughly 40 years ago?

However, in 2014 the RDBMS is no longer the “be all and end all” of database technology. An RDBMS can’t meet the demands placed on it by big data and cloud computing. Data entry has changed dramatically also. Instead of a requirement to scale with the number of data processing employees, there is now a requirement to scale with the number of customers, or to give a more dramatic example, to scale with the number of devices or sensors in a machine-to-machine (M2M) or Internet of Things (IoT) scenario. Many enterprises have outgrown their RDBMS, as have most telecommunications providers.

All up and down the application stack we can see the ability to scale out and in quite easily. By definition, big data requires an elastic database that can scale across multiple storage and compute nodes. Other technology that was created to be elastic, such as NoSQL and NewSQL, are more appropriate for big data environments.

How to Know if You Need Elasticity

Not every project requires an elastic database. When one does, things go much more smoothly if you can figure that out in advance and plan accordingly. It’s much easier if you make the effort to plan for an elastic architecture from the beginning. Look at your planned load and your projected growth and ask yourself whether it will exceed the capacity of your current hardware/software architecture. Will your database requirements fluctuate in demand? Will there be daily, weekly, monthly, and/or seasonal changes in the number of servers required? For example, if you have an analytics application that requires eight database nodes 24×7, yet peaks at 14 nodes for four hours every night, then elasticity is important.

NoSQL, NewSQL, and Elasticity

When NoSQL systems were initially being designed, emphasis was placed on scalability. In many cases, this meant eliminating many of the features that had been added to RDBMSs over time: powerful query languages, database consistency guarantees, durability, atomic operations – and just about everything else. At this point we had lots of elastically scalable databases that offered little else, whereby making them unusable except for very specific use cases.

NewSQL goes beyond NoSQL and stipulates that elasticity isn’t the only thing that matters and is instead a baseline requirement. Many of the things that we gave up (such as SQL) in our quest for elasticity are important. NoSQL required many of these things to be built into applications (increasing complexity and cost) and now we want them back in the database layer where they belong.

IERS is Built for Elasticity

In addition to having elasticity in its name, NEC’s InfoFrame Elastic Relational Store (IERS) was designed from the very beginning to provide a high-performance elastically scalable database with full ACID capabilities. IERS’ scale-out architecture expands your system without downtime as demand and data volume increases. This allows you to start small, save on unnecessary resource investments and then scale out easily based on demand. Minimal to no application modification is required to scale out or in.

IERS can scale out easily and quickly. System resource can be added while the system is live and in production, enabling the system to be reconfigured on-the-fly without downtime. Also, as the system scales out, automatic rebalancing of the data takes place. This process does not impact user operations. IERS sports an easy to use web based GUI that allows administrators to scale-in/scale-out with a few clicks from anywhere in the globe. Process once initiated requires no further human intervention.

To learn more about NEC’s IERS solution visit:

Matt Sarrel *Matt Sarrel is a leading tech analyst and writer providing guest content for NEC.