Datica Podcast

April 14, 2020

ONC Final Rules on Information Blocking – Part 3

In this episode of 4x4 Health, we continue our exploration of the ONC’s final rules for promoting interoperability with a deep dive into API’s, FHIR, data sets and certification requirements. We talk with Avinash Shanbhag, Acting Executive Director of the Office of Technology, in the Office of National Coordinator for Health IT (ONC) where he leads activities in the advancement of health IT standards for interoperability and with Johnny Bender, a Public Health Analyst in the Certification and Testing Division of ONC. Johnny assisted in writing the API section of the Cures Act final rule, serves as a subject matter expert on several HL7 FHIR standards, and manages several certification criteria for the ONC Certification Program.

Dr. David: Welcome to 4 x 4 health sponsored by Datica. Datica, bringing healthcare to the cloud. Check them out at www.datica.com. I'm your host, Dr. David Levin. Today I'm talking with Avinash Shanbhang, acting executive director of the office of technology in the office of the national coordinator for health IT, usually referred to as ONC. Where he leads activities in the advancement of health IT standards for interoperability. Also with us today is Johnny Bender, a public health analyst in the certification and testing division of ONC. Johnny assisted in the writing of the API section of the curious act final rule. Serves as a subject matter expert on several HL7 FHIR standards and manages several certification criteria for the ONC certification project. The recently released final rules from ONC on interoperability address some of the most important issues in health IT today. Avinash and Johnny have played key roles in establishing requirements and standards in support of interoperability. I'm grateful they're here today to share their insights. Welcome to 4 x 4 health Avinash and Johnny.

Avinash: Dave, this is Avinash. Thank you very much. It's a pleasure to be with you today. Thank you.

Dr. David: Wonderful. For today's discussion, we're going to want to dive into the substance of the final roles as they relate to standards, APIs and data sets. But first to get us started, I'd like to take a few minutes so we can learn a bit more about you as individuals and your work. So Avinash, if you don't mind going first, tell us a little bit about yourself and the ONC and then we'll have Johnny do the same.

Avinash: Thank you Dave. So, I'm Avinash Shanbhang and I’ve been with ONC since 2011. So I have actually worked, I joined in the standards and testing division, so I worked at ONC during the stage run meaningful use program and the 2015 certification edition. So really got a good exposure of the standards and the challenges around implementation. Around the time I became a deputy director that, and really for the last several months have been acting as the executive director for Oxford technology. That I lead our certification program, the standards division that coordinates standards across all the standards developing organizations and our technical strategy analysis division, which really looks at both innovative solutions and also, metrics on how all of our standards activities are impacting the world. So that's a brief background. Previous to joining ONC, I was a software developer and a manager in a private sector company. Thank you.

Dr. David: Thank you. And so, Johnny, if you do the same, take a moment and tell us a little bit about yourself and your role at the ONC.

John: Yeah, absolutely. So I got my start in health IT soon after I graduated college at the university of Texas at Austin through a certificate program that was actually started by ONC. So it's kind of full circle that I'm working here now, because this program was meant to develop a health IT workforce. So now I feel like I'm paying my dues. So I did that program and worked in health IT related things for several years after that, part of the time in South Texas and in Brownsville, Texas, where I worked with like a regional health information exchange and some other health innovation projects. And then moved up to DC and have been working with the federal government for about two and a half years now. I'm coming up on my two-year anniversary at ONC, which I'm excited about. And I’ve had experience with, using a lot of the standards that we have adopted as part of the final rule through partnerships with the Georgia tech, master’s in computer science program. And working on other projects just on my own. So yeah, I joined ONC as an intern and have moved up to a public health analyst and, now I support various certification criteria for the program.

Dr. David: Well thanks for sharing that. So interesting career journey. We may have to have you come back sometime just to go a little bit deeper into what that experience has been like. So I do want to turn now to the substance of the work you've been doing, but before we do that, I have to remind you, it is a rule of the 4 x 4 podcasts that guests are not only allowed but are encouraged to call BS on the host if he says things that aren't accurate or incomplete or whatever. So you guys are clearly experts in this discussion and as we go through this, please feel free to, at least politely correct any misperceptions or anything that, any confusion I may add to the conversation. The way I see this, one of the overarching themes of these rules is that with a few well-defined exceptions, clinical data should flow for the benefit of the patient. The assumption is the data will flow. And when I think about how you make that happen, I think of it as having sort of three if you will, three layers in an overall approach to promoting interoperability. So one layer is sort of standardized pipes for connecting. And I believe this is where APIs in general and the use of the FHIR specification particularly come into play. But the next layer in this is the data, once we've established the pipes that allow us to connect consistently, what's the data that we should expect to flow through those pipes? And in particular a kind of minimal data set, an example being the USCDI. And then lastly, there are the behaviors that either promote or conversely can block the flow of information. And as I noted in a previous episodes, we've talked with ONC officials about that last item, the behaviors that result in information blocking, the rules designed to address those behaviors and the exceptions that apply as well. What I'd like now is for you Avinash and John to help us dig deeper into, if you will, the pipes and the data and more broadly the role that standards and certification can play. So let's start by talking about APIs. Whichever one of you feels comfortable, take a moment and, for our audience, explain what is an API and why are they a key ingredient in advancing interoperability. And then we'll transition into a bit of discussion about FHIR. So if you would, what one of you address that basic question about what the heck are these APIs and why are they so important in solving interoperability challenges?

Avinash: Hey Dave, this is Avinash. I'll begin and then turn over to Johnny to talk about additional details. So thank you for that question. So, APIs or application programming interfaces are really the connectors, if at all I can say between software programs, that are written by disparate or different groups. So again, example for folks that use everyday tools like on smartphones, if you are making a travel booking or if you are looking for a hotel reservation or restaurants, what you're doing is accessing information that is not really fronted by a user interface but data that flows seamlessly through internet and really is being utilized by apps in innovative ways. So what API has really allowed us as an industry to do is make use of information that's available and, and, developed at different companies without having to really use the entire product suite and those off things that are for everyone instance of product that somebody wants to use. So for example, if I want to use an app that wants to look at maps, instead of spending a lot of hours at deals building maps, it's much easier to use an API to connect it to a map solution that perhaps Google has. So really apps allows you to innovate, to build out new products quickly scalably and also let you focus on things that you are good at without having to understand everything. And those from the foundation. Does it help?

Dr. David: Yeah. So I think that's a really good explanation. And the other important thing to point out here is, this is not theory. This is how a lot of the broader digital economy works today. So as is sometimes the case in healthcare, we're catching up to where a lot of the world already is today. So there's a lot of reason to have confidence, in this solution and the impact that can have. Avinash the other example I like to use when explaining this to people is, you go on Amazon and you order a package, and somehow ups or FedEx, knows and is able to tell you. And Amazon is also knowing and is able to tell you where that package is as it transits. They're not accessing the internal guts of each other systems. They are exchanging data via APIs. And it's that sort of unique ability to connect and exchange and collaborate that makes them so powerful. Johnny, you want to get a word [10:47 inaudible]?

John: Absolutely. Yeah. So I'd also like to add that healthcare is a really unique industry for APIs. Because we've required through regulation that healthcare providers use electronic health records across the country for administrative data. So we now have like computer terminals where providers are entering information. It's being recorded in a database across the country. And because we don't mandate the use of a single electronic health record, we are a Federation of States, it becomes complicated when we want to share that information between systems. So this highlights why application programming interfaces need to be standardized, for healthcare specifically because we were dealing with a number of different information systems, different vendors that have developed their own proprietary databases, ways of capturing and storing this information. But now we need to build an interface that's available to apps and for information exchange, that's standardized and usable by everyone. So I think it's a really unique industry. And I think that you wanted us to dig deeper into like the roles that standards and certification can play. I think ONC and the certification program specifically has a huge role to play in mandating like a standardized API to enable like a whole app economy, and nationwide information sharing and a lot of like public health surveillance activities that would help to address the problems that we're experiencing right now with Covid.

Dr. David: well, [12:53 inaudible] Covid, cause I’ve been thinking about that this week as well and we don't have it, but if we had some sort of standard reporting API in place across the country, we'd be in a much, much better position to collect that data in near real time, have a better sense of the trajectory of the epidemic, how to distribute precious resources and all the rest of it. So don't have that today, but clearly that capability is embedded in the technology that we're deploying, and we can get there. You've mentioned standards, that feels like a pretty good opening to ask. So what's this business about FHIR, and why was FHIR chosen, in particular as part of the final roles?

Avinash: Good. So this is Avinash. Maybe I’ll start off and then again transition to Johnny for some details. So, interesting you mentioned about FHIR. So I’ll talk a little bit about 2015, when we had the 2015 edition certification, and we had requirements for API at that time, so really providers and vendors are building and supporting APIs. Interestingly, at that time, FHIR standard was not as mature. So our health IT, top federal advisory committee requested, ONC to not specify a standard, but to make it a functional API. So when, since 2015 when we adopted API as a functional requirement, what we found was industry coalesced very quickly into a project called the Argonaut project and industry, all the industry leads really getting together and realize, as Johnny mentioned earlier, that rather than building these [14:50 inaudible] APIs that are like uniquely built for each vendor, it would be great to kind of have a standardized way of talking to each other. So exactly what an API does, rather than having everybody built off that unique way of calling each other, let's just come up with a standard way of calling and exchanging the clinical data. And that really from that emerged the FHIR standard, which is a standards in the Agile seven standards developing organization really well supported by industry and FHIR has undergone many versions. So it started off in 2015 as a version one and by now in 2019 and 2020, we are on FHIR version four. And just a background like, over the years, what we found is that lot of certified health its developers, when they came for certification, they had some version of FHIR that they were using as an API for accessing, for giving access to the app developers. So during the time, as we were looking at implementing the cures act, regular requirements of having certified health IT developers publish APIs that can be used without special efforts, our notice of proposed rulemaking requested various options. We kind of looked at industry and requested them to opine on whether we should go for older version, version two, which was really well adopted by industry or the later versions. And through all the public feedback, what we found is industry overwhelmingly suggested we go to the version 4 which was both, not only a later version, but also more importantly have some of the standards which are called resources within the standard as [16:43 inaudible], that means that they are backward compatible. So over the course of our NPRM and the final regulations we landed on these standardized API called FHIR and the version four, which is the latest normative standards, just so that the industry has a stable base, stable and exactly standardized technical guidance that everybody can build off as a foundation. So in short, what FHIR standard enables both industries to do is they don't help kind of work towards a Denovo standards but can use what all of the industry have come coalesce to and can really spend their efforts on building innovative tools and usage of these APIs. So it really helps both industry and especially the users of this APIs to have a very standard platform that is both well adopted, well integrated with and really leveraged by industry.

Dr. David: So this is a topic of real to me personally and I guess I have to confess in front of all of you and our listeners. I've written some things that were pretty skeptical about FHIR in the past. And I’ve come to see that I was wrong about that. And in particular, I was concerned about the ability of the industry to reach a consensus, and the time that it would take. And I have to say, I’ve been pleasantly surprised at the speed at which FHIR has evolved and had the pleasure of talking with Graham Grieve, many of whom was considered to be the father of FHIR if you will. And he would make the point that part of the reason for that is that they've really focused on building our community of users. And that's been a game changer in terms of agility within the standard. So that's all great. But let me push you guys a little bit on this because it's also I think fair to say that, although the FHIR standard is substantial progress and I'm fully supportive of the idea of we need something like that as a foundation and the rules really help us get there. But there are application needs that go beyond what FHIR can offer. And so I'm curious about your thinking about the place for custom or proprietary APIs as we go forward into this new world. So, FHIR can do a lot, but not everything, it will evolve over time. Some will want to go faster than that natural evolution. So is there a place for custom and proprietary APIs and how do you guys think about that part?

Avinash: Absolutely. So I’ll start and again, Johnny, feel free to chime in. I would say one of the benefits and one of the things when we started looking, and actually I should say not ONC specifically, but the industry started looking at FHIR, one of the things that the FHIR developers started with Graham Grieve and his group really built from the start was a great extension model. So really, I can give you a good example and that's something we talked about was, in US requirements for data exchange. We have the requirement from to be able to exchange race and ethnicity whereas in many European countries, race and ethnicity is clearly not allowed to be exchanged. So what we found was industry, the standards folks were able to extend the FHIR standards, FHIR resources. They are the kind of modules of standards to able to support these extensions very easily add in a way that was also able to be programmatically understood by recipients. So if I'm an app developer that's calling an API that has race ethnicity, I can programmatically understand that it has a race and ethnicity without having to pick up a phone and call to the actual EHR system to know what data they have. So the benefits are, and again, like just to kind of talk about FHIR standard where we feel of kind of combating with other standards such as Agile 7B2 or CCDA is that from the beginning it has been built to be extensible and customizable. So we feel that it can enable that challenge of growth and innovation. I'll stop that and see if Johnny wants to add in a few things.

John: I mean, so I would add that, so you know, ONC is working on a small part or a rather large part of interoperability. But it's not the only part that's required for the healthcare system. So I mean there's like GS1 standards for tracking supply chain, and like large supplies within an entity. And there's obviously proprietary solutions for things that aren't represented by FHIR. So like, FHIR isn't trying to encapsulate everything in a healthcare environment meet all business needs and healthcare needs. But it is designed in a way that it's flexible, and it’s based specification and a lot of the specifications that we've adopted as part of the rule, actually don't require the use of like several pieces of the standard. So like for example, some parts of the smart application launch framework, maybe optional. And what we've done as part of the certification program and as part of the publication of the final rule is where it's ambiguous, we've tried to, clarify and require some of these optional capabilities. So my point I guess is that FHIR isn't going to encompass everything, but it wasn't designed to, and sure there's absolutely needs for proprietary APIs for different use cases. But what we're trying to do is enable standardized APIs for sharing health information across the country. So I think we're trying to stay in our lane as much as possible.

Dr. David: This makes a lot of sense to me. And, the way I’ve thought about this is, there can be a virtuous cycle here as well. So the folks that want to be way out on the bleeding edge and begin to do, develop custom solutions and proprietary solutions, they're kind of on a journey of discovery and hopefully the lessons learned there can feed back into the development of standards like FHIR. And then those standards eventually predominate. So hopefully there's a way that these things cannot just coexist but actually feed off of each other in a positive sort of way. Oh, please go ahead. Don't let me cut you off.

John: Well, I was going to say that like the proprietary API of today, maybe the standard of tomorrow.

Dr. David: See Johnny, I don't like it when my guests summarize what it took me a paragraph to say and just a couple of elegant words. So I'm going to let that go this time, I want to go just a little bit deeper on this topic, because I think that it's important for folks interested in this area to understand the way you thought about the various stakeholders. So as I read the rules, essentially there are these three groups of API stakeholders, there's the certified API developers, there's the API information sources, and there are API users. I'd like one of you to just briefly walk us through these different stakeholders. Who are they and how do you expect that they will be impacted by the API requirements and or other rules?

Avinash: Sure. So this is Avinash, I’ll begin. So, you are right. We kind of wanted to be very sure that as we developed the final rules, we wanted to be cognizant about all the current EHR vendors, the app API users and the like. So we took great pains to make sure that we define and we kind of clarify who they are. Sort of high level, just starting with like the easiest, the certified API developers are the health IT developers who are part of our certification programs. So they are the ones, the EHR developers who are certified who have an API. So clearly, they are the ones who are impacted by rules because they are the regulated entity if I may say so in the rule. And what you've done is in the final rule is try to make sure that we have developed very pragmatic solutions. So we have again, put in standard that the industry has already developed. So we haven't gone and tried to pick something that was way out in the discovery area. We also have tried to constrain in the business practices, our condition certifications, which are really the business compliment to the technical criteria. We have limited the focus of those business conditions only to the certified API developers that relates to that certified capabilities. And that's the new, again the next level of kind of clarities. The certified technologies are only there are about for a certified health its criteria that we put into our regulations out of which three are from the 2015 edition. So really this new rule only adds in this new standard API certification criteria. So both are the developers are the certified API developers and the technologies are called certified API technology. API users are, as the name says, they are the users of API. So they will be the app developers who will be developing, who will be potentially innovating and using this API. And clearly this rule has a lot of support for the API users, the app developers. Because what we really wanted was like take to heart the Congressive direction of making sure that the API can be used without special effort. So we kind of put in a lot of common sense requirements around it, around both the technical specification of standardization and also the business requirements around transparency, fees, condition and the business requirements around rights and the like to just make sure that the app developers, the users of these API who would be building new apps for providers and payers and the patients all are able to do as seamlessly as they can.

And finally, the API information source are nothing but the provider organizations that have purchased these products. And really, I think what you wanted to make sure was that once the provider organizations purchase this product, they have all the independent rights to be able to use the API both internally. Because what we heard was there are lots of cool ways by which providers can use the data to help their own operations and quality measures and the life. So we wanted to make sure that all that is also allowed at fallacious due to these rules. So we kind of crafted it around these four kind of large buckets of stakeholders. And again, our attempt was to make sure that the existing EHR developers have [29:22 inaudible] for word, which is common sense and pragmatic, while at the same time the provider organizations and the app developers can clearly be able to leverage this and build innovative solutions.

Dr. David: This is really helpful. And in previous podcasts we talked about, this gets into interesting balancing acts about how do you protect intellectual property while still promoting innovation. The business rules around this and, the like, because as I said at the top of the podcast, it's not just about the technology and those requirements, it's also about the behaviors that people choose. So this is really helpful. Johnny, anything you want to add to that before we move on?

John: No, I think Avinash got it pretty well.

Dr. David: So Johnny, let me keep you here for a second because I know you manage several certification criteria for the ONC certification program besides the APIs. I don't want to go really deep on this but take a minute and tell us a bit about some of these others like ECQM and public health criteria.

John: Yeah, absolutely. So we have, several different certification criteria. If you go to our website, you can see a listing. We always send people to the certification companion guides, which shows a listing of all of the certification criteria that are adopted and regulation for our program. So each of these are, designed in kind of a modular fashion, so that, health IT developers can attest to, different modules, and kind of ease the burden on ALTs, Authorized Testing Laboratories for testing and certification. So the ECQM criteria, as you mentioned, there's four certification criteria for ECQM, C one through C four, in our CCGs. And these are designed primarily to support submissions to the CMS quality programs. So, they have for eligible hospitals and eligible professionals. They have an annual reporting process for ECQM to see how the other population of hospitals and providers are performing on a certain measures. So the ECQM criteria test the ability of the health IT module to calculate the different measures that are required as part of the CMS, reporting. And then I'm also, the SME for the public health criteria that we have in the program. There are several public health criteria. A lot of these rely on, non-API messaging. So they relied on older versions of HL7, like HL7v2. And that's health level seven, version two for more basic transactions of messages. And there's things for like, cancer reporting and, syndromic surveillance. I mean I think one thing that I personally like to do, and I see for our program is as we see the industry more broadly adopt, FHIR R4 in the coming years. It would be great to think about how we can leverage these standardized APIs across our other certification criteria. And CMS is doing a lot of work right now, investigating the use of, like FHIR Ball data to support ECQM's. So that, maybe one day we won't have to have a separate certification criteria for, RCQMs at least in the way that it's designed today. And the same is true for public health. Like a lot of the public health features, that are supported with the certification criteria today, could be improved. Obviously with a lot of stakeholder input, could be improved and, streamlined with like a standardized API.

Dr. David: it's exciting to think about where this could go. I mean part of the vision for electronic health technology in a clinical setting is, the care providers will just go about doing their job and the data will be an exhaust, if you will, that it comes out the backside of that. And this kind of reporting can be greatly auto automated and there's, I'm sure there's many, many different kinds of barriers us getting there. But it's a lovely vision and, we know it can be achieved. We know it's been achieved in other industries.

John: our certification program has received, criticism, for being overly burdensome and complex. And that's kind of the promise of, something like a standardized API, is to potentially reduce the burden, and not have to require, several different methods of, reporting for all these different types of programs.

Avinash: so this is Avinash, I may want to add a little bit. Interestingly, and thanks for Johnny for talking a little bit about burden because as we all know, the whole quality reporting program is highly burdensome with Denovo quality measures and reports being generated. As part of this final rule we have in the standardized API requirements, we actually have an initial version of what we call as a standardized API for population services. So you may think, you can think of it as rather than having data for a single patient, what you are now getting as a standardized API for a group of patients or whatever cohort of patients that really is acessible and excitement for us at least is that again industry and the standards are developing a development organization folks all worked on it for about substantially about two years to build out the standards. And our hope is that, using these bulk APIs will really be a game changer in both the reduction of burden on the quality measure reporting as Johnny mentioned. And also for, again not for now, but again hopefully like the next time, hopefully nothing will happen. But if there's a Covid like situation, public health reporting agencies and other organizations that have to access information from hospitals would be able to do that at a dramatically faster pace than what we see. So really, we see the initial requirement of bulk data API we called the population level API, which we worked with industry and several of our partners, in the stakeholder community are really going to help us and, make the whole exchange and, use of health information dramatically improve. So I just wanted to mention that.

Dr. David: Yeah, I think of that as, what I call health IT 2.0. So health IT 1.0 was the basic digitalization of clinical care and data essentially rolling out the EHR and the work we've done over the last 10 years. And that's like a necessary precondition to go into the world that we're all hoping for that can have a dramatic impact on safety, on quality, on efficiency, on satisfaction. And I think you've given some really terrific examples of that. If you've just joined us, you're listening to 4 x 4 health and we're talking with Avinash Shanbaug, acting executive director of the office of technology in the office of national coordinator for health IT or ONC and Johnny Bender, a public health analyst in the certification and testing division of ONC. And I'd like to turn now to a discussion of data sets, if you will. And as I kind of laid out at the top of the podcast, I view this having three layers. There's the layer that defines the pipes as it were, what they should look like, how they should connect. And then there's the discussion around, well what data should actually flow through those pipes. So if you buy my analogy there, I am wondering, how did you think about that? Why was this important and where did you land in terms of some other requirements around standardized data sets?

Avinash: Sure. Thank you. This is Avinash. I'll start. So you're right. I think, at the end of the day, the 21st century cures act really required all electronic health information to be exchanged. But then as we looked at our final rules and really wanted to make sure that, we wanted to take a common sense approach, pragmatic approach that let industry evolve and be able to support, the exchange and use of that data at an increasing scale without really either burdening them with information that was perhaps too much, too soon or, be exchanging information that was not sufficiently standardized, structured to be useful to the recipient. So what we landed on was this concept on, and actually we have in the final rule a concept and a standard that ONC is going to manage called the United States core data for interoperability. This is really a curated list of data at a policy level. So this is not a data with any specific, exchange standards of standards of how to structure it and the light. But really this is a list of data elements that over the course of our meaningful use program, from stage one onwards. And again, working with stakeholders, we find it extremely useful as a flow. Like they have basic stuff for identifying patients. So really that data consists of patient demographics, like main addresses and the like that really go towards improving patient matching, very high level and very important clinical setup information like medications, problems, procedures and the like that are very critical to the use to do clinical calves for the patients. So really we took a very critical and deliberate approach to make sure that the data that was going to be exchanged through API, through electronic health information requirements of the regulations and through the act what both, standardized so that both the senders and receivers could understand it and also in a way that industry could adopt and upgrade over the period of time. So what we started off the US CDI is really a small update to what we had originally put into place for our previous certification and we called the common clinical data set that was established in 2015. We updated it to improve patient matching at a high level, improve patient matching. We added in a few data elements that were optional in the 2015 particularly for the pediatric environment. Again, because pediatric care or the important requirements coming out of [42:15 inaudible] rules. So we wanted to add in that and then we also updated some of the terminology standards because as you know, some of these standards are rapidly changing. For example, with the Covid we also have now [42:28 inaudible] codes and [42:29 inaudible] are coming up. So industry migrates and is allowed to upgrade their terminologies rapidly. So we wanted to make sure that we were able to have these data elements of correspond with all the required terminology. So we did a very modest step. But we also, as part of a final rule, we put in place something that we are very excited to talk about that is called the US CDI promotion model. But what we want is, we want this data set to grow over the years but based on public input. So as part of our cure’s implementation, we will be having a process that will be a public process where every year the United States core date of interoperability will be upgraded based on public input, stakeholders, proposing. You can think of a situation where you have stakeholders proposing new data elements. We'll go through a review process and finally we will have an updated set of data elements that kind of gives industry a very deliberate enhancement trend that they can then manage their own development efforts to it. So we are excited about US CDI, we are excited about the fact that it's going to be a public process so that industry knows what's coming rather than having to kind of wait for the regulations to kind of emerge and then gear towards updating their system. Does that help?

Dr. David: Yeah. So I think it really helps, you had anticipated my next question, which was about, these things are not frozen in time, so how do they evolve, their data sets emerge that we didn't even conceive of in the past. So, the whole Omex revolution is a good example of that. And like you, I am excited, and I think this made more of an impact to me as I was reviewing the final rules that there's this pathway for evolution and, it feels like a kind of public, private joint venture, which is, I believe served us really well to this point. Johnny, anything you want to add to that before we pivot to our final topic.

John: No, I think Avinash got it all pretty well. One thing that I wanted to, kind of mentioned is, so we're requiring standards as part of this final rule. And it's a mix of several different standards that kind of interface together. And, one way I like to think about it is, you have these standards that are maybe, developed by, like an internet organization, right? Like, [45:23 inaudible] something. And then like HL7 will develop standards that kind of profile those standards. And then we come in and see those standards and figure out how we can mandate them as part of certification requirements. And so we in a way profile those published standards by like standards development organizations like HL7. And then we go a step further to define like a test procedures where like, it's almost like the brass taxes of what the electronic health record companies or the health IT developers will need to demonstrate, the functionality to meet the certification criteria. And then we actually have testing tools that we help to develop, where it's even less abstracted than the test procedures that we've written. So it's like there's, and I mean the US CDI is as part of this, right? Because, the US core implementation specification was developed by HL7 in response to the US CDI that we specified. And so I think it's interesting to think about how my Lewis standards, kind of works together, and how it's operationalized within our program.

Dr. David: That's really helpful. And you've set me up for my final question today, which is, what's the timeline for implementing and enforcing some of the things that we've talked about today? How's this going to play out in the months?

Avinash: Sure. Again, this is Avinash. So as we put out in a final rule, there are variety of timelines, but at a high level, for certified health IT developers that are already supporting existing functional APIs, they have two years from the publication date of the rule. And I just want to emphasize that the rule has not yet been published, by the federal register. So once the rule gets published on the register, that's when the clock will start. So from the time it publishes, they have up to two years, the developers to build out this new API and then provide it to the provider organization. Now they can do it. The effective date is the earliest they can start, which is 60 days from the time the publication is done. So we anticipate vendors looking at the rule and over the course from 60 days to two years be rolling out these products. These should be seamless to the providers, because providers as I mentioned earlier, if they are using certified health IT products, they previously, they already have API. So, this is more of like, seamlessly getting a patch, as we all are familiar with our systems, getting Microsoft operation systems, or Mac patches, hopefully it's a patch upgrade for that providers will be able to receive over the next two years. For the developers, for the health IT developers, some of our conditions of certification really start at around six months after publication. And that aligns with both the information blocking requirements and the other conditions of certification requirements. Those are really business practices such as ensuring that the documentations are publicly accessible. All the terms and conditions are published appropriately and presented to the developer community. So we'll see in terms of broad timelines for APIs, we'll see some of the business practices, kind of updated around six months of the publication and the implementation and really the API is being made available to the providers anywhere between 60 days, six months and up to two years for existing health IT developers. And then we obviously, anticipate and encourage new developers to also join the program anytime once the rules become effective.

Dr. David: Well, I for one I am going to get some popcorn and watch how the various EHR vendors respond to that interval, who goes quickly out of the gate and who delays over time. So when did you guys anticipate a formal publication in the federal register? Is that something we can expect within a couple of months or, what can you share with us on that part of the time?

Avinash: Yeah. That I have no visibility towards that. So Johnny and I, once it goes from our hands to the federal register, it's really something that we have not had much visibility towards. So we won't be able to respond to that.

Dr. David: Okay. Well, I'd rather you not tell us the answer to something you don't know the answer to, so thank you for that. This has been really terrific. And, we've been talking with Avinash Shanbhag acting executive director of the office of technology at the ONC and Jonny Bender, a public health analyst in the certification testing division of ONC. Avinash and Johnny thank you so much for joining us today for the hard work you've done on behalf of the country and, for sharing your expertise.

John: Thank you.

Avinash: Dave, again this is Avinash. Thank you very much for having us. And again, we want to take this opportunity to appreciate all the tremendous feedback that we got from our stakeholders. So really, it's the community that helps us do our jobs. So thank you very much.

Dr. David: And I’ll build on that. It is been my pleasure and honor to play a small part in all of that. And I know the federal government sometimes takes a beating, but I have to say I have found this to be a terrific process. I have found, ONC leadership on staff to be very accessible and, interested and open minded. So again, thank you for the hard work you've done. I'm personally very excited about how this is going to unlock a competition and drive innovation forward.

You've been listening to 4 x 4 health sponsored by Datica. Datica, bringing healthcare to the cloud. Check them out at www.datica.com. I hope you'll join us next time for another 4 x 4 discussion with healthcare innovators. Until then, I'm your host, Dr Dave Levin. Thanks for listening.