This week I'm in Oakbrook, IL at IHE PCC meetings. This post is prompted by one of the discussions we were just having there.
What is the difference between a care plan and a treatment plan? It depends upon who you are talking to, and what your context is. The problem I have is that many clinical documents in use today use the phrases "plan", "treatment plan", "plan of treatment", "care plan", and "plan of care" to mean what LOINC describes as the "plan of treatment" (18776-5) section.
From another perspective, the plan of care is an overall document describing how a patient will be cared for, similar to what is found in the IHE PCC Patient Plan of Care Profile. From a nursing perspective, this describes how a patient will be cared for overall, rather than what specific treatments (interventions, medications or procedures) will be applied to cure their ailment. LOINC has another Document level code for "Treatment plan" (56447-6).
Many of the times that I've been engaged into similar discussions the approach that I've taken is that I don't care what you call it, so long as I know what "it" is.
The challenge here is that across different domains in healthcare, different people use different terms to describe "it". Domain 1 uses term A, and Domain 2 uses term B, but in Domain 1, term B means something else. It's all very confusing.
The lack of human readable definitions in some of the controlled terminology (e.g., LOINC and SNOMED), make it difficult to determine when you are using them correctly. Eventually, I hope vocabulary creators includes human readable definitions for some of this terminology. It's not needed for things like medications where chemical names and structures pretty clearly define boundaries. Socialized concepts need it though.
Another simple change would be to have some editorial consistency in how these terms are created. There's not reason to use "Treatment Plan" in one place and "Plan of Treatment" in another. I'm fine with having the two concepts (document and section), where I have problems is that they use different phrases.
P.S. OK, and now we are talking about complications and problems. Same problem, and like I said, it's complicated.
Monday, July 12, 2010
An Alternative Approach for how to use the NIEM
In Adopting the NIEM for Health Information Exchange Joel Massou talks about replacing the current set of standards that many of us have been working on over the last decade years with new XML content. While he makes many key points (e.g., concept naming and software development requirements), I disagree with the overall approach.
The key approach that I think is important from the NIEM is not the current set of data models, but rather the approaches used in harmonization. I'm told that the key here in the NIEM is to engage committed stakeholders and in the processes used to obtain consensus. Having seen how some of these processes played out in NHIN Direct, I think that NIEM may be on to something, but more work is clearly needed.
If you've read this blog before, you've seen me reference Glen Marshall's excellent article on the Standards Value Chain. The point is that it takes time (sometimes as longer than five years) to go from the development of a standard to release in a product. It all depends upon market demand. ONC has already created a demand for the CCD and CDA standards in the Interim Final Rule. Changing that would be a disaster at this stage of the game. Too many have already headed down the path because providers need products using these standards yesterday.
Changing standards in the middle of this process will take even more time. There should be an evolution in the standards along the lines that Joel suggests, rather than a revolution. In fact, this is an ideal time in HL7 to address this needed change. The Structured Documents Workgroup is presently working on the next release of CDA and on Green CDA, the ITS workgroup is reviewing several simpler ITS forms including hData and MicroITS, Clinical Decision Support is searching for models, and everybody is trying to simplify. An evolutionary path will be sustainable.
My father's imparted wisdom comes to mind again, this time, about trying to change horses in midstream, and the effects that it has on both schedules and quality of work.
The key approach that I think is important from the NIEM is not the current set of data models, but rather the approaches used in harmonization. I'm told that the key here in the NIEM is to engage committed stakeholders and in the processes used to obtain consensus. Having seen how some of these processes played out in NHIN Direct, I think that NIEM may be on to something, but more work is clearly needed.
If you've read this blog before, you've seen me reference Glen Marshall's excellent article on the Standards Value Chain. The point is that it takes time (sometimes as longer than five years) to go from the development of a standard to release in a product. It all depends upon market demand. ONC has already created a demand for the CCD and CDA standards in the Interim Final Rule. Changing that would be a disaster at this stage of the game. Too many have already headed down the path because providers need products using these standards yesterday.
Changing standards in the middle of this process will take even more time. There should be an evolution in the standards along the lines that Joel suggests, rather than a revolution. In fact, this is an ideal time in HL7 to address this needed change. The Structured Documents Workgroup is presently working on the next release of CDA and on Green CDA, the ITS workgroup is reviewing several simpler ITS forms including hData and MicroITS, Clinical Decision Support is searching for models, and everybody is trying to simplify. An evolutionary path will be sustainable.
My father's imparted wisdom comes to mind again, this time, about trying to change horses in midstream, and the effects that it has on both schedules and quality of work.
Sunday, July 11, 2010
What does HITECH mean to the average person?
What does HITECH mean to the average person? It means change, hopefully for the better, but most don't really know how and few are aware of how significant these changes will be (if I get any say). While I think we need to all be more educated patients, it isn't going to happen overnight.
This was highlighted to me over the weekend as I attended a large family gathering celebrating the 70th birthday of my brother-in-law. In my travels this summer I get to talk to a lot of different people, including many who work in healthcare. I have a large number of extended family and many friends who also work in the healthcare field. A lot of them know vaguely what I do for a living, more so now that it's gotten so much attention. The people at this party who had a clue about what I do increased 10-fold over a similar gathering five years ago.
As I listened to stories told around the party related to healthcare, I heard the same kinds of anecdotes that we are all familiar with. How simple solutions could have saved much anguish, or how complex it was to navigate through so many various systems.
Almost all of the story-tellers had no awareness about the standards used to exchange information, how healthcare IT works (or any IT for that matter). Few, even inside of the healthcare field, had any real understanding about the HITECH / ARRA laws and regulations that will affect them. A few had heard something about HIPAA because they've either seen (or been trained on if they work in healthcare) HIPAA privacy notices. Few had any real understanding of how our healthcare system works (including me).
With all of the heady attention that healthcare standards and healthcare IT has gotten in the media lately in this country, it was very good to listen to these friends and family. They remind me what is really important. It's not the standards, the system, or the healthcare IT, it is the people involved in providing and receiving healthcare; especially the latter.
My father once told me that the purpose of getting through high-school was to learn what you needed to do to live, and that the purpose of college was to learn what you needed to do to make a living. If you think back to what you learned in high-school, you probably learned how to do enough math to cook a meal, buy groceries, balance a checkbook, tip your waiter and pay your taxes. You learned enough history to know that politics is not fun. You learned how to type, or use a computer. And in grade school, you learned how to read and write.
But did you learn enough in high-school to evaluate a health-insurance program, or coordinate healthcare for your aging parents, or get access to your medical records, or keep track of your medical history? I know I didn't, nor did many of the people telling their healthcare horror stories this weekend. All of their experience had to come the hard way.
My advice for my colleagues in this field is to channel your grand-parents, your parents, and other family members and friends that you know. Remember their healthcare horror stories, and become advocates for them.
Remember also the nurse, technician, clerk, administrator and other staffer as well as the doctor who has to work with (or in some cases around) the IT systems in healthcare. For every doctor who goes near a computer, there are probably 10-20 more people behind him or her that keep things moving.
Part of the reason I’m on this trip across the country is to teach my children something about the country they live in. I need to remember also to teach them what they need to know about our system of healthcare.
This was highlighted to me over the weekend as I attended a large family gathering celebrating the 70th birthday of my brother-in-law. In my travels this summer I get to talk to a lot of different people, including many who work in healthcare. I have a large number of extended family and many friends who also work in the healthcare field. A lot of them know vaguely what I do for a living, more so now that it's gotten so much attention. The people at this party who had a clue about what I do increased 10-fold over a similar gathering five years ago.
As I listened to stories told around the party related to healthcare, I heard the same kinds of anecdotes that we are all familiar with. How simple solutions could have saved much anguish, or how complex it was to navigate through so many various systems.
Almost all of the story-tellers had no awareness about the standards used to exchange information, how healthcare IT works (or any IT for that matter). Few, even inside of the healthcare field, had any real understanding about the HITECH / ARRA laws and regulations that will affect them. A few had heard something about HIPAA because they've either seen (or been trained on if they work in healthcare) HIPAA privacy notices. Few had any real understanding of how our healthcare system works (including me).
With all of the heady attention that healthcare standards and healthcare IT has gotten in the media lately in this country, it was very good to listen to these friends and family. They remind me what is really important. It's not the standards, the system, or the healthcare IT, it is the people involved in providing and receiving healthcare; especially the latter.
My father once told me that the purpose of getting through high-school was to learn what you needed to do to live, and that the purpose of college was to learn what you needed to do to make a living. If you think back to what you learned in high-school, you probably learned how to do enough math to cook a meal, buy groceries, balance a checkbook, tip your waiter and pay your taxes. You learned enough history to know that politics is not fun. You learned how to type, or use a computer. And in grade school, you learned how to read and write.
But did you learn enough in high-school to evaluate a health-insurance program, or coordinate healthcare for your aging parents, or get access to your medical records, or keep track of your medical history? I know I didn't, nor did many of the people telling their healthcare horror stories this weekend. All of their experience had to come the hard way.
My advice for my colleagues in this field is to channel your grand-parents, your parents, and other family members and friends that you know. Remember their healthcare horror stories, and become advocates for them.
Remember also the nurse, technician, clerk, administrator and other staffer as well as the doctor who has to work with (or in some cases around) the IT systems in healthcare. For every doctor who goes near a computer, there are probably 10-20 more people behind him or her that keep things moving.
Part of the reason I’m on this trip across the country is to teach my children something about the country they live in. I need to remember also to teach them what they need to know about our system of healthcare.
Friday, July 9, 2010
Using OpenID
In developing the Templates Registry project, one of the problems we had to resolve was managing the identity of the various participants. We specified requirements to identify and authenticate users in the registry requirements project, and we also included requirements for password reset and identity related notifications. In actual development, I’m avoiding having to code for some of those elements by using a standard called OpenID. I have about four different OpenIDs at present that I can count including: http://motorcycleguy.blogspot.com/
OpenID is an HTTP-based standard for exchanging and verifying identity. Here’s how it works.
There are three main parties:
Getting all of this to work with open source is about a days’ worth of effort. You need about half a day to locate the right OpenID library (I used openid4java) and a good login user interface (I used the jQueryOpenIdPlugin which also requires jQuery). A couple of hours of reading the specifications, and a couple more playing around, and you have a workable login page. Having done it once, it will only take me an hour or two the next time around. I could have spent days on this problem alone, but because of standards, I don't have to.
Using OpenID I've completely eliminated the need to deal with:
OpenID is an HTTP-based standard for exchanging and verifying identity. Here’s how it works.
- The end user whose identity needs to be verified (me).
- The identity server who verifies the identity (blogspot.com).
- The identity consumer who needs to use the identity (my application).
- The identity consumer (my application) displays a login page allowing the end user to specify their OpenID URL (see link jQueryOpenIdPlugin below).
- The user (me) specifies a URL (http://motorcycleguy.blogspot.com/) that they control to the identity consumer.
- The identity consumer uses that URL to discover the identity server it needs to correspond with.
- The identity consumer passes an HTTP request to the identity server that includes a nonce and a return page.
- The identity server returns a user interface that allows the user to login.
- The user logs in.
- The identity server redirects the user to the return page with a few parameters indicating the success of the login request and the identity of the user (if successful).
Using OpenID I've completely eliminated the need to deal with:
- Identity Creation
- Password Management
Wednesday, July 7, 2010
Canadians are Certifiable too!
The following crossed my desk a couple of days ago. Canada went down the certification pathway some time ago. What is different here (I just spent five days in Canada), is that the certification path includes reuse of existing testing activity (e.g., IHE connectathons). What is similar is that in order to access this market, you will need to have certified product, and spend a good chunk of money (e.g., Around $25K (CAN) for a DIR to obtain the certification).
July 5, 2010 (Toronto, ON) – Canada Health Infoway (Infoway) has added diagnostic imaging and drug information systems to its pre-implementation Certification Services. Health information technology vendors can now receive certification for seven classes of technology.
Receiving the 'Infoway Certified' mark gives vendors of health information technology products an advantage in the marketplace by signalling to potential healthcare customers their commitment to pan-Canadian standards and industry best practices, and their leadership in contributing to interoperable health information for Canadians.
"When a vendor solution bears the 'Infoway Certified' mark, the buyer can have confidence the solution will meet the standards of interoperable health information technology in Canada," says Richard Alvarez, President and CEO of Canada Health Infoway. "It signals to the Health IT sector both nationally and internationally that the product meets pan-Canadian standards and best practices related to privacy, security and interoperability.”
Infoway is the only organization in Canada certifying health information technology systems against pan-Canadian electronic health record (EHR) standards. Having produced national interoperability standards and a technology framework for the sustainable development of an interoperable EHR system across Canada, Infoway is ideally positioned to ensure current and emerging products provide required privacy and security and can interoperate with all EHR systems being implemented throughout the country.
The seven pre-implementation certifications currently available include:
For more information, please see the Certification Services Backgrounder.
Infoway Certification Services expands to include Diagnostic Imaging, Drug Information Systems
'Infoway Certified' assures products meet pan-Canadian standardsJuly 5, 2010 (Toronto, ON) – Canada Health Infoway (Infoway) has added diagnostic imaging and drug information systems to its pre-implementation Certification Services. Health information technology vendors can now receive certification for seven classes of technology.
Receiving the 'Infoway Certified' mark gives vendors of health information technology products an advantage in the marketplace by signalling to potential healthcare customers their commitment to pan-Canadian standards and industry best practices, and their leadership in contributing to interoperable health information for Canadians.
"When a vendor solution bears the 'Infoway Certified' mark, the buyer can have confidence the solution will meet the standards of interoperable health information technology in Canada," says Richard Alvarez, President and CEO of Canada Health Infoway. "It signals to the Health IT sector both nationally and internationally that the product meets pan-Canadian standards and best practices related to privacy, security and interoperability.”
Infoway is the only organization in Canada certifying health information technology systems against pan-Canadian electronic health record (EHR) standards. Having produced national interoperability standards and a technology framework for the sustainable development of an interoperable EHR system across Canada, Infoway is ideally positioned to ensure current and emerging products provide required privacy and security and can interoperate with all EHR systems being implemented throughout the country.
The seven pre-implementation certifications currently available include:
- Diagnostic Imaging – New!
- Drug Information Systems – New!
- Consumer Health Platforms
- Consumer Health Applications
- Client Registries
- Provider Registries
- Immunization Registries
For more information, please see the Certification Services Backgrounder.
Tuesday, July 6, 2010
Stumping Around
I’m running for the Board of Directors of HL7. If you’d like to vote for me for the HL7 Board of Directors, click on the link to the right that says “Vote for Keith”. That will take you to a page where you can decide who you want to vote for as an HL7 member.
I have just one thing that I want to focus on as a member of the HL7 board, and that is to strengthen our connection to our customers.
Who are HL7’s customers? Are they the organizations that are members of HL7? Is it the individuals in those organizations who participate in the development of HL7 standards? Is it the vendors who deliver products using HL7 standards? Is it the engineers who create interfaces between products using our standards? Is it healthcare IT organizations looking for best practices for developing frameworks? Is it all of these?
In an HL7 implementation, there are different kinds of people who will be exposed to an HL7 standard in many different ways. At the very highest level, there is one person who is responsible for the budget that pays for use of the standard in the technology that solves their business problems. They may know the standard by name (often not). Next are the handful of enterprise architects and analysts who decide to use an HL7 standard to solve a particular problem. They will know its name, what it is intended to do, and likely how to use it. Following in their footsteps are the handfuls of developers who have to interact closely with the standard to implement it in a business solution. They will know its name, what it is supposed to do, and understand where it works, and where it needs to be worked around for their solution. After that there are potentially hundreds of doctors who use the system that implements the standard. They may be aware of the standard, but only if it happens to be named in some regulation or law, and even then, they might not. Finally, there are the thousands of patients whose healthcare will be impacted by it. They won’t even be aware that it is used in all but the rarest of cases. Who of these are our customers?
The patients and doctors who use applications built upon our work products or who benefit from those applications are not our customers, but they are the people who our customers serve. The person who approves the project isn’t really our customer either. He or she may approve the project, but the real users are elsewhere. Of the groups I enumerated previously, only the architects, analysts, and developers are “directly” impacted by the text that we write that appears in our standards. In our membership HL7 has many more of the architects designing these systems, and very few people who write the running code.
But the people who write the code are the customers we must reconnect to if HL7 is to be as successful as we would like to be. In order to be not just the best, but also the most WIDELY used healthcare standard, we must be the MOST EASILY implemented standard, and that also means the most easily understood. To get there, we need to worry about not just the engineering viewpoint (al la SAIF), but ALSO the ENGINEERS viewpoint.
What Nurses have taught me is that you must treat not only the disease, but also the patient. What I have learned from them, and from the RESTful crowd, and those who struggle to implement HL7 is that to develop a standard, you must understand not just what it must do, but also what the people who implement it must do.
If you feel as I do, please cast your vote for me as a member of the HL7 board this year.
I have just one thing that I want to focus on as a member of the HL7 board, and that is to strengthen our connection to our customers.
Who are HL7’s customers? Are they the organizations that are members of HL7? Is it the individuals in those organizations who participate in the development of HL7 standards? Is it the vendors who deliver products using HL7 standards? Is it the engineers who create interfaces between products using our standards? Is it healthcare IT organizations looking for best practices for developing frameworks? Is it all of these?
In an HL7 implementation, there are different kinds of people who will be exposed to an HL7 standard in many different ways. At the very highest level, there is one person who is responsible for the budget that pays for use of the standard in the technology that solves their business problems. They may know the standard by name (often not). Next are the handful of enterprise architects and analysts who decide to use an HL7 standard to solve a particular problem. They will know its name, what it is intended to do, and likely how to use it. Following in their footsteps are the handfuls of developers who have to interact closely with the standard to implement it in a business solution. They will know its name, what it is supposed to do, and understand where it works, and where it needs to be worked around for their solution. After that there are potentially hundreds of doctors who use the system that implements the standard. They may be aware of the standard, but only if it happens to be named in some regulation or law, and even then, they might not. Finally, there are the thousands of patients whose healthcare will be impacted by it. They won’t even be aware that it is used in all but the rarest of cases. Who of these are our customers?
The patients and doctors who use applications built upon our work products or who benefit from those applications are not our customers, but they are the people who our customers serve. The person who approves the project isn’t really our customer either. He or she may approve the project, but the real users are elsewhere. Of the groups I enumerated previously, only the architects, analysts, and developers are “directly” impacted by the text that we write that appears in our standards. In our membership HL7 has many more of the architects designing these systems, and very few people who write the running code.
But the people who write the code are the customers we must reconnect to if HL7 is to be as successful as we would like to be. In order to be not just the best, but also the most WIDELY used healthcare standard, we must be the MOST EASILY implemented standard, and that also means the most easily understood. To get there, we need to worry about not just the engineering viewpoint (al la SAIF), but ALSO the ENGINEERS viewpoint.
What Nurses have taught me is that you must treat not only the disease, but also the patient. What I have learned from them, and from the RESTful crowd, and those who struggle to implement HL7 is that to develop a standard, you must understand not just what it must do, but also what the people who implement it must do.
If you feel as I do, please cast your vote for me as a member of the HL7 board this year.
Thursday, July 1, 2010
IHE 2010 Educational Webinar Series
IHE Community,
IHE 2010 Educational Webinar Series Announces 15 New Webinars through
September 2010:
IHE has announced 15 new educational webinars for the 2010 Educational Webinar Series. View the featured webinars below or go online to see the full schedule and register in advance. The 2010 Educational Webinar will include presentations such as: IHE Domain presentations, Introduction to IHE, IHE Committee Collaboration Tools, and How to Participate in IHE Committees. Plus, the IHE 2011 N.A. Connectathon and the HIMSS11 Interoperability Showcase registration opens August 16 – September 30, 2010. Learn how to register for these events during the Registration Kick-Off webinars as listed below on August 12 & 17, 2010.
· IHE Domain Updates- During the month of July 2010
there will be a large number of Domain presentations in the IHE Educational
Webinar Series. Please visit the full schedule register for these specific educational sessions.
there will be a large number of Domain presentations in the IHE Educational
Webinar Series. Please visit the full schedule register for these specific educational sessions.
· IHE Committee Collaboration Tools- New Committee Member Webinar
Thursday, July 22, 2010 at 9:30-10:30am CST. Register Online
· Introduction to IHE- Integration the Healthcare Enterprise- New
& Interested Member Webinar
& Interested Member Webinar
Tuesday, August 3, 2010 at 9:30-10:30am CST. Register Online
· HIMSS11 Interoperability Showcase Registration Kick-off & Detailed Overview- New & Past Participant Webinar
· IHE 2011 N.A. Connectathon Registration Kick-off & Detailed Overview- New
& Past Participant Webinar
& Past Participant Webinar
· How to Participate in IHE Committees? New & Interested Member Webinar
Thursday, September 2, 2010 at 10:30-12:00pm CST. Register Online
Want to receive updates on the IHE 2010 Educational Webinar Series, email our team at secretary@ihe.net to be added to our mailing list.
Past IHE Educational Presentations Now Posted Online:
The most current IHE Webinar Series archives are now listed online here. All future webinars and archives will be made available on both http://www.interoperabiltyshowcase.org/ and http://www.ihe.net/. Visit the Interoperability Showcase website to upload audio recordings, PowerPoint slide decks and other informational materials. Click here to be directed to this page immediately.
Want to Learn More?
For more information, please visit our website or contact us directly at secretary@ihe.net.
Integrating the Healthcare Enterprise- Visit http://www.ihe.net/.
Subscribe to:
Posts (Atom)