HIMSS 2015: Why Data-Sharing Among Medical Devices is Crucial

Do medical devices inadvertently cause deadly errors in hospitals? In a recent Gary and Mary West Health Institute study, half of the nurses surveyed said they had witnessed at least one on-the-job error due to medical devices not automatically sharing data with one another.

In a separate Spyglass Consulting Group study, researchers cited communication breakdowns as the root cause of 70 percent of treatment delays and sentinel events–defined as unexpected occurrences resulting in serious injury or death.

It’s estimated that as many as 440,000 people die in hospitals each year from preventable causes. Expanded data-sharing and products that improve staff communication will absolutely help improve that statistic.

There’s still work to be done to achieve that goal.

Hospitals that want to free their staff to spend more time with patients need to give them better tools to communicate while on the go. That means giving nurses and doctors mobile devices that contain live, actionable contextual data.

Consider a glucose meter that shares live readings with an insulin pump, which automatically adjusts its dosages accordingly. That data gets automatically saved on the patient’s Electronic Health Record, which medical personnel can review on their mobile device.

Many medical devices still live in technology silos, forcing nurses and doctors to transfer data manually or interpret readings themselves, adding time, complexity, and the possibility of error to the health equation.

The solution is more openness between devices, and a common development platform (such as Engagement Development Platform) to federate data-sharing between those devices.

In a similar vein, hospitals need to adopt a strategy to handle mobile devices across different workflow processes. Currently, hospital workers can carry badges, wireless phones, hospital-owned smartphones, personal smartphones–and yes, even pagers.

If one nurse wants to call another nurse, which device do they use? Does your hospital have a clear communication workflow?

Here at Avaya, we encourage the hospitals we work with to consolidate their communication devices and streamline their communication workflows, to better combat the ineffectiveness and confusion surrounding multiple devices.

Don’t forget about secure texting solutions: With certain procedures, medical personnel need to focus on the task at hand, making secure texting a necessity.

Consider nurse call integrations, allowing the patient to press the bedside call button and get connected immediately with a nurse carrying a mobile device. Other functions, such as the patient discharge process, can be sped up with EHR integration into the mobile device.

Precious minutes are wasted each day by doctors and nurses who walk around their floor, looking for someone specific who isn’t answering their phone. Connected mobile devices can make that a thing of the past, by automatically locating specific clinical resources.

Mobile care team coordination can unleash the power of engagement for hospital staff across the continuum of care, and create a mobile engagement environment that can help reduce communication breakdowns.

Join Avaya next week in Chicago (April 12-16) at HIMSS, the country’s largest healthcare IT show. At booth #3695, we’ll be demonstrating our line of healthcare solutions, including an on-call physician locator application, built using the Engagement Development Platform.

For more information about Avaya Healthcare Solutions, visit avaya.com/healthcare.

Related Articles:

A Developer’s Intro to Avaya Engagement Call Control (ECC)

I need to start by telling you that I am a Java programmer. Having experienced quite a few computer languages over the years, I started writing in Java fairly exclusively in the late 1990s. I love the elegance, power and flexibility of Java. It ran circles around other object oriented languages such as C++ and made my life as a software designer much easier.

However, I recognize that Java isn’t for everyone or for every circumstance. While it’s not necessarily a difficult language to learn, it requires a particular way of thinking. You can’t write Java code the way you may have written software in other languages – object-oriented or not – and I understand why some people get frustrated with Java and turn to other languages for their development projects.

Even more importantly, I realize that in certain areas, pure Java can feel like a square peg in a round hole. To avoid developer/application mismatch, it’s important to keep an open mind and be willing to adapt to the situation at hand.

The new Avaya Engagement Call Control (ECC) Snap-in is the perfect example of something different being the right choice. Built on top of the Avaya Engagement Development Platform (EDP), ECC exposes a wide array of RESTful Web services that allows developers to quickly and easily add a myriad of call control features into their applications.

While much of the ECC functionality is supported natively by EDP, EDP interfaces require Java and, by their very nature, are a bit more difficult to use than Web services.

On the other hand, ECC features can be used by any language or scripting tool that supports Web services. This includes Python, Ruby, Node.js, .NET, PHP and, yes, even Java. So, while hardcore programmers might prefer a more traditional language, powerful ECC applications can be quickly built with easy-to-use and highly portable Ruby. In fact, there may be times when an application is prototyped with Python and productized with .NET. Developers have choices and are not locked into a single platform or a specific way of programming.

Read additional articles from Andrew Prokop at SIP Adventures.

A powerful difference between ECC Web services and EDP Java interfaces is the ability for ECC to monitor and control calls of all types. While EDP applications are limited to calls to and from trunks, ECC can act upon trunk calls as well as station-to-station calls. That alone makes ECC worth the price of admission.

This difference comes from the fact that the ECC Snap-in uses the Avaya Application Enablement Server (AES) to provide telephony features, while EDP Java applications run as sequenced applications on Session Manager. By using AES, ECC Web services extend AES’s close relationship with Communication Manager (CM). In other words, any call that CM can see, ECC can also see.

The following list is a more comprehensive look at the differences between the ECC and Java APIs:


A Look at the ECC Interfaces

ECC Web services support the following call control interfaces:

  • Make Call
  • Get Call
  • Drop Call
  • Drop Connection
  • Answer Call
  • Hold Call
  • Retrieve Call
  • Get Call Forward
  • Set Call Forward
  • Cancel Call Forward
  • Get Connections By Address
  • Get Call Connections
  • Get Connections Details
  • Redirect Call
  • Single Step Transfer
  • Consult Initiate
  • Complete Transfer
  • Complete Conference

As a software developer, I can immediately envision a myriad of applications made possible by these 18 function calls. For instance, it would be painless to add click-to-call capability to a corporate Web page or an employee services portal. The same holds true for CRM or workflow management packages. Although Avaya Communicator makes it unnecessary, it wouldn’t be that difficult to write your own soft client. The possibilities are endless.

In addition to operations that create and manage voice calls, ECC supports a number of Web services that act upon Avaya Aura Messaging. These are:

  • Get Messagebox by ID
  • Get Message by ID
  • Get All Messages
  • Get Message Flags
  • Set Message Flags:
  • Get Message Parts
  • Get Message Part by ID
  • Get Message Part Content
  • Purge All Messages in Trash

Again, there are quite a few applications that could be built from these interfaces with Visual Voice Mail being the most obvious. It would be very simple to create a Web page that displayed and played a user’s voice mails. I don’t know about you, but I am all for anything that keeps me from entering DTMF commands from my telephone. I have been a Modular Messaging user for years and still refer to the cheat sheet of commands pinned on my bulletin board.

Digging Deeper

As a developer, I want more than function names. Thankfully, Avaya has done a great job of documenting every Web service and its associated data structures. Before I did anything with ECC, I downloaded the documentation and poked around the function calls.

For instance, the Make Call operation consists of an invocation and subsequent response. The Make Call invocation looks like this:


“id” :”#MakeCall”,
“type” : “object”,
“properties” : {
“from” : { “type” : “string”},
“to” : { “type” : “string”}
},”additionalProperties”: false

And a successful response (200 OK) looks like this:


“id” : “#Call”,
“type” : “object”,
“properties” : {
“callID” : { “type” : “string”},
“statusUrl” : { “type” : “string”}
},”additionalProperties”: false

In English, Make Call requires To and From destinations. For example, the To could be my telephone number (“+19524563516”) and the From might be my coworker, Debbie (“+19524563888”). Note that To and From are expressed as E.164 numbers.

A successful response contains a  callID that uniquely identifies the call. This  callID will be used in subsequent commands to manage the newly created call.

The remaining function calls follow a similar model of command and response.

ECC Events

Of course, it’s not enough to simply tell ECC to do something. You need to know when something has occurred. For that, ECC delivers the following events:

  • HELD

Applications will register an event handler that will subsequently be invoked for all new events. For example, an ECC application is made aware of a ringing call with an ALERTING event:

event {

callEvent: ALERTING


originalCallingParticipant: A

originalCalledParticipant: B

alertingParticipants: B

participants:A, B

callID: <call_id>

callHref: https://<CLUSTER-IP>/services/EngagementCallControl/calls/callID

address: A


An application could act upon that event by issuing an Answer Call command.

After the call has been answered, an ACTIVE event would be delivered to the application’s event handler.

event {

callEvent: ACTIVE

originalCallingParticipant: A

originalCalledParticipant: B

participants:A, B


callID: <call_id>

callHref: https://<CLUSTER-IP>/services/EngagementCallControl/calls/callID

connectionId: <connection_id>

connectionHref: https://<CLUSTER-IP>/services/EngagementCallControl/connections/connectionId

address: A

operations: [

endCallHref: https://<CLUSTER-IP>/services/EngagementCallControl/calls/callID holdCallHref:


consultCallHref: https://<CLUSTER-IP>/services/EngagementCallControl/connections/connectionId?action=consult]


Make note of connectionId. Like callID, this reference is used in commands that act upon calls and their various connections. For example, an application can use connectionId to drop a single participant from a conference call while not releasing the call itself.

Mischief Managed

My goal for this blog article was to provide an introduction to ECC, and I hope I accomplished that. In future articles, I may dig in a bit deeper to the commands, events and call models that ECC supports.

In the meantime, I highly recommend that you go to the Avaya DevConnect page, download the SDK and supporting documentation, take a look at the sample applications, and have a go at it. I think you’ll find it as easy to understand as I did!

Andrew Prokop is the Director of Vertical Industries at Arrow Systems Integration. Andrew is an active blogger and his widely-read blog, SIP Adventures, discusses every imaginable topic in the world of unified communications. Follow Andrew on Twitter at @ajprokop, and read his blog, SIP Adventures.