Late Night Rants

"I am a bit frustrated." ... begins the e-mail that comes to me.  It continues "I am struggling to find in the RIM and CDA where the patient gets to express their voice. "

And indeed, I understand the frustration.  There are at least three issues here:

1. Can the information be modeled in the RIM?
2. Do we have common models (C-METs) from which to draw?
3. Can you represent these models in CDA?

Can the information be modeled in the RIM?

The answer to the first question is YES.  The RIM models acts with participants playing roles played by entities and scoped by other entities. This is rather arcane stuff, as models usually are.  Making things a lot simpler:  I, you, or someone else; in a role as patient, knowledgeable 3rd party, parent/guardian or patient advocate, want to author information about, perform, authorize or otherwise take responsibility for healthcare activities.  The subject of those statements or activities may be a healthcare professional, organization, or diagnostic or treatment activity.

So how would this be represented in the RIM?

For the person performing the activity, this represented in the RIM as a Person class, and would show up as a green box in the model.  The role could be patient, agent, caregiver, guardian, family member, or a few other possibilities.  In the case of the patient role, the "scoper" of the role is the healthcare organization where the patient is getting care.  In the case of all other roles, the "scoper" of the role is the person playing the patient role.

Possible participations include Author, Performer, Responsible Party, Verifier, Legal Authenticator and many others.

Other participants, could be healthcare providers, which would be represented as "living subjects" since they are subject of the activity.  Note that patient as person, and provider as living subject is a reversal of the usual role assignment.  The might appear in the act as the record target (in the patients "record" about their providers), the subject, or as an author of health information or performer of care activities.

So, all of this can be represented in the RIM.

Do we have common models from which to draw?

Not really.  Yes, there are some common models, but they are so generic as to be nearly useless in helping a non-HL7 modeler make use of HL7 content.

Can you represent these models in CDA?

Yes and no.  You can represent probably 60-70 percent of the essence of these models in CDA.  One of the challenges is that the use case for CDA as originally envisioned some 15 years ago did not include extensive capturing of patient authored or expressed content.  So, many model components would need to be inferred.  And since we don't have any truly authoritative common models from which to draw, it is hard even to map into CDA.  I could do it, but I would expected someone who is new to HL7 to understand it the way I would, and arguably, I wouldn't expect other HL7 experts to draw the same diagrams I would.

It actually sounds like a good activity for HL7 to engage in, developing patient-centric models for clinical statements being produced by patients or their representatives possibly about healthcare providers or other activities.  First I think we would need a Conceptual Model to describe what we wanted to represent, then I think we could develop some CMETs which could be used to inform other HL7 modeling efforts.  The most interesting piece for me is trying to imagine where this would go.

The Patient Care work group sounds right, but is almost the diametrically opposite place from where I'd put it.  Why?  Because Patient Care mostly contains healthcare providers.  EHR also seems wrong in some way.  Clinical Quality Improvement?  Not really.  This also is less about domain expertise, and more about structure and semantic design, so maybe I should be looking in that division?  Clinical Decision Support?  Nope.  Structured Documents? Maybe.  Clinical Statement?  Yep. That actually seems like the right place

So, here is my thinking:

Propose a project to the Clinical Statement workgroup to develop a conceptual model of patient-centric RIM models of clinical statements to address clinical statements made by patients or their representatives about their healthcare, or providers or provider organizations, and to generate CMETS which can support those representations, which can be used to support development of additional HL7 models.

Three IHE Domains Publish new Documents

IHE Eye Care Technical Framework Supplements Published for Public Comment The IHE Eye Care Technical Committee has published the following supplements to the IHE Eye Care Technical Framework for public comment in the period from June 26 through July 26, 2014. General Eye Care Evaluation (GEE) Small Clinic Workflow (SMC-EYECARE) The documents are available for download at http://ihe.net/Public_Comment/. Comments submitted by July 26, 2014 will be considered by the IHE Eye Care Technical Committee in developing the trial implementation version of the supplements. Comments can be submitted at http://ihe.net/Eye_Care_Public_Comments/. IHE Patient Care Device Technical Framework Supplements Published The IHE Patient Care Device Technical Committee has published the following supplements to the IHE Patient Care Device Technical Framework for public comment in the period from June 26 through July 26, 2014: Medical Equipment Management Device Management Communication (MEMDMC) Medical Equipment Management Location Services (MEMLS) The documents are available for download at http://ihe.net/Public_Comment/. Comments submitted by July 26, 2014 will be considered by the IHE Patient Care Device Technical Committee in developing the trial implementation version of the supplements. Comments can be submitted at http://ihe.net/PCD_Public_Comments/. The committee has also published the following supplement to the IHE Patient Care Device Technical Framework for trial implementation as of June 26, 2014: Infusion Pump Event Communication (IPEC) This profile may be available for testing at subsequent IHE Connectathons. The document is available for download at http://ihe.net/Technical_Frameworks/. Comments on all documents are invited at any time and can be submitted at http://ihe.net/PCD_Public_Comments/.   IHE Radiation Oncology Technical Framework Volumes Published The IHE Radiation Oncology Technical Committee has published the following Technical Framework Volumes as of June 26, 2014: Volume 1 (RO TF-1): Profiles Volume 2 (RO TF-2): Transactions The profiles contained within these volumes may be available for testing at subsequent IHE Connectathons. The documents are available for download at http://ihe.net/Technical_Frameworks/. Comments on all documents are invited at any time and can be submitted at http://ihe.net/Radiation_Oncology_Public_Comments/.

Consumer Empowerment as a Business Opportunity

The biggest buzzwords today in healthcare seems to be all about consumer empowerment.  So, let's put a consumer hat on, take a step back from all the activity, and analyze what is happening:

1. A number of businesses are emerging promising to empower consumers.
2. These businesses need to get paid somehow, most likely by the healthcare system.
3. So, who is going to pay them, and where is the money coming from?

And in the long run, how does this all benefit me?

I shouldn't have to pay for information to make healthcare a better market for me, and nobody else should either.  We need to rethink the policies that make it necessary for healthcare consumers to foot the bill to make healthcare market consumer driven.  And if you think I'm not the one paying for it, think again.  That cost is either going to my pocket eventually, or keeping my employer from paying me more because it is coming out of my benefits.

Another Term Ends

I just finished another term in my Clinical Informatics program at OHSU.  This term I took two classes, Consumer Health Informatics, and Clinical Quality Improvement.  I expected Clinical Quality Improvement to be harder, and in some ways it was, but when I look back on the two classes, I think that Consumer Health Informatics really is the harder discipline, at least for me.

I say that because Consumer Health Informatics is both softer, and broader than Clinical Quality Improvement.  I can do math, and often do it in my sleep, and a lot of Quality Improvement is about understanding measurement and statistics, and evaluating graphs and charts.  Other parts of it are also fairly objective, so it comes to me fairly easy.

It's the qualitative, subjective stuff where my brain sometimes goes to mush. Or perhaps not mush, so much as I feel like I'm trying to nail mush to the wall.  While I did well on my final exam, it's also the lowest exam grade I've gotten yet.  Part of it has to do with really focusing on a consumer's needs fully.  And while I certainly have a consumer perspective, I don't get to work with other consumers that often (especially those not in the e-Patient crowd), so I only have my own (and my family's) experiences to rely on.

Next term I'll be looking at a completely different side of things.  I've registered for two classes, Organizational Behavior and Management, and the Business of Healthcare Informatics.  Neither of these is something that I can claim any special expertise in, although working to change organizations is something that I have been practicing for quite some time, and understanding the other end of the business (the sales rather than purchasing side) may give me some interesting insights.

I thought about taking the summer off, but that would just push my education down the road, and I really do enjoy the classes.

   Keith

Is Your Doc IT Savvy? How an ePatient can find out.

How would you even know?  How could you find out?  This 15-minute video is my attempt to help patients answer this question.  It's designed to interrupt the Health IT Video a few seconds in...



This was one of my assignments for my Consumer Health Informatics class this term.

   Keith

The Tools You Have

The other day I walked my youngest daughter home from school.  I would have ridden save that my eldest forgot to return my car keys (which also have my motorcycle key), and so I had to walk.  This isn't really a big deal, as school is only a mile or so away.  If you Google map the drive, it's either 1.2 or 1.4 miles.  However, if you walk it the way my daughter does, it's only a mile, and coming from school, mostly all downhill.  There's a slightly longer route that takes about 1.1 miles, but is much more level.  She takes that route in sometimes, especially when biking, and the other route home.  When I drive, I have to go one of the longer ways, and the way I take varies by time of day to avoid rush-hour traffic.

This just goes to show how the tools that you have (be it a hammer or a screw driver or a motorcycle or your own feet) influence what you can do easily.  It's something to be aware of when planning your interoperable solutions, especially when a variety of different tools are readily available.

Template Identifiers Redux

A while back I reported on several issues with the CDA Consolidated Release 2.0 efforts, and we got an answer sort of back in October (more than 8 months ago).  Since then, the CCDA Release 2.0 still hasn't been finished, and Templates is nearly done.  So we successfully reopened the discussion at the last HL7 Working Group meeting.  And after several rounds of discussion, I was pleased to hear that Lantana Group was willing to invest in changing the Trifolia tool which is used to create the CCDA specification to support the change.  So we seem to be all set to move ahead with the new Template version recommendations from the Templates Workgroup, and that appears to line up well with other efforts at the International level.

As a result, there is one more discussion to have within the HL7 Tooling workgroup to approve the changes, some QA work I've volunteered to perform (along with a George Cole of Allscripts), and we should soon be ready to use versioned templates.

The solution to the problem goes back to how the tooling manages template identifiers.  Since they are opaque strings for the most part, folks at Lantana put a bit of structure around them, making them URNs. That allows the tool to detect the type of template ID.  An unversioned template ID uses a straight OID, and a versioned template ID uses one of the HL7 URN formats for II that Grahame Grieve mentioned earlier this week (and now you know why Rick and Austin were looking into that format and why there are two).

When the template ID is unversioned, the previous generation code is used.  When the template ID is versioned, some small changes are made to the generation code to use @root and @extension, and to apply constraints appropriately, in the guide, in examples, and in schematron.

How will these be tested?  It's a simple process really.  I'll use template ID patterns to produce a list table of output patterns containing template IDs in the various artifacts.  The number of columns in the table depends on how big patterns can get, but usually 5 columns is sufficient.  A row in the table is populated with the sequence of N whitespace-delimited tokens which the central token contains a pattern.  After you produce the table, you sort it in various orders alphabetically, and find matching patterns.

For each matching pattern, you then describe what the new output would look like, repeat the search on the new output, and then see if you get what you expect.  If you do, it passes, if you don't you log a bug.  This is an text processing pattern I've used for many years to develop NLP pattern matching and restructuring scripts, and it works to either develop those scripts, or to test the execution of them.  And that is exactly what we are doing, testing the execution of text processing scripts.

I look forward to finishing this pretty quickly, and Kudos to the folks at Lantana Group for supporting this effort, including Rick Geimer, Sean McIlvenna, and Liora Alshuler!

   Keith

NIC NOC Who's there?

Arguably in the various Healthcare Standards battles I've watched, it is most often the nurses that act like grown ups.  But not always. I sit on the sidelines and observe this time around, as the Nursing Terminology Wars heat up again in the discussion of appropriate terminologies for encoding different parts of the care plan.  Someone asserts that general agreement was made to use terminology X, another person cites terminology Y is better suited.  This same debate occurred more than five years ago in my memory, and I'm sure it has occurred many times prior to that.  For the most part, I'm hoping against hope that it won't crop up again after this minor flare up.

Several (perhaps the majority even), are fairly clear, and readily understand the way forward, and that is simply to use SNOMED CT (at least in countries that license it) for this challenge.  NIC, NOC, NANDA, and CCC terms have all been mapped into SNOMED CT.  Unlike many of the nursing specific vocabularies, SNOMED CT is free to use by all in the US, does not have restrictive licensing agreements on use with other terminology systems, and has already been built into many products.

So why are we having this debate again?

Differentiating Policy Requirements from Interoperability Requirements

Several times over the past several days I've had to deal with issues of policy which were raised as problems preventing interoperability.

In one case, the discussion was around the failure of two big organizations to be able to interoperably exchange information with each other using the HITSP C32.  The challenge wasn't really in the ability of the two organizations to do the exchange, or even understand the information being exchanged.  The problem was in the fact that the business policies and procedures of those organizations were different enough that the data both organization considered essential was captured either using different vocabularies, or that they had different definitions of essential data.  The data could be transmitted in the C32, but what was sent by one organization either wasn't used, or couldn't be used as effectively by the other because of the allowed variations in coding.

Another example of this is in how CCDA focuses on the US Realm vocabularies and identity domains, thus failing to be internationally supportable.  For example, CCDA says to use the providers National Provider ID (NPI), and specifies an OID that is required to be used.  Yes, in the US, the policy being applied here is that the identifier of the provider is communicated using NPI, and so when you put that policy together with CDA (producing CCDA), you get a requirement that the OID has to be the NPI OID.

But the interoperability requirement is much simpler.  There must be an identifier for the provider in the document that is from the identity domain established by policy.  And the policy requirement is also very simple: The (in this case national) policy is that providers in the US are identified by their NPI.

Unfortunately for implementers, separating policy requirements from interoperability requirements creates a level of indirection that quite honestly, most of them don't, and shouldn't have to care about.  It's just like vocabulary binding.  There are probably two dozen people in the world who are real experts about all the nuances of vocabulary binding.  The rest of us just want to know how to create the content needed, and care very little about all this nuance.  So putting that level of indirection in the implementation guide isn't really what many implementers want.

So we put policy requirements in implementation guides (especially realm specific guides) in ways that support what implementers need.  Somehow, we need to make this easier for people.  There needs to be a way to express policy constraints just as there is a way to express interoperability constraints, and we need to be able to separate those concerns, and build tools that will enable them to be managed, and to produce the result of combining both.  In that way, we can readily create implementation guides that can be more easily customized based on policy decisions.

     Keith

MeaningfulUse VDT, BlueButton Plus Push, Pull, Direct and FHIR, untangling it all

VDT, or View, Download and Transmit, is a set of requirements for 2014 Certified Electronic Health records under Meaningful Use for the EHR to enable the patient to View, Download or Transmit their data.  In addition to VDT requirements, the EHR must also use the Consolidated CDA (CCDA) under those regulations, and must support The Direct Protocol, and may support other protocols.

Providers who want to get incentive $$$ for Meaningful Use must use the standard format (CCDA) when enabling patients to Download or Transmit data.  They may, but are not required to use the standard protocols the EHR must support for transmission of CCDA documents for referral.  This is a rare exception to the general rule that to obtain the incentive, you must use the certified capability.  In making this exception CMS understood that some very functional referral networks already had document transmission capabilities and did NOT want to have to replace them with The Direct Protocol just to support the same feature.

Blue Button Plus is an extension of Blue Button that uses the CCD and CCDA formats specified under the 2011 and 2014 Certification and Standards rules to exchange patient data.  When the document is transmitted using The Direct Protocol, effectively you have the BB+ Push capability.  When it can be downloaded using a pre-draft subset of the HL7 FHIR standard, you have the BB+ Pull capability.

Neither the 2011, 2014, or proposed 2015 certification criteria require Blue Button or Blue Button Plus. Blue Button Plus has been proposed for 2017 certification criteria.

Oh, and finally, Blue Button, Blue Button Plus and Open Notes are very similar.  When you can get your Open Notes using the CCD or CCDA format, effectively you are using the same content standards supported by BB+, and then it is all a matter of how you would download or transmit it.

That is the challenge when setting the low bar in VDT.  More functional bars like BB+ Push or BB+ Pull aren't required by Meaningful Use, but are perfectly capable of meeting the requirements for it.

IHE ITI, PCC and QRPH Technical Framework Documents Published

Also note that Public Comments are also still being solicited for the Data Access Framework White Paper

---

IHE IT Infrastructure Technical Framework Supplements Published for Public Comment The IHE IT Infrastructure Technical Committee has published the following supplements to the IHE IT Infrastructure Technical Framework for public comment in the period from June 6 through July 5, 2014: Patient Demographics Query for Mobile (PDQm)  Secure Retrieve (SeR) The documents are available for download at http://www.ihe.net/Public_Comment/. Comments submitted by July 5, 2014 will be considered by the IHE IT Infrastructure Technical Committee in developing the trial implementation versions of the supplements. Comments can be submitted at http://ihe.net/ITI_Public_Comments/. The committee has also published the following Handbook: De-Identification De-Identification Mapping (Excel file) The documents are available for download at http://ihe.net/Technical_Frameworks/. Comments on all documents are invited at any time and can be submitted at http://ihe.net/ITI_Public_Comments/.   IHE Patient Care Coordination Technical Framework Supplements Published for Public Comment The IHE Patient Care Coordination Technical Committee has published the following supplements to the IHE Patient Care Coordination Technical Framework for public comment in the period from June 6 through July 5, 2014: Multiple Content Views (MCV) Reconciliation of Clinical Content and Care Providers (RECON) Also available for comment is the following white paper: Data Access Framework (DAF) The documents are available for download at http://www.ihe.net/Public_Comment/. Comments submitted by July 5, 2014 will be considered by the IHE Patient Care Coordination Technical Committee in developing the trial implementation versions of the supplements. Comments can be submitted at http://ihe.net/PCC_Public_Comments/.   IHE Quality, Research and Public Health Technical Framework Supplements Published for Public Comment The IHE Quality, Research and Public Health Technical Committee has published the following supplements to the trial implementation version of the IHE Quality, Research and Public Health Technical Framework for public comment in the period from June 6 through July 5, 2014: Birth and Fetal Death Reporting-Enhanced (BFDR-E) Early Hearing Detection and Intervention (EHDI) EHDI Sample Form (Excel file) Family Planning (FP) Structured Data Capture (SDC) SDC Schemas (zip file) Sample XML file (FEHR) Sample XML file (Medications) The documents are available for download at http://www.ihe.net/Public_Comment/. Comments submitted by July 5, 2014 will be considered by the IHE Quality, Research and Public Health Technical Committee in developing the trial implementation versions of the supplements. Comments can be submitted at http://ihe.net/QRPH_Public_Comments/.

Is Your Doctor a MeaningfulUser

For my Consumer Health Informatics class, I developed a presentation for patients to help them figure out whether or not their doctor was Tech Savvy.  One of the questions they could ask was whether or not their doctor was a Meaningful User or participated in the CMS EHR Incentive Program.  Sometimes you have to ask the question one way, and sometimes another to get a good answer.  Not everybody knows what these terms mean.

There are ways other than asking that you can find this out, but it really takes a computer to work it out for a patient.  Provider NPI data identifies providers by name, organization, license number, practice location address and specialties.  You can get that data here.  These are all different ways you can search for providers, and it can also support, with the aid of some good mapping data sets, geo-searching (e.g., find provider within 20 miles of my location).

CMS also provides information about which providers and hospitals have received meaningful use payments. That data set tells you, by NPI, which providers have been paid under Meaningful Use, and the program year number and date (by which you can determine stage of meaningful use), and their reported results for core and menu set measures, and the EHR they use (by the EHR Certification number assigned).

So, there is nothing stopping ANYONE from finding a a doctor within 50 miles, that met a particular set of core and menu set measures, at a particular stage of meaningful use, using a particular EHR.  Well, except for a small matter of programming.  Because really, searching through all that data isn't possible without a computer.

I'm hoping some enterprising visualization and/or data geeks will take on this challenge (This would be a great addition to ONC's HealthIT Dashboard).  Because I'm probably going to be needing to find a new doctor after I move (staying in the same county, but moving to a bigger house, just far enough away to make it challenging to keep my old one), and the last thing I want to do is figure it out the hard way.

It's Complicated

A long time ago a close friend and colleague told me that if you cannot be replaced, that you cannot be promoted either.  It's a lesson I took to heart a very long time ago, and it turned me even more towards teaching others.  I found and still find this to be a very rewarding part of my job.  One of my favorite quotes is from my personal hero Richard Feynman:

You know, I couldn't do it. I couldn't reduce it to the freshman level. That means we really don't understand it.

This is a concept I (and others) fail to consider a great deal in developing standards. Because if we cannot explain it clearly enough so that the average developer can implement it, then we may not really understand it ourselves.  It's why I go back and implement specifications that I've written as often as I can (or better yet while I'm writing them), because only then do I ever understand the problems of my audience.

Real art, and real skill is not being able to understand what is complicated, but in making it easier for others to do so. This is a challenge that few specifications ever really succeed with. And when we argue that the specifications must be complicated because Healthcare is complicated, sometimes I wonder if what we are really saying is we don't understand it ourselves.

So it is up to us to make it easy.  That is, unless we want to be stuck doing the same complicated stuff all our lives.  I, for one, would like to do something different every now and again.

iOS, HealthKit, Hype and FHIR

Apple now enters into the Health Platform API fray with something called HealthKit, after Google has left the field, and Microsoft simply carries on with its Health Vault platform.  This isn't really really new news, so much as confirmation of what we've been hearing for a little while about Apple's entry into the Health and Quantified Self space.  As someone who has more than 5 QS/Health apps on his phone and iPad which DO NOT work together at all, I appreciate that the iOS platform will soon have these capabilities built in.  And I can also see that vendors developing these applications will have to rather quickly start working with the new APIs.

But what does this mean with respect to standards like HL7's FHIR.  Apple's not a big participant in standards activities. Apple developers have somewhat been locked in to Objective C for development, although Apple now announces a "new" programming language called Swift (which for all intents and purposes looks like what JavaScript would if you started from Objective C and seems to have no real additional value other than to have an Apple-branded scripting language for IOS).

Looking at the basic descriptions of what Apple has in store for us at the moment, it seems as if Apple's definition of a Health API isn't all that much more than what HL7 FHIR already has with regard to definition for various Health related resources.  I expect some enterprising FHIR developers will be building bridges between the new Apple Health APIs and FHIR.  We've already seen some development of FHIR in Objective-C, and I expect that the Apple announcement of HealthKit will encourage others to explore bridging between it and HL7's FHIR specification.  But don't expect Apple to start showing up at HL7 FHIR Connectathons, or participating in FHIR development.

Just as I expect Microsoft will be doing similar things with Health Vault at some point in the future.  But they won't be doing it right away according to at least one Microsoft employee. Even so, at least Microsoft shows up.

We'll just have to see how this all plays out.  I'm not really too worried about Apple's entry into the Health API space.  After all, the world doesn't live on iOS alone, there will be always be a need for a consensus standard Health API like FHIR that can work on any platform.

    Keith

How do you teach a subject that is changing rapidly?

Two of the classes that I'm taking at OHSU this term are in topic areas where the difference from year to year about what is known is advancing rapidly.  The classes are Consumer Health Informatics, and Healthcare Quality.  This is challenging, a text book that is five years old is already out of date, and numbers from even a year ago may be significantly different.

One of the applicable techniques here is "teaching a person how to fish." and gratefully, both of my instructors are doing that by pointing us where to go find stuff, and which organizations are actively working in the space.

In both places it is fun to see some of what is being taught being influenced by stuff I've been involved in, for example, Blue Button Plus in Consumer Health Informatics, and HQMF in Healthcare Quality.

My advice to students in these areas is the same advice that was given at some point by both my instructors, which is to get involved.  That's the best way to learn what is going on.

    Keith