Please note: This post by the HIT Standards Committee’s Implementation Workgroup is now closed for comment. Monitor this blog for more posts from the FACA committees and its workgroups as issues develop. Also, please visit the Health IT Buzz Blog to join other Health IT related conversations.
Since May of 2009, a Federal Advisory Committee called the HIT Standards Committee (HITSC) has been identifying standards that will help stakeholders select and meaningfully use electronic health record (EHR) systems.
What is a standard?
A standard (per the definition of the Healthcare Information Technology Standards Panel) specifies a well-defined approach that supports a business process and: (1) has been agreed upon by a group of experts; (2) has been publicly vetted; (3) provides rules, guidelines, or characteristics; (4) helps to ensure that materials, products, processes, and services are fit for their intended purpose; (5) is available in an accessible format; and (6) is subject to an ongoing review and revision process.
Mature standards are those with running implementations in diverse environments.
HITSC is charged with recommending standards, certification criteria, and implementation guidance, that will help accelerate interoperability in the context of the policy goals recommended by the HIT Policy Committee for the meaningful use of EHR systems. All stakeholders are represented – consumers, government, industry, payers, providers, and employers. HITSC has 4 working groups – Privacy and Security which focuses on technical security and data integrity; Clinical Quality which focuses on metrics that measure quality; Clinical Operations which focuses on the content and vocabulary standards that enable data exchange between organizations for quality measurement, clinical care, population health, and patient engagement; and Implementation which identifies and mitigates barriers to interoperability.
The Privacy and Security matrices specify the standards, certification criteria and implementation guidance recommended by the Committee to protect privacy and ensure data integrity. The work includes standards for products and standards for the infrastructure on which the products operate. The first matrix includes functionality, standards, a timeframe for adoption, and certification criteria. The second matrix includes functionality, standards, and implementation guidance. These spreadsheets include standards for authentication, authorization, auditing, access control, secure transmission, and exchange of documents. You’ll find an English description of the certification and implementation guidance here.
The Clinical Quality matrices specify the metrics, data types, and implementation guidance recommended by the Committee to measure quality – an important part of meaningful use. Of the 29 metrics listed, 17 are measures of quality which are being retooled by quality measure authors to be based on data elements captured in an EHR. Of the remaining 12, two are privacy/security related (Full compliance with HIPAA Privacy and Security Rules, Conduct or update a security risk assessment and implement security updates as necessary) and 10 are related to the adoption of EHR function (i.e. % of orders for medications, lab tests, procedures, radiology, and referrals entered directly by physicians through CPOE).
There are a number of stakeholders for quality data exchange:
- Measure definition entities such as the National Quality Forum, which endorses measures developed by various measure stewards.
- Providers who record clinical data in electronic health records.
- Data Collection Assistant entities such as Healthcare Information Exchanges which gather data from EHRs and transport it for a multitude of purposes.
- Quality Report Processing entities such as registry providers, performance analysis companies, or specialty societies which gather benchmarking data.
- Receiver entities which collect quality reports as part of a reimbursement process.
Among these stakeholders, you can imagine several kinds of data exchange:
- Transport of the new or revised definitions of measures from measure authors to all the other stakeholders in an unambiguous structured format rather than by verbal documents
- Transport from EHRs to existing Physician Quality Reporting Initiative (PQRI) registries and any new PQRI registries
- Transport from EHRs to CMS, where the EHR performs all filtering, aggregation, measure calculation, and measure submission functions
- Transport through an intermediary where the EHR performs filtering of data elements needed for the measure, but a third party “quality report processing entity” aggregates data, calculates, and submits the measure to CMS
- Transport through multiple intermediaries where the EHR generates data, but a “data collection assistant” intermediary filters data for the measure from all data of the patient, then submits relevant patient-level data to a “quality report processing entity” intermediary that aggregates, calculates, and submits the measure to CMS.
The HIT Standards Committee has recommended standards for 2-5, but these standards have varying degrees of maturity. The work of the next several months will be to fill gaps and accelerate adoption of the standards needed to support these exchanges.
The Clinical Operations matrices include standards and implementation guidance (health outcomes priority, meaningful use measure, subject area, 2011 implementation guidance, 2013 implementation guidance, and future trajectory) for clinical care and clinical quality. You’ll find plain English explanations of these standards here. You’ll find a description of all the “dependencies” (when a standard is selected there are often supporting standards required) here.
We welcome your thoughts about this work to accelerate interoperability. We’ve done our best to create a glide path from 2011 to 2015 which balances the need for secure interoperability, existing installed systems, and the change management required to embrace a more connected healthcare future.
– Dr. John Halamka, HIT Standards Committee Co-Chair
Tags: FACA, HIT Standards Committee
Benefits of an Incremental CDA Strategy to Support Meaningful Use
We at Siemens applaud and support the work of the HIT Standards Committee in to accelerate adoption and implementation. We strongly believe that efficiency, and avoidance of unnecessary complexity and barriers, are important to advance interoperability, meaningful use, and health outcomes.
The EHR Association expressed its views well in Mark Segal’s blog reply dated November 5th, 9:05am, with which we agree. Another key, but subtle point is that all the HITSP CDA documents leverage a common reusable set of data modules (documented in HITSP C83).
We think that both CCR and CCD can help coordination of care. But, CCR and CCD are only an excellent beginning, and the debate over “CCR and/or CCD” is not the right question. The purpose of CCD was to align CCR with CDA. This alignment was required because CCR lacked several sections and the architecture needed to provide for similar communication in many other use cases. For example, a hospital discharge represents an important transfer of care, and this communication is typically done though a Discharge Summary. A Discharge Summary contains many of the same sections as a CCR such as a problem list, and a medication list. But, a Discharge Summary also includes additional sections such as Hospital Course, and for hospital systems it is important to clarify which medication list is being referenced (admission, discharge, active, or administered). These cannot be represented adequately in CCR.
Alignment of data in CDA is work that the Standards Committee has already done. Many vendors have been going down this path for at least two years, and it would be counterproductive to change that path now. For example, doing CCR plus PQRI plus CDA Encounter (Discharge) Summary would all be XML based, but would have no commonality in data representation among them. On the other hand, using CCD (HITSP C32) + QRDA (HITSP C105) + Encounter Summary (HITSP C48) would have major reuse of data content, structure, terminology, etc. The CDA and C83 infrastructure means that we don’t need multiple ways to represent the patient’s ID, or the patient’s problem, or a patient’s allergy. That’s a good thing.
Once someone has started with CDA (perhaps via CCD), that investment helps fulfill so many other objectives, including but not limited to Quality Reporting, Syndromic Surveillance, Public Health Reporting, Patient Privacy Consents, family history, and personal healthcare monitoring. For the ‘little guy’ (perhaps a small PHR vendor), alignment on CDA+C83 means that the same medication list from a hospital discharge summary created for other purposes, could be imported into a the PHR. Alignment on CDA means that there is consistency in the way patient identifying information looks in a consent document and for the symptom review sheet they create for their next visit to their PCP. As CDA is leveraged, the value can grow significantly over time, without requiring a major increase in development, even for future objectives not known today.
In summary, we agree that “starting small” (e.g., just with the CCD to support provider-provider and provider-patient exchanges), and building on that momentum into the future (expanded CDA use per HITSP specs) supports both the “glide path” and yet moves inexorably toward the goal of semantic interoperability to improve healthcare for us all. The argument for “simplicity” as it applies to one use case should not be used to lead to multiple standards and dilution of effort. To make most efficient use of the HIT resources spread across hundreds of vendors and thousands of healthcare organizations, we believe that the most “bang for the buck” can be achieved through endorsing the growing CDA family of standards and implementation guides, including CCD.
Agree or Disagree:
19 
7 (+12)
Please remove the nonmeaningful measure: Generic Drug Usage Within the Inpatient Setting
We suggest that the proposed MU measure “% of all medications, entered into EHR as generic, when generic options exist in the relevant drug class [EP, IP]” is not a truly meaningful and helpful measure, at least not for IP in 2011.
Firstly, there is a gap with no NQF-endorsed measures for this purpose, so even if the measure were useful, there is inadequate lead time to add this measure to existing EHR systems in the less than 11 months left before the first MU year begins. Developers can’t even start until the measure is defined (which we’ve heard would at best be Spring 2010, if then).
Secondly, if the purpose of the measure is to affect prescribing practices to reduce cost, it will be unlikely to achieve those outcomes in inpatient settings. The use of generic medications and restrictive formularies are routine practices in hospital facilities that serve to reduce overall drug expenditures. This practice is typically driven by hospital policy that is set forth by the Medical Staff via the Pharmacy and Therapeutics Committee. Consequently, the hospital policy may state that it is acceptable for the hospital pharmacy to substitute generic equivalent products whenever possible. In some cases, this may be incorporated in to the medical by-laws and/or physician credentialing process. This differs from the ambulatory scenario (especially without eRx) where the formulary varies depending on which retail pharmacy the patient goes to have his prescription filled, and also because the ordering physician is not constrained by a restricted inpatient formulary.
Many hospitals participate in national buying groups that offer volume discounts to their members. In these situations, either a branded or generic product may be the lowest priced product for the Pharmacy to purchase. In this case, the pharmacy will purchase the contracted product, unless the drug wholesaler cannot provide it.
The tracking of generic drug orders is not a meaningful practice in the hospital setting since the purchasing and prescribing decisions are not typically driven by an individual physician or pharmacist. Therefore, we recommend that this measure be removed and limited to the ambulatory setting only.
Agree or Disagree:
15 
7 (+8)
I’d like to bring to your attention PDF Healthcare. PDF Healthcare is NOT a standard, although it meets all the criteria mentioned, above, by Dr. Halamka and is supported by two Standards Development Organizations, ASTM and AIIM. In other words, PDF Healthcare specifies a well-defined approach that supports a business process (secure data exchange) and: (1) has been agreed upon by a group of experts (a consortium of healthcare IT leaders and thinkers); (2) has been publicly vetted (via the ASTM and AIIM protocols); (3) provides rules, guidelines, or characteristics (via the Best Practices and Implementation Guides); (4) helps to ensure that materials, products, processes, and services are fit for their intended purpose; (5) is available in an accessible format (PDF Reader is available around the world); and (6) is subject to an ongoing review and revision process (version 2 of the Implementation Guide will be published by ASTM and AIIM by end 2009).
PDF Healthcare is a Best Practices Guide (BPG) and Implementation Guide (IG), with versions 1 published in 2008 by ASTM and AIIM and authored by a voluntary committee of healthcare industry consultants, vendors, thought leaders, and users. Again, PDF Healthcare is NOT another standard. PDF Healthcare (i.e., its BPG and IG) describes (generally unknown) attributes of the Portable Document Format (PDF — an international, open, ISO-ratified and published standard, originally created by Adobe Systems, Inc., but since July 1, 2008, developed and maintained by ISO) – freely viewable on almost every netbook/laptop/desktop around the world – to cost-effectively facilitate the capture, exchange, preservation, and protection of health information. Such attributes include the ability for healthcare providers and consumers to develop secure, electronic WRAPPERS (a.k.a. containers) that store and transmit relevant healthcare information, including but not limited to personal, handwritten documents, (structured or unstructured) clinical notes, (structured) laboratory test result reports, (unstructured) word-processed / text summary reports, electronic forms, scanned document images, digital diagnostic images, photographs, and signal tracings (e.g., electrocardiograms [ECGs]). PDF Healthcare maintains any well-formed eXtensible Markup Language (XML), allowing any standardized data set (e.g., the CCR, the CDA, etc.) to be embedded in a PDF and then linked to the actual display of that data, retaining the XML. (As you probably know, XML supports what is seen on the screen when the CCR or CDA are encoded.) Currently, many providers (e.g., Stasia Kahn, MD in No. IL) use the CCD and PDF Healthcare to send information from their EHR to referring or primary care physicians’ EHRs (if they have EHRs; if no, they can view).
For example, if a consumer, provider, or provider organization must send a patient’s (structured) medication list and (unstructured) radiology exam result report, let’s say from an office EHR, to multiple physician offices — some with office EHRs, some without — the consumer, provider, or provider organization is able to embed those documents in the PDF container and securely send them. If the reports were sent to a provider who does not have an office EHR, the receiving provider can simply (and freely!) view the documents (and / or print them to paper). (Also, the receiving provider can print the documents to paper from his/her smartphone without the need of a computer!) However, if the reports were sent to a provider who does have an office EHR, the EHR can consume the XML data in the PDF container and populate the recipient’s EHR.
Agree or Disagree:
37 
15 (+22)
I would like to briefly expand on the very informative post by Ms. Kohn. First, I would like to share links to in depth information found at AIIM, http://www.informationzen.org/group/pdfhealthcare & http://www.aiim.org/article.aspx?ID=31832. I hope these links provide even more detail to the depth and breadth of PDF Healthcare.
Of particular note, I wanted to call out specifically that a well constructed PDF document has applicability not only as a familiar paradigm for people to engage with, but also, it is useful and applicable to machine-use as well. As Ms. Kohn pointed out, PDF Healthcare is intended to help illustrate how the attributes of PDF can be used within the context of the healthcare ecosystem. The needs of people (providers, and machines create a widely varied set of requirements that define how information is collectible, discoverable, accessible, available, readable, indexable, secure, authentic, controllable and archivable. In it’s open, native form, PDF has the ability to provide information that meets each of these requirements with familiarity and ubiquity.
Agree or Disagree:
13 
8 (+5)
Note that HITSP has recommended
C62 (http://www.hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=4&PrefixNumeric=62)
and CAP-120 (http://www.hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=13&PrefixNumeric=120)
which also address this use case, but in a slightly different way.
C62, references the use of PDF/A embedded in a CDA. (eg, the wrapper is the CDA XML, the content is the PDF, rather than the other way around.)
Agree or Disagree:
14 
7 (+7)
Social comments and analytics for this post…
This post was mentioned on Twitter by ahier: New on the ONC Blog: What is a Standard? http://bit.ly/MDqra by @JHalamka…
Agree or Disagree:
17 
8 (+9)
HIT STANDARDS COMMITTEE IMPLEMENTATION WORK GROUP
This blog is the follow-up to my testimony before the HHS HIT Standards Committee Implementation Work Group on October 29, 2009. The slides I used are enclosed and a part of the testimony.
E-Certus, Inc. is an IT solutions provider that uses structured data technology for innovative systems integration, products & services. It specializes in Second Generation XML (“SG XML”). This is XML + XLink+ Other features = SC XML.
SG XML uses computer coding and taxonomy to provide interoperability between disparate existing systems. Original XML can not provide interoperability between and among systems because of its schemas and heterogeneous extensions. While I applaud the efforts of the ONC to date, to the best of my knowledge, not one interoperable medical record has been transferred between clinical groups, updated, and made available to the next physician the patient sees. This undermines and makes virtually useless any “meaningful use” between a first line physician and a specialist the physician referred the patient to consult. XML is a decade old technology that was not completed when it was introduced and has failed to live up to its promise. This was why SG XML was invented.
The ONC has allocated hundred of millions of dollars to promoting regional health and stateside health information exchanges and has nothing to show for it. Now, these exchanges are renamed “data-sharing hubs” and the ONC is making an initial grant of $564 million to supposedly “get things started.” In addition, legacy health care information systems providers, consultants, and academics are all supportive of this approach in the same manner as the defense contractors support the F22 fighter, which was designed for the sole purpose of fighting the advanced fighters of the Soviet Union over the skies of Germany for air superiority. Today that is an anachronistic concept, but still pursued by the federal contractors.
Similar to the Defense Department contractors being well paid to prepare to fight the last war, the healthcare contractors and healthcare information technology providers are still focused on utilizing decade old information technology and pretending it will do in the next decade what it has been unable to do in the last decade. This approach is like Einstein’s definition of insanity, “Doing the same thing over and over again and expecting a different result.” Why don’t the Defense Department and Veterans Administration have interoperable healthcare records after a decade of trying?
A new information technology approach is needed in healthcare. We recommend that the ONC consider using XHTML technology with each patient having their own URL. This can accommodate XML, SG XML, and other technologies. All privacy, security, and authentication standards can be incorporated in it.
The remarkable work of HITSP the last years has produced a well defined and agreed upon path to “semantic interoperability.” Developing and harmonizing semantic standards is high level policy work and that process has gone exceptionally well given the constraints of the HITSP process. However, it will not provide “computer interoperability” unless the data standard is selected and enforced to support the semantic interoperability. It is not logical for the HIT Standards Committee to select a decade old standard like XML, when SG XML is available and has inexpensive software mapping tools to move form existing healthcare standards, e.g., HL7 and X12 to SG XML.
We recommend that the ONC undertake a formal feasibility study on the use of URLs and SG XML with XHTML for medical records. This is a less expensive alternative then continuing down the current path with obsolete technology that will not provide interoperable medical records. We submit that the ONC re-evaluate its commitment to data sharing hubs and ask, why are these data sharing hubs are necessary at all? Why not have each patient with a unique identifier, their URL address, and use the simplistic power of the Internet to achieve interoperability? Will another $1billion failed experiment in interoperability be necessary before healthcare considers an alternative approach?
Our enclosed slides summarize our recommendation. I am having trouble getting them into the blog, and shall e-mail to Aneesh and his Executive Assistant, who can porbably input them. For more information or a copy of the slides please contact: rtmcnamar@e-certus.com.
Hot debate. What do you think?
12 
9 (+3)
I am not finding any references for SG XML and I don’t believe this is a standard . Could you link to some additional info?
The URL idea is interesting. How is it different than something like HealthVault in concept? Each provider would have to create something that responds to this URL on first seeing a patient. How would they know if the patient had already gotten a url from another provider? How would it become the patients URL? How or who would control access? I am sure you can imagine many more questions like this as a URL is hosted and comes with all the issues of the web and the issues of privacy and security.
The e-certus.com website seems to be dead, is this the real site?
Agree or Disagree:
13 
7 (+6)
In the current health IT standards discussion, my question is not “what is a standard?” but “which standard?” Organizations implementing technical solutions for health IT — whether EHR systems or information exchange capabilities — and the vendors that provide the technologies to enable those solutions may be challenged to comply with both the HITPC standards and conformance criteria and the criteria necessary to achieve conformance with the underlying standard selected for particular health IT purposes. Conforming implementations of technical standards such as SAML or ATNA are obligated to support multiple technical alternatives for some functions (such as confirmation methods for SAML assertions or audit trail transport mechanisms in ATNA), while the use of those standards in the health IT context constrains their implementation to a single alternative. There are also relationships or dependencies among technical standards (such as the set of IHE standards often implemented together by healthcare organizations) that should be considered, particularly when a single standard is withdrawn or deprecated, as has been recommended for EUA. Organizations shouldn’t be forced to choose between complying with relevant industry-specific standards and satisfying standards promulgated for meaningful use.
Agree or Disagree:
14 
7 (+7)
[...] and crosswalked it with the 17 quality metrics required for meaningful use, as documented on the new HHS Blog. In summary, the measures will include treatment process and outcomes data for: Acute Bronchitis [...]
Agree or Disagree:
11 
7 (+4)
This is a very helpful recap…can you please post the .XLS’s of the reference documents.
Agree or Disagree:
12 
8 (+4)
Love the work and effort underway, the goals and frameworks are a great point in reference.
Have a background in enterprise data standards, B2B, and now consumer applications and wanted to add a few thoughts to the dialog.
In terms of opportunities for accelerating adoption, would like to suggest a pattern of “100% done” for “smallest unit of value”. In this case, supporting a mechanic all the way down to implementation of being able to share medications between parties seems to be the lowest hanging fruit.
Setup an agreement to “by any means necessary” support the ability for a patient to interoperate with everyone in their care team (doctor, nurse, pharmacy), and show the role of the government and government services in getting the job done.
The premise is that if we look for a bit just at this problem, with the same people in the room, we see new services and architectures that important to the picture. For example, what is “done” from a consumer data point of view when we look at the PHR. Does it have NDCs, RxNorms, either, both, neither? When we look at the chain between person and Federal standards, what do we consider the proper end state. For example, in this architecture, is it implied that there is a Federal Registry that “knows” every medication assignment? This is a practical question that might be very useful to extend further than standards, and into implementation design to further explore.
One trend this takes advantage of is where the person’s network and devices become stronger, and more real-time. In essence, asking the question what if the Federal standards and the person’s personal application are synch…before the system in the middle.
Best, thank you for the opportunity to share.
Agree or Disagree:
13 
7 (+6)
I like the “Gold Star” idea to declare a long term goal for new standards implementation but in the short term map what exists to new standards at the border of the organization rather than convert all existing legacy systems. One of the strategic problems with making such huge changes as are envisioned by these efforts is not only funding the new systems needed, but converting existing systems to meet the new criteria.
To have a national system that is truly interoperable is a massive effort. And keeping content and transmission as separate standards will make the transition smoother. When it comes to standards, it is best to keep it simple…
Agree or Disagree:
22 
8 (+14)
Funny… someone clicks disagree but doesn’t have the ability to articulate what it is specifically that they disagree with (or maybe they are just disagreeable
Maybe the ‘disagree’ was because some folks believe that when it comes to standards it is best to keep it complicated? Oh well, I always enjoy a good debate, but it is difficult to know exactly where the perceived error is in the previous comment…
Agree or Disagree:
14 
8 (+6)