Healthcare Standards: March 2012

Friday, March 30, 2012

Testing for MeaningfulUse Stage2 with Consolidated CDA

Nope, sorry, my schematron generator isn't done. This is actually on a separate topic.

My rant from yesterday inspired a number of questions, key among them being how would you test the use of Consolidated CDA to support Meaningful Use. This is actually a good thing, because where we need to be going with Consolidated CDA is towards testing and implementation, not shaking things up again and therefore scaring away implementers (which is what happens when you tell them that the standard is going to change).

Let's assume that ONC and CMS clean up their definitions of a summary care record as I've previously suggested (I have a few suggested edits that help even further).

There are three criteria that mention summary of care record:

170.314(b)(1) Transitions of care -- incorporate summary care record.
170.314(b)(2) Transitions of care -- create and transmit summary care record.
170.314 (e)(1) View, download, and transmit to 3rd party. ... (B)(2) A summary care record ...

I'll skip view, download and transmit because that is all after the fact once you've created an appropriate document from the Consolidated CDA.

For create and transmit above, one of the questions that arises is which CDA Consolidation document should be created. With the exception of the Unstructured Document, I would allow you to test with any one of them (you could choose to test with more than one, but only one is sufficient). You would have to demonstrate several things:

The document you create is valid according to one of the CDA Consolidation Guide document templates that contains structured data.
The data elements in that document meet the meaningful use criteria found in my proposed section 170.208(a)
The data elements in that document match the standards specified for them in the Standards rule (see my proposed 170.208(b) at the same location)

To verify #1, you could used MDHT, the CDA Consolidation Schematron that I expect to appear on the S&I Framework Wiki, or a schematron generated from the Trifolia database (which I'm still working on).

Not every document in the Consolidated CDA tells you how to meet the meaningful use requirements explicitly. This post explains which Consolidated CDA sections can be used to match up to the data elements. So, to verify #2 above, you'd need a separate test to ensure that the document under test include at least one (and possibly more than one) of the sections which I've mapped to the data elements in the table.

Finally, to verify #3, you'd need to add some tests on vocabulary, where Meaningful Use requirements are stronger than those in the Consolidated CDA specifications. That's a few additional assertions in a separate schematron, or similar testing capability.

Incorporate is a defined term in the proposed rule. It means "to electronically import, attribute, associate, or link information in EHR technology."

As defined, it could match up with IHE "Discrete Data Import" option, "Section Import" option, or "Document Import" option. If you proudly explain that you've imported this whole document into your EHR to the test examiners, and then show them where they can pull up the document, my personal feeling as a patient is that I'd hope that would fail. As I read the rule, the goal behind incorporate is closer to what it means for lab results, which is really import, but they allow for other alternatives, and I've seen some really creative ideas here. There are some real challenges with respect to incorporate vs. import which I will address in a separate blog post.

Some things might need to be incorporated at a "Section Level", like the care plan, where the details are not yet well standardized, and text is the norm. But for other things, like problems, medications and allergies, what I expect you will need to show is a patient record that has nothing, then you perform an import, then you show the examiners where each required data element now appears in the EHR. BTW: This is the kind of testing that IHE would do for the discrete data import option.

We'd need to understand in the regulation, which of the data elements are expected to be imported discretely, and which could be imported at a higher level (e.g., section or document). The data elements for which vocabulary is proposed (or would be if it were available in the case of allergies), is probably the maximum limit for could be reasonable expected to be "discretely imported". The remainder could be imported at a higher level (section or document).

That leads to the following clarification for 170.208(b) in my previous suggestion:

§170.208 Summary Care Record
...
(b) Standards When supplied in an electronic form, the summary care record shall be formatted according to the standards specified in §170.205(a)(3):
(1) Document. The document shall contain structured entries for data elements described in section 170.208(a)(1) through 170.208(a)(17)
(2) Vocabulary. The vocabulary used for structured entries must conform to the following standards:
(i) Race and ethnicity. The standard specified in § 170.207(f)
(ii) Preferred language. The standard specified in § 170.207(j)
(iii) Smoking status. The standard specified in § 170.207(l)
(iv) Problems. At a minimum, the version of the standard specified in § 170.207(a)(3)
(v) Encounter diagnoses. The standard specified in § 170.207(m)
(vi) Medications. At a minimum, the version of the standard specified in § 170.207(h); and
(vii) Reserved (For Allergies)
(viii) Procedures. The standard specified in § 170.207(b)(2) or § 170.207(b)(3)
(ix) Immunizations. The standard specified in § 170.207(i)
(x) Laboratory test(s). At a minimum, the version of the standard specified in § 170.207(g)

The bold and italicized text is new. It is what makes sure that developers can only use the documents with structured entries, and so prevents someone from trying to use the "Unstructured Document" to meet MU requirements.

IHE and Meaningful Use Announcements

These crossed my desk over the last couple of days ...

IHE Radiology Technical Framework Supplements Published for Public Comment

The IHE Radiology Technical Committee has published the following supplements to the IHE Radiology Technical Framework for Public Comment in the period from March 30 through April 30, 2012:

These profiles will be available for testing at subsequent IHE Connectathons. Comments submitted by April 30, 2012 will be considered by the Radiology Technical Committee in developing the trial implementation version of the supplements. The documents are available for download at http://ihe.net/Technical_Framework/public_comment.cfm. Comments should be submitted at http://ihe.net/radiology/radiologycomments.cfm.

Resources available on Standards and Certification NPRM; check out the public comment template

On March 7, 2012, the Office of the National Coordinator for Health Information Technology (ONC) published a notice of proposed rulemaking (NPRM) that proposed revisions to the initial set of standards, implementation specifications, and certification criteria adopted in a 2010 final rule. The 2014 Edition EHR certification criteria were jointly proposed with the Centers for Medicare & Medicaid Services' (CMS) NPRM on the EHR Incentive Programs – which provides incentive payments to eligible health care providers that adopt Certified EHR Technology (CEHRT) and susequently demonstrate "meaningful use."

Public comments will be accepted through Monday, May 7, 2012. ONC will take into consideration all timely public comments as it develops a final rule, which we anticipate publishing this summer. We encourage commenters to submit comments electronically at regulations.gov. To enhance public participation in the rulemaking process, ONC has made available on its website HealthIT.gov a copy of the rule in Microsoft Word format and is piloting a "Public Comment Template" meant to provide the public with a simple and organized way to submit comments.

Additionally, several educational resources are now available to illustrate the relationship of the 2014 edition certification criteria to the policy proposals in the ONC proposed rule. Visit www.healthit.gov/providers-professionals/meaningful-use-stage-2 to learn more.

Questions? Contact us at onc.request@hhs.gov.

Thursday, March 29, 2012

The Road to Hell...

... is paved with good intentions. -- Anonymous

My current frustration is with a proposal in HL7 Structured Documents to modify the CDA Consolidation guide to add clarifications needed for the proposed Standards and Certification rule.

I think it is the right idea, but the wrong approach for several reasons:

The idea that the industry needs guidance and clarification on how to implement the standard to meet the regulation is dead on. The problem is that we don't know what the regulation will say until it is finalized this summer.

Let's take a simple example: As currently specified, the guide uses the Problem Observation template for both the Problem List section, and several of the diagnoses sections (e.g., Discharge Diagnoses). That template says that the vocabulary for the problem @code SHOULD be selected from SNOMED CT. But the rule says that Diagnoses should be encoded using ICD-10-CM, and problems in SNOMED CT. So we could "fix" the guide to make ICD-10-CM one of the allowed vocabularies.

Now, the ICD-10-CM / SNOMED CT issue is already drawing a lot of attention in the proposed rule. There are three possible things that could happen, and some of them depend on what CMS does with respect to ICD-10-CM compliance. CMS could delay enforcement on the use of ICD-10, or they could choose not to. If they delay enforcement, it could be 6 months, it could be a year, we just don't know. Then, ONC could respond to what CMS does and to comments by: Dropping ICD-10 altogether and just using SNOMED CT (avoiding any issues), or staying the course (hoping that certification and meaningful use could help CMS with its ICD-10 issues), or allowing ICD-9 or ICD-10 or SNOMED CT (thinking that will create the path of least resistance for all involved).

There are good arguments for any of the three responses, and I'm hard pressed to predict what will happen. In every possible alternative, the Consolidated CDA guide actually supports the menu of choices that seem likely, because SNOMED CT is a SHOULD, not a SHALL requirement. If we guess right, there's no problem. If we guess wrong, then we've simply wasted our time, because we'll have to reclarify subsequently.

Let's look at another suggestion: Strengthen the CDA General Header constraints to require certain demographic fields and vocabularies: preferred language, race and ethnicity. As presently written, the General Header constraints are pretty good, and CDA already supports all the required fields. I'd actually like to see these constraints be adopted a bit more internationally. Strengthening the constraints weakens the ability to reuse the general header internationally (remember, IHE contributed a lot of its work to this effort, and it is used internationally). If we make Consolidated CDA too MU-centric, we confine it in a box that could prevent others from using it more broadly. As it stands today, the general header constraints work quite well in other guides, for example, in an EMS guide currently being balloted by HL7. But, if we modify them to support MU, then some data elements which may not be available at an accident site now become required. Yes, you could say "I don't know", but it's still more work.

I'm not a great shot. I'd much rather try to shoot a sitting duck (the final rule), rather than try to hit a duck in flight at night (the proposed rule).

What I really want to see is HL7 put together an informative document that teaches people how to USE the CDA Consolidation Guide to meet meaningful use requirements AFTER we know what those requirements are. What seems likely though, is that we'll put together something that doesn't address what implementers needs fully, and we may likely be having to go back and fix things later. That is a distraction, and a waste of valuable volunteer effort. This comes at a time when I'm trying to give developers a good grounding in what we already have; I feel in some ways like I'm trying to build a foundation in sand.

The choices to me are pretty clear cut:

Build something now to hit a target we can not identify well, and limit ourselves to those things that we are pretty sure we can predict, and fix it fully later, or;
Build something in a few months that will address all of the issues that industry needs.

It seems to me that our efforts would be better spent on #2. As I posted previously, and David Tao, and others in the S&I Framework efforts have determined, Consolidated CDA meets the requirements of the proposed regulations. We should stop trying to "fix it" to meet requirements that aren't even done yet, give the industry the time it needs to understand it, and then explain how to use it in a guide. If we take that approach, I'll be happy to help as much as I can.

Tuesday, March 27, 2012

How to say No Med Allergies in Consolidated CDA

Arien Malec raised the question on on twitter about how to record no drug allergies, but allergic to latex in Consolidated CDA.

@motorcycle_guy: How do you say "no med allergies but allergic to latex" in CCDA?
— Arien Malec (@amalec) March 27, 2012

No Drug Allergy
The answer for no drug allergy is below. It uses the model for negation and unknown that I talked about previously here in How to say No.

<act classCode='ACT' moodCode='EVN'>
<templateId root='2.16.840.1.113883.5.6'/>
<id root='55092E13-32D5-4e54-A4B2-B61B58901DD2'/>
<code code='48765-2' displayName='Allergies, adverse reactions, alerts'
codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/>
<statusCode code='active'/>
<effectiveTime>
<low value='20120216'/>
</effectiveTime>
<entryRelationship typeCode='SUBJ'>
  <observation classCode='OBS' moodCode='EVN' negationInd='true'>
      <templateId root='2.16.840.1.113883.10.20.22.4.7'/>
     <id root='654AB113-EAD6-43fd-8ABC-E55228690AB3'/>
    <code code='ASSERTION' codeSystem='2.16.840.1.113883.5.4'/>
    <statusCode code='completed'/>
    <effectiveTime>
      <low value='1972'/>
      </effectiveTime>
     <value xsi:type='CD' code='416098002' displayName='Drug Allergy'
     codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED CT'>
    <originalText><reference value='#Allergy-1'/></originalText>
    </value>
    <participant classCode='MANU'>
      <playingEntity classCode='MMAT'>
      <code code='410942007' displayName='drug or medication'
      codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED CT'>
    <originalText><reference value='#Allergen-1'/></originalText>
      </code>
        </playingEntity>
    </particpant>
   </observation>
</entryRelationship>
</act>

Translated, the inner observation reads: has no drug allergy to any drug or medication. The challenge with this is in the code for the playing entity. It doesn't actually match any of the value sets specified in Consolidated CDA for what goes in an allergy observation. There are three value sets specified in the guide:

One for a specific medication (RxNORM)
Another for class of medications (NDF-RT)
A final one for non-medication substances (UNII)

This isn't a specific medication, so RxNORM doesn't work. It is not a non-medication, so UNII isn't right either. So I should use a code for class of medications (that is a the superset), but I cannot find a code in NDF-RT for the class of all medications (if you can, USE IT instead and let me know what it is), so I used the SNOMED code for drug or medication.

Latex Allergy

For recording a Latex allergy, I'll take the same XML, and modify it thus:

Remove negationInd since I want to record the presence rather than the absence of an allergy
Change the value element code to the SNOMED CT allergy to substance code:
Replace the SNOMED CT code for "drug or medication" with the UNII code for Latex

Monday, March 26, 2012

An Informatics Model for HealthIT Standards

I was at a conference last week, and someone asked me if I'd be willing to write an Introductory article about Healthcare Standards. I agreed to do it, but as I was going through it I realized that I first needed to organize the standards into a model. The OSI 7 Layer model doesn't work, as this post explains.

Kinds of Standards
Standards are like potato chips. You always need more than one to get the job done. And just as potato chips come in all shapes and flavors, so do standards. NIST has a decent classification of standards in NISTIR 6014, but in the Healthcare IT space, that's not really how most folks think about them. Most people classify standards by function.

Functionally, Health IT uses a variety of standards for (in no special order) e-Prescribing, payment (including claims and elligibility), quality measurement, clinical care (including lab reporting, medical records, and imaging results), administration (registration & admission), public health management (ELR and immunization reporting), Health Information Exchange, and privacy and security.

The problem with classifying standards functionally is that it isn't sufficient to get to the level of a single standard. Lab reporting still requires a bunch of different standards used together to get a lab results interface working. So standards geeks like me break it down a little bit differently. In order to perform a particular function, (e.g., lab reporting), you need a stack of standards supporting different layers.

If we take the laboratory reporting function, we could:

Communicate over the Internet, using DNS for discovery, TCP/IP for basic communication, MLLP for framing (delimiting) a message, and
Use the HL7 Version 2.5.1 syntax and ORU message models for content, and
Identify Lab Orders and Results in LOINC, units of measure using UCUM, and body parts and organisms in SNOMED CT.

The OSI 7 layer model was one historical attempt to classify the stack, but it doesn't get at enough detail in the higher layers. The challenge with the OSI model today is that from the session layer (5), through the presentation layer (6) and application layer (7), protocols have become fractal. What was once considered an application layer protocol (HTTP), has become a building block upon which new protocols (e.g., SOAP and WS-*) are built supporting additional session, presentation and application models. And intertwined with the various layers are security protocols.

An Informatics Model for Health IT Standards

A new model for describing standards is needed. The model I use bridges between the technology space (OSI 7 Layer model), and the space that organizations like the US HIT Standards Committee and the Office of the National Coordinator work in, which is somewhere between technology and policy. Probably the best descriptor of that space is Informatics, a general term describing information science.

Transport

At the bottom-most layer is connectivity, which describes the set of standards that allow different systems to connect and communicate. This covers details about how two systems discover, initiate and engage in conversations. In the Health IT Informatics space, these are thought of as the "transport protocols", but in the technology space, that could mean any of the protocols traditionally assigned to many of the 7 layers in the OSI model.

Important sub-types of Transport standards include:

Discovery
Connection
Communication

Content

On top of transport we must describe the content that is communicated. This layer addresses basic syntax, data types, structure and meaning of that content. The content can describe simple data (e.g., an ECG Waveform), a summary of a clinical encounter, an order for a lab test, images (an X-ray) or other complex media (an MRI). Inside the content are specialized terms that communicate predefined semantics (vocabulary) or relationships (ontology) through the use of specific codes. The content is quite often structured, using some sort of model to represent various objects and relationships between them. Finally, content must often be rendered in order to be acted upon (e.g., images and documents) ,

Content is also fractal. Given the stack of standards that we use in Health IT, one piece of content may wrap around (envelope) another, supporting appropriate layering of transport, behavior or security for each system involved in the communication.

Important sub-types of content standards include:

Syntax

Data Types
Structure

Semantics and Modeling
Vocabulary

Classification
Ontology

Rendering

Behavioral
After content, we need to describe the services performed or behavior expected of each participant during the communication. This is perhaps the most difficult part of standards in the Health IT space. Defining specific behaviors to be performed can be done in the form of an algorithm to be performed (e.g., matching patient demographics, computing a hash, or encrypting content) or by describing the services which are provided (often in terms of what is done on the content and transport side).

Important sub-types of transaction standards include:

Algorithms
Services
Messages

Mapping Standards to the Model
Now that I've developed a model, the next test is to evaluate it against standards. Let's take a few different paradigms in Health Information exchange and look at how they match up.

SNOMED CT
SNOMED CT is an ontology standard. It not only identifies important terms, but also relates those terms to each other, for example, that disease X is a disorder of body part Y. As such, it embodies a certain amount of world knowledge in it that does more than just partition it into distinct kinds of things.

ICD-9-CM
ICD-9-CM is a classification standard. It identifies important terms, but does little to relate all of the different classifications it provides to other parts of itself. For example, there is nothing one "family" of codes in ICD-9-CM to another "family" of codes in that same system.

CDA Consolidation
The CDA Consolidation guide is a content standard. Syntax is based on XML and an XML Schema defined based on the HL7 Version 3 RIM (semantics and modeling), the CDA Standard (again modeling), and a variety of predefined vocabulary choices.

The DIRECT Project
The DIRECT Project is mostly a transport standard with some behavioral/service components.

IHE XDS
IHE XDS is again mostly a transport standard, with some service and content components. There is a good deal of content associated with the XDS Metadata. The fact that XDS fits into all three categories isn't surprising because it actually is an implementation guide describing how to use multiple standards to support an HIE use case.

NCPDP Script
NCPDP Script mostly addresses behavior at a message level. It's messages describe things like "New Prescription", "Prescription Change", or "Refill". The contents of the messages are described in terms of segments and fields (much like HL7 Version 2), with defined data types and vocabulary.

TLS
Transport Layer Security is mostly about behavior at a service level, with some notion of transport thrown in. As you read through TLS, you'll see that there are many services (encryption, authentication, non-repudiation, reliable communication) embedded in the standard.

A Note on Security

Throughout any communication, we must secure the information exchanged; making sure that that only authorized users or systems engage in communication, authenticating the identify of users or systems as needed, that secured functions are accessed in a controlled way, and that actions are logged to enable auditing. But security not a separate layer in the standards stack. It fits into, and takes advantage of transport, content and behavioral layers. Good security is designed in, not added as an afterthought. Because it is designed in at every level, it doesn't stand out as a separate layer in an an ontology describing the different layers of standards.

Friday, March 23, 2012

Crossing into MeaningfulUse Stage2 Standards Video

I'm in the stomping grounds of my youth in Valley Forge, PA at the Crossing the Infrastructure and HITECH Meaningful Use Divide conference. My reason for coming was to present on the new standards in the ONC Standards rule. These folks are Internet2 savvy, so the presentation was not only recorded, but also sent live to differnt parts of the US, Canada, Europe and elsewhere.

They missed the first few minutes where I started with my back to the audience and explained a bit about my jacket, but they did catch everything else.

On The Meaningful Use Stage 2 Rules

I've written a score and more posts on Meaningful Use Stage 2. This post serves as a quick link to all my writings on Stage 2 for those of you looking for an easy way to find something. New writing on Stage 2 will eventually be added to the end of this page, but you will also be able to find it by looking for the Stage 2 tag in the cloud to the right. This page can be found in My Favorites.

Posts on the Test Procedures

Posts on the Final Rule

What changed in the Meaningful Use Stage 2 Standards Regulation?
A detailed list of changes in the Standards Rule.
The Bare Essentials: Changes in Meaningful Use Stage 2 Standards
An executive summary of what changed in the Standards rule.
Changes to the Meaningful Use Incentives Stage 2 Rule
What changed in the Incentives Rule, including an Executive Summary
HL7 Standards and IHE Profiles in the Meaningful Use Stage 2 Final Rule
A list of HL7 and IHE Standards and Implementation Guides that you should have copies of.
Links to the Bookmarked Rule (via Corey Spears)
Links to the Bookmarked Final Rules that Corey Spears put together for us.
Are we Final yet for Meaningful Use Stage 2? Perhaps Not
QRDA Category III is named for Quality Reporting, but HL7 isn't done with it yet. The rule could change...
On Standards for Human Language and Meaningful Use
What happens when two requirements collided. CDA and Meaningful Use have different ways to express Human languages.
Stage 2 Final Rule Crosswalk from Meaningful Use Objectives to the Standards
What standards need to be used to meet that criteria? What certified capabilities do providers need? These tables will help.

Posts On the Proposed Rule

Summary of the Standards and Certification Rule
My initial reactions to 42 CFR 170
Objectives mapped to Certification Criteria
Mapping from 42 CFR 495.6 (Meaningful use objectives) to 42 CFR 170.314 (Certification Criteria)
Certification Criteria Crosswalk to Standards
Mapping from 42 CFR 170.314 (Certification Criteria) to 42 CFR 170.20X (Adopted Standards)
Thoughts on the Incentives Rule
My initial reactions to 42 CFR 496
A Summary Care Record by any other name ... is as clear as mud.
Part 1 of a four part series in which I point out a problem across the proposed wording in the Certification and Incentives rule.
Defining a Summary Care Record
Part 2 of a four part series in which I map the definitions to a set of named requirements and show that they aren't really all that much different.
Using the CDA Consolidation Guide to make Sense of Summary Care Records
Part 3 of a four part series in which I take the requirements from part 2 and map it to the CDA Consolidation Guide document, section and entry templates.
There can be only one: What the Summary Care Record should look like
Part 4 of 4 addresses how we fix the problem in the rules.
Time to Ship It
In which I address the question of whether CDA Consolidation guide is good enough, or if we need more (spoiler, we don't need more).
Patient Engagement is a Two-way Effort
In which I address the issue of measuring providers on what patients do.
Testing for Meaningful Use Stage 2 with Consolidated CDA
In which I explain what the testing criteria would look like to address questions about which document you must generate (at least one of the structured documents in Consolidated CDA), and which you must be able to "incorporate" (for lack of a better term).
How does the ICD10 Delay Impact Meaningful Use Stage 2
We had a delay in MU Stage 2 that helped coordinate Stage 2 and ICD-10 implementation, and now we have an ICD-10 proposed delay that undoes that. How could this impact Stage 2 implementation?
Writing to and Reading From /dev/nul in Meaningful Use Stage 2
Where I explain some missing stuff from Stage 2 that means we could be writing to the bit bucket, and how the lack of backwards compatibility means that we cannot read from Stage 1 history.
On Vocabulary for Smoking Status
In which I describe a decent value set to support smoking status from SNOMED CT.
When Clinical Documents are Not Enough
Why CDA isn't enough to support EHR migration.
Harmonizing Value Sets in Meaningful Use Stage 2
In which I discuss issues about value sets needed for Meaningful Use and the quality measures.
Two IHE Profiles for Meaningful Use Stage 2
In which I describe two IHE profiles that support Meaningful Use Stage 2, one on the HL7 Infobutton standard, and another supporting reconciliation of problems, medications and allergies.
Q&A from the HL7 Meaningful Use Webinar
I answer about 30 odd questions from the webinar that I gave.

Thursday, March 22, 2012

IHE Patient Care Device Technical Framework Volume 3 Published

IHE Patient Care Device Technical Framework Volume 3 (PCD TF-3) Published

The IHE Patient Care Device Technical Committee has published the following Technical Framework Volume as of March 21, 2012:

Vol. 3 (PCD TF-3): Semantic Content

The document is available for download at http://www.ihe.net/Technical_Framework/index.cfm. Comments should be submitted at http://www.ihe.net/pcd/pcdcomments.cfm.

Wednesday, March 21, 2012

Interconnected Health 2012

If I could go, I would. Since I can't the least I can do is promote it, especially as it's being hosted by four organizations I have a great deal of respect for (HL7, HIMSS, OHT and OMG). OMG and HL7 have been doing this conference for the past few years and they were formerly known as SOA In Healthcare. SOA is great for those who know what it means, but for those that don't the new title is much better, and I expect the conference will be even better than prior years too.

Tricky testing bits in CDA Consolidation

My Grandmother was a fanatic about cleaning. One day while she was visiting our house, she decided to clean the kitchen. As she was doing so, she noted that doors in it that hid our heater and air conditioning system were dirty, so she decided they needed cleaning too (the system drew air and therefore lint into the slats). She dug around beneath the sink and found a brush that would go between the slats, but before she used it, she decided it needed cleaning too. When I first heard my mom tell this story, I laughed, but today I find myself in a similar situation, in this case, in my own fanaticism about testing and implementation of the CDA Consolidation Guide.

I really want to write a post on moving from the HITSP C32 (version 2.5) to the CDA Consolidation guide. Before I could do that, I had to make sense of what a Summary Care Record was in the meaningful use regulations. The next step in my process is to take a valid C32 and migrate it to become a valid CCD 1.1 according to the Consolidation guide. But, before I can do that, I need to be able to validate that the CCD 1.1 that I create is in fact correct. I need a Schematron, but since none was delivered with the Consolidated Guide, I have to build one. I could do it by hand, but I’d much rather automate that process.

Where it gets tricky
So, I’ve been working on a Schematron Generator for the Trifolia Database. One of the problems that I’ve run across is how to deal with constraints that suggest that a particular data element having certain characteristics exists in the document. The pattern associated with this goes something like this:
count(dataElement[SHALL(this) and SHOULD(that) and MAY(theOtherThing)] = 1

A simple example of this is CONF:9477 which reads:
1. SHALL contain exactly one [1..1] templateId (CONF:9477) such that it
a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.1.1" (CONF:10039)

This translates into:
<sch:assert flag="SHALL" id="CONF-9477-branch"
test="count(cda:templateId[ @root='2.16.840.1.113883.10.20.22.1.1'])=1">

And that is exactly what I want in that case. But where it gets challenging is when you have not just SHALL, but also SHOULD and/or MAY constraints associated with the “such that it” clause. An example of that is in CONF:8662

8. SHOULD contain at least one [1..*] participant (CONF:8662) such that it
a. SHALL contain exactly one [1..1] @typeCode="VRF" Verifier (CodeSystem: HL7ParticipationType 2.16.840.1.113883.5.90) (CONF:8663).
b. SHALL contain exactly one [1..1] templateId (CONF:8664) such that it
i. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.1.58" (CONF:10486).
c. SHOULD contain zero or one [0..1] time (CONF:8665).
i. The data type of Observation/participant/time in a verification SHALL be TS (time stamp) (CONF:8666).
d. SHALL contain exactly one [1..1] participantRole (CONF:8825).

In that case, when the SHOULD rules are firing in the context of the Observation (where this constraint appears), what I’m generating right now is:

<sch:assert flag="SHOULD" id="CONF-8662-branch"
test="count(cda:participant[@typeCode='VRF' and
count(cda:templateId[@root='2.16.840.1.113883.10.20.1.58'])=1
and count(cda:time)<=1 and
count(cda:participantRole)=1])>=1">

The parts in bold represent things that must be there, and italic, things that SHOULD be there.
What I need to do with this assertion is break it into two parts. The first part executes in the context of the observation and only looks for shall requirements:

<sch:assert flag="SHOULD" id="CONF-8662-branch"
test="count(cda:participant[@typeCode='VRF' and
count(cda:templateId[@root='2.16.840.1.113883.10.20.1.58'])=1
and count(cda:participantRole)=1])<=1">

The second part executes in the context of the observation/participant[@typeCode='VRF' and count(cda:templateId[@root='2.16.840.1.113883.10.20.1.58'])=1 and count(cda:participantRole)=1] and only looks for SHOULD requirements:
What it would say is:

<sch:assert flag="SHOULD" id="CONF-8662-branch" test="count(cda:time)<=1">

Cleaning out the Lint
What becomes really challenging is reporting on cda:participant elements which are intended to meet the criteria SHALL/SHOULD internal criteria, but don’t for some reason. From a testing perspective, this is a LINT style check (you did this, is that what you intended). You have something that might qualify (the participant), and you want to test to see if it does. These sort of tests prevent errors, but violating the test criteria (not really a constraint) might have been intentional (as in cases where you intentionally write a for loop with an empty body).

For example, in the context of an observation, report on participants that don't meet the shall sub-criteria (see 8.a through 8.d above), in case those participant elements were intended to.

It’s going to take me some more time to think this part through. I need to get the SHALL/SHOULD/MAY tests working right. I won't focus a lot of attention on LINT style (did you really mean to do that) checks right now, because I too need to ship.

-- Keith

P.S. If you were reading carefully, you probably noted that count(cda:time)<=1 isn't all that useful. What it needs to do for SHOULD rules is raise the lower bound from 0 to 1, which will result in count(cda:time)=1 which will do what we want. I have a fix for that that I'll address when I refactor again.

P.P.S. The rules around participant should be reconstructed to just focus on the required templateId,

8. SHOULD contain at least one [1..*] participant (CONF:8662) such that it
a. SHALL contain exactly one [1..1] templateId (CONF:8664) such that it
i. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.1.58" (CONF:10486).

Then there should be other rules based on that templateId. That would resolve the problem for THIS case, but there are possibly other cases that look like this that wouldn't be addressed.

Tuesday, March 20, 2012

Patient Engagement is a two-way effort in MeaningfulUse Stage2

This question came to me via Linked In:

I know CMS is trying to push patient engagement, but how can a practice/provider prove 10 percent and, also, why only 10 percent if it is made available to half of patients?

Secondly, this means meeting meaningful use hinges on the patients and is out of the provider’s control. Is that fair? If they are not engaged, they are not engaged. And what if patients are not wired to see and access their records, such as rural areas?

Before I get into details, let's look at what the rule states:

§495.6 (j)(10) Provide patients the ability to view online, download, and transmit their health information within 4 business days of the information being available to the EP.

More than 50 percent of all unique patients seen by the EP during the EHR reporting period are provided timely (within 4 business days after the information is available to the EP) online access to their health information subject to the EP's discretion to withhold certain information

More than 10 percent of all unique patients seen by the EP during the EHR reporting period (or their authorized representatives) view, download , or transmit to a third party their health information

§495.6 (l)(8) Provide patients the ability to view online, download, and transmit information about a hospital admission

More than 50 percent of all patients who are discharged from the inpatient or emergency department (POS 21 or 23) of an eligible hospital or CAH have their information available online within 36 hours of discharge

More than 10 percent of all patients who are discharged from the inpatient or emergency department (POS 21 or 23) of an eligible hospital or CAH view, download or transmit to a third party their information during the reporting period

There are actually four points the querant addresses:

How to prove 10%
Why 10% if only half have access
Fairness of judging providers on patient behavior
Lack of Broadband Access

Broadband Access
I'll address the last one first. There is an exclusion for lack of broadband access in the rule. It says:

Any EP that conducts 50 percent or more of his or her patient encounters in a county that does not have 50 percent or more of its housing units with 4Mbps broadband availability according to the latest information available from the FCC on the first day of the EHR reporting period may exclude only the second measure.

This means that if the provider does not have access to broadband, they can exclude the measure. The problem with this exclusion is that it isn't the providers access that should be the reason for the exclusion, rather it should be the patient access. I'd reword the exclusion as:

Any EP that conducts 50 percent or more of his or her patient encounters in a county, or with patients who live in a county that does not have 50 percent or more of its housing units with 4Mbps broadband availability according to the latest information available from the FCC on the first day of the EHR reporting period may exclude only the second measure.

In that way, provider could be excluded based upon where the patients who would need to access the information live, rather than where the provider is located, as well as being excluded if the provider doesn't have access.

Proving the 10%
Now, back to the first item: On how to prove the 10%. In order to claim "Meaningful Use", the provider must use the certified technology. This is noted in the Discussion of the Relationship of Meaningful Use to Certified EHR Technology in the Incentive rule. In 314(g)(1) of the Standards and Certification rule, the Certified EHR technology must be able to electronically record the numerator for each meaningful use objective with a percentage-based measure. So, how to prove it? Ask your EHR.

Why 10% and 50%?
Why should the measure be 10% if only 50% have access? Actually, that's a logical conjunction not made by the rule. There are two measures: At least 50% must have access, and 10% must do something with that access. A smart provider will be sure to provide as many patients as possible with access.

Is it Fair to Judge providers on what patients do?

Finally, on the fairness of judging providers based on their patient's behavior: Engagement is a two way street. It takes both parties to create engagement, not just one or the other. Given that the incentive rule is giving providers $ to show that they are doing something meaningful, judging them on a meaningful outcome that shows patients are engaging is certainly fair, at least in my viewpoint.

Arguably, 10% could be challenging for some providers (including specialties). I think the key for this objective is to make a meaningful effort to engage with patients, and you could judge that effort based on the number of responses you get. In marketing, expecting 10% response rate is rather difficult.

I would argue that this objective should be a fixed number, such as 200 patients, rather than a percentage of the patient population. Ten percent will be difficult to reach for some specialty providers, especially for those whose patients will also have access to the same information via their GP. Making the measure a significant number of patients will ensure that all providers attempt to engage meaningfully with their patients without making it overly difficult for specialty providers who are at a disadvantage due to the transitory nature of their patient relationships. Making the number significant (like 200), means that half-hearted attempts at engagement won't do, and it still would achieve the CMS goal of getting patients engaged.

What do you think?

Monday, March 19, 2012

Time to Ship it

In software development, there's always this question that comes up towards the end of a development cycle as to whether we are ready to move to the next stage, or if we should do more clean up on the current stage. I don't care really how you do your development, it will even show up if you are doing agile, because at some point in time, you do have to ship it.

Under the proposed Meaningful Use rules, there's still a disconnect between how CMS and ONC define a Summary of Care Record in the Rules, what the S&I Transitions of Care project did, and how they could be implemented in the CDA Consolidation guide. I've spent the last week making sense of it, and I think my last two posts succeed in that. We need to rationalize the description of the Summary Care Record, and we need to indicate how it can be implemented using the CDA Consolidation guide.

This could be better done in an implementation guide. The question that someone asked me this morning is if we need to write one in time for it to be named in the final rule. I think not, and here is why:

It's time to ship what we have, and let people start implementing. We need to let the implementation issues guide the next steps, not what we theorize will be the issues.
The current CDA Consolidation guide is based on a new framework for developing CDA templates. That framework also needs time for further development and improvement. Changing the guide (again) before we continue on framework development activities will further delay framework improvements.

We have substantial experience with CDA now in the Healthcare industry. The CDA Consolidation guide builds from that experience. We'll be better served by letting the industry move forward at a reasoned pace than we will by starting another crash project that will take away from comprehending what we already have.

At this stage, we need testing and validation tools, implementation tools and working source code. If you want something to work on for Meaningful Use, any of those are good targets.

Friday, March 16, 2012

There can be only one: What should the Summary Care Record look like in MeaningfulUse Stage2

Having done all of this work over the past week on what a Summary Care Record is, and how it maps to the standards, I'm now prepared to suggest how we should take a sharp sword the Meaningful Use regulations to address the confusion and reduce us to only one definition. Please note that this post only addresses the issue around multiple definitions of Summary Care Record in the Meaningful Use rule. There may be other changes I'll suggest, for example, with regard to patients being able to get their record in an inpatient setting in 170.314(e)(2). Also, please remember, this is my blog, these are just my own opinions.

In the Standards and Certification Rule, I'd suggest adding a Section defining the Summary Care Record. The point of this definition is that it is written once, and is referenced as necessary from other locations. You'll note that I consolidated the various requirements across ambulatory and inpatient so that there was really only one definition. For examples, see subsection (a), items (4), (5), (7), and (14).

§170.208 Summary Care Record
The secretary adopts the following as the definition of a Summary Care Record
(a) Content A summary care record contains the following information:
(1) Patient Name
(2) Patient Demographics, including
(i) Gender,
(ii) Date of Birth,
(iii) Race and Ethnicity
(3) The patient's preferred language
(4) The date and location of care, including:
(i) Ambulatory Only -- The date of the visit
(ii) Inpatient Only -- The admit and discharge date of the hospital stay
(5) Contact information for the provider(s) responsible for the patient's care during the visit or inpatient stay.
(6) Contact information for other providers on the patient's care team when known
(7) The reason for receiving care (e.g., Chief complaint, reason for visit, or admission diagnosis)
(8) The Patient's smoking status
(9) Most recent vital signs, including Blood Pressure, Height and Weight where applicable (note that I dropped BMI and Growth Charts, more on that later).
(10) A list of current and relevant past problems.
(11) A list of currently active medications.
(12) A list of currently active medication allergies.
(13) A list of procedures performed during the visit or inpatient stay.
(14) A list of immunizations given during the visit or inpatient stay.
(15) A list of medications given during the visit or inpatient stay.
(16) A list of lab tests and results provided during the visit, or tests and results on discharge for an inpatient stay, including any results still pending.
(17) Any diagnoses produced as a result of the visit or inpatient stay.
(18) Care Plan, including Patient Instructions, Decision Aids; Goals; and any future scheduled tests, visits or referrals
(b) Standards When supplied in an electronic form, the summary care record shall be formatted according to the standards specified in §170.205(a)(3).
(1) Race and ethnicity. The standard specified in § 170.207(f)
(2) Preferred language. The standard specified in § 170.207(j)
(3) Smoking status. The standard specified in § 170.207(l)
(4) Problems. At a minimum, the version of the standard specified in § 170.207(a)(3)
(5) Encounter diagnoses. The standard specified in § 170.207(m)
(6) Medications. At a minimum, the version of the standard specified in § 170.207(h); and
(7) Reserved (For Allergies)
(8) Procedures. The standard specified in § 170.207(b)(2) or § 170.207(b)(3)
(9) Immunizations. The standard specified in § 170.207(i)
(9) Laboratory test(s). At a minimum, the version of the standard specified in § 170.207(g)

Elsewhere in the Standards rule, reference the appropriate parts of this section:

170.314(b)(1) Transitions of care—incorporate summary care record. Upon receipt of a summary care record formatted according to the standard adopted at § 170.208(b), electronically incorporate the data elements found in § 170.208(a).

170.314(b)(2) Transitions of care—create and transmit summary care record.

(i) Enable a user to electronically create a summary care record formatted according to the standards as described in § 170.208(b) and that includes the data elements expressed in § 170.208(a) according to the specified standard(s)

170.314 (e)(1) View, download, and transmit to 3rd party.

(i) Enable a user to provide patients (and their authorized representatives) with online access to do all of the following:

(A) View. Electronically view in accordance with the standard adopted at § 170.204(a), at a minimum, the data elements expressed in § 170.208(a)

170.314(e)(1)(B)(2) A summary care record formatted according to the standards adopted at § 170.208(b) and that includes, at a minimum, the data elements expressed in 170.208(a).

170.314(e)(2) Ambulatory setting only—clinical summaries. Enable a user to provide clinical summaries to patients for each office visit that include, at a minimum, the data elements expressed in 170.208(a).

(On another note, strike the Ambulatory Setting Only part, but that's another set of edits to apply).

(ii) Provided in a summary care record formatted according to the standard adopted at § 170.208(b) with the data elements in § 170.208(b) expressed, where applicable, according to the specified standard(s).

To the Incentive Rule, replace the text describing a Summary Care Record in the preface with:
All summary of care documents used to meet this objective must meet the definition in §170.208(a).
And add the following definition at 495.4:
Summary Care Record
A document containing the data elements found in §170.208(a) and formatted according to the standards at § 170.208(b) when exchanged electronically.

Pages