Today I got to present to the HIT Standards Clinical Quality Workgroup on principles for standards selection. I had raised the point at our last meeting that it would be good if, before we started selecting standards, we actually understood the principles behind which such a selection was made.
A lot of work has already been done in this area, as I reminded the workgroup. I started from first principles as to why consensus standards are desirable, moving to a derivation from NIST's Guiding Principles for Identifying Standards for Implementation as found in the Framework and Roadmap for Smart Grid Interoperability, and then on to principles found in HITSP's Tier 2 standards evaluation criteria, and the unwritten principles (now written down) for IHE standards selection, and the written principles for taking a profile to final text.
Then I gave an overview of the feedback I had received from many interested parties who responded to this post, or whom I found it interesting to talk to about the issue, including the guy who labels himself as "a dumb family doc" but is now sitting in the National Coordinator's seat (he wasn't at the time I asked). Next time around I get to summarize this into a strawman proposal for the workgroup (the reward for a job well-done is another job).
There was a really great question from the caller from AHRQ, which was related to the point I raised about what is our standards architecture for Meaningful Use. After all, if you don't plan one, it just sort of happens. I'm hoping we can discuss that on a future call. I have some idea about what sort of architecture could be extracted from that program.
The transcript will be posted later, and you can find the materials and a subsequent transcript of what was discussed on the HIT FACA Web Site. Here are my slides:
Thursday, October 31, 2013
Wednesday, October 30, 2013
Make A Meal Plan Before You Shop
We have a Saturday ritual at our house. My wife starts a meal plan for the week, and I grab the circular for the grocery store that we use. She tells me what she is trying to do with the plan, and I tell her what is on sale at the store that could fit with it. It helps us identify the things we need, ensuring that we don't leave the store without anything we do. It also helps us ensure that we don't get more than we need to. We also check to make sure we aren't missing anything.
Some Saturday's we don't get to do that, either because we slept in, or the morning is busier than usual. Inevitably, we leave the grocery store having spent more money because we sort of make the meal plan up as we go along (missing out on savings), or leave the store without something essential.
Today on the Data Access Framework call, we were shopping without a list. DAF participants were presented with a list of data elements that might be used for queries or results, and in that list was also a column indicating whether the data elements in that list might be used for a query. Some of the data elements, like race, age and gender, I had a question about. Why would you want to retrieve all documents specific to those patient demographics? What were you trying to do? (What meal are you trying to make). And of course, we really didn't have an answer, because we hadn't really assessed what kinds of queries would actually be needed for various purposes.
I'm hoping that we go back and make that list. Because otherwise, we won't know what data elements are actually required to address a query requirement. In other words, what the ingredients are that we need to make the meal for Monday (or any other day of the week). And without that list, we won't actually know whether we've selected the right set of data elements. So, we need to go back and make a requirements list (a meal plan), and then we can go shopping (select data elements to query on).
The team who put together the list pulled the data elements from the right sources, but they didn't do so in a way that makes it clear from where it came. Along the way, some things were also lost in translation. Healthcare Facility Type Code because Healthcare Facility ID. The former included in HITSP C80 Document Metadata a small set of codes defined by CMS and mapped to a vocabulary. The latter is NPI. At least if all you read was the name. We'll fix that.
The real question to ask is why this metadata is included. John Moehrke put together an excellent blog post that explains XDS Metadata and a classification of metadata into various categories. The categories do a reasonable job of explaining why this data is present, and John also notes that there may be multiple reasons for a particular data element to be present.
And there also may be particular reasons why metadata might exist, but cannot be searched up. For example, IHE made the point in defining the XDS metadata to include patient demographics metadata in the document entry to ensure that we could compare the metadata in the document entry to what appears in the document to trace errors in submissions. Mismatched patient identities is a crucial and far to common problem in exchange scenarios. However, we chose not to make that metadata searchable because there is no particular need. Patient identity is always necessary in an XDS Document Query transaction. This isn't a case where people should be searching for patients without knowing who the patient is. If you allow that, you introduce a target of opportunity into the ecosystem which people would attempt to access to get information about patients they shouldn't have.
It all gets back to what are you trying to do.
Some Saturday's we don't get to do that, either because we slept in, or the morning is busier than usual. Inevitably, we leave the grocery store having spent more money because we sort of make the meal plan up as we go along (missing out on savings), or leave the store without something essential.
Today on the Data Access Framework call, we were shopping without a list. DAF participants were presented with a list of data elements that might be used for queries or results, and in that list was also a column indicating whether the data elements in that list might be used for a query. Some of the data elements, like race, age and gender, I had a question about. Why would you want to retrieve all documents specific to those patient demographics? What were you trying to do? (What meal are you trying to make). And of course, we really didn't have an answer, because we hadn't really assessed what kinds of queries would actually be needed for various purposes.
I'm hoping that we go back and make that list. Because otherwise, we won't know what data elements are actually required to address a query requirement. In other words, what the ingredients are that we need to make the meal for Monday (or any other day of the week). And without that list, we won't actually know whether we've selected the right set of data elements. So, we need to go back and make a requirements list (a meal plan), and then we can go shopping (select data elements to query on).
The team who put together the list pulled the data elements from the right sources, but they didn't do so in a way that makes it clear from where it came. Along the way, some things were also lost in translation. Healthcare Facility Type Code because Healthcare Facility ID. The former included in HITSP C80 Document Metadata a small set of codes defined by CMS and mapped to a vocabulary. The latter is NPI. At least if all you read was the name. We'll fix that.
The real question to ask is why this metadata is included. John Moehrke put together an excellent blog post that explains XDS Metadata and a classification of metadata into various categories. The categories do a reasonable job of explaining why this data is present, and John also notes that there may be multiple reasons for a particular data element to be present.
And there also may be particular reasons why metadata might exist, but cannot be searched up. For example, IHE made the point in defining the XDS metadata to include patient demographics metadata in the document entry to ensure that we could compare the metadata in the document entry to what appears in the document to trace errors in submissions. Mismatched patient identities is a crucial and far to common problem in exchange scenarios. However, we chose not to make that metadata searchable because there is no particular need. Patient identity is always necessary in an XDS Document Query transaction. This isn't a case where people should be searching for patients without knowing who the patient is. If you allow that, you introduce a target of opportunity into the ecosystem which people would attempt to access to get information about patients they shouldn't have.
It all gets back to what are you trying to do.
Tuesday, October 29, 2013
Congitive Load
Healthcare is tremendously complex, but I sometimes wonder if we are suffering needlessly from complexity that we can do without. And if you think technical standards are fraught with unnecessary complexity, acronyms and specialized language, the language of healthcare providers itself can be very confusing to the patient.
One of the classes I am taking this year is The Practice of Healthcare. The text is a 1200 page tome called "The Essentials of Pathophysiology", and we use it to help us understand what clinicians must do for each of 10 cases addressed over the term. The "Essentials" indeed, because the complete work would consume 4-5 times that in paper. Fortunately, I have the electronic copy, which greatly improves my ability to find what I need.
Many of the other students in my class are clinicians in training or in practice, and this material is not quite as daunting for them. I find myself struggling with the reading, having to stop and look up a term about 4 times on each page.
But in the process of doing so, what I have learned is that for many of these terms, there are simpler ways of explaining what these terms mean. I understand the origins of many of the terms, and can routinely parse the meanings of them (but still look them up to be certain). The words I seem to have the biggest problems with aren't the nouns (after all, engineers invent new nouns routinely), but rather the adjectives.
So I wonder, is it really necessary to say ventral and dorsal, or could we say front and back? Is distal the best adjective or would far do? And others like afferent and efferent, did we really need to have a word be able to be changed to its opposite by substitution of a single letter. Would not transmitting and receiving be more readily understood?
How much of a physicians cognitive load is impressed upon him or her by the complexity of a secondary terminology that duplicates the function of words we already have and know? Could that could be improved? (And I also ask myself that same question about technology, but that has been less of an issue).
I'm afraid as I learn more that I might slip into the same pattern of language use. I try to be diligent in my responses to translate the medical language into the English I already know, and avoid the use of three, four and five letter acronyms in my responses. I now understand the short hand, but unless I respond in "my own" language, I'm not actually certain I understand the answer I just gave.
The next time I hear a clinician complain about my technical babblety babble, I'm not sure how I will respond. I certainly have a better understanding of how they feel, but I think I just might explode on their own (ab)uses of language.
One of the classes I am taking this year is The Practice of Healthcare. The text is a 1200 page tome called "The Essentials of Pathophysiology", and we use it to help us understand what clinicians must do for each of 10 cases addressed over the term. The "Essentials" indeed, because the complete work would consume 4-5 times that in paper. Fortunately, I have the electronic copy, which greatly improves my ability to find what I need.
Many of the other students in my class are clinicians in training or in practice, and this material is not quite as daunting for them. I find myself struggling with the reading, having to stop and look up a term about 4 times on each page.
But in the process of doing so, what I have learned is that for many of these terms, there are simpler ways of explaining what these terms mean. I understand the origins of many of the terms, and can routinely parse the meanings of them (but still look them up to be certain). The words I seem to have the biggest problems with aren't the nouns (after all, engineers invent new nouns routinely), but rather the adjectives.
So I wonder, is it really necessary to say ventral and dorsal, or could we say front and back? Is distal the best adjective or would far do? And others like afferent and efferent, did we really need to have a word be able to be changed to its opposite by substitution of a single letter. Would not transmitting and receiving be more readily understood?
How much of a physicians cognitive load is impressed upon him or her by the complexity of a secondary terminology that duplicates the function of words we already have and know? Could that could be improved? (And I also ask myself that same question about technology, but that has been less of an issue).
I'm afraid as I learn more that I might slip into the same pattern of language use. I try to be diligent in my responses to translate the medical language into the English I already know, and avoid the use of three, four and five letter acronyms in my responses. I now understand the short hand, but unless I respond in "my own" language, I'm not actually certain I understand the answer I just gave.
The next time I hear a clinician complain about my technical babblety babble, I'm not sure how I will respond. I certainly have a better understanding of how they feel, but I think I just might explode on their own (ab)uses of language.
Thursday, October 24, 2013
An Answer, and a Question
So a decision on templates versioning for CCDA has been finally made. We'll do the template ID shuffle one more time, and then we'll fix the problem for good afterwards. It's not the answer that I was looking for, but it is an answer. I'm wishing we didn't have to go down that pathway, and if I had marshaled the troops available, I'm certain the outcome could have been different, the votes were that close. That also would have been an obvious abuse of the consensus process, so I'll save that tactic for when it is really needed ;-)
I've been struggling continuously with balancing S&I Framework and HL7 International activities for far too long. I've been hoping to get someone interested in developing a US Standards Collaborative for quite some time, as it seems that it is really necessary. But for some reason, I can't seem to get any traction on this.
So let me ask the question, who would be interested in starting a group to investigate formation of said collaborative? Perhaps the first thing we could investigate is what it would take to form an HL7 USA, and discover who might be interested in that.
If you have some interest, leave a note here, or e-mail me. You can find my contact information here.
I've been struggling continuously with balancing S&I Framework and HL7 International activities for far too long. I've been hoping to get someone interested in developing a US Standards Collaborative for quite some time, as it seems that it is really necessary. But for some reason, I can't seem to get any traction on this.
So let me ask the question, who would be interested in starting a group to investigate formation of said collaborative? Perhaps the first thing we could investigate is what it would take to form an HL7 USA, and discover who might be interested in that.
If you have some interest, leave a note here, or e-mail me. You can find my contact information here.
Wednesday, October 23, 2013
Template Versions ONE LAST TIME (I hope)
We're still stuck on the template identifier versioning problem in HL7 as we try to finish up the CCDA Release 2.0 specification.
The challenge is simply this: In order to clean up after ourselves, we have two choices:
Change just about every template identifier we are currently using in the guide, and replace it with a new (but likely similar identifier).
So:
<templateId root="X"/>
Becomes in most cases:
<templateId root="X.2" />
But that doesn't happen the same way every place because some of those values for X come from a different namespace and have to be totally replaced, and some of those X.2 values may already have existed as well.
OR do something like this:
So:
<templateId root="X"/>
Becomes in all cases:
<templateId root="X" extension="V2.0"/>
The challenge is simply this: In order to clean up after ourselves, we have two choices:
Change just about every template identifier we are currently using in the guide, and replace it with a new (but likely similar identifier).
So:
<templateId root="X"/>
Becomes in most cases:
<templateId root="X.2" />
But that doesn't happen the same way every place because some of those values for X come from a different namespace and have to be totally replaced, and some of those X.2 values may already have existed as well.
OR do something like this:
So:
<templateId root="X"/>
Becomes in all cases:
<templateId root="X" extension="V2.0"/>
And of course, we could always use V2.1 or V2.2 for minor version changes. This latter course is compatible with the current solution that the Templates workgroup has proposed, and also the course that IHE went with (working with HL7 Templates) to upgrade its templates to work with CCDA.
Thursday (tommorrow) is when we make big decision in SDWG. There are two camps still, and they seem to be divided not really over the solution, but rather over the timing of it. For the most part, I believe we are all agreed that when Templates makes the final decision, SDWG will follow it for future release. But in this particular case, there are some outside pressures pushing SDWG to have CCDA Release 2.0 out the door before templates can make its decision. That pressure seems to be coming from the usual source: ONC/CMS.
Now, I have to ask, one more time. Do we really need to make this kind of trouble for ourselves? Or can we do the right thing? Frankly, the right thing is to let templates make the decision, and follow it. Given the recent interruptions in service from the government, I'd say that several bets about deadlines are changing. I know the HIT Standards Committee was already rethinking its deadlines before the shutdown, and now are almost certainly not going to reach their goals. I really would like to see ONC/CMS back off on any deadline pressure that they have, and let HL7 governance be able to address the specification development the right way.
When I count the voices I've heard, it seems overwhelming that the negatives are coming from a very few sources.
If you care about this issue, and want to be heard, I ask for one thing: Show up on the Structured Documents call tomorrow (See the Upcoming Calls Section of the page). We'll be covering the topic in the first hour (10:00-11:00 Eastern).
Thursday (tommorrow) is when we make big decision in SDWG. There are two camps still, and they seem to be divided not really over the solution, but rather over the timing of it. For the most part, I believe we are all agreed that when Templates makes the final decision, SDWG will follow it for future release. But in this particular case, there are some outside pressures pushing SDWG to have CCDA Release 2.0 out the door before templates can make its decision. That pressure seems to be coming from the usual source: ONC/CMS.
Now, I have to ask, one more time. Do we really need to make this kind of trouble for ourselves? Or can we do the right thing? Frankly, the right thing is to let templates make the decision, and follow it. Given the recent interruptions in service from the government, I'd say that several bets about deadlines are changing. I know the HIT Standards Committee was already rethinking its deadlines before the shutdown, and now are almost certainly not going to reach their goals. I really would like to see ONC/CMS back off on any deadline pressure that they have, and let HL7 governance be able to address the specification development the right way.
When I count the voices I've heard, it seems overwhelming that the negatives are coming from a very few sources.
If you care about this issue, and want to be heard, I ask for one thing: Show up on the Structured Documents call tomorrow (See the Upcoming Calls Section of the page). We'll be covering the topic in the first hour (10:00-11:00 Eastern).
Khannnn!
I'm not sure how to approach this one. It started with a Twitter exchange that got me thinking about how to teach CDA, and my own Informatics class work which involves short lectures from the Khan Academy. I'm wondering how to put the two concepts together. I have all the content I need (and others have content for other training).
What I'm wondering about is what it would take to start putting together some short (5-10 minute) videos , and how they should be structured. I found this explanation about what tools the Khan Academy uses for its videos.
Being able to edit XML on the screen in real time, and annotate it with a pen while recording would be great. I'm not sure what tools I would need to do that. I seem to recall webex has a way you can do that, which may be a way that I can annotate on screen while I'm using an application. I might also be able to record the output, but then I'd have to convert that to a more usable format. I just don't have enough experience with either of those tools. Some screen capture programs might have the right capabilities. I'd love to be able to annotate real time while I'm demonstrating.
I'm thinking that a class (or element) or template or data type (or two) might be about the right level of segmentation for each one. I'm going to have to try to find time to try this out.
Damn. Just what I needed. Another project. Although this one might actually save me time in the long run.
What I'm wondering about is what it would take to start putting together some short (5-10 minute) videos , and how they should be structured. I found this explanation about what tools the Khan Academy uses for its videos.
Being able to edit XML on the screen in real time, and annotate it with a pen while recording would be great. I'm not sure what tools I would need to do that. I seem to recall webex has a way you can do that, which may be a way that I can annotate on screen while I'm using an application. I might also be able to record the output, but then I'd have to convert that to a more usable format. I just don't have enough experience with either of those tools. Some screen capture programs might have the right capabilities. I'd love to be able to annotate real time while I'm demonstrating.
I'm thinking that a class (or element) or template or data type (or two) might be about the right level of segmentation for each one. I'm going to have to try to find time to try this out.
Damn. Just what I needed. Another project. Although this one might actually save me time in the long run.
Tuesday, October 22, 2013
Healthcare Cost Resources
One of the "extras" I added to an assignment was to add cost data to diagnosis and treatment options for my "disease project" paper in one of my classes. I found a number of resources that were somewhat helpful in finding cost data. While the variations in cost for different tests and treatments are quite insane, I can verify that they do in fact exist, and that I have seen some of these ranges even from my own insurer.
Some useful resources at the Meta-level:
Members of the Society for Participatory Medicine were especially helpful in answering my queries.
Twitter as always helps: @PracticalWisdom @RichDuszak @dlschermd @ElinSilveous @emilayamei and @Berci all provided some useful feedback and links.
Some of these tools require that you know the right codes. If you don't know the ICD or CPT code, just write the name of the procedure and add ICD-9 or CPT to the search criteria. You'll find it.
These were the tools I wound up using in my search
And then there's always Google.
Some useful resources at the Meta-level:
Members of the Society for Participatory Medicine were especially helpful in answering my queries.
Twitter as always helps: @PracticalWisdom @RichDuszak @dlschermd @ElinSilveous @emilayamei and @Berci all provided some useful feedback and links.
Some of these tools require that you know the right codes. If you don't know the ICD or CPT code, just write the name of the procedure and add ICD-9 or CPT to the search criteria. You'll find it.
These were the tools I wound up using in my search
- New Choice Health
Not every procedure is covered, and they have limited coverage of various cities. If you live close enough to a big one, you'll find it. I wish they'd provide national level ranges for some procedures. - Health Care Blue Book
Also missing a number of procedures, but has more than New Choice Health. The method by which fair price is determined isn't terribly transparent (to me at least), but the prices seem to be in line. - AHRQ Healthcare Cost and Utilization Project
Hospital data only apparently. Still quite useful and an lot more detail than you might expect. - Medicare Physician Fee Schedule Search
Non-hospital fees for various treatments and diagnostics. Useful but I wish there was a way to get min/max/average easily for a codes list or range
And then there's always Google.
Friday, October 18, 2013
What is an Informaticist?
So I have to write a term paper (actually three) for some of my classes. For one of them I started to organize my thoughts, and modified an exercise I learned in a change acceleration class to help me do so. The goal of the exercise was to generate my "elevator speech", and my topic was the role of an informaticist.
If I plug in various adjectives, I can describe various specializations of informatics and informaticists in much the same way:
Medical Bioinformaticists work with (principally) biomedical data, and help biomedical staff answer the questions they have about it.
Clinical informaticists work with (principally) clinical data, and help clinical staff answer the questions they have about it.
Public health informaticists work with (principally) public (or population) health data, and help public health practitioners answer the questions they have above it.
Consumer Health informaticists work with a variety of health data, and help consumers answer the questions they have about it.
This worked well enough for me as an elevator speech that I proceeded with the next step (focusing on consumer informatics), which is the kinds of questions that a consumer has.
The questions that a consumer has with respect to health data are related to three segments of time:
"The role of an informaticist is to facilitate the development of systems and processes which enable questions to be answered from available data."Systems and processes need not be "computer programs". They can be card files, paper forms or other methods. Facilitation means that the informaticist is not necessarily the sole person involved in the development of these systems and processes. What informaticists do is bring knowledge about how to use information to the process of designing such systems. The statement doesn't say who is asking or answering the questions. Part of the informaticists role may be in making data available.
If I plug in various adjectives, I can describe various specializations of informatics and informaticists in much the same way:
Medical Bioinformaticists work with (principally) biomedical data, and help biomedical staff answer the questions they have about it.
Clinical informaticists work with (principally) clinical data, and help clinical staff answer the questions they have about it.
Public health informaticists work with (principally) public (or population) health data, and help public health practitioners answer the questions they have above it.
Consumer Health informaticists work with a variety of health data, and help consumers answer the questions they have about it.
This worked well enough for me as an elevator speech that I proceeded with the next step (focusing on consumer informatics), which is the kinds of questions that a consumer has.
The questions that a consumer has with respect to health data are related to three segments of time:
- Understanding the past. How did this happen? What caused it?
- Interpreting the present What can I do about it? What does this mean for me now?
- Predicting the future. What is likely to happen? What can I do to change it?
Let's see where this goes.
Wednesday, October 16, 2013
Delivering and Measuring Consensus
In any standards project, you have at least one key deliverable, and that is the specification. How is that any different from other tasks where you can put 1,2,3 .. 5 whatever number of experts together to produce something that will work (or fail)? It isn't really. The experts work out the details, focusing on their areas of expertise, and form and storm and norm and eventually product a work product.
What is different in standards work is the almost forgotten delivery that goes along with a successful standard. Consensus. Sometimes in our haste to get things done, we forget that this is also a deliverable. That we, in the course of obtaining our insights into the problems we have solved, must also share those with others in a way that they see what we see, and hopefully agree that we have solved it in the right way.
And the best measures of consensus aren't yes votes. No, those measures are better indicated by two things, one short term, and one in the longer term. In the shorter term, you can measure consensus by how the workgroup feels after the shouting is over and the job is done. Did we feel good about what we delivered? Do we think it was worth doing? Or are we so glad that is behind us so we can get onto some real work?
And in the longer term, did it get used? Implemented by someone? Incorporated into a program? Or at the very least, did it feed into and inform something else of use.
In the end, it isn't about delivering a specification. Anyone can sit in a room by themselves and write (I do that on a daily basis). The real measure is whether what you delivered is consensus.
What is different in standards work is the almost forgotten delivery that goes along with a successful standard. Consensus. Sometimes in our haste to get things done, we forget that this is also a deliverable. That we, in the course of obtaining our insights into the problems we have solved, must also share those with others in a way that they see what we see, and hopefully agree that we have solved it in the right way.
And the best measures of consensus aren't yes votes. No, those measures are better indicated by two things, one short term, and one in the longer term. In the shorter term, you can measure consensus by how the workgroup feels after the shouting is over and the job is done. Did we feel good about what we delivered? Do we think it was worth doing? Or are we so glad that is behind us so we can get onto some real work?
And in the longer term, did it get used? Implemented by someone? Incorporated into a program? Or at the very least, did it feed into and inform something else of use.
In the end, it isn't about delivering a specification. Anyone can sit in a room by themselves and write (I do that on a daily basis). The real measure is whether what you delivered is consensus.
Tuesday, October 15, 2013
Engaging also means sharing language
I read a short history and physical this morning. It was filled with abbreviations common to physicians, and I've seen things like this before: ROS, PE, ABD, HEENT, HTN, Rx, Tx, Dx, Hx, Px, BP. If I were to alphabetize the list and present it without contextual cues, I bet a number of trained physicians might even misinterpret some of these. With contextual cues and a trained person, I'm certain they wouldn't as much.
These are useful ways to create information. From a UX (I mean User Experience, see other groups do this too) perspective, it is pretty clear that providing mechanisms for expert entry of information is quite useful and speeds up the process. But from other perspectives, including presentation, it's not as usable for everyone.
When we (provider and patients) want to be engaged with each other, it's very clear that we need to move more closely towards patient language. Medical language is quite precise, but we can simplify a good deal of it: Which question would stop you in your tracks? Do you have nocturia? Or Do you pee at night? Have you ever been short of breath? Did you ever experience dyspnea?
In some ways language helps establish norms and culture. Geeks invent their own language, and we are surrounded in acronym soup all the time. Medical geeks do the same thing. What's a bit different with medical geeks is that their language has been around quite a bit longer, and may be a harder habit to break.
As technologists, we may be able to help mediate that transformation between what the physician sees and what the patient understands.
These are useful ways to create information. From a UX (I mean User Experience, see other groups do this too) perspective, it is pretty clear that providing mechanisms for expert entry of information is quite useful and speeds up the process. But from other perspectives, including presentation, it's not as usable for everyone.
When we (provider and patients) want to be engaged with each other, it's very clear that we need to move more closely towards patient language. Medical language is quite precise, but we can simplify a good deal of it: Which question would stop you in your tracks? Do you have nocturia? Or Do you pee at night? Have you ever been short of breath? Did you ever experience dyspnea?
In some ways language helps establish norms and culture. Geeks invent their own language, and we are surrounded in acronym soup all the time. Medical geeks do the same thing. What's a bit different with medical geeks is that their language has been around quite a bit longer, and may be a harder habit to break.
As technologists, we may be able to help mediate that transformation between what the physician sees and what the patient understands.
Friday, October 11, 2013
DAF Transport
Some initial thoughts on DAF "transport" layers:
If you are working in a REST framework, your syntax will be JSON or XML. Few other choices make sense. For that, EUA or IUA would be where I'd go for authentication/authorization. XUA is really designed for the SOAP stack.
If you are working in a SOAP framework, your syntax will most likely be XML. I can't imagine someone using SOAP trying to parse ER7 or JSON. You have a couple of choices for your XML. Could it be FHIR, HL7 V3, HL7 V2, or ebXML. This is an area where we have to apply some critical. All of these are reasonable choices, but, why would you want to use FHIR with SOAP? And while there are deployments of V2 messages using XML in SOAP, this is again, not really a platform combination that I'd see being terribly viable.
If you are working in SMTP, your syntax is really going to be about MIME, and inside that, well, you could have an XML attachment or a collection of things (e.g., an XDM ZIP file). You will secure the content using S/MIME. The query/response pattern is not a very common one with SMTP, but it has been done by many mailing list management packages, where a simple query can be submitted to the list server in the subject line, and the e-mail you get back is the response.
If you are working in MLLP, your syntax will most likely be ER7 or XML, and semantics would come from HL7 V2. EUA is really the only choice for authentication as far as I can tell, but I'll have to check. There may be some ways in which XUA could be supported here. It might be amusing to translate ER7 notation into JSON via a more direct route, but that's already been done much better by FHIR. There are a few cases where V3 has been communicated using MLLP, but this is a rare bird hardly ever seen in the wild. A few known instances exist in captivity.
- For syntax, we have ER7, XML and JSON.
- For Transport, we have SMTP, REST, SOAP/HTTP, and MLLP that are existing choices in various IHE profiles.
- For Node authentication and encryption we have just TLS, but we really don't need to be able to replace that component.
- For authentication/authorization we have IUA, EUA, and XUA.
If you are working in a REST framework, your syntax will be JSON or XML. Few other choices make sense. For that, EUA or IUA would be where I'd go for authentication/authorization. XUA is really designed for the SOAP stack.
If you are working in a SOAP framework, your syntax will most likely be XML. I can't imagine someone using SOAP trying to parse ER7 or JSON. You have a couple of choices for your XML. Could it be FHIR, HL7 V3, HL7 V2, or ebXML. This is an area where we have to apply some critical. All of these are reasonable choices, but, why would you want to use FHIR with SOAP? And while there are deployments of V2 messages using XML in SOAP, this is again, not really a platform combination that I'd see being terribly viable.
If you are working in SMTP, your syntax is really going to be about MIME, and inside that, well, you could have an XML attachment or a collection of things (e.g., an XDM ZIP file). You will secure the content using S/MIME. The query/response pattern is not a very common one with SMTP, but it has been done by many mailing list management packages, where a simple query can be submitted to the list server in the subject line, and the e-mail you get back is the response.
If you are working in MLLP, your syntax will most likely be ER7 or XML, and semantics would come from HL7 V2. EUA is really the only choice for authentication as far as I can tell, but I'll have to check. There may be some ways in which XUA could be supported here. It might be amusing to translate ER7 notation into JSON via a more direct route, but that's already been done much better by FHIR. There are a few cases where V3 has been communicated using MLLP, but this is a rare bird hardly ever seen in the wild. A few known instances exist in captivity.
Transport | Syntax | Semantics | Authentication/ Authorization | Encryption |
---|---|---|---|---|
MLLP | ER7 | HL7 V2 | EUA | TLS |
MLLP | XML | HL7 V2 | EUA | TLS |
SOAP | XML | HL7 V3/ebXML | EUA | TLS |
SOAP | XML | HL7 V3/ebXML | XUA | TLS |
REST | XML | HL7 FHIR | EUA | TLS |
REST | XML | HL7 FHIR | IUA | TLS |
REST | JSON | HL7 FHIR | EUA | TLS |
REST | JSON | HL7 FHIR | IUA | TLS |
SMTP | XML | MIME | S/MIME | TLS and S/MIME |
This isn't quite as bad at the previous set of choices. The only choice not presently supported somewhere by IHE is V2 Semantics with XML Syntax. There's a lot more nuance and detail to cover.
Thursday, October 10, 2013
SAIF in SDO Terms
One of the challenges with the HL7 SAIF Architecture is that it is framed in RM-ODP terms that aren't always familiar to the common SDO member. In working through the Theory of Everything a couple of weeks back, I translated those terms into everyday language as understood by HL7 members. In working with PCC and ITI members today, I used that same slide deck to frame how we might approach the DAF proposal from S&I Framework to IHE.
Tonight (this morning actually), I translated that same slide into IHE terms. I think my next step after this is to translate it into terms understood by the everyday software geek, but I'll save that for a day when I've had more sleep (today started at 5:00am, and if I'm not careful, it could end there as well).
So here are the slides starting with the original HL7 slide:
Moving to the terms that I used two weeks ago at HL7
Tonight (this morning actually), I translated that same slide into IHE terms. I think my next step after this is to translate it into terms understood by the everyday software geek, but I'll save that for a day when I've had more sleep (today started at 5:00am, and if I'm not careful, it could end there as well).
So here are the slides starting with the original HL7 slide:
Moving to the terms that I used two weeks ago at HL7
And now in similar terms for IHE.
Wednesday, October 9, 2013
The Patient View Profile
Today in IHE PCC we discussed a proposal to enable a good patient experience when viewing content. One of the unique things about this profile is that while it doesn't specify what a user experience should be, it enables systems to provide for a good user experience.
Here are some of the kinds of features the profile could enable hiding, showing, organizing or highlighting content according to user preferences and/or policies.
Here are some of the kinds of features the profile could enable hiding, showing, organizing or highlighting content according to user preferences and/or policies.
- Branding content.
- Patient demographics
- Empty sections
- Future appointments.
- Content Assessed during this visit.
- Modified/updated during this visit.
- Patient Contacts
- Provider List
The profile would, in volume I describe the user experience capabilities we want to enable, and in volume III, identify the ways we could classify narrative content to enable them.
Monday, October 7, 2013
Essential Tools for the Remote Healthcare Informatics Student
As you are probably already aware, I recently enrolled in OHSU's Clinical Informatics program. I have two classes, the Intro to Informatics, and Practice of Healthcare classes. Being a distance learning student has a unique set of requirements.
Textbook
Ideally, I can take my textbooks with me in electronic format. One of the classes has a required text that is 1200+ pages, which I can (and have) purchased in Kindle format. I like even better being able to search the text electronically. It makes it much easier to find things I know I've read that would be fairly difficult to find thumbing pages.
Access to Classroom Content
OHSU uses Sakai, which means that a good deal of class content is delivered through either Flash, or a combination of PDF and MP3. There are at least two (and possibly more) challenges here due to the fact that I use an iPad as my primary tablet device. Flash is of course a problem for access via the iPad. MP3's are also a problem because most browsers don't "download", instead offering to playback the content in their own control.
Flash Browsers
There are a couple of browsers that do support Flash (via server mediated interpretation). The one I looked at thus far was Puffin Browser, which has both a free and paid edition (you need the paid edition for long term use with Flash). The problem with any paid stuff is that you don't know if it will work until after you've bought it, and then you are stuck. I was pleased with Puffin's free trial and will likely purchase the full edition. Puffin works fine with Flash, but it is missing a critical capability -- variable playback speed, which I'll mention next.
Variable Playback Speed
Recorded media, such as Flash and MP3 can be run at different speeds. I find that I can readily listen at double speed and still take good notes (pausing as needed). This is especially useful when some of the material is review (I find myself speed adjusting depending on the content).
I've looked at a couple of tools. One of these is Swift for the iPad (and iPhone) which is a relatively cheap application that can speed up MP3 playback and video playback. Once you have an MP3 transferred to your iPad, you can request it be opened in Swift. The frustrating bit is that the two browsers I already had: Chrome and Safari (because I cannot get rid of it), don't download the MP3, they play in back in their own controls. I looked at other tools and I finally just downloaded the content to my PC and then uploaded it into Drop Box. That's still challenging because then I have to favorite it in Drop Box on my iPad to force local download, which then allows opening it in Swift. Those gyrations aren't really all that bad, but the user experience could be a hell of a lot easier. Swift is worthwhile but I wish there was something better because it won't let me log in right now (it appears to be a cookie problem). It supposedly has a way to access content via the Web (so I could avoid the MP3 download to my computer, upload to DropBox, to favorite in DropBox to open in Swift steps), but that fails during the login process. I haven't spent much time trying to debug that (it being on an iPad and over https:, that would be fairly challenging).
On my personal computer, I've also looked at Enounce, but haven't gotten past the buffering stutter issue it causes on Windows. So while I can speed up the audio, then I have to wait for it to download the next chunk, which makes it not a useful tool. I wouldn't spend the money.
A couple of other gotcha's with the iPad and Distance Learning
Textbook
Ideally, I can take my textbooks with me in electronic format. One of the classes has a required text that is 1200+ pages, which I can (and have) purchased in Kindle format. I like even better being able to search the text electronically. It makes it much easier to find things I know I've read that would be fairly difficult to find thumbing pages.
Access to Classroom Content
OHSU uses Sakai, which means that a good deal of class content is delivered through either Flash, or a combination of PDF and MP3. There are at least two (and possibly more) challenges here due to the fact that I use an iPad as my primary tablet device. Flash is of course a problem for access via the iPad. MP3's are also a problem because most browsers don't "download", instead offering to playback the content in their own control.
Flash Browsers
There are a couple of browsers that do support Flash (via server mediated interpretation). The one I looked at thus far was Puffin Browser, which has both a free and paid edition (you need the paid edition for long term use with Flash). The problem with any paid stuff is that you don't know if it will work until after you've bought it, and then you are stuck. I was pleased with Puffin's free trial and will likely purchase the full edition. Puffin works fine with Flash, but it is missing a critical capability -- variable playback speed, which I'll mention next.
Variable Playback Speed
Recorded media, such as Flash and MP3 can be run at different speeds. I find that I can readily listen at double speed and still take good notes (pausing as needed). This is especially useful when some of the material is review (I find myself speed adjusting depending on the content).
I've looked at a couple of tools. One of these is Swift for the iPad (and iPhone) which is a relatively cheap application that can speed up MP3 playback and video playback. Once you have an MP3 transferred to your iPad, you can request it be opened in Swift. The frustrating bit is that the two browsers I already had: Chrome and Safari (because I cannot get rid of it), don't download the MP3, they play in back in their own controls. I looked at other tools and I finally just downloaded the content to my PC and then uploaded it into Drop Box. That's still challenging because then I have to favorite it in Drop Box on my iPad to force local download, which then allows opening it in Swift. Those gyrations aren't really all that bad, but the user experience could be a hell of a lot easier. Swift is worthwhile but I wish there was something better because it won't let me log in right now (it appears to be a cookie problem). It supposedly has a way to access content via the Web (so I could avoid the MP3 download to my computer, upload to DropBox, to favorite in DropBox to open in Swift steps), but that fails during the login process. I haven't spent much time trying to debug that (it being on an iPad and over https:, that would be fairly challenging).
On my personal computer, I've also looked at Enounce, but haven't gotten past the buffering stutter issue it causes on Windows. So while I can speed up the audio, then I have to wait for it to download the next chunk, which makes it not a useful tool. I wouldn't spend the money.
A couple of other gotcha's with the iPad and Distance Learning
- Editing long text without a keyboard is challenging. Invest in a good one.
- Write your text in notepad or some other tool and then upload to Sakai, because if you take too long, Sakai will time you out, and then you'll lose all the text you wrote in the browser rich text edit control.
If I hadn't already had an iPad, I'd use a different tablet computer for this class. As it is, I'll work around these issues.
Friday, October 4, 2013
IHE NA Connectathon Monitors Needed!
IHE USA Volunteers Gain Real-world IHE Experience!
IHE USA is looking for volunteer monitors to verify testing at the IHE NA Connectathon 2014, January 27 - 31, 2014, in downtown Chicago. Monitors use their skills and expertise to review interoperability tests performed by participating organizations at the North American Connectathon. As a monitor, you will examine evidence presented by participants and assign a pass/fail grade for each test.
Benefits of Volunteering:
· Opportunity to work directly with software engineers from the industry's top vendors.
· Gain deeper understanding about IHE Integration Profiles and how to implement IHE profiles.
· Gain hands-on experience and training for IHE software test tools.
· Explore opportunities for collaboration with vendors and HIEs in attendance
· Monitors receive travel, accommodations, and a daily per Diem for their participation (Note: IHE USA will not support international travel outside the U.S. and Canada.)
General Requirements of Participation:
· Must be available for the full week of the NA Connectathon 2014
o Monday, January 27 – Friday, January 31, 2013
o Monday, January 27 – Friday, January 31, 2013
· Monitors may NOT be employed by a participating vendor, nor be under contract to provide consulting or any other services to a participating vendor
· Completion of Conflict of Interest form
· Completion of Non-Disclosure agreement
· Applicants must have appropriate technical background in one of the 9 healthcare IT areas listed:
o IT Infrastructure
o Clinical Documents (HL7 CDA)
o Radiology and/or Cardiology departmental workflow
o Laboratory and/or Pharmacy
o Patient Care Devices
o Patient Care Coordination & Quality, Research, and Public Health
o IT Infrastructure
o Clinical Documents (HL7 CDA)
o Radiology and/or Cardiology departmental workflow
o Laboratory and/or Pharmacy
o Patient Care Devices
o Patient Care Coordination & Quality, Research, and Public Health
Applications Due October 4, 2013
All applicants must submit the following items by October 4, 2013, in order to be considered for participation on the 2014 Monitor team:
- Complete the online application: Apply Now!
- Send your CV to Steve Moore at smoore@wustl.edu
All applicants will be notified via email the week of October 14, 2013, regarding acceptance into the program. For more information, please visit IHE USA’s Volunteer webpage.
We value your collaboration and continued support of the IHE NA Connectathon!
Kind Regards,
IHE USA Staff
Is ONC Essential?
This most excellent question was posed on Twitter by Tom Sullivan, editor of Government Health IT.
Let's look at what isn't happening, and ask some critical questions:
1. TTT is still down. Actually, it's just NIST's version of it that is down. The real challenge here is not for testing bodies, but for organizations trying to certify product who need access to this tool prior to their certification runs.
What does this mean? It means that organizations that didn't have time, skills or resources to duplicate the TTT infrastructure are stuck on testing. Some certifiers have a copy of the testing tool handy (e.g., CCHIT reported that they do). Contact your certifier and see if they'll make that available to you for precertification testing. And next time, get a copy of the tools before they go away.
It would be nice if someone else who had them made them publicly available to anyone, customer or otherwise, to use while folks are off on furlough, and it would be a huge publicity bump. We as an industry should take some responsibility for having the necessary infrastructure. but I digress.
Essential? Only if having vendors be able to provide product so that providers can start Meaningful Use Stage 2 on time is essential. If necessary, both CMS and ONC have the regulatory tools to fix the problem. The folks most hurt by this are likely smaller vendors, who either haven't already tested, or didn't replicate the testing tools.
Essential? Maybe. Missed? Absolutely. But the reality is, probably not as much when I compare it to other things that aren't happening.
2. CHPL isn't being updated. That's a potential challenge in the long term, but not just yet. If it starts impacting the ability of vendors to provide product or providers to use certified product, then yes, it could be worth looking over. But I don't see a delay lasting as long as by when someone has to attest for Stage 2. f that were to happen, there's a lot more important things to worry about.
Essential? Nah. Missed? A bit.
3. Federal employee engagement in standard development. They have the requirements, but they mostly contract out the work. Contractors are somewhat impacted, but many are still working.
Essential? Nah. Missed? Not yet, but could be soon.
4. S&I Framework: You wouldn't believe the number of hours that I'm spending this week and next on project proposals coming out of S&I. And while key Federal people aren't available to discuss them, the rest of the world moves on why the Government remains at a stand-still.
The only essential things here are what ONC considers to be essential to meet it's mandates. And what I'd like to see is a bit more rational pace.
HL7 is moving forward with Project Scope Statements on the Theory of Everything related to Clinical Quality even though they aren't here to guide us. Volunteers got it done.
There are some ways we could make S&I Framework more volunteer driven, less a burden on ONC, and more relevant to healthcare provider needs, but I think one of its values to ONC is that it is very driven by ONC requirements. There's a middle path in here somewhere, and it could be worth exploring again in the future.
Essential? No. Missed? Yes.
5. FACA Meetings not being held. Development of regulation is being slowed down.
Essential? No. Missed? Not really. Those deadlines were insane to start with. It's important work, but that also means its important to do right. And right and fast don't always go together.
I think the most hurtful component of ONC cutting back to the healthcare economic sector is what these delays mean for healthcare providers and healthcare IT vendors with respect to Meaningful Use stage 2. There seems to be some economic impact here, but I have no clue how to measure it. But I bet there's some essential person at OMB who could compute the economic cost of the shutdown working right now.
The next most challenging impact is on the final quality of results should ONC try a hurry up to hit some of its internally set deadlines with regard to new regulations. If congress shuts you down, and you wind up being late, I don't think they should count that against you. As I recall, the Secretary of HHS has some leeway here.
The really painful part will be kick-starting everything again. I feel bad for Jacob. What better way could there be to start a new job but to send all your people home.
Overall, Essential? No. Missed? Yes.
Let's look at what isn't happening, and ask some critical questions:
1. TTT is still down. Actually, it's just NIST's version of it that is down. The real challenge here is not for testing bodies, but for organizations trying to certify product who need access to this tool prior to their certification runs.
What does this mean? It means that organizations that didn't have time, skills or resources to duplicate the TTT infrastructure are stuck on testing. Some certifiers have a copy of the testing tool handy (e.g., CCHIT reported that they do). Contact your certifier and see if they'll make that available to you for precertification testing. And next time, get a copy of the tools before they go away.
It would be nice if someone else who had them made them publicly available to anyone, customer or otherwise, to use while folks are off on furlough, and it would be a huge publicity bump. We as an industry should take some responsibility for having the necessary infrastructure. but I digress.
Essential? Only if having vendors be able to provide product so that providers can start Meaningful Use Stage 2 on time is essential. If necessary, both CMS and ONC have the regulatory tools to fix the problem. The folks most hurt by this are likely smaller vendors, who either haven't already tested, or didn't replicate the testing tools.
Essential? Maybe. Missed? Absolutely. But the reality is, probably not as much when I compare it to other things that aren't happening.
2. CHPL isn't being updated. That's a potential challenge in the long term, but not just yet. If it starts impacting the ability of vendors to provide product or providers to use certified product, then yes, it could be worth looking over. But I don't see a delay lasting as long as by when someone has to attest for Stage 2. f that were to happen, there's a lot more important things to worry about.
Essential? Nah. Missed? A bit.
3. Federal employee engagement in standard development. They have the requirements, but they mostly contract out the work. Contractors are somewhat impacted, but many are still working.
Essential? Nah. Missed? Not yet, but could be soon.
4. S&I Framework: You wouldn't believe the number of hours that I'm spending this week and next on project proposals coming out of S&I. And while key Federal people aren't available to discuss them, the rest of the world moves on why the Government remains at a stand-still.
The only essential things here are what ONC considers to be essential to meet it's mandates. And what I'd like to see is a bit more rational pace.
HL7 is moving forward with Project Scope Statements on the Theory of Everything related to Clinical Quality even though they aren't here to guide us. Volunteers got it done.
There are some ways we could make S&I Framework more volunteer driven, less a burden on ONC, and more relevant to healthcare provider needs, but I think one of its values to ONC is that it is very driven by ONC requirements. There's a middle path in here somewhere, and it could be worth exploring again in the future.
Essential? No. Missed? Yes.
5. FACA Meetings not being held. Development of regulation is being slowed down.
Essential? No. Missed? Not really. Those deadlines were insane to start with. It's important work, but that also means its important to do right. And right and fast don't always go together.
I think the most hurtful component of ONC cutting back to the healthcare economic sector is what these delays mean for healthcare providers and healthcare IT vendors with respect to Meaningful Use stage 2. There seems to be some economic impact here, but I have no clue how to measure it. But I bet there's some essential person at OMB who could compute the economic cost of the shutdown working right now.
The next most challenging impact is on the final quality of results should ONC try a hurry up to hit some of its internally set deadlines with regard to new regulations. If congress shuts you down, and you wind up being late, I don't think they should count that against you. As I recall, the Secretary of HHS has some leeway here.
The really painful part will be kick-starting everything again. I feel bad for Jacob. What better way could there be to start a new job but to send all your people home.
Overall, Essential? No. Missed? Yes.
Thursday, October 3, 2013
IHE PCC Profile Proposals for 2014-2015 Cycle
IHE Patient Care Coordination discussed two profiles for our next cycle, both of which I hope will go forward. The first of these is to support reconciliation of goals, care plans and care teams. This is pretty much a no brainer. Yes, these things definitely need to be able to be reconciled, and we've already established some pretty good patterns in the IHE Reconcilliation Profile (RECON) when we addressed problems, medications and allergies.
The next profile is even more fun to consider, and fortunately for me, the original name of it was right, even though I disagreed quite strongly with the approach. The idea was that there should be a profile that enabled a provider to give a patient a useful view of the information used in a recent encounter. The full proposal name slips my mind at the moment (I overloaded on classwork last night), but the first two words were Patient and View. And View is really the key word here. It is a virtual representation or projection of a total collection of information onto some other space.
We talked about the patient view, and I think that's a fine first place to approach this. One of the reasons for addressing this as a view, rather than a new form of CDA document is that as a patient, I want to see exactly what the doctor sees, as is done with Open Notes. So, I'm not interested in a restricted set of data. I want the whole thing. However, I also see the point that there aught to be a way to mark (tag, add metadata) to content in a document that enables end-users to filter and make better use of information.
Some of the metadata that might be needed:
All of the above has to do with so-called control-acts in HL7 Version 3 (which aren't directly supported in HL7 CDA -- but there may be a way to address that).
There are also ways to identify cases where:
The next profile is even more fun to consider, and fortunately for me, the original name of it was right, even though I disagreed quite strongly with the approach. The idea was that there should be a profile that enabled a provider to give a patient a useful view of the information used in a recent encounter. The full proposal name slips my mind at the moment (I overloaded on classwork last night), but the first two words were Patient and View. And View is really the key word here. It is a virtual representation or projection of a total collection of information onto some other space.
We talked about the patient view, and I think that's a fine first place to approach this. One of the reasons for addressing this as a view, rather than a new form of CDA document is that as a patient, I want to see exactly what the doctor sees, as is done with Open Notes. So, I'm not interested in a restricted set of data. I want the whole thing. However, I also see the point that there aught to be a way to mark (tag, add metadata) to content in a document that enables end-users to filter and make better use of information.
Some of the metadata that might be needed:
- Was this information verified this visit.
- Was this information otherwise updated this visit (e.g., change in medications).
- Was this information added this visit.
- Was any information removed during this visit.
All of the above has to do with so-called control-acts in HL7 Version 3 (which aren't directly supported in HL7 CDA -- but there may be a way to address that).
There are also ways to identify cases where:
- There's no information to be presented (other than the fact that there's no information).
- These are positive findings.
- These are the negative findings.
These have to do with various ways to say NO, YES, and UNKNOWN. Tri-state values on responses to key questions or observations that could be made during review of systems or physical examinations or other values.
Then there are differences that might have to do with interpretations:
- This is within normal limits
- This is outside of normal limits
- This is something to be really worried about.
I find myself both satisfied and amused that I'm using Tuesday night homework in putting together my analysis for today's feedback on this profile proposal.
These are the only two profile proposals that IHE PCC has. We are also still waiting with baited breath on the outcome of discussions next Thursday at the HL7 SDWG call on CCDA Release 2.0 template versioning, and what's needed to handle that, and whether it must all go half-way back to the drawing board or not in our harmonization efforts. I really do hope they adopt the solution I proposed. IHE has been coordinating a great deal with Templates on how to version artifacts, I'm hoping that SDWG will take the same approach.
Next week we'll be in Oakbrook to further define and refine these proposals. There may also be some work from DAF to look at, but ITI has first crack at that.
Wednesday, October 2, 2013
History can be Anything or "Patient Reported" ≠ "Subjective"
One of the classic forms for provider notes uses the acronym SOAP. I always wondered where "History" fell. In the notes I see being created, it's most often somewhere between the subjective [chief] complaint / reason for visit and history of present illness, and before review of systems, although sometimes it follows that. Inevitably the medications, allergies, family and social history are almost always before the physical examination.
It's pretty obvious that you need to gather the information that's going to guide your future activities before you start those activites. Right? Right.
The challenge of the acronym is the subtle distinction between Subjective and Objective. The former is individual, inconsistent between observers (unrepeatable), opinion. The latter is repeatable, observable, measurable, facts. The classification of patient reported as "subjective" simply isn't fair. Some of it is. Some of it isn't, and is in fact quite verifiable. Past medications, diagnoses, allergies, et cetera.
Clinician assessments are sometimes just as subjective. Terms like comfortable, or slight, or pleasant convey something of the physicians opinion of the overall appearance, but they aren't any less an opinion than a patient's statement of how they feel.
So let's forget SOAP and move to SHOAP. History is after all, just a collection of what happened in the past, be it subjective, or objective, or assessment or plan. How many times has physician put what you wrote down in your history as a problem or medication in your chart? How did that act make it any more or less objective? It didn't.
Keith
P.S. I came up with a new acronym for this style of reporting, but I think the debate about it would be far too confusing for those of us who have to cross the IT boundary.
It's pretty obvious that you need to gather the information that's going to guide your future activities before you start those activites. Right? Right.
The challenge of the acronym is the subtle distinction between Subjective and Objective. The former is individual, inconsistent between observers (unrepeatable), opinion. The latter is repeatable, observable, measurable, facts. The classification of patient reported as "subjective" simply isn't fair. Some of it is. Some of it isn't, and is in fact quite verifiable. Past medications, diagnoses, allergies, et cetera.
Clinician assessments are sometimes just as subjective. Terms like comfortable, or slight, or pleasant convey something of the physicians opinion of the overall appearance, but they aren't any less an opinion than a patient's statement of how they feel.
So let's forget SOAP and move to SHOAP. History is after all, just a collection of what happened in the past, be it subjective, or objective, or assessment or plan. How many times has physician put what you wrote down in your history as a problem or medication in your chart? How did that act make it any more or less objective? It didn't.
Keith
P.S. I came up with a new acronym for this style of reporting, but I think the debate about it would be far too confusing for those of us who have to cross the IT boundary.
- Reported -- This is what I was told.
- Established -- This is what I determined by observation or test.
- Summation -- This is how I sum it up
- Treatment -- and as a result, how the patient and I think he/she should be treated.
Tuesday, October 1, 2013
What do I want to know about Clinicians and Clinician Settings
Part of my first assignment for school, and so I get to write something about what I want to know. Cool! More sources for blog fodder. I'll start here, and then clean it up and submit it (since I've already been asked to share with classmates, I'll also share it here, I think it's a useful set of questions). I won't do this a lot (I don't want to scare away my instructors).
What do I want to know about clinicians and clinician settings?
I've got questions of my own that would help me answer that.
Where do you spend your time?
- How much of that is in direct contact with patients?
- How much of that is providing care via consultation with other professionals?
- How much of that is managing the care provided by other professionals treating patients?
- How much of that is in what I call administrivia? Stuff that you need to do but has more value to others than to yourself.
- How much of that is in managing your business? [Some of this could also fall under #4, save that you actually care about it].
- How much of that is in improving your own skills?
- How much of that is using technology?
- If you had unlimited time, where would you spend more?
- Where would you spend less time if you could?
- Where do you work? And what is your specialty?
- What kind of information systems do you use [note: a card file is an information system]? What of it uses computers?
- What is your technology footprint?
- How long have you been doing this?
What are your problems?
- What are the biggest problems that you have?
- What are the little annoyances that bug you?
- Complete this sentence: You know how the _____ always/sometimes/never _____? I really hate/love that!
- What won't ever change? Why? Is that good or bad?
What does this mean for my work going forward?
Answers to these questions could completely change my focus (but I doubt it), or redirect where I put emphasis (highly likely). It would certainly have an impact on the standards that I help develop that might become part of our national program. And I'm sure it will impact any products that I influence, directly or otherwise. The real answer is that I don't know what it means, other than knowing that it will mean something changes.
What the Government Shutdown Means for HealthIT Development
Non-essential US government operations are shut down as of last night. That has some impacts on us in the Health IT Standards development space:
For those concerned about the recently started Health Insurance Exchanges, I'm sure there will be some bobbles, but I've seen reports from several places including in HHS planning documents that indicate that Medicare and Medicaid related activities would continue.
- You won't be able to test your CCDA documents or your implementation of the Direct transport. TTT is down (the DNS name isn't even found right now).
- IHE testing supported by NIST will be offline (the servers are being shut down).
- The Certified Health IT Products List won't be updated. It will still function, but you won't see newly certified products after 9/27. Certifiers can still operate if they have local copies of test tools.
- Federal Employees engaged in standards development will not be on HL7 or IHE calls, or responding to e-mails. You may see SOME e-mails today ensuring an orderly shutdown, but that will be it until things are resolved.
- Contractors to the Federal government MAY be answering calls and/or handling e-mail, but will very likely be operating at reduced capacity. They won't get paid by the government until things are cleared up. As one person put it, we will be carried on overhead for the duration ... as long as it's short.
- The previous two mean that there will likely be some empty seats at the October IHE meetings, and could impact proposals from S&I Framework (Data Access Framework) to IHE. The private sector will just have to carry the load.
- Those two could also impact project scope statements and development of HL7 CQI Projects that were kick-[in-the-pants]-started last week in support of MU Stage 3 activities. Hopefully we'll get the scope statements submitted (the only immediately pending requirement) by Sunday.
- Federal Advisory Committee meetings will not be held, nor will any FACA workgroup meetings be held. (So, I have a little bit more time for my report back on principles for standards selection if you still want to give me your input.)
- Four people from ONC would remain working (my guess would be the top of the hierarchy: Jacob Rider [acting chief and CMO], Doug Fridsma [Chief Scientist], Judy Murphy [Deputy Coordinator], and Joy Pritts [Chief Privacy Officer]).
- S&I Framework Activities and calls will almost surely be canceled until the shutdown is over, but I've seen nothing official on that yet [this is now confirmed].
For those concerned about the recently started Health Insurance Exchanges, I'm sure there will be some bobbles, but I've seen reports from several places including in HHS planning documents that indicate that Medicare and Medicaid related activities would continue.
So, for those of us in the private sector, enjoy your vacation from Federally sponsored activities. For my friends in the public sector impacted by this mess, I'm sorry that I won't be hearing from you, and I do hope it gets fixed soon. We'll do our best to keep things going without you, and without making a mess of them while you aren't here to keep us in check (and that's not a tongue-in-cheek comment).
Subscribe to:
Posts (Atom)