One of the things that you learn about in Computer Science is the use of context free grammars. There is a good deal of research on making highly efficient parsers for these grammars. However, anyone who deals with real language also understands that there are parts of language that are highly context sensitive, and that in fact, is one of the reasons why natural language is and can be so much more expressive that computer languages. It can also be more ambiguous, which is yet another challenge.
In the HL7 RIM, and in CDA Templates, we've taken the approach that what you say and what you do is not affected by context. So, a problem, is a problem, is a problem, no matter where you find it. And the semantics used to communicate it, and the templates used to constrain it are consistent across many implementations.
But when we go to create an implementation guide for cancer treatment plan, or HIV services, quite often, those very general sections we described in a general way now need to be specialized. So now we wind up with specialized templates for the Breast Cancer Problems Section appearing in a Breast Cancer Treatment plan, or an HIV Problems Section specialized for an HIV Services document.
And the HIV problems section doesn't conform and cannot be used within the Breast Cancer problems section, and vise verse. We could proliferate these context dependent specializations of the problem section, but I'm playing around with another idea.
What if instead, we developed some context sensitive templates. Here's an example of one for a Breast Cancer Treatment Plan:
Breast Cancer Treatment Plan:
1. In a breast cancer treatment plan, the problems section will include BCTS specific entries for problems relevant to Breast Cancer Treatment.
2. In a breast cancer treatment plan, the encounters appearing in the encounters section may include a reason for hospitalization entry that specifies that the reason is due to toxicity.
These are just a couple of examples. The constraints themselves are attached to the breast cancer treatment plan document, and add to existing constraints of existing sections.
This is all very computable, and achieves the same goals, but it has a couple of added benefits:
It begins to attach context specific constraints to a higher level element defining the context, the document (remember that context is one of the six properties of a CDA document). I've been tossing this idea around for quite some time. The examples I gave above are derived from real work going on in HL7 ballots. I like the idea that we could say: In this context, we need information about X, Y and Z. And from a healthcare perspective, that is actually a quite useful piece of clinical knowledge. That X, Y, and Z are important in a particular context probably remains true where-ever that context exists. So even though we start off with a context of "Breast Cancer Treatment Plan", we could probably later rationalize that to cases of "Patients with Breast Cancer", and various flavors of that.
Then, the context drives the documentation, and when that happens, what you have is clearly an instance of clinical decision support. It's worth looking into.
Keith
Monday, April 29, 2013
Friday, April 26, 2013
An XML Book for non-Geeks
In the preface of The CDA Book, I insist that you must have at least a basic understanding of XML technologies in order to fully understand the HL7 CDA Standard. While I was in Saudi Arabia recently, a Health Informaticist with an interest in CDA asked me to recommend an XML book. He isn't a software engineer, but wanted to quickly develop the needed expertise in XML in order to better utilize The CDA Book.
I have numerous XML books on my shelf, as well as many SGML books. But my tastes are not what I think he needed. Nor do I think they are what many clinical or management folks need either. What they want is enough to understand what the technology can do, with enough examples and pointy brackets to explain what is needed, but not so technically overwhelming as to frighten them away.
For the non-technical I'd recommend a book that was written in 2002 and still has valuable content even now, more than a decade later. It's not one of those 500 page or 1000 page tomes that are also useful as a hammer or a booster chair, nor is it one of those dumbed down, Dummy or Idiot titles that I really don't care for. The title is XML Pocket Consultant, published by Microsoft.
The book is divided into four parts, each part including from 2 to 6 chapters. Part I covers XML. Part II DTD's (skip that) and Namespaces (read that). Part III is XML Schema, and Part IV is XSLT and XPath. It's a handy book for me because it goes into enough detail that I can use it as a pocket reference book, but it is also good book for non-technical folk because chapters are fairly short (20-40 pages), and each chapter provides a good overview of a single topic that can be easily digested.
This book won't make you an XML expert, but it may make you look like one to your colleagues, and it is a book that at least one expert (me) still uses.
I have numerous XML books on my shelf, as well as many SGML books. But my tastes are not what I think he needed. Nor do I think they are what many clinical or management folks need either. What they want is enough to understand what the technology can do, with enough examples and pointy brackets to explain what is needed, but not so technically overwhelming as to frighten them away.
The book is divided into four parts, each part including from 2 to 6 chapters. Part I covers XML. Part II DTD's (skip that) and Namespaces (read that). Part III is XML Schema, and Part IV is XSLT and XPath. It's a handy book for me because it goes into enough detail that I can use it as a pocket reference book, but it is also good book for non-technical folk because chapters are fairly short (20-40 pages), and each chapter provides a good overview of a single topic that can be easily digested.
This book won't make you an XML expert, but it may make you look like one to your colleagues, and it is a book that at least one expert (me) still uses.
Thursday, April 25, 2013
Wish me Luck
What can one person do? Quite a bit. Have you ever seen Regina Holliday's artwork, or listen to ePatient Dave talk?
My own "pet project" is Health System Literacy Education. I was inspired by what I could teach my youngest daughter to develop an outline for the content. I worked within my town last year on a health literacy project sponsored by one of the community grants made available through my community health network.
Now it is time to put the grant together. This morning I took a couple of hours off my day job to talk with other CHNA members about should go in the proposal. This afternoon I talk to my local head of public health who has also expressed interest. And this evening I go (with my eldest daughter) in battle gear to an information session for proposal writers to drum up support.
Last weekend my eldest and I spoke to a number of folks about what needs to go into the educational content, and drummed up some content experts to help develop materials.
I don't know what will happen, but already I've drummed up just enough excitement to see this idea move on to the next stage. Wish me luck.
Oh, and if you want to help with content, or support, or anything else (even just to wish me luck), drop me a message or comment below.
My own "pet project" is Health System Literacy Education. I was inspired by what I could teach my youngest daughter to develop an outline for the content. I worked within my town last year on a health literacy project sponsored by one of the community grants made available through my community health network.
Now it is time to put the grant together. This morning I took a couple of hours off my day job to talk with other CHNA members about should go in the proposal. This afternoon I talk to my local head of public health who has also expressed interest. And this evening I go (with my eldest daughter) in battle gear to an information session for proposal writers to drum up support.
Last weekend my eldest and I spoke to a number of folks about what needs to go into the educational content, and drummed up some content experts to help develop materials.
I don't know what will happen, but already I've drummed up just enough excitement to see this idea move on to the next stage. Wish me luck.
Oh, and if you want to help with content, or support, or anything else (even just to wish me luck), drop me a message or comment below.
Wednesday, April 24, 2013
Finally, a new definition of Interoperability
And do you know how I respond to this? I'm so very glad you figured that out. Now that you understand it, can we get on to some real work?
It's good that various organizations take the time to define what they are after. And there is value in looking at things over again from time to time to see what's changed. And it is also a good thing to get everyone on the same page. And I'm sure there was some good reason for this effort in 2013. But it doesn't excite me in the least.
This project has been done, and redone, and frankly, overdone, by AHIMA (2006), HIMSS (2005), HL7 (2007), NAHIT (2005) and ONC and various others over the past decade. For those of us who have been working in the field for the last decade or so are just a bit bored about new definitions for old concepts.
Was some or all of the prior work even considered? Unfortunately I don't know. The really sad part here is that I could have even helped out with these observations ahead of time, if I just had more time to pay attention.
One thing I truly find painful is when old definitions for old concepts are simply renamed. What IEEE used to call Interoperability in 1990 is what HIMSS calls Semantic Interoperability in 2013.
The IEEE definition published the most oft-quoted definition of Interoperability I've seen:
Would you like to know what the IEEE Standards Glossary says in 2013?
Don't get me wrong, getting folks to agree on what you are doing is good. Just don't expect me to get excited about redoing work that is already more than two decades old, and that comes to the same conclusions. It's simply not notable.
To do it again? Somehow I think there are better uses of our time, and wonder why nobody brought that up. Perhaps it helped to educate the new crop of freshman. I don't know, and just cannot figure this one out.
-- Keith
It's good that various organizations take the time to define what they are after. And there is value in looking at things over again from time to time to see what's changed. And it is also a good thing to get everyone on the same page. And I'm sure there was some good reason for this effort in 2013. But it doesn't excite me in the least.
This project has been done, and redone, and frankly, overdone, by AHIMA (2006), HIMSS (2005), HL7 (2007), NAHIT (2005) and ONC and various others over the past decade. For those of us who have been working in the field for the last decade or so are just a bit bored about new definitions for old concepts.
Was some or all of the prior work even considered? Unfortunately I don't know. The really sad part here is that I could have even helped out with these observations ahead of time, if I just had more time to pay attention.
One thing I truly find painful is when old definitions for old concepts are simply renamed. What IEEE used to call Interoperability in 1990 is what HIMSS calls Semantic Interoperability in 2013.
The IEEE definition published the most oft-quoted definition of Interoperability I've seen:
... the ability of two or more systems or components to exchange information and to use the information that has been exchanged.and comes from the IEEE Standards Dictionary, a compendium of glossaries published in 1990 (and is referenced from the HIMSS definition).
Would you like to know what the IEEE Standards Glossary says in 2013?
Ability of a system or a product to work with other systems or products without special effort on the part of the customer. Interoperability is made possible by the implementation of standards.Quite different phrasing, but much the same meaning to those of us who work in the space. To those who don't work in the space, this is much clearer. The without special effort on the part of the consumer is implied in the previous definition. Here it is made explicit, and that is quite useful. Was that even referenced?
Don't get me wrong, getting folks to agree on what you are doing is good. Just don't expect me to get excited about redoing work that is already more than two decades old, and that comes to the same conclusions. It's simply not notable.
To do it again? Somehow I think there are better uses of our time, and wonder why nobody brought that up. Perhaps it helped to educate the new crop of freshman. I don't know, and just cannot figure this one out.
-- Keith
Tuesday, April 23, 2013
Wouldn't it be interesting if ...
"Wouldn't it be interesting if ..." the tweet starts. And continues: "... there were a standards development organization founded/ran by patients?"
There is an idea in here that is absolutely right, and an implementation that isn't ideal.
Let's start with what is right. What is right is that patients are the ultimate consumer of what we do in Health IT, and they absolutely need to be at the table and well represented.
What is wrong is simply that standards are about consensus among all stakeholders. Any standards process that gives one body more representation or control than another is broken, even if it does so with the best of intentions.
I've been involved with standards efforts where one stakeholder group had more power than others (even today this is still true in S&I Framework -- just ask yourself who sets the agenda), and can tell you that it can be challenging. Been there, done that (on both sides). Certainly it is "comfortable" to be with the stakeholder group in power, but it doesn't lead to the best outcomes for all.
The harder thing, but probably more useful to do is to become influential in an existing community. Been there, done that. If you can manage it, it results in more success. Rather than attempting to compete on dramatically unequal footing, what you wind up doing is co-opting the existing community on your own terms. You have to start softer. You aren't trying to change the world all at once (see reboot or re-boot). Just trying to get the direction shifted a little bit, then a bit more. Until eventually, well, you get the idea.
This is happening to some degree inside HL7. There are people who are seeking change, and making it happen (e.g., Mobile Health, Quality, Free IP and other initiatives), bringing in other stakeholders to help. The balance of power is shifting. Directions are changing.
The biggest challenge for patients in all of this is understanding how they/we can participate. Some are techno-geeky, like me, but with non-healthcare backgrounds (also how I started). Others are non-techno geeky. Others have a healthcare background. And others, are simply just frustrated with the way things work today.
The biggest challenge for organizations wanting to engage patients is figuring out what it means to be a representative of that stakeholder group. The usual classifications here don't necessarily work. The minimal requirements for classification of stakeholders (according to section 2.3 of ANSI Essential Requirements) is:
There is an idea in here that is absolutely right, and an implementation that isn't ideal.
Let's start with what is right. What is right is that patients are the ultimate consumer of what we do in Health IT, and they absolutely need to be at the table and well represented.
What is wrong is simply that standards are about consensus among all stakeholders. Any standards process that gives one body more representation or control than another is broken, even if it does so with the best of intentions.
I've been involved with standards efforts where one stakeholder group had more power than others (even today this is still true in S&I Framework -- just ask yourself who sets the agenda), and can tell you that it can be challenging. Been there, done that (on both sides). Certainly it is "comfortable" to be with the stakeholder group in power, but it doesn't lead to the best outcomes for all.
The harder thing, but probably more useful to do is to become influential in an existing community. Been there, done that. If you can manage it, it results in more success. Rather than attempting to compete on dramatically unequal footing, what you wind up doing is co-opting the existing community on your own terms. You have to start softer. You aren't trying to change the world all at once (see reboot or re-boot). Just trying to get the direction shifted a little bit, then a bit more. Until eventually, well, you get the idea.
This is happening to some degree inside HL7. There are people who are seeking change, and making it happen (e.g., Mobile Health, Quality, Free IP and other initiatives), bringing in other stakeholders to help. The balance of power is shifting. Directions are changing.
The biggest challenge for patients in all of this is understanding how they/we can participate. Some are techno-geeky, like me, but with non-healthcare backgrounds (also how I started). Others are non-techno geeky. Others have a healthcare background. And others, are simply just frustrated with the way things work today.
The biggest challenge for organizations wanting to engage patients is figuring out what it means to be a representative of that stakeholder group. The usual classifications here don't necessarily work. The minimal requirements for classification of stakeholders (according to section 2.3 of ANSI Essential Requirements) is:
- Producer
- User
- General Interest
A fourth category that often shows up is "government", from the perspective of regulators or imposers of the standard. Producers and users (usually purchasers) often have an obvious financial stake that makes it possible for them to obtain funding to participate in the development of standards. Government too has a way to fund its participation. But patients most often fall into the "general interest" category, and from that perspective, often don't have a funding source for participation.
More often than not, other non-profit organizations devoted to representation of patients or consumers will often show up, and do have funding. But these organizations aren't the same as the stakeholders (and in fact, there are SOME I would NOT have represent me, because I don't agree with their perspective).
I like the idea of patient scholarships, but it isn't clear how that would work, or what the proper governance is.
The final challenge is how to address the fact that we can all fit ourselves (as I did in this post on Patient-Centric Health IT) into the "General Interest" category. While each of us can fit into that category, we have different perspectives based on our involvements as producers or users or other categories as well. And we all balance those differently. General interest in this list is almost an "other" category, as in Not Otherwise Specified.
What may be important are the various "declarations" that a participant can make:
- Do you spend money or resources to implement or conform to the standard?
- Do you receive money or resources to implement or conform to the standard?
- Are you in a position to require use of those standards in a particular market?
I find it difficult for many who would argue that they are representatives of patients who can say yes to either 1 or 2 as being strictly representative of the "patient" stakeholder group.
So, wouldn't it be interesting if, we were to find a way to enable patients more participation in the development of standards? Certainly it would be. But, I think the journey will possibly be more interesting than the destination.
Monday, April 22, 2013
Our Foo is Stronger
Headed to Boston for #Healthfoo was how the FB post read.
"Dang, I guess I wasn't invited this year," I thought to myself "again."
And this time there was nobody there to lobby for me to attend as happened last year.
Because by the time it started, they were already talking about canceling it. And by Friday afternoon it was cancelled, because Boston was either "locked down" or "sheltering in place" depending on whose spin you want to put on it.
But the next FB post I saw said something different: "Need help planning unconference."
So, I responded Friday night, and found out Saturday morning that Regina, Ted, David, Fred and many others were planning things out over breakfast a few hours from when I read the post. I dropped my daughter off at her horse-back riding, did the weeks shopping ultra-fast. Ran home and off-loaded it, and then bundled the rest of my family (who all wanted to at least meet Regina) into the car, where we then went back to pick up my eldest daughter from her horseback riding lesson, and threw clean clothes at her.
And we trucked on through Boston Saturday morning to meet up with the Health Foo crowd. It was a bit odd, see a caravan of eight police cars and military HUMVEE convoying from Huntington Avenue to Mass ave with sirens blaring ("Prisoner transport?" I thought to myself), or to see a second hummer sitting on Mass Ave at Boylston Street with a gun mount atop it.
We got to the breakfast venue only to see that the group was splitting, given the lack of space and quiet in venue #1. I left my eldest in the charge of Regina and the rest of the family joined the remaining crowd to plan things out. Discovering that the event had been cancelled actually made it possible for my eldest daughter and I to attend it. We could only spend Saturday (Sunday being the day we were to celebrate my youngest's 11th birthday). My wife and youngest daughter headed home after breakfast.
After our "second breakfast" (at least for my eldest and I who had already been up since 6), we met up for coffee again at a nearby hotel, and then headed over to MIT to hold the un-foo, or as it was later to be called, the foo-foo. We spent about 6 hours unconferencing in MIT space (made available by @littledevices), before the two of us headed home on the Red Line.
For more on what happened, see posts by Ted and David, and especially check out Ted's photo-stream.
On our way home, my daughter and I stopped to pay homage at the shrine that sprung up on campus for the MIT policeman who was shot and killed in the craziness on Friday.
As others have said, and I simply repeat: Our Foo is strong.
"Dang, I guess I wasn't invited this year," I thought to myself "again."
And this time there was nobody there to lobby for me to attend as happened last year.
Because by the time it started, they were already talking about canceling it. And by Friday afternoon it was cancelled, because Boston was either "locked down" or "sheltering in place" depending on whose spin you want to put on it.
But the next FB post I saw said something different: "Need help planning unconference."
So, I responded Friday night, and found out Saturday morning that Regina, Ted, David, Fred and many others were planning things out over breakfast a few hours from when I read the post. I dropped my daughter off at her horse-back riding, did the weeks shopping ultra-fast. Ran home and off-loaded it, and then bundled the rest of my family (who all wanted to at least meet Regina) into the car, where we then went back to pick up my eldest daughter from her horseback riding lesson, and threw clean clothes at her.
And we trucked on through Boston Saturday morning to meet up with the Health Foo crowd. It was a bit odd, see a caravan of eight police cars and military HUMVEE convoying from Huntington Avenue to Mass ave with sirens blaring ("Prisoner transport?" I thought to myself), or to see a second hummer sitting on Mass Ave at Boylston Street with a gun mount atop it.
We got to the breakfast venue only to see that the group was splitting, given the lack of space and quiet in venue #1. I left my eldest in the charge of Regina and the rest of the family joined the remaining crowd to plan things out. Discovering that the event had been cancelled actually made it possible for my eldest daughter and I to attend it. We could only spend Saturday (Sunday being the day we were to celebrate my youngest's 11th birthday). My wife and youngest daughter headed home after breakfast.
For more on what happened, see posts by Ted and David, and especially check out Ted's photo-stream.
On our way home, my daughter and I stopped to pay homage at the shrine that sprung up on campus for the MIT policeman who was shot and killed in the craziness on Friday.
As others have said, and I simply repeat: Our Foo is strong.
Friday, April 19, 2013
Reboot or Re-boot?
I've heard the phrase "reboot" used several times recently. A couple of days ago it was in reference to the HITECH act and Meaningful Use. Today it was about the healthcare system [sic], and at other times, I've heard the phrased used with respect to interoperability and standards.
Rarely is a reboot possible. Once a path is started down, there is simply too much momentum to shut it down and start over. As much as I would LOVE to redesign our healthcare system from scratch, I realize that existing momentum is greater than my capability to stop and restart the system. Also, unless you change something, reboot likely doesn't fix the problem. I can count on one hand the number of times rebooting fixed my networking issues, and it never works for the cable-guys when I call them (because if it would have, I'd have already done it).
In mathematics, complex optimization problems are often challenged by getting stuck in local minima. Various solutions to this problem usually involve successively larger and larger kicks. This often works to dislodge the system from a local minima and enables discovery of a better solution. Successive jolts are also useful when done in a repeated and rhythmic fashion (developing a harmonic). Ever rocked a stuck car out of an icy or otherwise slippery hole?
So, it's not "Reboot" as in start over again. By the time you've figured out that you are stuck with a non-optimal solution, the opportunity to start over probably doesn't exist. Rather, "Re-boot", as in "Kick it Harder". That just might work. Or you could end up breaking it altogether (which according to my Stage manager wife, means that it just needed replacing anyway), or you could just wind up with a broken toe. All of these are possible outcomes when you attempt to "re-boot". It's never a guarantee of success. The critical challenge with kick it again, or kick it harder, is figuring out where and how hard, and in what direction to apply that impulse.
So, if your advice is to "reboot", or even "re-boot", think again. What is the right direction and force to apply to that kick that will dislodge the system and move it in the right direction. It's pretty darn easy to say kick it again. The really hard part is to say "kick it right here". And that is what differentiates an expert from a novice.
Keith
Rarely is a reboot possible. Once a path is started down, there is simply too much momentum to shut it down and start over. As much as I would LOVE to redesign our healthcare system from scratch, I realize that existing momentum is greater than my capability to stop and restart the system. Also, unless you change something, reboot likely doesn't fix the problem. I can count on one hand the number of times rebooting fixed my networking issues, and it never works for the cable-guys when I call them (because if it would have, I'd have already done it).
In mathematics, complex optimization problems are often challenged by getting stuck in local minima. Various solutions to this problem usually involve successively larger and larger kicks. This often works to dislodge the system from a local minima and enables discovery of a better solution. Successive jolts are also useful when done in a repeated and rhythmic fashion (developing a harmonic). Ever rocked a stuck car out of an icy or otherwise slippery hole?
So, it's not "Reboot" as in start over again. By the time you've figured out that you are stuck with a non-optimal solution, the opportunity to start over probably doesn't exist. Rather, "Re-boot", as in "Kick it Harder". That just might work. Or you could end up breaking it altogether (which according to my Stage manager wife, means that it just needed replacing anyway), or you could just wind up with a broken toe. All of these are possible outcomes when you attempt to "re-boot". It's never a guarantee of success. The critical challenge with kick it again, or kick it harder, is figuring out where and how hard, and in what direction to apply that impulse.
Keith
Subscribe to:
Posts (Atom)