Family Medicine Notes

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.  :-(

Posted by Jacob Reider, MD at 04:11 AM | Permalink

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://www.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

Posted by Jacob Reider, MD at 02:40 AM | Permalink

• Elastix - The reliable PBX appliance software

Posted by Jacob Reider, MD at 08:17 PM | Permalink

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:EHR, EMR, Web, TBL, Faughnan

Posted by Jacob Reider, MD at 10:09 AM | Permalink

• Tell Me Where It Hurts - washingtonpost.com
  WP reviews a Consumer Reports article on physician & patient perspectives on their relationships.

Posted by Jacob Reider, MD at 08:17 PM | Permalink

• Institute for Vaccine Safety - Thimerosal Table
  Answers the questions we get rather frequently about which vaccines have mercury .. and which don't.

Posted by Jacob Reider, MD at 08:17 PM | Permalink

Posted by Jacob Reider, MD at 01:43 PM | Permalink

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 ...
  

Posted by Jacob Reider, MD at 10:15 AM | Permalink

This note in the Lancet (sorry - free registration required) tells a compelling story about the state of our Homeland security.  I'll admit I've never seen a Seton .. so I would have been just as confused as the Homeland security physician (did you know we had homeland security physicians?)

Posted by Jacob Reider, MD at 09:27 AM | Permalink

Posted by Jacob Reider, MD at 11:35 AM | Permalink

Dave's quote below is important - and a point I often try to make when working with software developers and patients alike.

Scripting News: 2/5/2007

I think many times when you know something that other people don't -- it's simply because you're standing some place where you can see something that you can't see if you're standing somewhere else. It's not because one person is smarter, or somehow better than others, it's just a point of view that's making seeing possible.

Because I am a physician - I have a certain perspective.  It's a product of my learning, my experiences, and (yes) my biases.  My perspective isn't better than yours - it's just different.  I'm not smarter because of this perspective.  

I learn from patients all of the time - since they have different perspectives that teach me things.

I don't speak Japanese.  That doesn't make me stupid - it just means that I never learned how to do that. 

You didn't go to medical school?  OK .. then I had better explain things to you in language that you understand.  Would I tolerate a Japanese speaker describing something to me in Japanese if they knew I didn't understand?  No.  So why do people tolerate physicians using DosctorSpeak?  I don't get that.

Posted by Jacob Reider, MD at 10:30 AM | Permalink

• Cold Remedies

Posted by Jacob Reider, MD at 08:18 PM | Permalink

Posted by Jacob Reider, MD at 02:49 PM | Permalink

My favorite Super Bowl advertisement:

Posted by Jacob Reider, MD at 09:36 AM | Permalink

Here's today's  silly sign.  " COMPUTER IT'S FOR STAFF USE ONLY "  Huh?

btw .. I've had comments set to require my approval on the Docnotes server for about 6 months.  I couldn't keep up with the CommentSpam - so only rarely authorized comments.   I've now turned it off entirely.  Want to comment on a post?  Sorry - you'll have to do so on your weblog instead.  :-(

Today (and yesterday)  I'm using Windows Live Writer for blog posting .. hey .. not bad.    Let's think about how weblogs have evolved since Dave first released Manila.  Back then - "edit this page" was the innovation.  Then came Radio and of course the rest is history.  (Just for the record - I was one of the first users of Pyra - the predecessor of Blogger).  What makes this all fit together so well isn't just RSS.  RSS is the front side - how we GET the stuff of blogs. It was a great idea .. and .. yes .. I'll give Dave credit for evangelizing it and honing it and parenting it through its childhood.  But the "back end" is just as important.  I can use Windows Live Writer to create this because it supports the metaweblog API.  The cool part is that I don't have to know that.  I tell it the URL for my blog, I give it my username & password .. and poof - it works.  Just like flock works, or performancing or blogjet.

Now (sorry - I can't resist) .. This stuff is not rocket science.  That's the point.  The API is pretty clean - just like the Flickr API or the Google Calendar API (though I still have a little trouble getting Oncalls to post properly to Google - even though the same ical feeds work fine with 30boxes).   These web-based apps all work right because the developers made them open.

Now look at healthcare.  I wrote about something about a year ago - and I still think there is merit to this model.  Since PHRs are all the rage (they should be) - why can't we:

• Post our "free-busy" schedules in ical format - and use a service like TimetoMeet to arrange appointments?
• Send patients their lab results as RSS feeds (yeh - secure .. )
• Set up IM portals for patients to ask questions of physicians/nurses (yeh - secure, logged to the EMR/PHR etc)
• Send SMS appointment reminders.
• Integrate with VOIP PBX, gtalk, etc.
• more ..

All of the above could be done now, with off-the-shelf tools.  Just gotta plug it all in together. 

EHR 2.0 is the next level.  Let's open up the EHR APIs like Flickr, Google, Yahoo, Userland, and Six Apart have done.  Want to edit your chart notes with a web-based minimal editor?  Go for it.  Want a "smart" (formerly called "fat") client with all of the bells and whistles that your OS has to offer?  Go for it.  Want to interface with a PHR or "patient portal?"  Go for it.  What do we need to do this?  EHR API.  We need to think of healthcare applications as a set of interoperable parts built on a solid foundation.  Just as the Metaweblog API makes it possible for me to migrate away from MovableType as my primary editing platform - it permits SixApart to focus on providing the parts they do best (server side - in the case of MT) and opens up a new market for BlogJet or Performancing.  Where to start?  EHRVA?  Hmmm.  I'm not sure they're ready to think outside the box in this way.  See yesterday's post.  Can software vendors see beyond the next quarter's sales numbers?  (Can we blame them?  As my favorite boss once said:  "with no margin - there can be no mission.")  There's a start on the front side - with CCD finally coming together as a product of CDA and CCR ... but the back side isn't there yet.  We need some leadership on this front.  Hmm.

<obligatory disclaimer>  This is my view and doesn't represent the view of anyone who is currently employing me or has previously employed me .. or will employ me in the future .. or any of my children, relatives or neighbors. </obligatory disclaimer>

Posted by Jacob Reider, MD at 09:53 AM | Permalink

Medical Decisions are hard to make.  Even when they seem easy.  

I'd say that the TV show "House" is popular because Dr House seems to focus on giving patients what they need (honesty, transparency, certain treatments) and not necessarily what they want.   In his case - the difference between the two are entertaining.   Does that make him a good doctor? 

In real life - this is much harder.   There's ample evidence that physicians' decisions are based on many factors.  What's best for the patient is simply one of these factors. 

We've had a medical student working on our office recently - and it's been interesting to see my practice style mirrored in her eyes:

• I "actually listen" to my patients (who doesn't?   I wonder ...)
• I spend lots of time with my patients (no wonder I come home late every day!)
• I hear what they mean - not just what they say (the hardest part)

I re-told this story to her - in abbreviated form.  I posted it nearly 5 years ago - but the principles I tried to highlight then remain important yet under-represented on the Internet today.  Medical blogs are now far greater in quantity - yet I still think there are rather few of them  that express the transparency that the initial work a few of us were striving for back then.   There are so many competing interests - for our time, our money, and our attention.  Without good principles - I'd argue that there is no way for physicians to stay the course - and really make the best decisions for our patients.

The National Physicians Alliance is a relatively new organization that's building steam - based on good principles.  It's great to see an organization that is committed to "Advancing the core values of the medical profession: Service, Integrity, and Advocacy."   You can also read the NPA’s ISSUE BRIEF outlining reasons why physician prescribing data should not be made readily available to pharmaceutical companies.  The issue brief mentions describes how to opt out of pharmaceutical industry data gathering by enrolling in the AMA's Physician Data Restriction Program (PDRP).  Cool.  Check.  Done. 

Integrity is so important - yet so often suspect when there is opacity.  Exposing our patients to the uncertainties of our profession is a cornerstone of shared decision making - yet it takes so much more effort - and so much more time - I'm not surprised that so few physicians actually do it. 

The same goes for plumbers.  We had a "free" cleaning of our furnace performed by these folks last week.  The service rep called my wife at work and told her we needed a new humidifier element for $45.  He happened to have one.  Said OK.  We also needed a new solenoid for the humidifier for $89 "on order."   Turns out - I replaced the humidifier element about 6 months ago (should be done once/year) and the solenoid seems to work just fine to me.  You can listen to  his explanation - left on our voicemail.   Now -  look at the picture. Water running pretty well, if you ask me!   I filled an 18 ounce cup in under 30 seconds.  If that's a "very small amount of water" - I think Gary needs to go back to plumbing school.

Either Gary is stupid - or he's lying.  Either way - I can't trust him or his company ever again - as I suspect that he's got his interests above mine.  I could buy the solenoid (see link above) for $45 if I really needed one.  And I'm a little mad that he took my 6 month old humidifier element with him when he sold me the new one (it's the honeycomb thing in the picture).  Either way - he can't be trusted.

We need trustworthy plumbers, doctors, bankers, lawyers, software developers, etc.    The principles of the profession  must guide our decisions.  If not - we will always be distracted or seduced by the many other choices on our path.  Plumbers who invent problems, doctors who self-refer, and software developers focus more on the icing than the cake - all compromise their integrity in the same way - and will ultimately lose.   

-------------------------

When my patient called this morning - I overheard Amanda our nurse explain why I couldn't just call in an antibiotic for this problem (as was his request).   Taking my time in our visit  this morning to really learn his needs - while I taught him about the science behind our treatment options - took me 35 minutes more than it would have taken to prescribe azithromycin and shoosh him out the door.   Yet when he left the office - I was enthusiastically thanked  for helping him to understand this problem in a way that no other physician had ever done.   Not only will he get better this time (sans antibiotics, btw) - he'll also know how to manage the problem on his own next time - preventing his discomfort and his need for the visit to the office.  Had I given him what he asked for - I wouldn't have given him what he needed. 

Posted by Jacob Reider, MD at 10:00 PM | Permalink

Then what is it?

Posted by Jacob Reider, MD at 12:56 PM | Permalink