Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Tuesday, January 7, 2014

Telling Stories

People really like to tell stories.  A few weeks back I was leading a workshop where I was trying to get a bunch of non-technical folk to explain to me what their needs were.  I had blocked off some time in the workshop to get into the details of what they needed.  My visioning exercise had totally bombed a half hour before (from my perspective).  Trying to get people to imagine what technology could do for them who hadn't ever been exposed to anything like what you have to show them is really challenging.

So what I did was ask them to tell me a story.  I broke the group up into smaller groups, and separated them from their usual cliques and colleagues, making them work with people in different specialties that they wouldn't normally run into.  Then I had each group tell me two stories.  The first story was about a normal event, when everything goes the way it should in a text book.  The next story was to expand on that, adding detail that can only happen in the real world.

PAYDIRT!  I hit Gold, or perhaps Oil, and it sure was a gusher.  The amount of information that shows up in a person's story (or a small group's) is tremendous.  As one of my instructors hinted there's untold information in the smallest details.  This is a really simple exercise to execute on, yields a wealth of information, and really gets the people participating with each other.  The next step was to have one person from each group tell their story, and have the participants comment on it.  If you ever need to fill a two-hour block in a workshop, this is a great way to do it.  And the content you get (especially if you are requirements gathering) is tremendous.

   Keith

P.S.  In case you hadn't noticed.  This too is a story.

2 comments:

  1. The last sentence of your first paragraph prompted me to think of this essay by E. W. Dijkstra (EWD 1036) which I read very recently for another reason. It begins this way:

    The second part of this talk pursues some of the scientific and educational consequences of the assumption that computers represent a radical novelty. In order to give this assumption clear contents, we have to be much more precise as to what we mean in this context by the adjective "radical". We shall do so in the first part of this talk, in which we shall furthermore supply evidence in support of our assumption.

    The usual way in which we plan today for tomorrow is in yesterday's vocabulary. We do so, because we try to get away with the concepts we are familiar with and that have acquired their meanings in our past experience. Of course, the words and the concepts don't quite fit because our future differs from our past, but then we stretch them a little bit. Linguists are quite familiar with the phenomenon that the meanings of words evolve over time, but also know that this is a slow and gradual process.

    It is the most common way of trying to cope with novelty: by means of metaphors and analogies we try to link the new to the old, the novel to the familiar. Under sufficiently slow and gradual change, it works reasonably well; in the case of a sharp discontinuity, however, the method breaks down: though we may glorify it with the name "common sense", our past experience is no longer relevant, the analogies become too shallow, and the metaphors become more misleading than illuminating. This is the situation that is characteristic for the "radical" novelty.

    Coping with radical novelty requires an orthogonal method. One must consider one's own past, the experiences collected, and the habits formed in it as an unfortunate accident of history, and one has to approach the radical novelty with a blank mind, consciously refusing to try to link it with what is already familiar, because the familiar is hopelessly inadequate. One has, with initially a kind of split personality, to come to grips with a radical novelty as a dissociated topic in its own right. Coming to grips with a radical novelty amounts to creating and learning a new foreign language that can not be translated into one's mother tongue. (Any one who has learned quantum mechanics knows what I am talking about.) Needless to say, adjusting to radical novelties is not a very popular activity, for it requires hard work. For the same reason, the radical novelties themselves are unwelcome.

    ReplyDelete
  2. PS: Also see this January 6 post on HealthIT.gov's BuzzBlog. An excerpt:

    c) Legacy software in a high-risk environment will evolve slowly – for good reason. One can’t change workflow or user experience too quickly, as changes in the user interface can increase error rates even if the new design is better for new users. Errors can harm or kill people. Developers need to evolve user experience slowly and carefully. Usability won’t improve overnight.

    ReplyDelete