Interoperability: Do we have the value proposition upside down?

互操作性:我们的价值主张是向上的吗?

2019-04-11 03:10:31 Healthcareitnews

本文共6268个字,阅读需16分钟

Dr. Doug Fridsma, CEO of the American Medical Informatics Association, has been working on the nuts and bolts of interoperability for a very long time. Prior to joining AMIA, he served as chief scientist at the Office of the National Coordinator for Health IT, leading management of the Federal Health Architecture and Standards & Interoperability Framework during the pivotal post-HITECH period. Since then, Fridsma and his AMIA colleagues have been vocal proponents of a forward-thinking and creative approach to interoperability, with an eye toward the health system of the future – one fed as much by data from medical devices, apps and other consumer-facing technology as by the clinical elements of the electronic health records. In a future driven by new types of patient-generated information and social determinants data, most of it coming from outside of traditional health systems, Fridsma says it's critical to think of interoperability not as a goal to be strived for, but as an ongoing process, driven by diverse stakeholders, that will continue to evolve and be reshaped by emerging developments. Fridsma spoke recently with Healthcare IT News about some lessons learned from his tenure at ONC; what AMIA thinks about the proposed interoperability rules from 21st Century Cures; the importance of staying focused on achievable use cases for data exchange, why it might be useful to share first and standardize later, and what lessons can be learned from the APIs undergirding the World Wide Web. Q. What's AMIA's take on interoperability? Both where we are now, and where we're going? The organization takes a pretty expansive view of how it should develop. What are the components we need to be thinking about, beyond the walls of hospitals and practices?    A. What is the purpose of interoperability? What is it that we're trying to achieve with the interoperability specifications and the standards and all that other stuff? I think it's really important that we don't lose sight of that. The reason we want things to be interoperable is that we can exchange information and then use that information that's been exchanged in powerful ways. Is it because we want to be able to have apps and other devices that help empower patients to be first order participants in their care? There's a whole host of things that we need to consider, and in my view of the world, interoperability can't be separated from the thing you want to do. Because interoperability isn't some kind of abstraction, some verdant green pasture where, you know, it's flowing with milk and honey – or flowing with data – it really is about being able to do something now that you couldn't do before, because you have the data in a format that allows you to make that happen. And so, to me, that's part of what we really have to make sure we do, is to recognize interoperability is difficult in the concrete, but impossible in the abstract. You have to think about what you're trying to do, or what you're trying to accomplish with interoperability. Now, that has a couple of good outcomes, right? It becomes much easier to measure it. And it also becomes much easier to see if you're making progress if you've got something tangible that you couldn't do before that you now are able to do as a result of systems being interoperable. Q. Have we even truly gotten to the point of having a reasonable sense of what we really want and need to be able to do, beyond bi-directional exchange? A. As the world progresses, we're going to want to start doing new and different things that we didn't anticipate that we were going to do 10 years ago, right? So if interoperability is defined by what you want to do, and over time you want to keep doing more and more things, in some sense you lose sight that it appears as if interoperability is fading away. Because the gap between what you want to do and the data standards and the infrastructure to help support that seems to be widening. But it isn't so much that interoperability isn't moving. It's that the things we want to do with it are changing and becoming more complicated. So we lament interoperability, but in fact we've made good progress. But then, you know, as we make that progress there's new things that we want to try to do: Now that we've been able to exchange this information, let's try to do some more sophisticated analytics, or let's try to make sure that semantically it's integrated. There's a whole variety of things that we could think about in that space. Q. There's a lot of frustration out there, and perhaps rightfully so, that we're still talking about this after all these years. But what can we do now, that we weren't able to do, say, back when you were still ONC? What have we been able to accomplish in the past few years? A. Well I think there's a lot more data that's flowing. It's very specific. You know we've got things like consolidated CDA, and there's exchanging of that of that kind of information. I think one of the challenges that we have is that at ONC we pushed to make sure that we would use standards to support interoperability. And so we pushed very, very hard to make sure that there were structured, discrete data elements, things that were kind of well formulated from a semantic perspective. When you press for structure and standardization first, and then sharing second – what ends up happening is that you have to speculate as to how to structure or standardize in anticipation of that thing you want to do. You sort of say, "If you build it they will come." That if you standardize it, people will use it. And sometimes we got it right and sometimes we didn't get it right. When I take a look at the descriptions of the USCDI, for example, the plan there is that as standards mature, they'll add to the USCDI, and they'll expect more and more information to be shared. My own feeling is that it has the equation upside down – or has the value proposition upside down. I sort of feel like we should share everything, and then standardize it over time. So what ends up happening is, if you've got the entire designated medical record set, right, there are some very basic standards that give you a little bit of metadata. They'll say, "This document is about Mrs. Jones from Dr. Smith at General Hospital; medical record number, date, and it's a pathology report. So rather than trying to standardize disease progression or disease classification, or the ontology of possible malignant diagnoses, or structuring the way in which all the elements that might be captured in a pathology report are there, we should get that pathology report out and to have just a minimum amount of information, and then all of the rest of it pretext. And computable. Not necessarily standardized, but computable. Because then I think what happens over time is that all the pathologists get together and say, "You know, I'm getting all these pathology reports, and they're all different. What if we just got together? Because it would make my life a whole lot easier if we all did it in a similar way.” What ends up happening is that you actually share at first, recognize the value and then have sort of a value-based standardization process that you can prioritize, based on what people think are going be important to standardize because they've looked at the data, they've seen what's in it and they can figure out ways to do it. Because there may be other things where you say, “You know what? I'm just going to use Google Analytics. Or, I'm going to go to natural language processing. Or, I'm going to convert this to FHIR resources and that'll be enough for me.” We don't have to do a whole bunch of standardization. Google did a really nice Brain study where they took huge datasets and they used an NLP, created FHIR resources, and used that as a way of providing some structure, after it was shared. Now, they basically said it's not worth it to try to standardize all those reports before we share them. We actually can use other techniques to be able to get get value out of it. So if interoperability is really about exchanging and use, they figured out a way to use it without those standards in place. Q. When we look to the future, though, we're talking about even more complexity: patient-generated health data, medical devices, etc. How well-positioned are we to be able to capitalize on some of that, given the ongoing challenges with just "basic" EHR data? A. If we try to standardize or structure it all before we have an opportunity to share it, it'll never get shared. It will never get there. And so it even gives more impetus. Right? Just like I was saying: The gap between the goal of ubiquitous interoperability and where we are now has widened – in large part because we want to do more things with the data. The gap has also widened because there's more kinds of information that are out there as well. And even if we spent all of our time, money and energy right now to standardize what it is that we've got, and tried to create some sort of interoperability specification that would help us exchange that information, next year there's gonna be new data types and new kinds of information. We're never going to actually be done with this job. So let's not wait, and let's not let the perfect be the enemy of good. Let's not let good be the enemy of better either, but let's try to make sure that the information is shared and then smart people are going to tell us what we should prioritize, and then we can use free text and other techniques to get the value we want out of it. I think one of the things that we have to be very careful about is that many of the people that are in healthcare are thinking about how all these things can interact with healthcare systems. But the reality is that the healthcare system is one of many players in this. There are consumers. There's billing. There's you a whole host of different groups, and more and more data that's going to be relevant to healthcare is going to actually be found outside of the healthcare environment, rather than inside. For example, things like social determinants of health. One response is: Let's standardize and let's create kind of social determinants of health that are captured in the healthcare system. The other way is: How are we going to get to a point where we can have interoperability with social services, for example, so that we we actually are able to both send and receive data on patients from social services. So then it becomes even a bigger problem. I think when the problems get bigger and bigger like that, you no longer can look at this from a traditional, kind of architectural view. You have to really step back and say this is more like the World Wide Web than it is creating a program or creating, you know, integration within a single enterprise. And when that happens, you have to have different ways of solving those problems and the World Wide Web is built on a set of standards – kind of a stack of standards, but they're pretty simple. There are essentially four APIs that run the World Wide Web. The World Wide Web operates on a on a get, which is clicking on the link; on a post, which is when you order something from Amazon and click OK to buy it; it has a delete function, which usually only is put into place for a wiki, and an update function. And those four APIs are what really manage the World Wide Web. So what are those kind of basic functions that we need in health care? Because if we can do that and simplify it then it's going to be much, much easier for us to be able to sustain it as it grows. We've got this push to develop APIs in healthcare, and there's potentially hundreds or thousands of them. That isn't necessarily going to be sustainable unless we think about what are the most basic kinds of functions that we need to do. And if we can standardize on those, it isn't like I have to learn 1,000 or 2,000 different API for Cerner and Epic and Allscripts and Apple and everything else. Maybe what we need to do is simplify the approach. And I think FHIR is going to help us because it gives us a more constrained set of building blocks to work with. But you know, what are the basic functions that we need to be able to do? Q. What do you think are the biggest remaining challenges? Are they related to technology and standards? Or are they more kind of cultural, people and process related? A. You go to the technology folks, and they'll say it's all a people problem. You talk to the people, and they'll say it's a technology problem. Everybody likes to point fingers at the other group. I actually think that from a technology perspective, we have some of the basic functionality that we need. But when we start talking about meaning and value and kind of more human characteristics, whether it's on the technology side or the people side, I think that's where we struggle. Because meaning is really important. But it's much more complicated than just having a syntax for how you would engage. And then, as you said about business processes and drivers for information sharing versus information blocking, it really becomes a people and a cultural problem. There's governance issues. Those are the sticky things that are problematic. It's easy to come up with the security and transport standards, and everybody kind of agrees upon those those. Those are much easier than to really understand what the nuances are about business drivers that would allow people to share or standardize things. Or integration in a dynamic way, so that not only do you know the context of the data, but you know where it fits in the workflow. Because people have different ways of doing that, and if you send someone a diagnosis code and it's an admission diagnosis and not a discharge diagnosis, that has implications in how those systems should view that information and if it doesn't capture that context, bad things happen. Q. Obviously, where the rubber hits the road on this stuff is going to be in the private sector. But what can policymakers be doing better or differently? A. There are a lot of ways to solve these problems. I'll just give you an example from usability – it's not interoperability, but it's illustrative. One way to solve it is to assess usability using standardized criteria. NIST has that. The airline industry has certain kinds of requirements for the way in which usability occurs. And you just require everybody to meet the characteristics of a certain usability. I'm not proposing that that's the right way to do things. That carries with it a very heavy regulatory arm that requires people to do certain things in a certain way. I think it tends to inhibit innovation and novel user interfaces that could get better. And regulation is a very, very blunt instrument to try to effect change. Because the more specific you get about it, the more brittle or difficult it is to manage it over time. The world changes and regulations take a long time to run through the process. The other way you could do it is to figure out a way to let markets drive increased usability, and let people vote with their feet that if they've got a good system that has high degrees of usability they should be able to use those systems. And if they've got low degrees of usability, then we should, you know, leave those systems and go in and buy other systems that are going to be better. We see this in cell phones and we see this in other kinds of technologies in which usability, because people can move their phone number and they can move their contacts and they can transfer all the information from one phone to another, they're able to get increasingly innovative and better products. Q. Which would be the better approach, if we can pick just one? A. We don't have a real good market in healthcare. You know, you spend a billion dollars implementing a system. And you spend $600 million if you want to transfer to another one. You don't have the market liquidity that would drive some of those behaviors that you'd like to see. The regulations are trying to address that. This electronic health information, or EHI, export function that's described in 21st Century Cures, says I should be able to take all the information – billing, administrative and clinical – and I should be able to export it from my electronic health record in a format that's intelligible, and that somebody could import into a new system. I think that's an effort to address some of the market failures, or the liquidity of things. But that's going to be a really hard thing for vendors to swallow. The challenge is that you can't or shouldn't have it both ways. You can't have a low regulatory environment in a market that's locked up. You've got to figure out some way to either unlock the data, and let the market drive innovation and interoperability, or you're going to have to have a heavy hand of regulation to force people to do things that they're otherwise not going to want to do or have any need to do. I tend to favor ones that are going to drive better innovation and empower physicians and patients, because it's all about getting the data out of the systems. If you get the data out of the systems, even though the vendors may or may not like that, in the end I think it's going to drive better engagement with the physicians and the patients and probably lead to better innovation and interoperability, because people are going to have to compete on a much more level playing field because if you don't like a particular system, the cost of converting to another system is lower and that makes it easier for you to make decisions that could potentially improve the product. Q. One last question. Speaking as we did earlier about the ONC and CMS rules, where does AMIA stand, and what will you be telling those agencies during the public comments period? A. We've got a set of policy principles that help guide the kinds of things that we pay attention to. We really want to make sure that data is used to make patients first order participants. We like the things that are about getting patients access to their full medical record. I don't want the regulations to put in kind of a two-tiered system, so that patients, if they want their full medical record, have to accept it in a format that is less useful than if I wanted to exchange my consolidated CDA using the Argonaut profile, for example. We really want there to be a more unified infrastructure so that patients can access their entire medical record using the app infrastructure. And there are some standards and other things that could be useful. Because that, I think, is going to drive a whole lot more value for patients than some kind of one shot export function that occurs just for patients. That's going to be really challenging for anybody to do anything with that information. So we really would like to have patients be that first order participant in their care and make them part of the app world, even while they access all of the information that's present in their electronic health record. Ultimately if you can get the data out, people are going to do interesting and useful things with it. And that can help us inform the interoperability conversation because you can get that data to prioritize as your next initiative, based on taking a look at what's there, how close it is to becoming a consensus-based standard and then focusing your efforts on that low-hanging fruit. We've looked through some of the information blocking and there's a whole set of information about what can you charge, and things like that. Because AMIA doesn't sell apps – we're an individual membership organization, not a trade organization – those things are really important and we want to make sure that it doesn't limit patients and providers access to that information. But we probably have less skin in the game about how much is going to be charged or what's legal to be charged for, as long as it doesn't impede the ability for patients and providers to get access to their information. The information blocking is complicated. In some sense, it feels like there's gonna have to be a lot of smart lawyers to try to figure out what's going on there. Like if there's a violation based on a policy, is that one violation or is it the 100 million patients that were affected by that policy? We as an organization have developed three response teams that are meeting every week for the next five weeks. So we've got kind of about 30 hours of work from our members, times about 30 or 40 members. So we'll have a lot of eyes and thought into this. I'm hopeful that we'll be able to produce something that is thoughtful and constructive, because this is really what's going to define health information exchange and the health IT space for the next five to 10 years. Twitter: @MikeMiliardHITN Email the writer: mike.miliard@himssmedia.com Healthcare IT News is a HIMSS Media publication. 
DougFridsma 博士,美国医学信息学协会的首席执行官,已经在很长一段时间的工作的坚果和螺栓的互操作性。在加入 AMIA 之前,他曾在国家卫生 IT 协调员办公室担任首席科学家,在 HITECH 之后的关键时期领导联邦卫生体系结构和标准及互操作性框架的管理。 从那以后, Fridsma 和他的 AMIA 同事一直大力支持前瞻性思维和创造性的互操作性方法,着眼于未来的健康系统——这一方法同样依赖于医疗设备、应用程序和其他面向消费者的技术的数据,以及电子健康记录的临床元素。 Fridsma 说,在未来由新类型的病人产生的信息和社会决定因素数据驱动的情况下,大部分数据来自传统卫生系统之外,至关重要的是要考虑互操作性,而不是要努力实现的目标,而是要在不同利益相关者的推动下持续进行的进程,这将继续演变,并因新的事态发展而改变。 Fridsma 最近采访了 Healthcare IT News ,介绍了他在 ONC 任职期间所学到的一些经验; AMIA 对21世纪 Cures 提出的互操作性规则的看法;关注可实现的数据交换用例的重要性;为什么首先共享并随后标准化可能是有用的,以及在万维网的基础上从 API 学到了什么教训。 问。AMIA 对互操作性有什么影响?我们现在在哪里,我们去哪里?该组织对它应该如何发展持相当广泛的观点。除了医院和实践之外,我们需要考虑哪些因素? A 。互操作性的目的是什么?我们试图通过互操作性规范、标准和其他所有东西来实现什么?我认为我们不能忽视这一点是非常重要的。我们希望事物具有互操作性的原因是我们可以交换信息,然后使用以强大方式交换的信息。 是因为我们希望能够有应用程序和其他设备来帮助病人成为他们护理的首要参与者? 我们需要考虑很多事情,在我看来,互操作性不能与您想要做的事情分开。因为互操作性不是某种抽象,而是一种绿色的牧场,在那里,你知道,它是通过牛奶和蜂蜜流动的,或者是通过数据流动的,它真正的是能够做一些你以前无法做的事情,因为你拥有的数据是一种允许你这样做的格式。 因此,对我来说,这是我们必须确保的一部分,就是要认识到互操作性在具体方面是困难的,但在抽象方面是不可能的。你必须考虑你想要做什么,或者你想通过互操作性完成什么。 现在,这有几个好的结果,对吗?测量它变得容易得多。如果你有一些有形的东西,你以前无法做,现在由于系统可以互操作,你可以更容易地看到你是否正在取得进展。 问。除了双向交流之外,我们还真的达到了对我们真正想要和需要能够做的事情有合理认识的程度吗? A 。随着世界的进步,我们将开始做新的和不同的事情,我们没有预料到我们将在10年前做,对吗? 因此,如果互操作性是由您想要做的事情来定义的,并且随着时间的推移,您希望继续做越来越多的事情,在某种意义上,您忽略了互操作性似乎正在消失。因为您想要做的事情与数据标准和基础架构之间的差距似乎正在扩大。 但这并不是因为互操作性没有移动。我们想要做的事情正在发生变化,变得越来越复杂。所以我们对互操作性感到遗憾,但事实上我们已经取得了良好的进展。但是,当我们取得进展的时候,有一些新的事情我们想要做:现在我们已经能够交换这些信息,让我们尝试做一些更复杂的分析,或者让我们尝试确保语义上的集成。我们可以在这个空间里思考各种各样的事情。 问。在那里有很多挫折,也许是正确的,我们在这些年之后仍然在谈论这个问题。但是我们现在能做些什么,那就是当你还在 ONC 的时候,我们不能做什么?我们在过去几年中能取得什么成绩? A 。我想有更多的数据是流动的。这是非常具体的。你知道我们有合并的 CDA 之类的东西,并且交换了这种信息。我认为我们面临的挑战之一是,在 ONC ,我们努力确保使用标准来支持互操作性。因此,我们非常、非常难以确保有结构化、离散的数据元素,这些元素是从语义角度很好地制定的。 当你首先追求结构和标准化,然后分享第二个——最终发生的是你必须思考如何在你想做的事情之前构建或标准化。你说:“如果你造出来,他们就来了。”如果你把它标准化,人们就会使用它。有时我们把它弄对了,有时我们没有把它弄对。 例如,当我看一看 USCDI 的描述时,计划是随着标准的成熟,他们将添加到 USCDI 中,他们将期望共享越来越多的信息。我自己的感觉是,它有向上的等式——或者有向下的价值主张。 我觉得我们应该分享一切,然后随着时间的推移使之标准化。因此,最终发生的情况是,如果你有整个指定的医疗记录,对,有一些非常基本的标准,给你一点元数据。他们会说:“这份文件是关于夫人的.琼斯从史密斯医生在总医院;医疗记录号码,日期,这是一个病理报告。 因此,我们不应试图标准化疾病进展或疾病分类,或可能的恶性诊断的本体论,或构建在病理报告中可能捕捉到的所有元素的方式,我们应该得到病理报告,并只有一个最小的信息量,然后所有其他的借口。和可计算的。不一定标准化,但可以计算。 因为那时我认为随着时间的推移所发生的事情是所有的病理学家聚集在一起说,“你知道,我得到所有这些病理报告,它们都不同。如果我们在一起怎么办?因为如果我们都以类似的方式来做,这会让我的生活变得更轻松。” 最终的结果是,你首先共享,认识到价值,然后有一种基于价值的标准化过程,你可以根据人们认为标准化将是重要的,因为他们已经看到了数据,他们已经看到了其中的内容,他们可以找到方法来做它。因为你可能还有其他的东西说:“你知道什么?我要用谷歌分析。或者,我要去自然语言处理。或者,我将把它转换成 FHIR 资源,这对我来说就足够了。”我们不必做一大堆标准化工作。 谷歌做了一项非常好的大脑研究,他们收集了大量的数据集,他们使用了 NLP ,创建了 FHIR 资源,并在共享后将其作为提供某种结构的一种方式。现在,他们基本上说,在我们共享这些报告之前尝试标准化这些报告是不值得的。我们实际上可以使用其他技术来获得价值。因此,如果互操作性真的是关于交换和使用,他们想出了一种在没有这些标准的情况下使用它的方法。 问。然而,当我们展望未来时,我们谈论的是更复杂的问题:病人产生的健康数据、医疗设备等。考虑到仅仅“基本” EHR 数据所带来的持续挑战,我们能够利用其中的一些优势有多好? A 。如果我们试图在有机会分享之前将它标准化或结构化,它将永远不会被共享。它永远不会到达那里。因此,它甚至提供了更多的动力。对吗?正如我所说的:无处不在的互操作性的目标与我们现在所处的领域之间的差距扩大了——这在很大程度上是因为我们想用数据做更多的事情。这种差距也扩大了,因为那里也有更多种类的信息。 即使我们现在花了我们所有的时间、金钱和精力来标准化我们所拥有的东西,并尝试创建某种互操作性规范来帮助我们交换这些信息,明年将会有新的数据类型和新的信息。我们从来不会做这份工作。让我们不要等待,让我们不要让完美成为好的敌人。让我们不要让好的成为更好的敌人,但让我们努力确保信息共享,然后聪明的人将告诉我们应该优先考虑的事项,然后我们可以使用免费的文本和其他技术来获得我们想要的价值。 我认为,我们必须非常小心的一件事是,许多医疗保健人员正在考虑所有这些事情如何与医疗系统互动。 但现实情况是,医疗保健系统是其中的许多参与者之一。有消费者。有账单。你有很多不同的群体,越来越多与医疗相关的数据将会在医疗环境之外而不是在内部找到。 例如,健康的社会决定因素。一种反应是:让我们标准化,让我们创造一种社会决定因素的健康被捕获的医疗保健系统。 另一种方式是:我们将如何达到这样一个点:例如,我们可以与社会服务进行互操作性,从而我们实际上能够从社会服务中发送和接收关于患者的数据。 因此,这就成为一个更大的问题。我认为当问题变得越来越大时,你再也不能从传统的建筑观点来看待它了。你必须后退一步,说这更像万维网,而不是创建一个程序,或者在一个企业内创建集成。 当这种情况发生时,你必须有不同的方法来解决这些问题,万维网是建立在一套标准之上的——这是一堆标准,但它们非常简单。基本上有四个 API 运行万维网。 万维网对一个 get (点击链接)进行操作;在一个帖子上,当你从亚马逊订购东西并点击 OK 购买时;它有一个删除功能,通常只对一个 wiki 和一个更新功能设置。这四个 API 是真正管理万维网的。那么,我们在医疗保健中需要什么样的基本功能?因为如果我们能做到这一点并简化它,那么它将会变得更容易,更容易使我们能够在它成长的时候维持它。 我们已经开始推动在医疗保健领域开发 API ,并且可能有数百或数千种 API 。除非我们考虑我们需要做的最基本的功能类型,否则这不一定是可持续的。如果我们能将这些标准标准化,我就不需要为 Cerner 、 Epic 、 Allcripts 、 Apple 和其他任何东西学习1,000或2,000种不同的原料药(API)。 也许我们需要做的是简化方法。我认为 FHIR 将帮助我们,因为它为我们提供了一组更受约束的构建块。但你知道,我们需要做的基本功能是什么? 问。你认为剩下的最大挑战是什么?它们是否与技术和标准有关?或者他们更多的是与文化、人和过程相关的吗? A 。你去找技术人员,他们会说这都是一个人的问题。你和人们交谈,他们会说这是一个技术问题。每个人都喜欢把手指指向另一个群体。 实际上,我认为从技术角度来看,我们有一些我们需要的基本功能。但是当我们开始谈论意义和价值以及人类更多的特性时,无论是在技术方面还是在人方面,我认为这是我们努力的地方。因为意义是非常重要的。但是,它比只有一个语法,你将如何参与要复杂得多。 然后,正如您所说的业务流程和驱动信息共享与信息阻塞的因素,它真正成为一个人和文化问题。存在治理问题。这些是棘手的问题。制定安全和运输标准很容易,所有人都同意这些标准。这比真正理解商业驱动因素的细微差别要容易得多,因为商业驱动因素允许人们共享或标准化东西。或者以动态方式集成,这样不仅您知道数据的上下文,而且您知道它在工作流程中的位置。因为人们有不同的方式去做这件事,如果你给某人发送诊断代码,那就是入院诊断,而不是出院诊断,这对这些系统应该如何看待这些信息以及如果它没有捕捉到这一背景,就会发生坏事情。 问。很明显,这种东西上的橡胶会在私营部门出现。但政策制定者能做得更好或不同些什么呢? A 。有很多方法可以解决这些问题。我只给你一个例子,从可用性-它不是互操作性,但它是说明性的。解决这个问题的方法之一是使用标准化的标准来评估可用性。NIST 有这一点。航空业对可用性发生的方式有一定的要求。你只需要每个人都满足某个可用性的特性。我不是建议这样做是正确的。 这是一个非常沉重的监管机构,要求人们以某种方式做某些事情。我认为它倾向于抑制创新和新的用户界面,这可能会变得更好。而监管是一种非常、非常生硬的手段,试图影响改革。因为你对它的了解越多,越脆弱或越难管理它。世界的变化和规则需要很长时间才能完成这个过程。 另一种方法是找出一种方法,让市场提高可用性,让人们用脚投票,如果他们有一个好的系统,具有很高的可用性,他们应该能够使用这些系统。如果他们的可用性很低,那么我们应该,离开这些系统,进入并购买其他更好的系统。 我们在手机中看到了这一点,我们在其他类型的技术中看到了这一点,在这些技术中,可用性,因为人们可以移动他们的电话号码,他们可以移动他们的联系人,他们可以将所有的信息从一个电话传输到另一个电话,他们能够获得越来越多的创新和更好的产品。 问。如果我们能选一个的话,哪种方法更好? A 。我们在医疗保健方面没有真正的好市场。你知道,你花了十亿美元来实现一个系统。如果你想转移到另一个人身上,你就会花费6亿美元。你没有市场流动性来驱动你想看到的一些行为。 法规正试图解决这一问题。21世纪 Cures 中描述的电子健康信息( EHI )出口功能表示,我应该能够获取所有信息,包括账单、行政和临床信息,我应该能够以一种可以理解的格式从我的电子健康记录中导出这些信息,并且有人可以导入一个新系统。我认为这是解决一些市场失灵或流动性问题的努力。但对于供应商来说,这将是一件非常困难的事情。 挑战是你不能也不应该同时拥有它。在一个被锁定的市场中,你不可能有一个低监管环境。你必须想出一些方法来解锁数据,让市场推动创新和互操作性,或者你必须有大量的监管来迫使人们去做他们不想做或不需要做的事情。 我倾向于支持那些能够推动更好的创新并增强医生和病人能力的人,因为这都是关于从系统中获取数据的。如果你从系统中获取数据,即使供应商可能不喜欢。最后,我认为这将推动更好地与医生和患者接触,并可能导致更好的创新和互操作性,因为人们将不得不在一个更公平的竞争环境中竞争,因为如果你不喜欢一个特定的系统,转换到另一个系统的成本更低,这使得你更容易作出可能改善产品的决定。 问。最后一个问题。正如我们之前所做的关于 ONC 和 CMS 规则的发言一样, AMIA 的立场是什么,在公众评论期间你会告诉这些机构什么? A 。我们有一套政策原则来指导我们关注的事情。我们真的想确保数据被用来使病人成为第一顺序的参与者。我们喜欢让病人获得完整的医疗记录。 我不希望这些法规采用两层体系,因此,如果病人想要完整的医疗记录,就必须以一种比我想用 Argonaut 配置文件交换我的合并 CDA 更有用的格式接受。 我们真的希望有一个更统一的基础设施,让病人可以使用应用基础设施访问他们的整个医疗记录。还有一些标准和其他可能有用的东西。因为,我认为,这将为患者带来更多的价值,而不仅仅是为患者带来某种一次性的出口功能。 这将是真正的挑战,任何人做任何与该信息。因此,我们真的希望让病人成为他们护理的第一顺序参与者,并使他们成为应用程序世界的一部分,即使他们访问所有的信息,目前在他们的电子健康记录。 最终,如果你能得到数据,人们会做有趣和有用的事情与它。这可以帮助我们了解互操作性对话,因为您可以将这些数据作为您的下一项计划的优先顺序,基于对其中的内容的观察,它是多么接近成为基于共识的标准,然后将您的努力集中在低挂起的成果上。 我们已经检查了一些信息阻塞,有一套关于你能收取什么费用的信息,诸如此类的信息。因为 AMIA 不销售应用程序——我们是个人会员组织,而不是贸易组织——这些东西非常重要,我们希望确保它不会限制患者和提供者访问这些信息。但是我们可能在游戏中没有太多关于收费多少或收费的法律问题,只要它不妨碍患者和提供者获得他们的信息的能力。 信息封锁比较复杂。从某种意义上说,要想弄清楚到底发生了什么,就必须有很多聪明的律师。就像基于政策的违反一样,是一种违反还是1亿患者受到该政策的影响? 作为一个组织,我们已经建立了三个反应小组,每周开会,为未来五周。所以我们有大约30个小时的工作,大约30到40个成员。所以我们会有很多的眼睛和想法。我希望我们能够产生一些深思熟虑和建设性的东西,因为这将真正定义未来五到十年的健康信息交换和健康 IT 空间。 Twitter :@ MikeMiliardHITN 给作者发邮件:迈克。millard @ himssmedia.com 医疗保健 IT 新闻是医疗卫生信息与管理系统协会(HIMSS)媒体出版物。

以上中文文本为机器翻译,存在不同程度偏差和错误;偶尔因源网页结构局限,内容无法一次完整呈现。请理解并参考原站原文阅读。

阅读原文