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.

Wednesday, June 26, 2013

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.

1 comment:

  1. I think you make some great points here Keith. I'm not sure if you have read Richard Soley's (OMG) blog "What Makes a Standards" from 2012 but I would like your .02 on developing "de facto" standards.

    Cheers & have a great 4th!