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