IHE IT Infrastructure is defining an integration profile called Cross Enterprise Document Workflow (shortened to XDW). This is truly infrastructure. There is no clinical content, and the workflow management component is very thin on management. Really it provides tracking of the workflow state of various tasks, and provides for a mechanism to update state. Any associated clinical content that works with this profile would be developed by a clinical domain (e.g., radiology, cardiology, patient care coordination, labs, et cetera).
Each step in the workflow is described by a short set of metadata and the workflow also has a set of metadata. All of the steps (and their metadata) in the workflow are recorded in a single document.
We (PCC) spent a bit of time in IT Infrastructure today to outline some of the requirements for the step and workflow metadata, and how this could work with the existing XDS infrastructure without change. One of the key principles of this profile is that applications using it would manage workflows, rather than having them be enforced by a workflow management engine. It doesn't preclude the use of such an agent once we get into the specific clinical workflows, but it does provide a vastly simpler scope that makes the profile broadly useful.
My next step is to do a little investigation into existing standards for describing workflows and steps, to see if there are any good candidates to include in this profile for representation of the workflow.
Wednesday, February 9, 2011
Monday, February 7, 2011
If I were King of Canada
I was at a dinner sponsored by Canada Health Infoway tonight as the guest speaker. My topic was CDA: An International Perspective. There were no slides for this presentation, but there were a few screen captures from some Infoway Standards, as well as a few clips from this blog. One of the items I spoke on was documents vs. messages. Before I tell you more about this, I want to tell you a bit about some improvements recently made to the ISO 7 layer model. You see, we've realized that there are two more layers beyond the application layer in the ISO model, those are politics and religion. Layer 9 plays an important role in this discussion.
Several years ago, around 2001, I told an employer that I had been working in XML for 9 years. If you get the joke, you realize that a) XML became a standard in 1998, and b) I'd been working in SGML for 6 years before that. SGML has been a standard for about 25 years now. The issue of documents vs. messages has been discussed in SGML and other computational circles for nearly as long. It still hasn't been resolved because we have only just now identified layer 9, and are still working out how to relate to each other at that level, let alone interoperate.
The fundamental difference between a document and a message is that a document is persistent. I don't care how you send it. If you retrieve it and get back the same information every time, it is a document. When you look at the Ontario specifications for a Discharge summary, you might see a message, but if it doesn't return the same data every time, I'm a fool and so are they. And they weren't fools. To me, that makes it a document. In fact, they even call it a clinical document. You know, we have a standard for that in HL7.
What is interesting about this to me, is that Ontario already has quite a bit of infrastructure in place to store large blobs of data. In fact, Canada has, to the best of my understanding, selected XDS-I for dealing with imaging exchange. So, if you want to store, query and retrieve chuncks of unchanging data, what's a good way to do that? Uhm, XDS of course.
But Canada has already invested quite a bit of development in HL7 Version 3 messaging specifications to exchange documents. It must have seemed like a good idea at the time. While I don't happen to have any off the shelf Version 3 implementations of this technology, if I wanted to build it today I could do so quite easily. Here is how:
Standards are like potato chips (you can never have just one). But they also provide solution that would let me use off-the-shelf, standards based software, so I don't have to reinvent the wheel. And that would let me leverage an existing infrastructure that used different standards.
Ah, but I am not the King of Canada, I'm not in charge, and I don't know who is, and finally, it's not my technology investment. But if you happen to live in Ontario, it is yours. Think about it, and not just for discharge summaries, that was just an example to make a point. There's a lot more to clincial documents than discharge summaries.
P.S. I can pick on Canada a little, because I live in a land that has much richer targets that this little issue, and the Lord knows, my Canadian friends certainly take advantage of that fact.
###
Dennis Giokas, CTO of Infoway, responded via e-mail asking that I post this as a response since it is to large to fit into comments. His response appears below.
Keith, I am not King of Canada either (is there an opening that I’m not aware of?) but I do lead the standards efforts at Canada Health Infoway and would like to comment on your blog.
You indicated in your blog posting, “The fundamental difference between a document and a message is that a document is persistent.” Messages can actually persist in any number of ways. The transaction they convey is often persisted in a database. I can reconstruct the results of those transactions via numerous mechanisms such as a transaction log.
A very key aspect of the agenda in Canada for the interoperable EHR are complete records of key clinical information, patient centric, and longitudinal. Snapshots at a point in time in a document such as a CCD will not support that very important business requirement effectively.
Let’s for example consider medication reconciliation. I would assert using a message on medication dispense to update a reconciled medication list is much more effective than a document. That resulting healthcare event’s information is persisted as discrete, structured and coded data as a record in a database. In addition, the system can manage and invoke the resulting behaviours behind the transaction. Whether a document or message, the resulting behaviours on the exchange are just as important as the information exchanged. With messages, the two systems can “have a conversation” to ensure the transaction is properly handled, especially if there are exceptions to be handled, corrections or retractions for the dispense. Messages have important transactional semantics that can be enhance the quality of data and thus reliability and accuracy of information in the interoperable electronic health record (EHR).
On a message-based query of medications I will always get the same information back every time. So getting the right information back is not the issue. In addition, there are significant advantages over documents in this scenario because the system that persists that information can be easily queried for lots of other information, such as medications that are no longer current. The system or user does not have to parse a series of documents to assemble that information over time.
To illustrate my point, would our banks use documents to post a loan or credit card payment? No. Would they use a document at the ATM on credits and debits from my checking account? No. Can they get an accurate view of all transactions and compute my balance after each of those transactions? Yes. So why would the healthcare industry strive to be different and feel as though it can be run efficiently and effectively using documents where message-based transactions are most appropriate?
Don’t get me wrong, there are things such as discharge summaries, e-referrals, and clinical notes which should be documents. But types of clinical information that need processing and reconciliation such as medications, allergies, problem lists, condition lists, and lab results should always be written using message-based transactions. This is especially true on the write of data. The write into a repository of discrete, structured, coded data is key feature of our approach.
In addition, this approach also has the benefit of being very flexible on the read side of the equation. I can support just functional interoperability on the read. One can query for the current medication list and get that back in many forms, and the same every time. It can be in a final form, such as PDF. A form that has flexibility for display, such as HTML. I can also do the read and achieve semantic interoperability and return a CDA document or a message such that the receiving system has ultimate control over the data for processing purposes. I can then process the medications list in the receiving system and look for issues of compliance or contraindications and alert the clinician. There are numerous options for read and use of the data when I put a lot of rigor on the write/exchange of clinical information.
Dr. John Halamka recently posted a blog on some aspects of this issue. http://geekdoctor.blogspot.com/2011/02/safety-of-hit-assisted-care.html CCD does have significant shortcoming and implications on patient safety. He says:
While it may be true an infrastructure could be up and running in six weeks, one cannot ignore the most critical aspect of interoperability over that infrastructure: the information model (e.g. payload over that infrastructure) and behavioural model on that information at both ends of the wire. That is the tough part and the one that takes time to define and time for the vendors to adopt and implement. Then one has to deploy it, test it, and implement a change management and training program for the end users.
Don’t get me wrong, we support and embrace CDA and XDS where it is appropriate. But it is not the solution to every health information exchange use case.
Several years ago, around 2001, I told an employer that I had been working in XML for 9 years. If you get the joke, you realize that a) XML became a standard in 1998, and b) I'd been working in SGML for 6 years before that. SGML has been a standard for about 25 years now. The issue of documents vs. messages has been discussed in SGML and other computational circles for nearly as long. It still hasn't been resolved because we have only just now identified layer 9, and are still working out how to relate to each other at that level, let alone interoperate.
The fundamental difference between a document and a message is that a document is persistent. I don't care how you send it. If you retrieve it and get back the same information every time, it is a document. When you look at the Ontario specifications for a Discharge summary, you might see a message, but if it doesn't return the same data every time, I'm a fool and so are they. And they weren't fools. To me, that makes it a document. In fact, they even call it a clinical document. You know, we have a standard for that in HL7.
What is interesting about this to me, is that Ontario already has quite a bit of infrastructure in place to store large blobs of data. In fact, Canada has, to the best of my understanding, selected XDS-I for dealing with imaging exchange. So, if you want to store, query and retrieve chuncks of unchanging data, what's a good way to do that? Uhm, XDS of course.
But Canada has already invested quite a bit of development in HL7 Version 3 messaging specifications to exchange documents. It must have seemed like a good idea at the time. While I don't happen to have any off the shelf Version 3 implementations of this technology, if I wanted to build it today I could do so quite easily. Here is how:
- I'd start with an XDS Registry and Repository. I happen to know where you can buy these and also know of a number of high quality open source implementations.
- Next, I'd configure the Affinity domain to deal with appropriate code systems for Ontario.
- But I'd also add configurations for some of the other query parameters that appear in the Ontario specification: Intended Recipient (already in XDS Metadata), Health Condition, Indication and Event Categories (which I would support using tghe XDS Event Code metadata). [Most good XDS implementors can query on metadata other than what's required by the profile -- it's a minimum requirement, not a closed specification]
- Then I'd find an interface technology that would let me map the V3 query into the appropriate XDS query, and away I'd go. I know where those can be purchased as well, and again, there are a number of good open source implementations.
- Of course, I'd also have to map the message storing the document to a provide and register transaction, but that is relatively simply. It's the reverse of what I did in step 3.
- Once I was done, and especially if it was me writing the code, I'd probably rewrite these as XSLT transformations and layer them into the services supported by the XDS Registry I was using. That way I could adjust to minor (or even major) changes to the specifications pretty quickly and using a language that truly is cross platform and not beholden to any single vendor.
Standards are like potato chips (you can never have just one). But they also provide solution that would let me use off-the-shelf, standards based software, so I don't have to reinvent the wheel. And that would let me leverage an existing infrastructure that used different standards.
Ah, but I am not the King of Canada, I'm not in charge, and I don't know who is, and finally, it's not my technology investment. But if you happen to live in Ontario, it is yours. Think about it, and not just for discharge summaries, that was just an example to make a point. There's a lot more to clincial documents than discharge summaries.
P.S. I can pick on Canada a little, because I live in a land that has much richer targets that this little issue, and the Lord knows, my Canadian friends certainly take advantage of that fact.
Dennis Giokas, CTO of Infoway, responded via e-mail asking that I post this as a response since it is to large to fit into comments. His response appears below.
Keith, I am not King of Canada either (is there an opening that I’m not aware of?) but I do lead the standards efforts at Canada Health Infoway and would like to comment on your blog.
You indicated in your blog posting, “The fundamental difference between a document and a message is that a document is persistent.” Messages can actually persist in any number of ways. The transaction they convey is often persisted in a database. I can reconstruct the results of those transactions via numerous mechanisms such as a transaction log.
A very key aspect of the agenda in Canada for the interoperable EHR are complete records of key clinical information, patient centric, and longitudinal. Snapshots at a point in time in a document such as a CCD will not support that very important business requirement effectively.
Let’s for example consider medication reconciliation. I would assert using a message on medication dispense to update a reconciled medication list is much more effective than a document. That resulting healthcare event’s information is persisted as discrete, structured and coded data as a record in a database. In addition, the system can manage and invoke the resulting behaviours behind the transaction. Whether a document or message, the resulting behaviours on the exchange are just as important as the information exchanged. With messages, the two systems can “have a conversation” to ensure the transaction is properly handled, especially if there are exceptions to be handled, corrections or retractions for the dispense. Messages have important transactional semantics that can be enhance the quality of data and thus reliability and accuracy of information in the interoperable electronic health record (EHR).
On a message-based query of medications I will always get the same information back every time. So getting the right information back is not the issue. In addition, there are significant advantages over documents in this scenario because the system that persists that information can be easily queried for lots of other information, such as medications that are no longer current. The system or user does not have to parse a series of documents to assemble that information over time.
To illustrate my point, would our banks use documents to post a loan or credit card payment? No. Would they use a document at the ATM on credits and debits from my checking account? No. Can they get an accurate view of all transactions and compute my balance after each of those transactions? Yes. So why would the healthcare industry strive to be different and feel as though it can be run efficiently and effectively using documents where message-based transactions are most appropriate?
Don’t get me wrong, there are things such as discharge summaries, e-referrals, and clinical notes which should be documents. But types of clinical information that need processing and reconciliation such as medications, allergies, problem lists, condition lists, and lab results should always be written using message-based transactions. This is especially true on the write of data. The write into a repository of discrete, structured, coded data is key feature of our approach.
In addition, this approach also has the benefit of being very flexible on the read side of the equation. I can support just functional interoperability on the read. One can query for the current medication list and get that back in many forms, and the same every time. It can be in a final form, such as PDF. A form that has flexibility for display, such as HTML. I can also do the read and achieve semantic interoperability and return a CDA document or a message such that the receiving system has ultimate control over the data for processing purposes. I can then process the medications list in the receiving system and look for issues of compliance or contraindications and alert the clinician. There are numerous options for read and use of the data when I put a lot of rigor on the write/exchange of clinical information.
Dr. John Halamka recently posted a blog on some aspects of this issue. http://geekdoctor.blogspot.com/2011/02/safety-of-hit-assisted-care.html CCD does have significant shortcoming and implications on patient safety. He says:
Safety is improved by ensuring each provider has a complete problem list, medication list, allergy list, and recent results. Such a document is useful for medication reconciliation, drug/drug and drug/allergy decision support, and managing the entire patient by understanding all active problems.I don’t think we can simplify healthcare interoperability and say all can be solved with CDA and XDS, nor with messages. I would encourage architects to look at all of the requirements at hand and identify the most appropriate solution approach.
However, summaries exchanged at a point in time are just that - a summary or abstract of the lifetime record that is accurate at a point in time. They do not provide access to the complete record such as inpatient notes, operative notes, history and physicals, and historical data such as discontinued medications or resolved problems. Many clinicians believe that a patient summary at a point in time is good enough for transitions of care, so the risk introduced by abstracting the record into just the salient handoff details may be minimal.
…….
Summary data is an abstract captured at a moment in time. Data corrections/updates are not sent. Thus, data about the patient becomes incomplete and stale over time. However, for the purpose intended, ensuring a transition of care is safe, a point in time summary may be good enough.
While it may be true an infrastructure could be up and running in six weeks, one cannot ignore the most critical aspect of interoperability over that infrastructure: the information model (e.g. payload over that infrastructure) and behavioural model on that information at both ends of the wire. That is the tough part and the one that takes time to define and time for the vendors to adopt and implement. Then one has to deploy it, test it, and implement a change management and training program for the end users.
Don’t get me wrong, we support and embrace CDA and XDS where it is appropriate. But it is not the solution to every health information exchange use case.
IHE Events at HIMSS11 in Orlando
There are a number of IHE related interoperability events going on at HIMSS11 this year besides the Showcase. This is a brief list of some of the more interesting ones:
Sunday, February 20, 8:45 AM - 9:45 AM
Clearing the Way Conceptually for Effective Secondary Use of Clinical Data Sunday, February 20, 3:15 PM - 4:15 PM
IHE: An Interoperability Process for Enabling the Utilization of Data Across Domains
Wednesday, February 23, 9:45 AM - 10:45 AM
Experiences Implementing IHE Profiles in the Real World
Wednesday, February 23, 1:00 PM - 2:00 PM
IHE Profiles Supporting Meaningful Use
I'll be one of the people facilitating this workshop...
Sunday, February 20, 8:30 AM - 12:30 PM
Fitting the Puzzle Pieces Together to Achieve Interoperability: A Hands-on Interoperability Workshop
And this, while not IHE related, is another event I'll be involved it. It is a short presentation on how to use various tools to use metrics with your blog that I'll also be giving.
Tuesday, February 22, 5:00 PM - 5:30 PM
Friday, February 4, 2011
Use Cases for Transfers of Care
A lot of this post is based on work that IHE did in 2005 on the IHE Cross Enterprise Document Sharing of Medical Summaries (XDS-MS) Profile. A key contributor to that profile was Dr. Dan Russler, who joined with me in the role of being the first technical co-chairs of that domain. Dan had been an active member of HL7 for a number of years before participating in IHE. In HL7 he co-chaired the Patient Care Workgroup for several years.
The XDS-MS profile grew out of frustration trying to share summary information for a number of different kinds of care transitions. Dan began by classifying transfers of care into three types: Collaborative, Episodic (What I think of as Temporary), and Permanent. This picture comes from the IHE PCC Technical Framework Volume I and places the three types on two axes.
The two axes address whether the problems being addressed are broad (the whole patient) or focused on a specific topic (a condition or medical specialty), and whether the intended audience for the information is also focused (usually among the responsible care provider, the consulting physician and the patient), or which may involve several others, usually around a particular episode of care.
The Transfers of Care initiative is focused on the Collaborative and Episodic transfers (the "Green Button" proposed project was focused on Permanent Transfers). The easy way to think about Collaborative and Episodic transfers is to look at specific use cases for each.
Collaborative transfers most often occur during referrals to specialists for certain kinds of care. Another common case for collaborative transfer is dealing with perinatal care. In these cases, the patient's initial state of health is exchanged, along with some history about why the collaboration is needed. This often includes a narrative history of the present illness or condition (pregnancy is not an illness). During the collaboration, care provided by the specialist may necessitate changes in care given by other physicians engaged in patient care, especially when the collaboration is not short-term. Short-term collaborations fall into two main categories: Collaboration for diagnosis and collaboration for treatment. For diagnosis, the case is often pretty straightforward. An examination and some tests are performed, and the resulting diagnosis and recommended treatment(s) are communicated back to the referring provider, who then "takes back" responsibility for the patient's care, and initiates the recommendations in collaboration with the patient. For treatment, this can be short term, e.g., getting through a simple surgical procedure to correct the problem, again, after which the referring provider handles the follow-up and recovery. Longer term "collaborations" usually wind up affecting the patient in multiple ways and get broader in scope, so they usually would be classified as episodic.
Episodic transfers are most often exemplified by hospitalization or emergency care, after which the primary care physician handles follow-up and recovery. But not all episodic transfers are initiated by a hospitalization or emergency department visit. Some are long term activities that involve multiple parties. For example, treatment for cancer would be an episodic transfer, even if it involved no inpatient stay.
For the ToC project, I would recommend the following sets of use cases:
For emergency care, again, they could use the HITSP C28 for the Emergency Department report and the C48 for the Discharge Summary. For the heads up referral to the ED, a slight variation on C48 exists in the IHE EDR profile, and I believe the necessary sections are already in C83.
The XDS-MS profile grew out of frustration trying to share summary information for a number of different kinds of care transitions. Dan began by classifying transfers of care into three types: Collaborative, Episodic (What I think of as Temporary), and Permanent. This picture comes from the IHE PCC Technical Framework Volume I and places the three types on two axes.
The two axes address whether the problems being addressed are broad (the whole patient) or focused on a specific topic (a condition or medical specialty), and whether the intended audience for the information is also focused (usually among the responsible care provider, the consulting physician and the patient), or which may involve several others, usually around a particular episode of care.
The Transfers of Care initiative is focused on the Collaborative and Episodic transfers (the "Green Button" proposed project was focused on Permanent Transfers). The easy way to think about Collaborative and Episodic transfers is to look at specific use cases for each.
Collaborative transfers most often occur during referrals to specialists for certain kinds of care. Another common case for collaborative transfer is dealing with perinatal care. In these cases, the patient's initial state of health is exchanged, along with some history about why the collaboration is needed. This often includes a narrative history of the present illness or condition (pregnancy is not an illness). During the collaboration, care provided by the specialist may necessitate changes in care given by other physicians engaged in patient care, especially when the collaboration is not short-term. Short-term collaborations fall into two main categories: Collaboration for diagnosis and collaboration for treatment. For diagnosis, the case is often pretty straightforward. An examination and some tests are performed, and the resulting diagnosis and recommended treatment(s) are communicated back to the referring provider, who then "takes back" responsibility for the patient's care, and initiates the recommendations in collaboration with the patient. For treatment, this can be short term, e.g., getting through a simple surgical procedure to correct the problem, again, after which the referring provider handles the follow-up and recovery. Longer term "collaborations" usually wind up affecting the patient in multiple ways and get broader in scope, so they usually would be classified as episodic.
Episodic transfers are most often exemplified by hospitalization or emergency care, after which the primary care physician handles follow-up and recovery. But not all episodic transfers are initiated by a hospitalization or emergency department visit. Some are long term activities that involve multiple parties. For example, treatment for cancer would be an episodic transfer, even if it involved no inpatient stay.
For the ToC project, I would recommend the following sets of use cases:
- Referral to a specialist for Diagnosis
- Referral to a specialist for Simple Treatment
- Referral to a specialist for Complex Treatment
- Heads up Referral to the ED
- Emergency Department Care requiring follow-up (with and without an accompanying inpatient stay)
- Hospitalization for an Episode of Care
For emergency care, again, they could use the HITSP C28 for the Emergency Department report and the C48 for the Discharge Summary. For the heads up referral to the ED, a slight variation on C48 exists in the IHE EDR profile, and I believe the necessary sections are already in C83.
Who should replace Dr. Blumenthal as ONC Head?
Create your free online surveys with SurveyMonkey, the world's leading questionnaire tool.
* I really will get back to that other post... The results are in, and it's close enough to the end of the month to report them. According to the survey, John Halamka is the overwhelming leader. I didn't vote for myself, and I'm not qualified for the job, but many of you did. Thanks to all of you who did, but even if it ever did happen, I think I'd take a pass. There were a total of 57 responses. Details are below.
500 and Counting
According to Blogger, this is my 500th post. I started this blog in June of 2008, mostly as a way to record my thoughts in a persistent way (I call persistent messages "documents") so that I could refer people to them later. It's been very effective for that purpose and since then many other things have happened that augment its utility. The top ten posts have more than 1000 views each and are still getting at least 30 views each month.
I wrote 25 posts in that first year. That first month I wrote a post on Clinical Decision Support that taught me the value of a simple title name that was easily searchable. It's still in the top 10 (position ) at over 1300 hits, and gets on average about 30 hits a month. Of course another post with a simple name was the Meaningful Use Standards Summary. That was a block buster post at the top of the chart that's gotten more than 5000 hits in 6 months, and still gets more than 300 views a month. Robin's Meaningful Use Posters at postion 8 is another good resource. The last post in this catagory is Laboratory Orders, in position 10. While the information in that is a little dated, the work that Clem McDonald did on Common lab orders from LOINC is something everyone should be aware of.
Robin is one of several winners of the Ad Hoc Harley award that I give out five times (more or less) a year. Her award page also includes more posters and resources, and so it is in position 5. The Ad Hoc Harley award winner pages as a general theme have also been a big hit, getting over 4000 hits since I started it in January of last year with the award to Andrew McCaffrey of NIST.
Another useful page is the Open Source Standards page, which was another blockbuster at #2. It's received over 2000 hits in less than a year. That's got an interesting trend line. It had more than 300 hits its first month, fell off to 150, and has then climbed back up to over 350 in December. I've never seen that happen before. By the way, if you have any updates to that page, please let me know. Another resource page is the starting post on the Where in the World is XDS map, at postition 9 and still more 50 hits a month. The map has been around for a little more than a year, and has gotten more than 100,000 hits on Google.
With the dawn of Meaningful Use, a lot of implementors had questions about the HITSP C32 specification, and moving from version 2.3 to 2.5. That page is in position 3, and gets more than 250 hits a month, although it finally seems to be slowing down some. I'm hoping that's because most people who would have benefited from it have implemented it by now.
I've been greatly involved in the development of Templated CDA, and one of my posts on that topic remains in position 4.
Last, but not least, was the post I wrote that was the reason for starting this blog: If I had a Hammer. I've been using that post as a hammer for 2+ years, and it finally seems to have set in. That post has had more readership in most of the the months that followed it than it got in the early days of this blog, and remains in the top 10 at position number 7.
I now return you to your regular blog stream with post 501 on the topic I promised yesterday.
I wrote 25 posts in that first year. That first month I wrote a post on Clinical Decision Support that taught me the value of a simple title name that was easily searchable. It's still in the top 10 (position ) at over 1300 hits, and gets on average about 30 hits a month. Of course another post with a simple name was the Meaningful Use Standards Summary. That was a block buster post at the top of the chart that's gotten more than 5000 hits in 6 months, and still gets more than 300 views a month. Robin's Meaningful Use Posters at postion 8 is another good resource. The last post in this catagory is Laboratory Orders, in position 10. While the information in that is a little dated, the work that Clem McDonald did on Common lab orders from LOINC is something everyone should be aware of.
Robin is one of several winners of the Ad Hoc Harley award that I give out five times (more or less) a year. Her award page also includes more posters and resources, and so it is in position 5. The Ad Hoc Harley award winner pages as a general theme have also been a big hit, getting over 4000 hits since I started it in January of last year with the award to Andrew McCaffrey of NIST.
Another useful page is the Open Source Standards page, which was another blockbuster at #2. It's received over 2000 hits in less than a year. That's got an interesting trend line. It had more than 300 hits its first month, fell off to 150, and has then climbed back up to over 350 in December. I've never seen that happen before. By the way, if you have any updates to that page, please let me know. Another resource page is the starting post on the Where in the World is XDS map, at postition 9 and still more 50 hits a month. The map has been around for a little more than a year, and has gotten more than 100,000 hits on Google.
With the dawn of Meaningful Use, a lot of implementors had questions about the HITSP C32 specification, and moving from version 2.3 to 2.5. That page is in position 3, and gets more than 250 hits a month, although it finally seems to be slowing down some. I'm hoping that's because most people who would have benefited from it have implemented it by now.
I've been greatly involved in the development of Templated CDA, and one of my posts on that topic remains in position 4.
Last, but not least, was the post I wrote that was the reason for starting this blog: If I had a Hammer. I've been using that post as a hammer for 2+ years, and it finally seems to have set in. That post has had more readership in most of the the months that followed it than it got in the early days of this blog, and remains in the top 10 at position number 7.
I now return you to your regular blog stream with post 501 on the topic I promised yesterday.
Thursday, February 3, 2011
Transfers of Care
I was on the ONC S&I Framework Transfers of Care Use case workgroup call yesterday. We got an outline of the project, went over rules of the road, and went into a little detail about the scope of the subgroup. It is tasked to create use cases for transfers of care.
To avoid Deja Vu All Over Again, I thought I'd share where we have been on this topic over the past decade and more.
In 1998, HL7's Claims Attachments Workgroup started development of a number specifications for a couple of different types of clinical reports, one of which included the Discharge Summary. That specification identified the following key data elements:
In 2005, shortly after CDA Release 2 was completed, I edited the Care Record Summary (CRS) Release 1.0. That supported three main care transition notes: The Summarization of Episode and its two main subtypes: Discharge Summarization Note and Transfer Summarization Note. That work was based on the prior claims Attachments efforts and the Vancouver Island Health Authorities eMedical Summary specification which they kindly made available to HL7.
That specification added the following data elements to the Discharge Summary:
All hell broke lose between ASTM and HL7 over the CRS work in late 2006, which eventually led to the start of the CCD work in December of 2006 collaboratively between ASTM and HL7.
Shortly after that, IHE began work on XPHR which was a profile of CCD. HITSP began work on the "Registration and Medication Summary" which was originally based on the XPHR work, but was dropped back to be based upon CCD after several protests from CCR promoters. This became the first version of the HITSP C32.
CCD used much of the work that had already been done in CRS and was adopted by HL7 in January of 2007. XPHR was completed in August of 2007 based on the final CCD work, and XDS-MS underwent a similar change over that took about two years to get all the bugs out of.
HL7 and Health Story (formerly CDA for Common Document Types) began work on a number of document specifications focused on transcription. These included the History and Physical Note, which took the general header constraints first established in CRS and made them a template which could be applied to any document. They also completed work on a Consultation Note.
In 2008, HITSP was given the Consultations and Transfers of Care Use case, for which those specifications were adopted. In that same year, the Care Management and Health Records TC worked on harmonizing across the HITSP specifications. HITSP had adoped two other IHE profiles EDES (C28), and XDS-MS (in C38 and C48) but in ways that meant a medications section in C28, C32, C38, C48 were not necessarily compatible with each other. That resulted in the creation of C83 (Sections and Entries) and C80.
In 2009 we went a bit crazy in HITSP, replacing our efforts mid-year with a crash priority task assignment by ONC to simplify our specifications even further. That resulted in more changes to C83 and C80, the creation of the HITSP Data Elements specification (C154), and changes to the various CDA specifications that relied upon them, including C28, C32, C48, C78, C84, C148, C161 and C162.
HL7 and Health Story continued their work in developing specifications for operative note and procedure note, and HITSP also updated C83 and Capability 119 (Exchange Docuemnts) to support a templated CDA approach.
The templated CDA approach supported by the current version of C83 enables not just transfers of care, but also establishes a set of "data molecules" that can be exchanged in different kinds of clinical documents. RTI and IBM used these capabilities when they created a specification for assessments based on the CMS CARE data set, proving that this approach can rapidly support implementation guide development.
I'm exited about the possibilities that successful completion of the Transfers of Care project would enable, but also concerned about potential changes in direction from the current approach. There's a lot of existing work that has been done in this space. Some of it is has been used for more than decade. Some of it is just as recent as January 2010, when HITSP harminized C83 and C80 with meaningful use vocabulary requirements, enabling C32 Version 2.5 to be selected in the Standards and Certification Regulation.
It's a tightrope walk almost as challenging as the Consolidation Project. The desire to make it better than it is competes with the desire to avoid breaking changes. We will need to carefully balance the various tensions to be successful. These projects are on much to short a timeline to enable "rip and replace" thinking, although there are some I would expect who will want to do just that.
Over the past seven years time I've been editor for more than a dozen implementation guides, and co-chaired three different committees in three different organizations overseeing this work. Tommorow I'll outline some of my thoughts on Transfers of Care use cases based on the work that I've seen in this area.
Well, I have my work cut out for me, I hope to see you there.
To avoid Deja Vu All Over Again, I thought I'd share where we have been on this topic over the past decade and more.
In 1998, HL7's Claims Attachments Workgroup started development of a number specifications for a couple of different types of clinical reports, one of which included the Discharge Summary. That specification identified the following key data elements:
- Admit and Discharge Date
- Admission and Discharge Diagnosis
- Course
- Consultations
- Disposition
- Procedures and Studies
- Physical Exam
- Discharge Medications
- Discharge History
- Followup
- Treatment Plan
In 2005, shortly after CDA Release 2 was completed, I edited the Care Record Summary (CRS) Release 1.0. That supported three main care transition notes: The Summarization of Episode and its two main subtypes: Discharge Summarization Note and Transfer Summarization Note. That work was based on the prior claims Attachments efforts and the Vancouver Island Health Authorities eMedical Summary specification which they kindly made available to HL7.
That specification added the following data elements to the Discharge Summary:
- Chief Complaint/Reason for Visit
- History of Present Illness
- Problem List
- Medications Administered and Medications on Admission (to meet med Reconciliation requirements)
- History of Allergies
- Review of Systems
- Vital Signs
- Advance Directives
- Reason for Referral
- Chief Complaint/Reason for Visit
- History of Present Illness
- Problem List
- Medication List
- Allergy List
- Sugical History
- Immunizations
- Family History
- Social History
- Review of Systems
- Vital Signs and Physical Exam
- Advance Directives
All hell broke lose between ASTM and HL7 over the CRS work in late 2006, which eventually led to the start of the CCD work in December of 2006 collaboratively between ASTM and HL7.
Shortly after that, IHE began work on XPHR which was a profile of CCD. HITSP began work on the "Registration and Medication Summary" which was originally based on the XPHR work, but was dropped back to be based upon CCD after several protests from CCR promoters. This became the first version of the HITSP C32.
CCD used much of the work that had already been done in CRS and was adopted by HL7 in January of 2007. XPHR was completed in August of 2007 based on the final CCD work, and XDS-MS underwent a similar change over that took about two years to get all the bugs out of.
HL7 and Health Story (formerly CDA for Common Document Types) began work on a number of document specifications focused on transcription. These included the History and Physical Note, which took the general header constraints first established in CRS and made them a template which could be applied to any document. They also completed work on a Consultation Note.
In 2008, HITSP was given the Consultations and Transfers of Care Use case, for which those specifications were adopted. In that same year, the Care Management and Health Records TC worked on harmonizing across the HITSP specifications. HITSP had adoped two other IHE profiles EDES (C28), and XDS-MS (in C38 and C48) but in ways that meant a medications section in C28, C32, C38, C48 were not necessarily compatible with each other. That resulted in the creation of C83 (Sections and Entries) and C80.
In 2009 we went a bit crazy in HITSP, replacing our efforts mid-year with a crash priority task assignment by ONC to simplify our specifications even further. That resulted in more changes to C83 and C80, the creation of the HITSP Data Elements specification (C154), and changes to the various CDA specifications that relied upon them, including C28, C32, C48, C78, C84, C148, C161 and C162.
HL7 and Health Story continued their work in developing specifications for operative note and procedure note, and HITSP also updated C83 and Capability 119 (Exchange Docuemnts) to support a templated CDA approach.
The templated CDA approach supported by the current version of C83 enables not just transfers of care, but also establishes a set of "data molecules" that can be exchanged in different kinds of clinical documents. RTI and IBM used these capabilities when they created a specification for assessments based on the CMS CARE data set, proving that this approach can rapidly support implementation guide development.
I'm exited about the possibilities that successful completion of the Transfers of Care project would enable, but also concerned about potential changes in direction from the current approach. There's a lot of existing work that has been done in this space. Some of it is has been used for more than decade. Some of it is just as recent as January 2010, when HITSP harminized C83 and C80 with meaningful use vocabulary requirements, enabling C32 Version 2.5 to be selected in the Standards and Certification Regulation.
It's a tightrope walk almost as challenging as the Consolidation Project. The desire to make it better than it is competes with the desire to avoid breaking changes. We will need to carefully balance the various tensions to be successful. These projects are on much to short a timeline to enable "rip and replace" thinking, although there are some I would expect who will want to do just that.
Over the past seven years time I've been editor for more than a dozen implementation guides, and co-chaired three different committees in three different organizations overseeing this work. Tommorow I'll outline some of my thoughts on Transfers of Care use cases based on the work that I've seen in this area.
Well, I have my work cut out for me, I hope to see you there.
Subscribe to:
Posts (Atom)