[This Transcript is Unedited]
Hubert H. Humphrey Building
200 Independence Avenue, SW
Room 800
Washington, D.C. 20201
AGENDA ITEM: Call to Order, Welcome and Introductions --HARRY REYNOLDS, CO-CHAIR
MR. REYNOLDS: Good morning. My name is Harry Reynolds, and I'm Vice President, Blue Cross and Blue Shield of North Carolina, and Co-Chair, along with Jeff Blair, of the Subcommittee on Standards and Security of the National Committee on Vital and Health Statistics.
The NCVHS is a Federal advisory committee consisting of private citizens that makes recommendations to the Secretary of HHS on health information policy.
On behalf of the Subcommittee and staff, I want to welcome you to today's hearing on e-prescribing and the secondary use of clinical data. We are being broadcast live over the Internet, and I want to welcome our Internet listeners as well.
As is our custom, we will begin with introductions of the members of the Subcommittee, staff, witnesses and guests. I would invite Subcommittee members to disclose any conflicts of interest. Staff, witnesses and guests need not disclose conflicts. I will begin by noting that I have no conflicts of interest.
I would request that witnesses and guests turn off their cell phones. Also, during the hearing, if we will all speak clearly and into the microphones, those listening on the Internet will be most appreciative, so, Jeff, you can start the introductions.
[Introductions.]
MS. GREENBERG: Harry?
MR. REYNOLDS: Yes, Marjorie?
MS. GREENBERG: I don't know if you received the email from Judy Warren?
MR. REYNOLDS: Yes.
MS. GREENBERG: You're aware of this, okay.
MR. REYNOLDS: Thank you.
MS. GREENBERG: Her plane was cancelled, and she'll be here later.
MR. REYNOLDS: We'll ask her for sure if she actually missed it. See, that's the party line, that her plane was cancelled.
[Laughter.]
MS. GREENBERG: The dog ate my homework?
MR. REYNOLDS: Okay. Our first presentation today is an update from Lynne Gilbertson on the work that NCPDP has done since our last hearings.
AGENDA ITEM: Presentation -- LYNNE GILBERTSON
MS. GILBERTSON: Thank you. It's really great to be back; it's like old home week. But I love the energy of the room. Let's get things done. So I'm here to present
the NCPDP status of the NCVHS recommendations to HHS on electronic prescribing for the MMA, the Medicare Modernization Act.
The testimony will go through the different observations that NCVHS recommended, of which NCPDP had a part, and give you a status on those items.
Observation 4 dealt with prescription messages, and the recommendation in particular was to include the fill status notification function of the NCPDP SCRIPT standard in the 2006 pilot tests to assess the business value and clinical utility of the fill status notification function as well as evaluate privacy issues and possible mitigation strategies.
The status on this item is that NCPDP Work Group 11, E-Prescribing and Related Transactions, RXFILL Task Group, created implementation and operational guidance to pharmacy and prescriber system participants for the consistent utilization for the fill status notification transactions.
This guidance includes operational challenges such as automatic triggering of fill status notifications, triggering on return to stock, inferring pick-up, privacy, liability, coordination with medication history functions, a patient changing physicians and other items.
This guidance was added to the SCRIPT Standard
Implementation Guide Version 8.1. They were not balloted items, but occurred in that publication of the version of the imp guide. The estimated publication of SCRIPT Version 8.1, because there were balloted items, will be in the October/November time frame.
Observation 4, coordination of prescription message standards -- this was related to the NCPDP HL7 e-prescribing coordination, the mapping project, and that status will be given by Ross Martin later this morning.
Observation 5, formulary messages -- HHS should actively participate in and support the rapid development of an NCPDP standard for formulary and benefit file transfer, using the RxHub protocol as a basis.
The status is that the protocol was brought forward. It had been vetted in the industry beforehand. There were numerous meetings held with a task group to vet it even further and the formulary and benefit standard Version 1.0 was brought forward to NCPDP at the March, 2005, work group meetings.
It was balloted in April of 2005 as part of the ANSI process. Ballots that receive any negative with comment are adjudicated. They were adjudicated in the May work group meeting. The comments were about clarification, ways to state things a little clearer, and they were very positive comments.
As part of the ANSI process, the recirculation ballot is going on right now in July. The final review of any comments that come in will occur in the August work group meeting at NCPDP. After the mandatory appeal time frame, which is September, the NCPDP Board of Trustees will be asked to approve the formulary and benefit standard implementation guide Version 1.0, and we anticipate that taking place in October.
The ANSI process is going on in tandem with the NCPDP process, so, again, we expect that probably by the time all the little bits and pieces -- I can't promise an exact date, but we know the time frames that hit each of the different things. We should have an expected publication by the November, at the latest December, time frame.
The standard includes the sharing of formulary status lists, codes to explain how to treat non-listed brand, generic, over-the-counter; whether the drug is on formulary or preferred status; its relative value limit.
It includes formulary alternative lists, conditions under which the patient's pharmacy benefit covers a medication.
The benefit co-pay lists, the extent to which the patient is responsible for the cost of the prescription -- the specification supports multiple ways to state this cost, including a flat dollar, a percentage, and the tiers.
It also contains a cross-reference file of user-recognized health plan product names to the identifiers that are used in the formulary, alternative, coverage and co-pay.
It's quite a proud industry undertaking to see that it got done. It's usual in a lot of our work group functions, but it is also amazing to see the amount of people that came together with various interests and sometimes competition, but recognized that there needed to be something moved forward that they could all agree to, and to watch this actually taking place and as quickly of a time frame -- I mean, if there were no negative comments on the ballot, then the ballot would have flown through faster, but I would have been skeptical that nobody read it, so it's always good to have some clarifications added and get it as tidied up as possible.
Observation 6, eligibility and benefits message
-- the item for the NCPDP status on this was a guidance document to map the pharmacy information that's on the Medicare Part D Pharmacy ID Card to the appropriate fields that you would use on the ASC X12N 270/217.
That has been completed. The notification went out with the 7-15 NCPDP newsletter and the information is posted on the -- I believe it's a public area of the website.
Observation 7, prior authorization messages -- this is to develop prior authorization workflow scenarios to contribute to contribute to the design of the 2006 pilot tests and to automate the communication, and we'll have a great update from Tony Schueth later this morning.
Observation 8, medication history messages, the recommendation was the HHS should actively participate in and support the rapid development of an NCPDP standard for a medication history message for communication from a payer/PBM to a prescriber, using the RxHub protocol as a basis.
Once again, RxHub fits, submitted what we call a "Data Element Request Form." It's a request to add functionality to a given standard. They brought it forward in November of last year. It was incorporated into the SCRIPT Standard Implementation Guide Version 8.0. The standard has been balloted and approved. At this moment, the NCPDP Board of Trustees is approving the ballot through the procedures. ANSI approval of SCRIPT 8.0 is also underway, and I expect notices back from the Board and from ANSI by September.
Observation 9, clinical drug terminology -- HHS should include in the 2006 pilot tests the RxNorm terminology in the NCPDP Script Standard for new prescriptions, renewals and changes.
In June, NCPDP members met via conference call with John Kilbourne from the National Library of Medicine. Stuart Nelson mentioned in his late update that he had a new employee who would be taking over this role in coordination with standards development organizations, and that is John.
We held an initial call to introduce John to the different standards that we thought there might be some fits for RxNorm, and right now the group is working on a Q&A document based on the different standards, where there are gaps, what kinds of problems have been seen with not having a standard set of code, values to go back and forth in different messages, and John will be attending the NCPDP August session and during Work Group 11 we will be discussing that document and starting to form a framework for what the next work product should be, to try to figure out how we get from the 50,000-foot level down to the 5,000 and what are we really talking about? What in a formulary message is really needed? What level of drug discussion goes on in those business functions? And is there really a fit for some level of RxNorm at this point?
In the new prescription messages that go back and forth, the refills, are there levels of business discussion that go back and forth with the discussion of the drug that
RxNorm could fit? At this point, we don't know. We think, we hope, but we need to continue that exploratory. And now that John has joined NLM, we have a go-to person to really start digging into the technical or the clinical side that the pharmacies and the prescribers understand from our perspective and John to understand from the RxNorm perspective, so hopefully we'll be able to pull everybody together.
Observation 10, structured and codified SIG -- HHS should support NCPDP, HL7 and others, especially including the prescriber community, in addressing SIG components in their standards. And we'll have an update in a little bit from Laura Topor, who's the task group leader of this activity.
Observation 13, pilot test objectives -- NCPDP didn't have any particular work item at this point. We are waiting on information from CMS.
One other item I wanted to bring to your attention is a lot of work is going on in NCPDP with Work Group 14, which is long-term care. They are spending a lot of time with a lot of industry expertise. They formed task groups to work on the needs of this sector, especially in light of the MMA.
They're working on billing needs. They're examining electronic prescribing needs, and they will work with NCPDP's Work Group 11, e-prescribing and related transactions, to develop enhancements to the SCRIPT Standard that meet the needs of the long-term care.
They have done a lot of work showing the process flows in long-term care. They're working on conformance criteria with the HL7 group for the LTC EHR -- electronic health record -- minimum functions. They have pulled expertise from across the long-term care industry, from organizations, from standard bodies in these various efforts. They have a lot of challenges, but they have been a really strong foundation for getting the work done.
And that concludes the status. Thank you.
MR. REYNOLDS: Lynne, thank you. I'd like to congratulate you and everybody that worked on it. You guys are a guiding light for what the word "collaboration" really means.
MS. GILBERTSON: Thank you. I get the good job of giving you the status, but there's an awful lot of people around the room --
MR. REYNOLDS: No, that's why --
MS. GILBERTSON: -- that could take a lot of credit.
MR. REYNOLDS: -- I think as a group they really stepped up.
Jeffrey, you led this, a lot of this e-prescribing, so why don't let you open the questions, if you have any. If not, I'll open it to the rest of the panel.
MR. BLAIR: Yes. I'll probably save my congratulations, but this is a preview, because I think the entire industry really -- RxHub, NCPDP, HL7, Express Scripts -- I could go down the list of all of the entities that have worked together to make this happen. This is unprecedented in my mind. I don't know that anything like this has ever happened in this time frame before.
Lynne, what is your expectations of the role that NCPDP SCRIPT will be playing during the pilot tests?
MS. GILBERTSON: I would expect that as the different groups who I know -- some folks are working together to form coordination, expecting what might be happening in the pilots -- I would expect that they would be coming forward with draft requests of "we think this is what we need to perform this particular function that we haven't thought of yet but is part of what we're going to test in the pilot so can we put together, you know, a draft copy of the document that shows how to implement this particular function?"
You know, I could see that we're going to have things crop up that people have said, well, now that we're in the midst of it, we realize could we add a field here or there to help this function better, knowing that that would then be brought forward after the dust settles and make it actually part of the standard. I could see that.
One of our functions I would see could be as some kind of assistance, maybe a conduit, maybe a way of sharing knowledge during our working group sessions to discuss who's doing what in the pilot, what they're finding, if they need someone to test something -- you know, putting out a call to arms for "come join us; we'd like to get a sector from long-term care, we'd like to get a sector from ambulatory," whatever kind of setting.
Let's see. I think we're going to be somewhat reactive because, as you will see from Laura and Tony's presentation, there are things that the dust hasn't settled on yet and so people are going to be finding things in some of the draft standards that haven't been vetted yet that we'll be modifying as we learn, typical lessons learned. That's just find; they're draft documents to begin with.
Obviously, we'll be very glad to notify the membership when we have the proposed prescribing pilot information available so that people can react to the request for proposal or however it'll be handled.
MS. FRIEDMAN: I have to say a word about that. Just a quick update. That is in process. We'd hoped to have it on the street by now; obviously it's not. So, stay tuned, and I will let people know as soon as it's published. The work is going to be done collaboratively between AHRQ and CMS.
MR. REYNOLDS: Jeff, any other question?
MR. BLAIR: Not at this time. Thank you.
MR. REYNOLDS: Okay, seeing no other hands, I have a few -- or Stan has one. So give it a shot.
DR. HUFF: Lynne, could you say more about what the issues and questions are related to the use of RxNorm?
MS. GILBERTSON: Some of it is my own. I'm just not quite sure what exactly -- from a standards perspective, I can put in a qualifier that says RxNorm and I can have a field that fits whatever codes you want to throw in there. Okay, so that part could be very easy.
What I'm trying to help the task groups and the work groups get through is when they see RxNorm, they're presented usually with a chart of about eight or ten tables, a model, and they say, what do I use? When I want to transmit the drug being prescribed, well, where do I go, what do I use in RxNorm? Or is it something that my drug knowledge base vendor will provide me some kind of cross-reference file to RxNorm based on what I have in my system?
So it's not necessarily the standard supporting; it's how you would support it to the best in that particular business case. I realize it's not a great answer, but that's the kind of thing we're stumbling with.
If on a new prescription, current use is to send the name, because it's the most current, the most up to date, the most usable item we have right now, and you turn that into an RxNorm code, how do you get it? Where does it come from? At what level do you pull it off?
The other is there have been some questions as well in making sure that does the RxNorm code that you would pull map exactly what that drug name was trying to tell you, and is there a confidence factor? And so we're looking at what that mapping really is, and does it reflect the right level of what the prescriber had pulled off when they pulled text, and making sure that confidence is high as well.
So those are some of the things we'll be working through in formulary and benefit.
Does it make more sense to send a representative NDC in the business case of sending some kind of formulary list? Does it make sense to send the RxNorm code? Formulary and benefit has a place-holder for RxNorm, but we have no guidance in the document for what that means. It's just a value place-holder right now that says when we know more, we'll add it to the implementation guide.
So those are some of the things we're trying to work through.
MR. REYNOLDS: Michael?
DR. FITZMAURICE: I guess Stan asked one of my major questions. But first, Lynne, I want to join everybody here -- this is just remarkable, the level of industry cooperation and the output of having concrete products, and you gave us dates on which they were going to be published. So you're reflecting the commitment of a lot of the work of the people who are on these committees, and traveling and being on the phone, giving up a lot of their time to make something work. And all I can say is: More!
[Laughter.]
DR. FITZMAURICE: That's not what you were expecting but --
MS. GILBERTSON: Yes, sir, we'll get right on it!
DR. FITZMAURICE: -- you always want more.
So, I gather from the RxNorm that to be ready for prime time, there needs to be more information about the business case incorporated by the developers of RxNorm and more knowledge of how it might work in the business by NCPDP and the pharmacies and the prescribers, and that has yet to be worked out yet. Just the fit of it in the workflow and what the advantages are and the benefits and the costs of it, is that another way of saying it?
MS. GILBERTSON: Right. That would be a good way of saying it.
And one of the things for the pilot, for example, would be the just -- and I don't know the answers to this, but one of the questions I would ask that we nail down is when, if someone's going to participate in the pilot with it, where do they get the RxNorm codes from? Are they up to date? You know, those kind of things, so that we understand -- is a production ready, is it able to be loaded in, do they require or need a drug knowledge base behind it with some kind of interface as well of some type?
And getting all those -- you know, there's a point where NCPDP will step back because we're not in the business of sending code sets around, that kind of thing. But to help facilitate the people in the pilot, we'd like to be able to at least point them in the right direction of how you get what you need to participate in the pilot.
DR. FITZMAURICE: So you're looking for a commitment by the developers, let's say by NLM, to maintain the code set and have a place for it on a website, a downloadable place where you can say, "Here's where it is and here's a version of it and this is ready to be put into a production." Is that it?
MS. GILBERTSON: And if the users have questions, where do they call? Who do they contact? You know, a help desk --
DR. FITZMAURICE: Both maintenance and support.
MS. GILBERTSON: Right. Of a production product, yes. Yes, and just making sure. Do they call their drug knowledge base company first? You know, those are just kind of things that -- because it's not out there and really being used in this environment, those are all just general questions of how do you get it limping for a pilot?
DR. FITZMAURICE: And so this is some of the information that John Kilbourne and NLM are going to be understanding and looking to see how they can meet the need?
MS. GILBERTSON: I'm hoping. That's on my list of questions as we go down them, that's right.
DR. FITZMAURICE: Okay. One more question. That is, on the Observation 6, eligibility and benefits messages, you talked about the task group has completed a mapping document between the two different standards. Do there need to be made changes to implementation guides for those standards to reflect the mapping, or in the normal course of standards you just say, "I need them like this into this and so I'll just grab the map and use it?" I'm looking at the top of Page 3.
MS. GILBERTSON: Right. Okay -- I guess I should apologize. It's kind of misuse of the word "map." It is a map, but not quite in the mapping functions we've been talking about.
Basically, you have an ID card implementation guide that says this is what your pharmacy health care ID card looks like. And it has, you know, where your name should be, where the routing information should be, things like that.
This mapping that they built was saying, if you are presented one of these cards as part of the Medicare program, for example, where do you put the information that you see on that card into the 270/271 message?
So it's not a functional/technical mapping; it's more a guidance for the vendors that say "the field called RX Bin on the card goes in this field on the 270 transaction."
DR. FITZMAURICE: Does that mean a change to the implementation guide for the 270 or --
MS. GILBERTSON: No. No changes were necessary.
DR. FITZMAURICE: Okay. Thank you.
MR. REYNOLDS: Okay, I've got a couple questions, Lynne.
On Observation 3, privacy issues was a point that we brought up, and possible mitigation strategies. And as I listened to the testimony, it mentions guidance on privacy. But could you tell us a little more about whether or not you saw any mitigation and what types of recommendations? Do you feel that you've dealt with the subject to the point that you made recommendations or that it needs further review?
MS. GILBERTSON: To the point that NCPDP, as a standards organization, there is guidance about privacy, but as a standards organization, we do not take it that extra step. So it only went as far as notifying the reader about the types of issues and the things to be concerned about but did not go that extra step. We don't give that kind of legal or that kind of guidance in our environment.
MR. REYNOLDS: Okay. On Observation 5, and Laura, I would appreciate it if you would maybe touch on this as you get to your presentation, as we listen to e-prescribing and you think of the actual implementation of it, especially in the individual doctor's office, when you look at the device they may have, whether it's hand-held or it's a notebook or what it is, as I look at what came out of the formulary, it talks about a lot of things.
As I reviewed Laura's presentation last night, there are a lot of pieces to the SIG. Can you give us any sense of whether or not the actual implementation was considered as you were putting it together and whether or not you see any kind of issues -- with the way the standard's set up, it wouldn't necessarily translate into when we get into the pilot, we might find that it's going to be more cumbersome than originally thought? Or just any comments you might have on it.
MS. GILBERTSON: Considerations were given, and I know that during the working sessions that RxHub had prior to bringing the formulary and benefit standard forward and then after the standard was brought forward, there was a lot of discussions about the amount of information. I mean, for the first time available to some participants, you know, to some prescribers, you can't plot all this information on a screen somewhere and expect it to be usable.
One of the things that did come across my mind as a lot of these discussions were taking place about how mystical and magical I think the e-prescribing vendors are, because they have to take a lot of information and figure out what is the prescriber's workflow. When do you want this information to show up? Do you want it to be a button you click? Do you want it to be a hard versus soft message? Things like that.
So there was consideration, and SIG we've talked a lot about, where SIG could go. I mean, there were people who started SIG thinking that we would have a six-byte code and then millions of possible combinations to describe each one of those six-byte codes, that that would be the easiest to do. And that's very true, but it's usefulness quickly became -- you know, it was not at all useful.
And we tried to then look at other examples, as SIG has been worked on for years, of how far to the other side you could go. And then there were a few of the doctors who kept the mantra of "keep it simple, keep it succinct. We're doing the 80/20. We're not doing all 100 percent."
So it may look a little verbose still, but there's a lot of information that has to be shared.
As far as presentation and what the vendors -- maybe some of the audience, Terri or others would have a lot, you know, to give you some real good examples of how that's been translated into usable, but I don't have a lot of working knowledge of that other than we did make sure it was on our shoulders when we were discussing.
MR. REYNOLDS: Yes, I don't need to go into that much detail. What I appreciate is that you considered it, you've had the discussions, because in the end, we all, as you've heard from the hearings, having it be able to work in the end is also one of the driving ends.
Jeff, you had another question?
MR. BLAIR: We don't have the reg yet in terms of how the pilot test will be constructed, so I don't know if this question is going to be good that it happens now or not good.
[Laughter.]
MR. BLAIR: So I'm beginning, as you could tell -- I sort of feel like a lot of the work has been done to identify the gaps and limitations in standards and to address them and to get them ready before the pilot tests.
And so my thinking now is in terms of getting ready to make sure that when the pilot tests occur that the mechanisms or processes or structures are in place, to gather the information that is needed to feed back to the SDOs and the industry so that either corrections can be made or issues can be mitigated, and so on one part that's a CMS activity, on the other part it would be on the part of the SDOs to have a mechanism to, as you indicated, answer questions, refine, maybe a help line, clarifications.
But the other piece might some kind of an internal adjudication process during the pilot tests to try to resolve issues that are being identified. Or even to give information back to CMS to say "here's the kind of data we need to have captured" during the pilot tests so that we can resolve issues.
So I guess my question is: Have those discussions already taken place between NCPDP and CMS, or is that something that you're planning on doing, or is that something that, you know, you sort of feel like you can't do until after the rule is released? Or what is the status of addressing those types of issues?
MS. GILBERTSON: Do you want to go first, Maria, or should I?
MS. FRIEDMAN: I really can't say anything to address that because things are in process and I really can't say anything till it's on the street, you know?
MR. BLAIR: Okay.
MS. GILBERTSON: But the other side, Jeff, would be that I would expect -- and if this is a volunteer, then it's on the record -- that as part of the process, depending on what items are put forth for actual testing, that the different sectors, the people, the organizations that come forward -- and actually I don't know if you have to sign on a dotted line or exactly how you sign up to participate -- that we have something that's very clear to them that if they're testing something having to do with an NCPDP standard that they can use, you know, me as the contact person and we will get items identified and we will work through them.
If it's, you know, a list of items I need to bring back to the work group, we'll do that. I mean, we have process for bringing things forward anyway. It's just making sure that those who participate in the pilot know they have some place they can go.
MS. FRIEDMAN: I'd just like to draw on a couple
of things we can say at this point, and one is it will be competitive process, and people will have to submit proposals.
MS. GILBERTSON: It's competitive?
MS. FRIEDMAN: Will be a competitive process.
MS. GILBERTSON: I was hoping it would be open to anyone who wanted to participate.
MS. FRIEDMAN: There will be guidance in the document we will be issuing soon, I hope. It will all be tested in how you apply.
MR. BLAIR: Well, in a sense that's good because it does give CMS the opportunity to raise questions to make sure these structures are in place to address the issues that I've just raised, so I'll just leave it at that.
MR. REYNOLDS: Okay. Lynne, thank you very much, and we'll move on to our next presentation with Laura Topor and Tony Schueth who'll be presenting, and we'll have both of you go ahead and do your presentation and then we'll open it for questions. Laura?
AGENDA ITEM: Presentation -- LAURA TOPOR
MS. TOPOR: Thank you for having me here today and I apologize in advance if my voice goes.
Just to walk through, I want to give you an overview of some of the history of the SIG standard, what we've done, show you the structure that we've developed, the impact we think it'll have, and then talk through some of the next steps.
As many of you know, we've been working on this off and on throughout the industry. It resurfaces annually. It's been going on for over ten years.
The stakeholders have changed where now long-term care is a big player at the table on this. We're trying to involve the different hubs such as RxHub and SureScripts to make sure that we've got everybody at the table; the previous efforts with NCPDP, with HL7, with the Continuity of Care Record, as well as the work being done by Julie James in the U.K. trying to incorporate that.
We went into this with a couple of operating assumptions. One, the need to be flexible. It's interesting that Lynne brought up about the physicians in the 80/20 rule because then I got an email from one of the physicians saying, "Okay, but remember, we got rid of 80/20 and we're at 99 percent where we think what we've mapped out really will work for any form of a SIG based on what we know from prescribing today." And again, the different industry segments with inpatient and outpatient and with products that have transitioned that used to be delivered or administered only in an inpatient setting now being administered in an outpatient setting.
There's over a hundred people signed up on this
task group, and I would say out of that there's a core group of approximately 20 who have been very, very active in this, and pretty much everybody's at the table. We have the pharmacy providers, we have physicians, we have the knowledge vendors, payers, the e-solution organizations, people from the academic centers, other SDOs.
I'll take a moment to recognize Peter Kaufman of Continuity of Care Record, Alan Zuckerman at Georgetown, Rick Peters from AAFP, Rob McClure for a lot of the work that they've done because they're bringing that clinical practice piece into it, which is an area where NCPDP has not always had strong representation.
When we set out, we wanted to be sure that what we were doing would conform with existing e-prescribing standards but not duplicate any of their content, and I'll get into that a little bit more later; obviously take advantage of all of the industry experiences that we know of to date, and the existing work products so as to not reinvent the wheel.
And again, a key focus on developing something that was flexible, that would support interoperability with different systems -- again, inpatient, outpatient in a retail environment.
We really got going on this a little less than a year ago. NCPDP met mid-August last year in San Francisco,
and it was probably the end of September when we had our first conference call. Since then, we've had calls pretty much every other week. We've met four times face to face and we'll be meeting again in August in Philadelphia.
We've been working with organizations, other SDOs. We do have a format that is pretty solid right now, and I'll show you that, but we've mapped approximately 30 SIGs to this format to make sure that what we've come up with will work out in the real world.
We have a draft of an implementation guide and I did get confirmation about a week or so ago that what we are doing is in conformance with the current ASTM Continuity of Care Record.
Again, in terms of structure, making sure that this will fit with whatever work is being done with NCPDP SCRIPT, to make sure that it fits and that it's something HL7 can incorporate as well as the Continuity of Care Record.
Right now, we have this structured in segments, and the segments include dose, dose calculation, dose restriction, the vehicle, route, site, frequency, interval, administration time, duration, stop, indication and free text.
So, what I'll do is walk you through all of those segments in a little bit more detail. I won't go through
all of it -- you don't want to hear all of it.
[Laughter.]
MS. TOPOR: Lynne can attest to that. She's been on all the calls!
Within the dose segment, which will define a fixed dose, is a repeating segment. It will support something as a range.
At our discussions last month, we identified the need for a dose indicator which, from an implementation and programming perspective, it was felt as valuable to say, okay, do I even need to look at this field or can I just skip it because there's nothing in here and it's all somewhere else? So we put the indicator in.
We have a dose delivery method, so how is it delivered? Is it take, is it applied, is it injected? For every code field that we have, we have a code system and a code system version field so that we can identify, again from a programming and implementation perspective, what we're using.
We have a dose delivery method modifier. Again, working with the data that we had available to us of what's happening out there in the real world today, you know, apply repeatedly, apply to the affected area sparingly. So we pulled all of those.
We get into the dose unit's text, which is,
again, the milligram, the numbers. We have codes for that.
And sequence position allows if it's take one to two every four hours. The sequence position supports that, as does the range modifier.
The dose calculation segment has been a topic of much discussion. One of, I think, the struggles for this group has been focusing on the broader picture and looking at not just what happens when I walk out of the doctor's office and I go across the street to just, you know, neighborhood pharmacy XYZ but what happens in the long-term care setting? What happens if it's something that's, you know, administered or mixed at school, trying to incorporate all of those as well as inpatient? So, a lot of concern about whether or not the calculation segment was truly needed. I think we finally all agreed that there is a place for it, probably much more so on some of the more acute care settings than your basic "take two and call me in the morning" type of prescription.
So we have a lot of the same fields that you saw in the dose segment. The range modifiers -- we will have the ability to actually put in the calculation -- so, in the example I think it's 125 milligrams. There are 40 milligrams per kilogram per day and three doses will be able to do that as well as have a code to indicate milligrams per kilogram.
Moving along. The dose restriction segment -- again, this was a patient safety issue as well as what's commonly seen in prescribing today. You know, "don't take more than ten tablets in 24 hours" or "not to exceed this." So we did incorporate that, again, with the code, with text, with variables, to allow for the incorporation of that including a calculation inflation functionality.
The vehicle segment, another challenging one. Is it part of the SIG? Is it part of patient instructions or pharmacist instruction?
We did go back and forth on this one a fair amount. We had some pretty solid examples of "mix with applesauce" where applesauce would be your vehicle as opposed to "take with," which would be a different segment and part of the patient instructions.
So it's important to keep in mind that within the segments, pretty much everything is optional. We are working through defining the situations of when it would be used.
The route segment, hopefully self-explanatory. It's the route of administration and it is a repeating segment, so text code, sequence, all of those.
Site segment, similar to route in structure, simply, you know, "insert in left ear" or we did get pretty granular on some things, down to the right antecubital
vein. Really just went away from that because we figured the physician wouldn't know which vein the IV was in anyway, so --
[Laughter.]
MS. TOPOR: The administration timing segment incorporates a number of things. It's the actual timing, so if a date is specified, a time is specified, if it's morning or before meals, those components.
We've also incorporated in here the rate of administration, so if it -- I think my example is five milligrams per kilograms over two minutes, one gram IV push over five minutes, things like that. So we incorporated all of those in there to support, again, more of an inpatient acute care setting.
Frequency is events per unit of time. It's pretty straightforward.
Interval is time between events, so "take one every four hours."
The duration segment allows us to support when the prescriber specifies exactly how long you're supposed to take the product for -- so, "take for ten days," "take until gone," as well as a stop segment, which is just "take it and then stop." So we've incorporated those.
Indication segment is really the indication for use of the medication. Again, a lot of debate on some of
the items that you don't see in here, and I'll talk to those, but really we know that there are prescribers out there who are going to write something and it's going to say, "Take as needed," or, "Use as directed," and that's the only thing that we're going to get. So we needed a way to support that, or "Take as needed for insomnia," things like that, and we put all of that in.
And then specifically we maintained a free text segment, and we looked at when this would be used. There was a lot of discussion about existing free text fields available within SCRIPT or within HL7, so what we wanted to do was really narrow this down to say that this is the SIG free text.
If it's being used, here are the six situations where, you know, you tell us why you're using it, what's in it. Is it because the system cannot generate a structured SIG? Is it to capture what the prescriber ordered, which is important in a number of states based on existing state laws? Is it completely pulled together from the structured SIG? Is it pure free text?
And then the last two values that we're recommending is fulfillment instructions. Those are the instructions from the prescriber to the pharmacist but they aren't part of the SIG as it's viewed by the group. And then, the patient instructions. So, again, not necessarily part of the SIG of how to address or consume the medication and then how often, but by the way, do this.
So those are the pieces. And then the entire segment does repeat.
And then we picked the Prednisone example because everybody likes the Prednisone example, which is Prednisone 10 milligrams, and you've got it to take four tablets a day for three days, then three tablets a day for three days, then two, then one, and then stop.
And so what we've mapped out here shows you, again, we're only using the fields that are needed to transmit the SIG, so there's a dose indicator saying "yes, there's information in the segment; keep going."
The delivery method text, what the dose is, the unit -- in this particular case, we're using a SNOMED code set.
The sequence position, which tells you the first thing you're going to do is take four, then three, then two, then one.
The route, we used an HL7 code set as an example.
The interval is one day, and we've got that mapped out, the interval modifier to say "take one, then it'll be three a day, then it'll be two a day, then it'll be one a day."
The free text string is just the indicator and then what the actual script is, what was written, and then the repeating segment to show you the sequence of it.
So that's one of the 30-some examples that we've managed to map out so far.
In terms of what's next on our plate, it's finalizing the format. We think we're about 95 percent there on the format in the examples.
Our struggle right now is code set validation. What code sets are we going to select? How are they maintained? How are they distributed? And trying to come to some agreement on that and keeping focused on the work that's being done with RxNorm and a number of the other initiatives.
Once we can get through that last hurdle, finalize the implementation guide. There's been discussion among members of the group about doing a pilot and then sending this through the necessary balloting processes via HL7 and NCPDP SCRIPT with Work Group 11.
And then to figure out how we're going to launch this. At this point, it's still going to be voluntary within the industry. I know we've got some opportunities again with AAFP and some of the other trade associations that are out there to really get this out in front of the prescribers and their e-prescribing system centers as well as the pharmacies.
That's where we're at.
MR. REYNOLDS: Okay. When I first saw your presentation last night, I don't need to hear from Tony about Friday morning. You did a great job, both of you.
[Laughter.]
MR. REYNOLDS: Really, in all respect here, I didn't know how I was going to break that news to him.
[Laughter.]
MR. REYNOLDS: Tony, if you'd go ahead and proceed. Thank you very much.
AGENDA ITEM: Presentation -- TONY SCHUETH
MR. SCHUETH: Thank you. My name's Tony Schueth, and I'm the Managing Partner for Point-of-Care Partners and the task group leader for Prior Authorization Workflow to Standards Task Group.
I think the name of the organization, or the task group, is important, and it sends a message that we're not just looking at a single transaction. We're looking at prior authorization, from soup to nuts, to the point where plan determines status of a drug through to when the claim is adjudicated at the pharmacy. And so it's, you know, the entire process, and we've mapped that out and we've got different organizations working on it that bring different perspectives to the process.
My first slide that I want to present is a quote from one of our task group members recently, and I think this can't be stated enough, and that's why I put this as the first slide in this presentation. I've said this before to this group, to NCVHS, I've said it to the work group, and we're going to say it again: "This is not an attempt to usurp the coverage decisions of the plan, but it's an effort to streamline and standardize the mechanism for activity."
So everyone understands that that's the philosophy, that that's why we're working on this project, and we're all sort of in agreement. And every time, you know, we might get stuck, you know, we consistently bring that up, so it's a philosophy that permeates the whole process.
Again, the task group name is Workflow to Transactions. It was formed at the November 18th NCPDP work group meeting. I'm the task group leader. A gentleman by the name of Ajit Dhavle, who's here today in the audience, has been also very active in leading some of the latter sessions, and I'm going to talk to you guys exactly about what he's been doing in a minute.
Our objectives are to promote standardization, the standardized automated adjudication of prior authorization; coordinate the further development and alignment of standards, and identify additional needed standards.
We have about 40 people that are task group members, about half of which are active. We've got about 20 active folks.
And I think what's pertinent about this particular slide is how representative this group is of the industry. First of all, it's not just an NCPDP task group. It's a joint effort between NCPDP, HL7 and X12. So we have task group members that come from each of those organizations, in fact that are leaders of groups in the other organizations.
We have physicians, nurses, pharmacists. We have folks from managed care, from PBMs, pharmaceutical manufacturers. We've got retail pharmacies that are represented. We've got providers. We have about as representative a group that you could ever hope for, you know, with only 40 task group members, and even among the 20, it's a very, very representative group, and we're proud that those folks are very active.
We've had several meetings. I'm not going to go into a ton of detail about these meetings, but the point is that we've had, you know, basically one call a week for the last almost two months, two and a half to three months.
Where we are in the process I'm getting to in a minute. But the first thing I want to do is talk through the workflow.
Prior authorization really begins with the payer, the health plan and the PBM, who determines the prior authorization status, the criteria and the rules. And I think it's important that I sort of define what we mean by these because I think there's been, in the early days at least and maybe even a little bit further on, there was some confusion within the task group.
The criteria -- when we talk about criteria, we're talking about the questions that a plan asks relative to the request for prior authorization. When we talk about rules, what we're talking about really is the logic. It's the "if, than, and" kind of thing. And so the payer determines status, the criteria, and the rules.
Then what happens is that drugs can be flagged as requiring prior auth, and some very simple rules can be applied using the NCPDP formulary and benefit standard. Things like age restrictions or quantity restrictions can be accommodated in the formulary and benefit standard, which, you know, as Lynne just mentioned, is something that is going to be ready by the pilot.
And so, you know, one of the things that we might think about is that, you know, without even piloting -- I said is going to be ready by the pilots -- but also a standard that's been named or proposed as one of the foundation standards, so, you know, there is a piece of prior authorization that could actually be, you know, put out there today that doesn't even need to be piloted.
Lynne went into a lot of detail on what's in the formulary and benefit standard but there's a couple things related to prior auth that she might not have mentioned and I'd add. Things, for example, like I just said -- we've got status of prior authorization, we've got quantity limits, age limits. There's also the ability to tie information directly to the drug and to put, you know, a link, a hyperlink, to information.
So one of the things that many plans do is to have a website that has the prior authorization form. So what you could do is today, without even piloting this, is, if the regulations are written as such, it could go out and they could launch and they could request, you know, this form and fill out this information or they could get certain prior authorization information.
Sorry for the diversion but I thought that was an important point to bring up at this point.
Now, it happens when the patient visits the prescriber, the prescriber writes the prescription, and what happens is that they see that a drug requires prior authorization. And what they're going to do today, based on our last task group, is that they're probably going to request prior authorization from the plan, and the information that they're going to send in the request is going to be some basic information that they already have about the patient and about the drug.
Then what's going to happen -- and that turns into a 278, an X12 278 transaction, which is a HIPAA-named transaction.
That's transmitted to the payer, and based on this last task group, where we're at is the payer would then respond with the criteria, with the questions that they wanted answered relative to that request.
So there's a back and forth.
And then when it gets back to the physician side, they respond to those questions and then transmit this back to the payer, at which point the payer can operate whatever process that they have within their four walls, whether it's, you know, going to go to a committee, or whether, you know, there's an individual that can make a decision. They probably have rules; there's all kinds of different ways, and every payer is different.
But then they're going to respond, and they're going to do one of three things, really. They're going to ask for more information. They might deny the request if they have enough information to make that determination. Or they may request more information.
So this is sort of a back and forth.
MR. BLAIR: Tony, requesting more information you gave twice; I think there was a third thing that you wanted to give -- deny or approve.
MR. SCHUETH: Or approve. Thanks, Jeff. Thanks for the clarification.
And this back and forth comes in the form of an X12 275 with an HL7 PA attachment. So now we've identified, and we have standards within three standards development organizations, NCPDP, X12 and HL7.
So the next phase is let's assume now that it's been authorized, that they've approved the drug to be prescribed. What they'll do is they'll send an authorization number to the prescriber.
That number is transmitted then with the prescription electronically to the pharmacy in the form of an NCPDP SCRIPT. The pharmacy then includes that number with the claim that they submit to the payer, and the prescription can then be dispensed.
Now, there's one other piece of all this that I should mention, and that's that we already have a process where if a prior authorization is originated in the pharmacy, there can be a request and response transaction between the pharmacy and the payer. And that already exists today within telecommunications standards, so it already exists today and it's out there being in use today.
Okay, so with that as sort of the framework of what we're doing, so what decisions has the task group made?
Well, in the very beginning what we did, and in fact what Lynne had presented to NCVHS in the past -- I'm sorry if I switched some slides around a little bit -- what Lynne had presented in the past is that we have looked at six therapeutic categories and seven health plans and done some analysis. And what she showed you was sort of a spreadsheet, and on that spreadsheet she showed you that not each plan had the same criteria, the same questions for each drug, that there are differences between plans.
And we only looked at, like I just said, six different drugs and seven different plans. So the first decision that the task group made was that we needed to be more comprehensive. There was no way we could build a standard based on, you know, that small of a sample set.
So what we did was we decided that we would do more analysis. And we actually made a request, and at this point I'd like to acknowledge AHRQ, who helped us fund the consultant to do this analysis.
I'd also like to acknowledge MediMedia. What they did was they sort of mined their database and determined, you know, which plans had prior authorization in forms and then they went out and they gathered about 300 different forms from health plans and PBMs around the country.
We also put out a request for forms to be submitted to us, and organizations like BlueCross BlueShield of Tennessee and Caremark, they provided their forms as well.
So we ended up with about 350 forms, and Ajit led this process. And what we did was we analyzed this, and we decided that we wanted to complete this analysis as close to the plan intention as possible. We wanted to look at it by drug and therapeutic category, depending on the way that the plan did it. We wanted to record the decision tree, or the rules if the plan had put the rules on the document, and that happens. Sometimes those rules are kept within the organization and sometimes they're put on the form.
And we wanted to log information that was outside of the drug criteria questions that were on these forms as well.
Now, when we did the first analysis, we had a managed care consultant, someone who had been in managed care for 25-30 years, who was sort of between jobs. We had her do the analysis. And with her experience, she was able to sort of normalize. That was when we did the six therapeutic categories-seven plan analysis.
And now that we were doing the full analysis of the industry, we didn't feel like a consultant should normalize that data. We felt like we should do that as a task group. And so we decided to do that, but what we wanted to do was we wanted to make sure we had broad representation of sort of some of the right people, and so we've made a concerted effort to make sure that there were physicians, pharmacists, plans, folks from HL7 and folks from X12 that have been on each of these sort of task group calls where we've been normalizing data.
We also decided that we would just have one PA attachment versus using, you know, laboratory and different attachments that are already in the works, so we would have just one PA attachment.
And we decided the drug or therapeutic level criteria would be transmitted in response to the initial PA request as I sort of just described in the flow a second ago.
What have we accomplished?
We've drafted a PA attachment. We've drafted an HL7 attachment. But we're now waiting until we're through the normalization process just to sort of tweak it a little bit. We drafted it based on the first work that was done; now, you know, we'll update it based on the normalization we've been doing.
AHRQ has not only, you know, helped us fund the initial process but they're also helping us fund the normalization. It's just an awful lot of work, and what it's been able to do is just sort of keep the momentum going. AHRQ's help -- you know, we appreciate it so much. And Michael also has been on a couple of calls and sort of helped rally the troops a couple of times, so we really appreciate that as well.
[Laughter.]
MR. SCHUETH: It's a lot of work, and any time that somebody gets on there and says you're doing a great job, that helps.
As I said, we analyzed 350 forms, about 1700 questions from 53 PBMs or plans, and we've normalized data now in the following therapeutic categories: ED, anti-fungals, antihistamines, Cox-2s and PPIs.
So what's going to be ready for the pilots?
Well, first of all, as I mentioned before, pharmacy PAs can be submitted via NCPDP telecommunications, so that piece is alive and operational today.
And, of course as Lynne mentioned this morning, formulary and benefits is able to go today.
The 278 is in the process of being updated. In fact, comments close at the end of this month and there's a meeting next month, and so the 278 will be ready for pilot as well.
Now, the whole process of writing a prescription, transmitting it via NCPDP SCRIPT to the pharmacy -- I'm sorry; I dropped some text, but that being submitted as a claim to the pair, that's all existing and operational today as well.
The piece that will not be ready by January 1st but nevertheless, you know, could be added to a pilot process is the 275 -- well, the 275 would be available, but the HL7 attachment, we're probably on track for that not to be available until February of next year.
And so that's sort where we're at. And I'm going to get a timeline in a little bit that'll make that whole thing a little bit clearer.
Now, at this point what I'd like to mention is another thing that that the task group has brought up recently, and this is a new slide -- my apologies. We're going to redistribute. I added this slide last night.
This is the whole notion of -- actually, let me go back a step -- when the information is on the prescriber's desktop, you know, can we ask the questions and provide the criteria right then and there? Right after the doctor sees that a drug requires prior authorization, can they go and can they fill out a series of questions? I mean, can they do that in a structured, machine computable, and standardized way?
And the task group has struggled a little bit with that, and some folks that are part of the task group that are also active in HL7 are working with the HL7 clinical decision support group on an effort called GELLO. And there are some folks in the audience that if we get into a lot of detail about this, they can come up and sort of help me on this.
But GELLO is basically Guideline Expression Language, and then they added the "LO" to make it jiggle or something.
[Laughter.]
MR. SCHUETH: I've got to have a joke about that.
What GELLO does at a very high level is it does two things that are really powerful to prior authorization.
The first thing is it allows you to ask or present this criteria in a structured, computable way, okay?
But the second thing that it does is it allows queries within the electronic medical record to sort of answer this information so that the physician or his or her staff doesn't have to type in this information, you know, from scratch. Each of these questions type in the answer to it.
It allows some of this information to be pre-filled, and it also allows them to pull out things like labs and things like that, so pull that out of the electronic medical record and include that in the response, or the request for prior authorization.
So it allows this whole thing to be more streamlined. It's really an exciting project. We haven't spent a lot of time in the task group talking about this. There's a separate effort within HL7, and I'm going to talk a little bit more about that within the timeline here.
So the timeline. The PA attachment, as I mentioned, because this is within HL7, that it's expected to be, you know, adjudicated and balloted by January 8th, by the January 8th to January 11th meeting. So that wouldn't be ready by January 1st, but it certainly could be included as part of the pilot.
GELLO's further out. It is, it's further out. But now is the time to be thinking about it and now's the time to be talking about it and working on it.
The first thing that really needs to be done with GELLO is that we need to do some analysis, and specifically we need to look at the syntax within HL7 and if there are any gaps in the HL7 rim, you know, to see how that fits with prior authorization.
And before we can do that, we need to finish the state of normalization, so that whole process hasn't exactly started yet. We've sort of asked for funding for that, and that funding request, I think it's in the process of being drafted at this point, but there has been some, you know, sort of discussions about the possibility of that and it does seem to be possible.
The interfaces piece of it is further out, and it's going to take a lot more effort, because what the second part of this is is the part that I talked about where GELLO would go out and it would grab information from within the electronic medical record and it would pull that into their quest. That's a much more complex process and just a little bit further out.
X12, as I said, we're really making good progress with X12. The 278 will be ready. The 275, it's not going to be voted on until February of next year, but nevertheless it can be piloted, so they're comfortable with that piece of it. And of course formulary and benefits, Lynne's already talked about.
So what are the next steps?
We need to complete the data normalization for therapeutic categories. We need to put the data into the format that's required by HL7 for the attachment. We need to complete harmonization of NCPDP and the Medicaid group.
They are actively involved in this as well.
We need to update the 278, 275 work groups and move 275 to comment and ballot. Within HL7, we need to create a booklet and ballot that booklet.
Long-term care, I'm sorry I neglected to mention earlier, has been involved in this project, but they need to sort of determine the impact of prior authorization on them, on long-term care, and then sort of streamline those processes.
And we've been doing all this over the phone, unlike, I think, Laura's group who's met, I think she said, four times. We've done this all over the phone, and we may need a face-to-face meeting. It's something that we've talked about.
So one of the things that I think you guys wanted from us was sort of a problem list -- you know, what are our challenges right now?
We're having some challenges with drug allergy code sets -- you know, just which ones do we use, those kinds of things. There's lack of code sets for outcomes of previously failed therapy.
There's an inconsistent classification system for prior authorization. Some plans use therapeutic categories, others use drugs, still others use some sort of a generic form, and so we need to settle on something like that, and that's something that the task group is working through.
There needs to be consensus to encourage drug specific criteria versus general forms. So what happens right now is we're just not super excited about the generic forms because it can be very time consuming and not that efficient, so we're going to try to encourage more drug specific forms to be used.
There doesn't seem to be any industry consensus on therapeutic categories, so if you look at this from a therapeutic category standpoint, that's great, but (?) uses one set of therapeutic categories, (?) uses yet another. You know, there's no consensus on which one to use.
And there's insufficient standardization, structured way to present the criteria and the rules. That's what I was talking about relative to GELLO, so that's another sort of problem that we have.
Some of the issues that we need to resolve is, you know, what's going to be the home of the PA questions/criteria superset? And we need to put together a documentation implementation guide.
What processes will be used to keep the criteria updated? How will new questions and criteria be added?
Some plans might be comfortable with rules being presented in the clinical system, others might not. How do we facilitate this?
So these are all issues that the task group is working on.
What can HHS do to help?
Well, you know, one of the things -- and this may be being worked on; I think I've heard that it has been, to a degree -- but there needs to be some sort of central information code set repository. So as we're going through this normalization and we're saying, you know, gosh, where do we get code sets for this or where do we get code sets for that? If we could just go to that repository --
Because we don't want to recreate the wheel. We don't want to create code sets when they're already out there. But we're having a heck of a time even with folks that are actively involved in HL7 and X12. We're having a heck of a time sort of figuring out where these are.
And we think that the support of the GELLO development effort will also be valuable.
And that's sort of my presentation.
MR. REYNOLDS: Okay. Thanks to both of you. Excellent job again, and it's amazing what all of you are pulling off. So, open floor to questions. Simon?
DR. COHN: Well, Harry, I actually want to sort of second your comments about the progress being made and I want to extend my appreciation of the efforts.
Tony, actually I had a couple of questions for you. And obviously I think one is -- I guess I shouldn't be surprised, I know the Subcommittee has talked about decision support now at some time and we've looked at it from time to time. I guess we'd always sort of thought it would be relating to critical clinical drug interactions and things like that.
But I guess I shouldn't be surprised that it should maybe become more advanced in things that have to do with payment or prior authorization or whatever and that may be one of the first major sort of standardized interoperability use cases.
I do see you sort of glommed on GELLO and clearly, you know, I think we've all been sort of watching it. I mean, is your assessment that that is really the way to go, whether that's ready enough for prime time?
MR. SCHUETH: No, I wouldn't say it's ready for prime time.
What we would say is -- I guess we used the analogy, if you're going to build the bridge, you need to start with the girders, you know? So we think that, you know, now is the time to be working on it.
And when I talked about it, when I showed the timeline for it, you know, I showed the first piece that needs to be done and can be done yet this year is analysis of, you know, where it is and how prior authorization would fit into it.
And then the second piece would be a little bit longer term, and that's relative to the timeline for developing it and its interfaces, and that would extend on into the next year.
I wouldn't suggest that that should be part of pilots, but, you know, we do think, and the task group has talked about that as being, you know, one of the long-term solutions and a use case that works.
I would like to invite -- particularly when we get into some of these more detailed questions, and I'm sorry; I meant to acknowledge many of the task group members are actually here in the room today. We've got Ross Martin from Pfizer, who actually, you know, could go into a lot of detail about GELLO; Ajid, some others that are in the audience that we could bring up.
DR. COHN: I guess in the interest of time I'm not sure we want to go into great detail on GELLO. It may be a subject that the Subcommittee wants to delve into further in subsequent hearings.
I guess I was just trying to get a sense from you since you spent a lot of time at the end sort of talking about it. I wondered how ready it was, based on your timeline and all of this. And it sounds like you actually have an optimistic timeline, based on your last comments.
I guess the other piece I would is you identified a set of problems that had to do with inconsistent classification systems and things like that. I was uncertain in my own mind how much to relate that to the use of decision support versus just the actual existence of these attachments and use of doing prior authorization. Can you reflect on that? I mean, are these all barriers to even doing sort of non-decision support prior authorization or are those things that just would be nice if we had decision support as part of it?
MR. SCHUETH: That's a very good question. First, let me say that the notion of GELLO, of decision support, has not been widely vetted within the task group. It came up on the last task group conference call. It was presented as an option to help us address this challenge of displaying and presenting criteria in the workflow and in responding -- you know, it was presented at that time, and the task group got very excited about it but would agree with your assessment, Simon, that it's further off.
And I would comment also that the timeline -- it is optimistic, but it would be based on if it were possible to receive funding, okay?
DR. COHN: Okay.
MR. SCHUETH: Now, to your question about the code sets and does that apply, so the answer to that question about the code sets and does that supply to decision supporters, we had identified those as issues long before we started talking about decision support.
Now, certainly, you know, you could do an attachment, you know, with free text fields, but it would be optimal if we could have, you know, codes instead of free text fields.
DR. COHN: Thank you.
MR. REYNOLDS: Okay, Suzie?
MS. BURKE-BEBEE: You answered a couple of my questions, but one that I want to ask about your problem list, I see allergies is on it. Was there any discussion in the work group about contraindications or indications?
MR. SCHUETH: Yes, that was another challenge that we have.
MR. REYNOLDS: Jeffrey?
MR. BLAIR: Thank you. In a sense, my question is similar to Simon's because if there's any possibility of being able to include prior authorization or SIGs in the pilot test for next year, you know, it'd just be wonderful to be able to add that in.
In listening to your testimony, you know, it sounds like neither of you will be ready by January the 1st.
And then there's aspects and pieces that I'm hearing that are just a month away, two months away, or like GELLO, a year away.
You know, all of these things are attractive. Maybe we can't get GELLO in the pilot test, but I'm wondering if each of you are able to articulate some type of a vision where there's some aspect of SIGs, some aspects of prior authorization, that might be ready for implementation and testing two months, three months, six months after the July 1st, 2006, beginning of the pilot test.
I'm not sure that this is realistic, and I guess Maria maybe can't comment on it, but my thought is that if there's a whole year, then maybe there's a chance for some things to get phased in after some of the testing begins, so maybe we shouldn't preclude something from being part of the pilot test just because it's not ready on January 1st.
So, Tony and Laura, could you each comment as to whether you're able to visualize a date somewhat later in 2006 where it might be possible for the SIGs or the prior auths to be part of a pilot test?
MR. REYNOLDS: Could we hold your question? Maria has a comment on this and then I'll let you talk.
MS. FRIEDMAN: Just two quick comments. First of all, we would certainly invite -- these are the kinds of things people need to be thinking about, and if people apply would include them in their proposals. And of course there'd have to be specifics about how those might be addressed.
But the second thing is that we've had a lot of discussion here in the Subcommittee about a lot of things need to be pilot tested that couldn't be done in time for the MMA pilots in January, 2006, and there certainly needs to be a research agenda where these things need to be tried out, both in public and private sectors. But that's just a thought, because there are so many things that are emerging now, we can't do them all in January, 2006 -- there's no way.
But they certainly do need to be tested before they are ready for prime time and implementation, so I encourage people to think about those kinds of things and how we might address them and what other opportunities there might be for that.
MR. REYNOLDS: Okay. Peter, do you have any comments?
MS. FRIEDMAN: I think Mike wanted to go next.
MR. BLAIR: Could I ask --
MR. REYNOLDS: Wait a minute -- I held up there the answer to your question, Jeff --
MR. BLAIR: Yes.
MR. REYNOLDS: -- so Maria could comment. Let me let them answer and then --
MS. TOPOR: I think, based on, you know, Maria's comment about just what the industry is ready to absorb for January 1st, has been, you know, one of the key issues we've come across in -- you know, this is great, we think we can do it, but I can't do it by January 1st unless somebody tells me I have to do it by January 1st.
I would anticipate that if we can resolve some of the code set issues that we're struggling with and that Tony also clearly is struggling with, if we can get those resolved over the next few months, I would expect that, you know, towards the end of first quarter next year, possibly the beginning of second quarter, from the standard SIG perspective, we should be in good enough shape that we're ready to go to include in some of those pilot testings.
That's what I'm hoping for. I was actually hoping we'd be done a little sooner but as we delved into it, it grew, and there were too many questions and we didn't want to rush through and not deliver something that was going to be useful.
MR. SCHUETH: And my perspective is that there are things that can be pilot tested out the gate and then things that would have to be phased in over time.
Because it's workflow to transactions, we're talking about several pieces to this puzzle, and I think, you know, as I tried to represent, several of them are already, you know, operational, balloted, even considered as foundation standards -- the telecommunications piece, prior authorization between the pharmacy and the payer, formulary and benefits, SCRIPT, it's in telecommunications, and others.
There's a lot of this that's live and operational today. The HL7 PA attachment will not be ready by January 1st, but that could be phased in. And the whole idea of clinical decision support and criteria in the doctor's office won't be ready. It simply won't be ready. Analysis could be done, and it could be, you know, a subsequent pilot.
MR. REYNOLDS: Jeff, did you have a follow-up on the comment?
MR. BLAIR: No. Thank you. You've both answered my question. Thank you.
MR. REYNOLDS: Okay. Michael, and then Stan.
DR. FITZMAURICE: I guess I'll preface some of it here and then ask a question.
I agree with what Maria said, and if we look at how the pilot testing is worth -- we look in the world for things that have sharp edges and time barriers and timelines. I guess in an ideal world we would want to have some way to work with people who would propose in this competitive process that was mentioned how to do the pilot testing.
Imagine that you have to pull together an electronic health record or a prescribing software and get the links to prescribers, pharmacies, PBMs or health plans, the same kind of mapping you did, Tony, and then as new stuff comes along, you have to have a bank of programmers ready to insert modules into their software, and it's hard to do that on the fly.
When you have only a year to do pilot testing, it's really hard. You have to make the opportunity to do this, and that's more not so much a contract and pin down but being flexible, being open and willing to try to make this work and have as much value to the pilots as is possible.
So there's some responsibility and foresight needed on the part of the government, on the part of the industry, and some flexibility needed by the people who eventually will be doing the pilots and the evaluating of the pilots.
So I just wanted to say that the more flexible we can have that process and the resources available, if they would permit such a process, then I think we can put a lot into testing. It's not going to be easy.
It's not easy getting here, and I applaud the hard work of the committees who really tried to make these things fit together. But we've done hard work before, and so we can do hard work next year to get these pilots testing as much as we can.
And the MMA pilots end at the end of the year, but it may create an opportunity for the industry to continue testing things they think will work and will help save time and money. So it may be the start of a process, although we envision it as here's a year's window that we have to do the pilots. It may be something that can continue.
My question. Laura, when I looked through everything that you did on all of your pieces of paper, I'm looking at the code set for this, code set for that, code set for this, and I'm thinking, my gosh, that's a lot of code sets. I'm used to dealing with like their CPT 480s, but a lot of code sets and answers to the questions -- well, what runs through my mind is: Who should develop those codes?
The answer probably would be many of them are already developed that have many standards, so many code sets. Which one should be chosen? Who should maintain the codes and try to harmonize all of this? Who should pay for the maintenance and the help desk needed to answer questions when people come about trying to use the codes? Or when they have a new thing that would work well with the code set, you've got to go to some editorial board or some place that is working with the code set.
There is just a large number of code sets. And I saw code sets in what you have, too, Tony. Is there any thinking about should there be an organization and institute, an existing SDO, should it be one of the major code set maintainers out there and give that person or that organization more work to do?
It's got to be more a matter of what does the industry want and what does the industry trust rather than the government solves the problem. But with all those code sets, I don't know what the solution is. Can you help me out on that?
MS. TOPOR: No, because I was hoping you were going to tell us what to do.
[Laughter.]
MS. TOPOR: And that has become the biggest challenge that we're facing right now.
The struggle is there are a number of code sets that exist. For SIG, SNOMED, probably we'll get 95 percent of the way of where we need to be, and they've indicated their willingness to go ahead and just create any new codes that we might need. So their support has been invaluable.
Where we're struggling is, is that the path that we think we should go down, is that the path we want to go down, of designating one code set or code system for every field that we have out there with a code? Do we want to look at maintaining the flexibility to say, you know, NCPDP has codes that'll work in this field and HL7 has codes and SNOMED has codes, so here's your code qualifier. And if you're going to pick SNOMED, you, you know, code it this way; if you're going to -- and that's what I think our current struggle is, and then, again, trying to incorporate, you know, a lot of the discussion that Lynne talked about with RxNorm.
You know, I was a part of that call, but because product isn't part of SIG, you know, that piece was pulled out. So right now I think that is our biggest struggle, to find something that works domestically and internationally that everybody can accept and can implement, and we don't know yet if it's one system or if we're going to need to incorporate the flexibility to support multiple code systems.
DR. FITZMAURICE: So it still remains a problem, yes?
MS. TOPOR: Mmh-hmm. I've got a call tomorrow afternoon, if anybody wants to join in and help solve.
DR. FITZMAURICE: I also want to make a comment
on GELLO. I'm used to seeing (?) evolved into GELLO to put this, then this, statement for clinical decision support, and I agree with what Tony said.
It looks like a natural pathway for GELLO, and I've also talked to Ross Martin about this, that if you can have these statements put into a common framework and if the industry takes it and uses it for prior authorization, then you've got a framework that everyone understands, and it could make the pathway easier for clinical decision support because the framework is already out there.
I don't think we know at this point. I don't see GELLO in production anywhere, as Simon brought up, but I think it's worth trying to see if it can fit and to see what molding has to be done, just like we're molding with some of these other -- I think it's an opportunity to support testing this out.
MR. SCHUETH: And, Harry, I want to clarify one thing that I said a second ago. I said that what will be ready and what won't be ready.
What won't be -- GELLO won't be ready to be pilot tested by January 1st. But that doesn't mean that presentation of criteria as part of the process couldn't be tested. That could possibly be tested.
So it's GELLO that won't be tested, and the task group, you know, thought that GELLO might be a solution.
But again, it wasn't fully vetted through the entire -- on the call was, you know, a subset of the task group; it wasn't fully vetted through all this.
So, you know, Maria, you may receive a proposal where somebody says, look, you know, I don't need to do GELLO where I can, you know, actually put these criteria in the doctor's office so that at least they can, you know, take a step to making that request.
So there may be something -- you know, I just wanted to clarify that. GELLO won't be ready, but it doesn't mean that the criteria couldn't be presented.
MR. REYNOLDS: Stan, you have a question?
DR. HUFF: So, I wanted to ask you for a clarification on one statement, make sure I understood, and then make a comment.
I think you said sometimes the rules are not placed on the form. My understanding of that basically was that the benefit providers are not making public their rule for this pre-authorization. Did I understand that correctly?
MR. SCHUETH: Based on our analysis of 350 forms, that's correct. Some of them do and some of them don't.
DR. HUFF: I guess the thing that came to mind -- I mean, that, from the provider's perspective, is maybe where some of the frustration is, and it's the opposite side of the coin.
So, recognize in your first statement, you know, that this isn't an attempt to usurp the coverage of the decision makers. I think, you know, the provider side of that would say, yes, but we need transparency. I mean, this can't be the sort of thing where somebody in the back room is watching this month's receipts and says, oh, we need to change our rule -- or if they do need to change the rule, they need to do that transparently so that it's obvious to the provider because, I mean, that's the heart of the suspicion the providers have about this process from the start, that what we're going to do is make you jump through hoops just to prevent you from knowing how this can be done and, you know, and so this kind of obscurity of what the real rule is doesn't help or play to really clarify that issue, so -- but that's interesting.
MR. REYNOLDS: Simon?
DR. COHN: Yes, and Stan, I think you do bring up a good issue. I'm actually sort of reminded that of course we don't have Clem McDonald here in yet -- he won't be here till this afternoon -- because I think early on he made some similar observations.
Certainly, I have no idea whether it's intentional or unintentional, but obviously the question will get called as we sort of move into these areas.
I guess there was really sort of one comment, and I guess I may have forgotten my question at this point -- or actually really I think it's two comments.
One is that, just as a sort of a comment to the Subcommittee itself, Mike, I think, made allusions to the issues, the fact that MMA is one pilot in one specific set of time, and it may be worthy for us to consider whether there's any advice that we may need to give the Secretary or the Administrator of CMS about the recognition that there may need to be some sort of ongoing pilots in this area.
The other piece, of course, is that what you're doing may be of enough value to the industry that the industry may just in and of itself decide to do pilots, because clearly automation of the things we're talking about may have such major business cases that people will just go out and start doing them anyway, and those are things that we need to consider.
Now, the other piece, and I've just been hearing this now from both Laura and Tony, and there's a bullet here, I think, Tony, in your slide where it says: What can HHS do to help? And it says "central information code set repository." And I think I've heard that from both of you. I'm actually sorry that NLM isn't here today, this morning, to in any way address that because it's something we should talk to them about. Certainly, I think our --
MR. BLAIR: Vivian Auld will be here later.
DR. COHN: What?
MR. BLAIR: Vivian Auld from NLM will be here later.
DR. COHN: Well, that's right. There may be something we really want to talk to her about. Certainly, I think all of our views are that people should not be at this point going out and making it up on their own, if at all possible.
Certainly, I think we would all observe that there are things like the consolidated health care informatics data code sets and all of that. There have been pronouncements by the Secretary of various code sets that are sort of national standard code sets.
And so, you know, on the one hand I would hate to see in every field that you have you say "SNOMED" and that's all, you know, knowing that SNOMED has hundreds of thousands of terms. One would hope you'd get a little more specific than that. But I would say certainly it would be helpful if one started looking at code sets that had been out there and identified as national standard and then only if those don't meet the needs, then you need to extend. Just a comment.
MR. REYNOLDS: Lynne?
MS. GILBERTSON: One of the things that has come up in multiple task group calls is the SDOs don't want to be code set maintainers. And I hope I'm not misrepresenting anyone, but we've had representation from X12, from HL7 on different calls and they said that's really not the business they're in, and especially when you get into the distribution and things like that. It's one thing to have a list in your data dictionary, but it's another to be a code set maintainer.
And part of the problem we've had, too, is, you know, scanning the Internet, Googling, trying to find who might have code sets of things, just trying to figure out: Has anybody touched this area before, you know? And asking the representation on the task group list: Does anybody know of anyone who's playing in this space? Because we don't want to go out and reinvent the wheel, but to get something out to press, we may have to, and that's kind of a shame, that, you know, are we the first group to have thought about that or are we the only ones who have to get something done, you know?
[Laughter.]
MS. GILBERTSON: I mean, I don't mean that negatively, but, you know, if you're going to try to get something out there, where is it coming from? You know, we've gone ISO, we've gone ANSI, we've gone different places like that looking as well.
MR. REYNOLDS: Jeff had a comment on code sets.
MR. BLAIR: Laura, you had indicated that you have a lot of frustration with the code sets, not having an answer for that? But then you also wound up saying -- I thought I heard you say -- that SNOMED has agreed to address 95 percent of the code set needs that you've raised. And I'm trying to reconcile the two statements.
MS. TOPOR: Let me see if I can clarify. What SNOMED has will -- for the fields that we have identified where we want codes, SNOMED has a code for almost everything, or will create the codes or the variances that we're looking for.
What the struggle is -- to Simon's point -- do we want to put something out there where the only code system option for implementation of the SIG standard is SNOMED? And until this is named as a mandated standard, I'm concerned about barriers to adoption where, you know, when you look at the players on this from a prescriber perspective, depending on the size of the group practice, a lot of them already are using SNOMED; it's already embedded in our legacy systems or in the systems that we're implementing.
From the pharmacy perspective and, you know, as the recipient, they're not using SNOMED. They don't see it now. They probably never heard of it, which I know I hadn't till I started this project.
So it's really just trying to find the balance to say: What can we do to make the voluntary implementation of this the most successful and widespread?
MR. BLAIR: Let me ask for a clarification.
Since the Secretary of Health and Human Services announced I guess it was in May, 2004, the CHI standards that Simon just referred to, consolidated health informatics initiative for DOD and VA and HHS, kind of as an example to the rest of the industry and SNOMED CT was identified as one of the core terminologies, that may be as far as the Federal government may be willing to go, because mandates might not be what you need.
Did you really mean mandates, or did you just mean Federal government recognition? Because there is Federal government recognition for SNOMED and LOINC and RxNorm -- well, I'm not sure whether RxNorm is in there yet; I think it is. Because if mandates is what's needed, then that may not be on the horizon.
MS. TOPOR: Quite honestly, I don't know if we need a mandate or if we need more widespread acknowledgment of that recognition. And again, the potential barrier is from the pharmacy community because, I mean, they don't really deal with a lot of code sets today from the, quote/unquote, "medical perspective." They're not doing a whole lot with CPT codes. They're not dealing with some, they don't see those things.
So that's where I think there's still work to be done and whether it's an educational campaign or I'm not quite sure what we need to do to say: You know what, pharmacies? There is just not going to be an NCPDP code set for this -- which is what you know and love and are used to, but here's the code set, here's the source -- you know.
I think the costs associated with access to the SNOMED database are relatively reasonable but I'm not a solo practitioner in a rural pharmacy on the Iron Range in Minnesota so I don't know if that cost is cost prohibitive or not.
But those are just a couple of the issues we're still struggling through.
MR. REYNOLDS: We have a comment from Stan and then one from Maria and then we'll take a break.
DR. HUFF: So I need to preface this with I have a potential conflict with HL7 because I am a co-chair of the vocabulary technical committee of HL7, but just a couple of things.
One is SNOMED has the codes, and one of the common issues has been, though, that you have the codes but they're not a recognizable subset so they don't have a name collection that corresponds exactly to this set of -- so you get the idea, for instance, if you were talking about methods of birth control, you know, you could have some of those things that are behavior, some that are medications, some that are barrier methods, abstinence, and those things are scattered different places in SNOMED and there may not be a name collection that meets the need of this specific field.
And so it's more than just saying there's a code that exists for this. You have to know the exact subset. And there's been a lot of work that goes on there.
The second thing. SNOMED has been recognized, and we have the license within the U.S. The organizations that are dealing with this oftentimes are international, and the SNOMED approach for funding is not clear for Canada, for Australia, for other countries, and so when you start talking about these things within the SDOs, it becomes problematic that SNOMED in fact is not free for use worldwide, and that becomes a barrier to adopting that as a solution internationally.
And the U.S. can be separated from that, but the international issues come into it because HL7 is international, ASTM is international, and so that, you know, presents some problems there.
Third is I agree we should talk very specifically with the National Library of Medicine but again, from my position as one of the co-chairs of HL7 vocabulary technical committee, we currently have a contract, HL7 has a contract, with NLM. One of the parts of that contract is in fact to investigate whether the NLM could in fact be the distributor of these code sets, value sets.
One of the reasons for that is in fact that we recognize that it's ultimately going to be a combination of LOINC codes and SNOMED codes and other things, and what you'd like to do is in fact have a sort of a one-stop-shopping thing where I could go to this place and get everything that I need to implement, you know, my EMR or my NCPDP interfaces or whatever.
And so I think it needs to be bigger than SNOMED or LOINC or something else, and you want something in fact that you can bank on in the long run and is not susceptible to company or even a volunteer organization's viability. These are now becoming important enough for the infrastructure that I think we need some really permanent, well-funded -- it may be private, but if it is, it needs to be well understood exactly how that happens and how that's going to be viable for not just the next five years or ten years but for the next 50 or a hundred years.
And so I really think there's an argument about why this should become a government institutional place, but certainly we want to understand how that's funded and how it's regulated or governed.
MR. REYNOLDS: And Maria passes on her comment, but thanks, Stan.
We purposely let this questioning go over a little bit because with this much data in this important a subject, let's go on a break and then come back and try to pick it back up.
So, thanks to all of you -- excellent job. And we'll take a 15-minute break. Thank you.
(Brief recess.)
MR. REYNOLDS: Could we go ahead and get started please?
Okay, let's get started on the second part of our morning session, and we're going to get an update on HL7 and NCPDP SCRIPT harmonization from Ross Martin, a familiar face to the Committee, and Lynne Gilbertson. So, Ross, if you'd -- thanks very much.
AGENDA ITEM: Presentation -- DR. ROSS D. MARTIN
DR. MARTIN: And Jim McCain was just here who's representing HL7, and he stepped out for a second, but if you see him wander back in, please tell him to pop over this way, too, because he may have some comment.
MS. GILBERTSON: Come to the front of the room!
DR. MARTIN: Jim, if you could join us for a second, that'd be great. Good. Jim McCain.
My name is Ross Martin. I'm a Director of Business Technology at Pfizer and also a Member of the Board of Trustees of the National Council for Prescription Drug Programs, and I'm going to be presenting a third update to the Committee on the NCPDP-HL7 Electronic Prescribing Coordination Project.
I'm happy to be doing this. I'm grateful, again, for your real impetus in making this happen. You were the ones who said, well, by golly, you guys should get together and do this, and it sort of put the fire under us to get working on this in a more concerted effort. So, thank you again for your encouragement and continued support.
Just a comment about the slide, the opening slide, here. Maybe you're wondering why this thing is in purple. Well, blue is the color of NCPDP and red is the color of HL7, and so we figured for the Coordination Project our, quote, "logo" would be the combination, which is purple.
MR. BLAIR: How politically correct!
DR. MARTIN: Yes. So Barney had nothing to do with it.
[Laughter.]
DR. MARTIN: So the summary of the prior update that I gave to you back -- I think it was in December of 2004 -- was that we began this Coordination Project last year, last summer. We had long recognized this need, but really hadn't developed it as a process yet, and met back in I think July, just before one of the NCVHS hearings, because we were all in the area.
From there, we started with just 16 participants and grew to a group of about 54 that are currently participating at the Yahoo! group's site with a, you know, subset of that that are actively participating in the calls, in the process. And I'll get into that in much greater detail.
I think in our last hearing, at the last hearing where we testified, we were saying that we were going to be doing a demo, a demonstration of the mapping process, and since that time we've completed that, and I'll get into that in a bit, and then just talking a little bit about where we're trying to go from here.
So, you may recall this slide from our original presentation. These were the 16 people from the different organizations that participated, including three of us who were designated liaisons between NCPDP and HL7. That would include Jim McCain, myself and Karen Eckert. And so we had fairly good distribution of folk from NCPDP and HL7 at that first meeting.
From there, we had pretty active involvement, as of December, of a larger group of folk, and then, again from there, we now, as I mentioned, have 54 people who have subscribed at some level to the Yahoo! groups, maybe just to monitor it to make sure that they can see what the documentation is going forward.
But we established a regular call schedule that actually involved two calls per week for many months. One call was for an hour, one for two hours. And that involved -- what we found was, in order to really make the project work, we had to have a certain subset of those people who were from both HL7 and NCPDP who were considered essential mappers, if you will, and if they weren't on the call, if we didn't have a subset from both HL7 and NCPDP represented, we had to not have the call.
We went through a couple of personnel changes in terms of the overall administration and project management of this, eventually settling on someone from now Accenture, previously from -- they came on behalf of Café Rx and now from Accenture, and that's Kevin Deysenroth, and I will get into it a little bit more about what his role and the support that he provided for us.
But you can see the asterisks next to the names were indications of people who were very critical to the mapping, the day-to-day mapping, of the activities.
And, by golly, I forgot to empty that box out, and if I could ask Shelley Spiro, just over to your left, that's a box against the wall that has copies of the actual mapping document that I would like to distribute to the people around this table. If you're a NCPDP or HL7 member, you may have a copy of it as well. If you are neither, we ask you not to take a copy at this time because this is a draft document that is considered at this point a non-published proprietary document. But we did want to make it available to the Subcommittee and staff because it's important, I think, just for you to kind of get a sense of what we're talking about here in terms of a work product.
MR. REYNOLDS: Process check. Marjorie or Simon?
If it's a non-published proprietary document that's about to be handed to us, that I believe --
DR. MARTIN: Are you obligated to post it?
MR. REYNOLDS: I believe -- does that change it to a -- you might want to hold passing them out for a second. I don't want to -- in other words, if you've got members of the Committee, they're a group that may not see it. If we see it, I'm not sure -- I need some help.
MS. GREENBERG: I'd probably prefer not to -- I mean, when you said proprietary, is it because it's pre-decisional?
DR. MARTIN: It's because it hasn't been balloted, it hasn't gone through that process. And also, because of the nature of how we publish standards, they are technically owned by the standards -- they're copyright by the standards organization. And in the case of both NCPDP and HL7, one of the ways that they make money as an organization, as a nonprofit organization to sustain themselves, is through the publication of their standards.
So it's a benefit of membership. We make them available to participants of the standards process, of this mapping process, whether they were members or not, if they were considered to be an expert that needed to be involved. I think in every instance pretty much everybody was a member of one or the other.
So if that's an issue -- if you could just --
MS. GREENBERG: If this is something that would be helpful to the Subcommittee to see to understand what your process is -- I mean, I think in that case, it can be given to the members and the staff, and we would not distribute it elsewhere.
But I guess ultimately someone could make a Freedom of Information request, probably, because there are exemptions to those requests because of proprietary materials -- I mean, I think rather than saying no, you can't look at it, because I think you may need to to advance your work, then I guess we'll proceed that way.
DR. MARTIN: I just want to be clear. This is not like these are trade secrets or something or, you know, nobody -- three people in the world can even read this thing, but --
[Laughter.]
DR. MARTIN: I think the point in even showing it to you is this is a double-sided document of 130 pages -- well, 65 pages, double-sided, so it's 130 pages of text -- and it didn't exist before this mapping process began, and now this is, again, in draft form, but every word in that pretty much had to be written or drawn from existing documentation modified to talk about how these two different standards talk to each other.
MR. REYNOLDS: Ross, I just didn't want you to get caught! [Laughs.]
MS. GREENBERG: If anyone has insomnia --
MR. REYNOLDS: I wanted to make sure -- we didn't want to put you on a billboard on the highway. [Laughs.]
DR. MARTIN: This is more being central to the SDOs that, you know, own this product and so -- thank you so much for working through that with me.
We did feel like it was important for the Subcommittee to understand a couple of things about this. We've already heard about the volunteer efforts of the participants in these projects. I think this one is
particularly special because nobody's going to make money off this one. There is no revenue stream. Maybe, I guess maybe SureScripts, because it's a transaction, they can make a quarter off of, you know, every time somebody sends one of these, but even if it's massively implemented, this will be a very small subset of the overall e-prescribing traffic.
But it was recognized as a critical part of the safety path, of miscommunication that happens today. And so, for example, Kevin Deysenroth from Accenture, he was mentioning on a call the other day -- and this is just one example of many -- where -- he's a consultant, you know, a big consulting firm; he earns his keep by billable hours. And this project, which he was part of project managing, he was not a subject matter expert. He was facilitating the process. He was the one manning the Web-x and the phone calls and making sure that all the Minutes got pulled out and all that stuff.
And he basically had to kind of put this one under the radar. And all of us were in that situation where this is not a project for anyone to do for a business reason directly. It's more it was the right thing to do.
So I think especially the people who dedicated an inordinate amounts of time -- I also want to point out in particular the woman to my right, Lynne Gilbertson, because when we didn't have funding for a documentarian, someone to write the guideline, the guidance document, Lynne stepped in and served as primary author. And I know that while that's part of her function as staff, we all know that if you start adding up the hours of calls that she's on, and if you'll notice that her voice is hoarse, I don't think it's because she's been screaming at a football game or something. It's because she's working tirelessly. And if there is some, you know, medal of honor that can go to the unsung heroes of the world that you guys can recommend, I would suggest that we nominate her.
So, getting back to the slides, we did do two demonstration projects in 2005, in February and March, one at HIMSS, the Health Information and Management Systems Society, conference in Dallas, Texas. It was part of the HL7 demonstration group. And one at the NCPDP annual conference in Phoenix that was actually sponsored by Pfizer and supported by both HL7 and NCPDP.
The demo participants, these were the ones that actually, you know, paid the fees to show their stuff at the conference or were part of the collaboration to do this. The Cleveland Clinic and Epic systems, HealthSoft Applications, InterSystems Corporation, NDCHealth, NextGen, Healthcare Information Systems, RxHub and SureScripts all participated in those booths in a very active way, had to spend time demonstrating this to anybody who walked by.
The scenarios that we primarily focused on were ones involving the scenario where medication orders were being created for a discharged patient from a hospital setting or an emergency room, for example. And that prescription, instead of being sent to the inpatient pharmacy where it would normally be sent through their computerized physician order entry system, was being sent to a retail pharmacy.
And that's the fundamental use case of this mapping project. You have to be able to talk HL7 in your own internal context and then transfer that to a retail or community pharmacy environment where SCRIPT is the dominant player, if you will.
But this could also be related to an electronic medical record product that uses HL7 for their e-prescribing tool and wants to do the same thing. It also would be in the ambulatory space where an electronic prescribing tool that normally speaks SCRIPT has to send something to a specialty pharmacy, for example, at a hospital, maybe for an oncology drug or something like that, but they would have to be able to talk in the other direction.
We also did medication histories that went from the pharmacy benefit management claims history database using SCRIPT, and that's actually no longer soon to be balloted SCRIPT, but it's been balloted, and translated into an HL7 message.
One of the vendors presented the use of a smart card to be able to deliver that medication history to an e-prescribing tool, to a physician in an ambulatory setting.
So this next graphic just shows the overall demo scenario, and it shows the players and the transactions that were demonstrated using these different systems.
So, one could go around the booth and kind of watch this information move. Normally, this is the kind of stuff that is so behind the scenes that you really never get to see it in action because it's very transparent to users; in fact, most of them would never know that there's any translation going on, no concept of that.
This is just a picture of the HL7 demonstration booth, and again it was part of a larger -- there were many other sponsors and participants in the demonstration booth there at HIMSS for the HL7 booth, but this was sort of the primary role in that and we also had live theater events at that where, you know, different individuals would get up and present at that.
And here's a photograph of the actual HL7/NCPDP booth at NCPDP, at the annual conference, which is a much smaller exhibit hall. HIMSS is a vast thing. So this got actually I would say probably more focused traffic at NCPDP than at HIMSS.
So in terms of a timeline of where we're going with this, we completed these two demonstration projects. We've now completed our work on the mapping document that you have in your hands now. This has been distributed to stakeholders at HL7 and at NCPDP. They're currently reviewing it, and any comments we would receive back, we will, quote, adjudicate at the task group level in August.
And then, if things go well and there aren't a lot of things that we have to fix and there's not a lot of controversy there -- I'm imagining that most things will be process oriented or typos and that sort of thing -- we will release this in September, hopefully, September 1st.
And then it'll go through the publishing process of the individual standards organizations, and I'm assuming that the general thing will be if you access the HL7 pharmacy stuff, you can get a copy of the mapping document along with that. If you access the NCPDP SCRIPT standard, you can get a copy of the mapping document from that direction. So you don't have to join both organizations or buy it from both organizations to license this tool, or this mapping guidance.
And another just point is that it is guidance; it's not a standard, because it's mapping to things that are implemented in different ways. Especially on the HL7 Version 2 side, there's a thousand ways to implement that, as this Subcommittee has heard on many different occasions about the general delivery of standards in the marketplace.
As you know, as you know well, pilots begin in 2006, so we're anxious to find out what CMS does have to say about the role of this mapping project in those pilots. We think that it's ready for that environment. We think, in fact, that's an essential part of this process because in theory we have the theory on paper now, and this is based on prior work from a number of stakeholders, including Cleveland Clinic and Epic and NDC and RxHub.
There's a lot more to prove. There's a lot more to prove that this can work in many multiple settings, and I'll get into that in a bit.
I've already mentioned that there were lots of individuals that contributed to this. We tried to do some sense of how big of a bread basket was this, and with the conference calls, consistently we had about a dozen people on those calls. You know, thousands of hours that happened off the books when we weren't in a call, when people were doing the homework that they were given between that call and the next call.
The demonstrations, everybody had to contribute, you know, had to sign up to participate in those demonstrations and pay registration fees and, you know, just the participation of that involved many, many hours.
So a very conservative estimate of the billable hours, and I really think that this doesn't account for the true capturing of the costs, is about $300,000 so far that corporations have basically donated to this process, and individuals.
So we wanted to share with you some of the lessons that we've learned in this process and things that not only apply to this project but perhaps other standards development -- especially standards harmonization processes -- and I think we shared this already in past testimony, that as hard as it is to get volunteers for single standard organization-directed projects, when you're trying to harmonize two things where they don't talk each other's languages too well, the reason that we didn't go to Version 3 in HL7 in the first place was because that was a whole another paradigm to understand and grasp and we weren't prepared to go there, so we really started with a Version 2 which I think will help in future efforts should we go down that next path.
There is a need for ongoing support for project coordination. We could not do this without somebody that's not a subject matter expert but just make sure that the calls get made, that the schedules get done, the Minutes get put out, the process continues. You know, you make sure that the right people are going to be there, all those -- I'm grateful that there are people in this world who really love to do that kind of work.
[Laughter.]
DR. MARTIN: It's like I'm so glad that my accountant loves when numbers come out right because I could never stand having to do that for a living. There are things that I do that I'm sure other people, it would drive them mad as well.
But, thankfully, there are people who like to do this. They need to be paid to do that, because there is no business rationale for somebody to do that work other than to make this thing get done.
Use cases are helping to drive this process, and so it was very helpful to have a stated goal about what thing in the marketplace were we trying to do? And market readiness, like this is the next thing that we need to accomplish -- okay, we've already gotten these basic things done, the 80/20 rule; now let's go to 85, let's go to 90 percent, let's capture those last pieces of challenge.
So that helps bring resources to the table because the more the market is ready, the more individuals and corporations and willing, you know, organizations, entities, are willing to bring those resources to bear on these projects.
I think the pilots, as I mentioned before, are critical for confirming the real world utility of the mapping documentation. We don't know what we don't know until we test it in non-controlled settings where things -- you know, real life happens, and new problems are encountered. And that helps us articulate the refinements that have to go into future versions of this.
Again, I mentioned this a little bit earlier, but the document that you have is only guidance. Every pathway to success will be different for every implementation because there is so much variability in how these things are implemented.
As it's been mentioned already earlier today on the two prior projects that we've received testimony about, vocabulary issues remain a challenge. We literally dodged some of the issues related to vocabulary in this project because there wasn't a way to resolve some of these things.
And I think some of the suggestions that you've already received are good ones about the need for a real coordinated process where the work of the standards developers is made easier because there's a place that they can go, and expertise like a librarian that knows how to guide them through the process of finding the right vocabulary -- a mechanism for people who don't own a vocabulary to make additions and modifications to that vocabulary or code set so that if the existing code set accommodates 90 percent of their needs but a couple things need to be added to accommodate 100 percent, that can happen without having to own it, having to maintain the process for changing it, but being able to inform that change will be very important.
This is critical for semantic interoperability, and I think I'm preaching to the choir on this issue, so I won't go further, but we welcome that opportunity. And I think the RFPs that have come out from ONCHIT in these last couple of months, early June, about standards harmonization, I think -- at least my personal read on those is that could be a real forum for this to happen and a mechanism for us to make this a normal process where anybody who owns the vocabulary, wherever it lives, there's a standard developer and a standard developer process for working with those together.
The fact that we don't have an unambiguous patient identifier -- we've seen the Cleveland Clinic Foundation commented on the call when we were discussing what we wanted to present -- there are challenges with maintaining accurate communications between prescribers and prescribing entities and dispensing entities, pharmacies, because there's not a necessarily natural place to keep the medical record identifiers that are native to the prescriber's environment where they're not native to the pharmacy environment.
They identify those patients in different ways, and because the payer information, their member information, changes, a lot of the identifiers change, those are some challenges with that, and so there's a need -- they talked about the need to have a retain and return policy, so if you get an identifier from an entity that's specific to that entity, like a medical record number and even a prescription number, that that be maintained with the original prescription in the pharmacy system so that if they ask for a refill or they ask a question, they can always send that information back.
And there are similar challenges for the provider identification and perhaps a national provider identifier and the enumeration process with that will help with that, but because these providers can change locations and contexts and things, that remains a bit of a challenge.
Some of the things that we're considering for future efforts include having a common process for reporting -- and again, these are more global lessons learned about what can be gained from this project for other harmonization projects. How are we going to report this? And the RFP around standards harmonization, maybe that's a place where we would do this regular reporting, kind of like we do it at a certain level at ANSI HISB today -- the Health Informatics Standards Board. Perhaps there's a place for this in this new entity that may emerge from those RFPs.
Places for shared work spaces -- I think we have this common process that we see over and over, and that relates back to vocabulary and code sets. And some of the tools that we're seeing emerge from projects like from the National Cancer Institute that actually have been very helpful in finding and identifying potential solutions, the more that those things can be fleshed out, those tools can be fleshed out and made available to standards developers will be very helpful.
Again, the project management that I've mentioned.
Meeting support -- that there's maybe a notion that said if there's an SDO-to-SDO harmonization process, there's a natural need for live meetings for coordinated, you know, web conferences and that sort of thing. Everyone agreed on our lessons learned call that having more live meetings would have made this whole thing go a whole lot faster, and if there's truly a sense of urgency being built around these things, the support for live meetings, to get people there, to get the experts that maybe don't have the natural support from a corporate or other organization sponsor to be able to show up at these would be very helpful.
I mentioned already the potential role for the future recipient of the standards harmonization RFP grant.
Then there's this whole question -- maybe, Jim, you could articulate or speak on this just a little bit more -- about this notion of a common model, a common information model, for the standards harmonization process in the future.
One example would be using HL7-RIM as the thing that we all kind of build toward and then look at that and make sure that the RIM is accommodating all of the standards development organization efforts without having to be subsumed necessarily by HL7 itself. I don't know if you want to make any additional comments right now about that or anything else so far.
I wanted to spend just a couple minutes talking about just the recommendations for pilots for 2006, and I know we're expecting these at any point, but we do hope that we can test this mapping guidance document in various settings, not just in large hospitals and emergency rooms but also in small practices that have EHRs that use HL7 as their back end to demonstrate the value of the message.
And this is an important thing -- to isolate the impact of the transaction. So, it doesn't necessarily make sense to say, let's pilot e-prescribing, and, oh, by the way, we're going to include the mapping.
We would really like to see this tested in places where e-prescribing exists, and what you're doing differently is, instead of having this thing go to print or to fax, it goes to an e-transaction, a message that goes to the pharmacy, so that you can isolate the impact of that thing. Does it make it happen faster and more effectively? Can you delineate the cost/benefit analysis of who has to do more work in that setting than not and who benefits from the existence of that versus not? And so kind of get some ideas about where the ROI lit exists and how we can accommodate for discrepancies between the return on investment of the efforts involved versus the efforts required.
Then, you know, are there decreased call-backs? Are there increased call-backs? Is there reduced staff time or prescriber time? Does it have an impact on fill/refill rates?
There's an opportunity to show either that there's a decreased compliance because the patient no longer has the paper reminder. I'm sure they're going to have some form or something that would say this is what you're supposed to go do, pick up your prescription, but there's also now a hand-off to the pharmacy, to the retail pharmacy, who has an incentive to contact that patient and say, hey, your prescription's ready, come get it, your refill's ready, come get it, which can perhaps impact refill rates.
Then just something I sort of made up, the notion of a semantic loss ratio, or SLR. You remember the old game of "Telephone" that you used to play as a kid where you took the people in the circle and you'd said something at one end and everybody whispered it to the next person and then you found out that it sounded something completely at the other end?
What percentage of this stuff, because we don't have a completely standardized code set because some of this stuff, we have truncation issues where some of the fields in NCPDP SCRIPT have a certain length and they don't go over that, and there aren't the same limits necessarily on the HL7 side, what happens when you lose that information? Do you lose the semantic meaning of it, behind it?
There are many issues like that that you want to be able to truly identify and figure out, and one assumes that, because it goes into electronic format, you have some ability to read it a little more accurately than what the handwritten script might be, but what happens? You know, what are the issues there?
Some of the things that we're considering for our future efforts -- you know, we're taking a little bit of a hiatus and a much needed breath from this project while we're awaiting comments from the two standards organizations and from you. Please do comment if you have anything to say.
But then we will need to look at this and try to maintain in our quarterly basis, and Jim is very focused on how we're going to do the ongoing maintenance of this. Also, then, the next question is: Do we take the next step and map it to Version 3? And there's some, again, real advantages to that potentially, even though it's not in widespread use, because everybody's looking at this move toward Version 3. Is this an opportunity to have the one size truly fits all because as you're mapping the Version 3 from your old HL7 2X version, you can have one way to get to NCPDP SCRIPT.
But as much as this required each person getting to know the other side of how HL7 works versus NCPDP, a whole lot more education needs to be built in to this in order to accomplish that task, so that's a clear opportunity for support.
The next slide just shows the email address, how to subscribe to Yahoo! Group, or you can contact any of the project coordinators for assistance on it as well.
Again, thank you for your attention. Thank you for your support of this. This has been a really -- I'm just anxious to see the day [voice catches with emotion] -- hmm, finish like that, excuse me -- when a life is saved.
I'll stop there.
MR. REYNOLDS: Thank you. I think what's exciting about what you just covered is that there may be a life saved is one thing. But obviously, I think as you look at it from strictly a business standpoint, the work that all of you have done will allow people to take what they already have and continue to use it and not have to reinvent everything that's going on out there.
I think that was one of the key things that was discussed early on about this whole mapping, letting the hospitals and others stay as they were and then move forward. So I think that's a great step.
I'll open the floor now for any questions. Jeff?
MR. BLAIR: It's going to get like a broken record, but, Ross, thanks for tremendous leadership on this. I know that you didn't do it by yourself and you've given recognition to all of the folks that contribute.
In terms of the next step, and you were mentioning mapping to HL7 Version 3, has any thought been given to whether that is a two-way mapping or a three-way mapping? Is it just going to be between HL7 Version 2 and Version 3 or is it going to have to be in addition to that, mapping between NCPDP SCRIPT and Version 3? That's one part of my question, so let me let you answer that first.
DR. MARTIN: Jim, feel free to chime in on this as well -- inasmuch as there is some level of mapping already between Version 2 and Version 3, we'd certainly build on what exists there and hope that there's very little to add to that necessarily.
You know, as we dig into it, there may be some clarification of specific needs that may be identified and may be unique to has to translate into NCPDP, but the intent would be to focus on the Version 3 to SCRIPT and just, you know, check the boxes to make sure that the 2 to 3 existing work is adequate, is consistent.
Is that fair to say, Jim?
MR. BLAIR: Okay. I'm sorry --
DR. MARTIN: I think Jim McCain wants to comment, too.
MR. McCAIN: I would just say that in the process that we're going through, the aspect of doing Version 3 mapping and so forth, back a year ago and so forth there was basically maybe only one way that we could accomplish the mapping to Version 3 and there were reasons that we did not do that mapping, as Ross alluded to.
In conjunction to what he alluded to was the fact that the HL7 Version 3 medication, model artifacts, and the pharmacy message model artifacts were not sufficiently stable at that point to warrant us going forward with a mapping to those particular things.
That has now changed, and in conjunction with that, there are now multiple processes that are being considered within HL7 for how to map from HL7 Version 2 standards to HL7 Version 3 standards.
So, the bottom line is there are multiple ways now that we can possibly achieve the NCPDP SCRIPT mapping to the HL7 Version 3 mapping, and we are in the process of having some experts provide us consultation on which method would be the most efficient and probably the best, cost-effective way to accomplish it.
MR. BLAIR: Okay. The other aspect -- I just made this three aspects -- so the second one. As you went through this process, did you find that the predominance of the use cases were that you would be translating from HL7 Version 2 to NCPDP SCRIPT and that that was likely to be the bulk of the way that the translations had to occur?
DR. MARTIN: As opposed to the other direction or as opposed to --
MR. BLAIR: As opposed to the other direction.
DR. MARTIN: Yes, I think that that was the more common scenario, because there are many more settings where, you know, almost every patient discharged from the hospital is going to have some medications to be on, many patients discharged from emergency rooms, large institutions' systems.
You have a relatively smaller number of pharmacies that would exclusively work on the HL7 side where there would be a need to send information from the ambulatory side.
I don't know that anybody's done any kind of objective measuring of the transaction potential there; I've not seen that.
MR. BLAIR: Did this wind up resulting in areas that were identified to NCPDP SCRIPT that needed to be enhanced because there was specificity from the HL7 pharmacy order that wasn't quite there in NCPDP SCRIPT, so in a sense just this exercise alone led to strengthening NCPDP SCRIPT?
MS. GILBERTSON: From what I recall, no. In fact, it went the other direction.
Most of the needs were recognized to be taken to HL7 to include, for example, some NCPDP code sets as part of their vernacular.
MR. BLAIR: Okay.
MS. GILBERTSON: Code sets were the biggest ones. I'm trying to think if there were -- I don't remember data elements. Well, no, there were some data elements because there were some address fields that were found to be missing, and we shifted back and forth.
Originally, we were going to start with just like Version 2.3 was it, way back then?
MR. McCAIN: Yes.
MS. GILBERTSON: And we found that we needed some fields that had been added all the way up to HL7 Version 2.6 to get the functionality needed for some of the transaction exchanges. So that was the good thing we found.
MR. BLAIR: So we almost got two for one out of this --
[Laughter.]
MR. BLAIR: -- in that we not only had a mapping process, which is beneficial for interoperability, but we also kind of set a new higher level of standards that whichever of the two message format standards had greater specificity, the other rose to that level. Is that correct?
DR. MARTIN: I think that's a fair statement, and I think it's consistent with the overall observation that one of the benefits of what happens often at HL7, for
example, being an international organization, even though you're dealing with very specific, realm specific needs -- you know, pharmacy in the U.S. is very different from pharmacy in Germany, very different from pharmacy in Australia -- but it forces you to abstract out to a level that accommodates them all, and you see these common things that, oh, here's the way to look at that, that kind of gets at the pure truth of it all, if you will. And I think that we observed some of that.
I guess the other side of the comment that Lynn made about more of it going in the other direction, it's not that HL7 doesn't have a lot of detail in it; in fact, a lot more detail in some areas. But it's not relevant necessarily to the outpatient prescribe, the ambulatory care setting, for what you need for a dispense.
Well, so much of the pharmacy model for HL7 deals with the administration of drugs and other, you know, timing issues with that that just aren't dealt with in a prescribe notice in the ambulatory setting.
MR. REYNOLDS: Michael?
MR. McCAIN: Jeff, if I can just add to the comment about where you're talking what transactions you'd say -- maybe more HL7 to NCPDP or vice versa and to the notion -- again, our use case is we're primarily for the institutional setting physician going outside.
But in the context of this particular Committee and the particular testimony that we're doing now on MMA, one side benefit of this is going to be -- as you know, there's been recent public release of the Office VistA software, EHR software, and so forth out to the general community. Well, that particular product has fairly robust support of HL7. It has less robust support of NCPDP standards.
Therefore, if you do get widespread implementation of the Office VistA product out there, you now with this map and so forth, you already have in place now at least a technical specification or document that the people out there trying to implement Office VistA or the MMA pieces can reference to accomplish that.
MR. BLAIR: So it'll kill three birds with one stone.
MR. REYNOLDS: Marjorie, you had a question?
MS. GILBERTSON: There is the other side of the equation, the third set, whatever, of transactions, which is the medication history, which are the PBM, the drug benefit program that speaks NCPDP sending information into the hospital setting or clinic setting for the medication history information.
MR. REYNOLDS: Michael?
DR. FITZMAURICE: Well, I don't want the Audubon Society to get after Jeff and me --
[Laughter.]
DR. FITZMAURICE: -- because we're always looking for birds to kill --
[Laughter.]
DR. FITZMAURICE: -- but as these mappings take place, does the RIM get changed as a result of additional variables and additional findings as you map to other standards? Is the RIM also a growing, living thing that rises to meet the occasion?
MR. McCAIN: That's kind of a complicated question.
DR. FITZMAURICE: Sounds like "no."
MR. McCAIN: No, the answer is actually yes. But what you find is that it depends at what level of the RIM that you're talking about.
If you talked at the high-level RIM aspects, you'll find there's very little that needs to be added. It's when we dive down into creating the lower-level model artifacts and so forth that we will bring into the harmonization process.
DR. FITZMAURICE: Well, like Jeff, I also want to give strong kudos to Ross Martin and Lynne, Jim, all the people who worked on your committees, to bring this about. And yet you said there's not much money involved in this.
It's mapping back and forth. And yet it's going to make the system work. It's going to make sure that someone in the hospital gets the right drug when they leave the hospital and go home.
Likewise, it can have the same effect on the hospital. It can add to the medication history. There's just a lot of things that can be done that isn't in the mainstream. This is really a critical linchpin for bringing together the SDOs to work together and so that we can make the system work across our domains.
Many congratulations for making that happen. It's rare that somebody bursts on the scene like Ross has and just has such an impact. He's able to leverage the good work of the people who are already working hard to get them focused and go for additional efforts.
While I have you up here, Ross --
[Laughter.]
DR. FITZMAURICE: -- you're a physician and you make decisions, and I'm sure you like to have decision support.
I don't know if you looked at GELLO and R10(?) syntax, but in an earlier discussion we had this morning, there was a possibility of GELLO being used for prior authorization that is taking rules: If this, then this. What is your opinion about that? Do you have a sense on whether GELLO can fit or not or whether it is worthwhile to look at?
DR. MARTIN: Well, I would say -- I guess it's an unfair question because I was the one who has been pushing for that within NCPDP and sort of instigated yet another full activity.
I think it's where we have to explore. Just for further clarification, while GELLO has not really been implemented much of anywhere, it is now a balloted ANSI-accredited standard, and that just happened in the last couple of months.
So I think there's a real opportunity to test it. It may actually turn out that it's overkill. It's possible that GELLO has so much potential robustness that we don't need all of that; we need a very small subset of it to do what amount to fairly straightforward clinical criteria.
But there are a couple of pieces of that that, in order to get to this next step of using GELLO within prior authorization, we need a compiler, we need other tools so that you can express these things in HL7-speak, and that requires development.
I don't know what the opportunity is in terms of piloting, as Tony mentioned. I think we could do pilots in 2006. They just wouldn't be the pilots that lead to final CMS regulations. There are the pilots that get us further
down the road to having a finished product that would do that. So I hope that we can put some real effort on this part of it.
The reason I thought it was so important to bring this particular use case to GELLO in particular is because clinical decision support requires something like GELLO, a way to express clinical concepts and criteria in a computable fashion.
And it's not just exclusive to prior authorizations, for evidence-based medicine, for any of these types of things. But the nice thing about prior authorization is it simplifies this whole question of clinical criteria because it's a point in time, whereas clinical guidelines involve a process that could span a year, two years, and things change in that. You're asking essentially yes/no, logical questions at a point in time, and if they're all true, or if a set of them are true, then you can get to the final yes, and that's the real opportunity here.
And so that's why the clinical decision support group at HL7 adopted this project, because they saw that it was a great way to bring GELLO into the clinical setting and make it work and then go on to these more complicated, much more involved processes.
Does that address the question?
DR. FITZMAURICE: Yes. Thank you, Ross. Thank you.
MR. REYNOLDS: Okay.
DR. MARTIN: You're welcome.
MR. REYNOLDS: I'd like to thank everybody. This ends our first part of the presentation today on e-prescribing. We'll start this afternoon on clinical data.
I'd have to say that the wow factor probably entered this discussion this morning a lot more than I thought it would. You all, everybody that's been involved, has done an incredible job.
A lot of people think of standards organizations as having a general direction. You have taken a very focused, laser-like look at the future and our making a major, major contribution, so thanks to all of you.
We will resume at 1 o'clock. We'll give you the hour for lunch. And I'd like everybody to be here promptly. We will start at 1.
So, thank you very much to everyone, and, Michael, thanks for what you're doing on helping lead AHRQ help some of these people out, so thank you very much for that.
MR. REYNOLDS: Thanks.
(Whereupon, the meeting recessed for lunch at 12:05 p.m.)
MR. REYNOLDS: Take your seat, please, and get started. We're going to start our afternoon session, and Jeff and I have talked about this a little bit and we're going to change our mode of operation a little bit.
Usually when someone presents, we wait to the end to ask them questions. But since this is a new subject to us and I looked through the charts last night and struggled on a few of the acronyms and some other things --[laughs]
-- as we try to learn this, staff and Committee, please put your hand up if you don't understand what an acronym stands for.
And then we're not going to ask questions during the presentations, but we would like to at least make sure that we're following along, because about the time you get six or seven acronyms that you didn't understand, you've lost the subject. So this afternoon we are going to change that process just a little bit to make sure that we can kind of stay with it.
Before we get started, I'd like to thank Dr. Stan Huff for being willing to lead this subject. Jeff did an excellent job with e-prescribing; Stan's now got secondary uses of clinical data, and we've got Judy on deck for some other stuff here shortly. So we appreciate that help.
So without any further ado, I'll go ahead and let Stan take over. Get the microphone, Stan.
AGENDA ITEM: Presentation -- DR. STANLEY M. HUFF
DR. HUFF: Am I on now? All right.
The first thing I'd like to point out is that this idea isn't original with me. The NHII Roadmap, there are a few sentences that talk about this subject. It talks about -- actually I guess it was this Committee said, you know, a comprehensive set of PMRI information standards can move the nation closer to a health care environment where clinically specific data can be captured once at the point of care with derivatives of this data available for meeting the needs of payers, health care administrators, clinical research, and public health.
This environment could significantly reduce the administrative and data capture burden on clinicians, dramatically shorten the time for clinical data to be available for public health emergencies and for traditional public health purposes; profoundly reduce the cost for communicating, duplicating and processing health care information, and last but not least, greatly improve the quality of care and safety for all patients.
So I think that this is a continuation of that thought. And I think that thought also -- I don't think it was original with the NHII Roadmap. I think it's sort of an unstated sort of understanding and motivation for a lot of the electronic health care records systems for the last
30 years. I know that's been one of the goals, for instance, of the help system that's in use at Intermountain Health Care.
So I just wanted to point out this isn't something that's original with me but something certainly I have a great interest in.
So, just a couple of definitions then, at least in the way that I use the terms.
If there's secondary use of data, then there has to be something that was primary use of data. So primary use of data is the collection, processing, display of data for purposes of taking care of a patient. And the way I use the term, that's care of the patient whether I collected the data in my institution and I'm caring for the patient in this institution or whether I transfer the patient to another institution and I send that data, using HL7 transactions, to another institution, take care of the patient there.
That's still primary use of the data, the primary use being the care of this patient, this individual patient.
Secondary uses of the data really then fall to, you know, when I want to use that same information to automatically drive billing, if I want to derive statistics from it, I want to do quality assurance from it, I want to do any of these other things. All of those are the secondary use of direct patient care data.
So, just to illustrate, this is an example that I used for Cancer Registry data, and recognize this is just one example of 20 or 30 or 50 kinds of examples.
But in the way that things happen now, if you look at clinical data flow within Intermountain Health Care, we have data that's coming from the laboratory, we have data from radiology, we have data from clinicians, we have pharmacy data. We have lots of ancillary systems that are contributing data to an interface engine. We normalize the data and then we store it out into our clinical data repository. And to the extent possible, we try and use standard interfaces to do that.
That's primary use of the data, because what we're doing is it's clinicians, physicians, nurses that are looking at that data to care for the patient, to make decisions about this patient's care -- what medications they should be given, what diagnostic tests should be done, all that sort of stuff.
So that's primary use of data.
If you compare that then to the Cancer Registry data flow, and I think this is pretty typical right now, what you have for Cancer Registries in general is that all of that electronic data becomes part of the patient's chart
and then there's some person who is manually extracting data from the charts and in a lot of cases re-entering that data back into computer systems, and then that data can go out. It becomes part of the hospital Registry. You can use standard interfaces for that and it becomes part of the regional or national registry.
But the point is, that is secondary use of data now, because now we're populating the Cancer Registry for the purposes of understanding population statistics relative to particular kinds of cancers and outcomes from cancer treatments et cetera.
But that's largely a manual process, and what we're talking about now: Is there something we could do that would automate that process so that we can algorithmically define these things?
So what we're talking about is a potential future state where the information is flowing in from a laboratory, from radiology. It's going in through an interface engine, and the information is coming out and it's going through a -- you can think of it as a filter or as a set of rules or a set of algorithms -- in an automated way into a hospital Registry.
Now, there should be no illusions that this unattended sort of flow, because you're still going to have people required to review and make sure that the rules are doing what they're supposed to do. And, you know, my guess is that in fact the Registry person won't be done away with. What they'll be doing is doing a different job -- to review data -- and a lot of the mundane things are taken out and they can do a more thoughtful process to make sure that the data is consistent and complete and that sort of stuff.
And so there's a filtering process there, and then again we're trying to use standard interfaces everywhere that we can to decrease the cost of implementing these interfaces and doing the rest of the work.
So the whole idea of this -- and again, this is just one example of lots and lots of different examples where what we're trying to say is we're capturing this data electronically, rather than then having people read and process the information manually. Can we set up rules that would allow them the assignment of billing codes or the inclusion of this data into Cancer Registries or for purposes of quality assurance? Could we do that in automated way so that the data stays electronic and really improve the efficiencies and the timeliness that we can produce these other secondary benefits?
So just to give you an idea, I wanted to go through a few secondary uses of data that are in place at Intermountain Health Care. And these are all things that I haven't done; these are things that are being done by Scott Evans and by Sid Thornton and lots of different people within IHC.
But one of them is adverse drug event monitoring. We originally got into adverse event drug monitoring and we were doing it the way most people do it, which is we ask people to report when there was an adverse drug event.
And then we started thinking and saying, well, how could we -- and our suspicion was that they were tremendously underreported -- so Scott Evans and others put in place and said, well, look, what if we looked at drug levels? So, I mean, if we saw toxic drug levels from the laboratory data, that might be indicative of an adverse drug event.
What if we watched and saw when Benadryl orders and Prednisone and other kinds of antidotes were prescribed, any kind of treatment that would normally be a treatment for a drug event, what if watched for those things in the system?
And what we found is that in fact electronically we could put rules in and through that electronic surveillance we increased roughly tenfold the detection of adverse drug events in the system, doing that.
We do nosocomial infection monitoring, and again, it's a fairly simple rule. And what it does, you know, the computer knows when the patient came into the hospital; it knows their white count, if they're afibrile et cetera, and the system simply watches to see people who are hospitalized who then get a fever or we watch the X-rays, and there's a fairly simple natural language processing on the X-rays that says, you know, is there a new infiltrate, new signs of pneumonia? And it watches for those things.
And so a combination of knowing when the patient was admitted, that they got a fever after they were admitted, their white count went up after they were admitted et cetera, we have a way of detecting people who in fact got nosocomial infection, that acquired an infection after they are in the hospital.
In the billing area, we've only done this in a small area, but in labor and delivery, we have a fairly comprehensive labor and delivery program that watches medications that are given to the mother. It produces a tracing of the labor intensity and pressures and fetal heart rates et cetera.
And we have a set of rules basically that look at that data stream and automatically assign the billing codes for that labor and delivery work so that it's a rule-based application of billing codes as opposed to our standard process.
We have a set of programs for reportable disease.
As all of you know, there are a number of diseases that we're required to report to the state health department, and it took a lot of manual work to produce those reports.
Now, actually what's happening today is that we electronically produce them and then somebody writes them down and hands them off, again manually, to the state, and what we'd like to do is in fact set it up so that we can just send them electronically to the state.
But in terms of us gathering the data, what happens now is that the system looks at antigen and antibody tests that are happening in the laboratory, the culture results from the laboratory, and it knows the list of things that are reportable diseases, and it produces a report every day that says these are the cases of reportable diseases that you have in the hospital.
In terms of quality improvement initiatives, we support, in particular for diabetics, a "how am I doing report" that physicians can run. And what it does is looks at hemoglobin A1c results. And what it can tell a physician is, for your diabetic patients, your diabetic patients have hemoglobin A1c levels of 8.1 on average. And throughout IHC, the average is 8.5 percent, and the best within IHC is actually, you know, 6.5 percent.
So a physician can look at the diabetic population they're managing and know how they're doing relative to their peers and relative to the best practices within IHC.
And it's had a remarkable effect on what physicians do. I mean, when they see themselves as an outlier in that kind of quality measure, they change their behaviors, and it's been a real eye-opener.
There are also things that we're doing in clinical research -- transurethral resection of the prostate -- and the clinical research in these cases are things that we do that ultimately end up being primary patient care, because we create a rule, or create process changes, that change the quality of care.
But in the case of TURP, for instance, what we found is that there was a huge variation that didn't seem to correlate to much. I mean, some people would go home within two days and other people would take as many as five days. And we could look at the computer data and try and figure out why that was and what the difference was.
What we found out basically with the TURP surgery is it depended entirely on when they pulled the catheter. If you pulled the catheter a day early, you have the same outcomes and everybody went home earlier. And if you left it in another day, they basically stayed another day. And there were no differences in outcome.
Another thing where we did research -- there was national literature about pre-term induction of labor. And in that particular case, you know, they said if you induce labor before 39 months, there's a much higher risk of complications in the baby.
And the physicians within IHC said, well, yes, that's probably true for those bad physicians nationally.
[Laughter.]
DR. HUFF: What we're able to do is go to the data in the computer system and in fact we could show exactly the same statistics on our own population and say when we do it within IHC, it's exactly the same way, and we're doing it roughly at the same rate as nationally.
And so it provided the justification for in fact implementing that rule through education and other means, and, again, dramatically reduced the pre-term inductions and dramatically reduced the number of ICU days for the babies et cetera.
So those are just some things. These are the kinds of things that we're talking about that are, quote/unquote, "secondary uses of data."
So this is kind of a more complete thing if you break it into categories. There could be billing, which -- we're going to hear, I think today, more opportunities about billing and assignment of billing codes and other things; morbidity and mortality reporting; quality; patient safety; clinical trials.
Clinical trials really comes to mind especially in the case of post-marketing information on drugs and devices and particularly also for enrollment into clinical protocols. One of the hardest things about clinical trials is in fact finding people to enroll in the trial, and the computer can be actually a big help in enrollment in trials.
Clinical research we've mentioned.
Health population statistics. The whole idea, and this is an area where I want to hear a lot of discussion from people more knowledgeable than myself about this, but the whole idea of -- you know, if we're interested in obesity in the country, I mean, we're taking I don't know how many -- I'm guessing that we probably have a thousand or two thousand weight measurements a day, probably more than that, into our electronic health record systems. I mean, we could almost have a daily report on how the population of Utah is doing relative to obesity.
And so, you know, I think there are untapped possibilities there that we need to think about.
Public health in general, bio-surveillance, reportable disease reporting, Cancer Registries, et cetera -- again, I think there's a real opportunity for automation in those areas.
So why should NCVHS study this topic?
To me, I'm just asking the question: Is there something that needs to be done?
It may be that after we get the data in, we say there aren't any new standards, there aren't any new needs for policies, everything's going along great. But it may be that in fact we do need some new standards or we may need some new funding or we may need to suggest some demonstration projects, some other things that in fact would encourage this, or maybe there's some new policies or maybe there's some changes in incentives that need to happen that would encourage this to happen faster, all for the benefit of increasing the quality and safety of patient care.
I think there have been questions. One of the other questions was: Should this be happening in Standards and Security? It may be that this is in fact very interesting to the Populations Subcommittee as well as to the Quality Workgroup, and this is an initial sort of discussion to say: Should we broaden this? Should we in fact raise this issue to the full Committee in some way? And so it's good Simon's here, and it's good you've got a retreat coming up. You might talk about it a little bit in the retreat to see if there's some common interest across the Subcommittee. So, that's the idea.
Okay, now this next thing is just sort of a little bit about the theoretical basis of some of this kind of secondary re-use of data, and this is going to be a characterization of sort of how you proceed from primary data to more and more higher level inferences that can be made from the data.
So, in some sense you start out, all sort of clinical care and decision making starts out with primitive observations. And even perceptions. You know -- colors of things, temperatures of things, the appearance of the patient, shapes, sizes, all of that sort of stuff.
And then what happens, either in a person or in a program, you can make inferences from that.
So if I'm looking in somebody's throat and I see particular colors and other characteristics, or I can assert that there's redness there, there's erythema. And if I'm palpating lymph nodes and I feel a particular size and shape, I can say that there's lymphadinopathy here and I can talk about the distribution of that.
And they tell me that they have pain in the throat, I can say they've got a sore throat. You know, from the heat, basically you get an accurate temperature; you can get a temperature from a thermometer or some other kind of interest and you can read voltages on a color(?) counter and get white blood counts.
And you see hemolytic colonies on an arger plate(?) and you can that they're beta hemolytic colonies there. So you see certain patterns.
So the next level then, you can apply some further processing to that, and when I take the redness and the cervical lymphadinopathy, I can say there's an inflammatory process going on.
And knowing things about the plate, I can say that this is a positive strep culture. And if I apply a rule to the temperature, I can say that it's not just 38.9, but I can apply a rule and say this constitutes a fever. And the white blood count is increased for this particular population et cetera.
And I can apply yet then another inference process, taking into account then that I have inflammation, a positive strep culture, fever, and plus I can say, well, they've got acute streptococcal pharyngitis. And I can add in some other facts about the fact that there's status post splenectomy or other things and I can actually come to the fact that this person is in an immuno-compromised patient.
So, the idea here is that in secondary use of data, you start out with these low-level perceptions, primitive data, and every place that I've got these little brown or yellow circles, there's some processing going on, and it's processing that either happens in people's brains
or it's processing that can happen in a computer system that can assert then that -- again, if I have inflammation, a positive strep culture, fever, increased white blood count, I can assert then that there's an acute streptococcal pharyngitis.
And that assertion can happen because a clinician, an expert clinician, assimilated that data in their brain and made that assertion or it can happen because a computer program has that logic in it and it can make the assertion based on logical processing of that information.
Now, there are a couple of things about this process. What happens often is that people assert information -- what you'll get, for instance, on a problem list is you'll get that this patient has acute streptococcal pharyngitis.
And that's good information, but if I could get the other information down at the primitive level, what I can actually do then is quality control on the process, okay, because I can look down there and say, you know -- because there might be all kinds of other data and I'd say, oh, you know, there could be a whole another explanation for that based on the primitive data.
And so you're in this situation where if it were possible, you would like to get data at the most
fundamental level, because that allows then the most scientific and thoughtful and systematic way of analyzing the data so that you look at the inference processes and actually see if it's correct. And that's where you get into quality assurance and all of the other things.
Now, the down side of that is data collection is costly, so it may be a lot easier to just catch the assertion of this thing on the problem list than it is to catch the individual temperatures, and so there's always a tension: How much good data can you afford to collect versus, you know, what you can get easily and support the process?
But if you take away this particular example but think of the process in general, what we're doing in all of these things is we're proceeding from data; we're trying to apply rules and come up with inferences from that data, things that we know, new things that we can assert that we know because of what we had in the data before.
So you apply that pattern again and again. If we can take the primitive data of hemoglobin A1cs out, we can do some rules and some inferencing and assert, oh, your average of diabetics is sort of in the middle of the pack, or it's a lot worse or it's a lot better than the average physician within IHC. So you're aggregating that data for a particular purpose.
So that's the general process, and sort of the general thought behind a lot of this is proceeding from one kind of primary data to more sophisticated inferences that we can make from the data that would serve quality purposes, all kinds of other kinds of purposes within the institution.
So just a couple of observations. Data capture is costly in terms of people's time and computer programming and instruments. The closer you capture the data to the level of perceptions, the more inferences you can make. And raw data allows testing whether the inference processes are accurate.
Related issues -- an idea that was put forth and one of the terms that Chris Chute has used, talking about this, is, quote/unquote, "aggregation logics." So in a sense, what you're doing is -- especially applicable to classifications are that you can start with primitive data; you can apply a set of logic and come up with a new conclusion or you can assign an ICD-9 or an ICD-10 code to a particular set of things.
And part of the whole idea of these aggregation logics are that you're not now dependent upon written descriptions in a book that a person or an expert coder has to understand, but what you're actually doing is creating computable rules that a program can execute.
And if we could get people to share those algorithms, and in fact CMS or others who are doing billing to say "this is exactly what we mean, this is exactly the evidence that we need. If you're going to bill us for a stay for diabetic ketoacidosis, this is exactly the kind of data that we need to support that conclusion."
And if those could be computable rules, rules that can be executed against standard data structures and standard terminologies, then it takes all of the ambiguity out of assigning those particular billing codes, and we can do it in a more efficient and timely way.
I would point out that having said that we're going to do the secondary use, I don't think we want to go to the extreme and think that we can do everything by secondary use of data because there will be lots and lots of times when the data you need wouldn't necessarily be collected as part of standard clinical care.
If you have a research question about correlation of diets or race and ethnicity, other kinds of things, there may be questions that you want to ask that are specific to that research study that wouldn't be part of routine clinical care.
So I don't think anybody should think that a lot of our national surveys or other things are going to go away because we get into the secondary use of data, or that
they would all go away. I guess some of them would go away or we're probably not going to benefit from this technology.
The same sort of thing is true obviously in clinical trials. You're looking at a very specific thing and, you know, if you're looking at impact on liver enzymes then for that trial, you're going to specifically ask for the collection of liver enzyme levels to test the hypothesis that's being studied.
But I think the point is that in spite of all of the potential for this activity, I think we need to recognize that we're still going to want to do very focused clinical trials as well as clinical surveys and other things that lead to specific kinds of data.
So I'll stop there. My intent was really to just lay some groundwork in terms of definitions and thought processes and let the other experts that are going to testify in fact delve into more of the details and strategy here, so I'll stop at this point and --
MR. REYNOLDS: Any questions? Any questions for Stan?
DR. FERRER: Stan, it seems at IHC you're doing a lot of quality assurance by providing that performance metric back to the clinician. Because of the competitive nature of the clinician, he wants to, quote, "perform equal to his peer or better."
If you go to the next step and you say, you know, we want to report that information, you know, when does the comfort level of the clinician become a barrier, if you will, once you start crossing the public reporting arena?
The reason I ask is because CMS is driving towards public reporting of performance measures, and oftentimes, you know, that quality assurance -- actually, that trust, if you will, is broken once you start doing things like that. So I'm just curious as to how --
DR. HUFF: There are a lot of interesting issues. Our focus is on improving quality, and we kind of approach the same mentality as with adverse drug event. We're trying to be non-judgmental, because as soon as you start imposing penalties for reporting, reporting will go to zero, so your ability to manage the process -- at the same time, you know, as a physician and an intern, I was much more comfortable with medical care when I knew all of the physicians. And now that I'm just a deadbeat pathologist informaticist --
[Laughter.]
DR. HUFF: -- I'm much more like a regular consumer when I go, you know, to a physician. And so I have a great sympathy for wanting to have public metrics that would tell me: How do I choose a good physician?
So I guess I would like to see this continue. I think the way we're doing it is successful, trying to improve the quality of physicians. I think it's a separate question about, you know, publicly available metrics. I would like to see them, but I don't know how to do it in a way that wouldn't in fact cause all kinds of other problems in sort of decreasing the people gaming the numbers. I don't know how to solve that.
MR. REYNOLDS: Stan, as you envision this secondary use, once some of those secondary uses became standard and the algorithms and other things became standard, then basically data could be pulled from anywhere into your inference engine, whether it's yours or anybody else's, and used to draw these same conclusions on a more general basis than just, in your case, Intermountain Health Care, right?
DR. HUFF: I missed the question part of that.
[Laughter.]
MR. REYNOLDS: Since this is primer, I'm trying to make sure I understand.
DR. HUFF: Right. I mean, and Clem may speak to this more directly, but, for instance, the HEDIS measures that are in place, that's specifically one of the things that we're talking about.
I mean, you could establish and basically say,
okay, for an institution, we want to know, you know, what percent of your eligible women are having mammograms. That could be an automated report that doesn't require compilations.
Basically, you look at the electronic medical record, and if the eligible women have a report that is a mammogram and there's a standard code in LOINC for the mammogram report, you know, more than one, if that report exists, I count that as a statistic. And I can do that as a query on the database.
And you could implement that, you know, broadly across the nation, and in fact it's simple enough that you could get weekly reports from people about how they're doing against that particular measurement.
So that's exactly right. I mean, it would be agreed that this is the exact algorithm for determining that, and I think you would see a lot of variability go out of the assignment of those as well as a much more efficient process in assigning that kind of statistic to a given institution.
MR. REYNOLDS: Simon?
DR. COHN: Yes. Stan, thank you, and Clem, welcome. I haven't looked at your presentation yet, Clem, and if I'm going to say something that you would likely have said, I will apologize.
But, you know, obviously I like very much what I'm seeing here. However, there is that thing that sort of worries me a little bit, and I guess I'm just trying to think of how this fits in. It's the issue of data quality.
Now, Dr. McDonald may want to use an example probably of talking about lab data being more reliable than physician-entered data. Now, that's something we all recognize, that I guess as we use these things and we make inferences and we try to automate all of this, there's, at least in the world that I see, a lot of not very clean data out there, data that's not likely to get a whole lot cleaner by the introduction of electronic health records. So that is arguable.
And I'm just wondering: Does that fit somewhere into this vision?
DR. HUFF: I think it's a very important issue, and I agree with you that it certainly is dependent upon data quality.
I would argue that, though, making it electronic does in fact have an opportunity then to improve the quality of that data because -- a couple of things, just an anecdotal --
Some of the other things, for instance, that go into that diabetic report besides the hemoglobin A1c were whether the physicians were doing monofilament line tests and other things. And we tried it two different ways.
We said -- you know, we just asked the physicians to put this data in, and it was hit and miss whether they put it in or not and whether it was reliable or not.
And then we started producing reports, and they showed up as having, you know, basically a zero for their monofilament line tests and they went, oh, hmm -- you know, I want to put it in.
But even beyond that, even beyond just sort of the "I want to be good and I don't want to show up as an outlier," it really is if the clinicians understand why the data is being collected, then they're tremendously more cooperative in supporting collection of that data.
So, it's really about patients getting better and understanding if there's a reason that we're collecting that number, that it's going to support the quality of patient care, then they're tremendously more motivated to do that than if there's just sort of a request for this kind of data and no explanation about why and nothing ever comes back to them as a result of that.
So, making it electronic and then creating that feedback loop so that they see some outcome from the data input I think tends to increase the quality of the data that's entered. And that's probably in fact one of the best ways that I can think of.
But you're right -- absolutely -- that the inferences you make are totally dependent upon the quality of data entry that happens at the bedside and at that clinical level.
DR. McDONALD: I'm going to touch on this, but the question has to be: Quality for what? And the answer --
PARTICIPANT: Microphone, Clem?
MR. REYNOLDS: Microphone.
DR. McDONALD: Well, I won't repeat that. I'm going to say a little bit about this.
DR. COHN: Good point.
DR. McDONALD: Should I start?
Well, I really am happy to be back. I had four great hugs when I came in the door.
[Laughter.]
DR. McDONALD: That hasn't happened to me in about a month, so --
[Laughter.]
DR. McDONALD: -- that by itself was worth the trip.
MR. REYNOLDS: Question. I thought you were going to comment on Simon's question.
DR. McDONALD: Well, that's going to come out of my --
MR. REYNOLDS: Oh, okay, but Steve's still got a question.
DR. McDONALD: Sorry -- I'm sorry.
DR. STEINDEL: Actually, it's somewhat of a question that may be touched on by future speakers today, or maybe future speakers in the future, because it's an aspect of secondary use of data that's generally not talked about, and there are really two types -- I look at it as two types -- of secondary uses of data, and Stan did a very good job of talking about the type of secondary use of data where we draw inferences. We take data, we apply rules engines to it, and from those rules engines, we get some type of conclusion, whatever it might be and however complex it might occur. You know, that depends on the nature of what we're asking, the nature of the data that's coming in.
And then you also touched on the other secondary use of data in your comments about HEDIS measurements, because a lot of secondary use of data is process. But we count things, we determine the rates of things. These are relatively simple secondary uses of data, where we have an element; we just count that element, we determine the rate of this or the rate of that, and we use that for quality control purposes or other purposes.
But one thing, that when we were looking at population health reporting for CHI, which involves secondary use of data -- virtually all population health reporting in some way or another comes from secondary uses of data -- and one of the observations that we came to during that report was: Inherent in the population health statistics reporting system is consistency of data.
Now, we can track the way the data changes over the years. And if all of a sudden we introduce electronic data that's been determined by inference-based engines, is that data the same as data that was put into place by humans applying their own inference-based engines, their brain, and putting this information down?
And that's something we determined we couldn't answer at that point in time, but it's something that I hope we're going to touch on eventually during these discussions.
DR. HUFF: You know, I think we have exactly that issue, that it's not unlike when you start using the new coding system or something. I mean, you know, I think in almost all cases you're going to have some delta there, and in that first implementation you're going to wonder how much of the delta is due to the new methodology versus how much of that delta might be some real change in the data, and I don't know any way to get around that.
I think you have that question, but I guess I wouldn't be stopped by moving forward because of that question. I'd just try and figure out all kind of ways we could to mitigate and understand how much of the delta was due to one thing or the other.
DR. STEINDEL: And I think that's the point I was going to make.
I agree with you 100 percent -- we're always going to have that perturbation and we shouldn't stop because of the fact that it might exist. But we do have to understand that it might occur.
DR. HUFF: Yes.
MR. REYNOLDS: Okay, Maria, you had a comment?
MS. FRIEDMAN: Actually, it just relates to what Steve was just saying. There's not only the issue of data comparability in quality but there's also the issue of database comparability in quality. Are we collecting and measuring things the same way and keeping them the same way? And when you start trying to take it up a level and do population health statistics or these other kinds of inferences outside of your own institution, how do you get these databases to talk to each other and do it correctly?
This is a problem we've been, you know, dealing with when I was at AHRQ in the '80s, and I don't think really it's gone away any.
MR. REYNOLDS: Jeff, you had a comment or question?
MR. BLAIR: Yes. I've been listening not only to Stan's testimony but also the questions. I see we're digging right into this issue right away and we're beginning to, on surface areas where there may be difficulties or imperfections or falling short or flaws, all of which I think is absolutely, totally appropriate.
So, I just wanted to add one thought to counter-balance that --
[Laughter.]
MR. BLAIR: -- and that is that is that if this exercise, however long it takes us, whether it's six months or 12 months or 18 months, to try to see what we could do to move the ball forward to capture clinically specific information once at the point of care and use derivatives for other uses, if we only get 20 or 30 percent of the way, we will have made such a tremendous improvement in quality of care, in cost of care, in clinical research that I just feel like we're entering an extremely important area.
So, the reason I make my comment is not that we don't need to identify all of these difficulties but that we try to keep a mindset that as we identify all of these difficulties, we don't have to get a hundred percent, we don't even need to get 50 percent, for this to be an extraordinarily valuable process.
MR. REYNOLDS: And before I turn this over to Clem, Stan, off to the side you need to help Jeff and I. On Chart 6, you've got that person sitting behind that PC. Everybody else on your charts is normal, and you got that person sitting there with a bad haircut and limited --
[Laughter.]
MR. REYNOLDS: I think it's a medical records guy and Jeff thinks it's the IS guy, so --
[Laughter.]
MR. REYNOLDS: -- we need a clarification.
The next presenter, for those of you on the Internet who might not know him, is Dr. Clement McDonald. He was an esteemed member of this Committee at one point and --
MR. BLAIR: He's not esteemed anymore?
[Laughter.]
MR. REYNOLDS: I'm not done here, Jeffrey.
[Laughter.]
MR. BLAIR: Oh, he's not a member of the Committee.
MR. REYNOLDS: That is correct. But it's always good when you have somebody come and you hear the words, like their insight, their expertise, their personality are missed on this Committee, so, Clem, welcome. We're excited to hear from you.
AGENDA ITEM: Presentation -- DR. CLEMENT J. McDONALD
DR. McDONALD: Thank you, Harry. Could I, just for a matter of tracking my life out, what's the actual schedule here? I mean, when am I supposed to be finished and when is this --
MR. REYNOLDS: You have till 2:20, 2:30.
DR. McDONALD: Okay. And then can I leave after that?
[Laughter.]
MR. REYNOLDS: No.
[Laughter.]
MR. REYNOLDS: Depends upon the quality of your presentation.
DR. McDONALD: Okay. Well, the only reason is I got a flight. That's my only constraint. And I wouldn't have done that if I thought I shouldn't have done that.
So I'm going to touch on a number of these things. So the bottom line is, among the things that should come out of this, there's a lot of good areas for research that I heard amongst the questions. And I may rebalance my presentation as I go, so if I flip through some slides very fast, it's because I probably shouldn't have put them in there.
[Laughter.]
DR. McDONALD: I want to discuss sort of two
roads, and I really wasn't quite sure of Stan's position, but I think we're pretty harmonious in what he's saying and thinking. Also, I'm going to have this from a point of view of trying to build a community system because I think a lot of the data you need to do these things need to cross institutions to start with.
The two roads are that standardized existing codes employ multiple -- I mean, existing content and employ it for multiple purposes, perhaps with some supplementation to kind of beef up something so you could get to it without huge effort for some existing purposes.
Secondly, is capture everything in coded form as a primary effort and use it to support a host of second efforts.
And I'll take these in order.
So the background and current realities -- I think the value proposition for the information infrastructure is that we standardize once and spread the cost over many uses.
And the big three of standardizing targets -- I'm just going to do these to highlight them; there's really other dimensions -- is IDs for patients or knowing who's the same patient, IDs for providers and knowing who's the same provider, and IDs for observation and reports. You can go down lower, but this is hard enough.
But I want to remind you that a few clinical applications needs less. You can actually get by with sort of some minimal standardizing, and that's not going to be useful for secondary.
So one example is we do community report delivery to physician's offices. And, bottom line, all you have to standardize is the physician, because you deliver them and they figure out the rest. You know, actually it's for printing out and putting in a chart for practical purposes so they keep them on line, too, and they can find them by knowing the patient's name. They don't really worry that there's two John Smiths in this model; it really works pretty well. And this is what it looks like, but that's not important.
[Laughter.]
DR. McDONALD: Well, there it was again. The middle white part is actually the patients' names, which we had to block out.
So it provides clinical utility while dodging the standardizing work. It requires only standardizing the providers in the HL7 messages, and that is some work, but that's going to go away, we hope, with the NPI, I mean, the National Provider ID, which we've been waiting for just for nine years, I think. Some of us had dark hair and dark mustaches when this started off. That's all gone now.
So this is easy to implement, and there's other easy tasks. There are a number of easy things you can do.
But the big clinical services need big standardization efforts. You need a flow sheet if you're going to bring different systems together. You need to have the same code to get the flow sheet to work, that simple. Specialized clinical reports, you need the same thing. Decision support -- if you're going to dig out who got a flu shot and you're counting and getting the ones done in a pharmacy and the ones done in Hospital X and the ones done -- you've got to have something standardized. Either that, or you've got a whole lot of extra labor in data collecting.
And the same is true of secondary uses. Epidemiology, clinical research of all kinds, public health case reporting, quality reporting for HEDIS, pay for performance -- it doesn't really matter where the flu shot was done; you get credit if it got done, but you'd like to know where were the other ones that you didn't do in your office, and more.
And I want to bring this up because I think that the real challenge here is we almost have to do secondary uses to get the energy equation to push over, to get all the standardization done. And I'm talking just on stuff we have now, not the hard stuff, not the full clinical notes.
I'm just saying if we get the labs and EKGs and the drugs and all this stuff that's kind of in reach, just getting that, we still need, I think, to really think in terms of going for both. Otherwise, we don't have enough maximum push to get it all done.
Now, we can deliver secondary services today and we don't have to wait for the full source data collection across the spectrum of all sources. And we can do a lot with what the electronic data has collected now. And granted that we maybe can't get perfect public health data collection totally automatically, but, by golly, we could do things on drug use and drug side effects that can't be done without the secondary data. I mean, you just can't do it.
The Vioxx thing could be stopped. We could do it with stuff that's kind of there but it's just connected. So as long as the patient and the observation codes are standardized, it can be connected in some way.
So, for a successful LHII -- and I guess the most recent term, and I'm still stuck on my previous NCVHS days where I think we called them Local Health Information Infrastructures and now it's been modernized to RHIO, but it's the same thing -- but these things --
[Laughter.]
DR. McDONALD: I think it's the same thing, quite the old one that, you know, came out of here. Because creating order, standardizing, requires work -- it costs. That is, there's just no way around it, and we just think what we standardize, and isn't that nice, it'll come out free. It's the second law of thermodynamics: You can't get order without doing work, period.
So we had to find many uses, to spread the costs over many clinical and secondary services, and for sure we don't want to design these systems that will preclude application to secondary services.
So we're going to just briefly talk, because I was just a little bit miscued about what this is about, about what we're doing in Indiana. So we've got a real live LHII, or maybe it's even a RHIO, with data flowing from all major Indianapolis hospitals, five systems, 1`5 hospitals. Physicians in the ER get access and we're about to turn it on for physicians in hospitals, to the data.
We report push to more than 2300 physicians. We integrate a number of public health functions, not all that we could; we still working at it. And we have a citywide research database.
So there's a lot going on. We have more than 94 HL7 message streams, more than 50 million separate HL7 messages per year, and that's not counting each result. And I want to say HL7 works. My sponsor, HL7 -- no, they're not my sponsor.
[Laughter.]
DR. McDONALD: It really does work. We get 30 million accesses per year for the clinical care at two hospitals. We add about 80 million results per year.
We have 30 years of cumulative data from one hospital, 15 years from two, and lesser amounts from the other three; 700 million rows of clinical observations; 45 million radiology image, not studies, because they make a lot of images per study; 14 million text reports; 30 million physician-signed orders; two million accesses per month.
And this is a centralized system. People kind of describe it that we've been lumped in with the distributor system. We ain't. We've got one big computer that sits in one room. We separate databases for some of it, but there's cross-links and cross-indexing. And we do the standardization centrally. We thought we'd just have everybody link them at their labs -- they don't; and we get experts and they can do it and it works out may be the way to do it.
The whole city has about 165,000 inpatient submissions per year, 450,000 ER visits and 2.7 million outpatient visits. Now, there are other visits to offices in other places that we don't count.
This is what Indianapolis looks like, a Blue State -- no, is it red?
[Laughter.]
DR. McDONALD: It's blue on this map, whatever color it really is.
And those "Hs" are hospitals. One of them, we lie about -- one of them is built but we're not really connected to it yet.
All the hospitals contribute discharge summaries, operative notes, radiology reports, path reports, cardiology reports, tumor registry data, and two-fifths of them contribute a whole lot more, and public health contributes data as well.
And I want to point out, though, this is far from everything. This is a lot, and a lot of it's text, so, I mean -- I didn't say laboratory; they also have all laboratory reports. But you can do stuff with text.
We've got a lot of other stuff going. We're trying to weave a bigger total. I'm not going to go into too much detail on that.
We are actually connected to RxHub, getting drug information on patients with ER, with permission to get it from anybody that's in an outpatient clinic. We have a tumor registry for the whole state now, 15 years of data. We're connecting to the EDs across the state for bio-surveillance. We have 36 of 134 hospitals.
We have an agreement with Medicaid to get all their data for the data, using it for clinical and research purposes under very restricted purposes. We almost have agreement with Wellpoint, which came from California to say hello to us in Indiana, and they collared some other operations that are kind of joining up.
Now, these are examples of functions that need standardization of patient ID and observation ID. So, flow sheet -- and if you could really read this slide, down below these "A's" and "B's" et cetera, some of this stuff comes from different places, and so we've indicated some of the different places by footnoting. But that required a standardizing effort to get the same hemoglobin from two different places to look like the hemoglobin or be called the hemoglobin. This didn't require standardizing -- I'm not sure of that one.
Business decision support, same thing, unless you're going to just stay in your own environment. Even there, since these hospitals joined together, the multiple hospitals, very often you've got multiple -- we've got three cardiac echo systems in our system, so even there you've got to do some standardizing to make it work.
This is a study of preventive reminders about flu shots, and a big effect with decision support, but you couldn't do that without standardization.
Epidemiology, there's just tremendous opportunities there, and I'm meaning epidemiology in a very broad -- with standardized databases. Even if we don't get into the new reaches of rich clinical data, just the stuff, the drugs, the diagnoses, the coded diagnoses.
We have two things we're especially proud of. We have kind of found -- not me, but some people in our group found an association between erythromycin and pyloric stenosis among newborns, a tenfold (?), and that was verified out of Tennessee in Wayne Ray's group but we did it first.
And there's a non-association between statin risk and liver disease. If you've got high enzymes, it doesn't mean you shouldn't use statins or can't use statins.
We have a tool now which goes across the city with the goal being to be able to do research without touching -- no-touch research -- so you never really touch any of the data. You just get back summary stuff.
So we have this SPIN tool where you can specify a cohort and then you can specify the variables you want to retrieve, and then you do the analyses and you get back statistical analysis. No, we haven't proven that this is going to be a break, but we think it'll make research a lot easier because you can explore a lot of things before you have to do the big work with the IRB and everything else.
This is what the form looks like. I did provide the slides, and if people really care about this, they can read it off them; this is too long a discussion.
This is what one of its cross-tabulations looks like, and you can do things like logistic regression. We use an "R," which is a one-letter programming language. It comes from Bell Labs. They called everything by one letter. If they did 26 programming languages, they would have been screwed, but "C" was the first one and then "X" and now "R."
And then the lessons learned from INPC. HL7 Version 2 works well for results delivery, but there are problems, and it's not the HL7 syntax. And this is something that maybe we need regulations or laws or something about. One to two percent of the messages are syntactically legal but stink. They're egregiously bad messages and there's just violent disregard for what the intent is of these messages.
And they all boil down to stuffing the wrong stuff into the wrong field. And it's just egregious. So you've got a field called Numeric Value, and its numbers will be there, and another field called Units, and you see Values and Units scrunched into the same field. You see Values and Units in normal ranges and discussions about where it was done all scrunched into the same field. And there's separate fields for those.
Then you'll see 12 results, like a Chem 12 scrunched into one field.
Literally, you can make those legal by just declaring it's a text field, and there's no way around that in any change in the syntax because you've got to be able to have a text field.
So we basically to have a semantic checker done. We have actually written a program called "HL7 Lint" which is a beginning on this and it actually looks for units in the wrong place and it finds most of the bad messages. Some of them aren't totally bad, but they're mostly bad.
And we had one of the experts at HL7 whose name you know who said, well, that's okay; that's what you're supposed to, make it a text when you can't fit it. Now -- hey, guys, put this stuff in the right place so we can process it with computers. And you could say if you get more than .4 percent, .3 percent bad messages by some semantic checker, you don't get paid that month, or some darn thing, I think we could fix this.
You know, I heard about the beauty in those. I love Stan's slide, all the wonderful things it can do. But when you really get down on the ground into the dust, it's like moths have eaten all the data. I mean, there's holes here, there's holes there, there's a missing thing there, you know?
We got all the drug data except, well, you know, we've got these HMO plans; they don't send us the drug data, you know, for Medicaid. And everywhere, wherever you go, you know, this moth has eaten a damn hole in it and we've got to worry about those moths, and some of it comes from these crappy messages where we get the moths.
Sorry about this -- it's a side issue. We've been working a long time, Stan --
[Laughter.]
DR. McDONALD: -- now to get good data we can use for a lot of things.
So a secondary use is public health. So we now do scan results from all the labs that we get data from, and we find reportable cases and we send them to the public health department sort of in one big package without any human review. I mean, except when it gets there and they go, ah, what's this!
But we find a lot more stuff. For a lot of the tests, it's not that hard. So if you've got a serology result, it says Hepatitis B, it's Hepatitis B, or an antigen. Or a DNA. The cultures get a little trickier, but with a little bit of parsing and all -- because it's all text; that's just how it is in blood cultures and effects. But it's from a menu, so you can parse them pretty easy. A given lab always says the same thing -- you know, it's normal, whatever they say -- so we can work it.
This sort of a draft of it. We get the inbound HL7. We use them for storing for clinical care. We filter them by the LOINC codes; we've already mapped in the LOINC codes. We then do some parsing inside the text to knock out some things.
Here the biggest regulatory good we could do for public health is require that labs must use the abnormal flag and mean it, so that instead having to parse through 5,000 TB cultures that are normal, but they say it 25 different ways, a lot of times saying no, might go back to tuberculosis, might go back to blah-blah-blah. Well, you can pick out the first "no" but these ellipses get tired.
And so when we first went into this, we found all kinds of positive TB because they had these strings of various TB variants and the "no" word was only in front of the first one. But if they just said "this is an abnormal one" in the result, we could really nail it pretty easily, and it's really sort of part of the HL7 thing, but they slip on that a lot in the culture area.
And then, we were developing this when there was a big outbreak of shigella in daycare centers and we weren't able to help this process, but retroactively we were able to find like three or four times more of it than they were able to find when we ran them through our system -- not three -- but some large number.
It's real time. We get 100 percent of the received. I think we found twice as many cases than the hospitals find by the usual method, and we get it eight days faster than the -- gee, I don't know what that stands for -- case signing -- and twice --
PARTICIPANT: Health Department.
DR. McDONALD: Health Department, yes, and thank you. And two days faster than the hospital case signing.
There's a lot more you can do, as Stan kind of alluded -- quality assurance, pay for performance, outcomes management. There's just a lot of things you can do with data, and a lot of this is not radical, wild stuff; the data's sort of sitting there. I'm not talking about getting deep into a discharge summary or the handwritten notes to figure things out. There are just good things, and I keep coming back to drug adverse effects, really some huge opportunities to do things with that. And we could find those early, drugs that are bad or bad for some purposes.
Actually, as an aside, I've always had the policy of don't use new drugs. You know, they're never that good, and they always something wrong and you find out five or six years later.
So I never used Vioxx. [Imitating patient] "But I really need it, Doc. I just love that drug. I saw it on TV."
[Laughter.]
DR. McDONALD: So the second option is capturing everything at the source.
And I actually want to put some cautions up against this. It's very attractive, I mean, if you capture it at the source, code it and do it standardized so we can use it across institutions.
I think we should first cash in on existing flows for secondary purposes. HEDIS does exactly that and uses existing data stuff and does a pretty good job on it. Now they're going to have to stretch further as they go further along.
I think the prime directive should be standardize what we have. Use it for both clinical and secondary purposes.
The sub prime directive is, if we do capture discrete data, capture it in a standardized and poolable form, one that you can use it for multiple places.
But data capture costs. That slide was supposed to be something really good, but I don't know what it was going to be.
[Laughter.]
DR. McDONALD: They said you have to close your portable PC now on the airplane now as I was coming down.
[Laughter.]
DR. McDONALD: So, there's a lot of questions. You know, there's a lot of research areas in here. Questions about capturing everything as computer-understandable form. We know almost nothing about the clinical content of the clinical data we collect. It's in rough form -- the handwritten notes, dictated notes. We really don't know what's there. We don't know about why clinicians record it and how they use and why they do it.
I mean, it could be as much as they use it to remind themselves at the next visit of what they were thinking about, so it may have very little value as sort of a formal, archival record for talking about the population and it may have huge value for making sure you can take care of that patient because you're using your own way.
And just converting current content to formal codes I don't think is going to be the answer, except when we can do it automatically, and there are some really nice opportunities for that, I think, hopefully.
Now, I think we've got to remember absolute ignorance. There was a great article in Science about 20 years; it talked about absolute ignorance. And that's the stuff -- you know what the melting point of lead is; it's that you didn't even know there was a question there.
[Laughter.]
DR. McDONALD: You know, you didn't know what you didn't know. It wasn't anything anyone ever thought of.
And that's the stuff that comes out of like Einstein, you know, when he came up with relativity, and there's a whole lot of things where they didn't know there was stuff like that. So we don't know what we don't know, and I think there's a lot of that in the discussion of computers and medicine. We really don't know nothing yet. We don't know what's what, I think, in areas.
And we ought to keep in mind that process, that we can just assume that we can do it -- you know, we got this and we can do that with it.
So I think we frequently confuse the computer with data. You know, we get the computer -- and this is to your point -- we got the computer now, we got the data. No, you don't. Now, there's a billion questions you can ask patients and no one ever asked those billion, and whatever this third party wants, this new idea is in the billion they haven't asked, those answers.
So, computerizing by itself doesn't produce data. It can, and it will, in some settings, and we've got to figure out what we want to ask and how we want to ask it.
So clinical data has extreme high dimensionality and a deep hierarchical and/or network structure. We don't fully understand it. But there's zillions of ways to ask things.
Users hate to read 20 variable standardized assessments, and we've got this beautiful data collection from nursing and nobody wants to look at it. I mean, it's useful for computer stuff because we actually use that to trigger things, but if you go down pages after pages --
Humans love well-formed human summaries, you know, discharge summaries. That's the first thing they read in our environment.
And there's good and bad things about both of them and we don't just know how they link or whether you can connect them to each other and we can't ask every question every time.
So we can't just map clinical narrative to codes, at least not for statistical use. We need to do this formal questionnaire development and reliability testing, which everybody hates to do -- I hate to do it. And then you get 20 questions to ask which you just thought you could do in one question.
So, things like the Hamilton score and the CAGE for alcoholism, Braden for the bed sore, these are things that formalize and standardize. There's lot of them, and they're good ones.
So that's the effort we have to think about doing in a lot more space to use these things as data, you know, on a formal statistical basis for a lot of the secondary purposes. And we require much tweaking of questions. You usually get good, reliable questions. How do we ask them so that people know what you meant always, the same way? Sometimes you have to ask more than one question. It sounds like it's redundant to get reliable answers.
So we don't know what content is worth doing this for, and we've got to sort of sort that out.
Now, and the other kind of things to think about -- the Ottawa Ankle rules. This kind of explains or highlights another thing we have to do as a research area.
So this is this guy named Stile(?) from Ottawa, I guess, because they name it the Ottawa Ankle rules. And they asked him: Who should we get X-rays on, ankle X-rays on? And the guy said, well, we don't know. If it feels right, you get it, you know?
And everybody said, well, you get it if X is true, you get it if Y is true, and they listed all the X and Ys, about a hundred variables, finding things. And then they said, let's just collect this on a thousand patients.
So they collected these hundred variables on a thousand patients. They got ankle X-rays on all of them.
And then they analyzed it, and they found out which of those hundred variables, about six of them, were predictive. And if you use those rules, you can save 25, 35 percent of the X-rays you would have done otherwise without being more specific.
And this is sort of what the process I think something like this has to be across a lot of medicine if we're going to rationalize it. And the other lesson here is that never are all the questions useful. I mean, I've never seen an analysis that didn't boil down a hundred questions to six or eight. I mean, there just isn't any predictive value, at least statistically, and I think probably really beyond all that redundancy. We don't know which of the hundred things we've asked about are the good ones.
So further, I don't think narrative can ever be replaced, at least in my lifetime. Of course, that may not be that long. The purpose may very local, as I said, to job providers' memory about how they thought about something or it may be for literature's sake or maybe for poetic sake, whatever. We're not going to get rid of that, I don't think.
We don't know the ideal tradeoff between narrative and structured information, but that's what we have to find. We have to find: What are those grabbers we should be always getting, you know, as a number, as a score or as a questionnaire, because it's just so valuable, or getting under certain circumstances because it's valuable?
We've got to do that homework, we've got to do that research. We can't just count on it happening because we've got computers. This is outside of the computer.
I think eventually we can expect the computer to understand the narrative to some degree and that'll help a lot, but there's a lot of research questions.
So, that, I guess, is the end of my talk, now that I've seen that I don't have any more slides. But I think that if we could kind of promote such research agenda on this, we can more done faster. And I don't mean just research, on racing to get -- but figuring out how to get from where we are, and not just putting computers in offices but figuring out what the questions should be, the variables should be, what are the predictor things.
In drug trials, they actually know these things, in a lot of drug trials, and they do these kind of surveys and questionnaires. And we ought to be thinking about which ones we should be asking in clinical care and when and how and why.
Thank you.
MR. REYNOLDS: Clem, thank you. Questions? Marjorie.
MS. GREENBERG: Well, I wanted to thank our current former members. I can't tell a lie: I provided one of the hugs.
[Laughter.]
DR. McDONALD: I want to come back!
MS. GREENBERG: It's great to see Clem again. And I want to thank Stan for bringing this to us and then bringing it back to us, and I frankly find it very exciting that the Committee is exploring these issues and questions and I do think that it really does belong not only on individual subcommittees but at the full Committee level.
I think only Simon was at the retreat of the Quality Workgroup.
DR. COHN: Yes.
MS. GREENBERG: Were the rest of you there?
DR. COHN: For one day.
MS. GREENBERG: What? And you were only able to be there part of the time. But, I mean, this is so related to what they spent a lot of time talking about.
Don Dettmer was there and John Halamka and -- well, your colleague from --
DR. HUFF: Brent James.
MS. GREENBERG: Yes, Brent James, et cetera. And they were talking about the -- and are now kind of trying to think this through about how they want to move ahead with their work plan, but exactly what you said, Clem -- just because we have IT and even electronic health records et cetera doesn't mean that we're going to have the road map for quality or have the answers to the quality.
And there are probably just a few places in the country that have as much development as you have there in Indianapolis and John Halamka, who is, you know, in Massachusetts also with a RHIO, where they have a very electronic environment.
We have all this, we have the lab, we have all of this, but we don't have the road map for quality and we haven't really thought through, and there isn't any kind of road map for how having all this IT and this electronic stuff will lead us to better quality data.
So I'd say at a minimum the Quality Workgroup needs to be a party to this, and I'll make sure that they get copies of these presentations and also refer them to the transcript when it's available.
But, you know, I think it's very much what they are thinking about.
Now, there are other applications, as you said, as well -- the population, the public health applications, would be more probably in the realm of the Populations Subcommittee and they are, I think, having a conference call in the next week or so to talk about their future work plan.
So this is really a very good time for this is really what I'm saying because there are several subcommittees, work groups to whom this is very relevant who are just thinking through their work plans now, and so, as was suggested by you, Stan, the Executive Subcommittee would be a good venue for this discussion, too, but I just wanted to reinforce that and to say that I do think we need to get this type of discussion before those groups sooner rather than later.
DR. McDONALD: I just wanted to not leave the impression -- I did, I really agreed with everything that Stan said, and there there is the issue about trying to the decision rules to kind of figure out higher level things.
But the other thing is that what happens at least I think at shops that have been informatically inclined for a long time is what the IT does do is getting people thinking maybe more rationally about what they're collecting, and so you do collect some things that you need and you should have collected as a formal piece of information.
And the idea of the to tell how well a diabetic sensation is going through a monofilament, that just could be one example. In this form that I described, 140 questions, actually it averages out about 70 on average.
It actually was a wonderful process because we worked the informatics with people, with nursing, to decide what they needed to collect in initial assessment.
And stuff like: Where do you go? Do you have a place to go when you leave here? You know, a nice thing to know, and early on especially.
But, you know, they were doing histories in physicals and repeating this stuff that everyone else was collecting and then they did the Kscore(?), you know, so we could intervene on people who were alcoholics. I think they did a little, a mini -- and I don't know if it's the Hamilton, but there's some other depression scores, a survey instrument, which could cue people to someone who's depressed and maybe again we could intervene.
So the informatics thinking is a helpful thing, not just the computer, to kind of decide why we're collecting what we're collecting and collect the stuff you'll make the basic decisions on.
MS. GREENBERG: Could I just add -- actually, I had a question, too, and that is whether in this distilling from all the different types of questions that one could ask down to what is really most predictive et cetera, in your work on this, have you used the RASH Analysis, or is there any particular analytical tools you've used or is it more consensus building or --
DR. McDONALD: Well, statistics, logistic regression, you know, that's what we use. I mean, the data says these things predict 80 -- well, you could usually pick more than one subset and come out very close.
But practically speaking, you know, after the tenth variable -- you don't need to collect everything in a formal way to get the same decision power, that's all, and it's usually a ten-to-one ratio of the variables to the particular instances (?).
MS. GREENBERG: Okay, thanks.
MR. REYNOLDS: Okay, thank you. Clem, we'll let you get to the airport. Why does it hit me that I can look and see a National Enquirer headline that Dr. Clement McDonald says moths are eating the important health data?
[Laughter.]
MR. REYNOLDS: Why does it look like it could turn into something. Thanks. It was really great having you.
DR. McDONALD: You've got to be careful of what you say!
MR. REYNOLDS: That's right. Thank you. Great seeing you again, too.
DR. McDONALD: Thank you.
MR. REYNOLDS: Okay. Vivian, they're going to get you set up and then we'll get started on that.
DR. COHN: Take a five-minute break?
MR. REYNOLDS: Why don't we do this?
MS. GREENBERG: Five-minute break.
MR. REYNOLDS: Why don't we just take the break, take a 15-minute break now, get it set up, and then we'll come up and we'll have two hours left to finish. Everybody okay with that? Let's do that.
(Brief recess.)
MR. REYNOLDS: Okay. Our next presenter today is Vivian Auld. She's going to cover the National Library of Medicine standards related activities. So, Vivian, thank you.
AGENDA ITEM: Presentation -- VIVIAN A. AULD
MS. AULD: Okay. Can you all hear me? Good.
Thank you for giving me this opportunity to talk to you today.
One of the reasons that I really wanted to talk with you is to give you an update of the various projects that NLM is doing relating to standards. Many of them are only known in pieces by different members of the Committee, and so I want to make sure that all of you have a complete picture. And it's not your fault that you don't have this complete picture; it's because we've been so busy doing, we haven't necessarily been telling people what we're doing. So I'd like to fix that today.
I just want to give you a little bit of context of why this is important and why we have a role in this. NLM's view is that electronic health data standards are a key component of the National Health Information Network and they're needed for efficient health care, research, public health and emergency detection and response.
Underlying NLM's interest in health data standards is the assumption that EHRs will make it easier to deliver relevant information at the time and place important decisions are actually being made.
And our specific interest is in the subset that deals with data content, standard vocabularies, mapping between clinical vocabularies, and administrative code sets.
And what I have here on the screen is a list of some of the activities that have been taking place in the last year that you all are extremely familiar with, starting with the creating of ONCHIT back in April, 2004; the HIT Strategic Framework; Secretary Leavitt's 500-day plan; the report on Nationwide Health Information Exchange, and the ONCHIT RFPs that have just been put out recently.
The reason that I mention these is because NLM has been working very hard to make sure that all of our programs and activities are aligned with these various projects and that we're contributing wherever we can. Both Dr. Lindberg and Betsy Humphreys have been in many, many conversations to make sure that we're on target for these.
And I have here a slide talking about NLM's long-range plan. The short story here is that it says in our long-range plan that we're going to do this, and so we are.
One other thing that I'll point out is that you made the recommendations to the Secretary that NLM act as a central coordinating body within HHS for Patient Medical Record Information terminologies and mapping recommendations or mapping between clinical and administrative data, and that is also something that we're actively working to make sure that we're supporting.
What this coordination covers is:
The uniform distribution of designated standard vocabularies through the Unified Medical Language System Metathesaurus.
Reducing peripheral overlap in establishing explicit relationships between the standard clinical vocabularies.
Aligning standard clinical vocabularies with standard record and message formats.
Mapping between standard clinical vocabularies and administrative code sets and/or other important vocabularies.
So what I'm going to do today is based on that definition of coordination and give you an overview of various projects that we're working on.
So, let's start with UMLS. I hope that you all recognize this page; this is our website, the main page for the UMLS, and this is where you can go to get information, documentation, find out when our last release is, et cetera, et cetera. And it also links you to all the various tools that are components of the UMLS.
In general, what's happening with the UMLS is that we're moving it from a research project to a production system. And this has several different steps that are rather painful to go through but the end result is going to be a very positive, sound system.
This includes transitioning from our research branch to our production branch. And the production branch are the same people who for all these many years have been -- they're the same departments that have been taking care of creation of Medline, so we have a lot of experience that we're building into this process.
Not only are we moving this from one set of staff to another but we're also migrating to new computer systems, both the hardware and the software, so that we are making sure that we're no longer following the research model but the production model, which has different requirements for firewalls and security et cetera, et cetera.
And we're also adding new staff to make sure that we're supporting improvements to the documentation, training people so that they know exactly what it is that they're using, quality assurance, and customer support.
And overall this movement from research to production is going to have the greatest effect on the Metathesaurus release files, but it's also going to have some reciprocal effect on some of the other tools within the UMLS.
And I just want to point out that this does not mean that the research branch is going to be out of the picture. They're a group of very talented individuals and we're going to give them the opportunity, because they're not worrying about day-to-day production, they'll be able to instead focus on continuing to update and bring in new features and capabilities of the UMLS.
So let's talk about the Metathesaurus itself.
The latest release that we have is 2005AB, which came out in June of this year, and there's a little over a million concepts. Concepts are terms that are grouped by meaning, so if you have one vocabulary that talks about myocardial infarction, another that talks about heart attack, they would be linked at the concept level.
There are 114 source vocabularies within the
UMLS, so it's rather big, and it represents 17 different languages.
MR. BLAIR: Could you just clarify that? What is the distinction -- maybe give an example of languages versus -- what was the first term you used? It was 114 --
MS. AULD: There's 114 sources within the UMLS, so by sources I mean SNOMED, RxNorm, LOINC, MeSH et cetera, et cetera; all the ICDs.
By different languages -- for example, we have MeSH translated into all 14 different languages, so you can get it in Spanish and German and French, et cetera.
MR. BLAIR: Thank you. It was probably on a slide; just couldn't see it.
MS. AULD: No, it's not.
MS. GREENBERG: We did need it.
MS. AULD: What we've been doing with the UMLS for the most part is in 2004 we made major changes to the structure of the Metathesaurus by introducing the Rich Release Format as an input and output format by changing it so that we can represent mappings and allowing for content view flags so that we can help people to create specialized subsets.
All of those background changes were made in 2004, and this year we're really starting to reach a point where we can start harvesting the fruit from all of these changes.
Because of all the transition efforts during 2005, we only have three updates. In 2006, we're going back to quarterly updates. The final release schedule that we're going to end up with sometime in the future is yet to be determined. It's really going to be a question of how are we going to synchronize the updates from the critical sources that are identified as standards? And that's actually an area where it's something that we're going to have to figure out as we go forward, but we're looking for input from the community to help us make sure that we're doing that correctly.
I was mentioning that we have the Rich Release Format as a standard submission format. This really makes it easier so that the source providers can give us their data in a uniform format so that we can quickly and efficiently get it into the UMLS. Right now, it generally takes roughly two months to invert a new source, and we'd like to cut that down so that we can do it much more quickly.
And we've been testing with HL7 code sets and with RxNorm, and we're hoping to add new sources in the very near future.
As an output device, the Rich Release Format enables us to insure that we have source transparency so
that we can insure that what SNOMED gives us, what the College of American Pathologists gives us for SNOMED, is the same thing that you can get out of it on the other end.
And the only other thing that I wanted to mention here was the content view flags, which are going to allow us to pre-define subsets. Right now, we only have these set up so you can get sources that don't have any copyright restrictions, but in the very near future we want to set this up so you can easily get all of the HIPAA standards or all of the CHI standards or the part of the CHI standards that are applicable to your situation.
So that brings us to MetamorphoSys, which is the installation program that goes along with the Metathesaurus. And our goal here is, because we have 11`4 sources, there are very few people, there's very few entities, who can make use of everything that's in the Metathesaurus. So we want to make it very easy for people to create a useful subset. And we've been making some changes in the last few months and we're going to continue to do so.
And as I was just commenting, there are currently three default subsets that you can specify within the Metathesaurus so that you can specify just Level 0 categories, or vocabularies, those that don't have copyright restrictions; the Level O plus SNOMED CT for use in the United States, and an RxNorm subset.
We also currently have a feature so that you can create your own subset or your own rules for creating a subset but you can't save that across versions of the UMLS, so in the next version that we're going to release in November, you will be able to migrate it from version to version.
And as I said, on the MetamorphoSys, this is where you'll be able to specify the HIPAA, the CHI, in the same subsets.
The Knowledge Source Server is our web-based system that allows you to search the UMLS without having to load it on your own system. It's also a program interface and it allows you to download the various components of the UMLS.
We are working on a new version for it. On the back end, this is going to provide implementing web services to make it easier for people to access the system. It's going to be XML-based.
On the front end, we're going to have portals that allow people to customize their view of the Metathesaurus. Instead of us telling you this is exactly how you should see it, we're going to let you say, this is how I want to use it.
We're going to have the prototype for that done by the AMIA meeting in 2005, later this year, and implementation in 2006.
And what I've listed on this page are just the other -- painted a complete picture of the UMLS, if you don't know it already. The other three components are the Semantic Network, the SPECIALIST Lexicon, and the natural language processing programs. None of those have any specific changes, so we won't talk about those anymore.
Also wanted to give you an update on RxNorm. I asked Dr. Nelson what he wanted me to talk about, and this is what he said, and if there's any mistakes, they're my mistakes, not his, because I didn't let him look at my slides.
We are currently producing monthly releases of RxNorm. We plan to have weekly releases available by the end of the year.
We are maintaining a harmony with the UMLS. Because RxNorm exists as a source in and of itself, that you can get stuff from the UMLS but it's also a source within the UMLS, we need to make sure that those are in synch.
So we're doing this two ways. First, we include RxNorm updates in every Metathesaurus release, and we also re-think Rx-Norm files after every Metathesaurus release.
And we've been making some major improvements in the process and product code. We've been learning a lot from what we've been doing over the last year. We no longer have the problem of returning RxNorm, which I'm sure will make many people happy. We've also been working a lot to improve how we're training staff so that we can bring more people on and make this a more efficient process.
We're incorporating more sources. For First DataBank and Micromedics, we have agreements signed and in place. Gold Standard, we're going to have an agreement any day now. Medi-Span, they are reviewing that agreement and we hope to have that in place very shortly. And we are also getting NDC codes where we're able to obtain them, which includes the FDA website, and (?) was just telling me that by October, we will be able to get those directly from them in a more complete format through the structured product label. It's a very good thing.
And this is a place where RxNorm is being put into use, the CHDR system. It's a joint DOD/VA project that facilitates the exchange of clinical data between their two independent systems.
So on the DOD side, you have their Clinical Data Repository that uses --
MR. BLAIR: You might have this on the chart, but could you tell me what "chedder" stands for -- c-h, what?
MS. AULD: That's what I'm just telling you now.
MR. BLAIR: I missed the acronym.
MS. AULD: Yes, it's the Clinical Data Repository/Health Data Repository.
MR. BLAIR: Thank you.
MS. AULD: And it consists of the DOD Clinical Data Repository, which uses First DataBank, and on the other side you have the VA Health Data Repository, which uses NDF/RT. And RxNorm is the link between the two that allows them to communicate, so it's mapping the First DataBank and NDF/RT so that they can work together.
And I believe that this system will be operational by the end of this year, I think October, but I'm not positive on that.
That's all I was going to cover with RxNorm.
I want to talk a little bit about some of the harmonization efforts that NLM is working on. Our primary focus is on insuring that the vocabularies that we directly support and maintain are in alignment, because we do not want to pay for the same thing to be created in more than one system unless we absolutely have to.
So the three that we are concerned with are LOINC, which we support through a contract with the Regenstrief Institute; RxNorm, which we directly developed, and SNOMED CT which, as you know, we have the contract and license agreement for use in the UMLS.
So, first let's talk about the harmonization between SNOMED and LOINC. This is actually our biggest concern, because there's a lot of overlap between SNOMED and LOINC.
We have been talking with both the College of American Pathologists and Regenstrief to come to an agreement for how we can resolve this.
One of the biggest factors affecting this is that CAP has an agreement in place with the National Health Service, the U.K. National Health Service, that limits what they can do.
The two options that we have for how to move forward on this are defining the specific scopes for SNOMED CT and LOINC such that any future development that they create for the two terminologies will be mutually exclusive. This probably isn't going to work because of that agreement with the National Health Service.
So our other option is to clarify the appropriate usage of each of these vocabularies within the U.S., and if we do so, we would be flagging that usage within the Metathesaurus through the Content V Flag. It's not the best solution, but it's probably the most workable solution at this point in time.
DR. FITZMAURICE: Excuse me, Vivian. What is "CVF?"
MS. AULD: That's the Content V Flag, which I talked about in the UMLS pages.
DR. FITZMAURICE: A flag on top of each variable that's either up or down?
MS. AULD: Effectively. It allows you to create that subset within the UMLS so that if something has a flag for usage of LOINC within a specific area, it's going to get that flag and you can just pull that subset.
DR. FITZMAURICE: Thank you.
MS. AULD: Clear as mud, isn't it?
We're also looking at harmonization between SNOMED and RxNorm. This one is colored by the same agreement between CAP and the National Health Service but it's not as much of a problem in this case.
SNOMED and RxNorm have different definitions, or different views, for what constitutes a drug, so what we're doing is within RX norm, we're making the links explicit so that it helps to clarify what those differences are and how they should work together. And this is something that we've gone a long ways towards creating all the necessary links but there's still a lot to be done.
And we're also, in a general sense of harmonization, making sure that we're coordinating all of our efforts with ONCHIT, especially in view of the RFP that they recently put out.
One other project that we are working on which half of it affects harmonization is the contract that we have in place between NLM and HL7. Their contract has two parts.
The first is aligning HL7 message standards with CHI standard vocabularies. This piece is under the auspices of NLM. And this really has two parts to it. We're specifying which subsets of standard vocabularies are valid for particular message segments, and we're also asking HL7 to replace the lists of coded values that they maintain with subsets of standard variables where feasible.
So if they have a set of coded values that is more appropriately in SNOMED, we're asking that they talk with CAP and make sure that those are over in SNOMED rather than HL7. And it's again we just don't want to end up covering the same information in two different places.
DR. COHN: Vivian, can you just clarify -- your slide says 2004.
MS. AULD: That's when the contract started.
DR. COHN: Oh, really? So it's been going on almost a year already.
MS. AULD: Yes.
DR. COHN: Okay, thank you.
MS. AULD: And the contract will last for three years total. The first part, the NLM-initiated part, will last the entire three years. The second part that I'll talk about in a minute will only last for two years unless we decide to extend it.
The second part of this contract is on behalf of ASPE. Suzie Burke-Bebee is the technical lead on the Federal side for this.
And what this is doing is creating implementation guides for transmitting an entire electronic health record between systems. And it's intended between systems that are not designed to talk to each other. We want to make it so that they can talk to each other.
They successfully designed a prototype and next April we're going to test it out between live systems. And we are on the schedule, I believe, to give a full presentation of this entire project in February of next year, I believe, so I won't waste your time with any more on that.
[Laughter.]
MS. AULD: The next thing that I want to talk about is the various mapping projects that are underway at NLM. And this probably is going to have the biggest impact to the conversation that you're talking about, secondary use of clinical data. There are 90 projects underway.
The first are looking at mapping between CHI standards and HIPAA code sets, and specifically what we're trying to facilitate here is mapping between clinical vocabularies and administrative vocabularies so that you can gather the information at the point of care and automatically generate appropriate billing data.
So the first map is SNOMED CT to ICD-9-CM, and it will eventually be SNOMED CT to ICD-10-CM. This map is being created by the College of American Pathologists, but we also have NCHS working with us on this, we have CMS working on it, we have AHIMA helping to validate it. And this will likely be the first draft mapping that we have available on the UMLS.
We're also working on SNOMED CT to CPT.
MR. BLAIR: What was on that last one?
MS. AULD: Yes?
MR. BLAIR: I'm sorry -- let me get over. On that last one, is there an approximate availability date?
MS. AULD: The draft map will be available by the end of this year. It's not determined yet when the final map will be available.
MR. BLAIR: And that's for the SNOMED to the HIPAA terminologies?
MS. AULD: That's for the SNOMED to ICD-9-CM. It will be available by the end of this year.
MR. BLAIR: Okay.
MS. AULD: The SNOMED CT to CPT, we have CAP and the American Medical Association working on this. We also have Kaiser, we have Simon, working on this as well. They've put together a proposal for how we might want to go forward with this. And again we have CMS working on this as well to make sure that we're fitting in to their goals as well. There's no estimation date for a draft map from that project.
The third one that we have is a mapping between LOINC and CPT, so for this one we have Regenstrief and the American Medical Association working on it. The draft map is being created by Intermountain Health Care under Stan's direction.
And that's probably going to be created in three different phases, the first phase effectively being the things that are just incredibly obvious -- A, no questions go to B. We can just take care of the ones that are very simple and get those out of the way.
And then it goes to the phases, to the most complex where we're just not at all clear on how you would map from one item to another and there's going to have to be some form of decision rules built into it.
So those are three CHI standard to HIPAA code sets that we're working on.
We are also working on projects that are mapping from SNOMED CT to other vocabularies. The first one is
MedDRA, which is the Medical Dictionary for Regulatory Affairs. And this is a mapping that we have been told, I think it's by the FDA, that they could definitely use this map, but the usage case is not completely clear, so we want to make sure that we have a very distinct usage case so that we know exactly what map needs to be created before we proceed any further. And I think we're close, but close can be a relative term.
We're also looking at mapping between SNOMED CT and the ICPC, which is the International Classification of Primary Care. In order to do that, we're going to make use of a map that already exists between SNOMED CT and ICD-10 which we're still trying to get a copy of. Many people, many good people, are working hard to try and facilitate that.
But on the other side, we have a map from ICD-10 to ICPC that we already have in the UMLS, and once we have that second piece, we'll be able to go directly from SNOMED to ICPC.
The next one is SNOMED CT to Medcin. Medcin is not currently a source within the UMLS, so we're working on getting that incorporated. It's not a straightforward process, so we have some very good people working on trying to figure out exactly what part of it should be represented and how and once that's done, then we can start working on the actual mapping.
SNOMED to MeSH, which is the NLM Medical Subject Headings, that's a project that's going to start up sometime this fall under Dr. Nelson's care and feeding.
And CAP has provided us with the mappings that they have between SNOMED CT and the various nursing vocabularies, specifically NIC, NOC and NANDA, so we have those available on the UMLS.
So, there are several key assumptions about mappings, but most of these came out in what I was just saying on the previous slide. But they are worth reiterating because this isn't going to work unless we follow these assumptions.
First, the participants in any mapping project have to include the producers of the vocabularies on both ends, prospective users and recipients of the output. And, for example, this would be health care providers, payers, as testers and validators. In other words, you have to make sure that you have all your bases covered in terms of who's developing it so that they can make appropriate changes to the vocabularies and also the people who are actually going to be using it so we can give them a worthwhile product.
Once you create a mapping, you have to update it every time the source on either end was updated, so we're trying to make sure that it is part of the process of updating a source to also update the map at the same time. We're trying to streamline that so that it doesn't become an added burden.
All these mappings are going to be distributed in the UMLS. They can also be distributed in other formats as well, but they're definitely going to be in the UMLS. And they're going to be governed by the terms applicable to the sources on both ends.
And mappings are still an R&D problem. It's not something that we can just give you a final product right now and know 100 percent that it's going to do everything it needs to do. It's something that we're going to put on the table, get people to use it, and then as we use it, we can improve it as we go.
And that's all I wanted to tell you. So, questions, please.
MR. REYNOLDS: Vivian, thank you very much. I know Jeff has a question first, then Michael.
MR. BLAIR: Vivian, thank you. A very informative presentation helps us -- where's that mike? Oh, gee, I haven't even asked a question yet. It just fell over.
[Laughter.]
MR. BLAIR: I had no idea that NLM was working on all of these mappings. I am delighted to hear that, and Godspeed.
MS. AULD: Thank you.
MR. BLAIR: I would be interested, very interested, if some of the major health care IT software development vendors, the folks that are producing commercial electronic health record systems -- have you begun to have interest in some of these mappings, and if so, or in SNOMED in particular or RxNorm? In short, if you have had interest, what areas are they most interested in, in terms of incorporating it or using it in their electronic health records?
MS. AULD: Very good question. I have had side conversations in various conferences of people who find out that we are working on various mapping projects and are extremely interested. But the conversation usually doesn't go beyond their saying "we see that it might possibly have an impact on development of our systems." But they don't go into specifics.
So, in other words, I'm getting a lot of people who are intrigued that we're doing all this work, but they're not telling me exactly how they're going to use it because they're waiting to see what we're going to produce first.
MR. BLAIR: That's understandable. So let me take the question one level further.
MS. AULD: Okay.
MR. BLAIR: Have any of these vendors indicated what they would need to enable or facilitate their adopting these terminologies? Have they expressed they need any types of support or incentives or anything else other than, you know, making these available?
MS. AULD: I don't have an answer to that.
MR. BLAIR: Okay.
MS. AULD: I'm not hearing answers to that question. But it's something that I'll definitely take back and see if we can explore that and try and get an answer to it.
MR. BLAIR: Or the question might even pursue it as the corollary -- what are the impediments to them rapidly adopting these terminologies and mappings when they're available? Vivian --
MS. AULD: Okay, I'll see if I can find out.
MR. REYNOLDS: Okay, we got Michael, Simon and then Steve.
DR. FITZMAURICE: Several questions. The MedDRA use case, if you map SNOMED CT to MedDRA and you map SNOMED CT to CPT, can you then map CPT to MedDRA using the daisy chain? And then can physicians report adverse drug events using CPT and this mapping will turn it into MedDRA?
MS. AULD: In theory, yes, definitely.
MR. BLAIR: Wow.
DR. FITZMAURICE: In theory, of course this can play, I guess, but is that maybe an end goal or --
MR. BLAIR: Wow.
DR. FITZMAURICE: -- is that something that would be desirable?
MS. AULD: If the use cases of the two mapping pieces fit nicely together, then yes, you can definitely create the map from MedDRA to CPT -- no, CPT to MedDRA.
DR. FITZMAURICE: The reason I'm asking is that Congress is considering bills to have patient safety events reported to a database, to a research agency perhaps such as AHRQ, and it would be very useful if this mapping could make things easier for physicians, for hospitals, to report something that they may want to report voluntarily. So that's what prompted that question.
DR. FITZMAURICE: Next question. When new codes are needed as a result of this mapping (?) -- if we had a SNOMED code, then it would map perfectly. Is CAP very amenable to producing these new codes that would improve the mapping?
MS. AULD: Yes, they've been very helpful, very interested in making sure that they do whatever needs to happen to make these usable products.
DR. FITZMAURICE: Great.
MS. AULD: They're definitely on board.
DR. FITZMAURICE: When does the current contract at NLM has with SNOMED run out, and what are the implications if it does run out?
MS. AULD: I believe it runs out the end of 2007. We have set this up so that if we choose not to renew it, we have the right to perpetually use the latest version of SNOMED in the UMLS and we can build on that to fill the future need.
DR. FITZMAURICE: It seems to me that five years may not be enough time for us to construct all the value of SNOMED and that if we could continue a good working relationship, maybe pay them something to continue making improvements, then that might be beneficial for all of us. Is that being thought of?
MS. AULD: Yes, it's being considered, it's being discussed. We're getting input from various other Federal agencies and those outside the government with their recommendations for whether we should or shouldn't renew it, what would be required in order for them to use it, things of this nature.
DR. FITZMAURICE: I've got two last questions.
[Laughter.]
DR. FITZMAURICE: I'm going to the first slide you have on Page 3.
MR. REYNOLDS: Michael, this would be considered a hearing.
[Laughter.]
DR. FITZMAURICE: It has to do with the RxNorm update and using RxNorm. As RxNorm has agreements with FDB, Micromedics and others, how can the users use their information content with the RxNorm link? I can envision a use case where, oh, now I'm using Micromedics; I want to use First DataBank. Can I daisy chain through the RxNorm name to use that information content, and then do I have to get licenses from both?
MS. AULD: That is the purpose behind RxNorm. It's intended to be a map between the various sources within it.
I should know, but I don't know whether or not you have to have agreements with the sources on either end. I would imagine that you do have to -- Randy's nodding his head -- because we're using the UMLS model wherever appropriate and that is definitely the model that we use within the UMLS. So I would expect that you would have to have agreements with both..
DR. FITZMAURICE: The last question is: In the past two years, AHRQ has been very happy to support NLM to the tunes of several millions of dollars to do a lot of work. Can you tell us --
MS. AULD: I forgot to mention how much we appreciate that.
[Laughter.]
DR. FITZMAURICE: Which work is being funded by AHRQ of what you presented?
MS. AULD: Which is being supported by AHRQ? The mapping efforts are definitely being supported. A lot of the NLM/HL7 contract on what I call the vocabulary side is being supported by it. RxNorm development is definitely being supported by the funds from AHRQ.
There are pieces of the UMLS, but I couldn't tell you expressly which those are. And I mentioned that we have a contract with Regenstrief for the development of LOINC; you're partially covering that.
I think those are the big ones.
DR. FITZMAURICE: Great. And we're very happy to do it because you have the expertise that we don't have, and it's a pleasure to help work together on patient safety issues.
MS. AULD: We definitely appreciate it. Thank you.
MR. REYNOLDS: Simon?
DR. COHN: Gosh, after that, I'm not sure -- it's hard to even think of a question you haven't asked, and further I'm precluded from asking any of the really good questions, but I'll ask one anyway.
This morning, we actually heard a number of presentations from people in NCPDP --
MS. AULD: I apologize for not being here.
DR. COHN: Well, that's no problem, but we told them we would ask you a question about all of it. And I don't know whether this is an issue that is related to lack of communication, lack of understanding, or really lack of functionality, but a number of them, as they talked about obviously expanding into SIGs issues relating to -- gosh, what was it? --
MS. GREENBERG: Prior authorization.
DR. COHN: -- prior authorization, et cetera, kept asking for -- geez, really what we need to do is to have access to what they described as a central information code set repository, so they sort of knew what was there, what was out there in existence, so they weren't out there replicating everything and starting from scratch.
And obviously I couldn't ask you why there was this gap. What are we missing here? In some ways, you would think that the Metathesaurus might be such a repository, but maybe that's not exactly what they need, or maybe there's something that's more than what the Metathesaurus is. So maybe you can help us with this?
MS. AULD: Well, let me ask a question back. Are they talking about a description of the entire code set or are they talking about specifics of the code set?
DR. COHN: I think they were talking about a repository where they can go to to get all of the codes that they might need for whatever purpose.
DR. FITZMAURICE: They may be subsets, but they're subsets for a particular application, say, of SNOMED, for example.
DR. HUFF: For example, in the coded SIG, you know, there's a part that describes the kind of actions where you're supposed to take the drug or you're supposed to rub the drug on your skin. There are routes and that sort of stuff. And they need a particular code set that fits into their model for that exact purpose.
And what they're looking for is to say, well, we can come up with a content for now, but we don't want to keep that forever, we don't want to distribute it to everybody. We want it someplace where everybody can get who wants to use this new standard coded SIG.
And I think the question is, you know: Is that something you guys see within your purview --
DR. COHN: Well, I think I also heard it in a slightly different way also. They didn't want to even make it up. They wanted to go to a place and identify these 50
terms or these hundred terms and be able to pull them in so they didn't even have to make them up. Stan, am I off on that? That was the other piece.
DR. HUFF: Well, I think yes. I think I probably heard both things, but, I mean, in some cases I think they are the experts that would come up with a list; in other cases they wanted to say, gee, we think it's likely that somebody else has done this, you know? Is there some place to go to find them, kind of thing, so --
MS. AULD: From what you're describing, I think the Content V Flag within the UMLS would probably be a very good way to pull those subsets together, but that's with the assumption that that code set already exists within the UMLS. As long as it already exists there, we could definitely create these subsets. We just need somebody to give them to us or tell us what's needed so that we can work with the experts to pull those together.
If the codes don't already exist, I would still want to hear about it because then we can help to facilitate in making sure that the correct people are coming together and creating them and putting them into a format so that people can use it.
So I think my short answer would be: Whoever made that comment this morning, come talk to me and tell me what is needed so that we can find a solution.
I would think that, depending upon the exact nature of what it is that they are looking for, it may or may not make sense for it to be in the UMLS. But even if it's not, we would want to work with you to make sure that it's in the appropriate place.
MR. REYNOLDS: Okay, Steve?
DR. STEINDEL: Yes, thank you. A lot going on, Vivian.
MS. AULD: Yes.
DR. STEINDEL: I'm sure you're having fun.
MS. AULD: I am.
DR. STEINDEL: A couple of observations and questions.
First of all, you made the comment and I think it's been lost. You made it several times but I don't want it to get lost. These mapping projects, I think we really need emphasize that they're use case specific.
MS. AULD: Definitely.
DR. STEINDEL: That just because we have a map to this and a map to that, it is a use case specific map and it can be used for that purpose and validated for that purpose. But if we try to use that map for another purpose, it may not work.
MS. AULD: And to take that one step further, we definitely envision that there will be multiple use cases between two specific sources. So there's not just going to be one SNOMED to -- for example -- CPT mapping; there is likely to be several mappings, depending on the use case.
DR. STEINDEL: That brings to my comment, because I'm very concerned about the comment that was made about the -- well, ICPC has a map to ICD-10 and once we map SNOMED to ICD-10, then we automatically get a map to ICPC.
MS. AULD: In this case, that does work --
DR. STEINDEL: Yes, I imagine in this particular case, it does.
MS. AULD: -- because the usage cases do match up --
DR. STEINDEL: Yes, but --
MS. AULD: -- we believe.
DR. STEINDEL: -- it's not going to be a full map to ICPC and SNOMED.
MS. AULD: No.
DR. STEINDEL: So, you know, I think --
MS. AULD: Thank you for clarifying that.
DR. STEINDEL: -- also the same analogy that Mike was using where we have a map to this to CPT and a map to that to CPT, therefore, we must have a map between that -- it's the same type of analogy here. So I think we need to be careful with extending these thoughts about mapping.
MS. AULD: Exactly. And that's why my response to him was it depends on the use case.
DR. STEINDEL: It's on the use case. And that's what caused me to emphasize, re-emphasize, so we make sure that it's in multiple places in the transcript.
MS. AULD: Exactly.
DR. STEINDEL: Then to my specific question, and this was a question that this Committee had a lot of problems getting an answer to when we were looking at PMRI terminology, and that is: What is the penetration of use of SNOMED CT in this country now that the license is in place and it has been available through the UMS for about a year? Does the Library have any indication of that?
MS. AULD: No, and that is actually something -- in preparing for this testimony, I was talking with various people around the Library working with UMLS, and one of the things that we would very much like to do is find out how many people are actually using the UMLS as a source for the various vocabularies. We don't have an answer to that. We know how many users we have, we know how many people are downloading it, but we don't know necessarily what they're using it for and how.
We do collect usage information once a year, but we're still in the process of developing a good questionnaire so we can get useful information. And part of that will show us in the future how many people are using it to get SNOMED CT.
For the moment, most of the responses that we're getting show that the UMLS is being used for research but not much beyond that.
DR. STEINDEL: But that still doesn't indicate that they're using SNOMED CT?
MS. AULD: No. We don't have anything specific for that at this point. But it's definitely something that we want to resolve, because on one hand it's nice to have 114 different sources because you can encompass a very broad spectrum, but is it the right spectrum, is it what is really needed out there? And are there pieces of that that we're expending resources to maintain that don't necessarily need to be maintained?
That's something we would like an answer to, and at some point in the future I'd like to be able to give you an answer to this question, but I don't have one now.
DR. STEINDEL: Thank you.
MR. REYNOLDS: Jeff has a follow-on on that and then Randy and then that's it for this particular session.
MR. BLAIR: A couple of dimensions to this in terms of the acceptance and adoption of SNOMED CT.
I've heard some criticisms of the direction in the U.S. to utilize SNOMED CT and the UMLS, and it's hard for me with my limited knowledge to sort out how much of that is an opposition because SNOMED is not licensed for free in those other countries that are doing the criticism versus valid criticisms.
And as you probably know, Vivian, I and many of us on this Subcommittee have strongly supported the idea of clinically specific terminologies, SNOMED, LOINC and RxNorm being at the core. I would hate to see all of the progress that we've made derailed if some of those criticisms turn out to be accurate and we haven't prepared Congress or the Administration to realize that there are impediments to adoption that we don't have in our plans.
So it kind of gets back to that other comment that I made, which is if vendors haven't been adopting it, what do they see as the impediments? They may or may not be similar to the international criticisms. But I think we ought to be aware of those criticisms and make sure that they're projected in our plans so that somebody doesn't come up and blindside us in the future, saying we've gone down this path, that it's flawed, because we haven't addressed X and X and X and X.
So the other piece that I might suggest is that, assuming you're familiar with the GELLO initiative? --
MS. AULD: Yes.
MR. BLAIR: Great. And I would hope that since that seems to be an effort to facilitate the standardization and exchange of the rules for clinical decision support, and since SNOMED is probably a very likely candidate to be part of that, I would hope that there's good and close communications between NLM and SNOMED and the GELLO initiative.
MS. AULD: I do not know what our relationship is at this point in time, but I will definitely take that back to Betsy and see what we can do to facilitate that.
MR. BLAIR: Thanks.
MS. AULD: Definitely.
MR. REYNOLDS: Okay, Randy?
DR. LEVIN: Just go back to this -- Randy Levin from FDA -- go back to something Simon brought up about the SIGs and the terminologies for SIGs, that FDA has been working with HL7 and other groups to harmonize on the dosage forms and working with the Europeans, Japanese and the Canadians on standards for units and measures for routes of administration as well as dosage forms and standards for packaging.
We've been working with NCI to put that with their Enterprise vocabulary service, to put that all in the NCI thesaurus, which will make its way into the UMLS, so --
MS. AULD: Yes.
DR. LEVIN: -- just to answer that, that we have terminologies for many of those things that will eventually make it into the UMLS.
DR. FITZMAURICE: A question of Randy -- are those terminologies compatible with what terminologies we're using in the United States, such as the SNOMED, or any other U.S. terminologies?
DR. LEVIN: It's compatible with the terminologies that we use for regulatory purposes and that would be in the labeling for each one of those.
DR. FITZMAURICE: Compatible with MedDRA?
DR. LEVIN: MedDRA doesn't have those terminologies but it's compatible with our regulatory and as well as the regulatory purposes of these other regions.
DR. FITZMAURICE: And the regulatory terminology is in UMLS?
DR. LEVIN: It will make its way into UMLS because we're collaborating with the NCI, using their thesaurus for our terminology.
DR. FITZMAURICE: Okay.
MS. AULD: I don't remember the schedule, but I know it's on the schedule. It's -- yes.
DR. FITZMAURICE: It makes sense, yes. NLM is the focal point for the terminologies. We're putting everything else there.
MS. AULD: Yes.
MR. REYNOLDS: Vivian, thank you.
MS. AULD: Can I make one last comment about SNOMED before --
One thing to remember when you're talking about, when you're hearing criticisms about, the usefulness of SNOMED and impediments to adoption is the reason that NLM supported and worked so hard to establish the license with the College of American Pathologists is because all the evidence was pointing to SNOMED being the best choice for that segment.
And so our goal was to remove the barrier of cost as an impediment to use. Now that we've removed that barrier, we want people to start using it and give feedback and work to try and improve it to see whether or not it really is the best solution or whether something else needs to happen.
So I'm glad that people are looking at it critically, but their criticism needs to be constructive and coming to either NLM or CAP so that we can feed it back into the process and improve it.
MR. REYNOLDS: Okay. Vivian, thank you --
MS. AULD: You're welcome. Thank you.
MR. REYNOLDS: -- very much. Our next panel that will come up --
MS. WARREN: Just one comment, Vivian. When you're seeing how many people are downloading SNOMED from the UMLS, I've actually done that myself. It takes a very long time and it would be cheaper for me to buy it from CAP on a disk that's already done. So you might want to look at talking to CAP about how many people are coming directly to them and buying it on a CD as opposed to just downloading it there.
MS. AULD: Okay.
DR. STEINDEL: A corollary to that. We've made a decision at CDC to extract it from UMLS and put it in a format that we can provide to our public health partners --
MS. AULD: Oh, okay.
DR. STEINDEL: -- because of what --
MS. AULD: Because of that very issue, okay.
DR. FITZMAURICE: So does that mean that everybody can be your public health partner and get it for free?
DR. STEINDEL: Everybody except certain agencies within HHS.
[Laughter.]
MS. AULD: Thank you all.
MR. REYNOLDS: That was the friendly banter portion of the program.
[Laughter.]
MR. REYNOLDS: Okay, our next group, I'll go ahead and start introducing them while we're getting set up. We're going to continue to talk about secondary use of clinical data to support billing, SNOMED CT and ICD-9-CM, James Campbell from University of Nebraska.
And then we'll move directly into auto-assisted coding. Valerie Watzlaf of AHIMA and Mary Stanfill of AHIMA will take us through that, so, James, as soon as you're set up, you've got the ball. And we welcome all of you.
AGENDA ITEM: Presentation -- DR. JAMES R. CAMPBELL
DR. CAMPBELL: Good afternoon, Mr. Chairman. Thank you for the invitation to come and speak. My name is Jim Campbell. I'm an internist at the University of Nebraska Medical Center, and I think by way of full disclosure, I'm also a working member of the Clinical LOINC Committee and of the HL7 Clinical Decision Support Committee; I'm a member of the SNOMED editorial board and I chair the mapping activity for that group.
MR. REYNOLDS: You should be sitting up here.
[Laughter.]
DR. CAMPBELL: As I was preparing my thoughts for this presentation, I was musing on the material that was sent out, and I was observing this morning that in an age where, and when, we are successful in implementing a complete, nationwide, decentralized NHII-based clinical record, all clinical information becomes of secondary use in a statistical sense.
And so I wanted to respond to the Committee's questions in a little bit more basic way, but I think in one that will be relevant, and in light of Ms. Auld's comments, I also find that some of the material that I have prepared hits upon similar areas and so I'll try and skim over those where appropriate and/or contrast issues where necessary.
In general, I would like to hearken back very briefly to the information architecture that the Committee proposed back in 2003 for national vocabulary convergence. I would like to talk a little bit about problems with use and re-use of information within each of those three clinical layers and then comment just briefly on issues of knowledge information and what I call the "inferred medical record" and what is ahead for that.
I don't think that I need to basically revisit what has happened, and I really applaud the Committee for their works in helping to push information technology convergence forward.
All of this is based upon a three-layer model in which core reference terminologies serve the central care needs of patient systems. It integrates closely with legacy clinical data sets that have to be brought within the core and also deals with external or administrative systems in such a way that the use cases for those systems or for those users are met.
And this is where mapping primarily comes in, but I'm going to talk a little bit more in detail about what I call mapping in just a little bit.
The core reference terminologies that we're talking about, of course, are SNOMED CT, LOINC, RxNorm and its relationships to NDFRT and the unified medical device nomenclature system.
And I just want to revisit very briefly a definition that may not be familiar to all our audience, and that is that a reference terminology is a concept-based vocabulary system which employs compositional forms -- that is, it pieces together necessary elements of a definition in order to come up with a definition that a computer can understand about that concept.
And basically it ties that all together within a network of meaning or relationships which is distributed along with the terminology, and that is a necessary and integral part of the whole, if you will, if you're going to deliver on all of the vision of what reference terminology should provide for clinical information systems. And I'll come back to that briefly.
Just to review quickly Layers 2 and 3 in the clinical code sets, or legacy schemes, we have nursing classifications, ICFDH, ICPC and a variety of drug databases in use in the U.S.
And then of course in the administrative classifications, we've got systems like MedDRA, DSM, ICD-9, ICD-10, CPT, common dental terminology, national drug codes, HCPCs et cetera.
Starting then with a discussion about re-use of information within the core itself, I would just like to revisit briefly why a single convergent model is necessary for core content.
Interoperability basically is all about re-use of information between systems so that, for example, my clinical system can send out a query, gather information on my patient from other systems, bring it together in some sort of a homogeneous way. This requires agreement on the fundamental elements which define the concept. Okay, that's central to reference terminology.
In addition, decision support technologies demand the additional relationships of the reference terminology. Those relationships are just as much as part of it as the terms and the concept identifiers that go along, because without that, the whole thing basically falls apart and the computer can no longer understand what's happening.
So, both of these elements basically must be consistent and robust if we are going to have shared systems and if we're going to have decision support and inference.
So, important shared use cases for the core reference terminologies, those four that we're talking about, are comprehensive, accurate and scaleable recording of all health care events, and also, sharing of clinical information in support of the NHII vision.
Now, I would suggest to you right now that we still have some barriers to the appropriate shared use of information within the core. And some of that inconsistency comes up because of differences in granularity and definition between those few areas where we still have overlapping classes, and as all of you described those very well.
And so I'll not dwell on this too much but, basically, duplications within this reference terminology core create data islands, because if we have systems recording in these different duplicate codes, then basically we can support messaging, we can send them information back and forth, but the machines cannot understand it in an interoperable way.
And the three particular areas, some of which have already mentioned, are SNOMED CT observables and LOINC, SNOMED CT medicinal products, along with NDFRT and the RxNorm clinical drugs. And then finally, one that's a little bit lower down on the clinical radar perhaps, but
SNOMED CT physical objects and the UMDNS.
If you take a look at what problem this duplication creates for clinical systems, here we have a representation, let's say in my system, of systolic blood pressure in SNOMED CT. And we have another representation, in a different system, of that same concept in clinical LOINC, okay? We have definitions; we can message them back and forth, but we can't share meaning.
Now, presumably we can create equivalence mapping between the two and resolve the question of making sure that I store it in my system the correct way, but basically mapping does not provide complete clinical decision support because of those other variables that I was talking about, basically the relationships, which are important elements of the reference terminologies.
So you can imagine -- and this is what I would hope would happen within the discussions and so forth that are occurring within the National Library of Medicine, is that these two discrepant models are basically replaced by a shared model which pulls together all of the necessary meaning from the two systems to uniquely define the concept, to easily equate it between the two systems, and to give us all the necessary information that we need for clinical decision support as well.
Such integration of core content within a shared model converges the editorial effort, assures interoperable content, and, finally, eliminates duplication as we go down the road. As Ms. Ault said, I think that creating clear boundaries and understanding of editorial responsibility and how we share work on this is really important to re-use within the core.
Now, right now barriers to some of that convergence are:
We don't necessarily have agreement upon the model for those overlap demands.
There needs to be a commitment from the terminology developers so that convergence can occur.
It requires shared funding on business plan, which obviously has to be developed.
And we've also got to recognize that the vendor community and the user community for sure by and large do not have a very good understanding of this. In fact, they find the whole area confusing, and they just want something delivered that they can use reliably and reproducibly, and I think it's our duty to give that to them.
So what comments I would make in terms of re-use of information within the core -- I think it's important to our success overall that further consolidation efforts, which are going on, I think are important to promote them and to encourage them, to endorse the NLM development of a single convergent model so that we can have a road map for how we're going to bring these systems together.
And finally, I think there's also educational efforts that need to happen to basically begin to bring our vendor community and our clinical users up to speed as to how all of this is going to fall together.
Now, I'm going to move from the core out to the Layer 2, where we're talking about clinical legacy systems that are important to the core because of their content but are not represented well there right now. And those are basically the systems I mentioned. Arguably, the most important are those for primary care and nursing, but I think you probably have some discussion about prior authorization. Nonetheless, I think we know the targets we're talking about.
I think it's important to understand that the goals of Layer 2 consolidation are not simply mapping, and I want to define mapping in just a second in a way which I hope makes that clear, because in Layer 2 we basically have, and we recognize the fact, that there is content information in many of these systems that is not now in our core systems. And this was especially true, for example, in nursing for a long time.
So we have basically two goals to accomplish when we're merging Layer 2 systems.
First of all, we have to model the clinical content in such a way that it becomes consistent with the core. And then, secondly, we have to create the mapping so that legacy data can be used for research and education.
Now, I think the best example of success here has been what's been going on within the nursing community in terms of bringing the nursing classification systems into SNOMED CT.
There's been a convergent nursing terminology work group now that's been meeting for four to five years that's been shepherding this effort. Members of this committee have basically chaired and directed that effort. And, by and large today, we can see represented within that core are the nursing concepts that we need, plus the maps that link them outward, as we saw from the NLM presentation earlier.
A caution here: I think we're talking about two different maps, okay? But I wanted to bring up a project which basically the primary care work group of the College of American Pathologists has been working on, and that's NICPC.
Because of the fact that we believe it's important content, because of the fact we believe it needs to be clearly represented within the core clinical systems, this is something that the primary care working group has
been pushing forward first as a modeling effort to make sure that we have all the content and then secondly as a map.
Now, I would observe, in answer to Dr. Fitzmaurice's earlier question, if you map A to B and B to C and C to D, and if you have an equivalence-based map, and even if you control all the variables, the frequency of correctness of that map will always be less than one. And how far less than one it will be will depend very much, very heavily upon what is the difference in granularity, the editorial assumptions, and the content focus of these systems.
So, mapping always gets you part of the way, but it doesn't get you all of the way, especially if your goal is to transfer 100 percent of meaning.
Now, within this ICPC modeling project that we're proposing from CAP, and I'd be glad to share the working documents with anybody who would like to see those, we've developed use cases to assure the content coverage is carried forward for reason for encounter and also all of the concepts in use in the primary care records.
But at the same time, this would support future research with clinical systems that have employed ICPC for research in the past.
To give you a little bit of an idea about
complexity, I want to talk in just a second about why we're interested in knowledge-based maps, or rule-based maps, but this is one concept out of SNOMED and how it might map to ICPC, where you can see we have up to 15 separate rules that carry that one individual concept into different ICPC codes.
The difference here is one of granularity. Basically, we're talking about codes, or classifications, which focus on very different levels in the clinical record. Both are correct, both have important information, but a simple equivalence map is probably not going to be adequate for our ICPC map insofar as we have organized it.
This is something that basically we have developed the use case for, and I'm going to discuss the use case that we distributed to you for ICD-9 CM in just a second. This has been reviewed and endorsed by the SNOMED and ICPC community. We are basically putting together the work plan and the project costs. We're currently seeking endorsement from primary care organizations in the U.S. to see if there's a buy-in as to the need for this, with a notion that we were going to submit it to the National Library of Medicine as a funded project.
Now, I'm pretty sure this is not the project you were talking about just a little bit earlier.
MS. AULD: Yes, it's a separate project.
DR. CAMPBELL: Okay. So you can see that we've already got examples of the right hand and the left hand not necessarily always knowing what each other are doing.
But this, I believe, is an important area, and whatever is the ultimate architecture that needs to be adopted, you know, that's a further discussion, but I think we recognize the importance of this to overall utility of clinical information systems.
Now, there's a number of things that we need to deal with in terms of barriers to Layer 2 harmonization.
First of all, we've got the issues of expansion of the convergent model. Secondly, we've got cost sharing and funding, which basically has to be negotiated piece by piece every step of the way.
And then something that I wanted to get to, and that is there is very little information, and this is something that Ms. Ault said earlier, there's very little scientific information about what constitutes good mapping, okay?
And I want to define mapping very specifically, as the process of creating interoperable links from a fully coordinated concept within a reference terminology to one or more assigned codes in a legacy vocabulary or administrative classification.
Now, there's lots of times that mapping is applied to other things, and I'm not trying to say that that is wrong, but this is what I'm talking about today when I'm talking about mapping because it specifically relates from going to the core concept where clinical records are out to the external schemes where we need to, let's say, generate the ICD-9 CM code, okay?
Now, maps have been in use for a long time. Back home, I've used a computerized record for 22 years. For the past eight years, I've used SNOMED CT in our clinical system, okay? And we have employed maps throughout that entire time in use.
This, for example, is a clinical care screen from one of my patients where you can see the patient problem list. And down the center right there, you basically see the problem list and the interface terminology, which is my term set, if you will, of SNOMED CT, my subset, that allows me to pick and choose into my problem list quickly and easily.
You can see that I've selected my problems for today's visit, okay, as a part of my service recognition. But then in the background the maps that we maintain from SNOMED CT to ICD-9-CM have basically supplied the billing codes which go out on my bill, okay?
This is an example that is probably state-of-the-art in terms of what mapping is like today -- one to one,
or equivalency. The problem is that, in my experience, error rates in these conventional maps are high, and disagreement upon what is a correct map are frequent, okay?
And these are problems which I think we need to deal with, as I think was mentioned earlier. These are technical challenges.
I'd like to enumerate some of the issues that we have to deal with when we're talking about problems with mapping between vocabulary systems.
First of all, there's properties of the vocabulary systems themselves. There's differences in scope and editorial policy. These create differences in assumptions about how things should be organized and at what level of granularity, for example, if they exist.
Differences in granularity of the classification systems also create problems which are always dealt with in these one-to-one maps incorporating a lot of assumptions and heuristics. And the deeper you dig into them, the more you realize just how difficult it is to understand them many times, the result being, as Dr. Steindel had mentioned earlier, that the use case has heavy impact upon a lot of these assumptions and that a universal solution is unlikely to happen except in the simplest of cases.
Other problems with the vocabulary systems that create technical barriers to the mapping include problems of context, okay, and this also goes in part to the issue of use case, that basically it deals with the fact that many of the complex classification systems have rules built into them which specifically refer to issues outside of the simple concept itself.
For example, ICD-9-CM basically says this is excluded if such-and-such is true in the patient record. That's a patient level exclusion.
There are also context restrictions based on encounter information and episode of care that are easily demonstrable within the ICD-9 constructs.
And the point is, these need to be dealt with in the maps if you're actually going to be successful and have a high rate of accuracy.
There are additional problems of update frequencies and map versioning.
There are problems within the vendor community, too, one of them being that when the vendor implements a map, there's always an assumption about their use case which may or may not correspond with the use case for which the map was developed.
In addition, every vendor has their own information model, which means that they segregate data within their clinical systems in different ways.
And so the question of what is being mapped frequently differs between clinical systems, and this in itself creates challenges and problems which create technical error.
As Clem had mentioned earlier today, within all of this there is little or no scientific research which really supports an understanding of what needs to be done.
Now, from the standpoint of people who at least have approached me and what I've heard about back within the SNOMED community, the financial and reimbursement use cases are arguably some of the most important to penetration of clinical information systems in the U.S. That's just my personal observation.
In addition, though, we have other clinical systems and classifications that we need to think about mapping. Right now, I think Ms. Ault has already nicely summarized what maps are available, and as a matter of fact, she certainly told me a few things that I didn't know.
I do want to mention and talk about a little bit more detail, the reimbursement use case map that basically we're working on now in the mapping work group, and there's been a hand-out distributed, and I think we have copies for the audience, too, if they wish, on what the use case and definition of procedures would look like for the ICD-9-CM SNOMED reimbursement use case map.
And I provide that basically -- I suspect that most of you don't need more nighttime reading, but that it gives you a little bit of an inkling in terms of some of the complexities that have to be dealt with in terms of managing the assumptions and so forth that are involved in these maps.
But basically this map is designed to support near-complete or near-automatic ICD-9 reporting from SNOMED clinical records to manage the sources of technical error that I have talked about as much as we can to reduce the error to the smallest manageable portion, to develop a paradigm which hopefully will be transferable to future maps, because ICD-10-CM is going to be here real quick.
Fortunately, many of the constructs are similar, so I think that a lot of what we've been working on will carry over.
The scope of this map is SNOMED disorders, clinical findings and context-dependent categories such as family history and the like, with a goal of basically supporting U.S. vendors in implementing better clinical information systems.
All of this is basically organized around managing that ICD-9-CM map for reimbursement support and making it more effective and to manage context in ways which we haven't been able to deal with before, namely, by extension in the knowledge-based systems.
So, for example, in this small snapshot, if you will, from the map, you can see that we mapped two SNOMED codes, the first, AIDS with volume depletion, and the second, perineal pain, into their appropriate ICD-9 codes.
Now, the first concept happens to have a dual map, which means there has to be two ICD codes that come out of that if you're going to be correct, and that's handled within the map groups.
So in the first case, the first map group always maps AIDS the same way. But you can see that the question of the volume loss is managed very differently, depending upon other patient-level exclusions -- that is, whether there's been post-operative shock or whether there's been traumatic shock that's contributed to the volume loss.
And so this is an example of the way that patient context creeps into the map. It has to be managed, if you will, if you're going to be successful.
Likewise, in the lower example, you can see that whether the patient is a male or a female changes the coding substantially.
And these are just simple examples that are present in large volume in the ICD map.
Now, we're in the position hopefully to release the majority of that for review later this year because we've basically already gone through a lot of the first round review. But we recognize the fact there's additional clinical relevance that must be dealt with and we also want to move it into a standards-based environment.
So, for those of you who have been long anticipating GELLO, which is an acronym for guideline expression language, here is an example of those same rules which have incorporated the use of the GELLO paradigm along with the HL7 RIM -- by that I mean a definition of what we expect the fields to be in the record and how the data query then would look in terms of support of those same rules in a standard construct which controls for the information model and which controls for the expression language as well as the vocabularies themselves.
So in terms of where that all is right now, the use case documentation has been developed and if you're interested, you can look at the hand-out. The project has been proposed to NLM and we've set up a tentative working plan for evaluation and feedback. As Ms. Ault mentioned, we're working with AHIMA on the validation step, accepting that there always needs to be external validation of these tools if they're going to be ultimately accepted in the marketplace.
The standards discussions are underway with the HL7 groups in terms of the constructs we would use for the knowledge base and how that should look, and we're working on deployment for demonstration later this year.
To summarize all of this, I would suggest to you that some basic mapping requirements for interoperability require:
A clear and unambiguous use case and documentation.
They require editorial decisions that are independently reviewed and validated.
I think that knowledge-based maps are going to become the rule, not the exception, because everything else basically has too high an error rate.
That external validation of these maps by independent and knowledgeable third parties must be a part of the business plan.
That there should be publication in the public domain.
And obviously, that release procedures need to be responsive to changes very much as you said earlier. As either one changes, then the map must change in response to that.
In terms of what NCVHS might consider doing, strategic agreement on map use cases that are required for success for deployment of the computerized record, I think a short list of what we need to do, and reaching consensus on that, would be very helpful.
Agreement upon knowledge formalisms for mapping and how those procedures should be developed.
Work in progress in terms of how to develop scientific methods and evaluating for how we can validate and establish the utility of these maps.
And then, finally, promoting vendor review and acceptance of this whole architecture as a necessary element of how we're going to be successful in achieving interoperable systems.
Now, just a few comments. I was a little surprised when I got the original message from the Committee about the subject for today. A lot of what was in there I call the "inferred record," or the use case being that while I'm implementing a diabetes guidelines, I notice that most of my patient records don't have a complete problem list or don't have a complete list of patients with chronic kidney disease, and so I basically have to go data mining in my clinical records in order to be sure that I come up with all of the necessary criteria so that I can identify all my patients eligible for the guideline.
So my knowledge engineer basically creates a set of rules in the guideline which search the record for things like serum creatinine and albumen tests and then implements standard criteria for how to establish the diagnosis. I would call that an inferred diagnosis or something like that.
I would just like to make a couple of comments about experience that we have had in the last two years when working on the SAGE project. You may or may not be aware that the SAGE project basically is an experiment in guidelines interoperability. It employs only NCVHS core vocabulary standards and all of the knowledge features that we developed.
We are evaluating right now against three AHRQ guidelines in terms of the needs, in terms of knowledge development and vocabulary support, and we are cooperating with HL7 in terms of developing interoperable decision tools that allow us to share knowledge between systems.
These things are a long way off. And I think that, if we're talking about obtaining near-term utility in terms of secondary use of clinical systems, we need to recognize the fact that sharing knowledge is probably going to be the most complex thing we do, and it's tied inextricably to the issue of sharing vocabulary, because in most of the knowledge offering that we have been doing within the SAGE project, 50 percent of our effort is actually involved in tweaking or manipulating the reference terminologies in order to be sure that all of the necessary structures are there to properly support the decision features of the guideline.
So in terms of the ability to deliver on the inferred record, I would suggest to you that it's equivalent to basically delivering on interoperable decision support, that it requires not only the vocabulary system and the interoperable formalism for shared knowledge but it requires that the vendor community have implemented basically the knowledge deployment software and that there's widespread acceptance of these issues of data mining and inferred diagnoses, which I think is a large question and problem in itself.
And so I think these issues are much further off than the maps which we hope to be looking at this year, and I hope the convergent terminology which we can be using within this calendar year.
And I think --
MR. REYNOLDS: Thank you, Dr. Campbell. Valerie, if you -- which one's going to go first?
MS. WATZLAF: I am.
MR. REYNOLDS: Valerie, go first, please.
AGENDA ITEM: Presentation -- VALERIE WATZLAF
MS. WATZLAF: Chairmen Blair and Reynolds, members of the Subcommittee, and ladies and gentlemen, good afternoon. I am Valerie Watzlaf, Associate Professor within the Department of Health Information Management in the School of Health and Rehabilitation Sciences at the University of Pittsburgh.
And with me this afternoon is Mary Stanfill, Professional Practice Manager of the American Health Information Management Association, or AHIMA.
On behalf of our Association and our 50,000 colleagues, we thank you for allowing us this opportunity to provide input on issues related to computer-assisted coding.
I believe that most of you are familiar with AHIMA. If not, we have placed a brief description of the Association in our written testimony and we invite you to visit our website at www.ahima.org if you wish to learn more about AHIMA and the health information management profession.
Last year, AHIMA convened a work group on computer-assisted coding, or CAC, to perform an extensive exploration of CAC technology. The work group was to research CAC technology and related emerging roles for HIM professionals and using this research, identify the best practices for evaluating and evaluating this technology and develop use cases and required skill set for emerging HIM roles.
The outcome of this effort was a set of practice guidelines, or a practice brief, called Delving into
Computer-Assisted Coding, and it was to assist health care organizations in preparing for the expanding role of this technology in the coding and billing process. And a copy of this practice brief was submitted, with our written testimony, for your review.
The practice brief discusses computerized tools available to automate the assignment of certain medical or surgical codes such as ICD-9-CM and CPT and HCPCs from clinical documentation that are traditionally assigned by coding or HIM professionals as well as clinical providers.
It also outlines the driving forces shaping the current and future applications of this technology. It examines application of the technology, and it provides guidance about the steps necessary to position coding professionals for the coming coding revolution.
It is appropriate at this time to disclose two pertinent current projects with which AHIMA is involved.
AHIMA's Foundation of Research and Education has a contract with the Office of the National Coordinator for HIT to look at how automated coding software and a nationwide interoperable health information technology infrastructure can address health care fraud issues.
This project is comprised of two tasks.
The first task is a descriptive study of the issues and steps in the development and use of automated coding, or CAC, software that will enhance health care anti-fraud activities. And I am one of the co-principal investigators on this task.
The second task will identify best practices to enhance the capabilities of a nationwide interoperable health information technology infrastructure to assist in health care fraud prevention, detection and prosecution.
The second project work AHIMA is conducting under contract with the National Library of Medicine, as was mentioned. This task is to assist in the development, review and testing of mappings between SNOMED CT and ICD-9-CM and any successor HIPAA standards to ICD-9-CM. And Mary is part of that team that is working on this project.
Let's begin first by clarifying some of the terms that we will be using. Electronic health record, or EHR, is the term we use to refer to computerization of health record content and associated processes. This is in contrast to the term "electronic medical record," which is computerized system of files that are often scanned rather than individual data elements. Today when we mention an EHR, we are referring to a system that captures, manages and maintains discrete health care data elements.
AHIMA defines computer-assisted coding as the use of computer software that automatically generates a set of medical codes for review and validation or use based upon clinical documentation that's provided by health care practitioners.
CAC is often referred to as "automated coding," but this can be confusing as it implies a fully automated process with no human involvement when these applications do require human review and validation for final code assignment for administrative purposes. We prefer including the term "assisted" when discussing these applications, as this more closely characterizes how they are employed.
We must also distinguish between CAC applications and other computerized tools that are currently utilized in the coding process. There are many tools available today to assist coding professionals in manual code assignment, including pick or look-up lists, automated super-bills, logic- or rules-based encoders, groupers, and imaged and remote coding applications.
All these tools serve to assist a person in manually assigning correct codes. They do not fundamentally change the coding process; they simply facilitate the manual coding process.
In contrast, the CAC applications significantly alter the coding process through automatic generation of codes for review by a coding expert who validates and edits the codes rather than manually selecting them.
In our research, we found two approaches to CAC applications employed today. One is structured input, and two, Natural Language Processing, or NLP.
Structured input or text, or codified input, is a form of data entry that captures data in a structured manner -- for example, point-and-click fields, pull-down menus, structured templates and macros.
Structured input CAC applications are essentially a documentation system where pre-defined clinical documentation is linked to the applicable code. As the clinical documentation is created via the caregiver selecting applicable clinical phrases, the linked codes are automatically assigned.
Natural Language Processing, or NLP, is essentially a form of artificial intelligence that emulates the way people read and understand so that it can extrapolate information from the written language the way the human brain does.
This software technology is applied to a text-based document and it uses computational linguistics to extract pertinent data and terms and then convert them into discrete data, in this case, the medical code.
NLP-based CAC applications may use either a statistics-based or rules-based approach to assign the code, and often, a hybrid, or a combination of both, is employed in the NLP system architecture.
With a statistics-based approach, the software predicts which code might apply for a given word or phrase based on past statistical experience. The rules-based approach uses programmed rules, or algorithms.
There is an entirely different mechanism to assist the coding process via automation, and that's the concept of mapping from a reference terminology embedded in an EHR to a classification system. Theoretically, once an EHR containing a clinical reference terminology -- for example, SNOMED CT -- has been implemented, information captured in the EHR during the course of patient care can be codified using the reference terminology, and an automated mapping process may be employed to link the content of the terminology to the desired code sets for secondary uses.
Thus, there are potentially three ways to accomplish the medical coding process:
First is manual code assignment, with or without the encoding tools.
Second is the use of a CAC application.
And third is mapping from a reference terminology embedded in an EHR to a classification system.
We would now like to compare and contrast these three methodologies.
The medical coding involves manual evaluation and review of clinical documentation and application of coding and reporting rules to assign administrative codes. This process may include the use of code books or computerized tools -- for example, encoders, automated super-bills, or pick lists -- and it may be performed by multiple individuals ranging from non-credentialed or credentialed coding professionals to physicians.
In contrast, the coding process utilizing a CAC application is very different. Structured input CAC applications are used by the caregiver, often at the point of care, as a data entry mechanism.
The clinician captures clinical information by adhering to the software application's pre-defined structure for input. For example, he or she might select applicable words or phrases from menus or utilize multiple point-and-click fields to store the information. If a menu or field is skipped, the application may prompt the caregiver for the missing documentation.
Implementation of a structured input CAC application first involves developing, or tailoring, the structure for data input so that it closely matches the clinical information that will be stored and maintained as health record documentation.
Once clinical information is set up in a structured format, the codes are assigned to the clinical words and phrases where applicable. The software links these codes with the correct phrases so that codes may be captured as the documentation is created. The list of codes that correspond to the documentation is presented to the caregiver for review and validation and is subsequently presented to the coding professional for review.
The coding process using an NLP-based CAC application is a little different. This software undertakes the following processes almost simultaneously:
It evaluates the documentation resulting from a patient/provider encounter to suggest codes that reflect the written word as documented.
Most NLP-based CAC applications use a combination of the statistics-based and rules-based approaches. In most cases, the statistics-based approach is applied first, and if errors are detected, then the rules-based approach is applied. Then an extensive quality check is usually performed.
And as the software performs this analysis, it may also evaluate patterns of documentation that are statistically different from the average documentation for similar cases. In this manner, it identifies potentially incomplete documentation so that physicians can be queried. Physicians are then provided with feedback regarding documentation variances to help improve the documentation practices.
And then a list of suggested codes is sent to the appropriate coding personnel to verify the codes. Code output from an NLP-based CAC application is normally ranked, based on the computer's level of confidence in the accuracy of the codes generated. Typically, it ranks it in different levels. Number one would be a high degree of confidence; the second would be more questionable codes, or it could also be inability of the software to determine any potential codes.
In the manual coding process and the coding process using a type of CAC application, the final code set is determined by a person. However, the process using CAC differs from the manual process in a significant way. CAC applications suggest potentially applicable codes, rather than a coding professional being entirely responsible for code selection. Therefore, the CAC tools can significantly improve productivity.
It is important to note that CAC applications today are not capable of generating codes on every single case. Manual coding must still be performed on cases that don't readily fit the defined input structure or on types of cases that the NLP system has not previously encountered and therefore has no framework from which to suggest applicable codes. So, with both structured input and NLP-based CAC applications, humans perform some manual code assignment, but it's to a lesser degree.
Editing and validation of computer-generated codes may involve the use of coding tools such as up-to-date code books, coding references, and encoders that assist in determining the correct code assignment through text prompts. The expectation is that, as the coding professional becomes an expert coder, editing codes generated by the software is much less time consuming than an entirely manual process.
In determining the final code set, the expert editor also applies modifiers and other payer reporting requirements that often require contextual information to be accurate -- for example, Medicare's Correct Coding Initiative edits).
Even though CAC applications do not fully automate the coding process -- human review for final code assignment is still necessary -- these applications are beneficial. They increase coder productivity, and they make the coding process for efficient. Therefore, there is return on investment.
The AHIMA practice brief includes a comprehensive includes a comprehensive exploration of the advantages and disadvantages of CAC. Reported improvements in the coding process include:
Improved coding consistency.
More comprehensive coding.
Enhanced coding compliance.
Decreased coding and billing costs.
Faster turn-around time, resulting in decreased accounts receivable days.
And enhanced workflow.
Benefits unique to structured input are related to the documentation process. Structured input creates consistent and potentially more complete documentation. The physician is prompted to add specificity to better reflect clinical details in the ICD system, and this potentially eliminates the physician queries. Also, structured input systems replace some dictation and transcription, thus reducing associated costs.
A significant benefit unique to NLP-based CAC is that physicians may continue to document using their preferred terms.
Lastly, many CAC applications offer mechanisms to query data from their systems. Therefore, we anticipate improved ability to analyze administrative data. The use of CAC data for such purposes as Joint Commission auditing, QA measures, performance studies, credentialing and research is an attractive feature of this technology. CAC applications may be characterized, then, as bridge technologies that serve the pressing need to improve today's manual coding process.
CAC significantly impacts workflow. With CAC that uses structured input, the entire coding workflow from the point of documentation through claim submission is affected.
Physicians are directly impacted, as they must document using the pre-defined structure, tailored to his or her practice. Cost savings are reported from elimination of transcription and dictation.
But there are reports that some systems increase physicians' documentation time, causing a decrease in throughput of patients and increasing waiting times, in these cases. However, when CAC works well, it does provide a closer relationship between data capture in real time and code assignment. With NLP-based CAC, the documentation process does not have to change. In fact, this type of CAC may be transparent to the physician.
CAC also impacts management of the coding process. The work load can be managing by routing work to queues based on specific parameters such as the report type, the particular codes suggested, or the CAC application's confidence level. This creates a much smoother workflow and allows coding staff to focus and become expert in certain specialties. CAC applications also enable management of the coding process through tracking and administrative reporting.
In short, incorporating a CAC application in the coding workflow has a profound effect on the coding staff.
It is more difficult to generalize the effect in terms of staffing changes. I noted that CAC has demonstrated improved productivity. However, specific performance in terms of coding accuracy for correct reimbursement is largely unknown.
In our research, we found that the coding quality in many of the systems employed has not be assessed in actual practice, and overall, no CAC application to date has an accuracy rate that meets the existing industry standard of 95 percent that coding professionals are expected to meet. Therefore, CAC applications are not at the point where large displacement of the coding work force can occur.
It should be noted that multiple vendors' marketing materials claim that their CAC products will result in reduction in FTEs, and certainly increased productivity always carries this potential. However, there are no empirical studies from which to estimate overall staff reduction versus shift in responsibility or simply relief from the coder shortage. This is not surprising, as
CAC applications do not address specific reporting requirements and have been only minimally deployed for reimbursement use cases in the inpatient setting where the real potential for staffing reduction exists.
Let's now look at the status of deployment of CAC technology.
Widespread adoption of these technologies has not yet occurred. There are only a minimal number of CAC applications that address inpatient coding for reimbursement purposes.
CAC applications are most commonly found in outpatient settings such as physician practice and hospital outpatient ancillary departments or emergency departments. Structured input CAC is deployed in procedurally driven domains where documentation is predictable and repetitive. NLP-based CAC is deployed in specific specialties where the vocabulary is more limited and source documentation is both limited and available in electronic text format -- for example, in radiology, cardiology and emergency medicine.
CAC applications are bridge technologies that serve the pressing need to improve today's manual coding process. Mapping from a clinical terminology to a classification system is ideal for secondary uses of data. Therefore, before we discuss the catalysts and barriers affecting deployment of the CAC applications, we must
describe the coding process when reference terminology embedded in an EHR is mapped to classification systems. And Mary is going to describe that process.
AGENDA ITEM: Presentation -- MARY H. STANFILL
MS. STANFILL: Thanks, Val. Good afternoon. I'm going to compare and contrast the process of mapping from a reference terminology embedded in an EHR to a classification system, with the work process utilizing a CAC application that Val just described.
Together, terminologies such as SNOMED CT, and classification systems like ICD, provide common medical language necessary for interoperability and the effective sharing of clinical data in an EHR environment. The benefits of using a reference terminology in an EHR increase exponentially if the reference terminology is linked to modern, standard classification systems for the purpose of generating health information necessary for secondary uses.
This linkage is accomplished through mapping, and we've been discussing that throughout the day today. Dr. Campbell gave you a very specific definition of mapping. We refer to mapping as the process of linking content from one terminology to another or to a classification. It's consistent with his definition.
Essentially, mapping provides a link between terminologies and classifications in order to use data collected for one purpose for another purpose, to retain the value of the data when migrating to newer database formats and schemas, to avoid entering data multiple times and the associated increased costs and error practice that may be involved there.
Clearly, clinical data captured at the point of care can be efficiently and effectively used for administrative and secondary purposes. Driven by the philosophy of "code once, use many times," after clinical care is recorded in an EHR using SNOMED CT, mapping tables can be used to identify the related codes in ICD.
This process allows data encoded in SNOMED CT to be aggregated into groupings for data reporting and analysis. Mapping avoids duplicate data capture while facilitating enhanced health reporting, billing and statistical analysis.
Okay, we've got that point. We've been talking about that all afternoon.
Now, the standard method for mapping begins with the development of heuristics, or rules of thumb used for problem solving and guidelines that support the use case or the purpose of the map, respecting the conventions of the source and the target to preserve the granularity and flexibility of both.
Defined mapping rules must be developed and consistently applied to minimize incompatibility without compromising clinical integrity. The map must remain context free, meaning care must be taken not to introduce any assumptions or assertions.
In order for diagnosis and procedure codes resulting from a map to be appropriate for use in meeting reimbursement requirements, algorithms that consider coding rules and conventions and reporting requirements, such as adhering to coding guidelines and identifying the principal diagnosis, for example, they need to be developed and they have to be applied to the mapping process.
The development of maps will not eliminate administrative coding or the need for expertise in code selection. Fully automating the process of mapping from a reference terminology to a classification system is challenging because of the inherent differences between them.
The mapping process is straightforward when the source terminology and the target match up. But when more information is needed to express the concept in the target, a CAC application could be used to bring in that contextual information to further refine the map output.
We have a couple of slides to illustrate the mapping process from SNOMED CT to ICD-9-CM for just a few concepts at varying levels of detail. On the left is a SNOMED CT concept ID for that clinical finding. On the right is the mapped ICD-9-CM diagnosis code. When there's a direct match between the concept and the code, the mapping is very straightforward. So, for example, the first example on the slide you'll see the concept of hypertension, without any further specificity, is fully reflected in one ICD-9-CM code, the 401.9. And this does happen fairly often.
But the second slide represents an instance where mapping is more complex. Here, the variance between the systems requires additional information in order to determine the target code.
The concept "esophageal reflux" cannot be assigned an ICD-9-CM code without additional information because it's classified in ICD-9-CM as either with or without esophagitis. This is the patient level exclusion information that Dr. Campbell was referring to.
Ulcer of esophagus is another example where contextual information is needed to complete the map because ICD-9-CM classifies an esophageal ulcer as with or without bleeding. The default code is "without bleeding," but you would not want the automated map to always default to that.
So you set up these rules, and this example is an
IFA rule is defined to allow for someone to obtain that additional contextual information on a particular case. The map output in this instance would be 530.21 if bleeding, or 530.20 if no bleeding. Somehow, that map output needs to be -- somebody has to finish that thought, right? You need to select the correct code then that applies to the case. Now, that could be determined by human review or perhaps a CAC application.
In an EHR with automated mapping from reference terminology to administrative code sets, the coding professional's knowledge will expand to include expertise in clinical terminologies, medical vocabularies, as well as classification systems. Rather than focusing on code assignment, coding professionals will focus on management and use of the data. Their role will include many of the functions Val described with use of the CAC applications, such as documentation specialist and revenue cycle specialist, but their role will also include functions such as:
Creation, maintenance and implementation of terminology, validation files and maps.
Ongoing review of the auto and manual encoder systems for terminology and classification systems for improving and optimizing the encoding process.
Also include functions like assisting in the analysis of the enterprise's classification and grouping system assignment trends and use of data from classification into these systems.
Proactively monitoring developments in the field of clinical terminology to medical vocabularies.
And recommending the most appropriate classification or terminology system to meet all the required information needs.
Val stated that current CAC applications are just an interim step during the transition to fully implemented EHR systems. Mapping is the ideal goal for a couple of reasons. While use of CAC applications can increase productivity and create a more efficient coding process, the use of standard terminology has the potential to further increase the accuracy of automated coding and thus further increase efficiency.
In addition, it's possible to more fully automate the coding process in an EHR with embedded clinical reference terminology mapped to a classification code set than is possible with the use of a CAC application.
Structured input systems essentially employ manual coding, albeit coded once at the time the structure is set up, but that set-up is time consuming and it does not lend itself readily to all the clinical nuances.
NLP-based CAC has improved dramatically over the last several years, especially the last four years or so, but more research is needed on the accuracy of these systems and expansion into clinical domains with broader clinical vocabularies has been difficult to achieve.
The coding process when mapping from a reference terminology in an EHR is entirely different than the process of using a CAC application, particularly in terms of the computing process that actually generates the suggested codes. Human review is still necessary before reporting a code resulting from a map in order to insure accuracy with regard to the context of a specific patient encounter and compliance with applicable coding guidelines and reimbursement policies.
As rules-based maps are developed for multiple-use cases and become increasingly sophisticated, the level of human review at the individual code level will diminish. Workplace roles will focus on the development and maintenance, including quality control, of maps for a variety of these cases, and the development of algorithmic translation and concept representation. Reduced staffing is expected.
While we focused on workflow and staffing, we also want to address the impact on data quality.
If clinical data, captured in an EHR at the point of care, is to be useful for whatever secondary purposes we may find appropriate, data quality is critical.
A common concern with data quality is manipulation of documentation to affect billing codes. Boundaries between clinical data capture and reimbursement are necessary to insure data integrity. A clinical terminology intended to support clinical care processes should not be manipulated to meet reimbursement and other external reporting requirements, as such manipulation would have an adverse effect on patient care, the development and use of decision support tools, and the practice of evidence-based medicine. The use of a reference terminology embedded in an EHR separates clinical data capture management from reimbursement. This is expected to improve data quality and result in more accurate reimbursement as well.
Today, an EHR with mapping from reference terminology to a classification system is rare, and I think we've established more information is needed on just how often that's done.
Vivian addressed the availability of the SNOMED CT to ICD-9-CM map. According to SNOMED International, the purpose of this cross-mapping is to support the process of deriving an ICD-9-CM from patient care.
The map provides users with an approximation of the closest ICD-9-CM code or codes. Since SNOMED CT's scope of content is much broader than ICD-9-CM, less than 30 percent of the content of SNOMED CT can be mapped to ICD-9-CM.
Lack of widespread adoption of EHRs is a barrier to adoption of these technologies. Without an EHR, the complexity, quality and format of health record documentation makes it very difficult to integrate CAC applications in the coding process.
Among other barriers is the complexity of Federal and state regulations impacting administrative clinical data reporting and our national reimbursement structure, resulting in variable and conflicting reporting requirements.
Today, many administrative coding practices are driven by individual health plans or payer reimbursement contracts or policies requiring health care providers to add, modify, omit or re-sequence reported diagnosis and procedure codes to reflect specific payer coverage policies or regulatory requirements contrary to code set reporting standards.
Not only does the variability in reporting requirements undermine the integrity and comparability of health care data, it significantly complicates the development of map rules and algorithms in CAC applications, hampers the advances in CAC applications, and increases the extent of human review required in both CAC and mapping technologies.
Current CAC applications rely on human intervention to apply these rules, limiting the degree of automation and thus the potential return on investment. The integrity of coded data and the ability to turn it into functional information require the use of uniform coding standards, including consistent application of standard codes, code definitions, and reporting requirements.
In addition, variable code set update schedules increase the cost and complexity of insuring CAC applications and maps are accurate and up to date. And I notice that Vivian has made a mention that NLM has noticed that, too, that that update schedule is going to be critical.
The failure to implement ICD-10-CM and ICD-10-PCS is also a barrier. It is extremely difficult to develop valid maps from current clinical reference terminology to an obsolete administrative code set. It makes no sense to map a robust terminology such as SNOMED CT to an outdated classification system such as ICD-9-CM.
The anticipated benefits of an EHR cannot be achieved if the reference terminology employed in the EHR, such as SNOMED CT, is aggregated into a 30-year-old classification system such as ICD-9-CM for administrative use and indexing.
When an up-to-date clinical terminology is mapped to an outdated classification system, the map is less reliable and meaningful information is lost. Furthermore, extensive guidelines and instructions have been created to compensate for the difficulties in using the obsolete ICD-9-CM coding system. This simply adds complexity in developing map rules or algorithms for CAC applications.
There are information technology barriers to adoption of CAC as well. We're all aware of the lack of industry standards that make integration of software applications difficult.
In addition, this technology itself has limitations. As Val noted, structured input is best suited to procedurally driven domains and NLP is limited to electronic text-based documents.
Performance of CAC applications in terms of quality is unknown. Available research evaluating existing CAC applications is insufficient. We need research designed to assess the usefulness of these applications in the administrative coding process.
In relation to mapping, heuristics are extremely difficult to define, given the various reimbursement rules, plus the inherent differences between reference terminology and classification systems.
Mapping between SNOMED CT and ICD is an imperfect science. It's very difficult to adequately represent some of the ICD coding conventions for a computer's purposes.
The codes produced by the cross-map must be evaluated in the context of the complete medical record as well as applicable reporting rules and reimbursement requirements before being submitted to payers and other external entities. Reliance on the technology alone carries the potential for increased errors in the coding process and associated compliance concerns.
Concerns of those involved in the coding process, the potential users of CAC and mapping technologies, can also be a barrier. These technologies involve significant change. User resistance to change is a very real factor.
Physicians often resist structured input. Coding professionals resist complete re-engineering of the coding workflow.
Other concerns are more concrete, such as the cost of CAC hardware and software, and the pressure to meet health care compliance requirements. The health care industry today is very sensitive to issues that may result in allegations of fraud or abuse. If not carefully designed and used with caution, documentation generated via structured templates may justify more reimbursement than deserved for the services rendered. Physicians and coding professionals express concern as to whether the OIG will embrace, or even allow, structured input systems.
This lengthy discussion of barriers may sound daunting, but it is really not surprising when you consider that CAC is a disruptive technology. So what are the drivers and trends that will produce the natural rate of diffusion?
There are many factors within the health care industry driving this technology, including the movement to adopt EHRs and create a National Health Information Network. The continued trend of increases in administrative costs within the health care is also a factor.
The manual coding process widely employed today is expensive and inefficient, and there is a recognized need to improve that coding process. Also, the shortage of qualified coders and increased outsourcing and remote work sites encourages use of CAC for productivity and consistency gains.
Deployment of EHRs with data input codified in a clinical reference technology is a catalyst that will cause innovative computer-assisted coding to become a necessity. Other catalysts that will enable this technology include:
Simplification of reimbursement regulations, so that algorithms can be designed and more readily deployed and maintained.
Adoption of ICD-10-CM and ICD-10-PCS to facilitate the development of automated maps between clinical terminologies and classifications systems.
And validation and availability of reimbursement use case maps from reference terminology to administrative code sets.
The NLM, through the UMLS, continues to play a large role in emerging national standards for the electronic health record, as we've seen. Resources have been committed and work is underway to validate the reimbursement use case map from SNOMED CT to ICD-9-CM. Val?
AGENDA ITEM: Presentation -- MS. WATZLAF [concludes]
MS. WATZLAF: Thanks, Mary.
As we have discussed, CAC applications presently are not widely deployed, and an EHR with mapping from a reference terminology to a classification system is rare. And we believe the Subcommittee can speed adoption of CAC if you support the following:
Continued efforts to encourage widespread adoption of EHRs.
Efforts to simplify and standardize the reimbursement framework.
And expeditious adoption of ICD-10-CM and ICD-10- PCS.
Our written testimony also includes three additional areas of research that you should recommend to the Secretary and some other tangential, long-term research questions to consider in the future.
As a profession, we are pleased the NCVHS is taking a concerted interest in issues related to CAC and mapping. We look forward with looking with you in this venture to help our industry move forward with its understanding and use of these significant tools.
Thank you again for the opportunity to contribute to your discussion here today, and Mary and I are ready to answer any questions the Subcommittee may have now or in the future. Thank you.
MR. REYNOLDS: Thank you very much, all of you, for a very thorough review of the subject. I'd like to open it to the Subcommittee to ask any of the three panelists a question. Stan, why don't you go first.
DR. HUFF: I think all of you mentioned the potential for impact on productivity of the coding staff. Has there been quanitation, I mean, in your experience, Jim, with the coding you do? Has that changed staffing or other things within your health information management group, and what's been the experience at other sites that you guys from -- Mary -- have been --
MR. CAMPBELL: I'm really not in a good position to respond to that, Stan. I can tell you that our studies indicate our quality of information goes up, you know, with some of the technology I showed you.
We have such a distributed staff at the Med Center that I don't have statistics for that.
DR. HUFF: You ladies?
MS. STANFILL: Stan, is your question in relation to computer-assisted coding type technologies as opposed to mapping?
DR. HUFF: Yes.
MS. STANFILL: Of course, we don't have a lot of -- we're speculating, largely, in terms of mapping.
DR. HUFF: Yes. I guess if we don't have numbers, I guess I'm asking for your best idea of what the potential for this is. I mean, if we do computer-assisted coding and say we achieved we could, you know, ultimately ten years or I don't know how long down the road, we achieved 80 percent of all of the billing assignment was done via computer-assisted coding, would that reduce the overall cost of doing that assignment by five percent, ten percent, 20 percent, 75 percent? You know, what's the relative efficiency of this compared to manual coding?
MS. STANFILL: Okay. You want to take a stab at that, Val? There's two answers to that, two ways to look at that.
There is some published research that's been published in the Journal of the American Medical Informatics Association that looks at the productivity of an NLP computer-assisted coding application, for example, an NLP coding engine, and the productivity potential is incredible.
They had someone do some manual coding of chest X-rays and then ran it through a CAC code, an NLP coding engine, and the manual person took two minutes per report to code it and the NLP coding engine needed .3 seconds to code it. I mean, the potential, productivity potential, is incredible.
But we'll tell you what we're seeing actually in real work, real processing of actually using a system because of that edit process and some of that sort of thing. We're hearing anecdotal reports of around like 30 percent productivity savings, those kinds of things. That's purely anecdotal.
When we talk to the users that actually have these systems in place, they have a very difficult time quantifying that because a structured input type of a software application changes their whole documentation process, et cetera. So when we say to them, what kind of efficiencies did you gain in the coding process, they can't really answer that question because it changes so much of their process.
And a lot of the burden -- burden might be a more strong word than I need -- but it's shifted a lot of that to the physician, who's now doing documentation a different way, et cetera, so there's a shift in the process in terms of who does what. So it's very difficult to quantify.
But in terms of the Natural Language Processing type of systems that are in use where it's purely just suggested codes and the coder's actually looking at that and then maybe faster, how much is a coder, we're hearing that -- that's where we get that anecdotal report of about 30 percent of their time.
But again, a lot of them aren't necessarily even able to measure it.
MR. REYNOLDS: Jeff has a question.
DR. HUFF: I wasn't finished with mine yet.
MR. REYNOLDS: Oh, I'm sorry.
MS. STANFILL: I should probably qualify that, though, Dr. Huff, because again, when we're talking about -- the NLP applications that are available are only for very specific subsets, so that's not like 30 percent saving in any kind of coding. That's only very specific cases, outpatient ancillary, just X-rays, or just their emergency department cases, that kind of thing.
DR. HUFF: Okay. Now, I'm trying to understand if there's a difference between what Chris Chute would have thought about as aggregation logics versus the kind of, quote/unquote, "mapping" we're doing, and there's a little bit of difference in the definition between mapping the way Jim used it, I think, and the way you folks use it, not much but some.
And I guess the question is -- it probably comes down to how you're representing the actual computable form of these mappings. If there's additional information needed, so, you know -- in the example, if you need to know that the patient was male or female in order to assign the proper code or if you need to know their age in order to -- are we using the standard coded representation for those observable things like age or sex or other things? Is that a coded part of a rule per se that you're creating or you have the mapping sort of between and then that's left as some additional information? How is that being done, or how are people thinking about that?
MS. STANFILL: You're addressing that to Dr. Campbell in terms of how is the map being designed?
DR. HUFF: Yes. Looks like I need to ask the question a different way. What is being done in terms of, quote/unquote, "mapping" end up with something that's entirely computable, or in fact are we just setting flags for people to ask a person the question?
I mean, age I can generally determine from the electronic health record. So when you do a mapping that needs age, is age referenced in a structured coded way in the rule that you're creating or how are you doing that?
MR. CAMPBELL: I slipped past that slide pretty quickly, Stan, but part of the point that I was making is that if we do want to create interoperable resources in a real sense of the term, then we have to, in our rules construction, manage the interface to the information model as well as the vocabulary as well as the expression language.
And so in the example I gave, which is actually under active discussion at HL7 now, you know, we were using GELLO as the expression language and we were using a specific feature of the HL7 RIM to construct. In those cases, there were observations and procedure history that were needed in order to resolve the rule.
Those standard architectures, I think, are needed as a part of anything that we build. And obviously of how we achieve that I think is happening right now.
DR. HUFF: I guess part of the question is -- and that sounds like something that's under discussion and will happen in the future -- the "mapping," quote/unquote, that's going on now between SNOMED CT and ICD-9 is something less than that, or is that in fact exactly what you've got for that?
MR. CAMPBELL: No, I mean these are concurrent activities. We have a number of deliverables in order to create an interoperable map. Obviously, content and review with our coding colleagues is a significant part of it.
But on the other side of it, we also have the necessary knowledge constructs and so forth, and it's a question of pulling all consensus together on all of those elements to deliver the product, not that, you know, one has to happen before the other.
DR. HUFF: Great. Thanks.
MR. BLAIR: Since the testimony this afternoon was so simplistic and there were so few variables, I just thought I'd add a variable in, just for some color.
I attended an ambulatory EMR road show that the Medical Records Institute puts on, and it's taken to different cities around the country, and I attended a few of them. And I learned a few things that I didn't know was going on in the marketplace.
One of the things, to my surprise, was that there's a number of vendors, to me surprisingly large number of vendors, that are very proud of the fact that they are offering Medcin as a front end, although I can't say it's a front end. They're just simply offering Medcin for capturing clinical information.
And, Jim, I know you're familiar with Medcin. I don't know if our other testifiers are. But earlier, Vivian Auld from NLM indicated that they're planning -- I thought it was further along, but they're planning on having mappings between Medcin and SNOMED.
Do you have an opinion whether a market acceptance of Medcin would enable,
encourage and facilitate adoption of SNOMED or whether it would be an
impediment?
MR. CAMPBELL: Well, in my recollection of this morning's discussion, there were
a number of comments about the needs for this or that code set. I think these
individuals are recognizing that within the larger construction of a reference
terminology such as we're talking about as our core, there's vastly more
information than we need in any specific instance, let's say, of a patient
encounter in a clinical record. And so we need to focus ourselves.
For example, right now CAP is also developing subsets which are basically vendor implementation tools, for examples, for problem list or clinical findings.
From my standpoint, Medcin has features of an interface terminology along with some elements of a knowledge base for primary clinical care that serve value. Ultimately, reference terminology is at the core of all of our system, becomes the common vehicle, becomes a necessary common vehicle to the distribution of knowledge-enabled systems.
And I think that Medcin, for example, is one more attractive aspect of how to put that together in the same sense that the problem list vocabulary at the University of Nebraska, which is in use in a dozen other institutions, you know, is a convenience. Those sites have not had the time, wherewithal or necessarily the training to go ahead and construct that, and delivering that vocabulary resource to them enabled them to get their implementation going.
Medcin, which is targeted or linked directly into a core reference terminology in a clinical system I think becomes a similar vehicle, or can be. Medcin is not going to grow up to be SNOMED CT and RxNorm because that's too big a job, but if it provides a useful and interoperable window for a set of clinicians to employ their clinical system, then it's obviously a win-win situation.
There's a lot of details in the answer, you know, and how that answer would play out, but I think I would say generally it should be a benefit, as long as we understand the relative roles that are being played by these schemes, you know, in the design of a clinical information system.
MR. BLAIR: Any other comments or observations?
Let me ask -- I'm going to do groping around here just for my understanding, and Jim or Stan, correct me if my understanding's not wrong -- that's why I'm asking about it.
When I think of Medcin, I think of a pre-coordinated terminology which is easier to use right now than SNOMED, and I think that's the reason that it's being adopted in the marketplace. And I think of it as something that's going to be easier to map from Medcin to SNOMED than some of the difficulties that you've articulated mapping SNOMED to something that has greater limitations, like ICD-9. Are those assumptions that I've just made, do you think that they're correct?
MR. CAMPBELL: Well, let's go back to the issues I raised of granularity, editorial focus, for example.
Medcin has been designed as a clinical system, as an interface or into a clinical system. I mean, that's the way it grew up.
Arguably, SNOMED CT has also grown the same way, although initially, you know, it obviously had a slightly different focus. But the point is it's clinically addressed.
Medcin has never been designed with all the features of a reference terminology.
MR. BLAIR: Right.
MR. CAMPBELL: So, again, when you go into your
database and take a look at what's there and will it support other features like sharing decision support logic with other clinical systems, you're going to find that Medcin is going to have limitations.
MR. BLAIR: Right.
MR. CAMPBELL: That's why I referenced it primarily as an interface terminology. You're right -- it is pre-coordinated, because I think in the vast majority of clinical implementations, most clinicians are not going to cut and paste SNOMED codes together to define a concept. That is not the way the interface will be designed.
And nor should it be. It'll be much easier for them to use -- and I just go back home to show you exactly how we've done it for that particular application.
Medcin, I think, approaches a similar problem. And to the extent that those Medcin concepts are clearly defined and easily constructed into a post-coordinated SNOMED, I don't see any reason that there's a competition there.
MR. BLAIR: Well, let me refine my question one last piece, because I think we've sort of cut down different layers.
A lot of the testimony that I've heard has enlightened me how difficult it is to create mappings, especially with CAC computer-assisted coding, from SNOMED to ICD-9. And there's also challenges with mapping it to other -- to LOINC and, you know, resolving the overlaps with LOINC and RxNorm.
I have the perception that mapping Medcin to SNOMED is not going to create similar types of mapping and translation problems, although it may offer new ones, that overall it's likely to be an enabler and a facilitator for us to move forward, rather than an added complexity. Is that assumption correct, or is it too early to tell?
MR. CAMPBELL: I think it is probably correct. If you take a look, for example, at the use case of the nursing classifications and what went into harmonizing them within SNOMED, there was a much greater discrepancy obviously between the nursing viewpoint of the clinical world and the medical viewpoint and there were new features that were added to the model in order to clearly develop and express that, whereas Medcin historically, you know, follows much at primary care, clinical, medical role, so I would expect their editorial alignments to be much better.
DR. HUFF: I think the other evidence that you can bring to that is that in a sense the re-codes were created, and were living in a similar environment to the Medcin codes, they were codes that were primarily used by clinicians to document what they were doing for the patient, and they had a much more pre-coordinated form to them and that got represented in clinical terms Version 3 as what were allowed qualifiers. And essentially that's a step towards creating the formal model for how you would de-compose a Medcin term into a primary SNOMED code with allowed qualifiers for that particular item.
And so I think the problem is much more bounded because, you know, the kind of thing that you would find in medicine would say something like "the patient has a cough productive of purulent sputum," and to post-coordinate that implies that, you know, you've got a primary finding of cough or sputum production and the assumption that you can have some description of what the sputum looks like kind of thing.
And so it's a matter of creating information models, or if you think of it, of creating a structure that tells you the allowed qualifiers that you can have with cough in creating that.
And I guess my experience in looking at it is in fact that there's a lot of work there but it's not theoretically a difficult problem. I think there are border cases where it is true, because you can get post-coordinated statements that imply a very sophisticated model, but they're used in a very small number of cases, and so you get to this sort of point of diminishing returns about whether it's really useful to make a model that that's sophisticated in order to represent the total semantics of two codes or something. So I think in the border cases you do, but in the whole, I think the mapping is possible and very doable and very valuable.
MR. REYNOLDS: Okay. Michael, you had a question?
DR. FITZMAURICE: I just love to sit here and listen to Jeff ask questions, and Jim Campbell and Valerie and Mary answer them. I'm learning much more than when I ask questions. But nevertheless --
[Laughter.]
DR. FITZMAURICE: -- I'm, still going to ask a question.
As I listen to this, it strikes me that so much of this is intuition by very learned people. Does there exist a research to build a body of knowledge about auto-coding regarding things like data quality, total labor productivity? I say total labor productivity because in some cases you're shifting the burden to the physician, moving from an X-dollar-an-hour to a 3X-dollar-an-hour person. And are there incentives to make a productive system work?
Let's suppose it is better to shift the burden from a coder to a physician, and suppose it makes money for the hospital, makes money maybe for a health plan. Are there ways to pay the physicians more if they do the coding which makes the system better and gets to this productivity and lower cost versus paying them less if they want to stick to the way they're doing it?
So, do we have a body of research regarding data quality and regarding the labor productivity and regarding the incentives maybe to make such a productive system work?
MS. WATZLAF: I think that's where we need research in all of those areas that you had mentioned. I think we recommended some of those, I think, in our written testimony, but I think much more research needs to be done.
In the study that I was involved in, I know that we did recommend some of those things, incentives for physicians and so forth. But again, looking at the quality of some of these systems and the productivity issues, all of that has not been assessed nearly as well as it should be, I think.
MS. STANFILL: I'm engaged in a literature review right now, that some are doing that. But I could tell you that the literature that is out there largely addresses the technical aspect of these systems but very little addresses the actual processes in terms of quality and actual productivity, you know, with a different workflow, et cetera, looking at it from practical aspects of administrative coding as opposed to simply, you know, using NLP in order to capture cases for research, that sort of thing.
DR. FITZMAURICE: One of the spurs for my question is that AHRQ is the lead agency for research into a patient's safety and quality of care, and good data on patient safety events is hard to come by, the voluntary reporting nature of it and the fact that you report it so many different kinds of ways.
And so it seems to me that it's a field that might be fertile with some prodding by Congress to get people to report voluntarily. If we would have a structure for them -- don't lose the free text because we don't know everything we need to know about classifying patient safety events and how to describe them -- but to take it and to start coding what comes in and classifying what comes in and see if we can start evolving into something better and better that's less burdensome. It's going to take some kind of a body of research like this.
And from our discussion today and from looking before, I don't see that body of research that says what's economical as well as what pays off in terms of eventually feeding back information that reduces patient safety events. Does that sound reasonable, that we should start investing in some of that?
MS. WATZLAF: Definitely.
DR. FITZMAURICE: Jim, you're quiet.
MR. REYNOLDS: Marjorie?
MR. CAMPBELL: I'm sorry?
DR. FITZMAURICE: You're quiet. Is that a nod of the head, that yes.
MR. CAMPBELL: I was going to say the short answer to your question is no.
DR. FITZMAURICE: Doesn't exist.
MR. CAMPBELL: And I would suggest that one of the biggest challenges to that is that there is such a discrepancy between health care organizations in terms of work organization and work plan and that implementation of these systems revise the work plan so substantially that before and after comparisons are extremely difficult and comparison between organizations is almost impossible.
So I think it's important, but I think it's also very difficult.
DR. FITZMAURICE: That the best we probably can do is case studies. It's like evaluating an electronic health record system. You run into the same kinds of problems.
MR. CAMPBELL: At least in the short term, I would like to see reliable information on validity, accuracy and information like that which has been woefully lacking in the past. And that, I think, is doable.
MS. STANFILL: And one of the difficulties in measuring accuracy is defining an accurate -- you know, take a case and give it to several people and you'll get it coded several ways.
So, I mean, there are some tools that could be developed that would facilitate even that research. One might be to have a better set of accurately coded cases that could be used to be the gold standard, measure against, that sort of thing. Some of those kinds of tools would be helpful.
DR. FITZMAURICE: We're going to have a gold standard panel.
MS. STANFILL: Yeah!
[Laughter.]
MS. STANFILL: We'll just sit tight.
[Laughter.]
MR. REYNOLDS: Marjorie?
MS. GREENBERG: Where Jeff's question educated you, mine may totally confuse you, but --
MR. CAMPBELL: It won't be hard.
MS. GREENBERG: -- at the risk of doing that, and it's five minutes after five, I realize, but I'm trying to kind of put all of this together and understand in particular how these different approaches of going from clinical data to administrative statistical data, how they all work, and the similarities. And so let me just sort of get some input from you to help me understand this.
I think I understand mapping, generally. I think the mapping from an existing terminology to a classification, that's what we're doing at NLM, we're doing a lot of that. You talked about that, Jim, and that was what Mary described. And although there are some differences, my sense is that pretty much you're all talking about the same process.
Then what Stan I know was talking about the last time -- well, the first time you raised this area, and also somewhat today, I think what you are referring to, Jim, as inferred, the inferred diagnosis, I mean you're not starting necessarily with a terminology like SNOMED CT. You're starting with a lot of clinical information in a record. It might be the lab values, it might be X-ray results, it could be a lot of different information.
So you have a lot of clinical findings, essentially. And that's what you were referring to as sort of an inferred diagnosis. Now introduced, comes on the scene here, the computer-assisted coding. And there are two ways to get to that, apparently. One is through Natural Language, so that doesn't suggest that you would have information coded in something like SNOMED CT, I guess, because it's Natural Language.
I don't know whether that might include some of these clinical findings that would go into an inferred diagnosis, whether CAC includes pulling information from lab findings or other types of clinical findings. I assume that it does.
MS. WATZLAF: Normally, with NLP, as long as it's on electronic text that it can read, it could take any of that information, read it and then --
MS. GREENBERG: So with the Natural Language side of it, you really are kind of talking about this inferred diagnosis approach? But what you're saying is it suggests various codes. It doesn't go all the way. It suggests them, and then the editor goes in and looks at it.
And then the structured text, that could include SNOMED text?
MS. WATZLAF: It could. Right. Normally, with the structured text, though, it's more of a template, just like a menu that it would just point-and-click?
MS. GREENBERG: More like a pick list?
MS. WATZLAF: Right.
MS. GREENBERG: A sophisticated pick list?
MS. WATZLAF: Right.
MS. GREENBERG: Okay. Which may not, then use -- if you already have the SNOMED terms, then you would probably get into this mapping scenario rather than the CAC scenario, is that correct?
But then you mentioned that sometimes when you're doing the mapping and it's complicated, you could insert CAC into it. Is that because then you could pull in other information, like some of these clinical findings, et cetera?
MS. WATZLAF: I think that's where the whole coding rules and all of that would come into play. So I think with this slide where it's a little more ambiguous as to what the code would be, then the CAC application would be applied and help with the end result. Is that what --
MS. STANFILL: I think, Marjorie, what might be confusing here is that structured input is a form of input. But we also talked about a structured input CAC tool, which is a specific type of application available today that uses structured input.
So, both structured input or Natural Language Processing might be used in an EHR if we had an EHR with SNOMED CT embedded in it. That vendor's EHR might use structured input as a data capture mechanism, might use Natural Language Processing somewhere.
But when we were talking about structured input CAC, that's a specific type of software application available today that uses a SIG picklet, that sort of thing, that are pre-coded. And the systems that we're familiar with today are pre-coded in IC-9-CM because that's the predominant thing used today for billing.
In most of the systems, the use case for the applications are billing.
MS. WATZLAF: And we also did see in some of our research that when we asked them -- we did ask, you know, what about SNOMED CT? -- they said they were working on those but at this point they didn't have that yet because, of course, ICD-9 and so forth are the ones that they would need for the billing process, just like Mary said.
MS. GREENBERG: So the CAC applications currently don't interface with SNOMED CT?
MS. WATZLAF: They could be, but at this point, they said they were working on that. They could actually apply it, but they haven't done it.
DR. HUFF: I think it's probably worth distinguishing those two parts, or two different kinds of inferences. I mean, you know, if I were implementing, say, logic, you know, to carry on the hypertension example, you essentially have very simple logic that says, oh, somebody has placed the SNOMED code for hypertension on the problem list; I can infer --
MS. GREENBERG: It's a no-brainer.
DR. HUFF: -- this ICD-9-CM code.
MS. GREENBERG: Right.
DR. HUFF: There's another way. And, I mean, if you were literally implementing this and you wanted to be accurate in terms of hypertension, then you'd say, "Oh." But if they didn't do that, gosh, I could actually look at their blood pressures. I could have a simple rule that said, gee, if I observed blood pressures that were over 140 systolic and over 90 or 85, whatever the current rule is, for diastolics, and I saw a sustained pattern of that over months, and I also saw anti-hypertensive drugs were prescribed for this patient and I saw that they had hypertensive changes noted in the eyes from the ophthalmologic, then I could assert, yes, this guy's got hypertension, even though nobody put the hypertensive code anywhere in the record.
And I guess maybe the reason to make the distinction is the current mappings are looking at, you know, complicated versions of the first thing where the assumption is that the diagnosis codes and some combination of diagnosis codes are there, and the other more basic logic that would allow me to look at the more primitive things and assert an inferred diagnosis of hypertension, you know, we're not doing as a shared collective work anywhere, and there's probably benefit in both of those. The first thing is much easier to do early, the low-hanging fruit. The second thing is harder to do, but ultimately might prove very, very --
MS. GREENBERG: Well, there are quality issues, too.
DR. HUFF: Yes, because you get the --
MS. GREENBERG: You could look and say, you know, if they're not taking hypertensive medications, but I've seen this pattern in all these other things, so what's going on here? I mean --
DR. HUFF: Right.
MS. GREENBERG: You can see --
DR. HUFF: Yes, that comes back to that one slide with the levels of abstraction. If you develop the rule that says, you know, these are the basic findings that allow you to make an assertion of hypertension, you can do both things. If you see those and hypertension was not asserted, you go, "Oh," you know, something's -- we can assert that.
The second thing is also true, because then you can do quality assurance where you say, "Oh, somebody asserted that but I don't see any evidence of that in the record."
And that comes back to the fraud detection and all of that other stuff. I mean, if somebody's asserting things that you don't see, blood pressure readings, you don't see anti-hypertensive medications, you don't see any of those other things in the record, you go, "That's awfully suspicious," you know?
So both of those I think have merit, and it's nice for you to pick those out.
MR. REYNOLDS: Okay, Jeff, last question on this?
MR. BLAIR: This is a question for Stan, based on our scope of work here, and if you say the right answer, then --
[Laughter.]
MR. BLAIR: -- I'm going to take advantage of the fact that Jim Campbell is here. So, is it within our scope? We indicated that we're looking at secondary -- you know, capturing information once at the point of care and with clinically specific terminologies and then using derivatives of that for reimbursement, public health, clinical research.
Question: Is it within our scope of work here that if we use that clinically specific terminology to improve the specificity of outcomes data to improve clinical processes and work flow, that that's within the scope that you're considering?
DR. HUFF: Yes.
MR. BLAIR: Okay. Got a question for Jim.
[Laughter.]
MR. REYNOLDS: Try again, Stan.
MR. BLAIR: Jim, you're one of the few organizations, or you represent one of the few organizations that I know that has been using SNOMED, and therefore, have you, in fact, been able to take advantage of SNOMED to improve the specificity of your outcomes measurement to improve clinical processes or work flows?
MR. CAMPBELL: I'm sorry, Jeff. I heard everything, but what was the question?
MR. BLAIR: Have we done it? Have you used SNOMED to improve the specificity of outcomes measurement which then has flowed into improving clinical processes or work flows?
MR. CAMPBELL: I don't know that I can answer that question on into the question of the work flow. I can tell you that we have been, you know, implementing quality assurance initiatives -- for example, on diabetes, for example, on community-acquired pneumonia -- over the past year and a half, two years, in alignment with a lot of national priorities and that the information in our database, in our clinical records system, needed SNOMED in order to be successful in terms of getting sufficient clinical information to support those guidelines.
So in everything that we have done along those lines, we've been, I think, very happy with what we've gotten out of SNOMED in that respect.
MR. CAMPBELL: Now, I can't give you then, you know, how many patients were not hospitalized or how many did not come back to the emergency room.
MR. BLAIR: Okay. But you have gone through this process, and I'm wondering if you have any guidance or recommendations to the NCVHS then for things that we should consider that should enable, facilitate, make it easier for you to do that, because improving clinical processes and work flow is something that's a very important thing we want to do and you're one of the few that have gone through that process.
Were there impediments that you encountered --
MR. CAMPBELL: Well, there's other vendors that I could point you to who are in the midst of, I think, the same process. But in reflection of an earlier comment, I would say that in 2004 when the National Library of Medicine signed the contract with CAP, on that next release, you know, our problem lexicon went out to all of our clients with SNOMED for the first time, because we didn't have to worry about contract costs at all those individual sites then in distributing it.
So at least that's the first testimonial, even if you haven't had any others. And so I think there was no question that cost was a big barrier, and suspicion, and worries about ulterior motives and long-term contract issues.
So I think that has been very important in terms of pushing the whole discussion forward, more towards the issue of clinical relevance and outcomes which is, I think, where it needs to be. Right now, I think one of the biggest problems is education, understanding and guidelines for how to move forward, because the whole thing is complicated and it's not clear just how exactly you do that.
So some of the things we're looking for in the SNOMED community are basically implementation exemplars as pathways, if you will, for other vendors to help give them some assurance of, you know, what the risks and benefits are of proceeding.
MR. BLAIR: Thank you, Jim.
MR. REYNOLDS: Okay. Again, thank you very much for the panel. You obviously spent an incredible amount of time getting ready and we appreciate you helping us slug through this thing, which is still going to be quite a bit of a struggle.
Stan, I'd like to turn the last few minutes over to you to -- we'll try to adjourn about 5:30 -- go through a summary of today and in case anybody starts getting out of here before that, thank you. What an incredible amount of information, what a great panel. We already thanked everybody in e-prescribing but you personally were really grabbing hold of this and taking it -- thank you so much because most people don't know this much after a year, let alone after one-half a day. So, thank you.
DR. HUFF: Well, I want to thank the people who were willing to come and present because I really do appreciate everyone, you know, Valerie and Mary and Dr. Campbell and Clem McDonald and obviously Vivian's testimony, too, about what's happening. All very pertinent.
I don't know at this point that I want to make a summary. I'm excited about this subject; I guess I would say that. And I was pleased by how much I learned from the people who testified and wanted to thank them.
Other than that, you know, I'm ready to quit, so --
[Laughter.]
MR. BLAIR: You mean for the day?
DR. HUFF: For the day, sure. For the day.
MR. REYNOLDS: Seeing nobody jump up to make Stan keep doing, we'll adjourn for today.
Our plan tomorrow is to talk about future meetings. We can obviously continue a bit of debrief here and then we've got to look at the rest, the other things that are on our plate plus, you know, meld in the things we heard today to see what we do next.
So, starting at 8:30 in the morning. Thanks, everyone.
(Whereupon, the subcommittee adjourned at 5:21 P.M., to reconvene the next day.)