BMI 516/BMI 616
Standards and Interoperability in Healthcare
Module 1-2
Standards
Rev 2012
Focus for Unit
Standard definition of standards
The standards value proposition
The standards process
Issues with implementing standards
2/
Harry Solomon /
Module 1-2 - Standards/
Standard Definition of “Standard”
Document, established by consensus and approved by a
recognized body, that provides, for common and repeated
use, rules, guidelines or characteristics for activities or
their results, aimed at the achievement of the optimum
degree of order in a given context
ISO/IEC Guide 2:2004 Standardization and related
activities -- General vocabulary
3/
Harry Solomon /
Module 1-2 - Standards/
Parsed definition
Document, no longer a physical exemplar
established by consensus among stakeholders
approved by a recognized body, authoritative for participants
that provides for common and repeated use, not a one-off
rules, guidelines or characteristics the meat!
for activities processes or their results, products
aimed at the achievement of not guaranteed
the optimum degree of order in the eyes of the stakeholders
in a given context scope
4/
Harry Solomon /
Module 1-2 - Standards/
Case Study: Edison light bulbs c. 1893
Class
Howexercise:
many
standards
What
problems
does
it take
does
this
pose for
• to
Manufacturer
screw in a
• light
Customer
bulb?
• Distributor/Vendor
• Installer/Integrator
• Public Safety
No, seriously …
how many?
Brush-Swan, U.S. base , Thomson-Houston,
Perkins-Mather, Shaeffer, Edison
Photographs from http://www.sparkmuseum.com/lighting.htm
Concept from David Channin, MD, Guthrie Clinic
5/
Harry Solomon /
Module 1-2 - Standards/
Cost Drivers in Non-Standard Solutions
Manufacturer
• ?
Tooling, supply chains, inventory, training, service
User / consumer
Choice, vertical lock-in, vendor lock-in, negotiation disadvantage
• ?
Distributor / System Integrator
Inventory, licensing, tools, training, adapters
• ?
Public Safety / Regulatory
Safety certification, emergency preparedness training
• ?
Applies to light bulbs - and Healthcare IT!
6/
Harry Solomon /
Module 1-2 - Standards/
Screwing in light bulbs
The multiple manufacturers needed to agree to standardize
They needed to agree to use a screw base
1902 – Lampholder Manufacturers Conference
• Each received a physical copy of Edison lamp gauge
1914 – standardization turned over to American Society of
Mechanical Engineers
• 1929 – joint custody with National Electrical Manufacturers Association
• Now designated ANSI/IEC C81.63
Screw base light bulbs manufactured in 1888 will operate in
lamp sockets made today – and for the foreseeable future
Will we have units of healthcare information that can
be used after a full century and more?
7/
Harry Solomon /
Module 1-2 - Standards/
Why do standards happen
Recognition of a specific problem by a critical
mass of stakeholders
• Manufacturers
• Users / consumers (often represented by professional
organization or government)
• Distributors / system integrators
• Public safety / regulatory
Consensus to establish a standards-based
approach to problem solution
• Typically for cost reduction / mitigation
8/
Harry Solomon /
Module 1-2 - Standards/
Standards and the
Economics of Interoperability
Without standards, everything is a custom integration
• Custom jobs inherently expensive
• Must negotiate both financial and technical terms
• Non-expert consumers at competitive disadvantage
Standard “sockets” between components
• Allow user choice of component implementer
• Allow vendors to specialize in improving components
Standards allow “retail users” to leverage best practice
• Domain expertise codified into standard
• Expertise reproduced into each compliant system
Standards make a market
9/
Harry Solomon /
Module 1-2 - Standards/
Standards History
You can’t measure without a standard
Leviticus 19:36 Thou shalt have an
honest balance, honest weights, an
honest dry measure, and an honest
liquid measure.
1875 Adoption of the “Convention du
Mètre” and establishment of the
International Bureau of Weights and
Measures (BIPM).
So what’s the reason to measure?
10 /
Harry Solomon /
Module 1-2 - Standards/
The Standards
Value Proposition
Mechanisms of value
11 /
Harry Solomon /
Module 1-2 - Standards/
Standards enable a market
Standards enable valuation
• Objective criteria for comparison
Standards facilitate deal-making
• Simplifies negotiation of the technical parameters of a
transaction
Standards facilitate open markets
• Customers (or political entities) cannot impose arbitrary
technical requirements that lock out certain players
• Lack of standards is a “barrier to trade”
Allow competition – reduce barriers to vendors
Grow the market – reduce barriers to customers
12 /
Harry Solomon /
Module 1-2 - Standards/
Standards facilitate system design
Standards define stable system partitioning and
component boundaries
• Architectural model of standard can be re-used
• Removes boundary debate from system design
Standards allow focused component development
• Encourages specialized competence for components
• Allows component improvement / re-engineering
• Allows incremental implementation and verification of
components
13 /
Harry Solomon /
Module 1-2 - Standards/
Standards reduce interface design cost
Use of existing standard reduces cost of defining, reviewing, and
documenting interfaces for specific product
Quality of interface is typically better
• SDO design review is broader than the two immediate parties to
a specific implementation
• Multiple implementations to same interface provide more
opportunities to debug the design
SDO manages the standard interface, rather than one of the
implementing parties
• Independence from specific implementation
Costs of interface definition/design shared by all users across all
products
SDO = Standards Development Organization
14 /
Harry Solomon /
Module 1-2 - Standards/
Standards leverage commoditization
Standard components have larger markets
• Stable interfaces allow components to be reused in different
contexts
• Cost of component design amortized over more units
Standard-related tools and services are commoditized
• Design tools and services
• Testing and validation tools and services
• Standard-related products becomes a market itself
15 /
Harry Solomon /
Module 1-2 - Standards/
Standards reduce workforce
training costs
Standards knowledge can be reused
• Minimize required workforce training for new
products/projects
• Training on standard can be a prerequisite for job –
moves cost of training to prior experience or basic
educational system
– Example: software programming language training
Standards provide a larger pool of trained candidates
Project start-up accelerated
16 /
Harry Solomon /
Module 1-2 - Standards/
Standards facilitate mergers &
acquisitions
Integration of acquired product lines facilitated by
adherence of products to standards
• Benefit to acquiring company – simplified
integration
– Fits into standards based processes, allowing reduction
of redundancies
– Product teams share common standards-based domain
concepts and vocabulary
• Benefits to acquired company – increased
valuation
17 /
Harry Solomon /
Module 1-2 - Standards/
Interoperability
The ability of two or more
systems or components to
exchange information and
to use the information that
has been exchanged.
Standards
A consensus specification
of rules for repeatable
activities or uniform
characteristics of products
in a given context.
Interoperability is silent on the method used to achieve
the result - could be re-done for each pair of systems.
Standards provide a method that is economically
effective - amortizing the cost of design and
implementation over many system pairs.
18 /
Harry Solomon /
Module 1-2 - Standards/
How do standards “happen”?
Government decree
• Procurement (for government use – e.g., MIL-STDs)
• General mandate (for broad economic policy – e.g., HIPAA)
Major vendor de facto (e.g., PDF)
Industry consortium / trade association
• Professional society
• “Consensus standard”
International standards body
• Academic collaboration
To solve a specific problem
19 /
Harry Solomon /
Module 1-2 - Standards/
Standards process
(consortium approach)
1. Problem recognition by critical mass of stakeholders
2. Search for a relevant standards body
3. Project proposal/approval; call for participation
4. Development in committee
5. Preliminary review, revision
6. Ballot by members of standards body
7. Reconciliation of negative ballots
8. Publication
May iterate
through Drafts
for Trial Use
before reaching
Normative status
Typically 18 months to several years
20 /
Harry Solomon /
Module 1-2 - Standards/
International Standards Bodies (1)
International Treaty Standards Organizations
IEC
ISO
ITU
International
Electrotechnical
Commission
International
Organization for
Standardization
International
Telecommunications
Union
Technical Committees
National Member Bodies
TC215
ANSI
Healthcare
Informatics
American National
Standards Institute
JTC1
Information
Technology
TC62
Electrical equipment
in medical practice
AFNOR
BSI
DIN
U.S. Accredited
Standards Committees
HL7
X12
ASTM
INCITS
21 /
Harry Solomon /
Module 1-2 - Standards/
International Standards Bodies (2)
Independent SDOs
IEEE
Formal
Liaison
ISO
Institute of Electrical and
Electronic Engineers
International
Organization for
Standardization
DICOM
Digital Imaging and
Communications in Medicine
TC215
Healthcare
Informatics
HL7
IHTSDO
International Healthcare
Terminology Standards
Development Organisation
W3C
JTC1
Information
Technology
World Wide Web
Consortium
AAMI
Association for the
Advancement of Medical
Instrumentation
IEC
International
Electrotechnical
Commission
TC62
Electrical equipment
in medical practice
SDOs with liaison to
an ISO TC can “fast
track” their approved
standards to be ratified
as an ISO standard
22 /
Harry Solomon /
Module 1-2 - Standards/
The great thing about standards –
there are so many to choose from!
23 /
Harry Solomon /
Module 1-2 - Standards/
Why?
All standards start from trying to solve a specific problem
• So it gets solved, but inevitably that problem turns out to be just a piece
of a larger problem
• Or the technological environment has changed
• So the standards developer expands the scope of their domain to
address the bigger problem or the new environment
• And repeat …
Multiple standards and domains
• Overlap and redundancy due to growth from niches
• Conflict because domain boundaries are unclear and information
models are different (and there is turf to be protected)
●
24 /
Harry Solomon /
Module 1-2 - Standards/
Case Study: DICOM (1)
1970’s – introduction of digital imaging (CT)
1983 – recognition of problem: sending digital images to printers
• Radiologists wanted image printers to be decoupled from imaging modalities
• Formation of joint professional-industry committee to address problem (ACRNEMA)
1985 – publication of ACR-NEMA Std 300
• 50-pin parallel interface (16-bit data bus), control and data elements
• 1988 – publication of version 2
1993 – publication of DICOM (ver. 3.0)
• Based on network communications in accordance with ISO Open System
Integration (OSI) standard model (over OSI or TCP/IP stack)
• Image formats for CT, MR, CR, US, NM
• Persistent information objects uniquely identified
• Film print management (page compositing, printer control)
25 /
Harry Solomon /
Module 1-2 - Standards/
Case Study: DICOM (2)
1993 – recognition of the cardiology problem
• Digital angiography – massive amounts of data (500 MB) needed physical
media for consultation
• ACC-NEMA committee; decision to work with DICOM (cardiologists cooperating
with radiologists!)
• 1995 – Extension to media interchange (particularly CD-R)
1993 – recognition of the workflow problem
• Need to manage the process of image acquisition
• European equipment manufacturers
• 1995 – Extension for Modality Worklist
1995 – recognition of the reporting and vocabulary problem
• Championed by persistent individual, also member of SNOMED Editorial Board
• 1998 – External coded concepts; 2000 – Structured reporting; 2001 – DICOM
controlled terminology and templates
26 /
Harry Solomon /
Module 1-2 - Standards/
Case Study: DICOM (3)
Workflow issues with HL7
• HL7 evolved over early 1990s from focus on interdepartmental communications,
including orders to radiology (rad info system – RIS)
• Disconnect on terminology, e.g.,
–
–
DICOM Accession Number = HL7 Filler Order Number ?
DICOM Admission ID = HL7 Patient Account Number or HL7 Visit Number ?
Structured reporting issues with HL7
• Parallel efforts on structured documents resulted in CDA being issued about the
same time as DICOM SR
• Disconnect on units of structure - CDA modeled using HL7v3 RIM (complex
units of data), SR uses more atomic DICOM Content Items
• Disconnect on fundamental purpose – CDA for human readability, SR for
machine-processable image findings
Joint HL7-DICOM working group and memorandum of understanding established
• Harmonization items feed into both organizations
• Both organizations want it to work
27 /
Harry Solomon /
Module 1-2 - Standards/
Case Study: the CCR wars
Goal – electronic version of Massachusetts Medical Society Continuity of Care
Form (used for critical patient information upon referral)
MMS partnered with ASTM E31 to standardize an XML-based representation,
resulting in Continuity of Care Record (CCR)
Parallel effort in HL7 resulted in Care Record Summary (CRS) with similar scope,
also XML-based (using HL7 v3 RIM and CDA)
ASTM threatened to sue HL7 for infringement of their Intellectual Property (both
ANSI accredited standards organizations)
Secretary of Health and Human Services said “Work it out – without litigation”
Joint HL7/ASTM Continuity of Care Document (CCD) developed and adopted –
basis for HHS recognized interoperability standards
●
ASTM
HL7
28 /
Harry Solomon /
Module 1-2 - Standards/
Standards alone are not the
whole interoperability story
Standards are broad, abstract and flexible
• Standards developers don’t want to impose too many constraints
that would limit the scope of applicability
• Room for interpretation in implementation (local customization)
hinders interoperability
Typically no single standard addresses full user tasks
Need to profile the specific use of specific standards for a specific
purpose
• A.k.a. Implementation Guides
• Profiling is a different mindset from standards development –
need to impose constraints
Interoperability promotion organizations (SDOs / non-SDOs)
29 /
Harry Solomon /
Module 1-2 - Standards/
Getting a standard implemented
Just because it’s written in a standard doesn’t mean you can buy it
Steps and timeline after standard approval
• Product manager decides standard is a valuable feature to be added
0 - 4 years – or maybe never
–
–
–
–
Cost of implementation vs. value of feature to customer
Value/cost against other potential product features
Customer stated or unstated needs (or gov’t mandates)
Market readiness: Competitor products, availability of profile / implementation guide
• Resources assigned to implement during next budget cycle .5 - 1 year
• Development team designs, implements, tests feature in accordance
with good software practice 1 year
• Commercial team rolls out product to sales force at next trade show
.5 - 1 year
Integration requires both sides of interface – limited by longer product cycle
30 /
Harry Solomon /
Module 1-2 - Standards/
Framework model for types of
Healthcare IT Standards
Workflow
Use Case Based Profiles and
Implementation Guides
Messaging
Data Interchange Standards
Format
Vocabulary
Health Record Content Standards
Vocabulary and Terminology
Standards
Where do clinical standards fit?
31 /
Harry Solomon /
Module 1-2 - Standards/
http://xkcd.com/927/
licensed under a Creative Commons Attribution-NonCommercial 2.5 License
32 /
Harry Solomon /
Module 1-2 - Standards/
Can you answer these questions?
What value does standardization provide to:
• Manufacturers
• Suppliers
• Customers
• Governments
How long does it take to develop a new standard?
How long does it take for a new standard to achieve
broad implementation?
Why are there so many standards?
33 /
Harry Solomon /
Module 1-2 - Standards/