All right, wanted to welcome everyone for joining us today for the webinar discussing interoperability in healthcare. We have some insightful topics that we'll plan to cover today specific to how health plans and providers can meet the CMS mandates with the upcoming July 1st, 2021 deadline. Today's speakers are Ricky Sahu, who is the CEO of one of Health and for some background purposes, prior to starting one up, Ricky worked at Google. And was also the first employee and director of Engineering for Care Journey with any Chopra, who is a former CTO at the White House. Ricky has also been a leading proponent of FHIR since it's the very beginning and has led the balloting for Fhirbook Data Standard as well as the development of the reference implementation with Boston Children's Hospital. Alison, who is the Director of Healthcare and is a Product owner at Tata Consultancy Services. Alison's healthcare career began with the Blue Cross Blue Shield plans and then she moved into the consulting space. Alison also served as a board member of groups like Healthcare Executive Group as well as WEDI and CAQH, helping lead writing of a lot of the published white papers. And we also have Visky who is the Chief Architect and principal consultant at Tata Consultancy Services as well. And in his role, he specifically conceptualizes new strategic solutions as well as platforms for healthcare clients including payers, providers, pharmacy, pharmacy Benefit management companies and so forth. And he has over 30 years of industry experience and the healthcare technology space. And then lastly myself, I'm Khristina, I work at One Up Health and I'm the Head of Product for our patient facing applications. And I come from an engineering background focused on the biopharma industry. And today I'll be helping to moderate as well as ask a lot of the questions that you might have. So definitely feel free to ask any questions in the YouTube chat that you see on the side. And with that, I'll pass it off to our speakers. Thank you, Christina. I work. Thanks, Christina, and welcome everyone. We're so excited for you to be here today with us at our webinar with TCS, Tata Consultancy Services and one upheld. So the purpose of today's webinar is, as Khristina mentioned, really to talk about what is happening with the regulations that came out from CMS along with the Cures Act because they do go hand in hand. So we'll be explaining a little bit of that. And then we're going to be talking a little bit more around what are the true implementation implications of this final rule and regulation. And then finally, we'll be opening it up for question and answer. So as Khristina said, please feel free to utilize the chats and we welcome all your questions and hopefully we'll get a chance to get to them all today. So and one other note, this also is being recorded and will be available for anyone who would like to review it. After the session is over. So with that, what I would like to start is just going over a little bit about who one up is and who TCS is. So Ricky, if you'd like to start and just give everyone a little overview as to who One up is, that would be great. Yeah, for sure. Thanks, Alison. So hello everyone. I'm Ricky Sahu, CEO of One Up. And we have been in the FHIR space for quite some time now. We've been building products to help health plans, health systems and application developers. Connect to one another and build on top of FHIR APIs. And as these new regulations from CMS and OMC are coming about, we are making sure that those organizations can take full advantage of a scalable FHIR platform that's deployed to support these regs. Since our inception, we've now connected to about 10,000 health systems across the US, which cover about. 85 to 90% of the US population, which means that you know almost anyone in the US now can authorize access to their healthcare data with any app. We have about 650 companies using our APIs to build various applications. And are doing thousands of transactions a second and we won a number of government awards in the space which we'll talk about a little later. But what's really interesting is that since these. Regulations came out for the providers in about 2015. A lot of momentum has been carried into the pairs which are now required to implement similar rules for patient access, and we're really getting to see all kinds of different players in this, from the health plans to the. Know pharmacy benefit managers to the applications that are interacting with members and. Think that a really thriving community is going to be developed, an economy is going to be developed around these requirements and patient data access. And do you want to share more about Tata alison? Sure. Thanks, Ricky. So just to let everyone know a little bit about who Tata Consultancy Services is. We are part of the Tata Group and we are a global IT services company. We have around 900 clients throughout the world. Close to 46 different countries and we are Focus on many different verticals in Healthcare is the vertical that we are currently talking about today. In our healthcare vertical, we represent everyone across the value chain within healthcare. And we have some great presence in a lot of the US payers providers as well as medical distributors and life sciences. So with that, one of the things that TCS is looking for always is how can we help transform, How can we bring innovation to our customers? And we recognize that there are a lot of companies like One Up that can bring value and to help us bring that innovation that we're looking for to our customers. So with that, TCS has what we call our Co innovation network or Coin network and it's companies like One Up that partner with us to bring these really great solutions to the marketplace. So as part of our partnership, we're really pleased to be working with Ricky and his company One up on trying to solve this whole problem around interoperability and how can we together really help everyone in the industry quickly and easily adapt to these interoperability principles. And I know Ricky, you had also there are some awards, I know from a TCS perspective we have you know numerous awards to our name, we've been recognized. Across the board by a lot of different analyst groups and in fact for those of you who are paying attention to the news, TCS has just surpassed Accenture and market Cap as well. So we're we're, we're we're doing really well and we're excited to have one up as one of our coin partners. And Ricky, I don't know if you'd just like to talk a few minutes about your some of the accolades and awards that you've received from one up as well. Definitely. And so we've been very focused in the FHIR and healthcare interoperability space. So I've won a number of awards from the federal government, from ONC to HHS and CMS. We've won awards around health data provenance, the bulk data LEAP grant and collaboration Boston Children's and bulk data is a specific requirement of the CMS regs also awards for consumer health data aggregation. Privacy and security for FHIR servers. We also recently got a cool vendor award from Gardner where they called us where they said what upheld Fhir platform is the first true implementation of ON TCS intent for healthcare interoperability which we're we're very proud of. So yeah and like Alison was saying you know we decided to team up in this case because we both believe.you know Our companies have excellent offerings here and. Think that the addition of it is really much better than what you may have alone. So definitely excited to work with Tata on this and I think that there will be some really interesting solutions pushed out from the collaboration. OK, great. Thanks, Ricky. So before we get into some of the more I think technical aspects, if you will, of what's happening with interoperability, I just like to take a few minutes just to kind of level set what some of the impetus was behind CMS pushing out these interoperability regulations. And I think first and foremost is probably the current problem statement and pain points that everyone has today around sharing data. And I think that this is a great representation of what happens to a patient and keeping the patient in mind of when, for example, they have to go to the hospital, they need to follow up with their doctors, they might need to have an extended stay at. A rehab center? And being able to share all that data between the different entities and stakeholders in today's world is not as easy as you think. And I feel many people can probably relate to this, whether they're actively involved in healthcare or not. Because more than likely yourself or a loved one has been in a situation where you're trying to coordinate and work between the various providers, hospitals, pharmacies to get all the right information at the right time. And because of this disparate system that we have today. I really believe that it's the main pain point we're feeling is the fact that we're not getting the right care at the time at the right place of service and things fall through the cracks because we don't have the data which should be available available. So with that. ONC along with CMS. Have worked together to come up with a combination of really two different rules. One is the 21st Century Cures Act and this was released in March of 2020. And this is going to be covering more of the more of the technical aspects of what's happening and really pushing out as Ricky had talked about those FHIR APIs along with the certification for those FHIR APIs, CMS is looking at this. They're limiting mostly to their stakeholders, which would include the Medicare Medicaid community. Along with the federal health exchanges and anyone involved in that and making sure that patients have access to their data. And what they're requiring really of the health plans at this point is to ensure that the health plans are not only giving their members that their claims information, but also their encounter information, their lab information, their pharmacy information. And they're requiring that this be all done through the FHIR APIs that were regulated through. ONC and eventually to be certified on that. So as I said, these are the plans that these are the stakeholders within the community that are going to be regulated. So we have all your Medicare Advantage members. You have your Medicare fee for service. You have your managed Medicaid plans along with your fee for service, your Medicaid fee for service and CHIP plans along with your qualified health plans through the federal exchanges. And where CMS is going with this is they are really looking at putting the patient at the center and allowing the patient to own their information. Now with that being said, I know there's a lot of questions around HIPAA and privacy and security and that has all been taken into account by CMS as well. And we'll talk a little bit later about the privacy and security aspects, but there and so there that is has been taken into consideration under the HIPAA rules. And then also through consent management being allowed to share this information. But as long as the consent is there from the patient to share this information, we should be able to very easily allow a person to totally control who is seeing their information, when they're seeing it. And to allow for ease of access to that information. Which ultimately is the goal of CMS to be to allow people to have that exchange of information easily and securely. And Alison, thanks for providing that background. I think it's super helpful for our audiences to better understand what are the ONC and CMS final rules and kind of what is the background as to why they were created as well as the future vision. Maybe Ricky, can you discuss next on kind of what are the approaches to implementing interoperability and data exchange? Definitely So the one of the biggest requirements around the rule are to implement a 3-legged OAuth2 flow, which basically means that members must be able to authorize a  third party app to connect to a health plans. So those are the three players, the three legged. Specifically means that there needs to be a client secret, client ID, redirect URL and auth code and an access code. That needs to be in the mix here. So that's all very technical stuff. But what how that really manifests itself is that the third party apps may be requesting a member to share medical or claims data from another health system or a health plan. And that might do that if they're trying to help a member shop around for the best type of healthcare for that individual based on their past medical conditions. Or maybe it's an application that's helping them find? The places the nearest pharmacies for the meds that they're on, or it might be an app that allows them to share this data with other providers or maybe family members. It could be really any sort of application. But the kind of core piece of that is that app needs access to that data. And when that app wants to request that access, they may have a button on the application that says, hey, connect to my plan data and when they do that. They would be sent to this. Khristina, can you get back or sorry, Alison, can you go back? Yeah. So when they click that button, they'll be directed to a member consent page, which is going to be served up by the health plan. The user will enter their credentials and click authorize access, and when they authorize access, that health plan will redirect them back to the app with an auth code. And then on the next page, we can see that the third party app would exchange that auth code for a open ID and access token and then make a request via FHIR APIs using the access token that they get back and ultimately get fire data back. And then they will be able to use that fhir data in their application to do you know, whatever those things that they wanted to do to help improve the patient's life or make their decisions easier. And essentially what's happening behind the scenes is that this is this has a few different components of it hooked up. One is obviously the healthcare application which is interacting with the developer portal. Then there is a OAuth2 server that developer portal creates credentials in and then there is a fhir API that accepts credentials from that of two server. So those are all kind of working in concert. To enable this sort of functionality in a seamless manner, and we have a ton of experience here where literally hundreds of apps are interacting with our APIs to do this connection flow for thousands of health systems and now that same functionality is coming to pairs. And Visky, a question for you just based on your experience and all the years that you spent in healthcare, how do you envision interoperability keeping organizations relevant in the market space based on some of the points that Ricky and Alison touched on? Hey. See one of the key thing is the interoperability, the fire standard essentially at the outset it looks like very technical piece of standard for integration and it it's a primarily a piece of technology. But then there are deeper connect context and connotations. There are very clear business drivers, outcomes that are indicated by that rule. One of the key things is objectives. That is, in the patient's ease of access to the data, patients can see their health care data. At ease in their mobile, at the point of whatever information they had encounters with theirs medication, everything they can see, they can get to see what their entire health has been and then what This in turn what it means is, as Alison said, today's in the disconnected word. The data is not seamlessly flowing, but in this world, with this fire data, the integration. It increases the data fluidity and then data liquidity. And the patient can see the data and then he can he can report what is the if he's missed the medication, if there is a missed appointment, is there a network doctors they have seen All of those things that have been taken into account can be corrected. Basically what it means is the organisations can focus on reducing the gaps in care, which directly relates to improving the outcomes. And on a larger context, this also means while improving the access improves the data, the means to it is you're reducing the complexity. So basically the organization's exchange data seamlessly, so the workflows are improved there are less efficient. Maybe what you say, friction, more workflow efficiencies and then the patient has a unified experience and moment. You have a standard. The there are more and more tools. You can have more tools for interoperability, more tools for care communities. You can create care communities. And all of those things. When the organizations do with security and privacy what it means in layman's terms, it is patient has a consent. The consent is not only at a broad level, what is opting in, what is opting out, whether something needs to be excluded. So when you enable this patient access with security and consent, it automatically leads to improved outcomes, better patient engagement and overall. This increases the value. And what would you say would be the benefits of implementing a lot of these fhir standards? OK, there are several benefits. To improving the by implementing the fhir standards. One is 1 more. Data fluidity and then exchange so patients can have access to the data. Organisations can exchange data more easily in a very standard, seamless way. But then if you can see the point to the next slide. We can achieve by several means. The overall objective is improved patient access and then better outcomes. There here is a way how you can achieve. One of the ways is here is a componentized architecture that is to these things. One to achieve interoperability using fhir and then to deliver analytics. This is a value added services and offer it as a platform as a service. So what, We show here is you have a lots and lots of data. You have lots of data from the care points of care. You have radiology, electronic health records and then the medications in the pharmacies, the laboratories and then the healthcare insurers have a lot of data. They have the claims data and then the various encounter data and then. And then the different pieces of information from the provider and then the government that is going to go and set up for information. And then as we see the future is also changing. So we will slightly come to that a little bit later. But then do you have various source of data in the today's world we can all integrate with this platform in this architecture? Various types of data with different velocities. They are ingested and stored and then the piece of analytics, it's a component which we can do at different levels. We can describe various these things. What is the longitudinal view of the patient? What has been his healthcare? And this point of view, his or her or her child. And then you can also predict the different healthcare. Cohorts analytics and then it can evolve into your prescriptive analytics. But what it means is you publish everything all these data sets in a longitudinal view and then insights and then they can publish using fhir standard which can be consumed by the patient using their applications or consumed by the health plans or consumed by providers for actionable insights. And then it can be consumed in any form. There are this is the architecture is also a future proof way because it takes into account the where the world is going. There are more and more devices that will be coming and the more and more social information, the social determinants of health today fhir is evolving so eventually we'll address. So this is a future proof architecture that. Ingests all types of data, allows the exchange of data and also provides value added dimensions of analytics to it. The box is shown in blue or one up this thing I would like, Ricky, would you like to talk about this? Yeah, definitely. So yeah, as Visky said, there is definitely a very broad. Set of data for healthcare interoperability that should be considered and. Where the team at Tata brings that very broad scope and where we're focused at on one up is specifically claims encountered and other data that is required for fhir or for integrations for the CMS and OMC data access rules. And. Was that ultimately manifest itself as is clinical and claims level integrations from health plans and health systems that can then support other workflows like fire subscription, sequel interfaces or other analytic tools to really query and interrogate healthcare data at scale. And the way that we are deploying and building our fhir server is that. It's unlike any other organization where everything that we're doing is serverless, cloud based, auto updating and It can scale literally to know thousands of requests a second which were normally transacting with. And that's also important because as a plan or a health system, you don't want to have to deal with performance bottlenecks. Everyone wants data immediately and in real time, and that's what we built our infrastructure for and then we're also helping the group manage. Developer and member consent. So there is a developer portal that allows developers to sign up. They can view. Their access and API logs there as well as health plans can do the same on their side. Members can consent and also some plans are using our member portal which allows them to. Disconnect or view the apps that they have already authorized access to, and then. Even after the data is transformed and put into an environment that you can analyze it and make available to other others via APIs, you also need to think about how you're going to maintain and manage support on an ongoing basis, and we're doing that today specifically for fhir related and member related access questions. So we have a team of. Support Technical Support people that. Take these incoming cases. Respond to them, Understand fhir. Understand the common issues that members see and have documentation for all that. So those are things that, you know, we're not really expecting plans or providers to become experts at and stuff that we could roll out for them really immediately. And Ricky, can you also touch a little bit more about kind of book fhir, essentially what it is and what it can be used for as well? Yeah, so the CMS regs require bulk data access via Fir Fhire bulk data standard. And how fhir bulk data differs from standard fhir is that it is essentially allowing you to extract entire population or you know records for all different resources. In bulk, rather than maybe a dozen or 10 resources at a time. It doesn't really allow you to query it with the same fidelity that standard Fhir does, but it allows you to extract it and load it into some other system. But the standard or the format is slightly different as well. Whereas standard Fhir is a Json payload, Bulk data is a flat file with lines of Json in it for each individual resource. And what you can do with that is you can take it all out of 1 system. Say you have a health plan that has a large set of members that are now under different health plan. You may be required to transmit that data set using the bulk data specification into this other organization and. That would then require the receiving health plan to take that data and process it and load it into their own environment. So bulk data allows for that transfer of data. But what it doesn't do, which we do and we work with Boston Children's on, is the ability to analyze that data in a POP health sort of infrastructure environment. And what we did there was we took the bulk data format and we loaded it into a columnar data store, which then allows you to run pop health analytics using standard sequel interfaces. So you get a essentially an ODBC and JDBC driver that you can plug into any sort of API tool like Tableau or Looker or Power BI or anything off the shelf that you can then use to interact with this data again without having to do any custom work on yours. And I think that's where both bulk data becomes really interesting is when you can run analytics on both your internal data sets but also external data sets that may have been provided to you or maybe you have a consistent feed. From the bulk data format. Awesome. And then are there any real world examples that either you, Ricky, Alison or Visky can share about just implementations overall using Fire? Yes. So maybe I'll share this piece 1st and then Alison can jump in. But yeah, so we basically developed the Karen Health Care and Alliance Healthcare App Gallery, which has a number of healthcare apps that are all building against fire. Most of them are taking the care and pledge for their code of conduct. And we also have an app gallery that is. Apps that are building against one up health. And what's cool here is that there really isn't a place that patients can go to see what you know, what are applications that work with fhir. And now you know the care and healthcare app Gallery is doing that. Then we were also mentioned in NPR, where Mass Mutual is using One Up Health to help individuals get life insurance, even though we can't be close to one another during. These days of COVID, which a whole different story and. Boston Children's is, we work with them to enable analytics on the Fhirbook data format so that they can connect to both internal and external data sources and query claims data for their ACO patients. So that's also, you know, very interesting and what's important here is that healthcare data sharing via patients is happening. It's not that these rules were just released and no one did anything about it. Not only did all the health systems mobilize and make their data available if you're a fhir, but we also had numerous organizations build applications against these standards and now patients are interacting with that. And we'll see that happen even further as developers build against the CMS regulated health plans to do a work with their claims data as well. And Alison, maybe you and Visky had other thoughts on what's happening in the fire space. See, one of the things is what we have a Health 360 app which is a patient. And see health data which was outlined in the earlier slide, what is my visits and then what are my prescriptions and overall including your activities and other things. So one thing is from a patient engagement, how we can. Using fhir integration all the health data. So that is 1 use case and then we are working with few large players. I cannot disclose the names because of the other confidentiality where we are integrating the fire data for data exchanges, how payers exchange with other those things. Other stakeholders in healthcare. That's right Visky and from an interoperability standpoint and I think one of the advantages of coming from TCS and cross industry experience that we have. For many of those who have worked like myself for over 25 years in the healthcare industry, the healthcare industry tends to be a little bit further behind than other industries when it comes to technology. And one of the things that TCS has seen in other industries is the move, like for example in banking, with interoperability. And having worked on a lot of those projects for many years now, we bring the breadth and depth of experience from those other industries, some of the pain points and problems that they had as they moved to an interoperability solution into our solutions. So that's one of the things that TCS can do is to really help streamline and bring those best practices to bear when. Implementing interoperability. And that's unfortunately you we are bound by confidentiality, so we can't really name names but that that's one of the things that we do bring to our clients is that breadth and depth of experience. The other thing to Ricky's point around population health, I think that personally this is really exciting times to be in healthcare with a lot of what's happening with interoperability because you know I know myself you know thinking back and how do even. At a health plan, the question was how do we get out of? Looking at something retrospectively in order to figure out what's going to happen in the future and now with interoperability, the sharing of both clinical and claims data, bringing in pharmacy data, bringing in lab data now even genomics data, which we can all very easily do, bring it all together. So you have that 360 degree view of the patient to run not only you know retrospectively what happened to the patient, but also to build out those predictive models to help identify someone who. For example, may be pre diabetic. And understanding what is the risk of that person moving from a pre diabetic state into diabetes and helping through education programs or monitoring a little bit more closely ensuring that they don't cross that threshold. So it is. I personally, I'm very excited. I think that this is a great time to be in healthcare and I think there's a lot of exciting things happening, especially around interoperability. Certainly from a technical perspective, but also from a business perspective too, and helping to guide health plans and providers ensure that the patient is getting the care that they need, when they need it, and not at an exorbitant cost. Awesome. That's super helpful. And I think just kind of hearing a little bit more about patient and getting access to patient data and sharing patient data, I think one of the first things that always comes to mind is Hipaa. So Ricky, maybe you could touch upon kind of how does patient data sharing and HIPAA kind of coincide and what does that really mean with fire inoperability? Oh, Ricky, I think you're on mute. Thanks. Yes, that's definitely an interesting topic because I think HIPAA is protecting. Patient Protected Health information that is transmitting between 2 entities. Usually business entities, but any two entities we could be a provider in a business or other organizations. Without necessarily the patient's explicit consent during that process, and the patient you know may when you're signing up. With the health system or other organization, you're already kind of giving consent for all those business associates behind the scenes to receive and transmit and interact with your data. To support payment, treatment and operations. Where Healthcare apps differ is and the patient mediated consent differs is that the patient is in the loop when they're authorizing a third party app. So for example in this mass mutual case here. The patient would be sent to a screen where Mass Mutual asks them for consent to receive their health data in exchange to be able to get enough information to provide them a life insurance policy. And it's not like the health system is just sending this data behind the scenes to Mass Mutual without the patient in the loop. So when the patient is in the loop, it's almost the same as telling your friend or telling someone else. About your medical health condition and that friend or that other person if you're if they're not like a doctor that is doing this for payment, treatment or operations. Technically, they could tell whoever they want and there is no kind of legal recourse there. They're allowed to you open it up essentially to them on your own accord. So that's the same idea here where? When a patient can sense a third party app, they're opening up this data to that third party app. And now that app is essentially bound by their terms of service with that patient or member or and their privacy policy. So what's really important here for individuals is that they trust those applications and they, you know, understand those terms of service and privacy policies by which the app is governing access to their data. And in many cases, you know apps will not share data with anyone else. But in other cases maybe that is their whole business model. And what we're doing with these healthcare app galleries is to make it easier for members and patients to understand what those apps are doing and how they're interacting with this data as well as reviewing those apps to make sure they are doing what they say that they are doing. So yeah, it's very different. And ultimately those third party apps that are getting consent to view and interact with your data are not bound by HIPAA. So it's entering a whole different world when a patient consents. Yeah, that's super helpful. And it sounds like kind of where the direction of Fhir interoperability is going. It's kind of very similar to how currently consumers interact with banking apps. And say, for example, I use apps like Venmo all the time, I also link my billing information to my bank account. And I think the idea behind that is that as a consumer, you would make that decision whether or not you'd like to share your banking information. And it sounds like the idea is very similar to medical records as well. Yep. Yeah, exactly. Awesome. So Alison and visky, just based on your, you know, breadth of experience across many, many different verticals, I guess how would you describe what does inoperability means for patients? No, the interoperability. Means different things to different this thing as a patient like you get more access to the data for organizations, they can unlock the real power of data. Today there is so much data even in current context. Forget the next stage where it's going to explode with Iots and devices. Payers have a lot of data. They have years worth of claims and then lot of encounters and then different. Clinical data in terms of the CAD management, medical management and. A lot of analytics, pharmacy and then the providers have a lot of data from different care organizations from their. Affiliated healthcare organizations, hospitals, critical care, hospital rehabs. So you can unlock this power of the data, even the existing data sets, using whatever we will show if this is a huge volume of data, if we can put together in one place, analyse and then exchange seamlessly. So that is means a lot and then we can also build a future state using fire standard using and then with the right new process right with the complete consent of the patient, applicable consent to exchange information put to better use. So that puts organization a great place to unlock the power of data, do a lot of value added things with the data, exchange it and keep the patient at the heart of the whole thing. I agree, Visky and Christina, to your point around banking and even retail apps, as consumers today, we are very used to having our banking information, our retail information available right at the touch of our fingers. We don't have that with healthcare today. We're going back to that first diagram and showing the disparity of where the data sits your pharmacy data is sitting with. Your pharmacist, your. Your general doctor has all of your Wellness information. If you see a cardiologist, they have all that information. If you've been to a hospital, they have that information. And so how as a consumer of healthcare do I get everything together And today I think that's that that's very difficult unless you have the a little, you're a little tech save yourself and able to bring that information together. With interoperability. That should all go away. You should be able to have one app that has all of your health information together so you can manage not only who you're seeing and when you're seeing, for example, the ease of making a doctor's appointment, but also understanding the cost of who to go see. And I think that that's a big part of. And even with COVID, we've seen it where people are saying that they go to the hospital and they have no idea what that hospital visit is going to cost them. And I think that as we encourage interoperability, as we encourage the sharing of data. We'll also see to the consumers benefit the transparency of healthcare cost as well and we'll be able to manage and contain the cost of healthcare through interoperability. Awesome. And this kind of segue was really perfectly into one of the audience questions in terms of what is in our interoperability trying to achieve in healthcare. And I think this may be specifically helpful to some of the audiences that perhaps joined a little bit late to the webinar. Yes, I can take a first crack of that. I think like Alison and visky, he said. A lot of this has to do with the cost of healthcare in the United States, which I think is a very different model for many other countries, given that it's more private insurance and. What interoperability is getting us from a cost perspective is that. A very clear example is if you know that. A patient has had some sort of procedure done or some lab result or lab test done, then you don't necessarily need to do that again at another organization if that patient has been transferred between the two. And that's not only important for costs, but it's also important for, you know, the patient because the patient also has time constraints and maybe they've already been put through a lot of their, you know, if they're seeking healthcare, they're probably valuing their time more than they are. Having to go to the doctor for one, yet one other event. And so that's very important, but I think. Apart from cost, healthcare data is the best data to help us all live longer, healthier lives. But it's also the data that is the most locked down, the least successful, and the most esoteric. And I think the goal here is to make that more available, securely, of course, to other developers or other systems. So that they can interact with that with the data at least that they have the right to or the data that the patients have given them the right to in a manner which allows them to put their own creativity behind it so that we can discover novel solutions for. Various elements that people have had, It's really important in research, especially with clinical research organizations that might have to deal with patients that have rare genetic diseases, it's often difficult to find a large enough cohort of them at one organization. You might have to run a campaign and ask patients from thousands of different institutions to share their data so that you can find a big enough group to actually run analytics that get you some sort of. Solution. So I think there's a lot that can be. That a lot of unlocking of the healthcare industry, that will happen with better interoperability and that's all stuff yet to come. I agree Ricky and you, I think the other thing too that we'll hopefully see through interoperability is reduction in fraud, waste and abuse. As we know this is a huge. Impact on going back to healthcare costs, but also just the fact that people are missing out sometimes on healthcare because of fraud, waste and abuse. And it's my hope that through interoperability, through exposed transparency. Of data sharing that will also be able to reduce the amount of fraud, waste and abuse, which is in the billions of dollars right now in the United States. And Ricky and Alison, you guys both touched a little bit on cost kind of from the patient perspective of just not doing, for example, AVP procedures and things like that. What are the typical costs associated with achieving interoperability in any type of healthcare organization? Yes, I think they're the best answer. Here is probably what CM s s guidelines are. And. That that's published in their rule, but I think that's also a little bit. They have a good answer for what the initial cost is, which they're estimating about 1.5 million. I'm not saying that's what our cost is. But they're also ongoing costs that I think CMS has published that may be missing the mark on the full scope of things. The total cost of ownership that a plan should probably be considering. Because even after you have this up and running, there are other applications that want to connect their patients that you know may have issues with authorizing access or. you know It'll frankly increase the level of engagement that patients have with your health plan and the other apps as well, which is probably a benefit to the plan because they have a, they then have a closer relationship to the individual and I think there will be additional costs put on that. Will be cost if you're looking at a kind of? With a small field of view, but ultimately the goal and the. Potential here is that it would increase. The retention of these members, but also lower the overall cost of, you know, healthcare for these individuals. So imagine you know right now when you're enrolling a new member, you don't know anything about their history of their medical conditions. With these new rules, you will have the opportunity to ask them and the, you know, transferring health plan or health system will be required to provide you. With that data, which you can then use to better direct that individual's healthcare or make sure they don't miss a beat between the transfer of plans, so I think ultimately. This should lead to a reduction in total. Cost of care from these plans when you're looking at it at a macro level. From a technical perspective, the organizations to just to meet the goals of interoperability, they will have to ability capability to ingest the fhir data which we can use our products and solutions Similarly to exchange information what their existing data for example health plan has to publish their data, they again they have to integrate using fhir standard, again they can use the products and services. So this is the base level where they can consume fhir data. Because Sphere isn't more like an integration or exchange standard. It's not data storage standard. But then if you want to truly add value, increase, increase the exchanges and then use more data and then gain more and more value out of it, then you increase you design, modify the data systems, use all the data that is available on fhir, and then add value. So to meet the base needs of interoperability, it's all your integration. Exchange. That is what will change. That is where the cost will happen. That is from a technology perspective. But moment you start using the data on there for the power of data, unlock it using big data and other architecture insights, engage with the patient, you get more value, there are additional cost to it and then but then there are more Better Business outcomes ultimately reduce the cost, increase the customer experience. I think you're absolutely right, Visky. And I think also you increase, hopefully one of the outcomes is better health all together because with the increase of data, with putting the power of analytics both descriptive, prescriptive and predictive analytics, you'll be better able to help patients manage their care, be able to pinpoint when somebody needs care. And hopefully guide them to the right place for care, as opposed to, for example, using emergency rooms or hospitalizations. To get them care outside of the hospital setting to reduce that overall cost of care. So while I agree with Ricky 100% that there is absolutely going to be a cost to implementing interoperability and I agree that right now I think our best estimates are the CMS estimates that we should be going with. I think that there is an ROI to this. There is a positive ROI. To both the health plans and the providers in being able to effectively utilize the data that they now have at their fingertips in order to better manage care. Awesome. That's super helpful. Another question we have in the audience is we can see the benefits of fhir bulk data. When can we expect it to be in wide use and what are the drivers that will help accelerate its use? So Fhirbook data is actually already being used by CMS and they are essentially allowing health systems that are engaging in ACOs for Medicare patient populations to receive fhir bulk data, formatted data for their attributed numbers or attributed patients. And what that means is that you can get your. Full medical history for your entire patient population in the ACO for all of the. Patient's medical care across all health systems of that individual under Medicare and then it's kind of up to you to do something with that bulk data format and we already from the one upside, we're already working with pairs that are using us to get data from various. Organizations, whether it's a health system or other plans or other apps and transforming, we're then transforming that to provide access via again, fhir APIs, the bulk data spec, but also analytic interfaces that then other organizations are using us to interact with that data. So I think it's already being used. The EHR vendors have not delivered full support for it yet, but there are federal mandates around its use. Basically this coming year. To implement it. So I believe that by the end of 2021, beginning of 2022, it should be pretty broadly used, at least for transmitting data, and then organizations will be able to use a platform like ours or build something themselves to then interact with that at the population level via analytic interfaces. Awesome. Another really good question. And just in terms of, you know, learning a little bit more about fhir content as well as implementing it into their organizations, someone asked Where can I find more information on fhir standards to help educate myself and my staff. Yes, Alison, do you guys want to take that or do you want me to? The HL 7 organization site has a lot of information about fhir standards, both for the technical users as well As for the developers. It provides the data model structure, security considerations, and the various resources that are available at our disposal at various levels. For example, what are the Security, Provenance, Consent or whatever developer needs to? Consider our organizations. Consider they are described and then whatever the actual the business context of the resources, the medication, the diagnosis and then the lab visits specimens and then the level, the last level where in about the analytics, the data, aggregated data, all of those things are there. So HL 7 dot R slash fire is a good resource. There are very one up also has other sources and then TCS. In our website you can find lot of white papers and blogs and point of views. And then? There are plenty of information today available in terms of implementing the Fire standard. CMS is has a lot of pretty good resources. And just give you just to add one more other resource. I don't O&C also has some good resources as well. Awesome. And I think we're at time. So I wanted to give a big thank you to our speakers today, Ricky, Alison and Visky for the Super informative session today. And a huge thank you to everyone that attended as well as engage in the discussion in the Q&A chat on our YouTube channel. I hope everybody found the webinar helpful, especially if you're working on implementing the OMC and CMS rules. As a summary, we got to review today the guiding principles and the future vision of CMS Final Rules. And how both one of health and TCS are working together on furthering interoperability and the healthcare sector. For anyone that missed parts of the webinar or joined a little bit late, just to iterate from our earlier points, the session has been recorded and will be available on our YouTube channel soon as well as both of our websites. So thank you again to everyone that joined us today. Have a good one. Bye bye, take care. Thanks everyone. Have a good day. Bye.