By LEONARD KISH

To answer their question, they did research on use cases and published a definition in a JAMIA article, “What makes an EHR “open” or interoperable?”

Leonard Kish, Principal at VivaPhi, sits down with Wright to talk about the EXTREME (EXtract, TRansmit, Exchange, Move, Embed) use-case based definition and more.

LK: So let’s just start from the beginning. Introduce yourself, how’d you get into interoperability and what are you working on.

AW: I’m an associate professor of medicine at Harvard and I work at one of the Harvard affiliated teaching hospitals – Brigham and Women’s Hospital in the general medicine division there although my background is in biomedical informatics…I have a PHD in biomedical informatics. Before that I studied math and  computer science. I got into health IT and interoperability because it just seemed like a ripe and interesting place to be applying things that have worked in other industries and asking “How can we apply some of this thinking to problems in healthcare?”  
What was attractive was that obviously the problems are interesting, but there’s also something pro-social about it. If you apply information technology in a way that improves health care and improves the lives of patients it essentially reduces errors and improves quality. That’s an appealing way to get involved. So I studied biomedical informatics and my focus has largely been on clinical decisions support systems and electronic health records. One of the key ways we build good support systems is by having good data. It’s a “garbage in – garbage out” problem.  One can’t make good decisions without good data. One of the problems is that a lot of the time data exists but it isn’t in the computer or isn’t in MY computer. Maybe someone has had a test somewhere else and I might not have any info, or if I’m lucky I might have a scanned .pdf of the results. But it’s rarer still that I’ll have good, structured data that I’ve been able to pull in from outside sources without a lot of transcription of effort. So I became very interested in this problem of interoperability and have been doing a range of different kinds of work.  Some of it actually focuses on how you do decision support, in the cloud or across systems.  So the question becomes: how can you build a decision support system that spans several electronic health records and integrated data from multiple sources to make more accurate suggestions for patient care?

LK: A lot of this is being talked about in Congress because of the precision medicine initiative and the 21st Century Cures Bill. It seems like there’s a growing awareness that interoperability is needed because to have precision medicine. To make good decisions, you need to have good data. And to get data you’re going to need interoperability or you’ll need the data in the right place so that you can make sense of it. Is interoperability a requirement for 21st Century medicine?

AW: Absolutely.  I think some of it has to do with the nature of the health care system in the United States.  Most people will have several jobs over the course of their lifetime and because health insurance is so tied to employment here, they’re likely to have several different health insurance plans and see many different doctors and perhaps receive health care at several different hospitals.  All of those are independent entities, which means we wind up with people who have fragments of the complete picture of a patient’s health history.  But perhaps no one has the complete picture, except (maybe) for the patient (and that’s assuming the patient has a good memory or is good at taking notes or getting copies of their records). So it’s very challenging. One of the things we’d like to see in precision medicine is subtle effects or time-delayed effects.  Are there complications from drugs?… Often you’ll take something and it might have a subtle effect that manifests years later.  And the problem is the more that we fragment patient data, the less likely we are to be able to spot trends like that.  You might have my exposure to something in one electronic health system and then the outcome that I experience is in a completely separate system.  My sense is that the main reason we should do interoperability is to get better care to patients.  That’s the number one reason.  But certainly an ancillary reason that I think is compelling is the ability, with the right consent and privacy practices in place, to do good research and quality measurements on the data. So I think interoperability is a key part to doing that.

LK: One of the things I like about your EXTREME definition of interoperability is how you have the different stakeholders.  There are many key players, including patients, that have a role with all the data that moves through our health system.  So maybe you could talk about how you arrived at the concept of the five stakeholders. 

AW:  Let me start with how we got started on this idea in the first place.  About a year ago Congress had started to have all these hearings.  And there was a lot of angry finger pointing.   We started realizing that there were kind of two levels where this was working. You had talking heads, pundits and politicians saying “We need interoperability and openness!” and on the flip side you had a bunch of skilled, capable people in HL7 working on the real details of the messaging formats, service formats and the ways that we actually exchange, format and structure the health information we want to move around.  So you have one group of people operating at a very high level saying “OPEN OPEN OPEN”.  And one group who was working at a very detailed technical level.  But there was a gap in the middle. What does it mean to be open? Why do we want our systems to be open?  What do we aspire to do once our systems are more open? Why are we making these standards? The beauty of the HL7 is it can be used for many different purposes.  So it seemed like doing something in the middle that would put some meat around an idea about what it meant to be open and interoperable was sort of intriguing to us.  We started just talking to our colleagues and looking at interesting things going on, but we weren’t exactly sure how we would orient it. Eventually we came to the idea of these use cases.   Because it seemed like the best way to know if the system was open was to see if we could say “we could do these useful things with the system”. So we started talking to people about what they had wished they could do with their systems, or what they had eventually been able to coax their systems to do and eventually we started to coalesce around these use cases. A lot of people who have been on electronic health records for a while now are actually at a point where, rather than implementing for the first time in the EHR, they’re actually in the process of replacing in the EHR.  So we heard a lot of stories about the pain involved in extracting data from the old one and loading it into the new one.  Almost everyone we talked to actually lost a lot of granularity in the process.  So you have a patient’s current medication list but then you have the history of all the medications you used to take, when changes have been made, who it was who made those changes, information about refills etc.  That information is actually sometimes useful.  You want to look at that information and ask: “How have we evolved the patient’s treatment for hypertension over time?”  And what we saw at a lot of places was that over time the medications would be imported and were there but the dates would be the date the system went live, the prescriber would not be available, and the history would be absent.  So that was a gap in being able to EXtract(EXT is for “Extract”) the data in a rich granular format so that you could bring the data into a new electronic record.  So that partly deals with the EXtract and partly with the Move (The “M” of “EXTREME” is for “Move”) uses cases. “How do I get the data out and put it into my instance for research or load it into my data warehouse so I can do quality reporting.”  But a lot of what we heard actually had to do with moving from one electronic health record system to another one. The Transmit (“TR” is for “TRansmit) one is one that we’ve seen a lot of use on.  Which is “I want to participate in health information exchange” or I even want to send some sort of bundled set of health information in a CCDA or CCD document to my patient or my patient’s delegate.  So I think the Transmit use cases are the ones that people often equate with interoperability.

LK: Well I think it’s one of the most frustrating ones.  You hear this story all the time.  There’s a commonly used example where somebody shows up in the ER and they need to get moved from the ER to another facility and the record can’t be moved.  I actually had a family member break an arm and had to go to an ER.  So I actually asked if we could get the images on a disc.  We got the disc (without any security whatsoever) and then we went to the orthopedist for a follow up appointment and she says, “Make sure to take this disc with you, because they won’t be able to get the images upstairs electronically.”

AW: And that story is so typical right?  I can see a hospital from my window that is right next to the hospital where I work and we have only limited capability right now to exchange information with them.  And like you said we provide physical copies and ask the patient to shuttle them.  The problem is that maybe a quarter of the time the patient loses it or misplaces it.  It just seems like there are ways we can be doing better by our patients.

LK: And everyone is used to it working better everywhere else.

AW: I’ll be honest with you; a lot of our patient’s seem genuinely surprised that we don’t have access to their information.  They would say something like “Oh yeah I was in Minnesota 8 years ago with a similar problem and they did a CT scan.  Why don’t you check that one?”  We can’t.  We call the hospital and fax back and forth, then they send the disc to us then we send it down to radiology.  In some ways I hate these examples like “My bank card works in Shanghai” and similar, but it’s just what people have become used to and they expect healthcare to work the same way. And I think that it’s maybe a harder in health care but it’s also awfully important and I think we could be doing more than we’re doing. So there’s Extract and Transmit, and then Exchange (E is for Exchange) is kind of Transmit wrapped with a few other features like the ability to display or view the CCD documents imported to participate in record location or interact in a fuller way. One particular thing that we tried to call out here is the ability to not require a “push” all the time but also allow a “pull” option.  So right now we have a way to send messages directly from my system but if you want to get one you have to call or send an e-mail saying “Please send Mr. Jones’ records”, then we have to send it and hope it works and then call back on the phone to make sure it works.

LK: It’s another kind of consumer driven thing.  You almost expect it to be like Google docs or something.  Why isn’t there just an image viewer in the cloud that you can just point to and say “that’s my image”?

AW: Exactly.  It seems like we’re far away from where we want to be in terms of exchange. So the last “E” is Embed, and this is the one I’m most excited about and where my own research is at right now.  We’re mostly either purchasing a complete system or choosing some “best of breed” approach, and using interfaces to integrate our system.  But certainly with SMART and more recently with FHIR and the Argonaut Project, I think we’ve seen a lot of movement toward the ability to actually embed applications into our systems. A lot of our HR systems have the ability to embed a PubMed window or an up to date browser in a tab in the HR. But here we’re talking about sort of deeper linking.  Contact sensitive patient information is flowing to an outside service and making some recommendations.  Then in a reasonable, workable, actionable way we’re giving suggestions back to people.  And I really think this is the way a lot of decisions for it are going to go.  We see all the time our physicians go online and use a risk calculator for cardiovascular disease risk or the Frac score for fracture risk.  It always seems so funny to open up a web browser and enter the patient’s age, weight and some information from these electronic reports.  Whenever I see someone taking information from one source and entering it somewhere else, it always raises my antennae and makes me think “this is somewhere we need to improve.”  I think more sophisticated standard space ways to embed applications, especially applications that can do things like place orders or make updates to the chart – not just render information – is going to be a big step forward.  I think the SMART project did a lot to set an agenda for that but there’s still a lot to do in terms of getting people to actually implement these things.  So we’ll see where that goes.

LK: So you mentioned FHIR and the Argonaut Project.  How do they fit with Extreme?

AW: We talked about ways that we might extract data from a medical record, it’s possible that if we have the right FHIR profile that we could use FHIR and API’s to extract data rather than dumping data out to a flat file or something like that.  What’s impressive to me about FHIR is that it’s a flexible approach.  I think that a lot of the packages with the other approaches were heavy weight and people struggled with implementation.  I think FHIR is a nice standard or a nice framework for creating standards in that it really allows you to flexibly create profiles for different use cases.  So I imagine you could use FHIR profiles to actually support a number of these approaches.  The commonwealth group, which is an industry based approach to information exchange is trying to use FHIR to do their health information exchange. So I think there are some uses for FHIR other than just embedding.

LK: What’s been the response since you wrote the EXTREME JAMIA article?

AW: It’s been very positive.

LK: Yeah that’s what I’ve seen.  I haven’t really noticed a lot of pushback.

AW: Yeah I think people said “Yeah this seems to be something we needed.” One thing we didn’t want to do was to show up and be another standard to compete with HL7 or something like that. We wanted to operate at a level where there is a need but there seemed to be a gap. I think the only pushback we’ve gotten is stuff like “ Hey we already have CCD, isn’t that enough?” and our response has been “That’s a really important building block and it helps with a number of the use cases but not all of them.”  The way you implement a CCDA and how you generate and send it affects a third utility.  I think this isn’t meant to compete with HL7 or CCD or FHIR but rather to complement them and if anything help outline some of the use cases where they might deploy the technology that they’ve been working on.

LK: What you’re proposing could really be a measuring stick, isn’t that where you want to take this?

AW: Yeah, I think so. You always want your goals or your standards to be measurable.  I think that there is some work to do.  Right now it’s very aspirational and I think we need to get down to brass tacks and ask “Well what does this mean? How will we measure or tell if a system supports extraction or supports moving or supports embedding.  And there’s a lot of work that my team will be working on – and I hope other people will be working on too – to actually take these concepts and really flesh them out in a way that we can objectively measure them across electronic health records.  I think that is the best next step and I think it’s something we can’t do by ourselves.  I think we need participation from a lot of stakeholders to really spell that out.

LK: How do you see getting that support going?

AW: I think we’re at the beginning of that. We’ve been talking to as many people as we can about these use cases.  We’ve been trying to look at how the standards work.  My hope is that vendors will see this and say (and some have), “How is our system measuring up? Let’s make sure we have this functionality.”  Half of the battle is having this functionality at all and half is having it in an open standard way.  We’ve heard from some vendors who say “We have our own API.  We’d like to move to supporting FHIR but we think it’s a little early, when do you think is the time to start thinking about it?”  Now is the time to start thinking about it. What this really essentially involves is a large group of stakeholders, patients, healthcare providers, HR vendors and standards developers all need to come together.  I think that the risk is that if we don’t do it the government will come in and impose a “one size fits all” definition on what it means.  And it may not be what any of us need.  So I think there’s an opportunity for us to work together collaboratively in the field to define that.  If you look at how the Internet works, standards have evolved for the web or email over time and people have really seen the value of collaboration.  I realize if I make a web browser and you make a web server, we better agree on the details of HTTP and HTML.  So I think we need to somehow catalyze a movement like that in health care.  And I honestly think that increasingly patients at our hospitals are expecting and demanding the ability to be able to email their doctors to see their lab results as soon as they are available to schedule online appointments.  My hope is that they’ll be demanding the ability to see complete accurate records in ways that that they can download and upload into their personal health record.  I hope that patients will be driving us toward a better answer and I think my job is to teach patients what to be asking for, or expecting or what is possible so they know what questions to ask.

LK: That’s the question I think – how do you get patients into this? Because everybody wants their data when they’re leaving the clinic, but when we’re dealing with the rest of our lives it’s not something we really think about.  So I think it takes a little bit of awareness but it also takes helping people understand what they can do with the data.  It’s not about the data per se but how they can use it to make their lives better. It seems like in some ways open data is the first step, because once you open up the data then people will think up creative ways to make it more useful, and that brings us to the next question about the will.  The reason this kind of stuff works in other industries is that there is usually some sort of a profit motive for sharing information or for making standards work.  My ATM works in a lot of places because there’s ATM fees that everybody could get a piece of if I can withdraw money anywhere in the world. In the BJ Fogg behavior model, it essentially says that half of what we decide to do is how enabled we are to do something. The other half is how motivated we are to do something.  One of the things that came out of these senate hearings also was that so much of this is based on value based care and getting away from Fee for Service, to change the stakeholder perspective on the system so that they’re not as concerned billing and can actually record the clinical encounter in a way that’s meaningful, because now we incentivize billing and we get billing systems in healthIT. So that’s a long-winded way of asking how much of this is will and how much of it is technology?

AW:  I haven’t seen a lot of what you would call intentional refusal to provide data.   My best guess is that it’s not that intentional.  We would never say “You cannot have a copy of your information” or “we’re trying to lock you in”.  I think that that they genuinely aren’t doing that.  The problem is that there are so many things vendors can be working on and they can’t do all of them.  So I think that people are responding to incentives and they’re responding to the incentives that they have.  Right now it doesn’t seem as if it’s a key competitive differentiator for a health system to be really good at providing patients with copies of their data.  But I think that might change.  I think that if patients are more sophisticated about asking their health system’s for data I think we might see that as a differentiator.  I think that at the same time in procurement hospitals are asking their HR vendors: “Do you support FHIR? Can I embed apps that we’ve developed into the system?” I think that there may be a shift. I happen to work at a hospital that has a long history of developing our own software, and we switched recently. A key question for us as we were considering different vendors was “To what extent can we embed or replicate the functionality that we’d developed in our prior systems in this new system?”  So I think as health care systems start to become more sophisticated and develop their own technology or want to purchase technology from other organizations, I think people might start asking these questions.  And I think that’s the point at which vendors are most likely to respond by adding capabilities.  The alternative is some external force like the certification requirements or Congress forcing the vendors to do it.  I guess this is a free market perspective in my mind, but I think it’s going to work better if our customers start understanding and articulating their needs and then purchasing the health care service or software that best fits them.  So I kind of hope that is the way this will evolve rather than through regulations and I think that’s yet to be seen.

LK: Yeah I think it works best that way.  Better carrots than sticks.

AW: Right. Nobody’s ever forced me to want to use the internet or Gmail or anything like that. They were obviously better to me.  The problem is that in healthcare often times using an electronic health record effectively often slows me down.  But it benefits my patient or the insurance company that’s paying for my patient’s care.  So there’s always this issue where benefits accrue to someone other than the person to whom the costs accrue.  As you said, it might be value based payment, new care models, or new ways of reimbursing for chronic disease management. Things like that sort of push the needle so that some of the benefits accrue to the person, usually the health care provider, that is incurring the expense.  I guess it’s my hope that that’s how’ll achieve that.  I think meaningful use was in some ways this attractive carrot, but it’s also a stick.  The real solution is I just pay you a little bit of money a few times and I make better software that you want to use and/or rearrange the way I pay you so that your incentives are such that you want to use software that leads to better outcomes for your patients.

LK: We had this big impetus to replace paper (through Meaningful Use).  It’s been largely successful through meaningful use.  But how much of that is that now we’ve pushed forward digitizing these paper based systems.  Do you see that as part of the problem?

AW: Absolutely.  I think there’s this tricky question: Given that you have this big thing to accomplish, how do you start?  So assuming that it’s back in 2004 and the president says “I want there to be interoperable health records.  Everyone should have health records electronically. And we know the adoption isn’t where we want it to be, and the technology isn’t where we want to be.”  It’s kind of like the chicken and the egg problem.  We can either push the technology and say “we’re going to have our Manhattan Project and we’re going to build the best EHR technology over the next five years and after that we’ll bring the doctors live.  Or you can push everyone to go live and you say “once we’re live we’ll make the software better”.  And it’s hard to know which of those approaches is the best one. I think that we’ve largely, especially with meaningful use incentives, said we’re going to go with the technology we have (“shovel ready project” was the language we used at the time) and we’ll improve it as we go along.  And I think that it introduced a little bit of distortion into the marketplace.  The way that a lot of this works (say, with the internet) is a few nerdy people use web browsers and the internet, then they provide feedback and we learn more about their habits.  Then later on it got a bit better and few more people were interested.  The more people that are interested in something like the internet, the more people will invest in making better websites or browsers.  There’s probably something similar in EHR.  There are people who have been using electronic versions of health records since the 60’s or even a little bit earlier.  There were people who were doing that.  Then we introduced this pressure to get more people to adopt EHR’s more quickly than they would have, with the normal pace of technology adoption.  And I think that might have been ok… The more people are on the system, the more useful it becomes.  There’s more data to share and more people to communicate with.  So that was the approach we picked.  We were going to create these strong incentives for people to adopt EHR’s, knowing that EHR’s were not yet perfectly interoperable or even always perfectly usable and didn’t have all the functionality that we wanted.  And now we’re trying to go back and patch that.  The thing is we now have had a lot of opportunity to learn how, with these EHR’s that were developed with large hospitals or academic systems in mind, how do they really work in critical access hospital or in a single doctor practice.  So we’ve learned, and I think the key is going to be to translate what we’ve learned into concrete improvements.  But I think that’s been hard.  I talk to some of my friends who are vendors and they’ve said  “A lot of people are giving us feedback and we’re working on it as fast as we can but at the same time we’re getting a lot of pressure from Meaningful Use.  So we can’t even use our best developers to build the stuff our customers are asking for asking for.”  So I think some way of fixing how we do innovation in health IT is going to be important and I don’t know how exactly how we’ll do it, given how many competing priorities there are.

LK: Well you bring up a really good point there.  I think it’s a lot about the creativity and the community of people actually working on the problems together.  So much of the internet is distributed by open source and communities that have developed there who have released powerful new solutions to shared problems.  I went to some of the senate hearings on information blocking last week and there were talks about openness in terms of gag clauses in contracts and things like that, more of a cultural acceptance of the lack of transparency.  On so many different levels there’s been a push to keep information and data almost silent.  So maybe that’s another part of it, the culture.  Because of all these blocks and the culture of health care, the developer communities haven’t been allowed to develop around these problems as quickly.

AW: I think that’s a really good point. That’s been a frustration of mine.  If I want to go to IOS app, I can get the SDK for free and it costs me $99 to release it in the app store.  If I want to build on most large commercial platforms, I have to sign a bunch of nondisclosure agreements, and enter into contracts. I might have to even pay $20,000 for access to the SDK.  So it’s hard for the people who like to tinker, who are pretty valuable people to have working on your program, to get involved in it.  So I think SMART was an attempt to fix that.  But the update to SMART has not yet been what I would have hoped it would be.  Maybe FHIR helps fix that.  I don’t know.

LK: It seems like it.  At least if you have open API’s you give people a chance to be creative with solutions they can create.

AW: Exactly.  The thing is people do creative wonderful things.  We talk about mashups a lot – people combining maps in interesting ways and just put things together in ways that you weren’t even guessing they were.   But I also think patients might do interesting things.  “Can I combine my FitBit data with my cholesterol results and, and learn something about myself”  It’s always hard to prognosticate, but I think this ends in ten years (or sooner) with a marketplace where people are able to make these apps and systems are more interoperable.  I think the question of how painful it is to get there, and how much disruption here has to be in the marketplace is a really open one.  In my mind, there’s almost an inevitability that we eventually get to a place where there is exchange of information and openness.  I just don’t know how precisely it’s going to happen yet.

LK: Well I think people are paying more, and so there’s a lot of examples of patients researching their problems, self-diagnosing  and just doing amazing things if they just have access to the data or informational tools like open API’s.  Talking about the will… they probably have more will than anybody. Changing topics slightly, one thing that came out of the hearing was a quote from the CEO of Allscrips that said “60% of physicians would actually change their recommendation if they saw the whole record.” That to me says that there is a huge quality issue there with the lack of interoperability.  He mentioned another study that I haven’t had a chance to look at yet.  I think he said it was out of the University of Pittsburgh.

AW: I’m not familiar with that study but I think that it squares with my intuition.  I think that in some ways we’ve all been obsessed with this one use case where you’re on vacation, you show up unconscious at the emergency department, you log in and see some key fact that helps them treat you.  And maybe that’s true sometimes but I think it’s not extremely common that that is how interoperability helps you.  I think that the kinds of errors we’re making due to the lack of interoperability are really a lot more insidious.  Missing an allergy that you had documented a long time ago or not spotting a trend in a lab test because you had it a few years ago in one place and I had it this year at my place.  We’ve seen a lot of issues in my area with a patient who has seen one specialist and got some test results, and then they go back to their primary care doctor who doesn’t have access to the results, or they go to another specialist and there’s some confusion about who is responsible for test results or who can see them.  So I absolutely think that seeing a complete picture of a patient’s information is key for safety and I do think that lack of interoperability is 100% a safety issue.  It’s something that we need to work on.  But we need to get beyond the “unconscious patient in Wyoming.”  I think that there’s so many more complex, subtle and insidious issues.  The thing is that it’s often hard to measure.  It’s hard to say “this is the one piece of information that changed my mind”.  But I do think complete information like that is going to be very important.  I’ll also offer you a flip side that I don’t really have an answer for yet: How much information am I responsible for viewing about a patient?  Somehow I now have every piece of information about a patient from the moment of birth to the present.  That might be more information than I can review before my brief visit with a patient.  Part of the solution to that is going to be in technology or tools that will help me summarize the information, spot key information, spot trends etc.  I think it’s going to be really exciting when we have that problem and have to build those tools.  I look forward to the day when we have so much information that we really need sophisticated tools to organize and sort through it.  Right now we’re a long way from that.  But I think you’re 100% right that it’s a safety issue.  But I’m not familiar with that exact study.

LK: In James Gleick’s book, The Information, he essentially says “from the primordial soup, to now with the Internet, the question of competing has always what to do with more information and how do you make it valuable.”  In healthcare, figuring out what’s important would be a good problem to have I guess. 

AW: I look forward to having that problem because how much will we have accomplished by the time we’re overwhelmed with interoperable data that has flowed into our system.

LK: So the last question is something Dan Monro brought up.  Dan did a three part series on interoperability on the site I write for called HL7  Standards.com. Essentially if you don’t have a patient identifier, then interoperability is a waste of time. He alluded to the idea of patient identifiers being something like a social security number in that they’re kind of old-school.  There’s better ways to do it with cryptography and being able to ID people biometrically.  So what can you tell us about patient identifiers? 

AW: I think it’s awfully important.  It’s certainly the case that when I have a database and you have a database and we want to link them together, it matters that we have a key so that we can tell who is the same person.  The approach right now with using a social security number has problems.  Not everyone always has a SSN, not everyone remembers them, there are errors, they lack any way to validate them, etc.  Using something like your Blue Cross member number is no good either because you can get another job.  So I think the solutions we have now are rotten.  We need some way to identify patients across systems.  The most commonly proposed, and probably simplest or most parsimonious solution, is a national patient identifier.  A numerator who sits in the government and assigns everyone a number shortly after birth and that’s their number.  That is just not going to fly palatably.  I just can’t see us creating the political will and I also am not sure that it is that desirable.  Travelers could come to the country and not have numbers or Americans can go elsewhere and how will this all work? It seems problematic.  But I think there are smart ways we could use technology to approximate that.  For a long time we had probabilistic record linking approaches where we look at your name, date of birth, address, age, sex, etc. and try to figure out what is the probability that these two people are the same, and we’ve had some pretty good results.  The Indianapolis Network for Patient Care has had some pretty good results there, using probabilistic linking rather than an identifier.  The reality is that if we can put the patient at the center of this and creates a credential and authentication that they control, I think that would be a lot more palatable than if we put some sort of central government number assigned to people.  And we have great examples.  I log in to Trello, a lot of other sites using my google account. And they use OAuth.  So I think there’s probably a lot we can learn from Internet authentication about how to create reliable patient identifiers with creating better identifiers, more security around them.  The patient could see more of their information and how it was shared.  I just think that there are better solutions than a single government based  national patient identifier.  And even if it’s the best solution, I just don’t think it’s politically possible.  So I think we ought to be focusing our efforts on something else.