On the Road to Interoperability with ONC’s Micky Tripathi

Automated:
Welcome to Cowen Insights, a space that brings leading thinkers together to share insights and ideas shaping the world around us. Join us as we converse with the top minds who are influencing our global sectors.
Charles Rhyee:
Hello, my name is Charles Rhyee, Cowen's healthcare technology analyst, and welcome to the Cowen FutureHealth podcast. Today's podcast is part of our monthly series that continues Cowen's efforts to bring together thought leaders, innovators and investors, to discuss how the convergence of healthcare technology and consumerism is changing the way we look at healthcare and the healthcare system. And joining me today to host is my colleague, Eric Assaraf from Cowen's Washington Research Group.
And in this episode, we'll be discussing interoperability in healthcare, which is the fancy way to say how data can be more easily shared among various stakeholders, which has been a unique problem in the U.S. healthcare system. We have though over the last decade seen efforts to resolve that problem first through the HITECH Act, and then through the 21st Century's Cures Act. As part of the Cures Act, most recently, we've seen the introduction of TEFCA, the Trusted Exchange Framework and Common Agreement, which sets out a number of guiding principles for the establishment of a nationwide health information network.
And to discuss this topic and more, we are delighted to be joined by Micky Tripathi, the National Coordinator for Health Information Technology at the U.S. Department of Health and Human Services, where he leads the formulation of the federal health IT strategy and coordinates federal health IT policies, standards, and programs and investments. Micky, thanks for being with us today.
Micky Tripathi:
Sure. Thanks, Charles and Eric. Good to be here.
Charles Rhyee:
So Eric, why don't you kick it off?
Eric Assaraf:
So the idea of data interoperability in healthcare has been something discussed for quite some time. So maybe to kick it off, can you remind our listeners the role ONC plays within HHS and what their responsibility is when it comes to interoperability?
Micky Tripathi:
Sure. So ONC, we're a staff division in the Department of Health and Human Services, which means we're a part of the secretary's office at large. And we report directly to the secretary. And we were founded in 2004 by an executive order signed by then President Bush. And then we were further instantiated in statute by the HITECH Act in 2009, 2010. And from the beginning, the mission has been to coordinate federal health IT activities to get strategic alignment of federal health IT activities across the different agencies across the federal government, as well as to coordinate the creation of interoperable health IT infrastructure in the market generally.
So there's a coordination aspect that's with the market itself as it relates to the U.S. government, interacting with the market and trying to push the market forward toward open industry standards and interoperability infrastructure, ultimately to improve the quality, safety, efficiency, affordability, and equity of care to individuals. So that at large is our mission. That doesn't tell you a whole lot about what we do. What we do is a variety of things. We work on standards, so we want to be able to try to get as much of the industry using open industry standards, meaning non-proprietary standards to allow systems to interact with each other.
And so we do a lot in the way of helping the standard development organizations, as well as help to identify standards that we strongly recommend or sometimes make into regulation to be used by health IT activities. We also do certification of electronic health record systems. And then finally, we do health information exchange interoperability activities, which is to connect up those systems and networks via APIs and other kinds of things. So a lot of work all related to ultimately better use of health IT to improve the individuals' lives.
Charles Rhyee:
That's really helpful. And so this past January, you announced the release of TEFCA. Starting with the Trusted Exchange Framework part, the agency outlined several core principles for the exchange. And at the core of the Trusted Exchange is this concept of the health information network. The way it's written, it indicates you expect a number of HINs or HINs operating across the country to form a nationwide network. Can you define for us what a HIN is, and what type of organizations do you envision applying to be QHINs, or qualified health information networks?
Micky Tripathi:
Right. Sure. So HINs are entities, organizations that facilitate the exchange of information among independent clinical entities and other healthcare stakeholder entities. And that's really when we think about platform economics and how we've seen platform technical and business models grow in almost every other part of the internet economy. In a way, a health information network is very much that. It's about the ability of an organization to be able to facilitate the exchange of information among a set of parties, under a common set of rules, common set of contractual arrangements, and a common set of expectations.
And usually that involves a common set of state standards as well to make those transactions easier. And the idea then of the Trusted Exchange Framework, where it points to health information networks is to have a set of organizations that can help to facilitate interoperability among all the thousands and thousands of thousands of electronic health record and other health IT systems that exist across the country. It's really hard to get every one of those individual health IT users, for example, or EHR systems to just connect with any other user without some network conventions that help to establish, what are the rules of the road for exchanging information, particularly in healthcare.
Unless you have a good understanding of who is this organization that's requesting information from me, how do I understand whether they are who they claim to be, whether they are authorized to have access to the information that I'm about to provide, and whether I have an expectation about what the use of that data is going to be, that it's very difficult to be able to have exchanges scale. That's one of the key functions that networks in general provide, not just in healthcare, but in any industry. The other thing that I think the networks really help with is just getting everyone to agree to a common standard so that you can essentially have one connection that allows you to connect to many, many other parties.
Basically, the multi-sided platform model, so that I don't have to build individual variations of technical approaches to connect to every other system, which creates exponential growth and complexity. The idea here is if I can connect once via one way and then be able to have a variety of use cases and connect to a variety of other organizations through that singular pipe, then I've created a whole bunch of scale and convenience for everyone.
Eric Assaraf:
Charles mentioned quality health information networks, or QHINs. How do they differ from the regional health information organizations created after the HITECH Act was passed?
Micky Tripathi:
So QHINs, actually not quality, it's qualified. So a QHIN is basically just a designation under TEFCA. So there are health information networks that live out in the wild, and as you pointed out that some of them came out of HITECH, where certainly ONC had almost a billion dollar program of funding different experiments, essentially in different states related to health information exchanges. Some of those died. A number of those continued and have sustainable models today and they just live out there in the wild. And then there are nationwide networks that live as well, Carequality of CommonWell, the eHealth Exchange. All of those are private sector networks that are health information networks performing those functions out in the market.
The idea of TEFCA is that under common governance framework, that there would be certain eligibility criteria that an organization would have to meet in order to be one of the networks that is one of the pillars of interoperability exchange under the TEFCA arrangement. So that means that there is a vetting process that happens to say, well, there are certain requirements that we want to be able to have those health information networks meet as regards the governance structures that they have, their financial stability, their ability and experience in transacting at high volume, very secure, healthcare compliant transactions. A number of criteria like that.
We want to make sure that if we're going to be a part of this core nationwide infrastructure, that they meet that bar. So that's what the idea of QHIN is. That the QHIN means that you've been qualified to participate or to be one of those anchors networks in the TEFCA model. And the eligibility would be determined by our nonprofit partner, the Sequoia Project, who we call the recognized coordinating entity, but they're basically the operating organization that is partnering with the Office of the National Coordinator to actually run and manage the TEFCA network.
Charles Rhyee:
What is the business model then for QHINs going to be like? And you mentioned before, there's some of these RHIOs that are still living out the wild, so they've obviously hit upon a business model. But you said earlier, you want to have a network where entities can just connect with each other on a same set of standards, like the internet. Is this something where AWS could become a QHIN or Verizon can come in and set up a QHIN? Maybe give us a sense for examples of what type of entities you envision becoming QHINs.
Micky Tripathi:
Sure, absolutely. So without getting into whether any particular organization or company would qualify, I would say just in general, for sure. That conceptually, those companies that you named, there is nothing conceptually that would prohibit them at a high level from becoming QHINs. Now, there are requirements, obviously. There's a governance requirement, and there's experience requirements on all of those. So again, I'm not saying that I know exactly whether they meet all those eligibility criteria. But there's certainly nothing preventing a private sector company, for example, that meets those criteria from becoming a QHIN and providing those services.
So stepping back then, just the first question you had, which is related to the business model. I think the business model is going to be one of those organizations that has met a certain eligibility criteria that the federal government supports and backs. And therefore, they're able to market themselves as organizations that their participants can trust, that has met a certain bar. And as organizations, and especially in healthcare, are very concerned as they should be with privacy, with security, with the rules of the world of data, they at least have the comfort of knowing that the organization that they are connecting with has met a certain bar and is required to meet that criteria.
And those are a set of criteria that are monitored and are part of a nationwide network that allows ... I always hate to say seamless, because seamless is really hard to accomplish, but that allows fluid information exchange with other networks and with other organizations across the country in what's going to be closest we're going to come to a true nationwide network. There's been a lot of thought over a number of years over what is going to be that nationwide network? And I think now that we're able to answer the question that, this is going to be the nationwide network. So that's one of the business models, I would argue.
The other is the ability to provide value-added services on top of that. And there's a number of organizations. There's the core function that you need to be able to provide to be a TEFCA QHIN, which is just being able to connect up those organizations according to that contractual model and according to technical requirements and broker those transactions across networks. So network to network, being able to broker those transactions and deliver those and receive those ... Send and receive those to the participants. That's a core function that you're required to do, and you're required to do it for a number of the named exchange purposes, like treatment, payment, operations, public health, individual access, what have you.
But on top of that, you could have QHINs that either already do or say, well, now that I've got those connections built and I have those participants who want me to be able to provide that, I could provide value-added services on top. I could aggregate that data with their permission, for example, and curate the data, do quality measurement, do analytics, do a wide variety of things that are on top of that, that isn't a QHIN requirement, but enables them to be able to deliver those value-added services, which would be a benefit to the participants and a benefit to the country overall.
And I think there are a variety of ways that there could be value services in that business model, but we'll see what happens. The other thing that I would just mention, again, related to another question is what kind of organizations do we expect? We certainly expect that the organizations that are networks today, operating at scale are certainly early likely candidates. So you've got CommonWell, the eHealth Exchange, a number of health information networks that operate in regions and in states could qualify. And there are other implementers in the Carequality framework that could conceivably come forward and decide to do that.
That's going to be up to them, but I'm just pointing to, those are the organizations that naturally already perform a number of these functions and already probably meet a number of the eligibility criteria, and therefore could probably find it to be a relatively easy step to be able to step up and be able to pull on those things. And one of the things that the 21st Century Cures Act specifically said is that the creation of TEFCA should be with minimal disruption to the market. So certainly that's one of the things that we wanted to do with TEFCA is to be able to say, well, where has the market been headed? How do we have a glide path so that those who already have been moving forward in this can continue on that trajectory and then participate in the TEFCA network?
But we also do anticipate new entrants, for sure. And what we've done with the eligibility requirements is we have left it open. We've said, well, there's certainly a certain set of requirements you need to meet from a governance perspective and a business integrity perspective and a technical capability perspective, but you don't have to be a network today performing all of those functions today. If you can demonstrate, for example, that you're an organization that actually could do this, and then you demonstrate the confidence and there's confidence that you could do this according to those criteria, then we absolutely want new entrants to be able to be QHINs as well.
Eric Assaraf:
Great. And the Trusted Exchange Framework is voluntary. What's the incentive for healthcare stakeholders to participate, given that it doesn't appear to be any enforcement mechanism built into that framework?
Micky Tripathi:
You got me. Because I really want them to, and they're going to break my heart if they don't do it. No. It's a great question. And the law specifically said that it's voluntary, so we are rolling it out as something that's obviously voluntary. There are a number of things, I think that could be real attractors, even though it is voluntary. One is I think just the participation in something that has the solidity and the trust that comes with the federal government being behind it, I think will be attractive to a number of organizations. And why would it be attractive to them? Because it's attractive to their participants.
I think, again, as you think about providers in the wild, who are solo practitioner in Nome, Alaska or in rural Mississippi or in Boston, Massachusetts, there's always the question of, I've got this electronic information. Increasingly, I'm getting more and more interoperability, more and more information coming and going. How do I have the assurance that everything's okay? How do I have the assurance that I'm not going to end up on the front page of the New York Times with some massive data spill that it was really hard for me to figure out exactly where all this information was going? And in a world where we're trying to push for more patient access, we're trying to push for more interoperability and more sharing of information, there's an inherent risk associated with that.
And so how do we balance those, those kinds of things. I think there's going to be a lot of participants, provider organizations and others who are going to see the trust that comes with the federal government's participation as being a real value. And that's why I think the networks who want to be able to offer that as a value proposition to their customers are going to see that as something that's valuable. The other things that, I think will also be valuable is that I think one of the key value propositions ... And again, this is a part of the benefit, I think, of the federal government participation is that we can help to break through some of the issues that the private sector has had difficulty of achieving on its own.
And that's not a criticism of the private sector. There's only certain things that the private sector, as we know, can get together. And this is competitors getting together and agreeing on a certain and set of things like, "All right, we'll lay down our arms for things like provider-to-provider exchange for treatment purposes. Great. We all agree on that. Let's do that." And that's how you see CommonWell and the eHealth Exchange and those networks form, and Carequality form, and as well as state and local HIEs. But once they get to other kinds of use cases that start to trade on competitive issues, and businesses that they already have and they start worrying about cannibalization of those businesses, then all of a sudden, you start to get less and less enthusiasm moving forward, and it's harder for them to move forward.
So issues related to payment and operations, for example, start to get a little trickier, and it's been harder for those networks to move forward. Public health has also been another area that's been hard for them to move forward on, because of the regulatory complexity. So that's not a competitive issue. It's just the regulatory complexity of 64 different public health jurisdictions across the country. It's really hard for the private sector to sort all of that out, and who has the motivation, and what's the ROI to them of really trying to invest in that when it's really a system problem. It's not a problem that any individual company or even a group of companies can solve on their own.
So I think the benefit of the federal government presence to be able to break those log jams and offer those as additional services offered by the networks at scale will also be an attractor. It'll basically be, "Well, gee, TEFCA does things that these private sector networks don't do. And that's why it's attractive to me." The last thing I would point to is that we are also working very hard with our federal agency partners to define and help define what might be use cases that would allow them to participate directly in TEFCA based exchange.
So for example, you can imagine that CMS, as well as the CDC. I talked about public health already, and CMS with payment operations kinds of activities. And this isn't about regulations, per se. There could be regulations, but that's way too early to talk about, but this is just about their market presence to be able to say, well, Medicare, Medicaid, they're big actors in the market. And if they decide that the TEFCA based exchange is a value to the government insurance program and therefore to all Americans, then that might be an attractor as well, because everyone wants to and has to interact with Medicare and Medicaid and those government programs.
So I think there's a variety of things that can make it attractive. And of course, hopefully, maybe down the road ... I shouldn't say hopefully. Maybe down the road there could be other incentives that are offered, but again, it's away too early to be talking about that.
Charles Rhyee:
So maybe if we could touch on a couple of the key principles in the Trusted Exchange Framework, with the first being standardization, you noted that QHINs should prioritize federally recognized and industry recognized standards, policy, best practices and procedures. Given the efforts to achieve greater standardization has been going on for some time, with groups like the Argonaut Project back in the mid 2010s, how much of the industry still isn't using federally or industry recognized technical standards?
Micky Tripathi:
No, it's a great question. So to your point, a really, really large portion of the industry is using federally recognized standards, for sure. And a part of that is it's both a bottom-up and a top-down. And what I mean by that is it's bottom up to the extent that ONC, for example, works very closely with the market and with standards development organizations to have the standards be matured and focused, but through a consensus process, which is defined by ISO and other international and U.S. based standards setting organizations.
So we very much work on the bottom up to say, what are the things that people want to do? What are things that are emerging standards? And then how can we accelerate those to be able to get those to a place where everyone will agree to them, and then they get approved by a standards development organization, and then we're able to pick them up and say, all right, there seems to be a good degree of industry consensus around these set of standards now. Now we can put those into regulation to be required to by EHR systems, for example, and be required for things like public health reporting and quality measurements, and things like that.
So it's very much an iterative process where we work with industry, but to your point, it's not static. And that's why we need to keep moving forward. So there are new standards that keep coming into play. FHIR is a great example of ... The Argonaut Project working on FHIR. That work isn't done. You start with the core construct of FHIR and there are certain things that are standardized, but there are lots of elements of FHIR that still need maturation. And once those are at a degree of maturity, then you include those in what you could either call a standard that may or may not have regulatory requirement or something that does have a regulatory requirement, depending on the use case and what it is.
So it really is a dynamic process and we just keep going, but we haven't had, I think for the most part .... And prior to joining the federal government a year ago, I was in the private sector in health IT for 20 years. So I see it from both sides, and I've come to the same conclusion, which is that because of the fragmentation of the really high fragmentation of the industry in healthcare and in health IT, I think that the industry appreciates and actually benefits from the federal governments coming in and saying, here is that version of that standard, which we're just going to say is the standard that everyone should use for this particular set of purpose as well. We have authority.
Because often you just get these small variations and the players don't care. They actually don't care. Is it version 4.1 or version 4.2? Well, I don't care, but I'm doing 4.1 and darn, everyone else did 4.2. And so if we could just say, you know what, do 4.1, then everyone appreciates that. It's like, okay, great. That's off the table. Let me just move forward.
Charles Rhyee:
You mentioned FHIR, and that's been kicking around for quite some time as well. Is there a difference between ... Because if we look at TEFCA and the Common Agreement, it doesn't require people to be on FHIR necessarily, but it's built to enable FHIR over time. Can you just follow up there and talk about ... Because it seems like everyone, I thought has been already migrating to FHIR. So it's interesting that this FHIR roadmap was also released to help people move along. Maybe you can just touch on that real quickly.
Micky Tripathi:
Sure. So there's a number of different puzzle pieces here that are at play and they compliment each other. First off, FHIR, well, it feels like it's been around for a long time. It really hasn't been around for that long when you think about the history here. I was part of the group that launched the Argonaut Project, and we did that in January of 2015, is when we launched the Argonaut Project. And when we launched the Argonaut Project, at that time if you ... I think the charter is still available on the website. Our charter said, we need to move healthcare interoperability to API based approaches. We need to have modern internet connections and modern internet standards using API based approaches for interoperability.
And one of the things that we said in that charter is we think that a pretty good candidate is this emerging standard called FHIR, but it's too early to tell. We're not committing to that right now. We're just going to do a bunch of work to see whether we can demonstrate that FHIR actually is ready for prime time. And we made a recommendation at the time that we said that if ONC decides that they are going to put an API requirement into regulation, our recommendation is that you not focus on FHIR yet because we don't believe it's ready for prime time. We still need to test it out. Now that wasn't that long ago. That was like seven years ago where we were saying, "No, we're not even sure about this FHIR thing. We think APIs are cool, but we're not sure about this FHIR thing."
So then you fast forward, Argonaut Project, worked on the implementation guide, did rapid cycle, demonstrated that it actually was ready for prime time. The Apple Health Record picked it up two years later, and then the industry started rapidly adopting it. ONC, working in parallel, made a functional API requirement. Said, "We think this FHIR thing might be a good thing, but we think it's not ready for prime time." And interestingly, all of the adoption that's happened with FHIR in the market today is without a requirement from the federal government to use FHIR. That requirement to use FHIR only comes into place this year, actually.
It's just this year where the ONC rule says that all certified EHR vendors who have certified APIs are required to implement a FHIR API, and that's by the end of 2022. So that's when you think about TEFCA and FHIR going hand in hand. What we did is we said, well, TEFCA isn't going to require FHIR. TEFCA is voluntary and it has no authority to require FHIR, but you've got the ONC regulations on certification of the EHRs that are saying, well, we can require FHIR, and that's what we're doing. So by the end of this year-
Charles Rhyee:
That makes sense.
Micky Tripathi:
... every certified EHR is required to have a particular version of FHIR available. And if you look at the FHIR roadmap, the timelines dovetail. Because what we said as well, on the FHIR roadmap, what we want to say is we should create network infrastructure to support these FHIR APIs, which we know are going to be coming into the market very rapidly over this year. And so that's why we said that that idea of facilitated FHIR exchange to support SMART on FHIR apps, we want that to happen this calendar year. To get pilots up and running this calendar year. Why? Because 2022 is the year of implementation of FHIR APIs by regulation. So that's how those two work hand in glove.
Automated:
I see that. That makes sense.
Eric Assaraf:
We also wanted to touch on privacy. One of the goals of the framework is for individuals to be able to access their personal health information. And as we know, when that data is shared among covered entities, it's protected by HIPAA, but once it's sent to an individual, it isn't. How do we ensure patient data remains safe and protected?
Micky Tripathi:
In that construct, the hard answer is that we can't ... And that's a real challenge. I think that's challenge for us as a society, in general, and with privacy in general is that we don't have a general privacy regulatory framework to protect individual's data once it's in their control. Again, that's just not an issue related to healthcare information, it's any information that we use the internet to conduct with and that we take possession of on our mobile devices or whatever it is.
So now that said, what we've done with TEFCA, for example, is that we have said that for provider organizations or ... Not provider organizations. I should say service providers or technology developers who want to provide what we call individual access services. So the ability for you, Eric, to be able to say, "You know what, I'd like to be able to request or query for my records over this TEFCA network so that I don't have to go to the ..." If you go to five different providers. So I don't have to go to every one of those five different providers and get username and password and go through all that stuff or connect to each of those portals, for example.
But I want to be able to just make a single query and be able to get that information. Well, you could sign up with a service, and there are vendors out there who do that, and we anticipate that they will connect into the network. One of the things that we've done with TEFCA is said, well, there isn't federal or state law that protects the information, to your point, once it gets into the hand of the individuals, but we're going to try to use the contractual requirement of TEFCA participation to raise the bar and help fill in some of that gap.
We can't fill in all of the gap because again, it would just be a contractual requirement. At some point you might raise the bar so high that no one wants to participate, and then what good has that done to anyone? And then you got people who are just living up there, doing whatever it is they want to do. So we tried to strike a balance. So one of the things that we did, for example, if you look at the Common Agreement, it says that if you are an entity that is not covered by HIPAA, you are still required to basically live by the rules of HIPAA.
So you're basically required to live by the HIPAA Privacy Rule and the HIPAA Security Rule. And in particular, then we actually went one level higher for those individual access service vendors as we said, you are required to demonstrate that you have gotten the consent of the patient to transact over this network. That's not a requirement for a HIPAA covered entity. The HIPAA covered entity, basically they're already covered by HIPAA. They don't have to get consent from a patient to do treatment pain and operations. What we said is, well, for those who aren't covered by HIPAA, we need to have some kind of trust that they have gotten the consent of the individual.
So anyway, so there's a number of things in there that tries to raise the bar through a contractual requirement for their participation. And again, we've tried to strike the balance of how do you have that be high enough that that'll be attractive to them that they'll say, "Oh, well, yes, that imposes more requirements on me than I have to do if I live outside of TEFCA and just do it out in the world. But if I do participate in TEFCA, maybe that makes my value proposition better to individuals, that I'm able to represent to them, 'Hey, I'm a part of this TEFCA network. I have met those requirements. So you should trust me more than that other vendor who's not a participant in TEFCA." And that's going to give you a greater assurance.
So you'll actually get other organizations to participate with me, because other organizations are always hesitant if they don't know ... Well, who is this vendor? They claim that they're representing Eric Assaraf, but how do I actually know that they are? And therefore, what we see in the markets today is provider organizations don't respond to those requests, because they're like, "I have no assurance that that vendor actually represents Eric." So anyway, that's what we've tried to do with TEFCA to be able to say, how do we fill in that gap a little bit through TEFCA participation in the hope that that's a part of a value proposition and not seen as a burden for all of those organizations.
Eric Assaraf:
And just to clarify, can digital health app type companies that consumers use be required to be covered entities?
Micky Tripathi:
We have no authority to wave a wand and say, you are a covered entity. The HIPAA law, that was 1996, defined what are the entities that are regulated by HIPAA? So first off, that would be an OCR decision, the Office of Civil Rights, not an ONC decision. And second, that's actually instantiated in law, who's regulated by HIPAA. So that would require a change in the statute, or rule making or whatever to do that. So it's not as if someone can wave the wand and say, "All of you are covered entities now," or it's not as if someone can volunteer and say, "I'd like to be a covered entity."
It's like, the law says you either are or you aren't. So that's why we put in the contract that you need to ... If you're going to participate in this network, you basically have to follow the HIPAA rules, even though you aren't actually a covered entity.
Charles Rhyee:
Great. So if we take everything that we've discussed so far, and you touched on it a little bit earlier. What do you see coming out of this? In particular, if we start to have this real network of QHINs and have this higher level of interoperability, you touched on some of the add-ons, value-added services. What are some of these new and innovative services do you see emerging as a result that creates opportunities for new company formation to come out of this?
Micky Tripathi:
Sure. So in general, I think any company that can take advantage of ... And I mean that in a good way. I don't mean that in a bad way. That can offer opportunities where they are able to aggregate information in an authorized way and be able to do good things with it, value enhancing things with that information, either through the aggregation of the information or being able to provide better access to the information or value-added services on top of that, and being able to have a network where they are able to easily get access to the information. Again, according to a set of rules that everyone agrees to, then I think that this is a valuable business proposition for them and an innovation platform for them.
So for example, when I ran an organization called the Massachusetts eHealth Collaborative in Massachusetts, we had a clinical quality data warehouse. And one of the things that we did is we joined the Massachusetts statewide HIE called the Mass HIway. And there was a fee that we had to pay to join that, but one of the reasons that we did that is that once we were connected, now we could basically go and sell our services to everyone else on the network. We could say, we don't have to build a separate interface to you. All you have to do is send the information to us over the network. No additional cost to you whatsoever to get the data to you.
So of course, we charge prices for value-added services on top, but it's basically being able to say, I am now a store in the shopping mall. I don't have to worry about parking. I don't have to worry about all the other stuff. I don't have to worry about people coming into the shopping mall. What I need to do is get the people who are in the shopping mall to come to my store. That's now my problem. And that takes away a whole bunch of that infrastructure stuff and a whole bunch of the friction of just being able to directly appeal to customers.
Takes the cost of the transaction down to the minimum commodity level, and allows me to focus on what value-added services I can provide on top and demonstrate that's over and above what really should just be commoditized, which is just the appropriate access to the data. And we shouldn't be competing on that. That really ought to be commoditized. So that's the idea here is how do you commoditize all of that so that people can really offer those value-added services on top?
Eric Assaraf:
And last question for me, now that TEFCA has been published, what are the next priorities for ONC in the coming year? I know that administration broadly has made equity our priority. What else is on your radar?
Micky Tripathi:
Well, I'll just go in order a little bit. Certainly, pushing forward with TEFCA is a key priority. Helping the industry adopt the information blocking rule and all of the associated requirements related to that is a big priority, because that's complex, but I think is a real turning point for the industry in terms of the obligation to share information with other parties. And that takes a lot of work. And so we're doing everything we can to help educate the industry about what those requirements are and how they can work their way through those to get to the place that we want to be, where people feel the obligation to share information with other parties and not try to hoard information for competitive purposes.
And health equity is certainly a big area, and that's related to data itself. So we're doing a lot of work in standardizing data, which we always do, but with a particular focus on social determinants of health and health equity related data, like social determinants of health data related to life circumstances, housing assistance, food assistance, food security, issues like that. And we did publish in July the beginning of a set of guidelines that will hopefully turn into requirements for the capture of structured social determinants of health data in EHR systems, as well as SOGI data, sexual orientation, gender identity.
And then we're working on, how do we get greater consistency in the capture of race, ethnicity, language data so that you're able to put all of that together and be able to identify where there might be health inequities that are turning into healthcare disparities in the delivery of care and in outcomes. And also, how can you develop interventions that help you try to head off issues before they become healthcare outcome type of issues. So being able to integrate better with social service agencies, for example, is another area that we're looking at.
The other area that's a little bit more nascent, but we're starting to take a very serious, good, hard look at it in the area of health equity is algorithms and algorithmic bias. Right now there are many federal government agencies who do a ton in algorithms and in AI and machine learning, like NIH and FDA and a number of agencies do. But from an ONC perspective, we are the only federal agency that has the direct connection from both the relationship perspective, as well as a regulatory perspective with electronic health record vendors and with the providers who use them.
And as we know, as we think more and more about algorithms that are being used in healthcare, what's the source of that information? Well, it's the electronic health record systems. That's where that information is coming from, and those are systems that are regulated by ONC. And the data that's in them, much of it is regulated by ONC as well. So in a way there's almost no way that we can't start to get involved in that discussion about, well, what are these AI tools? How should we be thinking about the appropriate use of those? How should we be thinking about being able to be more transparent about biases that may exist? Because every algorithm has bias. That's just a statistical phenomenon.
But how would a user of an AI system understand what was the data that this algorithm was trained on? What inherent biases might there have been in the training data that a user should be aware of? And then how are those used, and how can that just be disclosed to those users? Because the EHRs are not only the source of the data, but they're also the vehicle to deliver those algorithms in use, where a clinician, actually has functionality that has a whole bunch of algorithmic horsepower behind it. How do we think about that in a way as well?
And we want to be very careful. We certainly don't want to stifle innovation, but we want to think about, is there a greater transparency that we can give to the industry, just so that everyone has awareness of the appropriate use of those algorithms? So that's an area that we're starting to get into as well as we move forward.
Charles Rhyee:
Great. Hey, Micky, I think we're at the time here, and just wanted to thank you so much for your thoughts and your insight here, and helping us understand better where the agency is looking to move forward with. And looks like you got your plate full here in the coming years. So just wanted to thank you so much for being on our podcast today, and hopefully have you back as a guest sometime in the future.
Micky Tripathi:
Well, thanks Charles and Eric. And hopefully I did help you and your audience understand it better. And I'm delighted to come back and keep the conversation going. And thanks so much for your invitation.
Charles Rhyee:
Thank you. And thanks everyone for listening, and hope you join us for another podcast in the future.
Automated:
Thanks for joining us. Stay tuned for the next episode of Cowen Insights.

This podcast should not be copied, distributed, published or reproduced, in whole or in part. The information contained in this recording was obtained from publicly available sources, has not been independently verified by TD Securities, may not be current, and TD Securities has no obligation to provide any updates or changes. All price references and market forecasts are as of the date of recording. The views and opinions expressed in this podcast are not necessarily those of TD Securities and may differ from the views and opinions of other departments or divisions of TD Securities and its affiliates. TD Securities is not providing any financial, economic, legal, accounting, or tax advice or recommendations in this podcast. The information contained in this podcast does not constitute investment advice or an offer to buy or sell securities or any other product and should not be relied upon to evaluate any potential transaction. Neither TD Securities nor any of its affiliates makes any representation or warranty, express or implied, as to the accuracy or completeness of the statements or any information contained in this podcast and any liability therefore (including in respect of direct, indirect or consequential loss or damage) is expressly disclaimed.