Promoting Interoperability and Innovation: An ONC Expert View

In this episode of 4x4 Health, we continue our ONC Expert Series with Steven Posnak, the Executive Director of the Office of Technology within the Office of the National Coordinator (ONC).  This role places Steve at the intersection of regulation and innovative technology in Health IT, as he leads both the ONC Health IT Certification Program and directs the ONC Tech Lab.  In this episode, Steve discusses the new ONC proposed rules on interoperability (here are links to the rules themselves and where can post your comment directly), rapid technological innovations coming to Health IT, and how ONC is helping healthcare interoperability finally ‘catch up’ with the rest of the digital economy.  To learn more about the ONC proposed rules in relation to information blocking, listen to this 4x4 Health episode with fellow ONC leader Mike Lipinski, and, to hear from the National Coordinator himself, check out Dr. Rucker’s 2019 Predictions episode from earlier this year.

Dr. Dave Levin: Welcome to 4 x 4 Health, sponsored by Sansoro Health. Sansoro Health, integration at the speed of innovation. Check them out at www.sansorohealth.com. I am your host Dr. Dave Levin. Today I am talking with Steve Posnak, Executive Director of the Office of Technology within the Office of the National Coordinator for Health Information Technology, usually referred to as ONC. Steve has been with ONC since 2005 and currently advises the national coordinator, leads the ONC health IT certification program and directs ONC standards and technology investments through the ONC tech lab. He led the creation of the interoperability standards advisory, the redesign of ONC’s certified health IT product lists, created the interoperability proving ground and developed the CCDA scorecard. The recently proposed final rules from ONC on interoperability and information blocking deal with some of the most important issues in health IT today. I have spoken with Steve before. I could tell you he is a leading expert and a driving force behind this effort by the Federal Government to promote interoperability and the free exchange of health data. We are grateful to him for taking the time to talk with us about these critical issues. Welcome to 4 x 4 health, Steve.

Steven Posnak: Thanks for having me, Dave.

Dave: Alright, let’s jump right into this. We have a lot to cover today. I’m going to ask you a series of  four questions and we’ll take about four minutes to answer each one and to get us started. Just take a minute, tell us a little bit about yourself, about the ONC, it’s authority and how you go about doing the important work you’re involved in right now?

Steven: Sure, thanks again for having me, but you know the quick summary of myself, I went to Undergraduate for Computer Science and did what any other self-respecting young adult would do when the market in the early 2000 didn’t look so good. I deferred adulthood and went to Grad school and at the time I was interested in Information Security based on some of the work that I was involved in. So, I was able to get accepted into Johns Hopkins Information Security Institute where I did a Masters in what is called Security Informatics and as I was there, I got really interested in health policy at the time. If you can remember, or your listeners remember, I was right about when the HIPAA privacy and security rules were released by the Department of Health and Human Services and you know, there was this new era of information technology and health policy security compliance and the like that, that came about. So, that was really how I got interested in the health IT and policy space that I’m in now. I, the long courtship with my office to place in the early 2000s and right when it got formed in 2004 and as your intro mentioned, I’ve been here since July 2005. So, that’s a bit about myself and how I wound up here really quickly. Happy to dive into specific details about the organization as you may feel like.

Dave: Yeah, well so, take a minute and yeah, that was terrific. So, give us the same kind of fly over of ONC. You know, what’s it charged with and you know, very simply, broadly, how do you go about doing the work?

Steven: Yeah, absolutely. So, we are an agency within the executive branch. We’re part of the what’s called the Office of the Secretary within the Department of Health and Human Services. So, we have an HHS lingo. We have organizations that are called operating divisions. So, those are the big-name kind of kitchen table agencies as I like to describe them. FDA, CMS, CDC, those are all big operating divisions as part of the department. The smaller policy setting, and other focused agencies are typically part of the office of the secretary in HHS and most of the time they’re led by an assistant secretary for a particular issue. So, we’re at the same peer level to say, for instance, the Office for civil rights that enforces the HIPAA privacy and security rules and we were originally chartered or created under an executive order, under the Bush administration, W. Bush and we lived under this executive order up until the High Tech Act came along in 2009. So, the beginning of the Obama administration and that was the first time that ONC, the office was codified in law and so, we weren’t just dependent on a single executive order to implement our mission. At the same time, we gained a bunch of new statutory authority for the first time to implement. I have a bit of an adage, you know, in government we operate on political capital, money, so appropriated dollars and authority and so, with any kind of mix or combination of those three, that’s really how a federal agency runs. ONC at various stages of had a various amount of each of those in order to do our work. In 2009, we received 2 billion with a B dollars to implement the High Tech Act and along with the EHR incentive program, which is otherwise referred to as meaningful use, which is now as you all know, you know, I’ve seen subsequent name changes, but the way that we do our work is largely we coordinate within the executive branch with many of the other federal agencies that focused on health IT or have an interoperability related portfolio and we can certainly talk about that more and then we similarly work with the private sector to help advance interoperability interests. Such as standards, improvements or pilots or other types of innovation-related activities that can help advance interoperability.

Dave: Boy, I think you did a great job with summarizing which is a pretty complex, collection of alphabet soup there and three-letter agencies and all the like. The other thing that has struck me as I’ve delved into this world and begun to learn more is the sort of public, private partnership nature of this where you really go out of your way to find subject matter experts, bring them together, facilitate exploration of problems and potential solutions and then this whole cycle of the proposal and public comment and we’ll get a little deeper into this towards the end because I know part of what we want to do here is encourage the public to participate in this and comment, particularly during this period where the rules are available for that. So, I just want to add that, that little piece to your description as well. I want to turn now to interoperability and I usually ask my guests what is the most important or interesting thing you’re working on? But I’m telling you it is interoperability because that’s what I want to talk about today and again, I consider myself a slightly informed novice at this point. But there are some things that as I’ve looked at the language in the 21st Century Cures Act and in these proposed rules that jump out at me and of course 21st Century Cures Act has specific goals and I’m quoting to advance interoperability and support the access exchange and use of electronic health information. The way I have looked at this at the highest level is that the assumption is the data should flow, that this is good for health care, it’s good for patients, it’s good for containing the cost, and that if again, I would say the default assumption, the starting point for all of this at least could be sent to be that the data should flow, that it should be available without special effort or special costs unless there’s really well defined and legitimate reasons for that not to happen. Is that a fair lay person’s understanding of the overall intent of this work and particularly when we talk about interoperability and Steve, if it’s not, you go right ahead and correct me.

Steven: No, no, I think it’s a great way to help summarize and as you mentioned, so the 21st Century Cures Act passed at the end of 2016. As you noted, it includes some substantial changes to ONC’s authority. First with respect to the certification program and then secondarily with respect to what is called the information blocking; and that really is, you quoted the phrase does you are in the statute about the having information, the electronic health information be accessible, exchangeable and usable to say it in proper grammar, you know, for many different purposes in the healthcare ecosystem.

Dave: We had a wonderful discussion recently with your colleague Michael Lipinski and Mike and I went pretty deep on information blocking and at the time I proposed to him this kind of three-layer idea of an overall approach to promoting NRR and mitigating information blocking. I want to try that same idea out on you and get your reaction. So, I personally sort of think of this as coming in three layers. The first layer defines the technical protocols and essentially this is about APIs and use of the fire standard. The next layer defines the data that should be exchanged as part of this and using that technology and I think that the US core data for interoperability, that data set definition sort of, you know, gets us started there and then lastly there’s a behavioural layer that’s mostly to do with behaviours related to information blocking. So, tech in the form of APIs and you know, related technical requirements. A Data set that we can all agree on and then some behaviours that help promote the use and permit and help prevent info blocking. Is that, again, I know I’m speaking as a layman and I’m simplifying, but is that a reasonable way for folks to think about this?

Steven: Yeah, yeah, absolutely and maybe even make it even simpler. The way in which ONC is organized today is with a large focus of our office on, you know, the policy-minded thinkers, right. So, Mike Lipinski, my colleague, is a part of our office policy. I direct our office of technology and so, together you know, we often look at health IT issues, just like you described, there’s a policy component which is really that behaviour. Are there incentives in the market, are there anti-competitive practices that may be affecting how fast or easy it is for information to exchange or be exchanged and then similarly, do stakeholders have the technical capacity and capabilities at hand to engage in those practices if they, you know, were so properly invented, let’s say? So, where we look at really both sides of that coin in terms of, you know, there are some cases where we need to focus a little bit more of our attention on policy-related efforts to see that necessary behaviour change and then in other areas, the technical standards may be slightly immature or need further testing, spit and polish to make sure that they can really support in a way that’s satisfactory, the needs of, you know, healthcare providers and the like in the space.

Dave: I think that’s a really good summary and again at the end of the day there’s, a set of technical requirements but there’s also actions and practices of health IT developers and others that ultimately determine whether we have robust interoperability or not and I think it is one of the good things and one of the strong things about the Cures Act and about the way both ONC and CMS are approaching implementation is that recognizes that this is a complex interaction of technical and behavioural factors. It is probably time to start to go deep on those technical issues and I know that is a big sweet spot for you. So, take a couple of minutes and tell us, you know, again, broadly what were you after there. We know that the proposed rules include the adoption and use of APIs in general and specifically use of FHIR, take us deeply on if you will, the sort of technical underpinnings of the proposal.

Steven: Sure, and we will do a kind of fast forward, super-fast of the past decade, you know, leading up to, you know, leading up to this point and the important thing to keep in mind is that you know, prior to the High Tech Act in 2009 and when I first started for our, you know, earlier points, adoption of electronic health record technology was quite low in both the ambulatory and inpatient setting and we were acutely focused on getting computers, digitizing data and getting, you know, getting the capacity for information exchange and information sharing much higher than it was at that time and the incentives that were made available through the High Tech Act certainly had a big impact on electronic health record adoption, EHR adoption but as the years have gone by, you know, we’ve been looking and been focused on the bigger problems that we knew we always needed to solve and interoperability at large right across a number of different use case is one of them. Provider efficiency, provider burden in other cases if you want to, depending on if the glass is half full or half empty and how you referencing things.

Dave: Right.

Steven: You know, is the other dynamic that we also seek to affect and when we talk about the technical component here, the 21st Century Cures Act includes a specific condition of certification it’s called. So, it’s one of those substantial changes tell and see authority where not only are we looking to regulate or oversee the technical conformance as we described for the EHR software, we also look at the health IT developers business practices in these cases as well that the potential for application programming interfaces, APIs, we’ll do the acronym check for everyone, you know, was recognized by Congress in terms of its effect that it’s had on other industries, right. So, when we look at our experiences with the aviation industry, you know, banking, other types of, you know, consumer electronics, we use APIs every day in our daily lives and then we go into healthcare and we’re asked to fax things and so, I think, you know, Congress recognize this discrepancy between the health IT and healthcare community and the rest of, you know, our, our competitive markets and included this condition of certification which we’ve subsequently rolled out through our proposed rule that everyone can comment on. So, through May 3rd and the proposed rules focused related to API technology is around three attributes. One is around standardization as you already indicated, it’s really important to point to make sure that there’s consistency in the market in terms of how, let’s say, applications, apps or services are able to connect to other systems. There’s the transparency aspect, making sure for everyone that’s a software developer that they can access the technical documentation and other terms and conditions that may be necessary in order to interact with APIs and then the third area or attribute and focus is around pro-competitive marketplace practices and behaviours and so, those really revolve around areas where health IT developers may be in a position to set fees and we’ve proposed certain guidelines around those and equally, where there’s opportunity for health IT developers to prohibit or prevent their customers from using third-party applications that may otherwise compete or have an effect on their market share by virtue of the fact that, that third party service that a healthcare organization wants to use maybe a kind of competitive or other complimentary product that, that original health IT developer may be interested in selling to the customer. So, that’s a quick recap. You know, without going into too many details of the broad view that we took in our proposals for the API without special effort as the statute refers to it.

Dave: That’s a really good recap and the way I think about it is the initial push of essentially the last 10 years, was the basic digitalization of healthcare. We got our clinicians to put down pencils and pens and start using a keyboard and it sounds kind of silly when you say it that way, but it was a major accomplishment. I think many of us feel like we ended up digitizing our silos again and there was a kind of market failure that this legislation and the proposed rules are designed to address that will allow us to connect in more sensible ways and share data and you know, I said earlier that I felt like one of the themes was the data should flow. It seems clear to me, the other overarching theme of all of this is it’s a design to address. Again, what I see is a market failure. I know others share that view and they promote competition which will be healthy will drive innovation and improvement and so, the sooner the better as I’m concerned. You used a phrase technology suppliers and you’ve mentioned EHR companies a couple of times. One of the things that I learned is as part of doing this work, you’ve identified really three players if you will. Take a minute and explain to us the differences between the API tech supplier, the data provider and the user because they play, all play key roles in their linking, and it’s important to kind of understand that and how the rules play across that, I think.

Steven: Yeah, absolutely and this is an interesting point to try to emphasize here. One of the lessons that I would say, you know, personally I’ve learned, and I think a lot of my colleagues share here as a regulatory agency. We are only, our rules are only as good as we are able to communicate them, and you know, we see, you know, a lot of, just to pick on our other colleagues, you know, at the Office of Civil Rights, you know, HHS with the HIPAA privacy and security rules. Probably one of the most often cited, confused, you know, rules in terms of whether or not, you know, healthcare organizations are allowed to share data with patients if they’re allowed to share data with other healthcare organizations and our colleagues at OCR do a great job putting out, you know, frequently asked questions and other guidance, you know, in this new electronic ecosystem but it seems like, it’s never enough, you know, to really satisfy everyone’s needs and similarly, we have that same experience with a certification through our regulatory, you know, purview and oversight. You know, we run an effectively, I like to describe it as a citizen service. You know, we don’t issue passports here at ONC, but we effectively run the ONC health IT certification program and health IT software developers that seek to get their health IT software certified through our program are our customers. You know, we do the best that we can in implementing our regulatory requirements to make sure that they know the items with which they need to comply, and they can do so consistently and so, the way in which we approach regulation sometimes is to make sure that we are explicitly clear or as explicitly clear as we can be about the types of actors or stakeholders that are involved and so, with the proposals that we constructed for the API condition of certification, we really viewed this in a somewhat triangular relationship. So, we have the health IT developer, we refer to them in this context as an API technology supplier. They’re the organization that’s putting the software engineers and other types of software developers toward the creation of our proposals what would be a FHIR server. So, fast healthcare, interoperability resources, FHIR, and that would be the kind of software stack on which healthcare organizations would be able to make their data accessible. So, we refer to those healthcare organizations as API data providers because they’re the ones that are the stewards of health data and they’re making that data available to either other third parties with whom they want to have a business relationship. So, in a B to B way or to support equally important contexts when a patient just like us, when we’re requesting our health information through our HIPPA right of access, the healthcare organization will then again be supplying that data to the patient and in the instances, just to cover of the third actor here where you have someone that’s interacting with the API technology that wasn’t the original creator of that FHIR server and that isn’t a data steward that’s providing access to the data. We refer to those, they’re kind of the rest of that community as API users and so, these would be, if I’m a healthcare provider first, you know, it could be a population analytics company that I set up a contract with to do some analysis of my diabetic population. They would be considered an API user, VISA via proposals and then equally me as a patient, if I seek to use some type of third-party application to connect to the healthcare providers API, us too, me and my app would be considered an API user in that context.

Dave: That’s a great overview and again these sort of three buckets. So, there is the API tech supplier, the folks that are building an application and you’ve been very specific in this case that’s offering the FHIR spec API, there’s the API data provider, typically a health system or other that is licensing that technology and then there’s the API user, which could be a patient, could be a third party that’s got an App that requires the data and what’s interesting to me is the way these all fit together and how the rules have looked at some specific areas to ensure a balanced playing field and in to promote competition. So, for example, these days, it’s sometimes not clear who has authority, either formally or informally to decide that an API user, i.e. a third party. Let’s just say for the sake conversation, a mobile app developer, do they get to connect or not? Is it the sole purview of the licensee or does the technology supplier have a role in that as well and as I read the rules, they go directly at this sort of issue and they basically say, look, to be certified, you’ve got to serve it up as a FHIR standard and you’ve got to deliver the US CDI Dataset and it’s really up to the API data provider, typically the person licensing that technology to decide who they want to do business with and who connects and has access. So, to put a real concrete point of this, an EHR vendor will license our technology to a health system and as part of this arrangement, it will be really at the discretion of the health system to determine which third parties they want to do business with. Now we’ll carve patients out because they’re an exception and there’s really clear direction on what patients have a right to as well. So, again, I would ask you to either, you know, clarify or correct me or if I kind of bucketed up this thing in a way that makes sense and is that a typical scenario we can look forward to?

Steven: Yeah, absolutely and I think to put the finest tip point on it. You know, the scenario that you brought up was one that we’ve, you know, long heard about, I think that Congress heard about as well in part leading to the legislation that was passed in the 21st Century Cures Act and it was really this context where, you know, as you noted, maybe not to anyone’s fault per say but there was ambiguity in the market and you know, in a healthcare organization were to license or be supplied API technology by their API technology suppliers, we like to refer to them now. You know, it wasn’t clear how or under what terms and conditions the licensee, let’s call it in this case, you know, the healthcare organization or healthcare provider could on their own, you know, do a business-to-business kind of interaction with a third party if they wanted some new type of clinical decision support service or again, they wanted to do some type of population analytics or quality improvement study with their own data. They were faced with having to go back to their health IT developer to ask for permission and so, one of the things that we explicitly did under our pro-competitive conditions within the larger API condition certification was to say the health IT developer, in this context, the API technology supplier is responsible for, you know, producing the technical, you know, capacity, the technical capabilities embodied in this FHIR server and getting that certified in making sure that it’s standard conformant etc. can supply the US core data for interoperability as you mentioned and when they license it and hand it over and there’s an instance of that at a particular healthcare provider, it’s then their decision what they’re going to do with their own, the API that they’ve acquired, right. So, that healthcare provider is in the driver’s seat and they’re allowed to or they would be allowed pursuant to our proposals, you know, dictate with whom they want to have a relationship from, you know, different third-party services, etc. that may even compete with their original API technology supplier and that was really important for us. I think to a point you mentioned earlier about kind of re-levelling the playing field and making sure that there were opportunities for competitive entrance at all levels. You know, with respect to working with healthcare providers.

Dave: Well, this is a topic of great interest to me personally, I have coined the phrase ‘Innovation Constipation’. You can use that hashtag if you dare to, and it again, I see it as, you know, it’s just, there’s been a lack of natural alignment for some of the key stakeholders. It’s a classic market failure and as I read these rules, they’re designed to address this with you know, a minimal amount of regulation required. Like most things in life, we’ll try it and we’ll learn from the doing as well. If you have just joined us, you’re listening to 4 x 4 health. We are talking with Steve Posnak, Executive Director of the Office of Technology for ONC about interoperability and information blocking. Steve, the way I would summarize what I’ve heard so far is you’ve defined who the key players are in this, the folks who make technology, the folks who consume it and the folks that want to leverage that data for other activities. We’ve talked about if you will, the sort of specifications for the plugs and the sockets, the technical protocols and the like under an API and use of FHIR and we’ve talked about the data that can flow over those wires as it were as well. You know, part of having rules is enforcing rules and so what I’d like you to do now is take a few minutes and explain to us the enforcement aspects of this. How does this play into certification? What are the stakes for the various players to conform to these rules and the potential penalties if they don’t?

Steven: Sure, absolutely and, you know, the way I typically like to do this is to first start with the information blocking section of the 21st Century Cures Act and so, the way to kind of keep that in mind is that there are four named actors in the statute. The first being a health IT developers, second being health information exchanges, third being health information networks and then the fourth being healthcare providers. The last one has a specific statutory definition and if folks are interested they could certainly go and check that out on our website at www.healthit.gov as well as, you know, commenting through the proposed rule, which again is open until May 3rd and when it comes to health IT developers, largely the enforcement is kind of joint jurisdictional in that for information blocking related issues of the HHS Office of the Inspector General is charged with the ability to implement fines or civil monetary penalties. In this case, they could be up to $1 million per violation and that would be issued by again, the Office of the Inspector General and that would apply to the health IT developers, the health information exchanges and the health information networks. When it comes to the health IT developers that go through the ONC health IT certification program, they’re also subject to the full slate of what are called the conditions of certification again, and the easiest way that I try to describe the way in which the conditions of certification apply prior to the 21st Century Cures Act, ONC certification program and our authority really focused on the software product. Did the software product have the requisite functionality? Was it, you know, producing transactions that use the you know, specified standards in a conformant way and if there were other kind of business practices that a health IT developer engaged in, say, anti-competitive or discriminatory practices, we really didn’t have the authority to take oversight action in respect to those types of business practices. The 21st Century Cures Act changed that in that these conditions of certification now that we’ve included in our proposed rule apply to that, the health IT developer organization as a whole, which means they may have a fully technically, you know, compliant software product, but their actions in the market could violate one of the conditions of certification and at that point, ONC in this case, would have enforcement and Oversight Authority and depending on the type of activity that they were engaged in, our first interest is always to make sure that the health IT developer can remedy either a product nonconformity or in this case it could be a business you know, practice, you know, to cure whatever their behaviours may be and rectify the situation but if we were to need to take further action, you know, the health IT developers participation in the health IT certification program could be jeopardy.

Dave: Those are pretty big sticks, a million dollar fine per episode. The potential to have your module or your entire application decertified which would be catastrophic for a business. I do like the idea that, you know, the goal really is to identify issues and remedy them and then lastly this, as I said, this combination of looking not just at what we do from a technical standpoint, but behaviour and Michael Lipinski and I got pretty deep into this. If folks are wondering, well what’s an example of this kind of behaviour? It would be things like saying, well sure you can have the data but I’m going to charge you five times what I charged the other customer and I won’t be able to get to your class for 12 months. Well, that’s a class that’s really a no, it’s a behavioural type thing and again, the laws and the proposed rule is designed to create a more level playing field when it comes to those kinds of behaviours as well. You mentioned the comment period and so take a minute and tell us, you know, what comes next in the process and in particular, how can our listeners and others who are interested in this topic get involved and support the process?

Steven: Yeah, absolutely. So, right now we have a, what’s called the Federal Advisory Committee. It is the health IT advisory committee. So, originally named and they are a collection of industry stakeholders, experts in the health IT, health policy field. You know that we are on this Federal Advisory Committee. They’re going through the effort of reviewing certain sections of our rules to issue us comments and then equally, you know, as the comment period expires and all of the comments are submitted and we go through a pretty intensive process on the back end, let’s call it where, you know, depending on the issues we categorize them, we break them up and we spend many hours reading through all of the comments and then our subsequent steps in creating a final rule, which I would say I particularly enjoy because it’s really more of a question and answer type of approach. So, for each of our proposals, we’ll give stakeholders a summary in a final rule. Here’s what we’ve proposed, you know, here’s what happened on, on last season of our health IT, you know, theories and then we go through each of the proposals and the feedback that we received through the public comments and explain, here’s how we finalize the regulatory proposals, here is where we didn’t accept certain public comments and for what reasons or you know, we found these types of comments convincing or appropriate to help clarify ambiguities or to help add, you know, some explicit, you know, language to the particular, we call it regulation texts. That is really the kind of 10 commandments aspect of the rules and, you know, that, that’s what we’ll go through over the next coming months but I would know we read every single comment, you know, and often, you know, it’s one or two comments that really have an uh huh moment in terms of, you know, there’s a lot of interdependencies that goes on with, within the rule. Just, you know, based on our conversation, right. You’ve got the information blocking dynamic, you’ve got the conditions of certification dynamic, their health IT developers are playing both of those worlds and the best part of a public comment process is when stakeholders really apply the proposals that we’ve put out and say, here’s how I see it working, you know, is that what you intended? And sometimes, you know, they’re absolutely right. You know, there’s an unintended consequence and they’re able to forecast that and you know, where we’re able to address those prior to issuing a final rule or at the time we issue a final rule is always satisfying from a regulator’s perspective.

Dave: Well, and it is important to get that kind of feedback. I’m reminded of that old programmer’s adage, with more eyeballs, all bugs are shallow, and I think the same is true here. Getting these different perspectives and really making, fulfilling the private part of the public-private partnership is essential. I am going to get a little flowery here and just say, you know, I am relatively new to this world, but I’ve been really impressed with Dr. Rucker and the team at ONC and their genuine interest in addressing these important problems and in input and discussion and the various forums in their availability and like I said, it’s like everything else in life, particularly complicated things, you know, it’s not going to be perfect, but it sure looks pretty darn good to me and I like the process and I’m grateful to folks like yourself that have invested clearly enormous time and effort to get us to this point. We will include links to the key websites and places where our listeners can go if they want to comment. Again, I would urge them to do that. In preparing for this podcast, I learned that you direct something called ONC’s standards and technology investments in the ONC tech lab. I have no idea what that is, but it sounded really cool. Can you take a minute and tell us about that? What are you up to in the tech lab?

Steven: Sure and I am glad you asked because you know, it isn’t necessarily, you know, one of those front and centre things on www.healthit.gov, but you know, really has an important aspect and, adds and important aspect and dimension to our work. So, the reason why this came about, and I appreciate you know, you got the coolness factor associated with it is, you know, all this work is as Dr. Rucker may mention, sometimes blisteringly complex and you know, we still liked to have fun while we are, you know, working hard at all of these complicated issues that oftentimes, you know, from my experience take three, five, seven years really to play out and you know, when you work in the Federal Government perspective that’s often, you know, from the time we issue a regulation to the time that you see, you know, the first changes in the market could be, you know, three or four years and the way in which we kind of govern ourselves and with my staff, we said, what can we do to make our work not about who we work for, you know, in a hierarchical sense, but about the work that we do because a lot of the work that we do together among the various different, you know, branches on my team and the usual bureaucratic fashion, it’s a very, we have a very matrix organization in terms of, we have people that have super detailed knowledge of a particular either standard or code set or vocabulary that they need to pair up with someone that is potentially doing a pilot or working with the innovation community on, you know, understanding something about health IT and it became really clear to us that we needed a different way to categorize our work and portrayed the work that we were doing across teams and so that’s why we came up with the ONC tech lab. So, you know, one of the areas where we kind of blend together innovation and pilot-oriented work is we’ve recently released last year, what’s called the Leading Edge Acceleration Projects, LEAP, you know, because we always need an acronym in Government and you know, otherwise, you know, we’ll just let people down. So, we, you know, we put that out as an opportunity for the industry to say, here are a few forward-looking areas that we are willing to make some investments in. So, we’ve been working on that. We also do prize competitions from time to time, that really fit within our innovation space and then when it comes to standards coordination overall, one of the superpowers that we have as a coordinator or a convener is to work with the various, what are called Standards Development Organizations that are out there in the health IT space. So, you know, you’ve got HL7, IG, NCPDP, you know, LOINC, Snowmad, X12, at various, you know, various different levels, right. Some of them are you know, vocabulary and code sets, some of them are at what we call content, you know, exchange structure, you know, in syntax. Then making sure that they, they’re aware of some of the policy work that’s going on, that would affect, you know, the underlying standardization activities that happen in the organizations, but also to make sure that you know, we’re investing in the overall ecosystems approach and similarly, the way in which we do that, which is kind of this last area of the tech lab is around testing and other utilities and so we have certain test tools that we have built with our colleagues at the National Institute of Standards and Technology, NIST, which is another federal agency. People may be familiar with them from like, you know, the length of an inch or something along those lines. I almost said the wrong unit of measure. So, I’m glad I caught myself there, which would have been embarrassing as engineering guy, right and so, you know, we’ve worked with them for you know, throughout the almost better part of the last decade in putting together automated, you know, electronic testing tools for different types of health IT transactions. We at ONC, I’ve also financed the consolidated CDA, our related testing suite and, so we have one that’s more oriented for our certification program, but one that’s also oriented for just the community at large and so that one we call the CCDA scorecard where you know, as you’re an implementer and you’re working with the CCDA, you can keep testing, you know, up against it to see alright, you know, what are my issues, it’s kind of a debugging, you know, tool to help you make progress and lastly, you know, we’ve turned toward FHIR and you know, we have a FHIR server testing tool which we refer to as inferno because you’re not allowed to do anything in FHIR without using a pun.

Dave: No, I have to interrupt you there. We have a strict policy on 4 x 4 health, no FHIR puns. So, I’m going to let you slide. I am just going to give you a warning this time, no tick but I do want you to be aware.

Steven: That’s right, that’s right, alright. Well, that’ll be the, I’ll keep myself in check here. You know, so, we again look at opportunities for how we can advance industry consistency, right because as much value as a certification program can add, it is pretty downstream when it comes to the original, you know, specification development and early implementation testing that health IT developers may do and so, you know, again in a different way, you know, ONC as a federal agency plays, you know, we have had as a regulator, but then we also work our way upstream to try to collaborate, you know, just with, you know, the private sector to make sure that all the investments that are necessary to advance in interoperability to make sure that health IT products are being implemented consistently are there and so, you know, sometimes we invest in these testing and utility efforts.

Dave: Well, I think I was right. I said it sounded cool and it really does seem like it is pretty cool. I am always interested in not just the work, but how we do the work and how that affects us and so, I was very taken with the first part of your description that this was not just about how does ONC do its job better and partner with these different stakeholders better, but it also speaks to the staff at ONC and, you know, how do you build a sustainable workforce and all those other things. So, you really spoke to me on a couple of different levels there. Thanks for sharing that. I suspect that it may have been wrapped up in this as well, but I want to give you the last word here today. What is your most sage advice about all of this as we go forward as folks think about interoperability, about where these, where we are with these rules and where we’re going? You’ve been at ground zero for a long time now, Steve, I am sure you have some sage advice for us.

Steven: Yeah, you know, thinking about how it would best approach this, is to have two young kids and so often with, you know, an eight-year-old and a five-year-old, I find myself reflecting on the instant feedback I get from them, you know, relative to what I thought was a completely sane and reasonable policy, you know…

Dave: Yeah. Wait until they are 13 and 16, they are going to really give it to you.

Steven: So, I hear. You know, there’s kind of two dimensions to this and we touched on it a little bit earlier as well. You know, the first part I would say more globally is, there’s really no substitute for being curious and delivering hard, you know, work and thoughtful work and you know, the other dimension with respect to the kind of the health IT ecosystem in which we work is really that, that ingredient mixture in terms of how policy and technology need to be put together and I would say just like upon reflection, you know, haven’t been at this for a while now as we like to say, we’ve had valiant efforts that were, you know, say eighty to a hundred percent policy focus and they missed the mark and you know, similarly on the flip side, we’ve had tremendous efforts on investing in technology that also missed the mark and you know, it’s not that they weren’t successful so to speak, but they weren’t as impactful as it could be in a lot of what we talk about at the office and a lot that we talk about, you know, just in terms of being federal employees in general, right, to be a civil servant here. We’re all here to make an impact and I think the other thing that, you know, you touched on earlier in terms of the feedback that we get now from the broader population is indicative of how mainstream health IT has become in our lives. You know, it is not quite where we all want it to be because, you know, we are kind of on the cutting edge, but I hear from my mom, I hear from my dad, I hear from, you know, other people in my family. We hear from people at work now that are, you know, on Twitter or other types of social media expressing their frustration in their health IT experience and that really is what drives us. You know, it speak, you know, for everybody at ONC, it’s the personal experiences mixed with, you know, what we hear from the broader kind of American population about here’s where we think we can make an impact and, and we always strive, you know, getting back to my main point here to find the right blend of policy and technology that can really have that kind of amplifying effect.

Dave: Well, that’s really well said, and I couldn’t agree more with the gap between the experience and the rest of our lives, whether it’s you know, shopping or travelling or banking and what we experienced in health care, it’s a pretty big gap. I am fond of saying every day I work in healthcare and then I go home and live in the 21st century and, and I think that we all see that and feel it. I think the other thing that I hear, and this is, is the value of diversity and teamwork. So, you’re looking at the problem from a diverse perspective, you know, addressing the technical and the behavioural and the economics of it. I would extend that to say I again, as best I can grasp it, the way ONC and CMS have coordinated and collaborated to deliver a combined set of rules that in many ways are interlocking and self-reinforcing and as you said, we’ll see how it plays out. You know, typically life teaches us all kinds of interesting lessons when we go do things and I’m sure it will evolve from there. Very grateful to you today for sharing your insights and as I said earlier, for the work the whole team at ONC is doing. We’ve been talking with Steve Posnak, Executive Director of the Office of Technology for ONC. Steve, thanks again for joining us today.

Steven: Thanks, it was a pleasure.

Dave: You have been listening to 4 x 4 health, sponsored by Sansoro health. Sansoro health, integration at the speed of innovation. Check them out at www.sansorohealth.com. I hope you will join us next time for another 4 x 4 discussion with healthcare innovators. Until then, I am your host Dr. Dave Levin, thanks for listening.