SMEs know the right Keywords

Somewhere in the course of my career, I spent a good bit of time working on "Information Retrieval" projects.  I think my first one was a search enhancer while working for a linguistic software company, but in reality, much of my earlier work experience was also related to building searchable repositories for information.  My Capstone project was also an Information Retrieval project.

And even before that, I was an expert at finding things in books because I could remember WHICH book had the answer, and how to find the right page using the index.

A recent Facebook post I ran across asks: "Badly explain your day job".  I should have responded with the image above.

I suppose part of it is translating questions into Google and Stacktrace queries, but it's not just "JFGI".  A lot of the time it's translating the querant's request into terms that Subject Matter Experts (SMEs) in a particular art would use to answer the question.  I'm not an expert so much of in terms of what I know, so much as in what I know how to find out.  Yes, I have encyclopedic memory of the CDA R-MIM, and a few other things, but I don't keep that on the top of my memory, instead, I know where to find what I need.

The CDA Book came about so that I'd have a list of those things that I need for my work in print form by my desk (and yours).  This blog came about for some of the same reasons.  I know I wrote something about that, where the heck did I put it.

If Web 2.0 is the Semantic web, and Web 3.0 is some Block chain related thing, Web 4.0 should be the translator of simple questions into expert answers, and if we get there, we will also have solved the Touring problem.  Because to do what I do as a significant part of my day job, is to get INSIDE the head of the querent, figure out what they are really trying to do or understand, and then, get the expert answer and translate it back into something that they'll understand ... the Freshman lecture version if possible.

Experts don't always make the best teachers

To be an expert is different from being a teacher.  To be an expert one must amass a great deal of experience in a field.  This allows you to solve complex problems ... standards-based interoperability for example.

To be a teacher is a different mind-set.  Not only must you remember all the amassed experience, but you must also forget it ... or at least remember what it was like when you didn't know the answers, and if you are really good, the moment at which you finally got it, and then be able to convey that to others.

It's taken me ten years and more to become an expert at interoperability, and while I can claim some skill at teaching, I'm far from expert at it.  As I age, it becomes more difficult for me to remember what it was like to not know something.

Experts are often called upon to train others.  What is simple for us we must remember is not so simple for others without our experience.  And that is the critical piece of self-awareness that we have to learn to develop ... to recognize that there's a certain skill we had to develop, or piece of knowledge we had to slot into place in our minds before we could accomplish the "simple" task.

   Keith

What's an Error?

This question came up for me a while back building my first FHIR Server, and it comes up again now.  We're all fairly familiar with exceptions by this point, and logging.

Whether you use log4j2, lockback, slf4j, Java's native logging, C#/.NET logging, et cetera, we all know that there are about 5-7 different levels of logging, from INFO, to WARN, to ERROR and beyond for engineers digging into the code.

There are three kinds of problems depending on the root cause that can result in an exception.  And you probably need to log that exception.  The first two of these problems is an exception that occurs because, well, somebody screwed up.  The last class of problems aren't really problems because you can (and often do) recover from them if you've developed a robust system, either by trying again, or trying a different way.  In these cases, your exceptions are really just that, exceptional cases that need special attention, but the fact that you got the exception was in fact expected.

Even HL7 Version 2 acknowledges that there are two kinds of errors that a message processor can negatively acknowledge (NAK); problems on the application end (AE - Application Errors ), and problems on the other end of the pipe (AR - Application Reject).  The former are problems that the receiving application encounters in trying to process the content that aren't (at least at first inspection) caused by the sender, and the sender might try again later, the latter are problems where the sender shouldn't bother trying again with until they've fixed the problem on their end.

Similarly, in the RESTful / HTTP world, there are 4XX series errors (your input sucks buddy, fix it), and 5XX errors (something's wrong on my end here, sorry for the hassle).

Distinguishing between the two is also challenging, because folks don't always take proper care with error reporting.  Even good frameworks (like HAPI on FHIR), report 5XX series errors, when in fact, the problem is NOT with the server, but with the sender (as happens when you try to call the server with a query parameter that it doesn't support).

And then, how should these be reported in logs?  Should you use logger.warn() or logger.error()? [By no means should you use logger.info(), that's just plain wrong, but I've seen enough of it).

I've got some thoughts on this:
If the "error" occurs because of receiver inputs not meeting requirements of the receiver, and the receiver a) detects it, and b) reports it, this is NORMAL operation of a well running system.  These kinds of issues shouldn't be reported using logger.error().  BUT, the maintainer of that well-running system will want to know that these problems are occurring at the time of detection, and so they should be reported using logger.warn().  In some cases, a high number of warnings occurring at the very least indicates that something is broken downstream that someone (often not the maintainer) should be looking into because things could be done better.  At the very least, this gives the system maintainer an opportunity to help their customer do that (and perhaps reduce burden on the system as well).

If, on the other hand, the problem was detected, and it was something the service expected to succeed but didn't, then it should use logger.error() (at least).  Which brings me to my next question, how do you decide between logger.error() and logger.fatal().  Well, this is kind of like the difference between the engine light on your car, and (should you have one), the oil lamp.  The former reports an error that you can probably ignore for a bit, the latter reports a condition that likely needs immediate attention (or you could destroy your engine).  A fatal error is one that indicates that continued proper operation of the system is at risk, possibly even extreme risk.  Whereas, an error is one that says, hey, under these circumstances, X doesn't work.  But Y and Z might very well continue to work (I made it home 30 miles with a cylinder misfire the other day, but my daughter barely made it 5 miles with no oil in the car).  So, even though cylinder 5 was down, 1-4 and 6 were working well enough that I didn't need to two the vehicle 30 miles to the service station.  I could get it home and drop it off on Monday.  But yeah, that oil lamp left the car dead on the side of the road, and in need of a tow.  So, if the problem is likely to leave a single transaction uncompleted, its an error.  But if it means every transaction for the next hour is going to fail, it's definitely in the fatal category.

While when you log it for your own use, you differentiate, as far as the end user is concerned, it's still an error when you report it back to them.  But HTTP error response codes come to the rescue in identifying where the ID10T is for the error.  So, when you report Errors (on your end) to the end user, you should probably be using 5XX series HTTP response codes, but when you report errors on their end, you should probably be using 4XX series response codes.

Now, what do you do about the last of the three, where something went wrong, but you managed to recover ... say the database connection was lost, but you got another one solidly.  This again goes into warning territory.  In this case, the warning might even go to another log file, because these warnings are things that are causing your system grief.  Bad inputs that you detect aren't really causing you a ton of problems, but recovery from another system's failure almost surely is.  Just think about all the work you had to do just to get retry logic built in the first place.

You might think differently, but well, that's you, and this is me...

     Keith

Sweat the Small Stuff

Small things can sometimes make a big difference.  The difference between an adequate piece of equipment and an excellent one can be huge.  Sometimes the things that you need to change aren't your equipment, but rather yourself.  That's more than just money, it's time and effort.  It's hard.  It's annoying.

The way that small things can make a big difference is when they provide a small but consistent improvement in what you do.  Keyboards for example.  Today I had to switch back to a crappy backup keyboard because the 5 and 7* keys on my Unicomp keyboard died.  I can already feel the change in my typing speed.  More than half my work is typing, and the better keyboard is the difference between 70 WPM and 75 WPM.  That's a 6.667% difference in speed.  It's small, I can live with it for a short period of time.

What will using the cheaper keyboard cost me?  Well, I don't spend all my typing time at top speed, so really, it only impacts 50% of my work. But, for that 50%, that's the most productive time I have, because the other time is meetings and overhead.  So now I'm losing not just 6.667% of my time, I'm actually missing it out of my most productive activity.

Amortized over a year, that's a whole month of my productive time that I somehow have to make up for.  There goes vacation.  All for lack of a minor improvement.  I'll probably get the Unicomp repaired (it's a great keyboard when it works), but I've got a better one on order with Cherry MX blue switches.  They have a similar feel to the spring-switches in the Unicomp IBM-style switches and are the current "state-of-the-art" for typists as best I can tell.  And if it breaks, I can replace the dang switch, which I cannot do on the Unicomp without about two-three hours of effort.

A colleague and I were talking about how making personal changes can help you in your efforts.  His point was that many cyclists spend hundreds (or even more) to reduce the weight of they bicycles by a few more ounces to get greater hill-climbing speed.  He noted that losing a few pounds of personal weight can have a much greater impact (I'm down nearly 35 lbs since January, but my bike has never had a problem with hill-climbing, so I wouldn't know about that).

Learning to touch type was something I succeeded (if you can call a D success) in doing in high school, but never actually applied (why I got the D) until someone showed me that I was already doing it (but only when I wasn't thinking about it).  After discovering that, over the next six months, I went from being a two finger typist to four, and then to eight, and then to ten.  That simple physical skill has a huge impact on my productivity.

I now make it a point, when I learn a new application to understand how to operate it completely without removing my fingers from the keyboard.  And I train myself to operate the applications I most commonly use to learn them that way because it makes a small difference that adds up.  It's an almost meaningless small thing that greatly improves my productivity.  Yeah, I ****ing hated it when Microsoft changed the keyboard bindings in office (and I still remap to some that I have long familiarity with), but I spent the time to learn the new ones.  It ****ed me off for six months, but afterwards it paid off.

Here's where this starts to come into play in Health IT.  We KNOW that there are efficient and inefficient workflows.  We KNOW that changing workflows is really going to yank people's chains.  How do we get people to make even small changes who want to keep doing things the way they always have been?   And more importantly, what is going to happen to those non-digital-natives who have to adapt to an increasingly more digital world when their up and coming colleagues start having more influence.

When we get rushed, we let the small stuff slip.  It's a little bit more time, a little bit more effort.  And the reward is great and immediate, we get more done.  But the small stuff has value.  It's there to keep us from making mistakes.  Check in your code before the end of the day ... but I'll have to take a later train ... and now your hard drive is dead tomorrow, and you have to redo the day's work.  Which would you rather have?

Sweat it.  It's worth the effort.

So, what small thing are you going to change?  And what big difference will it make?

   Keith

* 7 is pretty darn common in hash tags I use, and in e-mails I write.  That's pretty dang frustrating.

Understanding and addressing technical debt

Architects and accountants have something in common, which is that they need to understand their organizations assets and liabilities.  For an accountant, these are fairly understood.  For an architect, one might think that they are as well.  Your assets are you IP and processes that add value, that enable your organization to out-pace its competition.  And your liabilities are those that don't.  We have a special word in architecture for IP liabilities: it's call technical debt.

Technical debt is a great opportunity for architects to benefit their organization, and here's why: it's something that is already costing your organization in terms of resources and credibility.  You can probably count the defects in the package, the tech support calls raised, the number of open customer issues that  are due to technical debt. You can put a very clear value on it, which makes it a great candidate for reducing cost.  It isn't free, but it is often quite worthwhile.

How do you do it? It's pretty simple -- pick a mess and clean it up.  I don't just mean pick the stuff up off the floor either, like your teen would clean their room.  At the very least, polish it like a fourth year recruit at West Point.  At best, remodel, and I mean completely remodel or rebuild -- like Grahame Grieve did for HL7 Version 3 creating FHIR.  The corollary to "if it ain't broke don't fix it" should be "if it keeps breaking, stop fixing it and replace it."  When car repairs exceed the cost of payments, it makes sense to get a new car (unless you are talking about something like a 69 Pontiac LeMans*).

It's painstaking work.  Usually messes like this accrue because code becomes fragile, knowledge gets lost, nobody knows quite how that works (or doesn't).  And yet there is still some underlying value to the code because it does something important and cannot be otherwise expunged, so some extra effort is needed.  It's like the antique in the attic that just needs the right refinishing to become an awesome heirloom.  This is frustrating work, often risky, and sometimes it's downright boring  and tedious (ever read through nearly a thousand different logging messages).  On the other hand, the value of the work can be made very clear and well defined.

The biggest challenge you will run into in trying to take on work like this are people who are concerned about the risks you are taking on. The biggest tool you have to combat risk is knowledge, and sometimes that means making the time to obtain more. The most fragile software components are usually the ones where the least is known about them. Go learn it. In the end, you'll be glad you did, even though getting it finished wasn't the most glorious thing you've ever done.

  -- Keith

P.S. As a teen, I spent the better part of a winter replacing an engine in a 69 Pontiac. It was cold, it was hard, it sucked.  It was my ride to school, and I learned a ton.  It looked something like the picture below, but was black.

Demand Driven Pricing

One of the things we've seen from early warnings about Hurricane Irma is a significant increase in prices in airline fares from some airlines.  Some of this, I'm sure is due to automated pricing algorithms on fares based on demand, for which there may very well be little or no human intervention.

That got me to thinking about how demand driven pricing AND demand driven reimbursement could have an interesting impact on prices for healthcare services IF it were possible to apply them more interactively and faster.

In the battle of algorithms, the organization with the best data would most likely win.  I see four facets to that evaluation of "Best": Breadth, Expression, Savvy, and Treatment (see what I did there?).

• Breadth
  More bigger data is better.
• Expression
  If your data is organized in a way that makes correlations more obvious, then you can gain an advantage.
• Savvy
  If you know how A relates to B, you also gain an advantage.  Organization is related to comprehension.
• Treatment
  Can you execute?  Does the data sing to you, or do you have to filter signal from a vast collection of white noise?

In the 5P model of healthcare system stakeholders, Polity (Government), Payer, Provider, Patient, and Proprietor (Employers):

1. Who has the largest breadth of data? The smallest?
2. Who has the best expression of data? The worst?
3. Who has the greatest savvy for the data? The least?
4. Who will be most able to treat the data to their best advantage? The least?

It seems pretty clear that the patient has the short end of the stick on most of this, except perhaps on their "personal" collection of data.

Payers are probably in better shape than others with regard to breadth, followed closely by Polity. The reason I say that is because government data is dispersed ... the left hand and the right hand can barely touch in some places.  Providers rarely have the breadth unless they begin to take on the Payer role as well (e.g., Kaiser, Intermountain, et cetera).

Providers have a better chance of having better expression, being able to tie treatment to condition in more detail, and have some chance at understanding outcomes as well.

It's not clear that employers are THAT much better off than patients, although frankly I honestly don't know how much information they really have.

Treatment is where it all comes together, and right now in the US, it seems that nobody has yet found the right treatment ...

Anyway, it's an interesting place to explore further.

   Keith

Or Leave the Tricky Bits to Me

One of the things that I really enjoy about my job is when I get to play with something particularly challenging, and as a result come away from the experience with a better understanding of how things work, or a better process model.

Often times, code gets away from us as developers (same is true with standards).  If you've ever had one of those situations where, as an engineer, you found yourself in the position of having developed a piece of software from the middle-out, you know what I mean.

Middle out solutions are where you have a particular problem, and basic principles are simply too basic to provide much help ... and details are sometimes rather nebulous.  I just need to fix this one problem with ... fill in the blank.  And so you find a way to fix that one problem.  Except that later you find an odd ball exception that doesn't quite fit.  And then there's another issue in the same space.

After a while you find you have this odd mess of code that just doesn't quite work because you came at things the wrong way.  And then some thread comes unwoven and it stops working altogether .. at least for that thing you cared about right now.  That thing somehow was important enough (unlike the rest of the work) to make you take a step back and try a different approach.

Somewhere along the line you took the lenses and flipped them around so that now you can see the forest instead of the trees, or vice versa.  And now that strange jumble of code begins to make sense all over again, fitted together in a different way, to your new model of understanding.

That's what I like about my job.  When that happens.


   Keith

Wearing Many Hats

When I first started working with ANSI/HITSP over a decade ago, one of the things I remarked upon to several people was the outstanding ability of John Halamka to wear many hats, and to make it clear which hat he was wearing when he was speaking, and his general ability to be wearing the right hat for the right audience.

It's a tricky challenge, and quite a juggling act.  I don't do it nearly as well as John does, but have been doing it a great deal over the last 18 months.  These are just a few of them in approximate rank order based on time investment (though not necessarily personal preference):

1. Patient Advocate
2. Architect Owner
3. Product Owner
4. Subject Matter Expert [Health IT Standards & Regs]
5. Informaticist
6. Software Developer
7. Engineering Manager
8. Thought Leader
9. Student
10. Teacher
11. HL7 Board Member
12. HL7 Member
13. IHE Member
14. Document Writer

I often find my various hats being at war with each other.  My software developer side wants to argue with my SME side, or sometimes I find my IHE side needs defending from one of my HL7 roles or ...

When that happens, it is very challenging to understand how to resolve the problem.  The pragmatist and the purist at war is not pretty.  Purism has its place, as does pragmatism.  Perfect is the enemy of the good goes to battle against applying the time to do it right as compared to the time to do it over.

How do I resolve this?  I've begun to discover that the final hidden role is that of customer advocate. That jumps to number 2 on my list.  Where Patient Advocate cannot break the tie or bring peace, Customer Advocate often can.

What roles do you play?  How do you reconcile them?

Thanks to That Person

In my first computer class, we entered our programs using a line editor, and unless we were unlucky, had a CRT to work with (although the unlucky still go stuck with the linotype).  We had a text book, some well thumbed compiler manuals on a bookshelf that were shared among the many students, and there was always, somewhere, that guy (or less often but still present, that girl), who soaked it up and knew the answers to the real tricky stuff.

As I moved into the workplace, we had CRTs still, but some had graphics capabilities, there were still tons of manuals on our shelves (and for most of us, we each had our own copy).  If you were one of the lucky ones, you got graphics.  The manuals were less well thumbed, and somewhere in the office, there was that guy (or more frequently, that gal) who knew how to find the answers.

Later, we all got to move up to 16, then 256, then 16384 colors, with 640 x 480 resolution, and then 800 x 600, and if you were one of the lucky ones, 1024 x 800 displays.  Email came to the fore. Manuals were still handy, yet there was still that person.  Sometimes they'd be in another office. You'd pick up the phone, or send them an email.  After two or three forwards and days, or more depending upon the challenge, the e-mail would come back with the answer.  And because that person had email, if they didn't know the answer, they at least knew who did.

And then came the Internet, and CD drives.  Instead of a shelf of books and a file drawer full of disks you saved because you just might need them again, there was the almighty CD.  And books were fewer.  And if you were one of the lucky ones, you had INTERNET!  And that guy or gal might be a half-continent away, and e-mail was reliable and you'd only need to way a few hours.  And he or she probably had Internet, at least at home, because they still sucked it all in, and knew where to find the answer, on the Internet, or on the CD.  Of course, you still had a drawer full of CDs, but at least it was a normal one instead of a file drawer.

Now we have StackTrace, and web sites, and volumes of data.  You can ask Google or Bing. Training is online, complete with slides and audio. that person has a blog, and a twitter account or a linked in, or all three. You no longer need to be lucky to have a laptop, though if you have a touch screen or tablet, you can probably to count yourself among the lucky.  You can read what that person has to say daily, or even listen to them or better yet watch them. That person now has fans.

I'm a fan of lot of people out there.  You know who you are.  I couldn't this person without you being that person.  Thanks.

-- Keith

Refactoring Standards

Code and standards (which are a special kind of code) grow with age.  When you started with your code, you had a plan.  It was fairly simple and so you wrote something simple, and it worked.  After a while you realized you could make it do something special by tweaking a little piece of it. Sometimes (if you designed it right), you can add significant functionality.  After a while, you have this thing that has grown to be quite complex.  Nobody would ever design it that way from the start (or maybe they would if they had infinite time and money), but it surely works.

The growth can be well-ordered, or it can have some benign little outgrowths, or they can even be tumorous.  Uncontrolled growth can be deadly, whether to a biological or a computer system.  You have to watch how things grow all the time.  After some time, the only solution may be a knife. Sometimes the guts of the patient will be majorly overhauled afterwards, even though fully functioning and alive.

When the normal adaptive processes work in standards, these growths naturally get pruned back.
It's interesting to watch some of the weird outgrowths of CCR become more and more vestigial over time through various prunings in CCD and CCDA.  FHIR on the other hand, well, that started as a major restructuring of V3 and CDA, and is very much on the growing side.

   -- Keith

Principle Driven Design

When you need to get something done quickly, and it's likely to involve a lot of discussion, one of the tactics I sometimes take is to get everyone to agree upon the principles which are important to us, and then to agree that we will apply those principles in our work.

It's quite effective, and can also be helpful when you have a solo project that is confused by lots of little different relationships between things.  If you work to establish what the relationships are in reproducable ways, and connect them, what you wind up with is a design that goes from a set of principles ... or even, simple mathematical relationships.  And the output is a function of the application of those principles.

It works quite well, and when things pop out that are odd, or don't work out, I find they are usually a result of some principle being applied inappropriately, or that your data is telling you about some outlier you haven't considered.  When HL7 completed the C-CDA 2.1 implementation guide in 6 weeks (a new record I think for updating a standard), we applied this tactic.

Having spent quite a few weeks dealing with the implementation details, I can tell you that it seems to have worked quite well.  And my most recent solo foray into obscure implementation details was also completed quite quickly.

   Keith

Other People's Stuff

Everyone likes to use their own toothbrush.  We know where it has been, and it fits our hand perfectly.  Someone else's toothbrush is just, well, ick!

The problem with standards is that they often have that "other person's toothbrush" feel to them.  It's not the way I'd do it, or I don't understand why they did X when clearly Y is so much better.  It takes a while sometimes to overcome that icky sensation of putting that thing in our mouth.

Eventually, if we keep at it, it becomes ours, to the point that we might actually find ourself facing the very same challenge trying to convince others to use what has now become "our standard."

It is certainly a true statement that trying to learn something new, or use something different that we are accustomed to is hard.  "I don't have time for this, why can't I just do what I've been doing?" I hear.  In fact, you might actually not have time.  But you may also be missing an opportunity to learn from what others have done.  Only you can decide which is more important.

Standards is all about using other people's stuff.  Few people are in a position to craft standards, many more are in a position to use them.  If, though, after asking yourself the question of "Is this the stuff I need to be worrying about, or is something else more important?"  you come to the conclusion that there is something more important to be worrying about, consider whether using other people's stuff might benefit you, so that you can move on to that more important thing.

It's always easier to understand what you did on your own, rather than to comprehend someone else's work and logic.  But that logic and rationale is present.  If you learn the knack of it, you can do awesome things.

   Keith

Changes

Ch-ch-ch-ch-Changes (Turn and face the strange)Turn and face the strainCh-ch-ChangesDon't have to be a richer manCh-ch-ch-ch-ChangesCh-ch-Changes (Turn and face the strange)Don't want to be a better manTime may change meBut I can't trace time -- David Bowie

I'm more than six months into my new position, and there have been a lot of changes over the past few months.

I dropped my eldest daughter off at college last week.  I still haven't adjusted to that.  I found myself wondering at 4:00 today why she wasn't home from school yet.  Oh yeah, I reminded myself.  November for Thanksgiving.

Next week I finish my last class in my Masters in Bioinformatics.  That and turning in my final capstone paper are all that stands between me an my degree.  I've learned a lot over the last three years in that program, and I cannot recommend it highly enough.  Bill Hersh has put together a great program at OHSU.  Whether you go for the certificate, the masters, or even just the 10x10 program, it's all good stuff.

My standards work is slacking off as my implementation work is picking up.  I'm principle architect for three teams working on Interoperability stuff.  I wear three hats. Some days I'm an architect, others a product manager, and others, an engineering manager.  Some days I do all three, sometimes at the same time.

My schedule is split between three time zones, the usual left-coast right-coast for the US that has been the norm for most of my life, but now also about 4 hours in the middle of the night (12am -4am) Bengaluru time.  I sleep when I'm tired, which is not as you would expect to be "most of the time".

I still struggle with what I want to be when I grow up, forgetting that since I managed to reach 50 without doing so a couple of years back, I don't actually have to grow up, and I have a certificate from my family to prove it.

I suppose that some day when I retire, I will want to teach full time, rather than spending about a third to half of my time doing that.  What I think that really means is that my projects will become my students, rather than having students because of my projects.

Now if I could just figure out how to get the next six things done that I need to before the day is over, without moving to somewhere like Mars, or worse yet, Mercury or Venus.

   Keith

A Review of the iPad Pro 12.9"

Every year I get myself a present with my annual bonus (in years that I get a bonus, which has been most of them in my career).  This year, I decided to replace my quite functional iPad 2 with an iPad Pro.  I had several reasons for upgrading, one of which was to make sure that my mother would be able to enjoy my wife's iPad (she got my old one, and hers went to my mother), and because I wanted the bigger display and the multitasking support.  I'm often trying to do two or three things at once.

What I like:  The bigger foot print means that it is easier to read and operate.  My high score on one of my video games went up because I can be more precise with the larger display.  And my aging eyes like the bigger screen for reading, which I use my iPad for quite a bit.  It's also easier to see the map while driving.  The multitasking isn't quite all I could ask for, but it beats what I used to have, which was nothing.  I also like what the bigger display does for helping me to manage my schedule.

What I dislike: The bigger foot print means that it is harder to carry around, and nearly impossible to use one handed.  I think I need a different case to be able to use it nearly the way I used to use my iPad while I was moving around on foot.  I use my iPhone now for mapping my way through the city while walking, and I don't carry it around with me everywhere.  That actually is a bonus, because I'm less likely to bury myself in it at the dinner table though.

I haven't spend any money on the pen or a keyboard case, I already have two blue-tooth keyboards that will work with it (I recently acquired a slim blue-tooth full sized keyboard for my travel set up). I may get the pen later just to play with it.

I put it in a Targus case very much like the one I use to have that I finally wore out, and am quite happy with the case, but am still getting used to the fact that the fold is about 1/3 the way in the back, which means I don't use it physically the same way as my old case.

The form-factor is different enough that my use of the device is different, but not substantially so for my needs.  Overall, I think I like it, but kinda wish I'd gotten the smaller iPad Pro in the original form factor that I've been accustomed to.

I'm probably going to spend some time playing with it as an external monitor for my laptop, to see how well that works for me.  I'm presently carrying around an AOC external USB display when I travel that has more screen, but less pixels.  Using my iPad for that could shorten my treck through airport security.  At least once over the past two weeks I had five bins filled through the TSA line, using my iPad for the same purpose could drop that by two, and get my travel computing back into one bag.

   Keith

In the Rough

The thing I like about coding is that at its best, it is a fluid way to solve problems.  The best code to work on is the crux of a solution.  The scaffolding is boring.  The shell and outer layers is finish work.  I can do a craftsman-like job on it, but frankly it is boring.  The fun is in figuring out some new way to solve a tough problem, and what I really like to work on is the heart of the problem.

I think the most fun for me is teasing out the solution.  Often I feel as if I can see in my minds eye how the solution is hidden behind or within a rough crystaline structure.  I look at it, pick it up, turn it, shine light on it from different directions, see which way shadows are cast and more.  At some stage, I catch just a wee glimpse at the right angle, and that narrows down some options.

Eventually, I see just enough to know where to put the knife, and cut.  And cut again.  When I started I had only a small clue of the basic shape, but when I finish ...

Image via Smithsonian.com

The Nightly Dumb

There's a design pattern that is often used in healthcare, and in other enterprise integrations with legacy that involves a nightly update.  What often happens is that a days transactions get aggregated into a single big file (by taking a dump of the days work -- which is why it is called the nightly dump).  Then this single big file is sent off somewhere else to be processed.

It's a convenient design.  It doesn't have to deal with transactions or locks .. the days work  is already done and nobody is using the transactional system.  It won't impact your users, because the day's work is already done and nobody is ...
Batches of stuff can be processed very quickly because the days work is ...

You get the picture.

This is such an often used design pattern, and for some reason, it just feels wrong to be so widely used.  There's a heuristic being applied ... that at the end of the day, the day's work is done, which we know isn't really the case.  There's always that one record or two which we never got back to which needs to be updated.  Yet we often act as if the heuristic is in fact a law of physics, only to discover to our chagrin that it is not, and we need to account for that in our processing of the nightly dump.

Often times when I see this pattern in use, I question it.  The answer I typically get is "this is more efficient".  And yet, I wonder, is it really?  Is it more efficient to wait to send something?  Or is that a premature optimization?  Is the delay between sending it, and subsequently finding a problem with it that needs to be corrected really the best way to handle this situation.

One thing I can tell you. The nightly dump is interfacing, not integration. When you have to wait 24 or 48 hours for the nightly dump to have taken place before another system can act on what was done elsewhere, someone is bound to notice somewhere.  And when they do, they are sure to start swearing.  Because at that point, the nightly dump will basically feel as if someone just took a dump on them.

   Keith

P.S.  In case you were wondering, yeah, I just got dumped on.

Pilot Error

Tails of failure often involve a sequence of multiple errors, each of which by itself is not fatal (or in this case, vaguely comedic), but which together produce a totality that is hard to fathom.  I was reminded of this today when I went to register for the last class I need to complete my degree program, only to find out that it is on-campus only.

1. I've been checking for the last three terms that I knew what I needed, AND
2. Knowing also that scheduling can sometimes change, I did my best to get as much out of the way as I could up front, AND
3. seeing that I had one dependency I couldn't meet last term, I checked with the instructor to be sure that the class was to be offered this term, AND 
4. received confirmation ...

BUT,

1. I failed to check that it was going to be available online, AND
2. The syllabus I read was out of date, AND 
3. I failed to notice that the syllabus was out of date, AND 
4. I missed the wee bit in the course catalog noting it was offered online only in odd years.

I have two hopes left... I'm wrong, or I can do something else. And, no matter which happens, no babies die if I don't graduate the same year as my eldest, so I'll live either way, and still graduate, just a little bit later than I wanted to.

Gah, Pilot error.  Or in other words, the person most responsible for making sure things lined up the way they were supposed to failed to accomplish that, in part by failing to note other errors or discrepancies in data available.  In this case, I'm the pilot, and guess what, I'm human too.

In healthcare, we often rely on the physician to be the pilot ... but she or he is only human as well, and on a bad day is likely only to perform as well as the systems and people that surround him or her. Design for humanity ... design for error, and the world will be a better place.

   -- Keith

Investing in Automation

I've been burning the midnight oil these past few weeks to automate a workflow that had I executed it manually, I would probably be done by now.  The compensation for automating this workflow, at least in terms of my time works out to have not been worth my investment -- at least if I'm just counting my time.  But...

1. Eventually, this will allow me to offload a piece of work that right now, in a manual task, only I (or someone similarly skilled) can do, to enable someone less skilled to do the same thing. Given that there are about 500 people like me with that specific set of skills in healthcare, that's really useful.  I don't scale up (something we've all learned by now).
2. I now much better understand the task being performed, and so can find ways to improve tasks leading up to it in terms of consistency, so as to make the automation much less complex.  That process knowledge is really useful, and I can apply it not to just this process, but to many others like it.
3. I now have a written, and repeatable record of what actually has to be done to perform the task, in a way that I can actually exchange with someone else, and they might benefit from that to. And many of the things I've learned how to do can also be applied to other problems.
4. The intellectual challenge in automating this workflow is SO much more interesting and intellectually stimulating than the hours of copy and paste work that I would have been otherwise doing.  So my boredom level is lower, but job satisfaction is higher, and as a result, my overall quality and outlook on life is much improved.
5. My rather accurate, and repeatable description of the process (in software) is something that others can also improve upon.  I'm certain (because I don't write code every day -- well, mostly not when, oh, OK, so I do write code every day, but not for production use -- except ...), well anyway, I'm still certain that someone could improve what I've written.  Including me a few years later ...

So add all this up, and what I get is a useful piece of code, several hours spent doing something more interesting that stupid and mindless repetition, a better understanding of the process, and most of all, job (or in this case, school) satisfaction.  And eventually, this work will amortize itself, just not for me.

This, I think, is what makes developing software so interesting for some people. There is so much intangible value here, over and above what my time investment does for me.

There's a certain satisfaction I also get from teaching, so what is more satisfying that teaching the stupidest thing in the world (a computer) how to do something almost human, and have it do it successfully.

   -- Keith

P.S. In case you were wondering WHAT I was writing, it was the metadata indexing algorithm for by Pubmed for Standards project.  Embedded in that algorithm is a great deal of knowledge and process I didn't even know existed when I started off on this effort.

Finding the problem is ONLY the first step

There's something just not right with this model. I don't know what it is, but ... It niggles at the back of my brain. It doesn't work.  It's missing these properties that I expect, but I don't know how to get them out of it, or bake them into it.  And I should... it's just math.

I fuss and fight with it, and finally, I see what I'm missing. It should have been obvious all along.  I no longer wonder about what is wrong with the model, but now have to go and fix it.  I don't know how to do that yet, but I know where I can go find out.

Sometimes finding out what the problem doesn't immediately lead to a solution, but it's a good first start. Now to go find some more magic smoke.

    -- Keith

der's yer problem, yah let ahl der smoke out pic.twitter.com/pV2uXq2hdV

— Keith W. Boone (@motorcycle_guy) December 2, 2015

P.S. Technology is just like normal stuff this way.  The other day I headed out for an appointment, but the bike wouldn't start (and my eldest had the truck). It's cold out I thought... battery probably needs to be put on the trickle charger these days.  So I was going to roll it down the driveway and start it that way, but it wouldn't roll easily.  Thinking I was in gear, I turned the key on (there was enough juice to operate the controls, just not enough to start it), but was in neutral.  I checked more closely, and sure enough the rear tire was flat.  Must be a slow leak I thought, have to fix that, let's grab the compressor to put air in it.  Picked up the compressor and the handle broke off the plastic hose.  So I cancelled my appointment, fixed the compressor, started to put air in the tire, found that air was leaking out the valve stem.  Tried to find a valve stem online, failed.  Called the shop, they explained that the valve is attached to the tube (not a tubeless tire as I'd though), and so I arranged for them to come get it and replace the tube.  I could do it myself, but I got other stuff people pay me to fix (like the problem above) so that I can pay others to fix my stuff.

Just Proud

What is it about age that makes us proud of our youth?  Over the last week I've had several opportunities to be proud of the accomplishment of others.

I'll start first with my youngest daughter, who overcame several setbacks this summer to brave her way through 20+ hours a week for several months of practice and rehearsal and 2-3 competitions each weekend to finally win (along with her classmates) the title of USBANDS National marching band champions.  That's just a proud dad talking.  To the left is a video of the band arriving home from their victory.

Then there's the team of students I taught Interoperability and Standards to this summer; whose class project sailed through IHE Patient Care Coordination for implementation in the 2016 - 2017 season. That's just a proud TA talking.

Then there's the team of students (see image at the right) from Heilbronn University who won the FHIR DevDays student competition.  I have no reason to be proud of them except that they did something cool with FHIR. That's just a proud co-developer talking.

Then there's the team of OHSU Informatics students who won the AMIA student competition, giving OHSU two wins in two years.  That's just a proud alum talking.

Then there's the four high school students who presented at AMIA.  I have no excuse to be proud of them, other than I see something in them that maybe I had at their age, or perhaps just wished I had at that age.   I guess I'm just proud to see others succeed.