I've had a lot of discussion with folks about models recently. as it relates to HQMF, as it relates to HIE, and as it relates to EHR products. The question that almost always comes up is "What is the best model?", and/or "What model do you recommend?" Unfortunately, my normal answer to this question of "It depends..." fails to satisfy many listeners. I suspect all to many are simply looking for an easy answer. I thought I would try again, but differently.
The essentials of your model, whatever it is, are going to be something that everyone can agree on. In developing a model for medical summaries, the top three and top five items are pretty easy to list out: Problems, Medications and Allergies are the top three. Few would argue that. The next two are labs, and immunizations. After that it gets a bit fuzzy. For the top three, we know you need the name of each thing, and likely a code to go with it. Dates are also important. Anything beyond that is gravy. We can all pretty much agree on these essentials. My model and yours and the models of anyone else will contain these things.
Names in the model don't much matter, but definitions do. If I call it problem and you call it concern and someone else calls it diagnosis, it doesn't matter if my definition of diagnosis is different from that of someone else. But we often wind up comparing the words, rather than the concepts. What matters is that my definition of problem pretty much matches somebody else's definition of concern. If the concepts are close we can approximate exchange of meaning. If I can put my thoughts down in a way that you understand, we've communicated.
I can hear the screams: "But what about semantic interoperability? What you just said means that nobody will thoroughly understand the information being communicated." Yep. Nor is it any better even when we share the same mother tongue. But it gets better.
Communication (and interoperability) is not a science. It is an art form perfected over time. What we are able to communicate initially will be rough, but useful, so long as we recognize the limitations [sort of like me asking "When is the toilet?" in Japanese (which does work)]. It will get better, and we'll have a deeper understanding of what is being communicated as time progresses (as I eventually learned my interrogative verbs). Nuances will begin to appear if the communication is sustained over time.
Continued communication creates the model, not the other way around. If you doubt me, try this experiment. Call a friend or family member whom you spent a great deal of time in childhood with, or with whom you went to school, and talk to them for a while. Listen to yourself. Can you hear your communication pattern change as you talk with them? Does your accent from your childhood gain strength? I'll bet it does.
Don't try to create a model that perfectly captures all the idioms between two systems. Instead, create enough of a model to get started, and evolve it over time. The model you evolve is one that is created with a number of small shifts in agreement, and the direction that it takes may surprise you. I recall where we started with the HL7 Care Record Summary (CRS) and IHE XDS-MS profile. I know many of the subsequent tweaks that have been applied as they evolved into CCD, XPHR, CDA4CDT, C32 and finally C-CDA. Many idioms created in CRS and XDS-MS still live on, but new ones have evolved as well, including some pretty important ideas about how to say no and I don't know.
It took time to get here. We (those of us using C-CDA) have a model that works for us. Others (those using another model) have a model that works for them. There's enough cross-talk that we can still communicate because at the core, we all have a common understanding. That's not a standard, and the boundaries are fuzzy but growing and evolving.
You can start here (with CCDA) if you want, or you can start from there (pick another model). If you have nothing, either is a good place to start. If you do, you should know than by the time you learn it, those using it will have moved further on. If you want to start with your own model, study those of others. You will find enough similarities to develop enough of a model that you'll be able to communicate with others using the common core.
Language is a living thing. Your model is only the first (or second, or third) approximation to it, and it to will evolve.
Showing posts with label V3. Show all posts
Showing posts with label V3. Show all posts
Monday, November 30, 2009
Addresses in CDA
Writing a book about a standard is different from implementing it. When you are implementing, you can get away with ignoring parts of the standard that aren't of concern to you. However, when writing a book about it, you need to cover details that wouldn't normally concern you, at least to explain to your audience why they do or don't matter, and when those rubriks apply. Somewhere in the middle of that is writing implementation guides. Because I'm now writing a book, I'm rereading the standard, and discovering things I didn't know. I'll be reporting these discoveries from time to time.
Over the weekend, I discovered something about addresses in CDA that I didn't previously know. Now I have an even deeper understanding (and perhaps some remaining confusion) about the AD data type.
There are about 27 different kinds of information that can appear in an address data type. They are all different kinds of address parts (ADXP) in the Version 3 Data Types standard. I knew that.
What I didn't know was the difference between <streetAddressLine> and <deliveryAddressLine>, and some fine details about the XML representation of these parts. You've probably never seen the <deliveryAddressLine> referenced in any implementation guide, but it should have been. The difference between a <streetAddressLine> and a <deliveryAddressLine> is the difference between a physical delivery address and a PO Box, rural route or other sort of delivery address. A dearth of examples probably contributes to my lack of knowledge.
The Version 3 data types standard (both release 1 and 2) represents the address data type (AD) as a list of Address parts (ADXP), which can repeat any number of times. Practically, some of these should only appear once (e.g., postal code, city, state, country or county), while others could appear multiple times (e.g., streetAddressLine or deliveryAddressLine). There is also hierarchy of address part types which seems to imply a whole/part relationship between elements of the hierarchy. For example, you would imagine that the <streetAddressLine> could contain a <streetName> element. However, the data types schema doesn't allow the content of a <streetAddressLine> to contain a <streetName> element. If you are going to parse any portion of the street address in detail, you cannot wrap the parsed elements in a <streetAddressLine> element.
The long and short of it is that I learned something new, and now, hopefully, you have too.
Over the weekend, I discovered something about addresses in CDA that I didn't previously know. Now I have an even deeper understanding (and perhaps some remaining confusion) about the AD data type.
There are about 27 different kinds of information that can appear in an address data type. They are all different kinds of address parts (ADXP) in the Version 3 Data Types standard. I knew that.
What I didn't know was the difference between <streetAddressLine> and <deliveryAddressLine>, and some fine details about the XML representation of these parts. You've probably never seen the <deliveryAddressLine> referenced in any implementation guide, but it should have been. The difference between a <streetAddressLine> and a <deliveryAddressLine> is the difference between a physical delivery address and a PO Box, rural route or other sort of delivery address. A dearth of examples probably contributes to my lack of knowledge.
The Version 3 data types standard (both release 1 and 2) represents the address data type (AD) as a list of Address parts (ADXP), which can repeat any number of times. Practically, some of these should only appear once (e.g., postal code, city, state, country or county), while others could appear multiple times (e.g., streetAddressLine or deliveryAddressLine). There is also hierarchy of address part types which seems to imply a whole/part relationship between elements of the hierarchy. For example, you would imagine that the <streetAddressLine> could contain a <streetName> element. However, the data types schema doesn't allow the content of a <streetAddressLine> to contain a <streetName> element. If you are going to parse any portion of the street address in detail, you cannot wrap the parsed elements in a <streetAddressLine> element.
The long and short of it is that I learned something new, and now, hopefully, you have too.
Tuesday, November 24, 2009
Looking for CDA Stories
Writing on "The CDA Book" has started. It is amazing the amount of non-writing writing that you have to do when you start a book. The amount of reading you have to do is also pretty mind-numbing. Thanks to the web, at least some of that material is readily accessible, even 10 years after the fact.
I'm looking for CDA stories right now, especially stories of the early days of CDA, PRA, or KEG. If you have any of these you'd like to share, please let me know. I'm also interested in real-world, "today" CDA stories. If you have good (or bad) stories about CDA implementations today, I'd like to hear them. Finally, I'm curious as to whether I need to spend any time in the book on "The great SDO debacle of 2006". What are your thoughts?
I'm looking for CDA stories right now, especially stories of the early days of CDA, PRA, or KEG. If you have any of these you'd like to share, please let me know. I'm also interested in real-world, "today" CDA stories. If you have good (or bad) stories about CDA implementations today, I'd like to hear them. Finally, I'm curious as to whether I need to spend any time in the book on "The great SDO debacle of 2006". What are your thoughts?
Monday, November 16, 2009
Two books
I just bought myself a netbook. For the past 3 years the company notebook, and the 3 or 4 computers in my house have been sufficient, but now I need a "real" computer of my own, that can also travel when I do, and doesn't need to be wrestled from my wife.
The primary reason is that I'm now seriously considering writing "The" book, and it needs to be done on my own equipment. "The" book, will of course be "The CDA" book, but looking over my outline, there's no way I can produce "The CDA" book that I want, so it will have to start off by being "The LITTLE CDA Book" that contains most of what you need to know. So, it won't go into detail on the interworkings of the IHE PCC Technical Framework, the ANSI/HITSP Specifications, or the CCD. I won't spend a lot of time on CDA history (which I find fun, but most of you may not), but it hopefully will get you up to speed enough on CDA.
I haven't figured out all of the details about it yet. I'm not sure about how to approach the content, but have one or two working outlines. I haven't lined up a publisher. I don't even know where I'll find the time to do it (probably between the hours of crazy o'clock and insane thirty, with ocassional stretches to o'dark hundred). But I've been convinced for quite some time that it is needed, and was recently arm-twisted into thinking that I could do it at the last working group meeting.
Why am I telling you this? I'm setting myself up to succeed by telling you that I'm going to do it. I'm also looking for your input. What's needed in the "little CDA book"? The big one?
Post your feedback here, or e-mail me (see my e-mail address on the HL7 Structured Documents page).
The primary reason is that I'm now seriously considering writing "The" book, and it needs to be done on my own equipment. "The" book, will of course be "The CDA" book, but looking over my outline, there's no way I can produce "The CDA" book that I want, so it will have to start off by being "The LITTLE CDA Book" that contains most of what you need to know. So, it won't go into detail on the interworkings of the IHE PCC Technical Framework, the ANSI/HITSP Specifications, or the CCD. I won't spend a lot of time on CDA history (which I find fun, but most of you may not), but it hopefully will get you up to speed enough on CDA.
I haven't figured out all of the details about it yet. I'm not sure about how to approach the content, but have one or two working outlines. I haven't lined up a publisher. I don't even know where I'll find the time to do it (probably between the hours of crazy o'clock and insane thirty, with ocassional stretches to o'dark hundred). But I've been convinced for quite some time that it is needed, and was recently arm-twisted into thinking that I could do it at the last working group meeting.
Why am I telling you this? I'm setting myself up to succeed by telling you that I'm going to do it. I'm also looking for your input. What's needed in the "little CDA book"? The big one?
Post your feedback here, or e-mail me (see my e-mail address on the HL7 Structured Documents page).
Moving Forward
Those who cannot learn from history are condemned to repeat it. -- George Santayana
The resurrection of the debate between "CCR" and "CDA" of four years seems to ignore all that has occured since then. If we are not careful, we are doomed to repeat our mistakes, and even if we are, it would appear that we are at least condemned to repeat the labor leading from our successes.
Do you remember all the hullaballo in early 2007 celebrating the harmonization of the CCR and CDA into CCD? As one of the 14 editors of that specification who worked on it with members of HL7 and ASTM for more than I year, I certainly do. At the time, it was celebrated as being one of the great successes of harmonization. Most of us, having achieved the success of CCD moved on. We built on that information model to support a truly interoperable exchange for healthcare. Only now there are some who wish to see that work discarded because "it's not internet friendly".
Lest we forget, there's a lot more to agreeing on CCD that was needed to ensure interoperability. There are some 80 different value sets from more than 25 different vocabularies that have been incorporated into the standards for the selected use cases. There's also the necessity to secure the transport of that information through at variety of different topologies.
That took some three years of effort AFTER we resolved the CDA vs. CCR debate with the "both AND" of CCD. If your definition of BOTH AND has changed, (and apparently it has for some), then more work is needed on the CCR half. We would need to bring CCR up to the same level of interoperability that we did with CCD, and that will require yet more effort. Frankly, I'd rather spend that time working on making the existing standards better by taking the learnings from the internet crowd and the health informatics crowd back into the healthcare standards organzations. That's a BOTH AND that is a step in the right direction, instead of a step backwards.
The resurrection of the debate between "CCR" and "CDA" of four years seems to ignore all that has occured since then. If we are not careful, we are doomed to repeat our mistakes, and even if we are, it would appear that we are at least condemned to repeat the labor leading from our successes.
Do you remember all the hullaballo in early 2007 celebrating the harmonization of the CCR and CDA into CCD? As one of the 14 editors of that specification who worked on it with members of HL7 and ASTM for more than I year, I certainly do. At the time, it was celebrated as being one of the great successes of harmonization. Most of us, having achieved the success of CCD moved on. We built on that information model to support a truly interoperable exchange for healthcare. Only now there are some who wish to see that work discarded because "it's not internet friendly".
Lest we forget, there's a lot more to agreeing on CCD that was needed to ensure interoperability. There are some 80 different value sets from more than 25 different vocabularies that have been incorporated into the standards for the selected use cases. There's also the necessity to secure the transport of that information through at variety of different topologies.
That took some three years of effort AFTER we resolved the CDA vs. CCR debate with the "both AND" of CCD. If your definition of BOTH AND has changed, (and apparently it has for some), then more work is needed on the CCR half. We would need to bring CCR up to the same level of interoperability that we did with CCD, and that will require yet more effort. Frankly, I'd rather spend that time working on making the existing standards better by taking the learnings from the internet crowd and the health informatics crowd back into the healthcare standards organzations. That's a BOTH AND that is a step in the right direction, instead of a step backwards.
Thursday, October 29, 2009
Team Building and CDA Schematrons
I'm in Portland Oregon for most of this week for a workout with one of our development teams. Joining me are my boss and one of our other Standards Geeks. I've long known the importance of face to face contact in developing relationships, and the benefits of my being out here for just one day are already apparent. For one, I've learned that my boss is a better pool player than I am, but not by much ;-)
Our discussions today were far ranging, but one of them centered around validating CDA constructs. There's a great tool that's been developed by NIST called the CDA Guideline Validator. This tool is based on collaborative work from NIST, Alschuler Associates, LLC, Integrating the Healthcare Enterprise (IHE) and the CCHIT Health IT Collaboration Effort "LAIKA" project. While it is a great tool, there are still some process issues that need to be worked out for it to be of greater service to the healthcare IT industry. Don't get me wrong, I love these tools, and point people to them several times a month, but I'd like to see a little bit more.
One of the issues that I run into is that we have to revalidate this tool every time it gets updated to use as part of our testing processes. Here are a few suggestions I'd like to make that I think will improve the use of this tool as part of certification testing and vendor implementation.
1. I'd like to see a design document that describes the overall design of the validation tools. The schematron source code for the validator is great, and frankly, I know a good bit about how that was built, but others need access to that information as well. This need not be a long document, it could be as short as 3 - 5 pages.
2. I'd like to see some explanations about how to read the output documented somewhere.
3. I'd really like to see a validation plan that shows how the rules implemented by the tool are tested, and a validation suite that tests the rules (both positively and negatively).
4. Having Andrew's and Mary's e-mail contact information available is terrific, but a little hard for people to find when they need to report problems. Also, not having an active bug list that people can view and track makes keeping up with the issues a bit of a struggle. I'd like to see a real bug tracking system installed and accessible from the main page.
5. Coordinating feedback from bugs to the organizations responsible for interpretation of the various templates is also difficult (I'm involved in three of them, and I hear from Andrew regularly with all three hats on).
6. I'd love to see a way to directly link each of the errors reported to the appropriate place in the document from which rule is derived. For HITSP and HL7 this is fairly straightforward (it's just a link to the appropriate constrain ID in the document), but for IHE is a little bit more difficult. The IHE profiles need to be a little bit more formal about their constraints in the profiles, now that it (we) have removed the Schematrons themselves from the technical framework (note to self, add as a discussion item at the PCC face to face in two weeks).
7. We need a little bit more formal governance model for how to deal with interpretation of the standards and implementation guides that this tool is supporting. Somewhere along the way I'd like to see a way to verify that the various tests do in fact meet the requirements specified by each of the various guides, and a process for resolving issues that require input from the appropriate authorities.
8. I think this tool could be taken further, and I'd like to see it run as an open source project(*) that we could all participate in. I think structuring it that way would provide more capacity for improvement.
We've already got a terrific bunch of players that has developed this tool, let's put them all on the same team.
* LAIKA is already an open source project, but only supports C32. I'd like to see the entire set of Schematron validation tools be part of a separate open source project. Oh, and it'd be really nice if they supported the IHE SVS profile for value set validation (ITI changed the profile during public comment last year to support an HTTP GET retrieval of the value set in XML that is suited for that purpose for that very reason). And furthermore..., oh just start the thing and I'll chime in.
Our discussions today were far ranging, but one of them centered around validating CDA constructs. There's a great tool that's been developed by NIST called the CDA Guideline Validator. This tool is based on collaborative work from NIST, Alschuler Associates, LLC, Integrating the Healthcare Enterprise (IHE) and the CCHIT Health IT Collaboration Effort "LAIKA" project. While it is a great tool, there are still some process issues that need to be worked out for it to be of greater service to the healthcare IT industry. Don't get me wrong, I love these tools, and point people to them several times a month, but I'd like to see a little bit more.
One of the issues that I run into is that we have to revalidate this tool every time it gets updated to use as part of our testing processes. Here are a few suggestions I'd like to make that I think will improve the use of this tool as part of certification testing and vendor implementation.
1. I'd like to see a design document that describes the overall design of the validation tools. The schematron source code for the validator is great, and frankly, I know a good bit about how that was built, but others need access to that information as well. This need not be a long document, it could be as short as 3 - 5 pages.
2. I'd like to see some explanations about how to read the output documented somewhere.
3. I'd really like to see a validation plan that shows how the rules implemented by the tool are tested, and a validation suite that tests the rules (both positively and negatively).
4. Having Andrew's and Mary's e-mail contact information available is terrific, but a little hard for people to find when they need to report problems. Also, not having an active bug list that people can view and track makes keeping up with the issues a bit of a struggle. I'd like to see a real bug tracking system installed and accessible from the main page.
5. Coordinating feedback from bugs to the organizations responsible for interpretation of the various templates is also difficult (I'm involved in three of them, and I hear from Andrew regularly with all three hats on).
6. I'd love to see a way to directly link each of the errors reported to the appropriate place in the document from which rule is derived. For HITSP and HL7 this is fairly straightforward (it's just a link to the appropriate constrain ID in the document), but for IHE is a little bit more difficult. The IHE profiles need to be a little bit more formal about their constraints in the profiles, now that it (we) have removed the Schematrons themselves from the technical framework (note to self, add as a discussion item at the PCC face to face in two weeks).
7. We need a little bit more formal governance model for how to deal with interpretation of the standards and implementation guides that this tool is supporting. Somewhere along the way I'd like to see a way to verify that the various tests do in fact meet the requirements specified by each of the various guides, and a process for resolving issues that require input from the appropriate authorities.
8. I think this tool could be taken further, and I'd like to see it run as an open source project(*) that we could all participate in. I think structuring it that way would provide more capacity for improvement.
We've already got a terrific bunch of players that has developed this tool, let's put them all on the same team.
* LAIKA is already an open source project, but only supports C32. I'd like to see the entire set of Schematron validation tools be part of a separate open source project. Oh, and it'd be really nice if they supported the IHE SVS profile for value set validation (ITI changed the profile during public comment last year to support an HTTP GET retrieval of the value set in XML that is suited for that purpose for that very reason). And furthermore..., oh just start the thing and I'll chime in.
Friday, October 9, 2009
An HL7 Version 3 WSDL Generator
A couple of weeks ago I railed at HL7 because they don't provide the tools that my collegues and I need to build Version 3 interfaces. To begin remedy that problem, I started on some of my own tools. I needed to create a WSDL for an IHE profile. Since I had already figured out that the problem could be automated, I decided to figure out how to do it. A few hours (about 20 all told) later, I've got a solution, which is about 8-12 hours longer than it would have taken me to hand-craft the WSDL in the first place. The ROI will show up the very next time I need a WSDL for something.
It's remarkably small too, about 1400 lines of Java and an XSL transform that lets me customize the way the WSDL is built. I spent about 15 of the 20 hours trying to figure out how to deal with the transmission infrastructure, before I gave up and punted.
The application uses the PubDB file created by the publishing facilitator for any given workgroup. Principally what it extracts from that database are relationships between the application roles and the interactions. These are then written to an XML document, which is finally transformed via an XSLT transform into the WSDL output.
There's probably a dozen places where I've done something wrong, have misunderstood the intent behind HL7 transmission infrastructure, the mapping between messages in HL7 Version 3, and elsewhere. However, I think its a useful start. Certainly it will save me some work in the future. Who knows, maybe someday this tool will actually be used during the build process of the HL7 Version 3 Standards to generate WSDLs automatically.
If you are interested, the complete project is in HL7V3WSDL.zip.
HL7V3WSDLGenerator is a rather simple software application that is designed to automatically generate WSDL files from HL7 Version 3 artifacts. To use this software you need only two more things:
java -cp . org.hl7.v3.wsdl.WSDLGenerator PubDB.mdb
It's remarkably small too, about 1400 lines of Java and an XSL transform that lets me customize the way the WSDL is built. I spent about 15 of the 20 hours trying to figure out how to deal with the transmission infrastructure, before I gave up and punted.
The application uses the PubDB file created by the publishing facilitator for any given workgroup. Principally what it extracts from that database are relationships between the application roles and the interactions. These are then written to an XML document, which is finally transformed via an XSLT transform into the WSDL output.
There's probably a dozen places where I've done something wrong, have misunderstood the intent behind HL7 transmission infrastructure, the mapping between messages in HL7 Version 3, and elsewhere. However, I think its a useful start. Certainly it will save me some work in the future. Who knows, maybe someday this tool will actually be used during the build process of the HL7 Version 3 Standards to generate WSDLs automatically.
If you are interested, the complete project is in HL7V3WSDL.zip.
HL7V3WSDLGenerator is a rather simple software application that is designed to automatically generate WSDL files from HL7 Version 3 artifacts. To use this software you need only two more things:
- A copy of the publication database for the domain you want to build a WSDL for
- A Java Virtual Machine that supports Java 1.5 or later.
Installing the sofware is simple, just unzip the file to your hard drive. Running it is equally simple. From the folder where you installed the software, type in
Where PubDb.mdb is the location of a PubDB file. Don't have one? You can find the ones used for each ballot cycle here: http://www.hl7.org/v3ballot/html/ (Just click on Source Files for the appropriate cycle, then domains and finally download one of the database zip files you find there; see here for an example).
Source code and documentation are provided, however I must note that support is not:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
I'm planning on moving this into HL7 G-Forge or OHT in the future. I'm also going to update the stylesheet (actually provide an alternate) to support IHE style WSDL files using ITI Volume II Appendix V rules. If you understood that, you need to get out more often.
Wednesday, June 18, 2008
If I had a Hammer
“If the only tool you have is a hammer, you tend to see every problem as a nail.” — Abraham Maslow (1908-70), American psychologist
Recently, I ran across a question on the ANSI/HITSP C32 specification from an implementer. The C32 specification describes how the US Federal Government expects to use the HL7 Continuity of Care Document in our National Health Information Network.
Much work has been done on creating CDA documents using these CCD templates, in HL7, IHE and elsewhere. To date, there are implementations guides that have been developed by IHE and HL7 for:
Recently, I ran across a question on the ANSI/HITSP C32 specification from an implementer. The C32 specification describes how the US Federal Government expects to use the HL7 Continuity of Care Document in our National Health Information Network.
The question expresses two parts of the problem:The basic question we started with is how does one represent an operative report, a discharge summary, or a progress note in a C32 document.
I am still a bit confused with the 2
sections and what goes into each one, and the fact that we can't capture the document type (i.e., operative report vs. discharge summary vs. progress note).
- How do we make use of the CCD to create a uniform way to exchange information, and having done so,
- How do we classify documents as to the type of service they describe.
Much work has been done on creating CDA documents using these CCD templates, in HL7, IHE and elsewhere. To date, there are implementations guides that have been developed by IHE and HL7 for:
- Discharge and Transfer Summaries
- Consult Notes
- History and Physical Notes
- Operative Reports
- Antepartum Summaries
- Remote Monitoring
- Personal Health Exchange
- Emergency Department Encounters
Each of these implementation guides is using templates from the HL7 Continuity of Care Document, so that as we look inside each document, problems, medications, allergies and other clinical information have a uniform representation based on the CCD.
So the real question is not, "how to I put an operative note into a CCD", but rather,
How do we use the CCD specifications to record this information inside a _____(fill in the blank)?
The answer is to use the same templates created for the CCD, and in the ANSI/HITSP C32 specification in those other clinical documents.
The reason for doing this can be explained very simply. Imagine that you are a physician caring for a patient, and you want to find a particular document. It may be an operative note, a discharge summary, a consultation, et cetera. If all documents are CCD's, then you no longer have the capability to distinguish between them by the kind of service represented in the document. Can you imaging wading through all of these CCD's to find the right document? What you really want is for those documents to be classified by the kind of service performed by the provider. If it's a discharge summary, then it should say so.
Recently, the ANSI/HITSP Care Management and Health Records Technical Committee met in Washington DC, and discussed this topic. The solution proposed was to recognize that the C32 specifications applied not to just CCD documents, but to all HITSP created CDA based specifications. That committee will be reworking the HITSP specifications this year to better enable reuse of the C32 specifications across all clinical documents.
The HL7 Structured Documents work group will also be reviewing plans for development of the next release of the HL7 Continuity of Care Document later this year. The expectation is that we would propose changes based on feedback from implementers such as the NHIN implementation projects. When that work begins, I will be proposing a change to the very first conformance statement in the Continuity of Care Document. That statement is reproduced here:
CONF-1: The value for “ClinicalDocument / code” SHALL be “34133-9” “Summarization of episode note” 2.16.840.1.113883.6.1 LOINC STATIC.
My proposal will change this conformance statement to allow for the use of other LOINC codes when the purpose of the document is to contain a medical summary and documentation of other care. I've shown the proposed text below. Please note, this is only my proposal, there is no guarantee that this will become part of the next version of CCD, but it could help to address the confusion raised by the current specification.
CONF-1: A document conforming the these specifications may use any LOINC code in “ClinicalDocument / code” to describe its content. When the purpose of the document is solely to summarize the patient's current health status, the value for “ClinicalDocument / code” SHALL be “34133-9” “Summarization of episode note” 2.16.840.1.113883.6.1 LOINC STATIC.
We need use the right tool for the job, and while the CCD Document is a hammer, the CCD specification itself provides us with a whole box of tools -- CDA sections and entries. We can use these tools to build any number of clinical documents. Furthermore, having done so, we can expect that healthcare applications will be able to understand the content.
Subscribe to:
Posts (Atom)