Remember the “Pass the secret” game we all played as kids? What went in on one side was never what came out the other because each person acted as a filter, misconstruing and warping the original message. You would be lucky if the intent made it all the way through the barrage of improper memory-mapping and malicious intent. We face the same dilemma today in Healthcare I.T., with interoperability and interfaces to and from the Electronic Medical Record (EMR) systems, communication vendors, and various other middle-ware solutions. It amazes me sometimes that it works at all. Mapping back and forth between discrete and non-discrete entry fields, through automated systems, and sometimes by temp analysts, is a recipe for disaster.

All too often, vendors produce mass-marketed solutions that don’t interact friendly with third-party systems. Because of this, inaccurate interfaces are erroneously created by third parties or inside of the hospital by their own IT staff to link these sub-systems together. These interfaces remain the weakest link in a hospital’s IT infrastructure which can lead to patient safety issues by reporting on inaccurate or incomplete patient information.

EMRs see their system as a central repository for all hospital data, and I tend to agree. We already see this complexity just getting data back into the system with back-end lab systems and flubbed interfaces, and the same complexity is seen with data coming out. How does a third-party system display that clinical data in an efficient and effective way? That burden must be on the EMR vendor to provide a more efficient way to display patient data and they must become more draconian about how their data is presented. As third-party vendors, we must start thinking of ourselves as a supplementary applications and a passive consumer of that data.

The same rules apply when duplicating data across systems. Every additional duplication is another failure point in the system. Hospital roles and assignment are a primary example of this problem. Many of our competitors duplicate roles and assignment, already found in the EMR system, into their own database repository. This is an inefficient and error-prone way of pulling information across hospital systems.

In summary, as a hospital IT developer, we need to find a better, more efficient way to reach across boundaries and communicate with a hospital’s EMR vendor. Data should become centralized with as little redundancy as necessary and we should rely on the EMR systems to display patient data, it shouldn’t be cannibalized by other systems.

Welcome to my first blog article, which happens to be written on my new iPhone 4S without a keyboard thanks to the help of Siri and speech to text. No desktop or laptop computer was used in the creation of this article and no apps were harmed in the process. Now for my top five favorite new features:

1. Siri is your new personal digital assistant. Siri is so much more than a speech to text recognition engine. It is the next generation. It is the next dimension. I remember when I got my first smartphone, the Palm Treo, and how complex it was to create something as simple as a new calendar event. I literally wished I could just talk to my phone and tell it to create a new event for tomorrow at 5 PM. Now, Siri does just that.

2. Reminders.app never forget anything again. This is one of my favorite new apps! I once carried a folded sheet of paper and post-it notes in my pocket with all my reminders. Now this app takes it to the next level and will remind me of my task at a certain time or location. The reminders based on location are amazing. For example, I can ask Siri to remind me to take my lunch when I leave the house or when I get to work to call Bob. This is what makes Siri seem so lifelike.

3. iMessage, therefore I am. Apple is now getting into the text messaging game and making it ridiculously easy to use. No configuration required and it works on the iPod touch and iPad. iMessage supports delivery receipts and read receipts, if they are enabled, but the killer feature is group messaging. Also Siri will be happy to read your new text messages aloud and create new ones hands-free (you know where I'm going with this one).

4. Camera and photos. This is the beginning of the end for the point-and-shoot digital camera. The iPhone 4S rivals most digital cameras with its eight megapixels and take 1080p HD video. It will edit your photos and videos, as well as GPS tag and upload them to your favorite social network! What digital camera lets you do all that? RIP digital point-and-shoot you served us well.

5. Speed demon. Every new iPhone gets faster and faster and the iPhone 4S is no exception. It has the new dual core A5 processor, which Apple claims is "up to two times more power and up to seven times faster graphics". I definitely agree, all my apps load faster and feel much more responsive.

My Conclusion: I love my iPhone 4S. When I hear people complaining that the 4S isn't that much different from the iPhone 4, ask them if they can "write" an entire blog article on their phone without using a keyboard? 

It’s no secret that Microsoft has launched a campaign to eliminate IE6. They have been encouraging people and organizations – for quite some time now - to upgrade to an IE7 or newer version. In fact, Microsoft has created a website (www.theie6countdown.com) specifically for convincing people to upgrade to at least IE8, and preferably IE9.

The reasons for upgrading are plentiful. The biggest reasons are centered on security and features. However, it seems as though hospitals in particular are slow to upgrade. I’ll touch on the two most common reasons today.

The most common concern has to do with legacy applications and sites. IT departments are concerned that IE8 won’t work with these applications and may cause an entire chain of “have to upgrade” events. You know…the chain of “I have to upgrade this, that, and the other to support this new software.” We’ve all been there.

However, newer versions of IE include a ‘compatibility mode’ that actually seem to work pretty well. A large number of the sites that many people don’t think will work with IE8 actually work fine, even without the compatibility mode.

The second issue concerns resources, manpower, or staff. Most hospitals have a limited budget for the IT department. Often, projects like “upgrade IE hospital-wide” seems to incur a cost with little perceived reward. Additionally, other projects tend to have a higher priority simply because the rewards are immediately noticeable.

The problem with this is…IE6 is a pretty large limitation. Both for the hospital environment, as well as those companies who provide applications and solutions used by those hospitals.

IE8 supports many new features, such as improved JavaScript engines, better CSS support, HTML5 support, and various other improvements. While it is true that many of these improvements won’t be immediately obvious, or taken advantage of, upgrading your web browser is the first step at enabling your content providers to offer you better solutions. Providers will be able to offer efficient, fuller, faster, stable, and more attractive interfaces.

IE8 can be deployed via group policy, or any of several software management utilities. Many hospitals decide to do a unit-by-unit, or department-by-department rollout. You can first start by testing all of the software that accounting uses, and then rollout to that department. You can test all of the software that ICU uses, and then rollout to that unit. You get the idea. The mass deployment of an updated web browser becomes a series of smaller tasks and projects, and often can gain traction easier within your facility when broken up in this manner.

How much of a life span does your IE6 have left?

Time-division multiplexing (TDM) has been around a long time and is considered to be a legacy protocol. Most public branch exchanges (PBX) will support TDM trunks provisioned as either channel associated signaling (CAS) or common channel signaling (CCS). CCS is often referred to as ISDN PRI. ISDN PRI is normally how most TDM PBX's are now provisioned, as there is a significant amount of intelligence that can be carried across these trunks as compared to a CAS trunk.

Here are my two cents as to why SIP is better than TDM.

Easier Integration: By using a SIP PBX it is so much easier integrating other applications with the PBX. There are a multitude of applications that support SIP, which will easily integrate and interoperate with a SIP PBX.

 

Utilizing a SIP IP PBX also allows you to integrate with other SIP applications such as Voice Mail running on a SIP Voice Mail Server.

 

More Security: SIP can be so much more secure than TDM. Users and trunks can be provisioned with authentication so no one can just plug into the SIP PBX and start making calls. Users and trunks must be provisioned and can include passwords along with user names to authenticate against. TDM must also be provisioned, but is generally not password protected. If you want to get really secure you can even send your signaling and audio path encrypted by using TLS and SRTP. This does require more processing overhead and is typically done in government installations.

 

No Limitations: TDM has hardware limitations limiting you to the amount of simultaneous calls you can make. Here, in the USA, most PBX's support T1 cards which limit the PBX to 23 calls per T1 card. If you need more simultaneous calls you will need to purchase additional cards.

 

With SIP you do not have these hardware limitations. You do not need T1 cards to handle your calls. You are basically limited only by your system configuration such as your CPU speed and memory amount. Your limitations only start after your processor has exceeded what it can handle in call volume, which can be in the hundreds and thousands of calls.

 

You are also less likely to have call issues due to hardware failure since there are no T1 cards required for SIP.

 

More Flexibility: SIP is an industry standard, which most vendors will deploy with. Staying with TDM often requires you to purchase only from your vendor thus limiting you to your vendors pricing. With SIP you can purchase from any vendor, which also supports SIP.

 

I could go on and on but for the sake of brevity let me conclude by saying, "I think SIP ROCKS!"

What are your reasons to using SIP over TDM?

If you write it, will they read it?  If you sell it, will they buy it?  If you _____it, will they _____it?   Fill in your own blanks.   Subconsciously, these  "if" questions are the ones that are asked by anyone initializing any new undertaking or maybe just satisfying a curiosity.

Many people have asked me how Voalte got started.   Hmm… Are they contemplating a similar undertaking or are they just curious?  Who and why is someone asking me this question?  Well, for starters, I attend many technology-related events such as local developer meet-ups, barcamps (those not related to alcohol serving establishments) and conferences and at every possible opportunity I proudly and passionately speak about my company and what we are doing.  I am so passionate and enthusiastic, I always get asked the question, "how did Voalte get started?"  Technologically speaking, I can relate to my audience very well.  Techies tend to think alike and resonate very well when speaking technology, but when it comes to the flip side -  the business or entrepreneurial side - then the resonance levels dip drastically.  Why?  

It seems like most of the techies I meet all seem to have some great new idea for an application or service that they think might rock the world like a Google or Facebook.  Ok, Ok.  I have this idea now tell me again how Voalte went from idea to version 1.0?  If I develop this, will they… you know the rest.

Once upon a time in June 2008, I was attending Apple's Worldwide Developer Conference in San Francisco.  This was just after Apple had released the iPhone software developer’s kit (SDK) to allow native applications on the iPhone.  Everyone and their mother was at the conference trying to learn how to create the next BIG app for the iPhone.  By the way, it was the first time Apple's developer conference had ever sold out!  It was a techie gold rush.

One night while socializing with other iPhone developers, we literally bumped into a young entrepreneur named Trey Lauderdale (who unfortunately was not able to buy a conference ticket in time).  He very generously offered to buy us a drink in exchange for our time to listen to his idea,  I recall it being such a simple idea, the kind that makes you ask yourself, "why didn't I think of that?"  His idea -- sending critical hospital alarms, such as nurse call, code blue or patient monitoring alarms to the iPhone.  Right off the bat I got it.  The iPhone would be the perfect mobile platform for use in the healthcare industry.

After the conference ended, Trey and I kept in touch.  It helped that he was living in Miami and I was living in Fort Lauderdale at the time.  A month had passed and Trey asked me to create a "real" simple demo application that he could present to some hospital CIOs.  I spent about two weekends creating the most basic iPhone app that when launched would pop-up a nurse call and a code blue alarm.  With that demo in hand, Trey approached several CIOs and was told right then and there, "if you build it, we will buy it."  From that first simple little app and positive reassurance from potential future customers, we had our green light.  It was all systems go.  The rest is history.  

I'd like to pass on some advice to new and upcoming entrepreneurs who think they have the next great idea.  First and foremost - keep your idea simple - simple to comprehend, that is.  Do not lose yourself or your audience in the stratosphere with an idea that is not understood or too complicated. Remember to resonate.  Because once you get going, your idea will take on a life of its own and, believe me, it will get more intense and complicated.  More so than you can ever imagine.  Second, sell your idea before you build it.  I know this is the hardest part of the equation for an engineer to understand - trust me - if you don't sell your potential customers now then they will not buy it when it is built.  Thirdly, do not try to do this all by yourself.  Impossible.  Get some partners in crime that compliment your skills and have the same energy and passion that you do.  Lastly, as Rob Campbell, our fearless CEO, constantly reminds us; this is not a sprint but a marathon.  We are doing so much more than just building an app.  We are saving lives, improving healthcare communication, building a culture and helping to change the world. 

For most people, the idea of software development is somewhat of a black art.  So consider this: if you’ve ever experienced homeownership, you already have a sense of what it is like to manage software development. 

For starters, you’re familiar with a fixed deadline:

“You really need to get the plumbing sorted out by Sunday night.”

You know about changing requirements:

“I didn’t know it was the wrong color until you finished painting the house”. 

And you know that mistakes are expensive:

Cutting the new bathroom door too small = buying another bathroom door.

Given these challenges are taxing enough in the domestic realm, how does a company like Voalté manage these same challenges in the complex world of software development? And how do our developers keep it all straight when they are delivering code for three endpoints (iPhone, Blackberry, web client), and two servers (voice & data) in a mission critical environment such as a hospital?

The answer is through a process called Scrum. The idea behind Scrum is fairly simple: develop software incrementally in iterations that last two to four weeks.  These iterations, referred to as Sprints, allow the Team to add new features on a frequent basis, with each iteration resulting in a shippable release. Perhaps the greatest advantage of Scrum is to the business itself, through the ability to quickly adapt to changing requirements and customer preferences.

Compare Scrum to the traditional model of software development (Waterfall):

1. Spend six months conducting market research

2. Spend another three months writing the product specifications

3. Hand requirements over to the Engineering Team (with great ceremony)

4. Engineering Team develops the product for a year.

5. Software is passed to the Quality Assurance Team (more ceremony)

6. Then the long slog as the product is debugged, often with limited success.

7. Finally the product is launched (greater ceremony).

Here’s where the real heartbreak is.  By this time the product is launched, the customer’s needs have either changed, or the customer now realizes that with the product in hand, they really wanted something else in the first place (see “wrong color” above).  Compare this to Scrum -- a working product, although not fully featured, is released to the customer far sooner, when changes can be made more easily and less expensively (bathroom door).

There are three main roles in Scrum.  The most central role is held by the development Team (typically seven members).  The Team is self-organizing, meaning that Team members decide how the problem is to be solved, and who is to complete what tasks.  Scrum is a “pull” based process, meaning the Team commits to only as much work as it believes it can complete during the Sprint.

The Team pulls work from a list called the Backlog.  The Backlog is composed of several user stories, which are effectively new features to be added to the product.  An example user story follows:

As a clinician, I want an easy way to send my most commonly used text messages, so that I do not have to retype the same message over and over again.

The backlog is created by the Product Owner, who is responsible for the commercial success of the product.  The Product Owner writes the user stories and prioritizes them by business value.  The Product Owner also has the responsibility of reviewing and accepting work completed by the Team.

The final role in Scrum is the Scrummaster.  The Scrummaster facilitates communication between Scrum participants, removes impediments, shields the Team from interruptions, and ensures the Team is on track to complete the work it has committed to. 

One of the most powerful elements of Scrum is the process of continuous improvement.  At the end of each Sprint, the Team reviews what went well and what didn’t, and then uses this feedback to improve the next Sprint.  This feedback loop is just one of the reasons highly effective Scrum teams see productivity levels at 5 to 10 times the industry average*.

Scrum, born from the shortcomings of the traditional Waterfall process, traces its roots a variety of influences, including lean manufacturing techniques, process engineering, and behavioral science.  Designed to be lightweight, easy and fun, Scrum is realistic enough to be adopted by even the most skeptical engineering team.

Now if I can just convince myself my next home improvement project will be lightweight, easy and fun…

* http://jeffsutherland.com/scrumpapers.pdf

Last week I attended the second annual Erlang Factory 2010 conference in San Francisco.  Erlang, is a programming language and runtime environment (which means it has it's own virtual machine, unlike most languages).  For example you would develop your application using the Erlang programming language and then run it in an Erlang virtual machine on top of your operating system.  This added level of abstraction allows your Erlang application to run on any system that can support the Erlang virtual machine.  During that conference I delivered a 10-minute presentation on Erlang in Healthcare, how the Voalté server is powered by this new technology and what it can offer other developers in the healthcare community.

Who is using Erlang in Healthcare? As far as I know, Voalté is the only company using Erlang in production software within the healthcare market.  Please comment if you know of any other companies.  We would love the opportunity to share best practices and discuss how to better evangelize Erlang in the healthcare space.

Why are we using Erlang? Ericsson, the European telecommunication supplier, developed Erlang in their research labs during the mid-1980's for the following reasons:

Concurrency - Erlang's main strength lies within its support for multi-core CPU's.  Erlang is designed around the idea of extremely lightweight "processes" that communicate via asynchronous message passing,,  thus avoiding the complexity and performance impact of threads and memory locks.

Distribution - Erlang was designed to be run in a distributed environment with each Erlang virtual machine referred to as a node.  A network of these nodes on different machines can communicate as if they were all on the same computer.  This built-in distribution makes it very easy to create a cluster of computers running your application.

Fault-tolerance - Erlang will continue to operate if a node goes down or becomes unreachable.  Erlang processes can be linked to each other so if one fails the other process is immediately notified and could restart the crashed process.  Therefore crashes in an Erlang application are not the end of the world because they can restart immediately in a manner that is transparent to the end user.

Robustness – Erlang’s error detection can be used to fail-over to other nodes and Erlang's use of pattern matching allows for a "catch all."  This makes designing and prototyping new features easier because you don't have to specify, in advance what types of objects you can receive.  

Soft real-time – Erlang’s response times are in the order of milliseconds, which is excellent for failover support. 

Hot-code swapping – Erlang code can be changed without stopping a system, something no other runtime system has built-in.  This is one of the coolest features, that can permit users to update code without stopping their application and thus enable continuation of an application.

Healthcare, like telecommunications has the same general system requirements, which are distributed high-availability systems.  Point of Care workers need to receive and respond to realtime data from nurse call, patient monitoring and smart medical devices.  Erlang was designed and created from the ground up to make creating these types of distributed high-availability systems practical.  Voalté embraced Erlang's sophisticated functionality, which allowed us to produce a product that was ready to pilot in an impressive time frame of only six months.  In addition, the hot-code swapping aspect has allowed us to update our server while causing minimal system interruption to the end users.

It's an exciting time to be apart of the Erlang community.  Bjarne Däcker, one of the fathers of Erlang, presented the growth curve for Erlang and it’s starting to look like a hockey stick curve (hopefully just like Voalté sales!).  Erlang is being adopted by many leading companies such as Facebook for their chat system, Yahoo, E*trade, and Chrysler, just to name a few.  At the Erlang Factory conference I had the opportunity to meet many people using Erlang in their applications including the founders of the Erlang language.  It was great to get their feedback on Voalté and to hear their stories about creating this great platform that is at the heart of the Voalté Server.

Our First Open Source Project

The project is an audio driver that connects the iPhone audio system, using the Audio Unit API, to the PJSIP framework (also open-source). It's primary propose is to provide Voice over Internet Protocol (VoIP) using the PJSIP framework on the Apple iPhone platform.

The iPhone SDK has a couple of audio API's. The choice of Audio Units gives very low-latency audio input/output in near-real-time. Audio Units are the lowest audio layer available in the iPhone SDK. In addition to this, Apple has supplied the Voice Processing I/O Audio Unit which provides acoustic echo cancellation! We take for granted the fact that we don't hear ourselves (an echo) when talking on speakerphone.

In the iPhone, the speaker (used in speakerphone mode) and the microphone are in very close proximity to each other. (They're both on the bottom of the device.) This can easily cause feedback, or an echo, when the microphone picks up sound coming out of the speaker. Consequently that sound gets sent back to the caller who now hears an echo of his/her voice. The echo is so bad that some VoIP software providers opt not to support speakerphone on the iPhone device.

Another major component of this echo cancellation capability is the ability to remove system sounds or alerts. For example when you are on a phone call and the device plays an alert tone that may or may not have come from your application. The voice processing unit removes the alert tone from the audio input, and the person you are talking to does not hear it at all. These noises are normally impossible to dampen, as they originate outside the pjsip audio stack.

By open-sourcing, we hope to promote VoIP on the iPhone platform, and a broader collaboration from both the iPhone and PJSIP communities. We encourage others to contribute by providing ideas, solutions and improvements by way of bug fixes, performance improvements, added features and thorough testing beyond our own application environment. Because of the BSD-license any iPhone developer will be able to use the work, including commercial apps. We hope this equates to more interest in the project, and more active development from a larger audience. Ultimately, we want to encourage open collaboration and provide the best user experience for VoIP on the iPhone platform.

http://code.google.com/p/pjsip-iphone-audio-driver/