Discussion for Week 4 Subscribe Topic:  Explain the data interchange standards required to enable the flow of the information. As part of the Stage 2 assignment, you will identify Data Interchange Standards the Midtown Family Clinic EHR system will use to exchange information with external organizations.  For this discussion, we will explore several different Data Interchange Standards, or "Interoperability Standards" as the ONC defines them.  First to understand the top challenges in sharing data, read http://www.pewtrusts.org/en/research-and-analysis/fact- sheets/2016/11/electronic-health-records-patient-matching-and-data- standardization-remain-top-challenges  This article highlights the need for data standardization.  Next, you will become familiar with the Interoperability Standards Advisory published and maintained by the Office of the National Coordinator for Health Information Technology (ONC)  https://www.healthit.gov/isa/ The purpose of the Advisory, as stated on the website is shown below. The Interoperability Standards Advisory (ISA) is meant to serve at least the following purposes: 1. To provide the industry with a single, public list of the standards and implementation specifications that can best be used to address specific clinical health information interoperability needs. Currently, the ISA is focused on interoperability for sharing information between entities and not on intra- organizational uses.   2. To reflect the results of ongoing dialogue, debate, and consensus among industry stakeholders when more than one standard or implementation specification could be used to address a specific interoperability need, discussion will take place through the ISA public comments process. The web- version of the ISA will improve upon existing processes, making comments more transparent, and allowing for threaded discussions to promote further dialogue. http://www.pewtrusts.org/en/research-and-analysis/fact-sheets/2016/11/electronic-health-records-patient-matching-and-data-standardization-remain-top-challenges https://www.healthit.gov/isa/ 3. To document known limitations, preconditions, and dependencies as well as provide suggestions for security best practices in the form of security patterns for referenced standards and implementation specifications when they are used to address a specific clinical health IT interoperability need." GROUP 4:  From the many different standards listed in the Advisory, choose one that has not yet been posted and: 1. Put the Title of the standard in the Subject line for your posting. 2. Conduct some additional research and explain: a. What the standard is b. What the standard is used for c. Why it is important GROUPS 1, 2 and 3:  For at least two postings, 1. Conduct your own research on the standard 2. Critically evaluate and respond to the explanation provided for: a. What the standard is b. What the standard is used for c. Why it is important 3. Provide at least one additional comme ...

1. Discussion for Week 4
Subscribe
Topic: Explain the data interchange standards required to
enable the flow of the
information.
As part of the Stage 2 assignment, you will identify Data
Interchange Standards the
Midtown Family Clinic EHR system will use to exchange
information with external
organizations. For this discussion, we will explore several
different Data
Interchange Standards, or "Interoperability Standards" as the
ONC defines them.
First to understand the top challenges in sharing data, read
http://www.pewtrusts.org/en/research-and-analysis/fact-
sheets/2016/11/electronic-health-records-patient-matching-and-
data-
standardization-remain-top-challenges This article highlights
the need for data
standardization. Next, you will become familiar with the
Interoperability Standards
Advisory published and maintained by the Office of the
National Coordinator for
Health Information Technology
(ONC) https://www.healthit.gov/isa/ The purpose
of the Advisory, as stated on the website is shown below.
The Interoperability Standards Advisory (ISA) is meant to serve

2. at least the following
purposes:
1. To provide the industry with a single, public list of the
standards and
implementation specifications that can best be used to address
specific
clinical health information interoperability needs. Currently, the
ISA is focused
on interoperability for sharing information between entities and
not on intra-
organizational uses.
2. To reflect the results of ongoing dialogue, debate, and
consensus among
industry stakeholders when more than one standard or
implementation
specification could be used to address a specific interoperability
need,
discussion will take place through the ISA public comments
process. The web-
version of the ISA will improve upon existing processes,
making comments
more transparent, and allowing for threaded discussions to
promote further
dialogue.
http://www.pewtrusts.org/en/research-and-analysis/fact-
sheets/2016/11/electronic-health-records-patient-matching-and-
data-standardization-remain-top-challenges
https://www.healthit.gov/isa/
3. To document known limitations, preconditions, and
dependencies as well as
provide suggestions for security best practices in the form of

3. security patterns
for referenced standards and implementation specifications
when they are
used to address a specific clinical health IT interoperability
need."
GROUP 4: From the many different standards listed in the
Advisory, choose one
that has not yet been posted and:
1. Put the Title of the standard in the Subject line for your
posting.
2. Conduct some additional research and explain:
a. What the standard is
b. What the standard is used for
c. Why it is important
GROUPS 1, 2 and 3: For at least two postings,
1. Conduct your own research on the standard
2. Critically evaluate and respond to the explanation provided
for:
a. What the standard is
b. What the standard is used for
c. Why it is important
3. Provide at least one additional comment on one of the aspects
above (what
the standard is, what it is used for, or why it is important)
Your responses should be complete and thorough, and not
simply "I agree."
EVERYONE: Review the criteria in the Discussion Grading

4. Rubric, and reply to those
who critique your work or post other points of view. Be sure to
demonstrate your
understanding of the topic and analytical thinking.
Overview
Since 2009, hospitals and physicians have rapidly moved from
paper patient records to electronic ones. These
technologies have helped to foster safer, higher-quality, and
more coordinated care.1 But electronic health records
(EHRs) have not yet reached their full potential. This is partly
because hospitals and doctors’ offices still face
challenges in sharing data about the same patient. The inability
to link patient records among different health
systems, and to format the data in a way that can be easily
exchanged, prevents patients and their doctors from
having the information they need to make appropriate
decisions.2
Barriers to interoperability
Patients often see multiple health care providers, including
primary care doctors, medical specialists, and
hospital-based and outpatient care. In each of these settings,
clinicians conduct physical examinations and order
laboratory tests, storing their findings in an EHR. To more
effectively and efficiently treat patients, hospitals
and health care providers should be able to both retrieve the
relevant data from their own copies of patients’
records and access information stored in other providers’ EHRs.
Unfortunately, they can’t do that now. This
obstacle—referred to as poor interoperability—leads to
redundant services, errors in patient care, unnecessary

5. Electronic Health Records: Patient
Matching and Data Standardization
Remain Top Challenges
Getty Images
Nov 2016A fact sheet from
hospitalizations, delays in treatment, and wasted provider time,
all of which raise health care costs.
A recent Government Accountability Office report found that
the main reasons for inadequate interoperability
are problems accurately matching patients to their health
records and the limitations of health data standards.3
Patient matching
When a patient arrives at a doctor’s office or hospital, the staff
attempts to locate his or her medical records,
both those within the facility and those held by other health
care providers. To match people with their prior
medical records, health care providers use a variety of
nonstandardized approaches that include different data
and algorithms. Many providers attempt to match records based
on an individual’s last name, date of birth,
address, and phone number, among other demographic data.
Often, an automated algorithm in the facility’s EHR
system evaluates multiple data fields and generates an overall
likelihood of a match.
This method produces relatively high error rates. One in 5
matches within an organization can be incorrect, and
up to half happen when providers seek data from other
facilities.4 The errors occur because data in patients’

6. EHRs may be missing or incorrect, and because there is no
consensus within the health care industry on the best
way to match patients across institutions. As a result, when one
hospital sends information to another health
care facility, the recipient cannot reliably link it to the patient’s
existing profile.
Errors within the same health care facility can occur if staff
match a new patient’s record with that of another
person with the same name. Alternatively, they may create a
new record for a patient already in the system. For
example, the Harris County health system, which includes
Houston, has 2,488 records with the name Maria
Garcia, of which 231 have the same birth date.5 Hospital staff
also may not be able to locate a patient’s record, for
example, because demographic information was incorrectly
entered or the patient moved.
These duplicate records and mismatches can jeopardize patient
safety. In one survey, 20 percent of hospital chief
information officers reported that at least one patient had been
harmed at their facilities in the past year because
of mismatched records.6 Another survey found that patients
with duplicate electronic records were more likely to
have abnormal laboratory results overlooked by their clinician.7
Managing IT systems to address these problems
is expensive: Resolving a single duplicate record can cost
hospitals approximately $1,000.8
Data standards
Aside from the inability to accurately match patients, EHR
systems store health data in different ways, making it
difficult for hospitals and clinicians to easily integrate
information they receive from another health care provider
into their records. For example, some EHRs classify a
medication reaction as an allergy, while others record it as a

7. side effect.9 These types of discrepancies could result in errors
at the point of care, such as a patient receiving the
wrong dose of a medication or one that causes a serious
reaction.
Federal criteria for documenting and exchanging EHR data
prioritize flexibility for the manufacturers of these
systems, giving them considerable latitude in how to interpret
and meet regulations. Compounding this problem
is insufficient transparency about the standards each EHR
system employs. As a result, health care providers
often cannot readily exchange data without building costly
customized interfaces between each platform.
Therefore, even when hospitals can match patients, their data
are often not easily and effectively exchanged
across providers.
Fixing interoperability
The ability to share health data should be a fundamental part of
a health care system that provides patients
with reliable, high-quality, coordinated care. A number of
possible solutions have been proposed to address the
challenges to interoperability, such as a creating a voluntary
national approach to uniquely identify each patient
and strengthening the standards that govern how EHRs store
data. The federal government, hospitals, clinicians,
EHR vendors, and other stakeholders should work together to
overcome interoperability challenges so that
individuals are matched with their records, and physicians can
use that data to improve patient health.
Endnotes
1 Centers for Medicare & Medicaid Services, “EHR Incentive
Program: Active Registrations” (July 2016),

8. https://www.cms.gov/
Regulations-and-
Guidance/Legislation/EHRIncentivePrograms/Downloads/July20
16_SummaryReport.pdf.
2 Office of the National Coordinator for Health Information
Technology, Connecting Health and Care for the Nation: A
Shared Nationwide
Interoperability Roadmap (October 2015),
https://www.healthit.gov/sites/default/files/hie-
interoperability/nationwide-interoperability-
roadmap-final-version-1.0.pdf; and Arthur L. Kellermann and
Spencer S. Jones, “What It Will Take to Achieve the As-Yet-
Unfulfilled
Promises of Health Information Technology,” Health
Affairs 32, no. 1 (January 2013): 63–8,
http://dx.doi.org/10.1377/hlthaff.2012.0693.
3 Government Accountability Office, Electronic Health
Records: Nonfederal Efforts to Help Achieve Health
Information Interoperability
(September 2015), http://www.gao.gov/products/GAO-15-817.
4 Bipartisan Policy Center, Challenges and Strategies for
Accurately Matching Patients to Their Health Data (June 2012),
http://cdn.
bipartisanpolicy.org/wp-
content/uploads/sites/default/files/BPC%20HIT%20Issue%20Bri
ef%20on%20Patient%20Matching.pdf; and
Office of the National Coordinator for Health Information
Technology, Patient Identification and Matching: Final Report
(February 2014),
https://www.healthit.gov/sites/default/files/patient_identificatio
n_matching_final_report.pdf.

9. 5 Cindy George, “Harris County Hospital District Tries New
Kind of Palm Reader,” Houston Chronicle, April 5, 2011,
http://www.chron.com/
news/houston-texas/article/Harris-County-Hospital-District-
tries-new-kind-of-1689057.php.
6 College of Healthcare Information Management Executives,
“Summary of CHIME Survey on Patient Data-Matching” (May
16, 2012),
https://chimecentral.org/wp-
content/uploads/2014/11/Summary_of_CHIME_Survey_on_Pati
ent_Data.pdf.
7 Erel Joffe et al., “Duplicate Patient Records—Implication for
Missed Laboratory Results,” American Medical Informatics
Association
Annual Symposium Proceedings (2012): 1269–75,
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3540536.
8 Brooke Murphy, “Unpacking the Costs of Patient
Misidentification on a Hospital’s Bottom Line,” Becker’s
Hospital CFO, Aug. 19, 2016,
http://www.beckershospitalreview.com/finance/unpacking-the-
costs-of-patient-identification-on-a-hospital-s-bottom-line.html.
9 Government Accountability Office, Electronic Health
Records: HHS Strategy to Address Information Exchange
Challenges Lacks Specific
Prioritized Actions and Milestones (March 2014),
http://www.gao.gov/assets/670/661846.pdf.
https://www.cms.gov/Regulations-and-
Guidance/Legislation/EHRIncentivePrograms/Downloads/July20
16_SummaryReport.pdf
https://www.cms.gov/Regulations-and-
Guidance/Legislation/EHRIncentivePrograms/Downloads/July20

10. 16_SummaryReport.pdf
https://www.healthit.gov/sites/default/files/hie-
interoperability/nationwide-interoperability-roadmap-final-
version-1.0.pdf
https://www.healthit.gov/sites/default/files/hie-
interoperability/nationwide-interoperability-roadmap-final-
version-1.0.pdf
http://dx.doi.org/10.1377/hlthaff.2012.0693
http://www.gao.gov/products/GAO-15-817
http://cdn.bipartisanpolicy.org/wp-
content/uploads/sites/default/files/BPC%20HIT%20Issue%20Bri
ef%20on%20Patient%20Matching.pdf
http://cdn.bipartisanpolicy.org/wp-
content/uploads/sites/default/files/BPC%20HIT%20Issue%20Bri
ef%20on%20Patient%20Matching.pdf
https://www.healthit.gov/sites/default/files/patient_identificatio
n_matching_final_report.pdf
http://www.chron.com/news/houston-texas/article/Harris-
County-Hospital-District-tries-new-kind-of-1689057.php
http://www.chron.com/news/houston-texas/article/Harris-
County-Hospital-District-tries-new-kind-of-1689057.php
https://chimecentral.org/wp-
content/uploads/2014/11/Summary_of_CHIME_Survey_on_Pati
ent_Data.pdf
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3540536
http://www.beckershospitalreview.com/finance/unpacking-the-
costs-of-patient-identification-on-a-hospital-s-bottom-line.html
http://www.gao.gov/assets/670/661846.pdf
Contact: Laurie Boeder, communications director
Email: [email protected]
Phone: 202-540-6397
For further information, please visit:
pewtrusts.org

11. The Pew Charitable Trusts is driven by the power of knowledge
to solve today’s most challenging problems. Pew applies a
rigorous, analytical
approach to improve public policy, inform the public, and
invigorate civic life.
mailto:[email protected]
http://www.pewtrusts.org/
Interoperability Standards Advisory
healthit.gov/isa
The annual ISA Review and Comment period has closed. Stay
tuned for the 2020 ISA Reference Edition - coming
this December.
The Interoperability Standards Advisory (ISA) process
represents the model by which the Office of the National
Coordinator for Health Information Technology (ONC) will
coordinate the identification, assessment, and public
awareness of interoperability standards and implementation
specifications that can be used by the healthcare
industry to address specific interoperability needs including, but
not limited to, interoperability for clinical, public
health, and research purposes. ONC encourages all stakeholders
to implement and use the standards and
implementation specifications identified in the ISA as
applicable to the specific interoperability needs they seek to
address. Furthermore, ONC encourages further pilot testing and
industry experience to be sought with respect to
standards and implementation specifications identified as
“emerging” in the ISA. For historical background on the ISA

12. please review prior ISA publications.
The 2019 ISA has been updated to include improvements made
based on recommendations received from public
comments and subject matter expert feedback. To learn more
about major revisions of the ISA, please review recent
ISA updates. Registered users may subscribe to change
notifications to be alerted by e-mail of all revisions to
individual interoperability needs or for ISA-wide changes.
Anyone may become a registered user by submitting an
account request. Once logged in, look for the blue “change
notification” button at the bottom of the interoperability
need page, or at the bottom of the home page to be notified of
any changes across the ISA. An RSS Feed was also
added in 2018, capturing more granular updates made to the
ISA.
Scope
Starting with the 2017 ISA, the ISA’s focus expanded to more
explicitly include public health and health research
interoperability. Thus, its scope includes electronic health
information created in the context of treatment, and
subsequently used to accomplish a purpose for which
interoperability is needed (e.g., a referral to another care
provider, public health reporting, or research). Added in late
2017, the ISA now also includes interoperability needs
related to Administrative functions within healthcare. These
additions were made through coordination with CMS,
and it is anticipated to include other administrative healthcare
interoperability needs going forward.
The ISA is not exhaustive but it is expected to be incrementally
updated to include a broader range of health IT
interoperability needs. When more than one standard or
implementation specification is listed it is intended to

13. prompt industry dialogue as to whether one standard or
implementation specification is necessary or if the industry
can efficiently interoperate more than one. It may also reflect
the fact that there is an ongoing transition from the use
of one standard towards a new version or even next-generation
approach.
As noted in previous ISA publications, a standard listed in one
section is not intended to imply that it would always be
used or implemented independent of a standard in another
section. To the contrary, it will often be necessary to
combine the applicable standards from multiple sections to
achieve interoperability for a particular clinical health
information interoperability need.
It is also important to note that the ISA is designed to inform
standards and implementation specification choices for
all types of health IT that support interoperability needs, not
solely electronic health record (EHR) systems.
Furthermore, the ISA is not intended to imply that health IT
systems need to support all of the listed standards and
implementation specifications. Rather, in the event that a health
IT developer or healthcare provider seeks to address
a particular interoperability need, the ISA should serve as the
first resource consulted to inform the selection of
standards and implementation specifications. Additionally, the
ISA is designed to inform the “what” that could be used
1/6
https://www.healthit.gov/isa/
https://www.healthit.gov/isa/historical-isa-publications
https://www.healthit.gov/isa/recent-isa-updates
https://www.healthit.gov/isa/user/register
https://www.healthit.gov/isa/isa-rss-feed

14. to address an interoperability need in order to assure industry
consistency around standards selection and is not
mean to explicitly direct “how” the standards and
implementation specifications would be implemented to address
an
interoperability need (e.g., application programming interface
or conversion tools).
The ISA is designed to be a coordinated catalog of standards
and implementation specifications that can be used by
different stakeholders to consistently address a specific
interoperability need. However, a listed interoperability need
(and its associated standard(s) and implementation
specifications(s)) is not meant to universally apply to all
stakeholders. Rather, if a listed interoperability need is relevant
to a particular clinical specialty, for example, the ISA is
designed to provide a consistent foundation from which these
stakeholders can agree on applicable technical
requirements. Similarly, in cases where a listed interoperability
need is not applicable to a given stakeholder group,
the ISA in no way compels such stakeholders to consider that
interoperability need.
Please note that the ISA serves as an informational resource for
available standards, specifications, profiles, etc that
exist to meet the interoperability needs contained within.
Stakeholders should ensure and verify that they are
adhering to applicable federal, state, and/or local laws or
regulations regarding requirements to use a specific
standard or specification that may conflict with the information
listed in the ISA, as these requirements supersede the
ISA.
Purpose

15. The Interoperability Standards Advisory is meant to serve at
least the following purposes:
1. To provide the industry with a single, public list of the
standards and implementation specifications that can
best be used to address specific clinical health information
interoperability needs. Currently, the ISA is focused
on interoperability for sharing information between entities and
not on intra-organizational uses.
2. To reflect the results of ongoing dialogue, debate, and
consensus among industry stakeholders when more
than one standard or implementation specification could be used
to address a specific interoperability need,
discussion will take place through the ISA public comments
process. The web-version of the ISA improves upon
existing processes, making comments more transparent, and
allowing for threaded discussions to promote
further dialogue.
3. To document known limitations, preconditions, and
dependencies as well as provide suggestions for security
best practices in the form of security patterns for referenced
standards and implementation specifications
when they are used to address a specific clinical health IT
interoperability need.
The ISA is designed to provide clarity, consistency, and
predictability for the public regarding the standards and
implementation specifications that could be used for a given
clinical health IT interoperability purpose.
Stakeholders who administer government programs,
procurements, and testing or certification programs with clinical
health IT interoperability components are encouraged to look
first to the ISA in order to more fully inform their goals.

16. In that regard, standards and implementation specifications in
the ISA and their associated informative characteristics
are also available to help more fully inform policymaking. In
this case, a standard or implementation specification’s
reference in the ISA may serve as the initial basis for industry
or government consideration and action. While the ISA
itself is a non-binding document and meant to be advisory in
nature, standards and implementation specifications
listed in the ISA may be considered for rulemaking or other
Federal requirements. However, those decisions would
be made on a case-by-case basis by the administering
organization.
This site contains numerous links to other federal agencies and
to private organizations. You are subject to these
sites’ privacy policies when you access them. HHS is not
responsible for Section 508 compliance (accessibility) on
other federal or private sites. HHS is not responsible for the
contents of any "off-site" web page referenced from this
site.
ISA Structure
The ISA is organized and structured into five sections.
2/6
Section I – Vocabulary/Code Sets/Terminology Standards and
Implementation Specifications (i.e., “semantics”).
Section II – Content/Structure Standards and Implementation
Specifications (i.e., “syntax”).
Section III – Standards and Implementation Specifications for
Services (i.e., the infrastructure components deployed
and used to address specific interoperability needs)

17. Section IV – Administrative Standards and Implementation
Specifications (i.e., payment, operations and other
"non-clinical" interoperability needs)
Questions and Requests for Stakeholder Feedback
Appendices
Within each section specific “interoperability need”
subheadings are listed and followed by tables similar to the one
illustrated below. Each interoperability need may have one or
more standards and/or implementation specifications
associated with it. Each standard and implementation
specification has six informative characteristics attributed to it
in order to provide added context.
When known, an “emerging” standard or implementation
specification is also listed and is shaded in a lighter color
and italicized for additional emphasis. In addition, for
vocabulary standards, where there may be one standard used
to represent the “observation” or question being asked, and one
standard used for the “observation value” or answer
these are listed in distinct rows. See Appendix III for
educational information about observations and observation
values.
The ISA also includes links within the limitations, dependencies
and preconditions to ONC’s Interoperability Proving
Ground (IPG) to showcase real-world implementations of
standards listed within the ISA. Please note: when accessing
links to the IPG, all projects for the selected standard will be
listed, including those that may be demonstrating use of
the standard for different interoperability needs. In addition,
IPG entries are self-reported by stakeholders, so the
quality and accuracy of the data may vary across entries.
In Section I, the vocabulary standards with unspecified code
sets or context may be further constrained by a more

18. explicit standard named in a subsequent section. For example,
Section I: Encounter Diagnoses specifies SNOMED-CT
and ICD-10-CM but does not define the context of use. The
Standard/Implementation Specification named for the
“Interoperability Need: Ordering Labs for a Patient in Section
II: Laboratory” further constrains the diagnosis for the
patient in the context of a lab order to ICD-9CM or ICD-10CM
since the lab order diagnosis is for billing/claims, not
clinical diagnostics.
Interoperability need: [Descriptive Text]
Standard
Implementation/Specification
Standards
Process
Maturity
Implementation
Maturity
Adoption
Level
Federally
Required Cost
Test Tool
Availability
Standard Final Production No Free No
Standard for observations Final Production Yes Free Yes
Standard for observation

19. values
Final Production No Free Yes
Emerging Standard Balloted
Draft
Pilot No Free No
3/6
https://www.healthit.gov/isa/appendix-iii-educational-and-
informational-resources
https://www.healthit.gov/techlab/ipg/
Limitations, Dependencies, and Preconditions for
Consideration:Limitations, Dependencies, and Preconditions for
Consideration:
Section I:Section I:
ApplicableApplicable
Value Set(s)Value Set(s)
and Starterand Starter
Set(s):Set(s):
Other Sections:Other Sections:
ApplicableApplicable
SecuritySecurity
Patterns forPatterns for
Consideration:Consideration:

20. In the case where there is a need to reflect a conformance
statement, the verbs
“must” and “shall” will reflect an absolute requirement and the
verbs “can” and
“may” reflect optionality.
Where standards listed for an interoperability need have active
projects listed on
ONC’s Interoperability Proving Ground, a link to that standard
will be provided in
this section. Please note, all projects for the standard will be
listed, including those
that may be demonstrating use of the standard for different
interoperability
needs.
Descriptive
text
The following describes the ISA’s six informative
characteristics in greater detail. This detail is meant to better
inform
stakeholders about the maturity and adoptability of a given
standard or implementation specification and provides
definition for the terms and symbols used throughout the ISA.
Stakeholders should consider all six characteristics
together to gain insight into the level of maturity and
adoptability of the standards and implementation specifications
provided within the ISA.
#1: Standards Process Maturity
This characteristic conveys a standard or implementation
specification’s maturity in terms of its stage within a
particular organization’s approval/voting process.
“Final” – when this designation is assigned, the standard or
implementation specification is considered “final

21. text” or “normative” by the organization that maintains it. This
also includes approved “ANSI Informative”
specifications.
“Balloted Draft” – when this designation is assigned, the
standard or implementation specification is considered
to be a Draft Standard for Trial Use (DSTU), Standard for Trial
Use (STU), or in a “trial implementation” status by
the organization that maintains it and has been voted on or
approved by its membership as such. This
designation does not include standards and implementation
guides that are unofficial drafts and early “works in
progress”.
“In Development” – when this designation is assigned, the
standard or implementation specification is currently
in development. It also includes those that are in the midst of
being balloted. These standards would generally
benefit from lessons learned through development and pilots.
#2: Implementation Maturity
This characteristic conveys a standard or implementation
specification’s maturity based upon its implementation
state. Where available, a link to published maturity assessments
based on known published criteria about the
standards is also provided.
“Production” – when this designation is assigned, the standard
or implementation specification is being used in
production to meet a health care interoperability need.
“Pilot” – when this designation is assigned, the standard or
implementation specification is being used on a
limited scale or only as part of pilots to meet a health care
interoperability need.
4/6
https://healthit.gov/techlab/ipg

22. #3: Adoption Level
This characteristic conveys a standard or implementation
specification’s approximate, average adoption level for that
specific interoperability need in health care within the United
States. The adoption level attempts to consider all
implemented technology that would be used to address the
identified interoperability need and is not limited to
EHRs. Adoption means that the standard or implementation
specification is being used in health IT in the field by end
users to address the specific interoperability need. Presently,
the adoption levels listed are based on ONC’s analysis of
several factors, including, but not limited to: 1) whether and/or
how long a standard or implementation specification
has been included in regulation for health IT certification (if
applicable) or another HHS regulatory or program
requirement which is used only as a proxy for industry
adoption; 2) feedback from subject matter experts and 3)
public comments.
The adoption level also considers the variety of stakeholders
and stakeholder groups that would use the standard
and implementation specification to address the specified
interoperability need and attempts to display it as such,
with the understanding that the designation is a generality or
"best guess" and not a pre-defined measured value.
Where available, annotated references or links to publicly
available documentation known about adoption levels for
listed standards are also provided.
The following scale is used to indicate the approximate, average
adoption level among the stakeholders that would
use a standard or implementation specification to meet the
specified interoperability need:

23. “Feedback
Requested”
Indicates that we do not have a known status for the current
level of adoption in
health care.
Indicates low adoption.
Indicates low-medium adoption.
Indicates medium adoption.
Indicates medium-high adoption.
Indicates high or widespread adoption.
#4: Federally Required
This characteristic (provided as a “Yes” or “No”) conveys
whether a standard or implementation specification has been
adopted in regulation, referenced as a federal program
requirement, or referenced in a federal procurement (i.e.,
contract or grant) for a particular interoperability need. Where
available, a link to the regulation has been provided.
Please note this is meant to be provided as a reference only.
Entities seeking to comply with federal regulations
should look to any and all federal regulations that may apply to
ensure adequate compliance.
#5: Cost
This characteristic conveys whether a fee is involved to
purchase, license, or obtain membership for access or use of
the recommended standard or implementation specification.
“$” – when this designation is assigned, it signifies that some
type of payment needs to be made in order to

24. obtain the standard or implementation specification. Where
known, the estimated cost for access will be
provided.
“Free” – when this designation is assigned, it signifies that the
standard or implementation specification can be
obtained without cost. This designation applies even if a user
account or license agreement is required to obtain
the standard at no cost, but is not meant to imply that there are
no costs associated with implementation.
#6: Test Tool Availability
This characteristic conveys whether a test tool is available to
evaluate health IT’s conformance to the standard or
implementation specification for the particular interoperability
need. Where available, a link will be provided to the
publicly available test tool.
5/6
“Yes” – When this designation is assigned, it signifies that a
test tool is available for a standard or implementation
specification and is free to use. Where available, a hyperlink
pointing to the test tool will be included.
“Yes ”– When this designation is assigned, it signifies that a
test tool is available for a standard or
implementation specification and has a cost associated with its
use. Where available, a hyperlink pointing to the
test tool will be included.
“Yes – Open” – When this designation is assigned, it signifies
that a test tool is available for a standard or
implementation specification and is available as open source
with rights to modify. Where available, a hyperlink
pointing to the test tool will be included.
“No” – When this designation is assigned, it signifies that no

25. test tool is available for a standard or
implementation specification.
“N/A” – When this designation is assigned, it signifies that a
test tool for the standard or implementation would
be “not applicable.”
$
6/6
Interoperability Standards Advisory