Candidate Standards Selection: Unresolved Issues

by Dr. Stephen Beller
President/CEO - National Health Data Systems, Inc.
updated: 8/7/2013

Purpose of this Post

In this post, I discuss the need to reassess a complementary set of standards that provides a viable solution for filling critical gaps in the standards currently selected by SDC.

These gaps exist at the transport layer, which includes the failure to comply with the only transport mechanism required by MU2, i.e., Basic DIRECT (PKI + SMTP & S/MIME). With the addition of a highly rated, free open source, spreadsheet model standard, this solution provides a simple, secure, and computationally powerful way to ship forms, capture data, and transmit that data point-to-point over the internet, anywhere/anytime, using e-mail clients and spreadsheet-based templates.

While I have not heard one valid reason why this solution should be excluded, I have heard misinformation and illogical arguments (discussed below), which have led to arbitrary decisions that do a shameful disservice to the SDC initiative.

Filling Critical Gaps

The solution I’m proposing differs significantly from all other candidate standards in very important ways. These differential capabilities fill critical gaps in particular situations. In contrast to the standards SDC is currently focusing on, the solution of which I speak is vital to users who:
  • Want to maintain local control over the data capture process instead of remote or centralized control
  • Want to use asynchronous e-mail instead of synchronous web services when on the go or disconnected from the Web
  • Want to deploy computationally powerful standalone form templates, whenever and wherever they desire, without being tethered to the web
  • Have to operate in low bandwidth environments or where there is only occasional internet connectivity
  • Prefer not to use a browser and web services for data capture (due to security or other concerns) and would rather use a standalone software application offline
  • Want to store the captured data locally to perform analytical reports (i.e., secondary use of data for quality improvement and other purposes)
  • Want the captured data to be automatically transformed into different formats/structures for delivery to different people/organizations
  • Need forms that perform very complex actions based on sophisticated rules
  • Want a simple way for the forms to adapt to changes in value sets, terminologies, data models, etc.
  • Want a simple and secure transport mechanism that is able to operate even in disaster situations that disrupt the Internet
  • Want a quick and easy way to distribute and discuss the results among care team members dispersed in loosely-coupled collaborative networks.

Benefits and Advantages of the Proposed Solution

The proposed solution:
  • Can exists alongside, and comply with, other SDC standards
  • Is the only candidate standard that complies with the MU2 requirement for all certified EHRs to implement basic DIRECT, which is PKI with SMTP and S/MIME; SOAP and REST are merely options, not replacements for SMTP
  • Can handle the most complex form actions
  • Can interoperate with any databases and consume any XML documents
  • Has a universal translator for mapping and transforming data between disparate systems
  • Requires very little bandwidth and only brief Internet connectivity
  • Allows forms to be used offline
  • Reduces architectural complexity, minimizes demands central servers, and conserves local resources
  • Has built-in transport capabilities
  • Has strong analytical/computational capabilities built-in
  • Is extremely flexible and adaptable
  • Is immune to Internet slowdowns and outages during the data capture process
  • Provides a means for transport when the Internet and Web are nonfunctional (using radio communications), such as in disaster situations
  • Is non-disruptive to existing I.T. systems.

Creative Commons License

I am willing to make novel and proprietary knowledge and tools available to the SDC community under the terms of the Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0) license.


This following presents four issues that the SDC community should discuss and deal with fairly and wisely:
  1. Spreadsheet Technology Candidate Standard
  2. Web Services Transport and DIRECT Candidate Standards
  3. SDC Decision-Making Process
  4. Dictating Coding Language.

1. Spreadsheet Technology Candidate Standard

[Note: I discussed this issue several weeks ago in an e-mail sent the SDC community]

As the primary person rating spreadsheet technology and who gave it very high scores, I want to make sure other in the SDC community concur with my ratings and reasons. My ratings raise spreadsheet technology from the current 64.7 to one of the highest rankings in Content and Structure (Transaction 3) list.

I made it clear to the leadership, via an offline phone conversation weeks ago, that my goal is to (a) make our community aware of the exceptional capabilities of a spreadsheet technology for attaining SDC’s objectives and (b) demonstrate how to do it. I have no relationship with, nor ownership of, any spreadsheet company; and I’m not trying to selling a product here.

I now share my knowledge of spreadsheet technology and provide justifications for my high ratings. If you disagree with any of the following or have questions, please post a reply so I can respond.

Spreadsheet Technology Forms Capabilities

Let me begin with a brief description of spreadsheet technology:
  • Is a stable, powerful, flexible, and enduring technology that has been around since the late 1970s, well before the Internet, browsers, PCs, etc.
  • Provides a platform for developing and deploying computational models; the Spreadsheet Standards Review Board (, which creates standards for spreadsheet models, has been in operation for 10 years.
  • Are available in free open source (e.g., OpenOffice Calc) and propriety products (e.g., Excel and Lotus 1-2-3).
  • Come in online and offline (standalone) versions.
  • Handles both numeric- and text-based data.
  • Has forms for data input and presentation (e.g., ActiveX forms and Google Spreadsheet Integration forms)
  • Has macro (automation) capability that enables it to, e.g., query databases, perform iterative computational processes, do data integrations and transformations, execute rules through logic- and numeric-based algorithms (such as complex branching logic and CDE selection and display in forms), etc.
  • Can handle any terminology standards, CDEs and domain-specific DEs, value sets, rules, etc.
  • Is able to emulate the forms and incorporate the rules of other data capture tools.
  • Is able to consume just about any file formats, including XML, delimited text, and semi-structured files.
  • Is able to output data in just about any formats.
  • Enables collaborative model building and sharing.
  • Can associate data capture models with their corresponding data analytical models in a way that streamlines the data exchange process.
  • Can send the captured data in whatever format and structure is required.
  • Can prepopulate a form via automated database queries, CCDA XML parsing, etc.
  • Can store the form results in any format, including XML.
  • Uses interconnected, multidimensional, cell-based “computational containers” in which data, formulas and functions are stored. These cell containers can:
    • Serve as interconnected database (flat file) tables, lists, data arrays, etc.
    • Format and present (render) data in a wide variety of views
    • Organize data is a highly human readable and computationally proficient manner
    • Be populated via manual and automated inputs
    • Enable granular-level data control
    • Be modified by macro-driven procedures.

Revised SDC Standards Ratings Explained

Below are the criteria from the SDC Standards Evaluation Template workbook, along with my most recent ratings and notes, for spreadsheet technology; please let us know if you disagree or have any questions as to why I gave those ratings. Note the SDC Standards Evaluation Template workbook currently defines the proposed standard as “XLS/XLSX/XLSM”; I requested that it be changed to a more generic term: “spreadsheet technology.”
Content & Structure
Maturity of Specification

Breadth of Support
Many sources of support
Around for 30+ years
Adoption of Specification
Do you know anyone who hasn’t used a spreadsheet?
Maturity of Underlying Technology Components

Breadth of Support
Many sources of support
30+ years
Adoption of Technology
Many millions of users
Platform Support
Spreadsheet are available for all common platforms
Maturity of the Technology Within its Life Cycle
30+ years
Maturity of Market Adoption

Installed Health Care User Base
I don’t know a specific number (so I rated it M, but it could be H), but spreadsheets are used in healthcare for such things as web-based data collection, real time data capture,business intelligence, accounting, expense tracking,decision support , and presenting public health results
Installed User Base Outside Health Care
How many professionals do you know anyone who haven’t used a spreadsheet?
Interoperable Implementations
Produces and consumes any structured (and semi-structured) data formats from any data sources via desktop and browser/web implementations
Future Projections and Anticipated Support
No reason to expect a negative change
Adoptability Ease of Implementation & Deployment

Availability of Off-the-Shelf Infrastructure to Support Implementation
Widely available
Specification Modularity
Spreadsheets are modular by their very nature in terms of the forms, worksheets and macro modules; they can be readily decomposed and recomposed as needed
Quality & Clarity of Specifications
30+ years of use and evolution has led to clear specifications
Ease of Use of Specification
Spreadsheet are easy to use and the learning curve for basic operations is not steep, including for forms and macro language
Degree to which Specification Uses Familiar Terms to Describe “Real-World” Concepts
Workbook, worksheet, cell, code module, formula, function, formatting … nothing out-of-the-ordinary
Expected Total Costs of Implementation
If a proprietary spreadsheet program is already installed (such as Excel, which is very ubiquitous), or if a free spreadsheet is used, then there is no cost for implementation; otherwise, the cost is low.
Appropriate Optionality
Rules easily implement or ignore optionality
Adoptability Intellectual Property

Anyone can use spreadsheets
Cost of spreadsheets vary from free to low
Freedom from Patent Impediments
While spreadsheets vary from open source to proprietary, the models built for SDC would be non-proprietary. This issue was discussed by the sub-workgroup and in offline conversation. The underlying components of a proprietary spreadsheet program (e.g., the algorithms that instruct it how to add and subtract) cannot be modified, nor should it, since that may corrupt the spreadsheet’s ability to calculate. However, all formulas, functions, forms, and macro code are available to developers and can be readily modified.
Standards & Interoperability Specific Regulatory

Meaningful Use


Other Regulation
The Spreadsheet Standards Review Board has been in operation for 10 years.
Standards & Interoperability Specific Usage within S&I Framework

Usage within S&I Framework
Spreadsheets are used a great deal in S&I, including the “SDC Standards Evaluation Template” workbook

Technical Feasibility Ratings

Spreadsheet technology also satisfies all the technical feasibility requirements in the Technical Feasibility Requirements 20130605.xlsx workbook.


Spreadsheet technology is a nearly perfect standard for SDC forms/templates and, unless proven otherwise by the overall SDC community, it should be near the top of the list!

I do commend SDC leadership, during the last Standards sub-workgroup, in approving the use of spreadsheet-based forms in SDC pilot studies. I contend that final judgment about this and all other potential technologies should be based on the capabilities they demonstrate during the pilots.

2. Web Services Transport and DIRECT Candidate Standards

In a sub-workgroup meeting last week, one explanation voiced for opposing secure e-mail is that it transports forms and requests for forms (as well as data) in an asynchronous manner. This is illogical since there’s an expressed expectation that forms can be used offline, which is asynchronous. The other reason mentioned is that this has something to do with the use of XML, which is simply incorrect.

I therefore oppose the absence of secure e-mail (PKI with SMTP+S/MIME) as an option in the current SDC Ballot Package (see image below - reference . I assert that secure e-mail should be included as a third option, along with SOAP and REST.
This issue goes further. Having implementations that use web services, along with those that use email clients, provides choice for end-users based on the relative advantages and first-hand knowledge of both. The transport method selected by an end-user can then be based on its cost, convenience, capabilities, security, and usability.

In fact, giving users a choice is already an SDC precedent since both SOAP and REST have been chosen as standards. While indicating that DIRECT "Can be used as an additional or optional layer of security on top of REST and/or SOAP" the reason for excluding it is that "SOAP and REST may be sufficient on their own. Is there any reason to keep DIRECT?" (see figure below). This rationale can be reversed, however, i.e., Why keep REST and SOAP when DIRECT may be sufficient. Interestingly, DIRECT, which makes SMTP an MU2 requirement, does include SOAP and REST as e-mail options (not SMTP replacements).


3. SDC Decision-Making Process
Over the past two years, I've been a committed member of five HHS/ONC initiatives and have been involved in their technical workgroups. I have serious concerns about the way certain initiatives:
  • Select standards, which is, at times, based on misinformation, ignorance, and impatience
  • Disrespect innovative approaches/technologies perceived to be “creatively destructive” [footnote 1]
  • Control the decision process through “regulatory capture” [footnote 2] or some other perverse set of processes.

Although decisions made by SDC should be transparent, some decisions appear to be done "behind closed doors" and then presented to the overall community as a fait accompli. Case in point is the in the introduction of ISO 16262, which was suddenly introduced with a rank of 85 and announced as a standard (see figure below - reference).


More about this in issue 4.

As such, modifications to the decision-making process for SDC and to other S&I Framework initiatives should include:
  • No decisions should be made about a candidate standard, both in sub-workgroups and all hands meetings, unless valid subject matter experts are present and available for comment, especially those who have been actively involved in prior discussions.
  • Reasons submitted by community members for changing prior decisions about candidate standards should be made available and openly discussed with the SDC community. This should be done without accusation of derailing the conversation and there should be transparent disclosure to the community of any offline conversations regarding such changes.

4. Dictating Coding Language

As discussed in the last All Hands meeting, ISO 16262 is based on JavaScript code. It was selected at the means for filling the “actions” gap in form functionality since the other standards selected lack such capabilities. Interestingly enough, spreadsheet technology has those capabilities, and probably many more, built right in. So, instead of selecting one of the best suited technologies for forms, decisions were made that unnecessarily increase complexity and cost without due consideration of other candidate standards that have the requisite capabilities.

Furthermore, no other HHS/ONC initiative I've been in dared to dictate the programming language and development platform that implementers must use in their applications (software products). Instead, as long as the they complied with certain other standards and had the requisite capabilities enabling them to be deployable by potential end-users, any program language and development platform is deemed acceptable.


[1] Creative destruction is a “term coined by Joseph Schumpeter…to denote a ‘process of industrial mutation that incessantly revolutionizes the economic structure from within, incessantly destroying the old one, incessantly creating a new one’” (from The term “disruptive innovation” is closely related to the creative destruction concept. Disruptive innovations help create a new market and value network, and eventually go on to disrupt an existing market and value network. They are generally technologically straightforward, consisting of off-the-shelf components put together in a product architecture that is simpler, more convenient and less expensive than prior approaches. They offer a different package of attributes than mainstream markets expect. For examples of disruptive healthcare innovation I healthcare, see

[2] “Regulatory capture…is the process by which regulatory agencies eventually come to be dominated by the very industries they were charged with regulating…[It] happens when a regulatory agency, formed to act in the public's interest, eventually acts in ways that benefit the industry it is supposed to be regulating, rather than the public” (from