Medical Blogs etc.

Dave Winer linked to yesterday's Grand Rounds post and the server is taking a big hit today.  I reorganized the archive template to load a bit faster .. and provide more context.

Doing the Grand Rounds reminded me that bloogers like (love?) traffic.   Do lots of hits define a good blog?   I remember Steve talking at the first Bloggercon about watching his traffic logs and keeping an eye on the referrers – always interested in who is out there reading what he writes.

I'm getting lots of e-mail this morning about posts that I didn't include, or suggestions for more.  No – these aren't the online Vi_g_a (dare I even write the word for fear of attracting TrackBackSpam) sites – but real bloggers who just want their message "out there."

Contrast this with the bloggers like Kevin and Sydney and DB.  Bloggin away .. and doing great work – whether you read it or not.  My best posts are written for me – not for you. 

I'm not saying that wanting traffic is bad (yeh – I sent Dave an e-mail inviting him to post a link) but I don't think that it should be the primary reason for doing this sort of writing.  

Grand Rounds #53 Published

One of the reasons that I’ve been less compelled to write recently is that much of the void that existed has been filled by the many health care providers now writing so well.  "The void" that I perceived was the absence of transparency in our business.   Before weblogs – it was uncommon for real healthcare providers to reveal their thoughts & feelings about the work that we do in a public forum.  Our patients know us as either wonderful and kind .. or uncaring, thoughtless and hurried  .. but little was revealed or understood by the "general public" about who we are and what we’re thinking. 

Another obvious role of medical weblogs is to educate.  We educate ourselves and our colleagues by constantly gleaning the vast information resources – and pointing to important or compelling bits.  And of course we editorialize .. which is the true advantage here.  We’re transparent about our biases – so (as some have argued) we may even provide a better view of the "news" as we’re more honest about the lens through which we view things:  new research findings, hew medications/indications, etc.

We’ll start with a few of the old favorites .. and them move into some of the more recent additions to the world of medical weblogs. I had over 50 suggestions for inclusion this week … and have done my best to select a good sampling.  Please don’t be mad if I didn’t include you! ..

  • Doctor Bob, as usual, educates.  Lest week – he brought us this entry on consumers using the Internet to choose physicians and hospitals – and reminds us that data inherently misses many of the qualities that can differentiate between good and not-so-good physicians.
  • Sydney’s style is more informal – news clips  with editorial tag lines.  I think this is what makes her blog so popular.  It’s quick reading – but you can always plan on seeing something new there.  Today’s post on physician conflict of interest begins with this: "Sadly, this is not surprising …[text of news item here] … and ends with this "Even sadder, the doctors involved can’t seem to understand why this is wrong."  Great stuff.
  • Another "old timer" from the medical blog world is/was Steve Hoffman .. who has been nearly as Idle as I am.  C’mon, Steve .. get back into gear!
  • Gruntdoc needs to look out for earthquakes!
  • Orac tells us about a tragic and unnecessary death of a child.
  • Alwin has also been in the mix for a few years … and he’s still trying to figure out why he blogs:   
    • "Me? I’m just as confused as I’ve always been. I’ve never been able to settle on an individual topic to focus on. No real reason to go on, no real reason to stop. After 5 years, this joint has it’s own kind of institutional inertia. “Help, help! I’m blogging and I can’t give up!” I could have been saved if I had been wearing my BlogAlert necklace…"
  • .. and we can’t even get rolling without mentioning Docshazzam … who went for a "girlie ride" this week.  Her blog – which (still) has the best title – chronicled her journey through a residency in Emergency Medicine.  She writes wonderfully – and her anecdotes about life in the ER are vivid. 
  • Matthew Holt’s blog is not one to read when you only have 30 seconds.  Gotta really think when you read this stuff – but I’m always impressed with his ability to see through the crap and guide the gentle reader through the maze we call our "heal care system." Today’s blurb:

and on to some more recent additions …

  • Intueri is the most poetic.  I simply love the prose:
    • The patient sat on the bed, his limbs dangling weakly from his trunk. Mustard was smeared across his chin and a soggy crumb of bread dangled from his upper lip. His mouth was hanging open.  When he spoke, his mouth never completely closed and yet somehow, his speech was thick and slurred like a milkshake that would not travel up a straw.
  • Barbados Butterfly weaves a tale of the Elderly Woman atop a Trolley.
  • Neils is a medical student at Tulane – and his posts about about post-hurricane Gulf Coast are informative – yet also provide some of that transparency we like so much:  I can tell from his writing that he’s a medical student .. learning this stuff .. and loving the excitement of it all.  Such a novelty this medicine bizness is … (he seems to be saying) .. so fun/scary/exciting/important.
  • Red State Moron reports on limiting medical student work hours.  But back in the day:
    • "Rounds started at 430 am; we usually had 60 patients on service.  Think Maine in the summer.  A lot of trauma, mostly MVC’s and burns.  We would spend the day in the OR, and finish with evening rounds and usually be out by 9 pm.  I never opened a text book.  But I learned more in that month than I thought was possible. "
  • Aggravated Docsurg follows with another wonderful view into the mind of a physician .. as we follow the bouncing ball through his cortex … all of which oddly reminded me of an episode I blogged about a few years ago. Physicians who listen are likely to hear more than those who speak.  Duh.
  • Power and Control shares a compelling review of research supporting the hypothesis that drug abuse is self medication for pain/anxiety.  This is one of the self-evident "truths" that most of us accept without good science to back us up.  Last week I suggested an antidepressant medication for a man who drinks heavily – smokes marijuana often, and uses cocaine to "keep stable."  But he doesn’t want to take a medication for fear it will alter his physiology.   "Man – you ARE taking medications" I meekly suggest.  He doesn’t see it that way.
  • Diabetes Mine is a weblog written BY a diabetic FOR diabetics.  It’s a great resource and I often refer patients there. This week she reminds us that a 15 minute eye exam can be much more than that … and then gives an excellent overview of one of the prevalent theories on the viral causes of Type 1 diabetes. I enjoy reading medical blogs by people who are doing their best to learn as much as possible about the disease that they (or a close friend/partner/relative etc) have.  Like the medical student blogs – I can feel the WONDER and EXCITEMENT as the science is explored … yet as that happens .. the imperfection of the science – and our truly limited understanding of all of this becomes more clear.  Debunking the myths that physicians know everything.  A+
  • Healthyconcerns is jonesing for a medlog fix … (which of course will soon be satisfied) .. and last week pointed us to the very cool earpopper (featured on Medgadget) that I am actually thinking of purchasing .. and has problems with increasing blood pressure over a silly little bill.
  • Parallel Universes teaches us that men don’t wash their hands after they go potty.  (no mention of the classic Seinfeld episode .. which of course confirms this "medical fact.")
  • The Health Business blog carries the message from a Boston Globe story that patients should plan for doctor visits.  Yeh .. um .. I agree, but the post sounds a bit like mom telling you to wear clean underpants.  This is a Blog, man .. where is your opinion/emotion?
  • This from ImpactED: "Being dead really sucked. I had a cramp in my leg and the body bag smelled like a bicycle repair kit." keep reading this one .. it’s funny .. and a bit unnerving.  With friends like this .. ?
  • Tim Gee is a connectologist .. writing about workflow automation
  •  .. and from the "what took them so long" department .. Clinical Cases Blog tells us about dental students getting lectures via podcast.  Hey – I thought of that WEEKS ago! ..
  • Speaking of podcasts (yes, Ken … we keep missing each other .. I’m still "in" .. ) There is a great podcast at J. with Scott Armstrong of Wharton who talks about the limits of peer review, the need for transparency in the doctor/patient relationship and the limitations of experts.
  • Kidney Notes shares a great view of the medical blogworld via a tagcloud 
  • Sometimes we think of difficult patients and groan as we inch toward the exam room door.  It’s true (transparency again) A Difficult Patient reminds us that difficult patients are not difficult on purpose .. and it’s difficult for them too! "This blog is very personal, and it is written by a difficult patient." 
  • No medical weblog roundup is complete without a pointer to two medical bloggers I’ve actually met:
    • John Faughnan’s posts are rarely medical, but always thoughtful and informative.
    • Enoch Choi is at the AAFP conference .. which is heavily financed by the pharmaceutical industry.  Good thing Enoch is immune to this:
      • "I’m surfing thanks to Crestor, which i don’t use since the singaporean studies showed twice the incidence of liver function abnormalities, causing them to recommend 1/2 the highest dose as a max for Asians. Good drug otherwise, I’ve heard."
  • Is Glenn McGee a Vulcan?   Glenn’s posts on are excellent – and usually thought provoking .. but we wish he would take a stance sometimes .. as he does a great job of raising the issues .. but I often have a hard time figuring out where he stands.  Reminds me of a classic dialog:
    •  Bones: SPOCK! You and your damnable Vulcan logic…

      Spock: You’re far too emotional Doctor.

      Bones: Why you damned green-blooded pointed-eared inhuman jack rabbit.
      Why don’t you just go fry in hell!

      Spock: Unlikely, Dr. McCoy, hell is …

On that note — we’ll close the anniversary edition of Grand Rounds.  Tune in next week and thanks for reading!

PBX for the Medical Office

Bruce gave me a hard time about the Switchvox review (yeh .. I’ll finish it) because there was no good introduction to exactly what the system is – and why I would want it.

 Here’s an intro paragraph:

Asterisk is an open-source phone system.  It replaces the Nortel or NEC or Siemens Or whatever system that you have in your office.

Why would you want to replace your current system?  Well .. because it’s old and hard to change settings and/or maybe it is just time to upgrage and you are shopping around.  In our case – it’s that the old system (a perfectly functional Nortel Meridian Sytem with Voicemail and ~10 extensions) didn’t do some thing that we wanted – and we’re tired of struggling with configuration changes that take either a long time to learn & memorize – or $90/hr to pay the local phone guys to come and help when we are over our heads.

Asterisk is great and has many features.  It does all of the things that your current phone system does .. like answer the phone .. route calls to extensions, manage voicemial, etc.  There are two things that make Asterisk different from most systems: 

  1. It usues VOIP
  2. It is free

The difference between a VOIP system and an analog system is that the voice is moved from the server to the phones over computer wires just like the signals from one computer to another.  Yes – it will work over WiFi too.  So of course the phones are not regular $9.99 phones you can pick up at Kmart .. they are actually little computers themselves – since they need to decode the bunches of data that represent the voice and make it into something that the person hears.  It all sounds like it would be too hard and too slow to do all of this encoding of data .. moving it and then decoding it .. but the technology has gotten pretty good.  Trust me – it works. Yes – you can even use the $9.99 phone from Kmart if you buy an ATA – which is a little adapter thing that costs about $60 and does the comptuer work for you.

Why would you want to use VOIP indtead of an analog system?  Using a computer to set-up the system and route the calls makes more sense than remembering (or reading) a bunch of codes and punching them into a telephone.  VOIP also means that the phones keep their setup information wherever they are.  So if you unplug the phone from the office and plug it back in at home (so long as you have an Internet connection) — the phone will work the same as it did at the office.  Dial a "local" extension for the person who was one office away and it will ring there just as if you had been back at work.

This makes it easy to have remote workers.  One of our nurses will be working from home to help us triage calls when we get too busy.  

Hardware and infrastructure needs.  To install a VOIP system – you really don’t need much.  Asterisk can run on an old PC with not-too much RAM.   The load on the server is proportional to the number of concurrent calls.  For home or small business – a reasonably capcable desktop PC would be fine.  Big companies can run hundreds fo concurrent calls through a moderately sized server.

The system needs to get calls .. and make calls – just like any phone system. 

If you want to use it at home, you could set it us with straight VIOP and pay for calls either monthly (unlimited minutes) or by the minute with Broadvoice or one of the other VOIP providers.  Google "Asterisk VOIP" and you’ll find lots.  You’ve heard of Vonage?  Well think of an Asterisk system as your own little Vonage.  Each extension you create in the system is like one of Vonage’s customers.

For a medical practice – VOIP may work for some things (we’re going to have a few lines on VOIP for overflow) but it’s better to connect the system to a T1 or partial T1 that is provided by your local phone company.  This will replace the analog lines that are plugged into your current system and will provide from 9 to 18 (depending on what you buy) lines.  The T1 connects to the Asterisk system (you have to buy a T1 card that goes into the computer for this – about $600), and Now Asterisk can "see " the lines from the phone company.  Calls from inside the system got out to the phone company .. and calls from outside come in.  You can set up rules for how calls are handled, set up "IVR trees" to help callers find what they want .. etc etc.

Still with me?

Ok .. so why use Switchvox instead of plain (free) asterisk?  Because The setup and management of Asterisk is not plug-and play.  I can do it ( I set up two Asterisk servers at home) and most nerds can – but I want something that our office manager can set up and manage without any technical help.  Switchvox is a commercial product that puts a plug-and-play user interface on top of Asterisk.  While there are other UI enhancements to Asterisk from competing vendors and open-source collaboratives, We selected Switchvox for the reasons I discuss in the review.  Switchvox costs about $1500.  Add the phones and you are probably talking about $3000 for the whole nine yards.  Compare that to a $10,000 or $20,000 phone system that does less.  Hmm .. hard choice — eh?

USb Flash Phone

Still thinking about how to outfit the office with phones for the new system (I don't want to spend a ton of $$ of Polycom phones for everyone! .. stumbled onto This Phone … which (I think) looks interesting, but I am thinkin that the Chinese => English translator needs a little work. The Q/A is funny to read. Esample:

1.Why I need order combo desktop package?

The combo desktop package will include one Telbox B2K and one USB phone P1K. You can install the Telbox B2K with your desk telephone, and use the USB phone P1K as your travel package. Also save your money.

SwitchVox Review – Part I

9-12-05  Update: I’ve posted an introduction to this review – as I had some feedback that I didn’t introduce the concept of VOIP very well (at all).

Tom’s Hardware Guide recently reviewed the Asterisk @ home system.   AAH was the first system that I used to implement Asterisk, and enabled me to learn about this wonderful open-source PBX.  This review will cover a commercial implementation of Asterisk – SwitchVox – from Four Loop Technologies

Implementing Asterisk with AAH is reasonably easy for someone with moderate technical skills – and I have previously been able to set up a home phone system without too much trouble.  Over the course of a few months last Spring, I learned enough about the innards of Asterisk to understand the potential of the software, and developed a rough model for how it might be used to enhance  the functions of a medical office.

But I also recognized that the setup and management of Asterisk requires technical skills.  Sure – I can build a system for home and if it breaks – I’ll fix it later (though the teenagers wouldn’t be too happy .. )  But while I’m seeing patients, I can’t step into the back room and troubleshoot the system for 2 hours.  A medical practice needs to install something that can be set-up and managed by normal humans – not nerds.

So I started looking at commercial versions of Asterisk.  There are several alternatives:  Fonality is well-known, but from the documentation and a review of their software, it seems that they don’t have an API that would support some of the more interactive features that I want to implement.    I reviewed Scopserv briefly – but the setup and maintenance requires more technical skill than most of our office staff currently has.  In looking at SwitchVox, I was impressed that the look-and-feel is very clean and well designed,  my e-mails were answered very promptly, and that one of the founders of the company gave me access to their test server said so I could build a thorough understanding of the capabilities of the software before I purchased it..

Unfortunately, there aren’t a any reviews that I could find in the Internet of any of these packages, so I have decided to write this short review of the SwitchVox system so that others can build a better understanding of how it functions and what some of the strengths and weaknesses are.

Although SwitchVox is based on Asterisk, this is invisible to the user.  Set up is accomplished with a CD-ROM for installation on a server, although most SwitchVox systems are sold preinstalled on hardware provided by the company.  While resellers can purchase the software for installation on certified systems, (systems that the company has approved as capable of supporting the software) this is clearly not the company’s standard operating procedure, as resellers receive only a minimal discount off of the retail pricing.

Initial configuration of the system involves setting it up with the appropriate IP address settings as one would any new computer system.  A series of menus walks the user through this set up.  It’s quite easy to do and requires no significant technical skill.

After this initial set up, which needs to be done locally on the computer, all of the interaction with the SwitchVox system is through a web-based interface.



The main screen provides access to set up extensions, PBX features, hardware and network configurations as well as some rudimentary diagnostic screens.


Before using the system, extensions need to be set up.  The process is very straightforward and once again, most of these functions could be performed by a non-technical user.  



The extension management page is clean and well-designed.  As you can see in this figure, it lists all of the currently configured extensions and provides intuitive buttons that permit the user to modify or delete existing extensions.  By clicking "create a new extension" the user is brought to the extension configuration page.  As with most pages, a well-written and well-designed help functionality is present and can be accessed by clicking on "how do I use this page."



To create an extension, one chooses the kind of extension, and the extension template.  Options for extension types include SIP telephones, analog telephones (so long as the appropriate hardware is installed), call queues, IVR (interactive voice response) menus, virtual extensions, directories, call queue agent logins, as well as dial tone access.   Notably missing from this menu are IAX extensions and fax "in" boxes.


The extension management screen for a SIP telephone or SIP ATA, which is accessed either by clicking "create a new extension" on the previous screen or clicking "modify" on the main extension management screen, provides access to the extension number, name of the primary user, in the ability to enable or disable access to PBX functions such as call forwarding, voice mail, call parking and web access.  Outgoing call rule access can also be defined here, so (for example) some extensions can access local calling only while others may have the ability to make local and international calls.


Overall, the extension management functionality is well-designed and in demonstrations of the software to office staff and clinical users, everyone seemed to "get it" after clicking around on the screens for only a minute or two.

Most of the commercial systems provide similar ease of use, so I don’t think we’ve yet seen anything that is extraordinary or unique.


The power of the SwitchVox system lies in the PBX functionality.



Features in the PBX menu include music on hold, IVR editor, sound manager, time segment manager, and agent settings.


These menu choices don’t seem to be grouped in any logical fashion.  The process of setting up an IVR menu requires quite a bit of planning and in fact, the first thing that is necessary to set up a robust IVR menu is to set up the proper sounds that will be played as the caller moves through the menu.  For example, if the first menu is going to say "Thank you for calling, press 1 to make an appointment and press 2 to request refills for your medications and press 3 if you are calling to review lab or radiology results” then before you even go into the IVR menu, you will need to go to the sound manager and record this prompt.  Therefore, I would have put the sound manager as the first menu item since this is the first step in creating an IVR menu.  Similarly, the “time segments” functions, which permit you to define when the office opens, when lunchtime is, when the office is closed, etc. would be the second step in creating a robust IVR since you would want to create one IVR tree during business hours and another IVR tree for when the office is closed.

Ideally, I would like to see a method for creating sounds within the IVR editor since I frequently found that I would have to go back and forth between IVR editor and sound editor to create new sounds for functions and prompts that I hadn’t anticipated the need for.

Nonetheless, these functions are easy to reach and going back-and-forth between sound manager and IVR editor is quite straightforward. 


The IVR editor is the most powerful component of the system and enables one to build extremely complex IVR menus (and in fact IVR menus of IVR menus) with a very straightforward user interface that is quite well-designed.


The software retains some of the nomenclature of Asterisk.  This can be a bit confusing for new users and I’m not sure that it’s necessary.  For example, IVR’s are created within "contexts"  the context is given and name for example "main switchboard greeting."  



As you can see here, one can name the context and provide a description of what the context does.  When introducing the system to new users, this was confusing because the term “context” doesn’t mean anything to them, and most would prefer to use a more descriptive term such as menu or menu tree.


After creating the new context, one  is presented with the main context configuration screen:




Although this screen is a little bit confusing, one gets used to it fairly quickly.  On the left is an overview of the context and on the right are buttons that permit the user to go into editing mode to add, modify or delete actions from the contexts.  Let’s look at how to add an action:



With the addition of an action, you can cause the system to do nearly anything.  At first, this is hard for users with no experience building such a menu to understand.  When working with the staff in our practice, I ended up taking a deck of 3 x 5 cards and writing the titles of the actions on the cards.


For example there are several cards called "record sound" and "record digits" and "play sound ___” so to plan an IVR, all one needs to do is choose the appropriate cards from the deck, and assemble them into a sequence of events.


This makes it easy to then sit down in front of the computer and create events in sequence using SwitchVox after the planning had been done. 


As you can see, menus to guide the user through IVR creation quite well and they even permit branching from one IVR menu to another by using the "Go to context/Action" option.



A unique component of SwitchVox (and one that caused me to purchase the product) is the ability of SwitchVox to send parameters and return data from an external web site.  The mechanism for doing this is pretty straightforward.


Let’s look at the demo on-call IVR that I am creating for our practice.  You can see the overall IVR tree on the left which shows the general sequence of events that occur throughout the menu. The details are on the right, and can be edited by clicking the edit buttons.  The first event is the announcement about the time of day and gives the user a series of choices to make regarding what they would like to do.



By clicking on a button called "modify actions" a detailed action modification screen can be accessed.  The screen provides detailed information about each of the actions, allows the user to move actions to different parts of the sequence, and allows for modification or addition of actions.  The first option obviously plays the sound as I mentioned above.



The second action "send call values to URL" is what we’re looking at now.  Let’s look at the details of this action.









The first section provides a field to enter a URL.. this has to be the URL of a web site that will provide the information back to the user in a form that SwitchVox can consume.  The SwitchVox documentation does provide some guidance for  how to do this so it didn’t take me too much time to figure out how to use this.


The goal of this action is to retrieve from an external data source which physician is on call tonight so that the appropriate physician can be paged to notify them of this patient’s phone call.  We’re using, which happens to be an ASP for physician call schedules that I developed with David Ross several years ago.  It took me about 10 minutes to configure a custom page that would respond to URL variables (a username and password – optionally encrypted) and would respond with an XML page with the appropriate data for SwitchVox.  If you look closely at the URL, and will see that an ID (my medical group) and a username and password are the only parameters passed into the web site.


At this point, OnCalls looks to see which provider is on call tonight in our group.  It will only return this information if a userid and password are passed which identify this physician as a user in this group.


In the middle section of the page, SwitchVox provides an easy mechanism to pass additional parameters out of SwitchVox and into the receiving system.  Any information that the user has entered for even information that SwitchVox has acquired in recent interactions with the a URL can be passed here.  


The XML page that OnCalls returns to SwitchVox  looks like this:


<?xml version="1.0" ?>
<variable name="docname">Reider,</variable>
<variable name="pager">########</variable>


So there are two values –  “Reider”  and “######” (which of course is my pager number that I didn’t want to publish on the Internet so you won’t page me to the Domino’s pizza in Anchorage, Alaska)



At the bottom, you can see that these values will be passed back in the variable names "docname” and ” pager.“


So now if we return to the overview of IVR screen, you can see that step three "play sound" is annotated to play the name of the physician on call.   I had previously recorded a sound with the name of the physician on call, and so now at this point, I can just play that name and the system will speak the name the correct person is on call.


From here on, you can see that I enjoyed playing with some if/then causes and dialing of telephones.  It would be easy for example to have the system call the physician’s pager number, cell phone, home phone all at once, and if one of telephones is picked up, the call would be routed to that extension (even if the extension is forwarded to my cell phone!)


Obviously, there would be more IVR options than this in real-life.  We will likely need to make sure that patients who have messages for daytime office staff ("I can’t come to my appointment tomorrow afternoon") don’t leave such messages for the on-call physician at three o’clock in the morning.


A more extensive method for using the IVR menu is to provide interactive experiences for the user based on who they are.  We are in the beginning stages of creating a menu that will permit the patient to enter a unique ID number and automatically retrieve the results of recent laboratory tests or radiology tests that will be entirely built with the system.  By sending a captured (patient – entered) series of digits to the URL, the URL can return an identifier for a certain type of lab result.  This identifier (when sent back to SwitchVox) can cause the system to play the appropriate message that is related to this patient’s result.

For example, Bob Jones calls the system and his ID number is 12345.  Bob pressed "5" for "retrieve my lab results" and then SwitchVox sends "12345" to the lab result reporting system.  The system looks and finds that his cholesterol report is available, and the result is a bit high – so a return variable "highchol" is sent back to SwitchVox – which plays the previously recorded message about high cholesterol, and what we advise Bob to do about this.

Of course,  the a system like this can’t provide information for all results, but we expect that roughly 70% of results would be available in this way – which significantly reduce the number of phone calls and letters that we currently generate.

So, as you see, the system not only interacts with itself and permits people to make telephone calls to each other easily within on office and beyond the office, it provides many functions that will allow office staff and patients to easily obtain or convey information.


Clearly, there are many more functions that the IVR editor can do and I have been working with Fourloop, the developers of SwitchVox on software that will interact with a future version of their product (hopefully in September) that will enable me to loop through a list of patients who have appointments in the next day or two and cause SwitchVox to call these patients —  reminding them of their appointments.  The call they receive will provide them with options such as "press 1 to confirm that you made this appointment and that you will be able to attend the appointment at the specified time, press 2 to if you would like to reschedule right away and you will be connected to a receptionist immediately … Press 3 to leave a message for the administrative staff who will assist you in rescheduling your appointment during the next business day.”  (Or something like that)


The system set up section of the Web administration menu for SwitchVox provides options to create channel banks and channels for hardware that is enabled directly in or attached to the system.  There’s also a fairly easy-to-use management interface that allows for the addition, modification or removal of new inbound or outbound VOIP providers.  These screens work reasonably well unless there are any problems.  Unfortunately, every VOIP provider’s requirements for set up are a little bit different.  We were able to get Teliax to work flawlessly with their default settings, but Broadvoice, Sixtel and voip-jet (we’re testing several of these providers to see which we have the best luck with) have been problematic to some degree and we have been frustrated by the cryptic nature of many of the errors in error reporting system.  I keep thinking that if I had accessed to the real Asterisk error logs, I would be able to diagnose and adequately repair the VOIP settings.  Nonetheless, neither I nor my consultant were successful in getting incoming calls from these providers to work with SwitchVox – though I have been able to get them working with an AAH installation just fine.

And there’s the trade-off of a commercial version of Asterisk.  If everything works perfectly, being protected from the configuration settings for Asterisk is just fine.  But when there are problems, we’re locked out – and can’t even adequately diagnose things.

I hope to provide additional information about  logging functions and other diagnostic and administrative functionality of the system.  I didn’t discuss call queues at all and I think that call queues are very important and robust part of the software, but this has gotten a bit longer than I intended .. so I’ll  quit for now  and begin working on Part II on the next day or two 


Before I do that, though .. here’s a quick overview of our hardware: 


Well, this isn’t really of review of the hardware in any significant detail, we purchased a series of Polycom phones to try them out.  The Polycom 301 and the Polycom 501.  The phones are excellent although I think that the better screen quality and better sound quality of the 501 may in fact make it the most popular phone in the office.  We also bought several SIPURA 2002 ATAs and I have been testing these as well.  Set up the scrape straightforward and takes about 90 seconds.  These phones will be given to employees who need to work from home  (or anywhere) yet retain an office extension and office callers ID members when calling hospitals, doctors offices or patients.