Five places you need a Programming Language

This morning while flipping through my "newspaper" (an eReader), I ran across this short video by Bjarne Stroustrup talking about The Five Programming Languages You Need to Know.  Bjarne is acknowledged to be the father of C++, and so clearly C++ was going to be on his list.  But what I found disappointing was that the rest of his list mostly included the C family of programming languages.  You know, C, C#, Java, JavaScript, et cetera, with maybe one exception.  Did he never access a database?  Larry Wall (inventor of Perl), had a slightly better take, but I still think it was pretty limited.  Even expanding the list to 10 languages gives what I think is a very weak picture.

I know far more than 10 programming languages.  The last time I updated that section of my resume (in 2006), I cut it back to 10 from the original long list I had.  Nobody cares these days if you know Pascal (or if they do, you don't want to work there).

One thing that eWeek had right in its list of 10 languages was that they have different purposes, and their list only addressed application development.

1. Application Development
   This is the basic stuff, of which the eWeek article, Bjarne and Larry are talking about.  Included here is C, C++, C#, Java, PHP, Perl, Ruby and a lot of others, including old stuff like Fortran, Cobol and some newer stuff like Erlang, and various esoterica like Haskel, Scheme and Lisp.
2. Data Management and Query
   For the most part, SQL, although these days thinks like XQuery and Sparql are much more interesting, but also esoteric.  With SQL, dialect variations between Oracle, MySQL and Microsoft SQL are almost as important as the various C family variations under application development above.
3. Web Applications
   HTML, CSS and JavaScript are the bare minimum here.  Then there's ASP, JSP,  (PHP really belongs here as well), ColdFusion and the whole host of other scripting frameworks.  And then there's also XSLT that almost deserves a section of its own.
4. Scripting Interfaces
   JavaScript, VBScript, CoffeeScript, Drools, Caml, and a ton of other languages.  These are principally used inside applications to do INTERNAL application automation and to build interfaces.
5. Application Automation
   External application automation is mostly an exercise in various shell scripting languages, back in the days the major interpreter was COMMAND.COM (DOS), now CMD.EXE (Windows).  Those learned some of their syntax from various Unix shell scripting languages, including sh (the Bourne shell), but there's also the C-shell and bash and many others.  My Unix days are quite dated. There are some other scripting languages (awk was an old favorite of mine).  Application build tools have a language all their own, and can also be used to automate application behaviors from the outside.

Any software engineer who's worth their salt can claim not just 5 programming languages, but probably five from each of the above categories with the possible exception of Data Management and Query.

ONC S&I Data Access Framework

This just showed up in my inbox. It looks like ONC is finally catching up after the latest Whitehouse meeting.

   Keith

---

 Call for Participation

Office of the National Coordinator for Health Information Technology (ONC)

Data Access Framework Initiative

ONC is pleased to announce the launch of a new S&I Framework Initiative, Data Access Framework, on Tuesday, July 16^th from 12:00-1:00pm EST.  This initiative will focus on the standards and framework necessary for clinicians, providers and healthcare professionals to gain access to patient data within their own organization and from external organizations which may contain patient data.   On behalf of ONC, I am pleased to invite your valued participation in the kickoff of the Data Access Framework Initiative.

As the nation moves toward an Electronic Health Records (EHR) critical mass, the ability of healthcare providers to access their patients’ data presents multiple challenges. These challenges include the lack of standard interfaces in which to access data from the organizations’ EHR and a limited set of standards to use when accessing data from external organizations.
 Giving healthcare providers a standard way to access patient data helps improve healthcare quality, which includes improved patient outcomes.  The Data Access Framework will be addressing among others, the following questions:

• Who – who is accessing the data? 
• What – what mechanisms will be used to access the data?  what data is accessed?
• Why – why are they accessing this data?

The goal of this initiative is to leverage existing standards to create a modular data access framework based on the identified business requirements of the community.
The official launch of the Data Access Framework Initiative will be held as a web meeting and teleconference on Tuesday, July 16^th, 2012 from 12:00-1:00 pm EST. Details on the Data Access Framework launch including web meeting access, call-in information, reference materials and the Project Charter are posted on the Data Access Framework wiki.

If you would like to participate in the Data Access Framework Initiative, please review the documentation on the S&I Framework wiki:  http://wiki.siframework.org/Getting+Started+as+a+Volunteer.

Once you have read through the material regarding participation, levels of commitment, guidelines for participation and voting rights,  please sign up to participate in the Data Access Framework Initiative by completing the registration form on the Data Framework Access Join Page.

Your experiences, thoughts, expertise and solutions are critical to the success of this initiative.  We look forward to your participation and getting to know you as part of this new initiative.

John Feikema, Coordinator, Standards & Interoperability Framework - Initiative Coordinator
Mera Choi, ONC Lead, Standards & Interoperability Framework

Office of the National Coordinator for Health IT

What is in a name?

I hardly ever get worked up about what you call some things (whereas I really care about others).  It's not my job to name things, or at least the things that aren't important, like what you'd call a product or service that you are selling.

The discussion I found really amusing today was on the "Is HIE a noun or a verb?"  It really depends on what you are selling I would guess.  If you "are" an HIE, then you are selling yourself, and the services provided by your organization, so you'd probably fall on the noun side of this debate.  If, on the other hand, your customers are "HIE" (noun form), or others who need exchange services, then you'd probably fall on the "verb" side of the debate.

Linguistically, the phrase "Health Information Exchange" parses ambiguously as either a noun or a verb.  The first two words "Health Information" are descriptive of either the kind (of noun), or the subject (of the verb). And exchange itself is ambiguous. As a verb it is the trade of information.  As the noun, it is the act or place where such trades occur.

Does it matter what "we" agree on?  No.  The word will still be ambiguous because usage creates definitions, not the other way around.

One of my followers pointed out that Name = Brands = Function = Market, and referenced Kleenex, Ziplock, Web, Chapstick, Coke and Sharpie.  I'll point out in response that it was the product that came first, then the name recognition that established the brand and subsequently the market.  While the name was important, what made the name successful was the product it was applied to, NOT the other way around.

Arguably, a bad name can kill a good product or service.  But I've never seen a good name save a bad product or service.  In fact, a bad product or service can kill a good name.  Did you see what happened to United stock when they broke his guitar?

Don't worry about the name.  Worry first about the product or service.  Even a silly name can become a great brand, but it never would have happened if the product hadn't tasted so good.

Failure has to be an option if success is to be Meaningful

Anyone familiar with one of my favorite TV shows:  MythBusters has probably heard the expression "Failure is always an option".  Co-host Adam Savage indicates that the principal behind this is that you learn from what you are doing, whether or not you succeed.

Compare that attitude with this most recent report to cross my twitter feed: Alarming Fact: Meaningful Use Dropout Rate at a Staggering 17%.

That 17% figure is staggering only if you aren't thinking about what it means.  17% of early adopters have decided to take an implementation break.  For some of them, that may be a signal that they are giving up, and for others, it might be a well considered strategy to ready themselves for the next stage. As I recall, Meaningful Use is forgiving for early adopters, allowing them to take a year off and still get the entire $44K reimbursement.  Of those 17%, I wonder how many are doing that?

We don't know because that isn't reported in the CMS attestation figures.  You'd have to ask providers what their intentions are.  There's another report that does just that, and finds that 14% of providers attesting to Stage 1 do not intend to attest for Stage 2.   Unlike the author of the first article, I don't find the conjunction of the two findings to be "even more alarming", since the second report simply confirms the results of the first, that somewhere around 15% of providers won't be moving forward (at least as far as incentive $$$ goes) into Stage 2.

Who are we losing?  The only group that this information can be readily applied to is early adopters, because those are the only providers who could have been doing MU Stage 1 for 2 years at this point.  So, my inference here would be that early adopters have a high failure rate.  The author of the first report is concerned because those are also the most experienced.  Another possible explanation here is that it was the ones who tried to be an early adopter but weren't the most experienced who dropped out.  Another possible explanation was that is was the specialty providers for whom Meaningful Use (especially Stage 1) wasn't a great fit.  There are a lot of unscary possibilities, and also some scary ones.  We need more data to evaluate.

Even so, I'm not really all that worried about the Meaningful Use program, and here is why: If failure isn't a possibility, we aren't pushing hard enough.  Failure has to be an option before success is at all meaningful.

   Keith

Principles for Standards Selection

In a discussion earlier today, the topic of principles for standards selection came up.  In determining principles for selection of standards, the first thing to realize is that this is not principally a technical issue, but rather one of policy and governance. The following factors influence choices between standards:

• Cost
  The cost to implement a standard can be measured in currency (e.g., USD) or time and effort, or a combination of both. Costs incurred may involve upgrading or retooling existing systems and infrastructure, licensing fees, or acquisition of new products to support the standard.
• Suitability to Purpose
  Suitability to purpose is a measure of quality of the standard with respect to the purpose to which it is being used. This factor addresses “functional” requirements. A standard that is ill-suited to a particular (not designed for) purpose may still succeed, however, it will likely not have the same return on investment. Using a standard that is perfectly suited to a specific purpose does not guarantee success either though.
• Availability
  Availability is most closely associated with cost and suitability to purpose. A standard that is “perfectly suited” to a particular purpose, but not widely implemented will cost more to deploy than one that is already available in existing products.  Availability is often a better measure than costs or suitability alone because it allows the market to find the right balance between these two factors.  Availability is not just with respect to "this instant in time", but also addresses the future.  You may choose a standard because even though it isn't widely deployed now, it is expected to be in the future.  That's a choice based on availability.
• Standing
  The standing of a standard addresses “non-functional” issues regarding the “quality” of the standard. These often have to do with how the standard is developed, it's "openness", its structure, the methodology used to develop it, or its recognition by other bodies (see also alignment with other policies), and its current buzzword compliance.  Common questions addressing standing are: Is it developed by a consensus-based standards body? Who maintains it? What other organizations use it?  Is it Service Oriented?  Is it RESTful?  Sometimes questions of standing overlap with ones of policy alignement.
• Alignment with Policies
  Policy alignment addresses issues with whether the chosen standard is aligned with, against, or without interfering with other policies. An alternative way to look at it is whether the choice of standard would be impacted by a change in policy. Some choices are “policy neutral”, that is, choosing those standards neither advances, nor interferes with implementation of a specific policy. 

Balancing these factors is necessary. No single factor always takes precedence in decision making about terminology (or any standards for that matter).  However, there are certain principles that can be reasonable developed:

1. Pay Attention to Policy
   Making standards choices which fly in the face of recently established policy is not a good idea. However, there are some fairly narrow lines to be navigated here.  Rarely is it the case that the policy being aligned with is directly related to the purpose for which the standard is being chosen (because if it was, the policy would simply be applied and there wouldn't be a choice of standard to begin with).  A perfect example of this in the US is the selection (by policy) of ICD-10-CM for diagnoses in administrative transactions as compared to the selection of SNOMED CT for clinical content.  In this case, "suitability to purpose" trumped policy alignment.
   When there is a policy, or a policy making body already charged with making choices in the area where the standard is needed, it is wise to consult with them.  You might not agree (I've been known to take issue with some of our national policy making bodies), but at the very least you need to consider what they are doing when making your choices.
2. Where do you stand on standing?Figure out what is acceptable and what is not?  Must it be developed by a consensus-based SDO?  Is formal governance necessary?  Is International necessary, or is National good enough?  Do you like HL7 and hate IHE (or vice versa).  These are all decisions based on standing.  Use this to set the boundaries between what is acceptable and what is not, and don't let it further influence your decision making.  Realistically, the "fine detail" it isn't a huge factor when you go to implement.  Frequently, fine detail is simply an excuse to exclude one body or another, especially since there are few ways those details can be measured by anything other than subjective criteria.
3. Cost at the start and the end.Issues of cost should be addressed at the beginning and the end of the discussion. Ignoring all other factors, how much does cost matter? If the answer is that you have no budget to acquire the standard (or license to it, or whatever it is you need to use it), then free becomes the only possible answer.  And again, at the end, having considered all other factors, which path will cost the least?  Like "standing", let cost set boundaries.
4. Focus on Suitability to Purpose and/or AvailabilityIf you are in a green field, go with suitability to purpose. In a brown-field, you have to decide whether "status-quo" is acceptable or not.  If the status-quo is acceptable (and you like it), focus more on availability.  If not, focus more on suitability to purpose.  That doesn't mean you should ignore one or the other, you simply need to decide how much weight to give it.

The choices you make for one project will differ from those you make on a different one.  Even within the same project, you might make a different set of choices because of where you land on the acceptability of the status-quo.  After you've made all of these decisions, then you can get down to the business of making technical choices, but usually buy now, your choices have been narrowed down to one or none already.

Evaluating Open Source Software for HealthIT

This post is about learning how to fish.  I don't plan on providing dinner ;-)

There are a number of different open source software (OSS) products available that support IHE and HL7 profiles.  Some of that is used by widely known hospitals, integrated delivery networks, or health IT vendors.

How can you tell which OSS components are worth looking into?

1. Who is working on it?
This is a big tell.  There are several IT vendors which strongly support OSS initiatives and basically staff open source projects with small teams.  The affiliation of the OSS project committers will often tell you what organizations are backing the project.  If you can also find evidence that they use the OSS in their own offerings, then you have an even better signal.

2. Recency of Updates?
When was the project last updated?  How frequently do they ship new releases?  A project that ships new releases 2-3 times a year for the past six years is much more viable than one who has only two releases in the same time period.

3. How big is the team?
Are you dealing with OSS developed by one person, or is this a team effort?  Don't get me wrong.  Really good OSS can be developed in a one person effort, but not everyone is a James Clark (a well known contributor to OSS in the SGML world).

4.  What does the defect tracking system tell you?
If there isn't a defect tracking system, walk away.  If defects have been reported but nothing has ever been done about them, walk away.  If there are a bunch of defects reported, that's almost surely a good sign.  You can find out at least two things from defect reports: Who uses the OSS product, and how responsive the team is about the defects.  Fixes may not happen overnight, but if defects are responded to quickly, that is a good sign.  Response need not be a problem resolution.  Some problems can take a long time to fix.  But at least the initial assignment and analysis should be fairly quick.

6.  How many other OSS projects rely upon it?
In my own list of Open Source XDS implementations, the IHE Profiles project under Open Health Tools really stands out because there are about a half dozen other OSS projects I've run across using one or more of its components.  Similarly on the CDA side, there are four different projects that I can think of that are making use of MDHT.

7.  Finally, has it done any public testing or certification?
Testing and certification are fairly extensive undertakings.  Few OSS projects are well enough resourced enough to undertake such efforts.  Those that do are worth checking out.  For example, OHT attended an IHE Connectathon in 2010 and tested a dozen profiles.

With a little bit of digging, you can readily identify the best open source projects to use, and figure out which ones are keepers, and which should be thrown back to grow some more.

The Calm Before...

I have no great wit to share today, just quiet.  I'm looking forward to my vacation this summer.  At the same time, it leaves me with precious little time to finish up several projects that need to be ready before I go.  Even so, at this stage, the only projects that I'm working on are ones of my own choosing, not those that others have subjected me to (or at least at this stage, my subjugation to those projects is now complete).

We'll be spending a week+ in England this summer.  I'll be meeting my family there on the way back from another international trek.  I'm looking forward to spending a week and more in the home of Shakespeare and Doctor Who.

And when I return, I'll have barely enough time to head to Chicago and Montreal in the same week for IHE and HL7 meetings. Somewhere in the coming weeks I need to find time to update a book chapter, and if all goes well, start a grant project in my hometown at the start of the next month.  And in a few more days, the very last piece of paper is expected to arrive at admissions to move me into yet one more step of my career. But all that turmoil can wait just a little bit longer.

Right now, at this very instant, all is quiet.  I have a moment or two to listen to the thunder and await the rain.  I can hear the frogs.  I try to close my eyes and focus so that I can see the future, so that when I have the time, I can make it happen.  But nothing comes.  So, I'll enjoy the quiet, and not confuse it with peace...