About MHDC

Founded in 1978, MHDC, a not-for-profit corporation, convenes the Massachusetts’s health information community in advancing multi-stakeholder health data collaborations. MHDC’s members include payers, providers, industry associations, state and federal agencies, technology and services companies, and consumers. The Consortium is the oldest organization of its kind in the country.

MHDC provides a variety of services to its members including educational and networking opportunities, analytics services on both the administrative and clinical side (Spotlight), and data governance and standardization efforts for both clinical and administrative data (the Data Governance Collaborative/DGC and the New England Healthcare Exchange Network, respectively).

About DGC

The DGC is a collaboration between payer and provider organizations convened to discuss, design, and implement data sharing and interoperability among payers, providers, patients/members, and other interested parties who need health data. It is a one stop interoperability resource. The DGC primarily focuses on three areas:

1. Collaboration: Development of common understanding of and specifications for data standards, exchange mechanisms, and what it means to participate in the modern health IT ecosystem
2. Education: helping members understand their regulatory obligations, the data and exchange standards they're expected to use, and modern technology and related processes
3. Innovation: Identification and development of projects and services needed to make modern health data practices and exchange a reality

General Comments

This section includes general comments about the guidance document.

Comment Window

We respectfully request CMS provide additional time to comment on documents such as this one and its companion document Draft eCQM Logic and Implementation Guidance which, unfortunately, we will not be able to comment on at this time.

We are providing high level comments about the guidance document but did not have time to provide a more detailed response in the allotted time. We hope to have additional opportunities to provide feedback in the future.

Order of Contents

Participants in our Data Governance Collaborative agreed that it would be helpful to have the building blocks section come first in the guidance as that’s where the concepts and terminology are introduced. These terms are used, mostly without explanation, in the naming conventions section that currently comes first.

Intended Audience

The intended audience of this guidance is not always clear. Some of the document appeared oriented toward people who had never heard of a quality measure and certainly not an eCQM before. Some of it seemed to assume a core of prior knowledge that such an audience would not have. We respectfully suggest that CMS consider the audience they are trying to serve with this document and orient the content and the organization of the document to present material that audience is not expected to know in an order that introduces it sensibly to them. If some content is meant to be review or presented to ensure consistent understanding of terms or concepts that may have slightly different meaning in other contexts, being transparent about that intent would be extremely helpful in setting expectations of readers.

Address FHIR

This guidance is designed solely for pre-FHIR measures which is totally fine, but it would be helpful to be specific about this and to point out areas that will or are likely to change once the measures are migrated to FHIR. Our Data Governance Collaborative is extremely interested in the migration to FHIR and it was sometimes difficult to sort out exactly which elements or aspects of the measures would still be relevant and exactly what would change once they supported FHIR.

Naming Inconsistencies

We were struck by inconsistencies in file naming, particularly around use of the ID in file names. In some cases the entire name uses the pattern “IDvVersion.extension” and in others it uses “ID-vVersion-OtherUnexplainedConstants.extension”

This type of inconsistency will lead to mistakes and confusion. We strongly recommend picking a specific pattern and using it everywhere. If needed to avoid duplication another segment with some type of description could be amended to the end of the core string (i.e. to distinguish between multiple XML files).

ID vs Identifier

In general, the terms ID and identifier are interchangeable – ID is essentially an abbreviation for identifier. However, CMS makes a clear distinction between those terms in this document, indicating that the identifier is one component of the ID. We respectfully suggest altering this terminology to comply with standard usage.

One option would be to call what is now the ID the composite ID, but this would require consistent application of both terms to avoid confusion. Alternately, another name for the internal segment could be devised.

Using Examples to Document Rules

We noticed that in many places in this guidance examples – often just one example – are used in lieu of explanation of rules. This leads to uncertainty and confusion as it is generally unclear which content in the example(s) are required to be as supplied and which are present as is because of choices made by the author of the example(s). Examples are great to illustrate guidelines after they are clearly presented but, respectfully, are not sufficient on their own.

Download and File Open Instructions

We were surprised by the inclusion of basic file download and file open instructions in a document of this sort. These are very basic instructions that anyone using a computer should have mastered in the first weeks of their usage. Their inclusion in a document of this sort seemed out of place and could potentially be construed as tone deaf or worse by some readers.

Exclusion vs Exception

Participants in our Data Governance Collaborative had an extended conversation trying to tease out the difference between an exception and an exclusion but did not come to a satisfactory conclusion. The MHDC Quality Measures specification, currently a flat file exchange via Secure FTP but in the early stages of being moved to FHIR, includes the concept of exceptions but not exclusions. It would be helpful to have clear definitions of the two and a discussion of how they are different.