Month: February 2007

Agile Development

The Agile Manifesto seems like ancient history now.  The concepts of iterative development were not new – but they hadn't been marketed until the manifesto was published and the movement was unleashed.

In  late 1999 or early 2000 I can remember sitting in a meeting room with the Assistant CIO of a large healthcare organization .. describing my preference for using what I then called an iterative development process – where we would define "bite-sized parts" for implementation, exposure, and refinement on a regular basis. 

She had never heard of such a thing – and advocated for the developers on the team: 

"They need to know when it's finished!" 

Me:  "This is software – it's never finished"

"But the customer needs to sign off on a completed project.  How can we know that it will meet the customer need?"

"uuuh … ask them?"

"We ask them during the requirements process – when they define the project"

"And that is successful?  They are always happy with the final product?"

"Well – no – but if they didn't describe their needs appropriately – that isn't our concern.  So long as they have signed off on the spec before the development work begins – we have clarity for the what the requrements are – and if we build it to spec – we've completed the project and we can move on."

..

I stopped trying.  Clearly the goal here was to complete the project "to spec" and move on to the next project. 

There was a problem though – developers were bypassing standard process – and interacting directly with customers (with no management oversight) and were creating solutions collaboratively with customers.

So the Ass(istant) CIO wanted to give the developers a sense of closure .. but the developers wanted to please the customers – and bypassed their managers to do so!

Trouble in them thar hills, too.  With no Human Factors training – and minimal design skill – developers all-too-often gave the customers what they asked for rather than what they needed.  End result: ACIO came down hard on such "renegade" developers.

This reinforced the waterfall mentality.  🙁

Free CallerID Reverse Lookups Mashup

As avid readers know – we use the Switchvox VOIP PBX in our office. It's been up about 18 months now .. and despite some hiccups – we're happy. It's flexible and reliable.

If our phone company was sending us the callerID names with the calls – we'd see them .. but they don't.    There are a few ways to get this – including some expensive solutions and some less expensive ones .. but I've spent some time tonight (this morning?) getting a little "mashup" to do this for free.

Overview:

Switchvox allows you to send or revieve information with a URL when certain events occur.

So every time a call comes in – SV can send the CALLERID to a URL somewhere. It expects an XML document back with the data. Using Dappit, I made a little application that goes and does a reverse lookup and returns the name(s) associated with that number.

Next – I had to make a stylesheet to turn that output into the XML form that SV wanted. FInally – I had to put it into the "default URL" field in the Switchvox URL manager page.

The URL for Switchvox is:

http://www.dappit.com/transform.php?dappName=RLK&transformer=XSL
&variableArg_0=%CALLER_ID_NUMBER%&extraArg_xslUrl=
http://docnotes.net/phone/phone2.xsl 

Don't click that – as it' will cause an error since there is no phone number.

You can use this link to see what it returns

Faughnan’s a grown-up now!

John's recent post on my "medical office mashup" comment is, as my colleague Paul would say, "spot-on." What I learned from his discussion:

  • Long ago in a Minnesota far-far away .. where Gopher was born .. and professional wrestlers were still wrestling … John used to look up at that cold sky and dream of medical mash-ups.
  • In a weak moment – you can still see that little kid in John – but he's been hangin out with the suits lately – and they make him say things like this:

    "Building a 98% reliable solution from x integrating parts requires (1- x*y*z…) reliability from each component."

Of course – he's right. That's the problem with the CIO types that he hangs out with — they're usually right.  Too many points of failure, too many dependencies on "foreign" systems, etc.  Gotta do it the "enterprise" way. 

But we've got to be able to dream these dreams – because they are the right ones to have. Sure – Google's calendar API will change and I'll zig with their zag – because for a user base of 1 person – this software is neither "mission critical" nor 100% reliable.

If we did everything the enterprise way – there would be no Internet.  TBL's vision was that by connecting things – we can derive enormous value.  Consider this section of one of his most famous essays:

 … For all these visions, the real world in which the
technologically rich field of High Energy Physics found itself in 1980 was one
of incompatible networks, disk formats, data formats, and character encoding
schemes, which made any attempt to transfer information between dislike
systems a daunting and generally impractical task. This was particularly
frustrating given that to a greater and greater extent computers were being
used directly for most information handling, and so almost anything one might
want to know was almost certainly recorded magnetically somewhere.

Design Criteria

The goal of the Web was to be a shared information space through which
people (and machines) could communicate.

The intent was that this space should span from a private information
system to a public information, from high value carefully checked and designed
material, to off-the-cuff ideas which make sense only to a few people and may
never be read again.

The design of the world-wide web was based on a few criteria.

  • An information system must be able to record random associations between
    any arbitrary objects, unlike most database systems;
  • If two sets of users started to use the system independently, to make a
    link from one system to another should be an incremental effort, not
    requiring unscalable operations such as the merging of link
    databases.
  • Any attempt to constrain users as a whole to the use of particular
    languages or operating systems was always doomed to failure;
  • Information must be available on all platforms, including future
    ones;
  • Any attempt to constrain the mental model users have of data into a
    given pattern was always doomed to failure;
  • If information within an organization is to be accurately represented in
    the system, entering or correcting it must be trivial for the person
    directly knowledgeable.

Lots of what TBL said in 1996 (about physics in 1980) still applies to healthcare in 2007.  shame on us!

So my tiny project (total time invested <2 hrs) is an example of how we might start thinking about the parts fitting together.   It's 2007 and there are companies out there that have already started to develop and deliver webservices that provide important parts of the EMR infrastructure.   They work today – and will do more tomorrow.

Of course I've been wrong before … a professional wrestler as Governor?  Never.  🙂

technorati tags:, , , ,

Google Calendar for office schedules

A few days ago I made a comment about how the building blocks were there to pull together some "mashups" in medical practice.   I said it wasn't rocket science.   Here's a short description of how I solved a real-life problem in my practice. 

Problem:

  • Dr Reider isn't as well organized as he could be.  Duh.  this is a common problem in healthcare.  Physicians work too much – we'd much rather spend time with our patients than at our desks reviewing paperwork, writing notes, etc.  Perhaps I'm worse than many others.  So be it.  Not going to change this old dog. 
  • Sometimes I'm not scheduled to see patients in the office (yes – I have too many jobs – but let's keep on track here!) but I agree to see someone anyway.  Perhaps I am on the phone with someone who tells me that they can't get an appintment to see me for a few weeks .. and I say "well, Bob .. how about we see each other at 8:30 next Tuesday?"  So Bob gets scheduled .. and next Tuesday rolls around and Bob shows up .. but I'm not there because I forgot. 
  • oops.  Office calls me.  I rush to the office .. see Bob.  All is well.   We hope.
  • My attempt @  human solution was to have the office staff look @ tomorrow's schedule .. see if there are patients scheduled to see me on a day that I'm not usually "in" – and call to remind me.  Short version: this didn't work. 
  • Enter technology:

Requirements:

  • The system will be able to determine when the provider is scheduled to see a patient on a day that he is not otherwise scheduled to see patients.
  • The system will be able to cause the provider to be reminded about the appointment(s) with enough warning to be able to be in the office on time – yet not so early (1 week) that he will forget.
  • The system should – if possible – be able to add the appointment(s) to his calendar in google calendar, 30Boxes, or Outlook.

Implementation:

  • I'm using the webservices that I created for our Misys Vision practice management system to get the information about the scheudle.  Easy.  Scheduled Task that runs on the server @ 6 PM
    • GetSchedule("JMR",BeginDate,EndDate)  .. in this case – I get 1 day – tomorrow.
  • I parse the data and decide if it's a "usual" day or a day I'm not supposed to be in
    • If # rows returned > 4 .. End
    • If $ rows returned < 4 .. then it's probably not an "in-office" day – so let's keep going
  • Push the data to Google's API – to add an event for each visit
    • Sending: BeginTime, EndTime, no patient identifier, description "patient scheduled"
  • The scheduled visit is now on my google calendar.  I can now receive an alert from google via SMS .. or sync with my PDA, outlook, 30Boxes, etc.  Easy.  Google this – there are so many options these days .. from SyncML free solutions – to commercial products.   Perhaps that topic deserves another post …