Skip to main content
Standards & Interoperability (S&I) Framework
S&I Framework Links:
ONC Initiatives currently located on wiki.siframework.org have migrated to the ONC Tech Lab Standards Coordination Space. Click
Pages and Files
Introduction & Overview
Processes & Guidelines
Getting Started as a Participant
Community Enabling Toolkit (CET)
Standards Development Support
Wiki User Guide
Clinical Quality Framework (CQF)
Data Access Framework (DAF)
Data Provenance (DPROV)
PDMP & Health IT Integration (PDMP)
Structured Data Capture (SDC)
Active Community Led or Other Agency Led Initiatives
a LOINC Order Code
electronic Long-Term Services and Supports (eLTSS)
Electronic Submission of Medical Documentation (esMD)
Laboratory Orders Interface (LOI)
Laboratory Results Interface (LRI)
Public Health Tiger Team
BlueButton Plus (BB+)
Data Segmentation for Privacy (DS4P)
EU-US eHealth Cooperation Initiative (EU-US)
Longitudinal Coordination of Care
Provider Directories (PD)
Public Health (PHRI)
Query Health (QH)
Transitions of Care (TOC)
Privacy on FHIR
Open Test Method Development Pilot Program
Direct Project (S&I Archetype)
Clinical Element Data Dictionary (CEDD)
Model Driven Health Tools
Face 2 Face Meetings
Mention of any product or organization on these pages does not imply endorsement of that product or organization by ONC, HHS, or any other Federal agency.
Canddiate Standards List Feedback
Candidate Standards Selection: Unresolved Issues
by Dr. Stephen Beller
President/CEO - National Health Data Systems, Inc.
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:
Spreadsheet Technology Candidate Standard
Web Services Transport and DIRECT Candidate Standards
SDC Decision-Making Process
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.,
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.
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
Adoption of Technology
Many millions of users
Spreadsheet are available for all common platforms
Maturity of the Technology Within its Life Cycle
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
, and presenting public health results
Installed User Base Outside Health Care
How many professionals do you know anyone who haven’t used a spreadsheet?
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
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.
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
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 -
. 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 -
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
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.
 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
 “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
help on how to format text
Contributions to http://wiki.siframework.org/ are licensed under a
Creative Commons Attribution Share-Alike 3.0 License
Portions not contributed by visitors are Copyright 2017 Tangient LLC
TES: The largest network of teachers in the world
Turn off "Getting Started"